- 10 Sep, 2002 2 commits
-
-
Mikael Pettersson authored
In the 2.5.33->2.5.34 step someone removed "export-objs" from drivers/char/ftape/lowlevel/Makefile, which makes it impossible to build ftape as a module since is _does_ have a number of EXPORT_SYMBOL's. This reverts that change.
-
Mikael Pettersson authored
The 2.5 floppy driver has for a long time has two init/exit bugs: 1. It calls register_sys_device() on init, but fails to call unregister_sys_device() in exit. This leads to data structure corruption if floppy is a module and it gets unloaded. 2. If calls register_sys_device() early on init, but fails to call unregister_sys_device() if init fails. Again, this leads to data structure corruption. The patch below fixes both these problems.
-
- 09 Sep, 2002 37 commits
-
-
Stephen Rothwell authored
drivers/cdrom/cdrom.c is the only file (apart from include/linux/fcntl.h) that includes asm/fcntl.h. This changes that and should have no affect. I need to do this before I consolidate the asm/fcntl.h files into linux/fcntl.h (coming next - again).
-
Skip Ford authored
This is needed since 2.5.32 to successfully mount a UFS partition.
-
Rolf Fokkens authored
I've been playing with different HZ values in the 2.4 kernel for a while now, and apparantly Linus also has decided to introduce a USER_HZ constant (I used CLOCKS_PER_SEC) while raising the HZ value on x86 to 1000. On x86 timekeeping has shown to be relative fragile when raising HZ (OK, I tried HZ=2048 which is quite high) because of the way the interrupt timer is configured to fire HZ times each second. This is done by configuring a divisor in the timer chip (LATCH) which divides a certain clock (1193180) and makes the chip fire interrupts at the resulting frequency. Now comes the catch: NTP requires a clock accuracy of 500 ppm. For some HZ values the clock is not accurate enough to meet this requirement, hence NTP won't work well. An example HZ value is 1020 which exceeds the 500 ppm requirement. In this case the best approximation is 1019.8 Hz. the xtime.tv_usec value is raised with a value of 980 each tick which means that after one second the tv_usec value has increased with 999404 (should be 1000000) which is an accuracy of 596 ppm. Some more examples: HZ Accuracy (ppm) ---- -------------- 100 17 1000 151 1024 632 2000 687 2008 343 2011 18 2048 1249 What I've been doing is replace tv_usec by tv_nsec, meaning xtime is now a timespec instead of a timeval. This allows the accuracy to be improved by a factor of 1000 for any (well ... any?) HZ value. Of course all kinds of calculations had te be improved as well. The ACTHZ constantant is introduced to approximate the actual HZ value, it's used to do some approximations of other related values.
-
Linus Torvalds authored
Cset exclude: greg@kroah.com|ChangeSet|20020905153320|19047
-
http://linux-acpi.bkbits.net/linux-acpiLinus Torvalds authored
into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
-
bk://linuxusb.bkbits.net/linus-2.5Linus Torvalds authored
into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
-
bk://linuxusb.bkbits.net/pci_hp-2.5Linus Torvalds authored
into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
-
Andy Grover authored
-
Andy Grover authored
into groveronline.com:/root/bk/linux-acpi
-
Patrick Mochel authored
during the initcall sequence, after all CPUs have been brought up. mtrr_init() calls a static init_other_cpus(), which fires off a function on all other cpus to replicate the state across all of them. arch/i386/kernel/smpboot.c::smp_callin() had the following: #ifdef CONFIG_MTRR /* * Must be done before calibration delay is computed */ mtrr_init_secondary_cpu (); #endif I couldn't figure this one out. The P4 manual says nothing about this, nor find any other documentation about it. The P4 manual says only that state must be synchronized across all CPUs, which it is. And, it happens before anything else is executed on the other CPUs, and before any devices or drivers have been brought up. The cyrix mtrr code was also updated to handle this style of SMP initialization.
-
Linus Torvalds authored
into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
-
Linus Torvalds authored
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
-
Patrick Mochel authored
- The early startup code was changed so smp_prepare_cpus() is now called before do_basic_setup(). do_basic_setup() is where mtrr_init() is called, which mtrr_init_secondary_cpu() is dependent on being called. - mtrr_init_boot_cpu() was removed from the AP startup code. This was a SMP-only hack that made sure mtrr_init() happened when SMP was enabled. That's right - two different code paths to do the same thing, obscured by compile-time defines. The appended patch makes sure mtrr_init() is called before smp_prepare_cpus(). It's ugly, and I'll work on a cleaner solution, but James: could you try it and see if it fixes your performance issues?
-
Juan Quintela authored
Documentation/porting: s/are/and/ Documentation/directory-locking: s/that means// was repeated
-
Petr Vandrovec authored
When recalc_sigpending was converted from inline to real function, appropriate EXPORT_SYMBOL() was not created. Needed at least for ncpfs and lockd.
-
Chris Wright authored
Update kernel-api.tmpl to reflect mtrr changes so that the docs will build.
-
Greg Kroah-Hartman authored
The pci_bus_* functions should be used instead.
-
Greg Kroah-Hartman authored
-
Irene Zubarev authored
-
Irene Zubarev authored
-
Irene Zubarev authored
- fix polling logic - add ability to write [chassis/rxe]#slot# instead of just slot#
-
Andy Grover authored
into groveronline.com:/root/bk/linux-acpi
-
Andy Grover authored
-
Greg Kroah-Hartman authored
- removed pci_announce_device_to_drivers() prototype as the function is long gone - always call /sbin/hotplug when pci devices are added to the system if so configured (this includes during the system bring up.)
-
Jeroen Vreeken authored
-
Greg Kroah-Hartman authored
-
David Brownell authored
I added a bug in 2.5.23 when cleaning up something that was broken ... it wasn't broken in quite the way I had thought at the time! This fixes a problem some folk have reported recently with ISO-IN, by masking a common non-error outcome. Please merge to Linus' tree, on top of the one patch you already have queued. Thanks to Nemosoft for such quick turnaround on testing!
-
Frank Zago authored
This patch fixes a problem with big endian machines and scanner drivers which use the SCANNER_IOCTL_CTRLMSG ioctl. The big endian to little endian swap was done twice, resulting in a no-op.
-
Alan Stern authored
Also, have you sent in the one-line fix I found for the abort bug? Andries found that it cured his BUG_ON problem. In case you didn't save a copy of it, I've included it below.
-
James Blackwell authored
Somewhere around 2.5.31 the method for setting and clearing interrupts changed: From- To- save_flags(flags); local_irq_save(flags); cli(); restore_flags(flags); local_irq_restore(flags); Though bordering on trivial, including toshiba support with stock 2.5.34 fails to compile, which this patch seems to fix. This patch fixes this issue and has worked reliably for me under 2.5.31, though it is untested on 2.5.32 and 2.5.33 because I didn't manage to get those to work. A note to those that are a bit rough on kernel patch newbies.... submitting a kernel patch for the very first time is a rather intimidating experience so please don't chew my head off unless its absolutely necessary. See my point? I was so worried that Cristoph Hellwig is going to come to my house and eat me I forgot to include the patch itself. :)
-
Greg Kroah-Hartman authored
into kroah.com:/home/greg/linux/BK/gregkh-2.5
-
Linus Torvalds authored
-
Greg Kroah-Hartman authored
into kroah.com:/home/greg/linux/BK/gregkh-2.5
-
bk://thebsh.namesys.com/bk/reiser3-linux-2.5Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Ingo Molnar authored
This avoids a crash that can be caused by a CLONE_DETACHED thread.
-
- 08 Sep, 2002 1 commit
-
-
Alexander Viro authored
There are 4 different scenarios of late boot: 1. no initrd or ROOT_DEV is ram0. That's the simplest one - we want whatever is on ROOT_DEV as final root. 2. initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd doesn't exit. We want initrd mounted, /linuxrc launched and /linuxrc will mount whatever it wants, maybe do pivot_root and exec init itself. Task with PID 1 (parent of linuxrc) will sit there reaping zombies, never leaving the kernel mode. 3. initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd does exit and sets real-root-dev to 256 (1:0, aka. ram0). We want initrd mounted, /linuxrc launched and we expect linuxrc to mount all stuff we need, maybe do pivot root and exit. Parent of /linuxrc (PID 1) will proceed to exec init once /linuxrc is done. 4. initrd is there, ROOT_DEV is not ram0, /linuxrc on initrd might have done something or not, but when it exits real-root-dev is not ram0. We want initrd mounted, /linuxrc launched and when it exits we are going to mount final root according to real-root-dev. If there is /initrd on the final root, initrd will be moved there. Otherwise initrd will be unmounted and its memory (if possible) freed. Then we exec init from final root. Note that we want the parent of linuxrc chrooted to initrd while linuxrc runs - otherwise things like request_module() will be rather unhappy. That goes for all variants that run linuxrc. Scenarios above go in order of increasing complexity. Let's start with #4: we had loaded initrd we mount initrd on /root we open / and /old (on initrd) chdir /root mount -- move . / chroot . Now we have initrd mounted on /, we are chrooted into it but keep opened descriptors of / and /old, so we'll be able to break out of jail later. we fork a child that will be linuxrc child closes opened descriptors, opens /dev/console, dups it to stdout and stderr, does setsid and execs /linuxrc. parent sits there reaping zombies until child is finished. Note that both parent and linuxrc are chrooted into /initrd and if linuxrc calls pivot_root, the parent will also have its root/cwd switched. OK, child is finished and after checking real_root_dev we see that it's not MKDEV(1,0). Now we know that it's scenario #4. We break out of jail, doing the following: fchdir to /old on rootfs mount --move / . fchdir to / on rootfs chroot to . That will move initrd to /old and leave us with root and cwd in / of rootfs. We can close these two descriptors now - they'd done their job. We mount final root to /root We attempt to mount -- move /old /root/initrd; if we are successful - we chdir to /root, mount --move . / and chroot to . That will leave us with * final root on / * initrd on /initrd of final root * cwd and root on final root. At that point we simply exec init. Now, if mount --move had failed, we got to clean up the mess. We unmount (with MNT_DETACH) initrd from /old and do BLKFLSBUF on ram0. After that we have final root on /root, initrd maybe still alive, but not mounted anywhere and our root/cwd in / of rootfs. Again, chdir /root mount --move . / chroot to . and we have final root mounted on /, we are chrooted into it and it's time for exec init. That's it for scenario 4. The rest will be simpler - there's less work to do. #3 diverges from #4 after linuxrc had finished and we had already broken out of jail. Whatever we got from linuxrc is mounted on /old now, so we move it back to /, get chrooted there and exec init. We could've left earlier (skipping the move to /old and move back parts), but that would lead to even messier logics in prepare_namespace() ;-/ #2 means that parent of /linuxrc never gets past waiting its child to finish. End of story. #1 is the simplest variant - it mounts final root on /root and then does usual "chdir there, mount --move . /, chroot to ." and execs init. Relevant code is in prepare_namespace()/handle_initrd() and yes, it's messy. Had been even worse... ;-/
-