* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
From: Grant Grundler @ 2004-01-11 4:09 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
In-Reply-To: <20040105194839.GB9269@systemhalted>
On Mon, Jan 05, 2004 at 02:48:39PM -0500, Carlos O'Donell wrote:
> http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
I finally installed these (libc6 and libc6-dev) and live is still good.
thanks carlos!
hth,
grant
^ permalink raw reply
* Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.
From: Grant Grundler @ 2004-01-11 4:09 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux, debian-hppa
In-Reply-To: <20040105194839.GB9269@systemhalted>
On Mon, Jan 05, 2004 at 02:48:39PM -0500, Carlos O'Donell wrote:
> http://www.parisc-linux.org/~carlos/glibc-2.3.2-debs-2004-01-05/
I finally installed these (libc6 and libc6-dev) and live is still good.
thanks carlos!
hth,
grant
^ permalink raw reply
* Re: logitech cordless desktop deluxe optical keyboard issues
From: Andries.Brouwer @ 2004-01-11 4:05 UTC (permalink / raw)
To: Andries.Brouwer, sven.kissner; +Cc: linux-kernel
> Anyway, I released kbd-1.10 last week or so, and it ignores the
> kernel NR_KEYS but tries to adapt dynamically to the kernel.
> It would not come with this error message, I suppose.
the message doesn't appear anymore, but installing is giving me
the following:
<-- snip -->
Setting up kbd (1.10-1) ...
Looking for keymap to install:
de-latin1-nodeadkeys
cannot open file de-latin1-nodeadkeys
Loading /etc/console/boottime.kmap.gz
<-- snap -->
I suppose by default you would find these under
/usr/share/kbd/keymaps/i386/qwertz/de-latin1-nodeadkeys.map.gz
/usr/share/kbd/keymaps/mac/all/mac-de-latin1-nodeadkeys.map.gz
> : atkbd.c: Unknown key pressed (translated set 2, code 0x91 on
>
> This is something different, a key without associated keycode.
> That is normal. If it really has high bit set it is a bit unusual.
> (What does showkey -s show?)
showkey -s is giving me exactly the same:
<-- snip -->
atkbd.c: Unknown key pressed
<-- snap -->
That is a kernel message, not showkey output.
(BTW - which kernel precisely? The message is not the 2.6.0 one.)
Maybe showkey -s never sees them?
Andries
^ permalink raw reply
* [PATCH] udev - Makefile error
From: Kay Sievers @ 2004-01-11 4:02 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]
I get the following error on install:
pim:/home/kay/src/udev.test# make install
sed -e "s:@udevdir@:/udev:" < etc/udev/udev.conf.in > etc/udev/udev.conf
/usr/bin/install -c -d /etc/udev/
/usr/bin/install -c -d /udev
/usr/bin/install -c -d /etc/hotplug.d/default
/usr/bin/install -c -D udev /sbin/udev
/bin/sh: -c: line 2: syntax error: unexpected end of file
make: *** [install] Error 2
thanks,
Kay
[-- Attachment #2: 03-Makefile.diff --]
[-- Type: text/plain, Size: 820 bytes --]
===== Makefile 1.73 vs edited =====
--- 1.73/Makefile Sun Jan 4 20:13:39 2004
+++ edited/Makefile Sun Jan 11 04:56:59 2004
@@ -297,10 +297,10 @@
$(INSTALL) -d $(DESTDIR)$(hotplugdir)
$(INSTALL_PROGRAM) -D $(ROOT) $(DESTDIR)$(sbindir)/$(ROOT)
@if [ "x$(USE_LSB)" = "xtrue" ]; then \
- $(INSTALL_PROGRAM) -D etc/init.d/udev.init.LSB $(DESTDIR)$(initdir)/udev
- ln -s $(DESTDIR)$(initdir)/udev $(sbin_dir)/rcudev
- else
- $(INSTALL_PROGRAM) -D etc/init.d/udev $(DESTDIR)$(initdir)/udev
+ $(INSTALL_PROGRAM) -D etc/init.d/udev.init.LSB $(DESTDIR)$(initdir)/udev; \
+ ln -s $(DESTDIR)$(initdir)/udev $(sbin_dir)/rcudev; \
+ else \
+ $(INSTALL_PROGRAM) -D etc/init.d/udev $(DESTDIR)$(initdir)/udev; \
fi
$(INSTALL_DATA) -D udev.8 $(DESTDIR)$(mandir)/man8/udev.8
- rm -f $(DESTDIR)$(hotplugdir)/udev.hotplug
^ permalink raw reply
* [linux-lvm] No VFS-lock under 2.6.x ?
From: Dan Sully @ 2004-01-11 4:02 UTC (permalink / raw)
To: linux-lvm
To my surprise, when attempting to do a live snapshot of a XFS filesystem on
2.6.1, it failed miserably, and caused the machine to spin out of control,
denying access to the main filesystems.
I couldn't find a patch on the net anywhere.
What is the state of VFS locking on 2.6.x?
And in a related question, is the 2.4.xx patch ever going to be integrated
into the mainline kernel? This is getting silly now.
Thanks.
-D
--
Begin the unnecessarily slow-moving dipping mechanism!
^ permalink raw reply
* Re: What is codaauth? Why is Linux polling it?
From: Rik van Riel @ 2004-01-11 3:58 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: Linux kernel
In-Reply-To: <Pine.LNX.4.53.0401082135560.1311@chaos>
On Fri, 9 Jan 2004, Richard B. Johnson wrote:
> I have a RH System at home, no mods, right out of the box.
> It keeps sending UDP packets to 63.240.115.23.codaauth, so fast
> it's killing my PPP bandwidth.
>
> Anybody know how to shut it up? There is no coda file-system on
> that machine (that I know of).
Figure out what program is sending the packets.
Chances are your bind got rooted. Guess why newer
RH distros have some kind of a firewall up by default?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
^ permalink raw reply
* Re: SiS964 SerialATA RAID
From: Jeff Garzik @ 2004-01-11 3:51 UTC (permalink / raw)
To: DaMouse Networks; +Cc: linux-kernel
In-Reply-To: <20040110195302.28aa3408@EozVul.WORKGROUP>
DaMouse Networks wrote:
> Hey,
> I've decided I want a mirrored SATA-RAID setup for my boxen in late 2004 and I was wondering how the development for the SiS964 SATA drivers are going for 2.6.x?
I'm not aware of any development in that direction, so far...
Jeff
^ permalink raw reply
* VT locking patch #2
From: Benjamin Herrenschmidt @ 2004-01-11 3:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel list, James Simmons
Hi Andrew !
Here's a new version of the patch, against 2.6.1 bk.
I went more in depth into some of the calls in vt_ioctl and I think
fixed a few more races along with a possible false-positive. I added
the check for oops in progress too.
There are matching bits that have to go to fbdev as well, they'll be
part of the fbdev merge.
James: Do no include this patch with your big fbdev patches please,
it makes things more confusing. I'll send you separately the patches
to apply to fbdev to add locking in the right place.
Ben.
^ permalink raw reply
* [NETDEV] experimental net driver queue updated
From: Jeff Garzik @ 2004-01-11 3:40 UTC (permalink / raw)
To: Linux Kernel, Netdev; +Cc: Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
The 250+ patch queue was getting way too big to manage, so using BK I
split things up locally into a number of buckets. This allowed me to
much more easily digest Al Viro's latest patch flood, as well as get
things into much better shape for submission to upstream (as soon as the
tree re-opens)... some changes were definitely more experimental than
others, and won't go to Andrew/upstream until bugs and interface issues
are fully sorted out.
This split-up allowed me to easily create broken-out sets of patches,
which are available at the URL below.
Note the new "netdev" moniker too, that's not a typo.
Summary of new changes:
* forcedeth update
* more fixes and cleanups from Al Viro
* netpoll, atmel, dgrs updates
* other bits
Summary of patchkit:
* new e100 driver (rewritten from scratch)
* new nVidia nForce NIC driver
* new pci200syn WAN driver
* r8169 major bug fixes
* e1000 minor updates / fixes
* sk98lin vendor updates / fixes
* many bonding updates and cleanups
* misc bug fixes
* 8139too NAPI support
* tulip NAPI support
* netconsole / netdump support
* net_device allocation and reference counting work
Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2
Full changelog:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.log
Broken-out patches (broken out into "buckets" not changesets):
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/broken-out/
BK repo:
bk://gkernel.bkbits.net/netdev-2.6
or
http://gkernel.bkbits.net/netdev-2.6
Changelog delta attached.
[-- Attachment #2: changelog.txt --]
[-- Type: text/plain, Size: 3275 bytes --]
Alexander Viro:
o [wan pci200syn] eliminate embedded hdlc_device struct
o [netdrvr s390/qeth] Alloc fixes
o [netdrvr shaper] fix double-free
o [netdrvr dvb/dvb_net] fixes
o [netdrvr arch/uml] leak fix
o [netdrvr saa9730] fix double-free
o [netdrvr arm/am79c961] Fix for IO-before-request_region race
o [wan] leak fixes in hostess_sv11, lapbether
o [netdrvr s390/lcs] Leak fix
o [wireless orinoco] check alloc_etherdev for failure
o [netdrvr apne] resource leak fix
o [netdrvr 3c509] Leak fixed
o [netdrvr acenic] Race and leak fixes
o [all over] more kfree -> free_netdev
o [netdrvr isa-skeleton] cleanups and fixes
o [wan sdla] Fixed leaks and double-free
o [netdrvr fec] switched to sane allocation. It still leaks on failure exits, though
o [netdrvr s390/netiucv] partially sanitized wrt allocation
o [wireless airo] switched to sane allocation
o [netdrvr tun] Killed bogus ->init()
o [wan sealevel] Plugged a leak
o [wan sbni] sane net_device allocation; plug a bunch of leaks
o [wan hostess_sv11] sane net_device allocation
o [wan hdlc_fr] Switched allocation of net_device to alloc_netdev()
o [wan hdlc] kill embedding of struct net_device
o [wan hdlc] removal hdlc_to_dev()
o [wan dscc4] embedded struct removal
o [wan farsync] embedded struct hdlc_device removal
o [wan pc300] use alloc_hdlcdev()/free_hdlcdev(). Leak fixed
o [wan hdlc] kill embedded struct in various drivers
o [wan hdlc] new private struct pointer in hdlc_device, and helpers for it
o [wan hdlc] switch register_hdlc_device() to take net_device arg
o [wan dscc4] Uses of ->hdlc and hdlc_to_dev() encapsulated into dscc4_to_dev()
o [wan hdlc] new hdlc_stats() helper
o [wan pc300] more direct use of net_device
o [wan hdlc] switch internal ioctl dispatch to net_device
o [wan wanxl] eliminated hdlc_to_name() uses and a bunch of port->hdlc ones
o [wan hdlc_x25] eliminated hdlc_to_dev() and hdlc_to_name() uses
o [wan hdlc] hdlc_fr: eliminated ->netdev, hdlc_to_dev() and hdlc_to_name() uses
o [wan hdlc] hdlc_cisco: killed ->netdev, hdlc_to_name() and hdlc_to_dev() uses
o [wan hdlc] hdlc->proto.*() switched to net_device
o [wan farsync] Eliminated a bunch of port->hdlc and hdlc_to_dev() uses
o [wan hdlc] hdlc->attach() switched to net_device
o [wan hdlc] hdlc_set_carrier() switched to net_device
o [wan hdlc] switch sca_xxx() to use net_device
o [wan hdlc] new port_to_dev() helper
o [wan hdlc] hdlc_close() switched to net_device
o [wan hdlc] hdlc_open() switched to net_device
o [wan lapb] kill now-unused custom token container
o [wan lapb] Printks switched from %p lapb->token to %p lapb->dev
o [wan lapb] switch to use net_device instead of custom token
o [wan lapb] beginning of cleanups
Andi Kleen:
o Mark IBM TR driver as not 64 bit clean
Jeff Garzik:
o [tokenring olympic] use memset_io to fix certain platforms
Manfred Spraul:
o [netdrvr forcedeth] alloc fixes
Matt Mackall:
o netpoll carrier handling
o netconsole init return code
o netconsole init return code
o [netdrvr] add netpoll support to several 8390-based drivers
o netpoll abort for bad interface
Simon Kelley:
o [wireless atmel] various updates
Stephen Hemminger:
o bugfixes for dgrs.c
^ permalink raw reply
* experimental net driver queue updated
From: Jeff Garzik @ 2004-01-11 3:40 UTC (permalink / raw)
To: Linux Kernel, Netdev; +Cc: Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
The 250+ patch queue was getting way too big to manage, so using BK I
split things up locally into a number of buckets. This allowed me to
much more easily digest Al Viro's latest patch flood, as well as get
things into much better shape for submission to upstream (as soon as the
tree re-opens)... some changes were definitely more experimental than
others, and won't go to Andrew/upstream until bugs and interface issues
are fully sorted out.
This split-up allowed me to easily create broken-out sets of patches,
which are available at the URL below.
Note the new "netdev" moniker too, that's not a typo.
Summary of new changes:
* forcedeth update
* more fixes and cleanups from Al Viro
* netpoll, atmel, dgrs updates
* other bits
Summary of patchkit:
* new e100 driver (rewritten from scratch)
* new nVidia nForce NIC driver
* new pci200syn WAN driver
* r8169 major bug fixes
* e1000 minor updates / fixes
* sk98lin vendor updates / fixes
* many bonding updates and cleanups
* misc bug fixes
* 8139too NAPI support
* tulip NAPI support
* netconsole / netdump support
* net_device allocation and reference counting work
Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2
Full changelog:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.log
Broken-out patches (broken out into "buckets" not changesets):
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/broken-out/
BK repo:
bk://gkernel.bkbits.net/netdev-2.6
or
http://gkernel.bkbits.net/netdev-2.6
Changelog delta attached.
[-- Attachment #2: changelog.txt --]
[-- Type: text/plain, Size: 3275 bytes --]
Alexander Viro:
o [wan pci200syn] eliminate embedded hdlc_device struct
o [netdrvr s390/qeth] Alloc fixes
o [netdrvr shaper] fix double-free
o [netdrvr dvb/dvb_net] fixes
o [netdrvr arch/uml] leak fix
o [netdrvr saa9730] fix double-free
o [netdrvr arm/am79c961] Fix for IO-before-request_region race
o [wan] leak fixes in hostess_sv11, lapbether
o [netdrvr s390/lcs] Leak fix
o [wireless orinoco] check alloc_etherdev for failure
o [netdrvr apne] resource leak fix
o [netdrvr 3c509] Leak fixed
o [netdrvr acenic] Race and leak fixes
o [all over] more kfree -> free_netdev
o [netdrvr isa-skeleton] cleanups and fixes
o [wan sdla] Fixed leaks and double-free
o [netdrvr fec] switched to sane allocation. It still leaks on failure exits, though
o [netdrvr s390/netiucv] partially sanitized wrt allocation
o [wireless airo] switched to sane allocation
o [netdrvr tun] Killed bogus ->init()
o [wan sealevel] Plugged a leak
o [wan sbni] sane net_device allocation; plug a bunch of leaks
o [wan hostess_sv11] sane net_device allocation
o [wan hdlc_fr] Switched allocation of net_device to alloc_netdev()
o [wan hdlc] kill embedding of struct net_device
o [wan hdlc] removal hdlc_to_dev()
o [wan dscc4] embedded struct removal
o [wan farsync] embedded struct hdlc_device removal
o [wan pc300] use alloc_hdlcdev()/free_hdlcdev(). Leak fixed
o [wan hdlc] kill embedded struct in various drivers
o [wan hdlc] new private struct pointer in hdlc_device, and helpers for it
o [wan hdlc] switch register_hdlc_device() to take net_device arg
o [wan dscc4] Uses of ->hdlc and hdlc_to_dev() encapsulated into dscc4_to_dev()
o [wan hdlc] new hdlc_stats() helper
o [wan pc300] more direct use of net_device
o [wan hdlc] switch internal ioctl dispatch to net_device
o [wan wanxl] eliminated hdlc_to_name() uses and a bunch of port->hdlc ones
o [wan hdlc_x25] eliminated hdlc_to_dev() and hdlc_to_name() uses
o [wan hdlc] hdlc_fr: eliminated ->netdev, hdlc_to_dev() and hdlc_to_name() uses
o [wan hdlc] hdlc_cisco: killed ->netdev, hdlc_to_name() and hdlc_to_dev() uses
o [wan hdlc] hdlc->proto.*() switched to net_device
o [wan farsync] Eliminated a bunch of port->hdlc and hdlc_to_dev() uses
o [wan hdlc] hdlc->attach() switched to net_device
o [wan hdlc] hdlc_set_carrier() switched to net_device
o [wan hdlc] switch sca_xxx() to use net_device
o [wan hdlc] new port_to_dev() helper
o [wan hdlc] hdlc_close() switched to net_device
o [wan hdlc] hdlc_open() switched to net_device
o [wan lapb] kill now-unused custom token container
o [wan lapb] Printks switched from %p lapb->token to %p lapb->dev
o [wan lapb] switch to use net_device instead of custom token
o [wan lapb] beginning of cleanups
Andi Kleen:
o Mark IBM TR driver as not 64 bit clean
Jeff Garzik:
o [tokenring olympic] use memset_io to fix certain platforms
Manfred Spraul:
o [netdrvr forcedeth] alloc fixes
Matt Mackall:
o netpoll carrier handling
o netconsole init return code
o netconsole init return code
o [netdrvr] add netpoll support to several 8390-based drivers
o netpoll abort for bad interface
Simon Kelley:
o [wireless atmel] various updates
Stephen Hemminger:
o bugfixes for dgrs.c
^ permalink raw reply
* Re: 2.6.1 and irq balancing
From: Nick Piggin @ 2004-01-11 3:38 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel, Ethan Weinstein
In-Reply-To: <200401102139.09883.edt@aei.ca>
Ed Tomlinson wrote:
>Hi,
>
>What is the load on the box when this is happening? If its low think
>this is optimal (for cache reasons).
>
>
I'd rather see different interrupt sources run on different CPUs
initially, which would help fairness a little bit, and should be
more optimal with big interrupt loads.
0: xxx1 0 0 0
1: 0 xxx2 0 0
2: 0 0 xxx3 0
3: 0 0 0 xxx4
This would delay the need for interrupt balancing in the case where
2 or more interrupts are heavily used.
^ permalink raw reply
* Re: Synaptics Touchpad workaround for strange behavior after Sync loss (With Patch).
From: Dmitry Torokhov @ 2004-01-11 3:33 UTC (permalink / raw)
To: Peter Berg Larsen, Vojtech Pavlik; +Cc: Gunter Königsmann, linux-kernel
In-Reply-To: <Pine.LNX.4.40.0401110335330.588-100000@shannon.math.ku.dk>
Hi,
It is a good stuff but we probably want not only restore mux mode
but also do serio_reconnect on all ports to make sure all devices are
properly configured. But it gets way too big for interrupt handler.
I am thinking that if mux error is detected the only thing that should
be done in i8042_interrupt is disabling the controller and then use
schedule_work to schedule the rest.
Also, if we get SERIO_REMOVED condition we should just do serio_reconnect
right away and let it sort through the device state.
What do you think?
Dmitry
^ permalink raw reply
* RE: Cannot boot after new Kernel Build
From: Zhu, Yi @ 2004-01-11 3:33 UTC (permalink / raw)
To: Alex, Christian Kivalo; +Cc: linux-kernel
Make sure what's your root device with `rdev'.
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Alex
> Sent: Sunday, January 11, 2004 12:20 AM
> To: Christian Kivalo
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: Cannot boot after new Kernel Build
>
>
> Hi,
> yes I already tried /dev/hda3 but still get the same errors
> when booting.
>
> Alex
>
> Christian Kivalo wrote:
>
> >>Hi,
> >>I tried changing the fstab, removing the LABLE from the grub.conf,
> >>removing initrd from it and also tried to boot with /dev/hda3.
> >>Nothing works, still the same problem.
> >>
> >>
> >
> >hi!
> >
> >you don't have to change your fstab, there should everything ok with
> >you fstab.
> >
> >you should change the root= entry in your grub configuration to your
> >actual root partition. if you don't know what partition your root is
> >on, do a 'df' and look where '/' is mounted on.
> >
> >the second line of df output should read somewhat similar to:
> >/dev/sda2 4806936 1611232 2951516 36% /
> >
> >that's my fileserver where /dev/sda2 is mounted as '/'.
> >
> >your root= in grub config should read somewhat like this:
> >root=/dev/hda1)
> >
> >hth
> >christian
> >
> >
> >
> >>Alex
> >>
> >>
> >>
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe
> linux-kernel"
> >in the body of a message to majordomo@vger.kernel.org More majordomo
> >info at http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at http://www.tux.org/lkml/
> >
> >
> >
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the
> FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* lowlatency patch question
From: shai @ 2004-01-11 3:31 UTC (permalink / raw)
To: linux-kernel
Hi,
I think the following is a bug that can affect kernels patched with
lowlatency, such as Audio… and RedHat AS2.1.
lowlatency patch added conditional_schedule() to be called from
close_files(…) at kernel/exit.c, which seems to raise a problem if the
process had LDT entries.
If it had LDT, at the stage of close_files(…) the tsk->mm already zeroed
(__exit_mm(…), which comes before __exit_files(…) in do_exit(…)). If
conditional_schedule() at close_files(…) will succeed, switching back into
this process (that now have zeroed tsk->mm) will fail since the kernel will
not use the right LDT (since tsk->mm was zeroed, so switch_mm(…) will not be
called to load the LDT at schedule()).
Switching back to a process that had a register that used the LDT will fail
since the register probably points to non-valid LDT entry (since we are
using the wrong LDT), which will lead to a segmentation fault.
--Shai
^ permalink raw reply
* Re: Laptops & CPU frequency
From: Robert Love @ 2004-01-11 3:17 UTC (permalink / raw)
To: jlnance; +Cc: linux-kernel
In-Reply-To: <20040111025623.GA19890@ncsu.edu>
On Sat, 2004-01-10 at 21:56, jlnance@unity.ncsu.edu wrote:
> The frequency displayed in /proc/cpuinfo does not change if the AC
> adapter is toggled on or off after the machine has booted. It stays
> in the same mode as it was booted into. I am curious if this is because
> the CPU frequency really is not changing, or if it is because the
> number in /proc/cpuinfo is only calculated at boot.
The MHz value in /proc/cpuinfo should be updated as the CPU speed
changes - that is, it is not calculated just at boot, but it is updated
as the speed actually changes.
You probably have some issue in your power management scripts - Fedora
should scale the CPU speed back as soon as you remove AC power, not just
at boot if not on AC.
Robert Love
^ permalink raw reply
* Re: [PATCH] udev - advanced user query options
From: Kay Sievers @ 2004-01-11 3:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040111023300.GA4762@vrfy.org>
On Sat, Jan 10, 2004 at 09:37:49PM -0500, Robert Love wrote:
> On Sat, 2004-01-10 at 21:33, Kay Sievers wrote:
>
> > This patch improves the user options for udev.
> > It is possible now to query for the name, the symlinks or owner/group.
> > If asked for the name of the node we are able to prepend the udev_root
> > with the -r option.
>
> Dude, this is some really great work - keep it up!
>
> Stuff like this can be really useful for scripts or debugging.
Hey, thanks. I enjoy it.
Nice to see somebody finding it useful too.
Kay
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Aloha!
From: Melissa Hargrove @ 2004-01-11 3:15 UTC (permalink / raw)
To: kernel-janitors
<HTML>
<BODY>
<P><FONT SIZE=2>Sometimes people call it "Magic Lubricant".
Sometimes - "Power Bottle".</FONT>
<BR><FONT SIZE=2>Why?</FONT>
</P>
<P><FONT SIZE=2>An amazing erection WITHING SEVERAL SECONDS is guaranteed
to
you!</FONT>
<BR><FONT SIZE=2>Double-strengthed orgasm and full satisfaction... I guess
this is excatly what are waiting from sex!</FONT> </P>
<P><FONT SIZE=2>Your easy-to-use solution is here:
<A HREF="http://www.hgee1.info/vpoil/?magik">http://www.hgee1.info/vpoil/?magik</A></FONT>
</P>
<P><FONT SIZE=2>-----</FONT>
<BR><FONT SIZE=2>Link below is for that people who dislike
adv.....</FONT>
<BR><FONT SIZE=2>
<A HREF="http://www.hgee1.info/pher/o.html">http://www.hgee1.info/pher/o.html</A></FONT>
</P>
<BR>
</BODY>
</HTML>
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Kernel-janitor-discuss mailing list
Kernel-janitor-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kernel-janitor-discuss
^ permalink raw reply
* Re: [1/4] better i386 CPU selection
From: Adrian Bunk @ 2004-01-11 3:13 UTC (permalink / raw)
To: Nick Piggin, Matt Mackall, linux-kernel
In-Reply-To: <20040110110443.GA29693@wiggy.net>
On Sat, Jan 10, 2004 at 12:04:43PM +0100, Wichert Akkerman wrote:
> Previously Adrian Bunk wrote:
> > - changed the i386 CPU selection from a choice to single options for
> > every cpu
>
> There was another patch last week which added a seperate option for
> Centrino CPUs, perhaps you can fold that into this patch? The current
> situation is quite confusing since none of the CPU choices mention
> Centrine.
Thanks for this suggestion. An updated version of this patch is below.
> Wichert.
cu
Adrian
Changes:
- changed the i386 CPU selection from a choice to single options for
every cpu
- X86_GENERIC is no longer required
- renamed the M* variables to CPU_*, this is needed to ask the users
upgrading from older kernels instead of silently changing the
semantics
- added Pentium M and Pentium-4 M
- X86_GOOD_APIC -> X86_BAD_APIC
- AMD Elan is a different subarch, you can't configure a kernel that
runs on both the AMD Elan and other i386 CPUs
- added optimizing CFLAGS for the AMD Elan
- gcc 2.95 supports -march=k6 (no need for check_gcc)
- help text changes/updates
TODO:
- module versioning
diffstat output:
arch/i386/Kconfig | 273 ++++++++++++---------------
arch/i386/Makefile | 58 +++--
arch/i386/boot/setup.S | 2
arch/i386/kernel/cpu/cpufreq/Kconfig | 2
arch/i386/lib/mmx.c | 2
arch/i386/mach-voyager/voyager_smp.c | 6
arch/x86_64/Kconfig | 4
drivers/serial/8250.h | 2
include/asm-i386/apic.h | 4
include/asm-i386/bugs.h | 7
include/asm-i386/module.h | 4
include/asm-i386/processor.h | 4
include/asm-i386/timex.h | 2
include/asm-x86_64/apic.h | 2
14 files changed, 186 insertions(+), 186 deletions(-)
--- linux-2.6.0-test5-mm4/include/asm-i386/processor.h.old 2003-09-25 14:28:07.000000000 +0200
+++ linux-2.6.0-test5-mm4/include/asm-i386/processor.h 2003-09-25 14:28:16.000000000 +0200
@@ -555,7 +555,7 @@
#define K7_NOP7 ".byte 0x8D,0x04,0x05,0,0,0,0\n"
#define K7_NOP8 K7_NOP7 ASM_NOP1
-#ifdef CONFIG_MK8
+#ifdef CONFIG_CPU_ONLY_K8
#define ASM_NOP1 K8_NOP1
#define ASM_NOP2 K8_NOP2
#define ASM_NOP3 K8_NOP3
@@ -564,7 +564,7 @@
#define ASM_NOP6 K8_NOP6
#define ASM_NOP7 K8_NOP7
#define ASM_NOP8 K8_NOP8
-#elif defined(CONFIG_MK7)
+#elif defined(CONFIG_CPU_ONLY_K7)
#define ASM_NOP1 K7_NOP1
#define ASM_NOP2 K7_NOP2
#define ASM_NOP3 K7_NOP3
--- linux-2.6.0-test5-mm4/drivers/serial/8250.h.old 2003-09-25 14:28:07.000000000 +0200
+++ linux-2.6.0-test5-mm4/drivers/serial/8250.h 2003-09-25 14:28:16.000000000 +0200
@@ -44,7 +44,7 @@
#undef SERIAL_DEBUG_PCI
-#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))
+#if defined(__i386__) && (defined(CONFIG_CPU_386) || defined(CONFIG_CPU_486))
#define SERIAL_INLINE
#endif
--- linux-2.6.0-test5-mm4/arch/i386/boot/setup.S.old 2003-09-25 14:28:07.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/i386/boot/setup.S 2003-09-25 14:28:16.000000000 +0200
@@ -755,7 +755,7 @@
# AMD Elan bug fix by Robert Schwebel.
#
-#if defined(CONFIG_MELAN)
+#if defined(CONFIG_X86_ELAN)
movb $0x02, %al # alternate A20 gate
outb %al, $0x92 # this works on SC410/SC520
a20_elan_wait:
--- linux-2.6.0-test5-mm4/include/asm-i386/timex.h.old 2003-09-25 14:28:07.000000000 +0200
+++ linux-2.6.0-test5-mm4/include/asm-i386/timex.h 2003-09-25 14:28:16.000000000 +0200
@@ -12,7 +12,7 @@
#ifdef CONFIG_X86_PC9800
extern int CLOCK_TICK_RATE;
#else
-#ifdef CONFIG_MELAN
+#ifdef CONFIG_X86_ELAN
# define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
#else
# define CLOCK_TICK_RATE 1193182 /* Underlying HZ */
--- linux-2.6.0-test5-mm4/arch/i386/lib/mmx.c.old 2003-09-25 14:28:07.000000000 +0200
+++ linux-2.6.0-test5-mm4/arch/i386/lib/mmx.c 2003-09-25 14:28:16.000000000 +0200
@@ -121,7 +121,7 @@
return p;
}
-#ifdef CONFIG_MK7
+#ifdef CONFIG_CPU_ONLY_K7
/*
* The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
--- linux-2.6.0-test5-mm4/include/asm-i386/bugs.h.old 2003-09-25 14:28:07.000000000 +0200
+++ linux-2.6.0-test5-mm4/include/asm-i386/bugs.h 2003-09-25 14:28:16.000000000 +0200
@@ -165,9 +165,8 @@
* - In order to run on anything without a TSC, we need to be
* compiled for a i486.
* - In order to support the local APIC on a buggy Pentium machine,
- * we need to be compiled with CONFIG_X86_GOOD_APIC disabled,
- * which happens implicitly if compiled for a Pentium or lower
- * (unless an advanced selection of CPU features is used) as an
+ * we need to be compiled with CONFIG_X86_BAD_APIC enabled,
+ * which happens implicitly if compiled for a Pentium as an
* otherwise config implies a properly working local APIC without
* the need to do extra reads from the APIC.
*/
@@ -198,7 +197,7 @@
* integrated APIC (see 11AP erratum in "Pentium Processor
* Specification Update").
*/
-#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86_GOOD_APIC)
+#if defined(CONFIG_X86_LOCAL_APIC) && !defined(CONFIG_X86_BAD_APIC)
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
&& cpu_has_apic
&& boot_cpu_data.x86 == 5
--- linux-2.6.0-test5-mm4/include/asm-i386/apic.h.old 2003-09-25 14:28:07.000000000 +0200
+++ linux-2.6.0-test5-mm4/include/asm-i386/apic.h 2003-09-25 14:28:16.000000000 +0200
@@ -41,7 +41,7 @@
do { } while ( apic_read( APIC_ICR ) & APIC_ICR_BUSY );
}
-#ifdef CONFIG_X86_GOOD_APIC
+#ifndef CONFIG_X86_BAD_APIC
# define FORCE_READ_AROUND_WRITE 0
# define apic_read_around(x)
# define apic_write_around(x,y) apic_write((x),(y))
@@ -56,7 +56,7 @@
/*
* ack_APIC_irq() actually gets compiled as a single instruction:
* - a single rmw on Pentium/82489DX
- * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+ * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
* ... yummie.
*/
--- linux-2.6.1-rc1/arch/i386/mach-voyager/voyager_smp.c.old 2004-01-08 03:50:02.000000000 +0100
+++ linux-2.6.1-rc1/arch/i386/mach-voyager/voyager_smp.c 2004-01-08 03:51:34.000000000 +0100
@@ -553,7 +553,7 @@
/* For the 486, we can't use the 4Mb page table trick, so
* must map a region of memory */
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
int i;
unsigned long *page_table_copies = (unsigned long *)
__get_free_page(GFP_KERNEL);
@@ -612,7 +612,7 @@
/* set the original swapper_pg_dir[0] to map 0 to 4Mb transparently
* (so that the booting CPU can find start_32 */
orig_swapper_pg_dir0 = swapper_pg_dir[0];
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
if(page_table_copies == NULL)
panic("No free memory for 486 page tables\n");
for(i = 0; i < PAGE_SIZE/sizeof(unsigned long); i++)
@@ -669,7 +669,7 @@
/* reset the page table */
swapper_pg_dir[0] = orig_swapper_pg_dir0;
local_flush_tlb();
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
free_page((unsigned long)page_table_copies);
#endif
--- linux-2.6.1-rc1/arch/i386/kernel/cpu/cpufreq/Kconfig.old 2004-01-08 04:04:37.000000000 +0100
+++ linux-2.6.1-rc1/arch/i386/kernel/cpu/cpufreq/Kconfig 2004-01-08 04:05:26.000000000 +0100
@@ -54,7 +54,7 @@
config ELAN_CPUFREQ
tristate "AMD Elan"
- depends on CPU_FREQ_TABLE && MELAN
+ depends on CPU_FREQ_TABLE && X86_ELAN
---help---
This adds the CPUFreq driver for AMD Elan SC400 and SC410
processors.
--- linux-2.6.1-rc1-tiny/arch/x86_64/Kconfig.old 2004-01-08 04:25:51.000000000 +0100
+++ linux-2.6.1-rc1-tiny/arch/x86_64/Kconfig 2004-01-08 04:26:53.000000000 +0100
@@ -108,10 +108,6 @@
bool
default y
-config X86_GOOD_APIC
- bool
- default y
-
config X86_MSR
tristate "/dev/cpu/*/msr - Model-specific register support"
help
--- linux-2.6.1-rc1-tiny/include/asm-x86_64/apic.h.old 2004-01-08 04:28:36.000000000 +0100
+++ linux-2.6.1-rc1-tiny/include/asm-x86_64/apic.h 2004-01-08 04:29:17.000000000 +0100
@@ -52,7 +52,7 @@
/*
* ack_APIC_irq() actually gets compiled as a single instruction:
* - a single rmw on Pentium/82489DX
- * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+ * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
* ... yummie.
*/
--- linux-2.6.1/arch/i386/Kconfig.old 2004-01-10 15:12:39.000000000 +0100
+++ linux-2.6.1/arch/i386/Kconfig 2004-01-10 15:22:40.000000000 +0100
@@ -43,6 +43,15 @@
help
Choose this option if your computer is a standard PC or compatible.
+config X86_ELAN
+ bool "Elan"
+ help
+ Select this for an AMD Elan processor.
+
+ Do not use this option for K6/Athlon/Opteron processors!
+
+ If unsure choose "PC-compatible" instead.
+
config X86_VOYAGER
bool "Voyager (NCR)"
help
@@ -130,48 +139,19 @@
default y
depends on SMP && X86_ES7000 && MPENTIUMIII
-choice
- prompt "Processor family"
- default M686
-config M386
- bool "386"
- ---help---
- This is the processor type of your CPU. This information is used for
- optimizing purposes. In order to compile a kernel that can run on
- all x86 CPU types (albeit not optimally fast), you can specify
- "386" here.
-
- The kernel will not necessarily run on earlier architectures than
- the one you have chosen, e.g. a Pentium optimized kernel will run on
- a PPro, but not necessarily on a i486.
-
- Here are the settings recommended for greatest speed:
- - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
- 486DLC/DLC2, UMC 486SX-S and NexGen Nx586. Only "386" kernels
- will run on a 386 class machine.
- - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
- SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.
- - "586" for generic Pentium CPUs lacking the TSC
- (time stamp counter) register.
- - "Pentium-Classic" for the Intel Pentium.
- - "Pentium-MMX" for the Intel Pentium MMX.
- - "Pentium-Pro" for the Intel Pentium Pro.
- - "Pentium-II" for the Intel Pentium II or pre-Coppermine Celeron.
- - "Pentium-III" for the Intel Pentium III or Coppermine Celeron.
- - "Pentium-4" for the Intel Pentium 4 or P4-based Celeron.
- - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
- - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
- - "Crusoe" for the Transmeta Crusoe series.
- - "Winchip-C6" for original IDT Winchip.
- - "Winchip-2" for IDT Winchip 2.
- - "Winchip-2A" for IDT Winchips with 3dNow! capabilities.
- - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
- - "VIA C3-2 for VIA C3-2 "Nehemiah" (model 9 and above).
+if !X86_ELAN
+
+menu "Processor support"
- If you don't know what to do, choose "386".
+comment "Select all processors your kernel should support"
+
+config CPU_386
+ bool "386"
+ help
+ Select this for a 386 series processor.
-config M486
+config CPU_486
bool "486"
help
Select this for a 486 series processor, either Intel or one of the
@@ -179,227 +159,230 @@
DX2, and DX4 variants; also SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or
U5S.
-config M586
+config CPU_586
bool "586/K5/5x86/6x86/6x86MX"
help
- Select this for an 586 or 686 series processor such as the AMD K5,
- the Intel 5x86 or 6x86, or the Intel 6x86MX. This choice does not
- assume the RDTSC (Read Time Stamp Counter) instruction.
+ Select this for a non-Intel 586 or 686 series processor such as
+ the AMD K5 or the Cyrix 6x86MX.
+
+ Several CPUs that have their own options below (e.g. AMD K6,
+ Duron, Athlon and Opteeron, IDT Winchip, Cyrix III and
+ VIA C3) do _not_ need this option.
+
+ This choice does not assume the RDTSC (Read Time Stamp Counter)
+ instruction.
-config M586TSC
+config CPU_586TSC
bool "Pentium-Classic"
help
Select this for a Pentium Classic processor with the RDTSC (Read
- Time Stamp Counter) instruction for benchmarking.
+ Time Stamp Counter) instruction.
-config M586MMX
+config CPU_586MMX
bool "Pentium-MMX"
help
Select this for a Pentium with the MMX graphics/multimedia
extended instructions.
-config M686
+config CPU_686
bool "Pentium-Pro"
help
- Select this for Intel Pentium Pro chips. This enables the use of
- Pentium Pro extended instructions, and disables the init-time guard
- against the f00f bug found in earlier Pentiums.
+ Select this for Intel Pentium Pro chips.
-config MPENTIUMII
+config CPU_PENTIUMII
bool "Pentium-II/Celeron(pre-Coppermine)"
help
Select this for Intel chips based on the Pentium-II and
- pre-Coppermine Celeron core. This option enables an unaligned
- copy optimization, compiles the kernel with optimization flags
- tailored for the chip, and applies any applicable Pentium Pro
- optimizations.
+ pre-Coppermine Celeron core.
-config MPENTIUMIII
+config CPU_PENTIUMIII
bool "Pentium-III/Celeron(Coppermine)/Pentium-III Xeon"
help
Select this for Intel chips based on the Pentium-III and
- Celeron-Coppermine core. This option enables use of some
- extended prefetch instructions in addition to the Pentium II
- extensions.
-
-config MPENTIUM4
- bool "Pentium-4/Celeron(P4-based)/Xeon"
- help
- Select this for Intel Pentium 4 chips. This includes both
- the Pentium 4 and P4-based Celeron chips. This option
- enables compile flags optimized for the chip, uses the
- correct cache shift, and applies any applicable Pentium III
- optimizations.
+ Celeron-Coppermine core.
-config MK6
+config CPU_PENTIUMM
+ bool "Pentium M"
+ help
+ Select this for Intel Pentium M (not Pentium-4 M)
+ notebook chips.
+
+config CPU_PENTIUM4
+ bool "Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon"
+ help
+ Select this for Intel Pentium 4 chips. This includes
+ the Pentium 4, P4-based Celeron and Xeon, and
+ Pentium-4 M (not Pentium M) chips.
+
+config CPU_K6
bool "K6/K6-II/K6-III"
help
- Select this for an AMD K6-family processor. Enables use of
- some extended instructions, and passes appropriate optimization
- flags to GCC.
+ Select this for an AMD K6, K6-II or K6-III (aka K6-3D).
-config MK7
+config CPU_K7
bool "Athlon/Duron/K7"
help
- Select this for an AMD Athlon K7-family processor. Enables use of
- some extended instructions, and passes appropriate optimization
- flags to GCC.
+ Select this for an AMD Athlon K7-family processor.
-config MK8
+config CPU_K8
bool "Opteron/Athlon64/Hammer/K8"
help
- Select this for an AMD Opteron or Athlon64 Hammer-family processor. Enables
- use of some extended instructions, and passes appropriate optimization
- flags to GCC.
-
-config MELAN
- bool "Elan"
+ Select this for an AMD Opteron or Athlon64 Hammer-family processor.
-config MCRUSOE
+config CPU_CRUSOE
bool "Crusoe"
help
- Select this for a Transmeta Crusoe processor. Treats the processor
- like a 586 with TSC, and sets some GCC optimization flags (like a
- Pentium Pro with no alignment requirements).
+ Select this for a Transmeta Crusoe processor.
-config MWINCHIPC6
+config CPU_WINCHIPC6
bool "Winchip-C6"
help
- Select this for an IDT Winchip C6 chip. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment requirements.
+ Select this for an IDT Winchip C6 chip.
-config MWINCHIP2
+config CPU_WINCHIP2
bool "Winchip-2"
help
- Select this for an IDT Winchip-2. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment requirements.
+ Select this for an IDT Winchip-2.
-config MWINCHIP3D
+config CPU_WINCHIP3D
bool "Winchip-2A/Winchip-3"
help
- Select this for an IDT Winchip-2A or 3. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment reqirements. Also enable out of order memory
- stores for this CPU, which can increase performance of some
- operations.
-
-config MCYRIXIII
- bool "CyrixIII/VIA-C3"
- help
- Select this for a Cyrix III or C3 chip. Presently Linux and GCC
- treat this chip as a generic 586. Whilst the CPU is 686 class,
- it lacks the cmov extension which gcc assumes is present when
- generating 686 code.
- Note that Nehemiah (Model 9) and above will not boot with this
- kernel due to them lacking the 3DNow! instructions used in earlier
- incarnations of the CPU.
+ Select this for an IDT Winchip-2A or 3 with 3dNow!
+ capabilities.
+
+config CPU_CYRIXIII
+ bool "Cyrix III/VIA C3"
+ help
+ Select this for a Cyrix III or VIA C3 chip.
-config MVIAC3_2
+ Note that Nehemiah (Model 9) and above need the next
+ option instead.
+
+config CPU_VIAC3_2
bool "VIA C3-2 (Nehemiah)"
help
- Select this for a VIA C3 "Nehemiah". Selecting this enables usage
- of SSE and tells gcc to treat the CPU as a 686.
- Note, this kernel will not boot on older (pre model 9) C3s.
+ Select this for a VIA C3 "Nehemiah" (model 9 and above).
-endchoice
+endmenu
-config X86_GENERIC
- bool "Generic x86 support"
- help
- Including some tuning for non selected x86 CPUs too.
- when it has moderate overhead. This is intended for generic
- distributions kernels.
+endif
+
+#
+# helper options
+#
+config CPU_INTEL
+ bool
+ depends on CPU_386 || CPU_486 || CPU_586TSC || CPU_686 || CPU_PENTIUMII || CPU_PENTIUMIII || CPU_PENTIUMM || CPU_PENTIUM4
+ default y
+
+config CPU_WINCHIP
+ bool
+ depends on CPU_WINCHIPC6 || CPU_WINCHIP2 || CPU_WINCHIP3D
+ default y
+
+config CPU_ONLY_K7
+ bool
+ depends on CPU_K7 && !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+ default y
+
+config CPU_ONLY_K8
+ bool
+ depends on CPU_K8 && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+ default y
+
+config CPU_ONLY_WINCHIP
+ bool
+ depends on CPU_WINCHIP && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
+ default y
#
# Define implied options from the CPU selection here
#
config X86_CMPXCHG
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_XADD
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_L1_CACHE_SHIFT
int
- default "7" if MPENTIUM4 || X86_GENERIC
- default "4" if MELAN || M486 || M386
- default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2
- default "6" if MK7 || MK8
+ default "7" if CPU_PENTIUM4
+ default "6" if CPU_K7 || CPU_K8 || CPU_PENTIUMM
+ default "5" if CPU_WINCHIP || CPU_CRUSOE || CPU_CYRIXIII || CPU_K6 || CPU_PENTIUMIII || CPU_PENTIUMII || CPU_686 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_VIAC3_2
+ default "4" if X86_ELAN || CPU_486 || CPU_386
config RWSEM_GENERIC_SPINLOCK
bool
- depends on M386
+ depends on CPU_386
default y
config RWSEM_XCHGADD_ALGORITHM
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_PPRO_FENCE
bool
- depends on M686 || M586MMX || M586TSC || M586 || M486 || M386
+ depends on CPU_686
default y
config X86_F00F_BUG
bool
- depends on M586MMX || M586TSC || M586 || M486 || M386
+ depends on CPU_586MMX || CPU_586TSC
default y
config X86_WP_WORKS_OK
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_INVLPG
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_BSWAP
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_POPAD_OK
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_ALIGNMENT_16
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
+ depends on CPU_WINCHIP || CPU_CYRIXIII || X86_ELAN || CPU_K6 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_486 || CPU_VIAC3_2
default y
-config X86_GOOD_APIC
+config X86_BAD_APIC
bool
- depends on MK7 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8
+ depends on CPU_586TSC
default y
config X86_INTEL_USERCOPY
bool
- depends on MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7
+ depends on CPU_K7 || CPU_K8 || CPU_PENTIUMII || CPU_PENTIUMIII || CPU_PENTIUMM || CPU_PENTIUM4
default y
config X86_USE_PPRO_CHECKSUM
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2
+ depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !X86_ELAN && !CPU_CRUSOE
default y
config X86_USE_3DNOW
bool
- depends on MCYRIXIII || MK7
+ depends on !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_VIAC3_2
default y
config X86_OOSTORE
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6
+ depends on CPU_ONLY_WINCHIP
default y
config HPET_TIMER
@@ -512,7 +495,7 @@
config X86_TSC
bool
- depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ
+ depends on !X86_NUMAQ && !CPU_386 && !CPU_486 && !CPU_586 && !X86_ELAN && !CPU_WINCHIPC6
default y
config X86_MCE
--- linux-2.6.1/arch/i386/Makefile.old 2004-01-10 15:12:39.000000000 +0100
+++ linux-2.6.1/arch/i386/Makefile 2004-01-10 15:25:53.000000000 +0100
@@ -26,28 +26,48 @@
align := $(subst -functions=0,,$(call check_gcc,-falign-functions=0,-malign-functions=0))
-cflags-$(CONFIG_M386) += -march=i386
-cflags-$(CONFIG_M486) += -march=i486
-cflags-$(CONFIG_M586) += -march=i586
-cflags-$(CONFIG_M586TSC) += -march=i586
-cflags-$(CONFIG_M586MMX) += $(call check_gcc,-march=pentium-mmx,-march=i586)
-cflags-$(CONFIG_M686) += -march=i686
-cflags-$(CONFIG_MPENTIUMII) += $(call check_gcc,-march=pentium2,-march=i686)
-cflags-$(CONFIG_MPENTIUMIII) += $(call check_gcc,-march=pentium3,-march=i686)
-cflags-$(CONFIG_MPENTIUM4) += $(call check_gcc,-march=pentium4,-march=i686)
-cflags-$(CONFIG_MK6) += $(call check_gcc,-march=k6,-march=i586)
+cpuflags-$(CONFIG_CPU_PENTIUM4) := $(call check_gcc,-march=pentium4,-march=i686)
+
+ifdef CONFIG_CPU_PENTIUM4
+ cpuflags-$(CONFIG_CPU_K8) := $(call check_gcc,-march=pentium3,-march=i686)
+else
+ cpuflags-$(CONFIG_CPU_K8) := $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
+endif
+
# Please note, that patches that add -march=athlon-xp and friends are pointless.
# They make zero difference whatsosever to performance at this time.
-cflags-$(CONFIG_MK7) += $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
-cflags-$(CONFIG_MK8) += $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
-cflags-$(CONFIG_MCRUSOE) += -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MWINCHIPC6) += $(call check_gcc,-march=winchip-c6,-march=i586)
-cflags-$(CONFIG_MWINCHIP2) += $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MWINCHIP3D) += $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MCYRIXIII) += $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MVIAC3_2) += $(call check_gcc,-march=c3-2,-march=i686)
+ifdef CONFIG_CPU_PENTIUM4
+ cpuflags-$(CONFIG_CPU_K7) := $(call check_gcc,-march=pentium3,-march=i686)
+else
+ cpuflags-$(CONFIG_CPU_K7) := $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
+endif
+
+cpuflags-$(CONFIG_CPU_PENTIUMM) := $(call check_gcc,-march=pentium3,-march=i686)
+cpuflags-$(CONFIG_CPU_PENTIUMIII) := $(call check_gcc,-march=pentium3,-march=i686)
+cpuflags-$(CONFIG_CPU_PENTIUMII) := $(call check_gcc,-march=pentium2,-march=i686)
+cpuflags-$(CONFIG_CPU_VIAC3_2) := $(call check_gcc,-march=c3-2,-march=i686)
+cpuflags-$(CONFIG_CPU_CRUSOE) := -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+cpuflags-$(CONFIG_CPU_686) := -march=i686
+
+# supports i686 without cmov
+cpuflags-$(CONFIG_CPU_CYRIXIII) := $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+
+cpuflags-$(CONFIG_CPU_K6) := -march=k6
+cpuflags-$(CONFIG_CPU_586MMX) := $(call check_gcc,-march=pentium-mmx,-march=i586)
+
+# Winchip supports i586
+cpuflags-$(CONFIG_CPU_WINCHIPC6) := $(call check_gcc,-march=winchip-c6,-march=i486)
+cpuflags-$(CONFIG_CPU_WINCHIP2) := $(call check_gcc,-march=winchip2,-march=i486)
+cpuflags-$(CONFIG_CPU_WINCHIP3D) := $(call check_gcc,-march=winchip2,-march=i486)
+
+cpuflags-$(CONFIG_CPU_586TSC) := -march=i586
+cpuflags-$(CONFIG_CPU_586) := -march=i586
+cpuflags-$(CONFIG_X86_ELAN) := -march=i486
+cpuflags-$(CONFIG_CPU_486) := -march=i486
+cpuflags-$(CONFIG_CPU_386) := -march=i386
+
-CFLAGS += $(cflags-y)
+CFLAGS += $(cpuflags-y)
# Default subarch .c files
mcore-y := mach-default
--- linux-2.6.1/include/asm-i386/module.h.old 2004-01-10 15:12:39.000000000 +0100
+++ linux-2.6.1/include/asm-i386/module.h 2004-01-10 15:24:14.000000000 +0100
@@ -26,6 +26,8 @@
#define MODULE_PROC_FAMILY "PENTIUMII "
#elif defined CONFIG_MPENTIUMIII
#define MODULE_PROC_FAMILY "PENTIUMIII "
+#elif defined CONFIG_MPENTIUMM
+#define MODULE_PROC_FAMILY "PENTIUMM "
#elif defined CONFIG_MPENTIUM4
#define MODULE_PROC_FAMILY "PENTIUM4 "
#elif defined CONFIG_MK6
@@ -49,7 +51,7 @@
#elif CONFIG_MVIAC3_2
#define MODULE_PROC_FAMILY "VIAC3-2 "
#else
-#error unknown processor family
+#define MODULE_PROC_FAMILY "this needs to be fixed"
#endif
#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY
^ permalink raw reply
* Re: tulip driver: errors instead TX packets?
From: Adam Kropelin @ 2004-01-11 3:20 UTC (permalink / raw)
To: Piotr Kaczuba; +Cc: Jeff Garzik, linux-kernel
In-Reply-To: <4000607D.1020102@attika.ath.cx>
On Sat, Jan 10, 2004 at 09:28:45PM +0100, Piotr Kaczuba wrote:
> Jeff Garzik wrote:
> > Piotr Kaczuba wrote:
> >
> >> I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip
> >> driver on 2.6.1. I wonder if anyone has noticed that ifconfig shows
> >> the packets sent in the errors field instead of the TX packets field.
> >> At least, this is what I assume because it shows 0 TX packets and
> >> 11756 errors.
> >
> > This is an old error, but since packets show up, nobody bothers with the
> > incorrect statistics...
>
> It seems that the error lies in the following piece of code from
> drivers/net/tulip/interrupt.c, function tulip_interrupt. I've inserted
> an additional printk after the "if (status & 0x8000)" and it looks like
> normal operation of the nic is considered as an major error by the
> driver because my printk appeared in dmesg output right after bringing
> the interface up. I assume that the else branch is never executed
> although I didn't test what happens if an transmit error really happens.
> I wonder if a fix for this problem consists of just changing the value
> of the AND mask but I have no idea what the right value would be.
>
>
> if (status & 0x8000) {
According to my PNIC docs (don't have true Tulip docs handy), this bit
is the logical OR of all the Tx error bits, so it appears a true tx
error has ocurred.
> /* There was an major error, log it. */
> #ifndef final_version
> if (tulip_debug > 1)
> printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",
> dev->name, status);
> #endif
Enabling this printk and setting tulip_debug appropriately would tell us
what tx error you're experiencing.
> tp->stats.tx_errors++;
> if (status & 0x4104) tp->stats.tx_aborted_errors++;
> if (status & 0x0C00) tp->stats.tx_carrier_errors++;
> if (status & 0x0200) tp->stats.tx_window_errors++;
> if (status & 0x0002) tp->stats.tx_fifo_errors++;
> if ((status & 0x0080) && tp->full_duplex == 0)
> tp->stats.tx_heartbeat_errors++;
And this code bumps error counters based on the specific error that
ocurred. It all seems perfectly sane to me. The actual problem lies
elsewhere, I think.
--Adam
^ permalink raw reply
* nfs failover
From: Eric Ford @ 2004-01-11 3:02 UTC (permalink / raw)
To: nfs
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]
Hello, everybody
I installed nfs on my cluster system, two head nodes(one is primary and another is backup) with two clients. They use NFS to store and transfer data between server and clients. But whenever failover happens, the client can't connect to backup server although
backup server has the same IP and hostname and same configuration at that time.
"NFS server is not responding, still trying"
I use this command: #service nfs restart on backup server, it is not useful.
What should I do on backup server so that client can get connection with it? By the way I use Pfilter (iptables) on both servers.
Thank you
Eric
---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
[-- Attachment #2: Type: text/html, Size: 1036 bytes --]
^ permalink raw reply
* Laptops & CPU frequency
From: jlnance @ 2004-01-11 2:56 UTC (permalink / raw)
To: linux-kernel
Hello All,
I am running the 2.4 kernel (latest from Fedora) on a Thinkpad 600E
laptop. If I start the laptop with the AC adapter turned on, the CPU
frequency in /proc/cpuinfo is approximatly 400 MHz. However, if I start
the laptop on battery power, /proc/cpuinfo indicates a processor frequency
of approximatly 100 MHz.
The frequency displayed in /proc/cpuinfo does not change if the AC
adapter is toggled on or off after the machine has booted. It stays
in the same mode as it was booted into. I am curious if this is because
the CPU frequency really is not changing, or if it is because the
number in /proc/cpuinfo is only calculated at boot.
Thanks,
Jim
^ permalink raw reply
* 2.4.23 SMP: kernel BUG at mmap.c
From: Chris Stromsoe @ 2004-01-11 2:56 UTC (permalink / raw)
To: linux-kernel
Yesterday I had a kernel oops twice within half an hour. Both are decoded
below. The system is an SMP P3 with 4Gb of RAM.
-Chris
ver_linux:
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux iris 2.4.23 #1 SMP Sun Nov 30 06:32:09 PST 2003 i686 unknown
Gnu C 2.95.4
Gnu make 3.79.1
util-linux 2.11n
mount 2.11n
modutils 2.4.15
e2fsprogs 1.27
jfsutils 1.1.4
Linux C Library 2.2.5
Dynamic linker (ldd) 2.2.5
Procps 2.0.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 2.0.11
Modules Loaded eepro100 mii
ksymoops 2.4.5 on i686 2.4.23. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.23/ (default)
-m /boot/System.map-2.4.23 (specified)
Jan 9 19:35:11 iris kernel: kernel BUG at mmap.c:1166!
Jan 9 19:35:11 iris kernel: invalid operand: 0000
Jan 9 19:35:11 iris kernel: CPU: 0
Jan 9 19:35:11 iris kernel: EIP: 0010:[exit_mmap+249/288] Not tainted
Jan 9 19:35:11 iris kernel: EFLAGS: 00010286
Jan 9 19:35:11 iris kernel: eax: 00000060 ebx: 00000000 ecx: c281ece4 edx: 00000060
Jan 9 19:35:11 iris kernel: esi: d86b4f20 edi: bfffb000 ebp: d3e9ff88 esp: d3e9ff74
Jan 9 19:35:11 iris kernel: ds: 0018 es: 0018 ss: 0018
Jan 9 19:35:11 iris kernel: Process gather (pid: 4348, stackpage=d3e9f000)
Jan 9 19:35:11 iris kernel: Stack: d86b4f20 40153344 d3e9e000 00005000 00000000 d3e9ff98 c0115a6a d86b4f20
Jan 9 19:35:11 iris kernel: d86b4f20 d3e9ffb0 c011a6b6 d86b4f20 d3e9e000 40153344 00000000 d3e9ffbc
Jan 9 19:35:11 iris kernel: c011a904 00000000 bffffdec c0106fa3 00000000 080480f4 40154e48 40153344
Jan 9 19:35:11 iris kernel: Call Trace: [mmput+94/124] [do_exit+190/740] [sys_wait4+0/952] [system_call+51/56]
Jan 9 19:35:11 iris kernel: Code: 0f 0b 8e 04 21 14 28 c0 68 00 03 00 00 6a 00 56 e8 a6 d1 ff
Using defaults from ksymoops -t elf32-i386 -a i386
>>ecx; c281ece4 <_end+24875f0/388f590c>
>>esi; d86b4f20 <_end+1831d82c/388f590c>
>>edi; bfffb000 Before first symbol
>>ebp; d3e9ff88 <_end+13b08894/388f590c>
>>esp; d3e9ff74 <_end+13b08880/388f590c>
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 0f 0b ud2a
Code; 00000002 Before first symbol
2: 8e 04 21 movl (%ecx,1),%es
Code; 00000005 Before first symbol
5: 14 28 adc $0x28,%al
Code; 00000007 Before first symbol
7: c0 68 00 03 shrb $0x3,0x0(%eax)
Code; 0000000b Before first symbol
b: 00 00 add %al,(%eax)
Code; 0000000d Before first symbol
d: 6a 00 push $0x0
Code; 0000000f Before first symbol
f: 56 push %esi
Code; 00000010 Before first symbol
10: e8 a6 d1 ff 00 call ffd1bb <_EIP+0xffd1bb> 00ffd1bb Before first symbol
ksymoops 2.4.5 on i686 2.4.23. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.23/ (default)
-m /boot/System.map-2.4.23 (specified)
Jan 9 19:56:32 iris kernel: kernel BUG at mmap.c:1166!
Jan 9 19:56:32 iris kernel: invalid operand: 0000
Jan 9 19:56:32 iris kernel: CPU: 0
Jan 9 19:56:32 iris kernel: EIP: 0010:[exit_mmap+249/288] Not tainted
Jan 9 19:56:32 iris kernel: EFLAGS: 00010286
Jan 9 19:56:32 iris kernel: eax: 000000b2 ebx: 00000000 ecx: c281ece4 edx: 000000b2
Jan 9 19:56:32 iris kernel: esi: d86b4e80 edi: bfffb000 ebp: c55f3f88 esp: c55f3f74
Jan 9 19:56:32 iris kernel: ds: 0018 es: 0018 ss: 0018
Jan 9 19:56:32 iris kernel: Process gather (pid: 32212, stackpage=c55f3000)
Jan 9 19:56:32 iris kernel: Stack: d86b4e80 40153344 c55f2000 00005000 00000000 c55f3f98 c0115a6a d86b4e80
Jan 9 19:56:32 iris kernel: d86b4e80 c55f3fb0 c011a6b6 d86b4e80 c55f2000 40153344 00000000 c55f3fbc
Jan 9 19:56:32 iris kernel: c011a904 00000000 bffffdec c0106fa3 00000000 080480f4 40154e48 40153344
Jan 9 19:56:32 iris kernel: Call Trace: [mmput+94/124] [do_exit+190/740] [sys_wait4+0/952] [system_call+51/56]
Jan 9 19:56:32 iris kernel: Code: 0f 0b 8e 04 21 14 28 c0 68 00 03 00 00 6a 00 56 e8 a6 d1 ff
Using defaults from ksymoops -t elf32-i386 -a i386
>>ecx; c281ece4 <_end+24875f0/388f590c>
>>esi; d86b4e80 <_end+1831d78c/388f590c>
>>edi; bfffb000 Before first symbol
>>ebp; c55f3f88 <_end+525c894/388f590c>
>>esp; c55f3f74 <_end+525c880/388f590c>
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 0f 0b ud2a
Code; 00000002 Before first symbol
2: 8e 04 21 movl (%ecx,1),%es
Code; 00000005 Before first symbol
5: 14 28 adc $0x28,%al
Code; 00000007 Before first symbol
7: c0 68 00 03 shrb $0x3,0x0(%eax)
Code; 0000000b Before first symbol
b: 00 00 add %al,(%eax)
Code; 0000000d Before first symbol
d: 6a 00 push $0x0
Code; 0000000f Before first symbol
f: 56 push %esi
Code; 00000010 Before first symbol
10: e8 a6 d1 ff 00 call ffd1bb <_EIP+0xffd1bb> 00ffd1bb Before first symbol
^ permalink raw reply
* Re: Questions about install SELinux in Fedora Core
From: Park Lee @ 2004-01-11 2:47 UTC (permalink / raw)
To: russell; +Cc: selinux
In-Reply-To: <200401111018.56582.russell@coker.com.au>
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
Dear Russell Coker
You say that:
>Better to get 2.6.1.
But there is only the 2.6.0-test11 kernel with SELinux patch applied could be down from www.nsa.gov/selinux.
>quota-tools doesn't matter unless you are using quotas, are >you using quotas?
>For xfsprogs, last I heard XFS support for SE Linux wasn't >quite ready. So
>unless something has changed you have to use Ext3, and >therefore the version
>of xfsprogs does not matter.
>Red Hat uses a different procps to everyone else. Don't worry >about it.
Then do you mean that I can ignore the above problems and install the 2.6 kernel with SELinux patch applied in the Fedora Core(2.4.22-1.2115.nptl ) successfully.
And if I download the newest version of xfsprogs,quota-tools and procps. Could I install them in the Fedora Core(2.4.22-1.2115.nptl ) and do not cause other problems.
Thank you very much!
Park Lee
2004-01-11
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[-- Attachment #2: Type: text/html, Size: 2089 bytes --]
^ permalink raw reply
* Re: 2.6.1 and irq balancing
From: Ed Tomlinson @ 2004-01-11 2:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Ethan Weinstein
In-Reply-To: <40008745.4070109@stinkfoot.org>
Hi,
What is the load on the box when this is happening? If its low think
this is optimal (for cache reasons).
Ed Tomlinson
On January 10, 2004 06:14 pm, Ethan Weinstein wrote:
> Greetings all,
>
> I upgraded my server to 2.6.1, and I'm finding I'm saddled with only
> interrupting on CPU0 again. 2.6.0 does this as well. This is the
> Supermicro X5DPL-iGM-O (E7501 chipset), 2 Xeons@2.4ghz HT enabled.
> /proc/cpuinfo is normal as per HT, displaying 4 cpus.
> 2.4.2(3|4) exhibited this behaviour as well, until I applied patches
> from here:
> http://www.hardrock.org/kernel/2.4.23/irqbalance-2.4.23-jb.patch, et al.
>
>
> CPU0 CPU1 CPU2 CPU3
> 0: 1572323 0 0 0 IO-APIC-edge timer
> 2: 0 0 0 0 XT-PIC cascade
> 3: 23520 0 0 0 IO-APIC-edge serial
> 8: 2 0 0 0 IO-APIC-edge rtc
> 9: 0 0 0 0 IO-APIC-level acpi
> 14: 10 0 0 0 IO-APIC-edge ide0
> 16: 30 0 0 0 IO-APIC-level
> sym53c8xx\r 22: 4162 0 0 0 IO-APIC-level
> eth0 48: 7798 0 0 0 IO-APIC-level
> aic79xx 49: 3385 0 0 0 IO-APIC-level
> aic79xx 54: 17062 0 0 0 IO-APIC-level
> eth1 NMI: 0 0 0 0
> LOC: 1572002 1572251 1572250 1572243
> ERR: 0
> MIS: 0
>
>
> THey keyboard isn't working either, but we see the i8042..
>
> serio: i8042 KBD port at 0x60,0x64 irq 1
>
>
> -Ethan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: Synaptics Touchpad workaround for strange behavior after Sync loss (With Patch).
From: Peter Berg Larsen @ 2004-01-11 2:39 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Gunter Königsmann, linux-kernel
In-Reply-To: <Pine.LNX.4.40.0401102336450.588-100000@shannon.math.ku.dk>
On Sat, 10 Jan 2004, Peter Berg Larsen wrote:
> I dont have a machine with active multiplexing so the the patch is
> untested. It warns when the mouse is removed, and tries to recover
> if multiplexing is disabled.
A lot a have changed since 2.6.0 so here is the patch against 2.6.1:
diff -rup a/include/linux/serio.h b/include/linux/serio.h
--- a/include/linux/serio.h Sun Oct 20 04:57:23 2002
+++ b/include/linux/serio.h Sun Oct 20 04:58:32 2002
@@ -99,6 +99,7 @@
#define SERIO_TIMEOUT 1
#define SERIO_PARITY 2
#define SERIO_FRAME 4
+#define SERIO_REMOVED 8
#define SERIO_TYPE 0xff000000UL
#define SERIO_XT 0x00000000UL
diff -rup a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c 2004-01-11 03:52:53.000000000 +0100
+++ b/drivers/input/serio/i8042.c 2004-01-11 04:02:34.000000000 +0100
@@ -78,6 +78,7 @@ struct timer_list i8042_timer;
#define i8042_request_irq_cookie (&i8042_timer)
static irqreturn_t i8042_interrupt(int irq, void *dev_id, struct pt_regs *regs);
+static int i8042_enable_mux_mode(struct i8042_values *values, unsigned char *mux_version);
/*
* The i8042_wait_read() and i8042_wait_write functions wait for the i8042 to
@@ -375,7 +376,7 @@ static irqreturn_t i8042_interrupt(int i
int data;
int str;
} buffer[I8042_BUFFER_SIZE];
- int i, j = 0;
+ int i, j = 0, mux_failed = 0;
spin_lock_irqsave(&i8042_lock, flags);
@@ -397,15 +398,17 @@ static irqreturn_t i8042_interrupt(int i
if (str & I8042_STR_MUXERR) {
switch (data) {
- case 0xfd:
+ case 0xfd: dfl = SERIO_REMOVED; break;
case 0xfe: dfl = SERIO_TIMEOUT; break;
case 0xff: dfl = SERIO_PARITY; break;
+ default: mux_failed = 1;
}
data = 0xfe;
} else dfl = 0;
- dbg("%02x <- i8042 (interrupt, aux%d, %d%s%s)",
+ dbg("%02x <- i8042 (interrupt, aux%d, %d%s%s%s)",
data, (str >> 6), irq,
+ dfl & SERIO_REMOVED ? ", removed" : "",
dfl & SERIO_PARITY ? ", bad parity" : "",
dfl & SERIO_TIMEOUT ? ", timeout" : "");
@@ -429,6 +432,12 @@ static irqreturn_t i8042_interrupt(int i
serio_interrupt(&i8042_kbd_port, data, dfl, regs);
}
+ if (mux_failed) {
+ printk(KERN_ERR "i8042.c: Reverted to lagacy aux mode.\n");
+ if (i8042_enable_mux_mode(NULL,NULL))
+ printk(KERN_ERR "i8042.c: Failed to activate mux again.\n");
+ }
+
return IRQ_RETVAL(j);
}
Peter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.