- 22 Jun, 2005 40 commits
-
-
NeilBrown authored
Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
- report sync_size properly - need /2 to convert sectors to KB - move everything over 2 spaces to allow proper spelling of "events cleared". Signed-off-by:
-
akpm@osdl.org authored
A u64 is not an unsigned long long. On power4 it is `long', and printk warns. Signed-off-by:
-
NeilBrown authored
As the array-wide clean bit (in the superblock) is set more agressively than the bits in the bitmap are cleared, it is possible to have an array which is clean despite there being bits set in the bitmap. These bits will currently never get cleared, as they can only be cleared by a resync pass, which never happens. No, when reading bits from disk, be aware of whether the whole array is known to be in sync, and act accordingly. Signed-off-by:
-
NeilBrown authored
Signed-off-by:
-
NeilBrown authored
The debugging message printed the wrong pid, which didn't help remove bugs.... Signed-off-by:
-
NeilBrown authored
bitmap_daemon_work clears bits in the bitmap for blocks that haven't been written to for a while. It needs to be called regularly to make sure the bitmap doesn't endup full of ones .... but it wasn't. So call it from the increasingly-inaptly-named md_check_recovery Signed-off-by:
-
NeilBrown authored
1/ When init from disk, it is a BUG if there is nowhere to init from, 2/ use seq_path to print path in /proc/mdstat Signed-off-by:
-
NeilBrown authored
With this patch, the intent to write to some block in the array can be logged to a bitmap file. Each bit represents some number of sectors and is set before any update happens, and only cleared when all writes relating to all sectors are complete. After an unclean shutdown, information in this bitmap can be used to optimise resync - only sectors which could be out-of-sync need to be updated. Also if a drive is removed and then added back into an array, the recovery can make use of the bitmap to optimise reconstruction. This is not implemented in this patch. Currently the bitmap is stored in a file which must (obviously) be stored on a separate device. The patch only provided infrastructure. It does not update any personalities to bitmap intent logging. Md arrays can still be used with no bitmap file. This patch has minimal impact on such arrays. Signed-off-by:
-
NeilBrown authored
1/ change the return value (which is number-of-sectors synced) from 'int' to 'sector_t'. The number of sectors is usually easily small enough to fit in an int, but if resync needs to abort, it may want to return the total number of remaining sectors, which could be large. Also errors cannot be returned as negative numbers now, so use 0 instead 2/ Add a 'skipped' return parameter to allow the array to report that it skipped the sectors. This allows md to take this into account in the speed calculations. Currently there is no important skipping, but the bitmap-based-resync that is coming will use this. Signed-off-by:
-
NeilBrown authored
When md marks the superblock dirty before a write, it calls generic_make_request (to write the superblock) from within generic_make_request (to write the first dirty block), which could cause problems later. With this patch, the superblock write is always done by the helper thread, and write request are delayed until that write completes. Also, the locking around marking the array dirty and writing the superblock is improved to avoid possible races. Signed-off-by:
-
NeilBrown authored
md_enter_safemode checks if it is time to mark the md superblock as 'clean'. i.e. if all writes have completed and a suitable delay has passed. This is currently called from md_handle_safemode which in-turn is called (almost) every time md_check_recovery is called, and from the end of md_do_sync which causes the mddev->thread to run, which will always call md_check_recovery as well. So it doesn't need to be a separate function and fits quite well into md_check_recovery. The "almost" is because multipathd calls md_check_recovery but not md_handle_safemode. This is OK because the code from md_enter_safemode is a no-op if mddev->safemode == 0, which it always is for a multipathd (providing we don't allow it to be set to 2 on a signal...) Signed-off-by:
-
NeilBrown authored
Currently if add_new_disk is used to hot-add a drive to a degraded array, recovery doesn't start ... because we didn't tell it to. Signed-off-by:
-
NeilBrown authored
i.e. missing or failed drives are moved to the end of the list. The means a 3 drive md array with the first drive missing can be shrunk to a two drive array. Currently that isn't possible. Also, the "last_used" device number might be out-of-range after the number of devices is reduced, so we set it to 0. Signed-off-by:
-
James Simmons authored
Several drivers miss filling in the access_align field. So this patch has them fill it in. Signed-off-by:
James Simmons <jsimmons@www.infradead.org> Signed-off-by:
-
James Simmons authored
Shrink the stack when calling the drawing alignment functions. Signed-off-by:
-
Jurriaan authored
Improve the fonts for use with the framebuffer. I've added all the characters marked 'FIXME' in the sun12x22 font and created a 10x18 font (based on the sun12x22 font) and a 7x14 font (based on the vga8x16 font). This patch is non-intrusive, no options are enabled by default so most users won't notice a thing. I am placing my changes under the GPL, however, I've not seen any copyright notices on the sun12x22 font and the vga8x16 font which I derived my new fonts from so I don't know what the copyright status is. Signed-off-by:
-
James Simmons authored
Patch adds pci ID for CT 69000 chipset. Signed-off-by:
-
Jaya Kumar authored
Add support for the Arc monochrome LCD board. The board uses KS108 controllers to drive individual 64x64 LCD matrices. The board can be paneled in a variety of setups such as 2x1=128x64, 4x4=256x256 and so on. The board/host interface is through GPIO. Signed-off-by:
Jaya Kumar <jayalk@intworks.biz> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: <linux-fbdev-devel@lists.sourceforge.net> Signed-off-by:
-
Sylvain Meyer authored
Add a small documentation of the driver parameters. Signed-off-by:
Sylvain Meyer <sylvain.meyer@worldonline.fr> Signed-off-by:
-
Sylvain Meyer authored
Changed the tests in intelfb_set_par to check also the parameter var.accel_flags. If null, do nothing about ring buffers. Now, the DirectFB i830 driver could nicely work even if intelfb is hw accelerated. Just change the /etc/fb.modes file to disable console hw acceleration when starting a DirectFB app. Signed-off-by:
-
Sylvain Meyer authored
- Add voffset option to avoid conficts with Xorg i810 driver Signed-off-by:
-
James Simmons authored
Currently when going from vgacon to fbcon the VT screenbuffer are often different sizes. In the case when they are different sizes a new VT screenbuffer is allocated and the contents are copied into the new buffer. Currently the amount copied from VGA text memory to the new screenbuf is the size of the framebuffer console. If the framebuffer console new VT screen buffer is greater than the VGA text memory size then we get some of the VGA BIOS contents as well. This patch will only allow you to copy up to the size of VGA text memory now. The rest is filled with erase characters. Initial patch by Jordan Crouse <jordan.crouse@amd.com> Signed-off-by:
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
James Simmons authored
Since no one is using the inbuf, outbuf of struct fb_pixmap I removed their use in the framebuffer console. The idea is instead move the pixmap functionality below the accelerated functions intead of on top as the way it is now. If there is no objection please apply. This is against Linus latestr GIT tree. Thank you. Signed-off-by:
-
Andrew Morton authored
Can't use this fancy name, because it's used to generate a sysfs filename: kobject_register failed for Intel(R) 830M/845G/852GM/855GM/865G/915G Framebuffer Driver (-13) [<c01bf8e3>] kobject_register+0x43/0x70 [<c022dfe2>] bus_add_driver+0x52/0xa0 [<c01c8c10>] pci_device_shutdown+0x0/0x20 [<c01c8d71>] pci_register_driver+0x61/0x80 [<c0387099>] intelfb_init+0x59/0x70 [<c03787cc>] do_initcalls+0x2c/0xc0 [<c0159025>] kern_mount+0x15/0x17 [<c01002a0>] init+0x0/0x100 [<c01002ca>] init+0x2a/0x100 [<c0100f58>] kernel_thread_helper+0x0/0x18 [<c0100f5d>] kernel_thread_helper+0x5/0x18 Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by:
-
Gerd Knorr authored
Fix the size passed to release_mem_region in an error path. Also adjust the message printed when vesafb cannot load; the comment there already says this must not be fatal, so the message should also not mention the word 'abort' otherwise indicating a problem to worry about in the log. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Gerd Knorr <kraxel@suse.de> Signed-off-by:
-
Andrew Morton authored
s1d13xxxfb_remove() is referenced from s1d13xxxfb_probe(), which is marked __devinit(). So s1d13xxxfb_remove() cannot be marked __devexit. Does this all make sense? Clearly the __devexit section will still be in core when the __devinit code is run, if the driver was loaded as a module. But I suppose that if the driver is statically linked, the __devexit section might be dropped early in boot. Still, we wouldn't drop __devexit prior to initcall completion, at which point the __devinit code has all been run anyway. verdict: this code was legal and made sense. Is this a generic problem, or an arm-specific problem? UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 `.exit.text' referenced in section `.init.text' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o Cc: Russell King <rmk@arm.linux.org.uk> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Keenan Pepper authored
I don't see any reason why the framebuffer should need to be cleared, and it makes Tux vanish. Cc: <linux-fbdev-devel@lists.sourceforge.net> Signed-off-by:
-
Jeremy White authored
The current isofs treatment of hidden files is flawed in two ways. First, it does not provide sufficient granularity; it hides both 'hidden' files and 'associated' files (resource fork for Mac files). Second, the default behavior to completely strip hidden files, while an admirable implementation of the spec, is a poor choice given the real world use of hidden files as a poor mans copy protection scheme for MSDOS and Windows based systems. A longer description of this is available here: http://www.uwsg.iu.edu/hypermail/linux/kernel/0205.3/0267.html This patch was originally built after a few private conversations with Alan Cox; I shamefully failed to persist in seeing it go forward, I hope to make amends now. This patch introduces granularity by allowing explicit control for both hidden and associated files. It also reverses the default so that by default, hidden files are treated as regular files on the iso9660 file system. This allow Wine to process Windows CDs, including those that are hybrid Mac/Windows CDs properly and completely, without our having to go muck up peoples fstabs as we do now. (I have tested this with such a hybrid + hidden CD and have verified that this patch works as claimed). Signed-off-by:
Jeremy White <jwhite@codeweavers.com> Signed-off-by:
-
Andrew Morton authored
Handle the case where the variable-sized part of a rock-ridge directory entry overhangs the end of the buffer which we allocated for it. Signed-off-by:
-
Andrew Morton authored
The silly thing does: struct foo { ... }; ... #define foo 42 so you can no longer refer to `struct foo' in C code. Rename the structures. Signed-off-by: -
Andrew Morton authored
The bug in rock.c is that it's totally trusting of the contents of the directories. If the directory says there's a continuation 10000 bytes into this 4k block then we cheerily poke around in memory we don't own and oops. So change rock_continue() to apply various sanity checks, at least ensuring that the offset+length remain within the bounds for the header part of a struct rock_ridge directory entry. Note that the kernel can still overindex the buffer due to the variable size of the rock-ridge directory entries. We cannot check that in rock_continue() unless we go parse the directory entry's signature and work out its size. Signed-off-by:
-
Andrew Morton authored
isofs/inode.c: - Remove some crufty leak detection code - coding style cleanups - kfree(NULL) is permitted. Signed-off-by:
-
Andrew Morton authored
So we have a couple of rock-ridge bugs. First up, rotoroot the poor thing into something which it is possible to work on. Feed rock.h through Lindent, tidy a couple of things by hand. Signed-off-by:
-
Andrew Morton authored
Be a bit more standard in comment layout. Signed-off-by:
-
Andrew Morton authored
- remove the MAYBE_CONTINUE macro - kfree(NULL) is OK. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Andrew Morton authored
- Remove the SETUP_ROCK_RIDGE macro. - In rock_ridge_symlink_readpage(), rename raw_inode to raw_de. It points at a directory entry, not an inode. Signed-off-by:
-
Andrew Morton authored
Remove the CHECK_CE macro Signed-off-by:
-
Andrew Morton authored
Remove the CONTINUE_DECLS macro. Signed-off-by:
-
