The 2.6.27 kernel is out [LWN.net]

The 2.6.27 kernel is out

Posted Oct 10, 2008 13:00 UTC (Fri) by Tuxie (guest, #47191) [Link]

No, but a layer of protection was added so it will print some debug data in your syslog instead of actually destroying the e1000 when the bug occurs.

The 2.6.27 kernel is out

Posted Oct 10, 2008 15:37 UTC (Fri) by iabervon (subscriber, #722) [Link]

The source of the problematic writes could be in a wide variety of places, many of which aren't in the kernel. 2.6.27 has a fix to make the hardware not break when they happen. The kernel fix makes e1000e behave like other hardware in not getting broken when those writes happen, so finding the real problem is less of an emergency, and seems likely to be some sort of X probing issue.

Device register violation

Posted Oct 13, 2008 21:29 UTC (Mon) by ncm (subscriber, #165) [Link]

I see what might be a similar sort of problem on my "nv" laptop: running "lshw" as superuser clobbers the display device registers. I have to reboot to get back control of the display.

First use of UBIFS?

Posted Oct 10, 2008 12:30 UTC (Fri) by rvfh (subscriber, #31018) [Link]

I would give it a few months before I trust it with any valuable data... or any data I need to access quickly without going through the restoration process ;-)

I am sure it quite good already, but better safe than sorry.

First use of UBIFS?

Posted Oct 10, 2008 12:46 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

UBIFS is for use on real flash.

SSD is not real flash. Well, it might be inside, but that's none of your business. It has a microcontroller between you and the flash, running a kind of pseudo-filesystem of its own, making it pretend to be a hard drive.

So far, I've never seen an SSD where the code on that internal microcontroller is actually any good, and where it won't lose data if you subject it to stuff like power-fail testing. Who knows? Maybe one day they'll be suitable for real data. Maybe some of them already are?

And that's ignoring the efficiency and the wear-levelling implications of running one journalling file system on top of another.

The new support we have for telling the underlying block device that it can forget the contents of certain sectors will help — but really, we can do better if we just let the dog see the rabbit. Give us real flash, and get your steenking microcontrollers out of our way.

First use of UBIFS?

Posted Oct 10, 2008 13:09 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

I should probably point out that I haven't been blessed with one of the shiny new drives that Linus raves about yet. Those are still like gold dust, it seems. So I haven't done any testing on those, and they're not included in the above observations.

First use of UBIFS?

Posted Oct 10, 2008 13:14 UTC (Fri) by epa (subscriber, #39769) [Link]

Is UBIFS a journalling filesystem? Why? If you have random access storage
then there is no particular need to keep a journal all in one place.
Rather than writing information synchronously to the journal you might as
well write it synchronously to the real place it has to go.

First use of UBIFS?

Posted Oct 10, 2008 16:04 UTC (Fri) by jamesh (subscriber, #1159) [Link]

From the look of the UBIFS web page, the data written to the journal becomes the new version of the data rather than being copied somewhere else when processing the journal.

I'd imagine that you'd want journalling of some form on flash for the same reason you'd want it on disk: to recover from power failures and crashes.

First use of UBIFS?

Posted Oct 10, 2008 18:37 UTC (Fri) by dedekind (subscriber, #32521) [Link]

This is right. Our journal is "wandering". We accumulate data in the journal, and then commit, which means we just update the indexing information. Then we pick different eraseblocks for the new journal.

Also, the journal is multi-headed. One head is for data, one head is for stuff like inode met-adata, truncation nodes etc - this nodes are likely to become obsolete soon. One head is for Garbage collector. This way we minimize the amount of Garbage collection.

Potentially, it is possible to dynamically allocate journal heads and separate data ford different inodes. That would optimize things even more, but we did not implement this.

First use of UBIFS?

Posted Oct 10, 2008 13:14 UTC (Fri) by salimma (subscriber, #34460) [Link]

SSDs on laptops provide a block-device interface. For the embedded Linux systems that UBIFS is targeted to, hopefully the vendor should enable it for you.

(I bet Nokia is planning to use it for their new Internet tablets, for example)

First use of UBIFS?

Posted Oct 10, 2008 18:56 UTC (Fri) by dedekind (subscriber, #32521) [Link]

Right. This often confuses "non-embedded" people who do not distinguish between a "block device" and "mtd device". UBIFS is for MTD devices. Examples of block devices: HDD, eMMC, SSD, CF, SD, etc.

Glance here for more information about what is the difference: http://www.linux-mtd.infradead.org/faq/general.html#L_mtd...