I just spent the better part of my afternoon figuring out what the hell was wrong with my girlfriend's Creative ZEN V Plus MP3 player. It froze yesterday and hasn't been able to connect to our computers since. Everytime she turned it on, it said Rebuilding Library, but it normally only does that during the boot immediately after it froze and has to be manually reset. It wouldn't connect in Linux, and in Windows the obnoxious balloon tips would report "MTP device found" again and again. In the Device Manager, it reported "Code 10: Device cannot start." Well, we finally found a fix.
Searching for zen v plus code 10 turns up 287,000 results including countless forum threads with no helpful replies. The most common suggestion is to uninstall the device in Device Manager, but trying this numerous times did nothing to help.
Many threads from Microsoft's social.answers.microsoft.com show the exact same problem reported over and over again, but no helpful responses.
After wasting hours searching the internet, we discovered the ZEN's Recovery Mode. You enter it by turning on the ZEN while holding down the Play button.
Selecting "Clean up" performs some magic which I cannot explain. Then select Reboot. When your ZEN comes back to life, it'll happily connect to your computer.
What an obnoxious problem. You'd think Creative would have written this article a few years ago, but they'd probably rather you junk your ZEN V Plus and hand over another hundred dollars for whatever their newest model is.
I've been involved with X.Org for a few months now. I want to increase my involvement, and at the same time learn the ropes. I also need something to do this summer–and that's why I've applied to the Google Summer of Code.
KMS for Permedia3/4 as a method for Documenting the KMS driver writing process
Abstract
The current trend in X11 graphics is to move mode-setting code into the kernel, allowing for faster and more graphical boots with fewer flickers. Only the big three drivers, Radeon, Intel, and Nouveau, support KMS, but there are many more X11 drivers that could benefit as well. Unfortunately, the big three drivers are large (smallest is 26,000 lines, largest is 65,000 lines) and complex, and is there no official documentation for writing KMS drivers. This project aims to provide the community with both documentation for writing KMS drivers and a basic, unaccelerated, reference KMS driver for Permedia3-series hardware.
Benefits to the Community
With a small reference KMS implementation and clear and detailed documentation, written from the perspective of a student not fluent in the world and process of writing graphics drivers, others should be able to write KMS drivers for other hardware much more easily and therefore improve the experience of users with such hardware.
Project Tasks
Implement a shell driver that claims the hardware. Get my hands dirty with kernel code. Once this is completed,
Implement basic mode-setting for the Permedia3. Although the Permedia4 (and Permedia2) are very similar, the mode-setting code on each chip could have its own bugs and headaches, so I am limiting the scope to only Permedia3.
Implement basic memory management using TTM. Study the TTM API, documenting relevant parts. Once the memory manager is completed, polish the code into something others can read and follow. This stage will be complete when X11 can run on the KMS driver using fbdev.
Write Documentation and Programming Guides for KMS, TTM, and other DRM interfaces.
Optional Tasks
Implement some form of Command Submission.
Implement system for submitting commands to the kernel
Implement system for knowing when the commands have been completed
Improve the memory manager to handle command buffers
Using command submission, accelerate some tasks of the KMS driver such as copy area and rectangle fills.
Make the existing xf86-video-glint DDX capable of operating with the KMS driver.
Make the existing xf86-video-glint DDX capable of making use of the memory manager.
Deliverables
Shell driver that claims the hardware (1 week)
Implement basic mode-setting (3 weeks)
Implement basic memory management using TTM (3 weeks)
Bug Fixes and polish - basic, unaccelerated KMS driver capable of providing fbdev with linear VRAM access. (2 weeks)
Document the process, finish Documentation and Guides for writing KMS drivers (2~3 weeks)
Optional Tasks
Command Submission (3 weeks, if time allows)
Accelerated KMS driver (1 week, if time allows)
Eventual Tasks, outside the scope of GSoC
Make xf86-video-glint run with KMS driver
Make xf86-video-glint capable of making use of memory manager
Related Work
Jesse Barnes proposed a work-in-progress patch to includes documentation that "provid[es] basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure."
Existing Permedia2/3 framebuffer drivers exist in the Linux Kernel, drivers/video/pm{2,3}fb.c.
Biographical Information
I am a senior at Lenoir-Rhyne University, with a major in Physics and minors in Mathematics and Computer Science. I work for the school's marketing department doing PHP/Drupal web development.
I'm a contributor to X.Org, the Linux Kernel, and Alpha/Linux (where I'm the de facto glibc maintainer).
For this summer, I plan to have a part-time internship, mostly unrelated to programming.
Skills and Qualifications
I'm experienced programming in C and x86/Alpha assembly. I'm also quite persistent and do not give up easily.
I've made close to 30 commits to the X server, for changes to between 1500 and 2000 lines of code. I've also made minor changes to the xf86-video-ati and xf86-video-intel drivers.
On the Kernel side, I run the alpha-2.6 git tree for collecting and funneling DEC Alpha patches that I and others write to Linus. I've made minor commits to the DRM kernel code.
I also maintain the AlphaLinux.Org Wiki, a community site documenting Alpha hardware, software, and the latest developments in open source affecting Alpha/Linux users.
My current desktop has served me quite well for nearly four years. Its Sempron 2800+ certainly doesn't compete with Phenoms or Core 2's in terms of performance, but what really bothered me about it was its lack of power management support. By some arbitrary decision, AMD chose to disable Cool'n'Quiet on Semprons <3000+. I've been vaguely interested in upgrading the processor for a while, but options are rather limited. It's not worth it to upgrade to a faster Sempron. Socket 754 Athlon 64s use quite a bit more power and mobile Athlon 64s still cost well over one hundred dollars. Socket 754 Turions exist, but I couldn't find any mention of compatibility with my ABIT NV8. I figured for eight dollars it was well worth the gamble, and bought a mobile Turion ML-34 on eBay to give it a try and to give my desktop a final upgrade.
So the specifications of the two processors are
Sempron 2800+
Turion ML-34
Frequency
1.6 GHz
1.8 GHz
L2 cache
256 KiB
1024 KiB
Power consumption
62 W
35 W
Power management
No
Yes
Being mobile processors, Socket 754 Turions don't have a heatspreader separating the die from the heatsink. To allow my Scythe Ninja heatsink to make contact directly with the core, I removed the black heatsink mounting equipment from the motherboard and shaved down about 2 millimeters from the bottom. After some adjustment it fit, and the heatsink made good contact. Once this was set, I fired it up. The BIOS even recognizes the Turion by name.
No benchmarks unfortunately, nor have I had a chance to test power consumption with my Kill-a-Watt. I can say that the CPU runs about 5 ℃ cooler. Linux also is able to change the CPU frequency on the fly between 1.8 GHz, 1.6 GHz and 800 MHz.
So I can confirm to any Socket 754 users left out there that Turions do work in the ABIT NV8. It's probably the most satisfying upgrade Socket 754 users as well.
As I was testing Radeon Kernel Mode-setting on Alpha, I casually started a conversation with Jesse Barnes, an Intel Graphics developer. I recalled that he was an ex-SGI employee, and being interested in SGI computers myself decided to ask him a question or two. What I learned about SGI absolutely floored me.
When Chicago Joe hacked a 600 MHz PMC-Sierra CPU into an SGI O2, the quest for newer, faster chips for the aging O2 began. 600 MHz is a nice upgrade, but why stop there? A 900 MHz CPU should be possible as well, but it would require changes to the O2's PROM at the source level. Due to one thing or another, SGI has been unwilling to release the PROM source code. I decided to ask Jesse if he knew the right people to contact at SGI to lobby for the release of the code.
The conversation went –
<mattst88> jbarnes, you used to work at SGI, no?
<jbarnes> yep
<mattst88> the holy grail of O2 hardware hacking is replacing the desoldering the CPU and replacing it with a a 600 MHz chip.
<mattst88> theoretically, 900 is also doable, but it would require the release of the O2's PROM code
<jbarnes> I played with some that had pmc 700MHz chips
<mattst88> rumor has it that Microsoft owns most of the code, from the MIPS consortium days
<jbarnes> I think we ended up not shipping due to some weird fp bug
<mattst88> any idea if SGI is even _able_ to legally release this code?
* jbarnes even did an irix kernel patch for that chip
<mattst88> btw, SGI just got bought out.
<jbarnes> yeah I'm still in touch with people there
<jbarnes> yeah they could release a lot of it
<mattst88> jbarnes, _SGI_ was going to ship 700 MHz chips for the O2?
<jbarnes> it's just a pain due to external contractors doing some etc
<jbarnes> yeah
<jbarnes> we even did an x86 port in 2000
<mattst88> never heard that before, that's cool stuff
<mattst88> x86 port of IRIX?
<jbarnes> yep
<mattst88> holy crap
<jbarnes> well time to go home...
<mattst88> do you think it's possible to pull the right strings to get as much code as possible to be released?
<mattst88> the PROM, that is?
<mattst88> btw, do you mind if I reproduce this conversation?
<jbarnes> sure sgi got sold so I guess it's ok for it to be widely known
<jbarnes> as for the prom... dunno who you'd talk to about that these days
<jbarnes> rich altmier is at intel now, otherwise he'd definitely be the guy
<mattst88> if you get any ideas, please let me know. there are definitely a lot of people who would love to hack at it
<mattst88> so, any more secret tidbits to share before you head for home?
<jbarnes> hehe
<jbarnes> I'm sure someone will write a book
<mattst88> why was the IRIX port to x86 not released?
<jbarnes> just show up to la fiesta in mtn view on any given wed evening and keep your ears open
<jbarnes> various reasons
<mattst88> saving them for the book? :)
<jbarnes> heh
<jbarnes> ok bbl
<mattst88> do you mind if I reproduce this conversation?
<jbarnes> sure np
<mattst88> thanks
