- 18 Jun, 2004 40 commits
-
-
Dominik Brodowski authored
The "mull" instruction in __const_udelay() cuts off the lower 32 bits -- so, it is "rounding down". This is both an issue for small ndelay()s for _all_ values for loops_per_jiffy and for certain {n,u}delay()s for many loops_per_jiffy values. Assuming LPJ = 1501115 udelay(87) results in 130597 loops to be spent. However, 1000 * 130597 / 1501115 is 86.999997 us, so we're actually _rounding down_. 1000 * 130598 / 1501115 is 87.000662841, which would be the technically correct thing to do. Of course, for the TSC case this won't matter as the maths take some time, so the actual delay is 1000 * __udelay(x) / lpj + __OVERHEAD(x) Anybody worried about both the additional overhead and the fact that the overhead takes some time to run should add a check if (unlikely(xloops < OVERHEAD)) return; xloops -= OVERHEAD; to the delay() routines in arch/i386/kernel/timers/*.c and determine what the OVERHEAD is. Signed-off-by:Dominik Brodowski <linux@brodo.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Dominik Brodowski authored
Round up in __udelay(): 2**32 / 100000 is 4294.97, so it's more intuitive to round up, and it causes more predictable results: n usec delay on a 1500000 BogoMIPS system: n before -mull after 1 1000 ticks 1499 ticks 1500 ticks 10 14000 ticks 14999 ticks 15000 ticks n usec delay on a 100000 BogoMIPS system: n before -mull after 1 0 ticks 99 ticks 100 ticks 10 0 ticks 999 ticks 1000 ticks 100 9000 ticks 9999 ticks 10000 ticks While it can be argued that some time is also spent in the delay functions, it's better to spend _at least_ the specified time sleeping, in my humble opinion. And the overhead of a specific ->delay() implementation should be substracted in the specific ->delay() implementation. Signed-off-by:
-
Dominik Brodowski authored
John Stultz mentioned on lkml ( http://lkml.org/lkml/2004/6/5/15 ) that calls to udelay() don't delay long enough, causing trouble e.g. in the USB subsystem. The following patches address this issue. Move the multiplication of (loops_per_jiffy * xloops) with HZ into the "mull" asm operation. This increases the accuracy of the delay functions largely: n usec delay on a system with loops_per_jiffy = 1500000 : n before after 1 1000 ticks 1499 ticks 10 14000 ticks 14999 ticks n usec delay on a system with loops_per_jiffy = 100000 : n before after 1 0 ticks 99 ticks 10 0 ticks 999 ticks 100 9000 ticks 9999 ticks As noted by Kurt Garloff, it's necessary to adjust for large loops_per_jiffies, as the multiplication of it with HZ fails for 4GHz or larger. So, John Stultz suggested multiplying xloops with 4 first, and multiplying with (HZ/4). Signed-off-by:
-
Neil Brown authored
The meaning of mddev->in_sync changed subtly a while ago, and raid1 wasn't changed to match. This results in raid1 read_balancing not working properly. This patch corrects the relevant test. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Alex Tomas authored
I've observed that ext3_htree_fill_tree() doesn't ignore empty records (de->inode == 0). test case is very simple: turn htree on, create several hundreds of files, remove them and look at strace ls: [root@victim tests]# ls -a /test/1 . .. [root@victim tests]# strace ls /test/1/ .... getdents64(3, /* 18 entries */, 4096) = 432 getdents64(3, /* 0 entries */, 4096) = 0 Signed-off-by:
-
William Lee Irwin III authored
* Removed period check for executables in fs/isofs/inode.c This fixes Debian BTS #162190 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162190 From: Jan Gregor <gregor_jan@seznam.cz> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: kernel-source-2.4.18: kernel ignores noexec and mode option in cdrom case Message-ID: <20020924162129.A328@pisidlo> In /etc/fstab i have following line: /dev/cdrom /cdrom iso9660 gid=100,noauto,ro,noexec,mode=0444,user 0 0 I found on one CD that some files have exec bit set. From brief view those files has no extension (filename.ext). My drive is asus-1610a (ATAPI writer) connected throught scsi-emulation. Signed-off-by:
-
William Lee Irwin III authored
* Fix slashes in broken Acorn ISO9660 images in fs/isofs/dir.c (Darren Salt) This fixes Debian BTS #141660. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=141660 From: Darren Salt <linux@youmustbejoking.demon.co.uk> Message-ID: <4B238BA09A%linux@youmustbejoking.demon.co.uk> To: submit@bugs.debian.org Subject: Handle '/' in filenames in broken ISO9660 images [Also applicable to 2.2.x] There has been for some time a problem with certain CD-ROMs whose images were generated using a particular tool on Acorn RISC OS. The problem is that in certain catalogue entries, the extension separator character '/' (RISC OS uses '.' and '/' the other way round) was not replaced with '.'; thus Linux cannot properly parse this without this patch, thinking that it is a directory separator. Signed-off-by:
-
William Lee Irwin III authored
* Fixed argument processing bug in init/main.c (Eric Delaunay) This fixes Debian BTS #58566. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=58566 From: Eric Delaunay <delaunay@lix.polytechnique.fr> Message-Id: <200002201918.UAA02327@jazz.pontchartrain.fr> Subject: pb in handling parameters on kernel command line To: submit@bugs.debian.org (debian bug tracking system) Hello, I found some bugs in kernel command line parser. AFAIK, they are not Debian nor sparc specific but I'm not subscribed to linux-kernel mailing list and since I'm involved with boot-floppies (mainly for sparc), I think I'm right to report it here. Feel free to forward it upstream (I checked the latest 2.3.46 sources and it seems these bugs are still there). These bugs are not release critical. The latter just not gives the user a chance to overwrite TERM env var at boot time. It could be just inconvenient for serial console boot, and in this case, our busybox' init is already enforcing TERM=vt102. Nevertheless if it could not be fixed before the release, I could even write a workaround in busybox' init (it's just a matter of rewriting getenv()). At last, it does not affect sysvinit package because serial console tty is controlled by a getty process which is reading terminal settings on its command line (take a look in inittab for T0 entries, if any). Ok, here is my modest contribution to kernel hacking. I don't know much about kernel internals but it seems that argument parsing is a bit broken. One trivial patch for command line like "init=/bin/sh console=prom" where console=prom is replaced by lot of spaces in previous call to setup_arch() on sparc, therefore the line parsed by parse_options() is really "init=/bin/sh " and a lot of null args are pushed into argv_init. The other patch is for command line like "TERM=vt100" where both default & user TERM entries are pushed into the env array. Taking a look into /proc/1/environ, it shows up: HOME=/ TERM=linux TERM=vt100 It appears that ash (maybe other shells too) is giving the latter entry but glibc getenv() is giving the former. It is therefore impossible to get entry from the user in a C program like busybox' init (used in Debian boot-floppies). I guess getenv() is not written to support duplicate entries, therefore the kernel should avoid such construct. Signed-off-by:
-
William Lee Irwin III authored
* Unregister driver if probing fails in sound/oss/sb_card.c This fixes Debian BTS #218845. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218845 From: Robin Gerard <robin.jag@free.fr> To: submit@bugs.debian.org Subject: no sound with kernel-image-2.6.0-test9-1-386 Message-ID: <20031103004939.GA2071@mauritius> I downlaoded the kernel-image-2.6.0-test9-1-386_2.6.0-test9-1_i386.deb and I installed it successfully. Everything works fine, except the sound. (I run also the kernel-image-2.4.20 and the sound is ok with this kernel) My sound card is a sb. First I launched modconf but no module was displayed. I did: modprobe sb and I got: sb: Init: Done sb: Init: Starting Probe... kobject_register failed for OSS SndBlstr (-17) Call Trace: [<c0191cda>] kobject_register+0x3a/0x40 [<c01d9bcc>] bus_add_driver+0x30/0x64 [<c01d9e51>] driver_register+0x2d/0x34 [<c011a24a>] preempt_schedule+0x2a/0x48 [<c01b6f84>] pnp_register_driver+0x28/0x58 [<c01b6c5e>] pnp_register_card_driver+0x5e/0x98 [<c488f063>] sb_init+0x63/0xb5 [sb] [<c0130bf4>] sys_init_module+0xe8/0x1f0 [<c010b577>] syscall_call+0x7/0xb Signed-off-by:
-
William Lee Irwin III authored
From: "Jon Thackray" <jgt@pobox.com> * Lowered priority of "too many keys" message in drivers/input/keyboard/atkbd.c This fixes Debian BTS #239036. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239036 The keyboard under 2.6.4 seems to be behaving strangely, reporting unknown key codes and too many keys pressed, even when no keys have been pressed. The keyboard is connected via an 8 way KVM switch, but was working quite acceptably under 2.4.25 with no such messages. Trying 2.6.3 is not an option as it doesn't support the hardware properly, as previously reported. Signed-off-by:
-
Randy Dunlap authored
istallion: Remove duplicate "%d" in printk(); Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
-
Egmont Koblinger authored
Using the vga console driver, if the number of the lines scrolled out is less than four, then Shift+PageUp doesn't work. The bug is closely related to the 'margin' feature of scrolling, which means that if less than four lines should remain unvisible in the direction we are scrolling to, then we scroll a little bit more just to see those few lines. Kind of two small magnets at the borders of the buffer. This bug was also reported with maybe a less clear description by Stepan Koltsov (cc'ed just for fun) back in 2001 and he got no answer. I found it at http://seclists.org/lists/linux-kernel/2001/Nov/0080.html His patch simply disables margin support and hence everythings becomes okay, but you lose a nice feature. Here's a patch that retains margin support and fixes the bug. Works for me, tested for a week. No guarantee. As I don't fully understand the code (see also my previous mail) I'm not 100% sure that I'm doing the right thing, so I'd prefer if someone would take a closer look at it. At least 2.4 and 2.6 are affected, maybe older ones too. Signed-off-by:
-
Davide Libenzi authored
The epoll allocation for the fd lookup hash used to allocate up to 1MB (depending on the "hint" size passed to epoll_create()) with __get_free_pages(0), and this might lead to a "malicious" user to do something like: for (i = 0; i < 1024; i++) epoll_create(BIG-NUM); You can replace "malicious user" with IBM-ltp test suite, and the meaning does not change. The above code might exhaust memory badly, even before the file creation limit is topped. Also, the allocation was independent from the number of fds pushed into the epoll fd hash. Using an rb-tree ther will be not pre-allocation of the hash, and the size of the memory used will be proportional to the number of fds pushed into the epoll fd. The patch also removes 100 lines of code, that is never a bad thing ;) Signed-off-by:Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
-
Robert T. Johnson authored
Judging from context, I think there's a misplaced "&" in this code that can cause stack overflows and other nasty problems. Perhaps it's left over from when msgdata was an array instead of a pointer? Signed-off-by:
-
Andrew Morton authored
Signed-off-by:
-
Petr Vandrovec authored
It decreases stack consumption in one of ncpfs's paths from 3000 to 2200 bytes (and stack portion in ncpfs ioctl code from 1336 to 452 bytes). - some code used large structure (with embeded 256 bytes for filename) while it never passed filename around. Use something smaller in ncp_conn_logged_in. Decrease 616 => 300. - gcc-3.3 is very bad when it comes to parallel blocks in ioctl. Split some branches from large switch to separate functions. ncp_ioctl now uses 152 bytes of stack (instead of 720) and biggest child 64. Signed-off-by:
Petr Vandrovec <vandrove@vc.cvut.cz> Signed-off-by:
-
Herbert Xu authored
It can be replaced by a simple memcpy. Signed-off-by:
-
Herbert Xu authored
Here's the patch that removes the memset calls from both pmdisk and swsusp. Signed-off-by:
-
Herbert Xu authored
Fix a couple of memory leaks in the pmdisk driver. Signed-off-by:
-
Pavel Machek authored
This fixes 2 memory leaks in swsusp: during relocating pagedir, eaten pages were not properly freed in error path and even regular freeing path was freeing one page too little. Signed-off-by:
-
Jens Axboe authored
The 'unplug on queued exceeding unplug threshold' logic only works for file system requests currently, since it's in __make_request(). Move it where it belongs, in elv_add_request(). This way it works for queued block sg requests as well. Signed-Off-By:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Jens Axboe authored
Mt rainier probe must be deferred to media load time, since it requires a valid media (the drive may present a different capability based on what media is loaded). This fixes that for ide-cd and sr. Signed-Off-By:
-
Mike Miller authored
This patch provides a conversion routine for 32-bit user space apps that call into a 64-bit kernel on x86_64 architectures. This is required for the HP Array Configuration utility and the HP management agents. Without this patch the apps will not function. The 2 ioctls affected are the cciss pass thru ioctls. Caveat: it spits out 2 warnings during compilation. I've tried everything I can think of to clean them up, but... If anyone has any helpful suggestions I'm all ears. Code by Stephen Cameron Tested by Stephen Cameron & Mike Miller Signed-off-by:
-
Andrea Arcangeli authored
Avoid taking down_write(mmap_sem) unless we really need it. Seems that the only reason we're taking it for writing is to protect vma->vm_flags. Signed-off-by:
-
Arun Sharma authored
Due to different structure alignment rules in the ABI between ia32 and ia64, certain members of the dirent structure are not guaranteed to be 8 byte aligned on ia64. This requires a compat wrapper around these 32 bit system calls. Other architectures may or may not have the problem, depending on the alignment rules. This was observed by running /emul/ia32-linux/bin/ls on 2.6.6 which produces kernel mode unaligned faults. Original patch by: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Gordon Jin <gordon.jin@intel.com> Signed-off-by:
Arun Sharma <arun.sharma@intel.com> Signed-off-by:
-
Thierry Vignaud authored
- "\<" and "\>" can be safely replaced with "<" and ">" - "$var =~ /^string$/" is better written "$var eq 'string'" - $i is better written without the double quotes - it's not safe to use for without "my"ing the iteration variable - "print foreach @array" is better written "print @array" - declare variables - ".*" is useless at the end of a regexp - "$a[@A] = $foo" is a rather obfuscated syntax for "push @A, $foo"... let's not opencoding language basic operators... - ignoring return value from a regexp is very bad: this can results in working on previous value of $1, $2, ... Signed-off-by:
-
Ashok Raj authored
This file provides ability for caller of register_cpu() to either create a control file, or not. This can be handy if a particular platform decides that certain CPU's are not removable. Hence would like to not create a control file. Signed-off-by:
Dave Hansen <haveblue@us.ibm.com> Signed-off-by:
Ashok Raj <ashok.raj@intel.com> Signed-off-by:
-
Yury Umanets authored
Adds memory allocation checks in cs46xx_dsp_proc_register_scb_desc() Signed-off-by:
Yury Umanets <torque@ukrpost.net> Signed-off-by:
-
Yury Umanets authored
Fixes memory allocation check in mtdblock_open() Signed-off-by:
-
Yury Umanets authored
Adds memory allocation checks in eth1394_update(). Signed-off-by:
-
Andi Kleen authored
Suggested by Manfred Spraul. __get_free_pages had a hack to do node interleaving allocation at boot time. This patch sets an interleave process policy using the NUMA API for init and the idle threads instead. Before entering the user space init the policy is reset to default again. Result is the same. Advantage is less code and removing of a check from a fast path. Removes more code than it adds. I verified that the memory distribution after boot is roughly the same. Signed-off-by:
-
William Lee Irwin III authored
While sweeping the APIC code two points were missed. The first is getting the definition of BAD_APICID available to include/asm-i386/mach-default/mach_apic.h by #including the right header, and the second is UP local APIC without UP IO-APIC linking in get_broadcast_physid(). Signed-off-by:
-
William Lee Irwin III authored
Marking invalid APIC ID's in phys_cpu_present_map was intended to generate "collisions" between APIC ID's in order to assist the ordinary bounds checking against the broadcast physical APIC ID. However, this is bounds checked everywhere it's necessary, and it's also not even possible to properly bounds-check everywhere. So this patch removes that marking of non-present physical APIC ID's. Signed-off-by:
-
William Lee Irwin III authored
The following patch repairs kicking of non-present cpus by making cpu_present_to_apicid() bounds-check its argument. It also corrects the same issue on NUMA-Q by correctly passing the generated artificial APIC ID instead of the raw value discovered in the MP table. A miscellaneous compilefix for CONFIG_ACPI_BOOT is also included for completeness. Signed-off-by:
-
William Lee Irwin III authored
The following patch appears sound according to an audit to ensure that all of the codepaths where it was introduced were called after the APIC fixmappings were set up. This patch introduces get_physical_broadcast(), which checks the version ID of the local APIC to determine whether it's a serial APIC or xAPIC, and returns the correct physical broadcast ID. It replaces all uses of APIC_BROADCAST_ID and IO_APIC_MAX_ID with this in order to ensure. It also changes the checks during MP table parsing so the APIC ID is checked in tandem with the version number. I'm holding out for some kind of testing to get an idea of whether this covers the cases or introduces regressions, or whatever. Signed-off-by:
-
Andrew Morton authored
Uninline the non-leaf bit search functions. Saves 9 kbytes from my vmlinux. And gratuitously s/__inline__/inline/ Signed-off-by:
-
William Lee Irwin III authored
arch/x86_64/mm/numa.c: In function `numa_initmem_init': arch/x86_64/mm/numa.c:185: error: incompatible types in assignment Signed-off-by:
-
Tom L. Nguyen authored
Somehow the change in TARGET_CPUS generated this error in UP environment. Patch below will fix it. Signed-off-by:
-
Kevin Corry authored
dm-raid1.c: In rh_exit(), use list_for_each_entry_safe instead of list_for_each_safe. Signed-off-by:
Kevin Corry <kevcorry@us.ibm.com> Signed-off-by:
-
Kevin Corry authored
dm-raid1.c: Make struct region::delayed_bios a bio_list instead of a bio*. This will ensure the queued bios are kept in the proper order. Signed-off-by:
-
