- 19 Oct, 2004 40 commits
-
-
Antonino Daplas authored
From: Gerd Knorr <kraxel@bytesex.org>: "IMHO the the only sane thing is to have two options for total + remapped memory as well. Otherwise we'll end up changing that back and forth like it happened for the size calculation stuff for quite some time ... The patch below does just that and also has the other vmode fix (vmode = yres * linelength /* instead of yres * xres * depth >> 3 */)." Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Antonino Daplas authored
- use vesafb_fix.line_length * vesafb_defined.yres to calculate the minimum memory required for a video mode. From Aurelien Jacobs <aurel@gnuage.org>. - separately calculate the memory required for a video mode, memory to be remapped, and total memory (for MTRR). From Gerd Knorr <kraxel@bytesex.org>. - the 'vram' option is for memory to be remapped, not total memory. Signed-off-by:
-
Venkatesh Pallipadi authored
EDID_INFO is encroaching on the space meant for E820 map in zero-page. This will result in E820 map corruption on any system that has more=20 than 18 E820 entries and CONFIG_VIDEO_SELECT. Not sure how this bug=20 managed to hide for more than a year. Attached patch should fix the bug. Signed-off-by:
-
Antonino Daplas authored
fbcon doesn't set a unimap at boot time, so special characters come out wrongly. This is the code sequence in take_over_console(). newcon->startup() oldcon->deinit() newcon->init() The previous console driver (ie, vgacon), via its deinit method, may release the unimap allocated by fbcon in fbcon_startup. This is the reason why calling con_set_default_unimap() in fbcon_init() works, but not in fbcon_startup(). Check if the default display has an allocated unimap, and if it has none, call con_set_default_unimap(). And if the target display has no allocated unimap, then call con_copy_unimap(), where the source unimap is from the default display. Signed-off-by:
-
Takashi Iwai authored
From: Egbert Eich <eich@suse.de> I would like to utilize kernel ioctls to save/restore console fonts in VGA text mode when running X. So far the Xserver takes care of this however there more and more problems with this: 1. On some platforms (IA64) we need to POST the BIOS before we even have a chance to access the hardware ourselves. This POSTing will usually undo any changes to the graphics hardware that the kernel may have done. 2. More and more drivers fully rely on BIOS support however the BIOS functions which could be used to save/restore register settings may be broken so the only way of mode save/restore is getting/setting the BIOS mode ID. I've hacked up some code for X however I ran into two problems: 1. con_font_get() in linux/drivers/char/vt.c seems to be broken as the font parameters (height, width, charcount) are never reported back. Therefore this function seems to be pretty useless. The fix is simple (please see below). 2. fb consoles seem to allow to install fonts per vt so that the user can have a different font on every console. The text console driver doesn't support this: the font is downloaded to the video card and will be used for all systems. Still the vga_con driver stores the font parameters per console with the effect that setting a font with different parameters on one console will result in the wron values when this font information is read back from another console. Appearantly this broken feature has been introduced in 2.6 as in the 2.4 kernel the vga_con font information is stored in one single global variable. The IA64 platform at least still heavily relies on the VGA text console. To be able to fix some VT switching issues with X on this platform I need these two issues resolved. Signed-off-by: -
Antonino Daplas authored
Add iomem annotations to vga16fb.c Signed-off-by:
-
Antonino Daplas authored
Add iomem annotations to i810fb. Signed-off-by:
-
Antonino Daplas authored
Add iomem annotations to fbmem.c Signed-off-by:
-
Andreas Henriksson authored
When Antonino A. Daplas posted his "fbdev: Initialize i810fb after agpgart" patch he said that the ugly agp initialization hack for intel agp shouldn't be needed but that he couldn't test it. I have tested the framebuffer updates and additionally removed the initialization hack and it does indeed work. Signed-off-by:
Andreas Henriksson <andreas@fjortis.info> Signed-off-by:
-
Benjamin Herrenschmidt authored
Fix a small logic error in the monitor probe code when nothing was found. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Antonino Daplas authored
This patches fixes the following: - scrolling corruption if scrolling mode is SCROLL_PAN_MOVE. This bug was introduced by the tile blitting patch. - flashing cursor even when console is blanked Signed-off-by:
-
Antonino Daplas authored
Hopefully, this patch fixes one last major regression for one particular driver, namely matroxfb. This drier has 2 versions, one for the kernel and another as a '2.4 backport' patch. This patch adds a tileblitting extension to fbcon. This extension, in summary, is basically a forward-port of the 2.4 fbdev/fbcon framework to 2.6 but without the fbcon dependency. Tile blitting is similar to bitblit, except that the basic unit is a tile (a bitmap of x-by-y dimensions). The display, instead of being described in terms of pixels and scanlines, are described as a region further subdivided into rectangular sections. In fbcon parlance, a tile is a character. Besides a possible fix for matroxfb, tileblitting can be advantageous for hardware that supports some kind of fontcaching mechanism. Also, in the unlikely chance that the console begins supporting multicolored fonts, tileblitting is probably more optimal than bitblitting because bitblitting will need to push more data through the bus. To enable support for this extension, a driver needs to: - enable CONFIG_FB_TILEBLITTING - set FBINFO_MISC_TILEBLITTING in info->flags - set the required function pointers in struct fb_tileops. The required operations are: - void (*fb_settile)(struct fb_info *info, struct fb_tilemap *map); tells driver about the tile characteristics (dimensions, bitdepth) and about the tilemap which is an array of bitmaps: display->fontdata - void (*fb_tilecopy)(struct fb_info *info, struct fb_tilearea *area); move a rectangular section of tiles (bmove) - void (*fb_tilefill)(struct fb_info *info, struct fb_tilerect *rect); fill a rectangular section with a tile (clear) - void (*fb_tileblit)(struct fb_info *info, struct fb_tileblit *blit); copy an array of tiles to a rectangular section (putcs) - void (*fb_tilecursor)(struct fb_info *info, struct fb_tilecursor *cursor); cursor function Changes: Addition of this extension necessitates cleanup of fbcon.c. The basic drawing functions in fbcon are bmove, clear, putcs and cursor (the fbcon_* set). The fbcon_* set are just wrappers to accel_* set. However, usage is not consistent, some functions call the fbcon_* set, others call the accel_* set. With this patch, a new fbcon-specific structure (struct fbcon_ops) is created. Depending on the setting of the hardware, this struct contains pointers to either the tileblitting set or the bitblitting set (formerly the accel_* set). The tileblitting set is new in this patch. The vast majority of functions in fbcon will need to only call the fbcon_* set. In turn, it calls functions in struct fbcon_ops. Knowledge of the blitting type is not required. The accel_* set is renamed to bit_* and is moved into a separate file, bitblit.c. The tile blitting set is in tileblit.c. In my case at least, the cleanup did produce an unexpected but beneficial side effect, a little more speedup. Not much, < 5%. Petr, if you have comments, suggestions, or you think this is a bad idea, let me know. Signed-off-by: -
Antonino Daplas authored
Swsusp turns off the display when a power-management-enabled framebuffer driver is used. According to Nigel Cunningham <ncunningham@linuxmail.org>, the fix may involve the following: "...I thought the best approach would be to use device classes to find the struct dev for the frame buffer driver, and then use the same code I use for storage devices to avoid suspending the frame buffer until later..." Changes: - pass info->device to class_simple_device_add() - add struct device *device to struct fb_info - store struct device in framebuffer_alloc() - for drivers not using framebuffer_alloc(), store the struct during initalization - port i810fb and rivafb to use framebuffer_alloc() Signed-off-by:
-
Antonino Daplas authored
This patch fixes the 'fbcon=map:<option>" of fbcon. (This option has been present since 2.4, but got broken in 2.6). This particular option tells fbcon what framebuffer device gets mapped to what console. Syntax is: fbcon=map:abcd... where a, b, c, d,... are framebuffer numbers as it would appear in /proc/fb. Given only 2 valid fbdevs, 0 and 1, if fbcon=map:0110, then: tty1 = fb0 tty2 = fb1 tty3 = fb1 tty4 = fb0 (sequence repeats for the rest of the consoles) If an invalid framebuffer is used, then the console will be mapped to the first user-chosen framebuffer. Ie: fbcon=map:102 tty1 = fb1 tty2 = fb0 tty3 = fb1 <
-
Antonino Daplas authored
This fixes the logo failing to draw in vga16fb due to faulty boolean logic. Signed-off-by:
-
Antonino Daplas authored
- This patch removes the unnecessary call to banshee_wait_idle() from tdfxfb_copyarea, imageblit and fillrect. Removal of the sync will garner an additional ~20% in scrolling speed. - Removes "inverse" which generates a compile warning if modular. Signed-off-by:
-
Marcelo Tosatti authored
We can shrink the pagevec structure to cacheline align it. It is used all over VM reclaiming and mpage pagecache read code. Right now it is 140 bytes on 64-bit and 72 bytes on 32-bit. Thats just a little bit more than a power of 2 (which will cacheline align), so shrink it to be aligned: 64 bytes on 32bit and 124bytes on 64-bit. It now occupies two cachelines most of the time instead of three. I changed nr and cold to "unsigned short" because they'll never reach 2 ^ 16. Did some reaim benchmarking on 4way PIII (32byte cacheline), with 512MB RAM: #### stock 2.6.9-rc1-mm4 #### Peak load Test: Maximum Jobs per Minute 4144.44 (average of 3 runs) Quick Convergence Test: Maximum Jobs per Minute 4007.86 (average of 3 runs) Peak load Test: Maximum Jobs per Minute 4207.48 (average of 3 runs) Quick Convergence Test: Maximum Jobs per Minute 3999.28 (average of 3 runs) #### shrink-pagevec ##### Peak load Test: Maximum Jobs per Minute 4717.88 (average of 3 runs) Quick Convergence Test: Maximum Jobs per Minute 4360.59 (average of 3 runs) Peak load Test: Maximum Jobs per Minute 4493.18 (average of 3 runs) Quick Convergence Test: Maximum Jobs per Minute 4327.77 (average of 3 runs) Signed-off-by:
-
Christoph Hellwig authored
Currently we every filesystem with Posix ACLs has it's own reimplemtation of the generic permission checking code with additonal ACL support. This patch - adds an optional callback to vfs_permission that filesystems can use for ACL support (and renames it to generic_permission because the old name was wrong - it wasn't like the other vfs_* functions at all) - uses it in ext2, ext3 and jfs. XFS will follow a little later as it's permission checking is burried under several layers of abstraction. From: Dave Kleikamp <shaggy@austin.ibm.com> jfs doesn't currently set MS_POSIXACL (it doesn't require the acl mount option), so this test would fail here. The patch below will set it. Signed-off-by:
-
Christoph Hellwig authored
Not exactly something we want modules to mess around with. Signed-off-by:
-
Christoph Hellwig authored
no user in sight Signed-off-by:
-
Christoph Hellwig authored
Besides namei.c it's only used in the SN2 hwgraph code which can't be modular (and will be removed soon) Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
Rather lowlevel functions that modules shouldn't mess with and fortunately currently don't. Signed-off-by:
-
Christoph Hellwig authored
Not exactly a thing we want done from modules, and no module uses it anyway. Signed-off-by:
-
Christoph Hellwig authored
These are basically shared code for native/32bit compat code, but as CONFIG_COMPAT is a bool there's no need to export them. Signed-off-by:
-
Christoph Hellwig authored
Only legit user is the partitioning code, in addition some uml code is still using despite the uml people beeing told to fix it at least two times. Signed-off-by:
-
Christoph Hellwig authored
Two dcache.c functions that shouldn't be used by filesystems directly (probably a leftover of the intermezzo mess). Signed-off-by:
-
Christoph Hellwig authored
Only used by kernel/sysctl.c which absolutely can't be modular Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
cutting back some unused legacy PM code Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
-
Christoph Hellwig authored
Completely unused but exported function in fs/posix_acl.c Signed-off-by:
-
Christoph Hellwig authored
mb_cache_entry_takeout and mb_cache_entry_dup are totally unused. Signed-off-by:
-
Christoph Hellwig authored
Already since 2.4 all block devices use block_device_operations and shouldn't deal with file operations directly. Signed-off-by:
-
Jens Axboe authored
The various io schedulers don't convert to and from jiffies and ms in their sysfs exported values. This patch adds that. Signed-off-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Jens Axboe authored
Here is the next incarnation of the CFQ io scheduler, so far known as CFQ v2 locally. It attempts to address some of the limitations of the original CFQ io scheduler (hence forth known as CFQ v1). Some of the problems with CFQ v1 are: - It does accounting for the lifetime of the cfq_queue, which is setup and torn down for the time when a process has io in flight. For a fork heavy work load (such as a kernel compile, for instance), new processes can effectively starve io of running processes. This is in part due to the fact that CFQ v1 gives preference to a new processes to get better latency numbers. Removing that heuristic is not an option exactly because of that. - It makes no attempts to address inter-cfq_queue fairness. - It makes no attempt to limit upper latency bound of a single request. - It only provides per-tgid grouping. You need to change the source to group on a different criteria. - It uses a mempool for the cfq_queues. Theoretically this could deadlock if io bound processes never exit. - The may_queue() logic can be unfair since it fluctuates quickly, thus leaving processes sleeping while new processes are allowed to allocate a request. CFQ v2 attempts to fix these issues. It uses the process io_context logic to maintain a cfq_queue lifetime of the duration of the process (and its io). This means we can now be a lot more clever in deciding which process is allowed to queue or dispatch io to the device. The cfq_io_context is per-process per-queue, this is an extension to what AS currently does in that we truly do have a unique per-process identifier for io grouping. Busy queues are sorted by service time used, sub sorted by in_flight requests. Queues that have no io in flight are also preferred at dispatch time. Accounting is done on completion time of a request, or with a fixed cost for tagged command queueing. Requests are fifo'ed like with deadline, to make sure that a single request doesn't stay in the io scheduler for ages. Process grouping is selectable at runtime. I provide 4 grouping criterias: process group, thread group id, user id, and group id. As usual, settings are sysfs tweakable in /sys/block/<dev>/queue/iosched axboe@apu:[.]s/block/hda/queue/iosched $ ls back_seek_max fifo_batch_expire find_best_crq queued back_seek_penalty fifo_expire_async key_type show_status clear_elapsed fifo_expire_sync quantum tagged In order, each of these settings control: back_seek_max back_seek_penalty: Useful logic stolen from AS that allow small backwards seeks in the io stream if we deem them useful. CFQ uses a strict ascending elevator otherwise. _max controls the maximum allowed backwards seek, defaulting to 16MiB. _penalty denotes how expensive we account a backwards seek compared to a forward seek. Default is 2, meaning it's twice as expensive. clear_elapsed: Really a debug switch, will go away in the future. It clears the maximum values for completion and dispatch time, shown in show_status. fifo_batch_expire fifo_batch_async fifo_batch_sync: The settings for the expiry fifo. batch_expire is how often we allow the fifo expire to control which request to select. Default is 125ms. _async is the deadline for async requests (typically writes), _sync is the deadline for sync requests (reads and sync writes). Defaults are, respectively, 5 seconds and 0.5 seconds. key_type: The grouping key. Can be set to pgid, tgid, uid, or gid. The current value is shown bracketed: axboe@apu:[.]s/block/hda/queue/iosched $ cat key_type [pgid] tgid uid gid Default is tgid. To set, simply echo any of the 4 words into the file. quantum: The amount of requests we select for dispatch when the driver asks for work to do and the current pending list is empty. Default is 4. queued: The minimum amount of requests a group is allowed to queue. Default is 8. show_status: Debug output showing the current state of the queues. tagged: Set this to 1 if the device is using tagged command queueing. This cannot be reliably detected by CFQ yet, since most drivers don't use the block layer (well it could, by looking at number of requests being between dispatch and completion. but not completely reliably). Default is 0. The patch is a little big, but works reliably here on my laptop. There are a number of other changes and fixes in there (like converting to hlist for hashes). The code is commented a lot better, CFQ v1 has basically no comments (reflecting that it was writting in one go, no touched or tuned much since then). This is of course only done to increase the AAF, akpm acceptance factor. Since I'm on the road, I cannot provide any really good numbers of CFQ v1 compared to v2, maybe someone will help me out there. Signed-off-by:
-
Jens Axboe authored
This patch modularizes the io schedulers completely, allowing them to be modular. Additionally it enables online switching of io schedulers. See also http://lwn.net/Articles/102593/ . There's a scheduler file in the sysfs directory for the block device queue: axboe@router:/sys/block/hda/queue> ls iosched max_sectors_kb read_ahead_kb max_hw_sectors_kb nr_requests scheduler If you list the contents of the file, it will show available schedulers and the active one: axboe@router:/sys/block/hda/queue> cat scheduler [cfq] Lets load a few more. router:/sys/block/hda/queue # modprobe deadline-iosched router:/sys/block/hda/queue # modprobe as-iosched router:/sys/block/hda/queue # cat scheduler [cfq] deadline anticipatory Changing is done with router:/sys/block/hda/queue # echo deadline > scheduler router:/sys/block/hda/queue # cat scheduler cfq [deadline] anticipatory deadline is now the new active io scheduler for hda. Signed-off-by:
-
Andrew Morton authored
davej points out that in this code local variable `ret' is already known to be positive non-zero, so this test is meaningless. Signed-off-by:
-
Andrew Morton authored
Processes can sleep in do_get_write_access(), waiting for buffers to be removed from the BJ_Shadow state. We did this by doing a wake_up_buffer() in the commit path and sleeping on the buffer in do_get_write_access(). With the filtered bit-level wakeup code this doesn't work properly any more - the wake_up_buffer() accidentally wakes up tasks which are sleeping in lock_buffer() as well. Those tasks now implicitly assume that the buffer came unlocked. Net effect: Bogus I/O errors when reading journal blocks, because the buffer isn't up to date yet. Hence the recently spate of journal_bmap() failure reports. The patch creates a new jbd-private BH flag purely for this wakeup function. So a wake_up_bit(..., BH_Unshadow) doesn't wake up someone who is waiting for a wake_up_bit(BH_Lock). JBD was the only user of wake_up_buffer(), so remove it altogether. Signed-off-by:
-
William Lee Irwin III authored
Document the requirement to use a memory barrier prior to wake_up_bit(). Signed-off-by:
-
