* Re: [PATCH] 2.4.20-rmap15b
From: Rik van Riel @ 2002-12-17 21:50 UTC (permalink / raw)
To: Georg Nikodym; +Cc: linux-mm, linux-kernel
In-Reply-To: <200212161610.gBGGAuB7028719@localhost.localdomain>
On Mon, 16 Dec 2002, Georg Nikodym wrote:
> Incidentally, a colleague claimed to have seem this behaviour on a
> non-rmap 2.4.20.
> 1. Known behaviour?
> 2. Is there any data that I should be collecting that people are
> interested in?
> 3. Or should I just go back to 2.4.19-rmap14b (which did not trouble me
> in this way)?
The suspect is the disk elevator, which isn't scheduling requests
in a way to cause lower read latency, but is optimised more for
throughput. This results in some pauses.
I'll need to look into it.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: 2.5.52 compile error
From: James Simmons @ 2002-12-17 22:49 UTC (permalink / raw)
To: Richard B. Tilley (Brad); +Cc: Steven Cole, Bob Miller, Linux Kernel
In-Reply-To: <1040160873.17544.24.camel@oubop4.bursar.vt.edu>
> All of these options are modules in my config file, *must* they be built
> into the kernel in order to compile?
Yes!!! I have a patch for fixing this issue.
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===================================================================
ChangeSet@1.868, 2002-12-10 12:07:45-08:00, jsimmons@kozmo.(none)
The VT tty layer depends on the input api now. Fixed this dependency.
Kconfig | 1 +
1 files changed, 1 insertion(+)
diff -Nru a/drivers/char/Kconfig b/drivers/char/Kconfig
--- a/drivers/char/Kconfig Tue Dec 10 12:16:48 2002
+++ b/drivers/char/Kconfig Tue Dec 10 12:16:48 2002
@@ -6,6 +6,7 @@
config VT
bool "Virtual terminal"
+ depends on INPUT=y
---help---
If you say Y here, you will get support for terminal devices with
display and keyboard devices. These are called "virtual" because you
===================================================================
This BitKeeper patch contains the following changesets:
+
## Wrapped with gzip_uu ##
begin 664 bkpatch6044
M'XL(`+!+]CT``]54VVH;,1!]MKYB("\MQ;NZ[,T+6]RFEX24UKA.7TH?A';L
MW=@KF97L9,-^?&6[N1!,H*5]J"X(9H;#F3D'G<"EQ38?7-FZ:8RVY`3.C'7Y
M8&EN&Q.\T$;C2Q^<&N.#X<:VH6U5N*KUYF98Z_7&$9^=2*<JV&)K\P$+Q'W$
M=6O,!]/W'R\_O9D24A1P6DF]P*_HH"B(,^U6KDH[EJY:&1VX5FK;H).!,DU_
M7]IS2KG?,4L%C9.>)31*>\5*QF3$L*0\RI*(W+4P?DS]"0KCC+)1%,6C7B24
M"?(.6)`E&5`>,G\H,)[3-(_B(<UR2N$H*+QB,*3D+?S=!DZ)@EF%\&T&SG6P
MDAVV4.(:=6G!:'`^MQ\YR'4-VEP'\*&^P=(G:ONK$+7J`B`7(.(TC<CD8>!D
M^)N+$"HI>0VW]7J-J_%!\B;)EH%I%]_O6O_1EVV]4SY4E6S#"V7TO%X<ADT%
MI9'@/.LYIUG6BU0D*.99R>>E$!R/3_<90`_IWY1Y]40<97M'':O>F>O?T2:E
MW.+56)D2/?DE=COD8+-\!I)Q?^/$JR[8B!]L)YZ:CHW^>]/M5?D"P_9Z?[R)
L)D<%^@,SGF?`R.`1L_//D\M9T3W\/ZI"M;2;IE!2\7B$2'X"W[RZ@MX$````
`
end
^ permalink raw reply
* Re: [PATCH] 2.4.20-rmap15b
From: Georg Nikodym @ 2002-12-17 21:54 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-mm, linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212171948400.26879-100000@imladris.surriel.com>
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]
On Tue, 17 Dec 2002 19:50:04 -0200 (BRST)
Rik van Riel <riel@conectiva.com.br> wrote:
> On Mon, 16 Dec 2002, Georg Nikodym wrote:
>
> > Incidentally, a colleague claimed to have seem this behaviour on a
> > non-rmap 2.4.20.
>
> > 1. Known behaviour?
> > 2. Is there any data that I should be collecting that people are
> > interested in?
> > 3. Or should I just go back to 2.4.19-rmap14b (which did not trouble
> > me
> > in this way)?
>
> The suspect is the disk elevator, which isn't scheduling requests
> in a way to cause lower read latency, but is optimised more for
> throughput. This results in some pauses.
>
> I'll need to look into it.
I discovered after sending the above:
Dec 16 15:08:04 keller kernel: ieee1394: sbp2: sbp2util_allocate_request_packet
- no packets available!
Dec 16 15:08:04 keller kernel: ieee1394: sbp2: sbp2util_allocate_write_request_p
acket failed
Dec 16 15:08:34 keller kernel: ieee1394: sbp2: aborting sbp2 command
These messages correspond with the pauses... However, the ieee1394 code
has not changed in some time (as in many months).
-g
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: MSN helper module
From: Carlos Fernandez Sanz @ 2002-12-17 21:46 UTC (permalink / raw)
To: Filip Sneppe (Cronos); +Cc: netfilter-devel, Michael Richardson
In-Reply-To: <1040161933.615.71.camel@exile>
Filip,
Thanks for the links. I have done some research already. I don't think it's
going to be a weekend project but possibly not a lot more :-) Anyway I don't
really have an option. It's starting to escalate...
BTW, when you started to work on this, did you take a look at the FTP
module? I think it solves most of the problems (including security), since
the connection method is identical to an active (PORT initiated) FTP data
connection.
Carlos.
----- Original Message -----
From: "Filip Sneppe (Cronos)" <filip.sneppe@cronos.be>
To: "Carlos Fernandez Sanz" <cfs-netfilter@nisupu.com>
Cc: <netfilter-devel@lists.netfilter.org>; "Michael Richardson"
<mcr@sandelman.ottawa.on.ca>
Sent: Tuesday, December 17, 2002 22:52
Subject: Re: MSN helper module
> On Tue, 2002-12-17 at 19:35, Carlos Fernandez Sanz wrote:
> > Yes, it needs some support for file tranmission, voice, etc. The
protocol
> > works a lot like FTP when using PORT (active) connections. The initiator
> > client sends its IP address and a port number for the other end to
connect
> > to. For basic messaging it doesn't need any special NAT support,
though -
> > the reason being that all connections are outgoing and there are no
related
> > children connections.
> >
> > So it is not a lot of work but it needs to be done. I haven't found
anything
> > about it so I'm assuming no one has started any work, so I'll do it
myself.
> > Anyway it's pretty much a one man job.
> >
>
> Hi Carlos,
>
> If you're thinking about this, these links will be of great help:
>
> http://www.hypothetic.org/docs/msn/index.php
> http://www.hypothetic.org/docs/msn/ietf_draft.php
> http://www.venkydude.com/articles/msn.htm
>
> I started working on a connection tracking module for this, but
> really didn't go any further than adding the basic conntrack/nat
> helper framework.
>
> If you're really serious about this, I can send you a diff of
> the basic conntrack/nat module to get you started. Just let me
> know.
>
> One thing to watch out for when writing a conntracker for
> this, is that the MSN packet that should add an expectation for
> a file transfer should contain data that like this:
>
> ...
> Invitation-Command: ACCEPT
> Invitation-Cookie: 33267
> IP-Address: 10.44.102.65
> Port: 6891
> AuthCookie: 93301
> ...
>
> Now the problem is that MSN also allows some chat-like protocol
> over the same port.
>
> If you're writing a conntracker, you must make sure that you
> are not parsing the "Messaging" packets as file transfer
> requests. Otherwise the code has a security vulnerability
> where a specially crafted "Messaging" packet can add a firewall
> connection expectation. When I realized my module was going to
> have to detect this, I realized this wasn't going to be a
> "weekend project" kind of thing and sort of gave up on it
> for now. It would be great if you picked up the slack !
>
> Regards,
> Filip
>
>
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Benjamin LaHaise @ 2002-12-17 21:53 UTC (permalink / raw)
To: H. Peter Anvin
Cc: dean gaudet, Linus Torvalds, Dave Jones, Ingo Molnar,
linux-kernel
In-Reply-To: <3DFF9A23.1090607@transmeta.com>
On Tue, Dec 17, 2002 at 01:41:55PM -0800, H. Peter Anvin wrote:
> > No, just take the number of context switches before and after the attempt
> > to read the time of day.
> How do you do that from userspace, atomically? A counter in the shared
> page?
Yup. You need some shared data for the TSC offset such anyways, so
moving the context switch counter onto such a page won't be much of
a problem. Using the %tr trick to get the CPU number would allow for
some of these data structures to be per-cpu without incurring any LOCK
overhead, too.
-ben
--
"Do you seek knowledge in time travel?"
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Benjamin LaHaise @ 2002-12-17 21:50 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Alan Cox, Ulrich Drepper, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <3DFF98F5.60706@transmeta.com>
On Tue, Dec 17, 2002 at 01:36:53PM -0800, H. Peter Anvin wrote:
> Benjamin LaHaise wrote:
> >
> > The stubs I used for the vsyscall bits just did an absolute jump to
> > the vsyscall page, which would then do a ret to the original calling
> > userspace code (since that provided library symbols for the user to
> > bind against).
> >
>
> What kind of "absolute jumps" were this?
It was a far jump (ljmp $__USER_CS,<address>).
-ben
--
"Do you seek knowledge in time travel?"
^ permalink raw reply
* Re: [PATCH] 2.4.20-rmap15b
From: Rik van Riel @ 2002-12-17 21:50 UTC (permalink / raw)
To: Georg Nikodym; +Cc: linux-mm, linux-kernel
In-Reply-To: <200212161610.gBGGAuB7028719@localhost.localdomain>
On Mon, 16 Dec 2002, Georg Nikodym wrote:
> Incidentally, a colleague claimed to have seem this behaviour on a
> non-rmap 2.4.20.
> 1. Known behaviour?
> 2. Is there any data that I should be collecting that people are
> interested in?
> 3. Or should I just go back to 2.4.19-rmap14b (which did not trouble me
> in this way)?
The suspect is the disk elevator, which isn't scheduling requests
in a way to cause lower read latency, but is optimised more for
throughput. This results in some pauses.
I'll need to look into it.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
^ permalink raw reply
* PROBLEM: VIA chipset, can't enable DMA
From: Martin Zoubek @ 2002-12-17 21:41 UTC (permalink / raw)
To: linux-ide
1. VIA chipset, can't enable DMA
2. VIA chipset is correctly detected, IRQs, ports, everything OK. But
then it says "hda: DMA: disabled". DMA enabling is set in my kernel
config. But in /proc/ide/hd?/settings there is shown using_dma 1.
Using "echo using_dma:1 > settings" don't help. DMA channels are
surely not enabled, disks are slower, trasfer rate dropped from 11
MB/s to 6.5 MB/s when copying files.
3. ide, dma
4. Linux version 2.5.52bk1 (root@kryten) (gcc version 3.2.1) #1 Tue
Dec 17 16:14:49 CET 2002
5. no Oops
7. BASH=/os/bash/bin/bash
BASH_VERSINFO=([0]="2" [1]="05a" [2]="0" [3]="1" [4]="release"
[5]="i686-pc-linux-gnu")
BASH_VERSION='2.05a.0(1)-release'
BOOT_IMAGE=bzimage2
COLUMNS=80
DIRSTACK=()
EUID=0
GROUPS=()
HISTFILE=//.bash_history
HISTFILESIZE=500
HISTSIZE=500
HOME=/
HOSTNAME='(none)'
HOSTTYPE=i686
IFS=$' \t\n'
LD_LIBRARY_PATH=/os/glibc/lib:/os/gcc/lib:/os/ncurses/lib:/os/perl/lib:/os/flex/lib:/os/binutils/lib:/os/bzip2/lib:/os/e2fsprogs/lib:/os/libtool/lib:/os/procps/lib:/os/gettext/lib:/os/shadow/lib
LD_RUN_PATH=/os/glibc/lib:/os/gcc/lib:/os/ncurses/lib:/os/perl/lib:/os/flex/lib:/os/binutils/lib:/os/bzip2/lib:/os/e2fsprogs/lib:/os/libtool/lib:/os/procps/lib:/os/gettext/lib:/os/shadow/lib
LINES=25
MACHTYPE=i686-pc-linux-gnu
MAILCHECK=60
OLDPWD=/
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/os/glibc/libexec:/os/glibc/sbin:/os/glibc/bin:/os/m4/bin:/os/autoconf/bin:/os/bison/bin:/os/mawk/bin:/os/gcc/bin:/os/findutils/libexec:/os/findutils/bin:/os/ncurses/bin:/os/less/bin:/os/groff/bin:/os/perl/bin:/os/textutils/bin:/os/sed/bin:/os/flex/bin:/os/binutils/bin:/os/fileutils/bin:/os/sh-utils/bin:/os/texinfo/bin:/os/bash/bin:/os/bzip2/bin:/os/diffutils/bin:/os/e2fsprogs/sbin:/os/e2fsprogs/bin:/os/grep/bin:/os/gzip/bin:/os/make/bin:/os/patch/bin:/os/tar/libexec:/os/tar/bin:/os/byacc/bin:/os/man/sbin:/os/man/bin:/os/automake/bin:/os/file/bin:/os/libtool/bin:/os/kbd/bin:/os/modutils/sbin:/os/netkit-base/sbin:/os/netkit-base/bin:/os/procinfo/bin:/os/procps/sbin:/os/procps/bin:/os/psmisc/bin:/os/gettext/bin:/os/net-tools/sbin:/os/net-tools/bin:/os/shadow/sbin:/os/shadow/bin:/os/sysklogd/sbin:/os/sysvinit/sbin:/os/sysvinit/bin:/os/util-linux/sbin:/os/util-linux/bin:/os/devfsd/sbin
PIPESTATUS=([0]="0")
PPID=1
PS1='\s-\v\$ '
PS2='> '
PS4='+ '
PWD=/os/linux/src
SHELL=/os/bash/bin/bash
SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comments:emacs
SHLVL=1
TERM=linux
UID=0
_=ls
init=/linuxrc
7.1. If some fields are empty or look unusual you may have an old
version.
Compare to the current minimal requirements in Documentation/Changes.
Linux (none) 2.5.52bk1 #1 Tue Dec 17 16:14:49 CET 2002 i686 unknown
Gnu C 3.2.1
Gnu make 3.79.1
binutils 2.11.2
util-linux 2.11n
mount 2.11n
modutils 2.4.13
e2fsprogs 1.26-WIP
Linux C Library 2.2.5
Linux C Library 2.2.5
Linux C Library 2.2.5
Dynamic linker (ldd) 2.2.5
Procps mounted
Net-tools 1.60
Kbd 1.06
Sh-utils 2.0
7.2. processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping : 2
cpu MHz : 751.127
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1470.46
7.4. 0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
4000-40ff : VIA Technologies, In VT82C686 [Apollo Sup
5000-500f : VIA Technologies, In VT82C686 [Apollo Sup
6000-607f : VIA Technologies, In VT82C686 [Apollo Sup
d000-d00f : VIA Technologies, In VT82C586B PIPC Bus M
d000-d007 : ide0
d008-d00f : ide1
dc00-dcff : VIA Technologies, In VT82C686 AC97 Audio
e000-e003 : VIA Technologies, In VT82C686 AC97 Audio
e400-e403 : VIA Technologies, In VT82C686 AC97 Audio
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-00efffff : System RAM
00100000-00364fc1 : Kernel code
00364fc2-003f097f : Kernel data
00f00000-00ffffff : reserved
01000000-07feffff : System RAM
07ff0000-07ff2fff : ACPI Non-volatile Storage
07ff3000-07ffffff : ACPI Tables
d0000000-d7ffffff : PCI Bus #01
d0000000-d7ffffff : nVidia Corporation NV11 [GeForce2 MX]
d8000000-dbffffff : VIA Technologies, In VT8363/8365 [KT133/K
dc000000-ddffffff : PCI Bus #01
dc000000-dcffffff : nVidia Corporation NV11 [GeForce2 MX]
de000000-de0001ff : Philips Semiconducto SAA7146
de001000-de001fff : Brooktree Corporatio Bt878 Video Capture
de002000-de002fff : Brooktree Corporatio Bt878 Audio Capture
ffff0000-ffffffff : reserved
7.5. PCI devices found:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies, In VT8363/8365 [KT133/K (rev 3).
Prefetchable 32 bit memory at 0xd8000000 [0xdbffffff].
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies, In VT8363/8365 [KT133/K (rev 0).
Master Capable. No bursts. Min Gnt=12.
Bus 0, device 7, function 0:
ISA bridge: VIA Technologies, In VT82C686 [Apollo Sup (rev 34).
Bus 0, device 7, function 1:
IDE interface: VIA Technologies, In VT82C586B PIPC Bus M (rev
16).
Master Capable. Latency=32.
I/O at 0xd000 [0xd00f].
Bus 0, device 7, function 4:
Host bridge: VIA Technologies, In VT82C686 [Apollo Sup (rev 48).
IRQ 11.
Bus 0, device 7, function 5:
Multimedia audio controller: VIA Technologies, In VT82C686 AC97
Audio (rev 32).
IRQ 12.
I/O at 0xdc00 [0xdcff].
I/O at 0xe000 [0xe003].
I/O at 0xe400 [0xe403].
Bus 0, device 10, function 0:
Multimedia controller: Philips Semiconducto SAA7146 (rev 1).
IRQ 9.
Master Capable. Latency=32. Min Gnt=15.Max Lat=38.
Non-prefetchable 32 bit memory at 0xde000000 [0xde0001ff].
Bus 0, device 12, function 0:
Multimedia video controller: Brooktree Corporatio Bt878 Video
Capture (rev 2).
IRQ 10.
Master Capable. Latency=32. Min Gnt=16.Max Lat=40.
Prefetchable 32 bit memory at 0xde001000 [0xde001fff].
Bus 0, device 12, function 1:
Multimedia controller: Brooktree Corporatio Bt878 Audio Capture
(rev 2).
IRQ 10.
Master Capable. Latency=32. Min Gnt=4.Max Lat=255.
Prefetchable 32 bit memory at 0xde002000 [0xde002fff].
Bus 1, device 0, function 0:
VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX]
(rev 161).
IRQ 11.
Master Capable. Latency=32. Min Gnt=5.Max Lat=1.
Non-prefetchable 32 bit memory at 0xdc000000 [0xdcffffff].
Prefetchable 32 bit memory at 0xd0000000 [0xd7ffffff].
X. With my 2.5.3 kernel (compiled under the same compiler,
environment, etc.) there is no such problem.
Bye,
Martin Zoubek
zoubek@seznam.cz
______________________________________________________________________
Reklama:
MP3 autorádio SONY CDX-MP30 za 8 990,-!/10 hodin hudby na jednom CD/odním. čelní panel/4x50W/D-bass/CD-R,RW play http://ad2.seznam.cz/redir.cgi?instance=38953%26url=http://www.sony-mobile.cz/
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Jun Sun @ 2002-12-17 21:40 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, linux-mips, jsun
In-Reply-To: <Pine.GSO.3.96.1021217131352.7289A-100000@delta.ds2.pg.gda.pl>
On Tue, Dec 17, 2002 at 02:39:21PM +0100, Maciej W. Rozycki wrote:
> > No MIPS boards are using do_slow_gettimeoffset(). We really should get
> > rid of it.
>
> I know none does at the moment. But are you sure there is no system that
> would need it and might be supported one day?
>
I serisouly don't think so. Moving forward every CPU will have a CPU counter,
which can be used for timeoffset purpose. Even if it does not have one,
it will surely have some onboard high resolution timer, which can be used
to intra-jiffy offset purpose.
Anyway, this function is only defined in old-time.c, which will go away
soon (hopefully). :-)
> Here is an example (untested) code that I would recommend. It sends
> explicit ACKs to the i8259As, which has the following advantages:
>
<snip>
Cool. This code works for me.
I studied it a little bit and I am convinced it is a better choice.
It should work for MIPS in general.
In my original code I did verify that the IRR bit is not cleared,
which apparently will be a problem in cases.
The only catch with your code is that we don't have iob() macro (which
apparently is very useful). Any suggestions on this? Otherwise
I will probably remove it.
Jun
^ permalink raw reply
* RE: [PATCH] S4bios for 2.5.52.
From: Grover, Andrew @ 2002-12-17 21:39 UTC (permalink / raw)
To: 'Ducrot Bruno', linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Pavel Machek, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> From: Ducrot Bruno [mailto:poup-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org]
> This patch add s4bios support for 2.5.52.
>
> S4bios is an alternative for the ACPI S4 system suspend
> state, but is a bit
> more easy to implement. It suppose though that the BIOS
> support this feature.
> For some BIOS, creating a so-called suspend partition with the help
> of lphdisk is OK.
>
> Plus, it permit for Pavel to have a nice graphic display at
> suspend/resume.
>
> echo 4 > /proc/acpi/sleep is for swsusp;
> echo 4b > /proc/acpi/sleep is for s4bios.
I still am not clear on why we would want s4bios in 2.5.x, since we have S4.
Like you said, S4bios is easier to implement, but since Pavel has done much
of the heavy lifting required for S4 proper, I don't see the need.
Regards -- Andy
^ permalink raw reply
* Re: Who's doing the SIBO port?
From: Paul Nasrat @ 2002-12-17 21:36 UTC (permalink / raw)
To: Linux 8086
In-Reply-To: <200212170917.gBH9H1Ix018482@eddie.loc>
On Tue, Dec 17, 2002 at 09:17:00AM +0000, Richard Wallman wrote:
> After successfully wiping the Internal ramdisk on my 3c (DOH! Where's
> that backup...) I thought it might be easier to ask the maintainer.
Apologies, I've been meaning to update the docs... :(
I'll shout you beer sometime if you are ever in London.
> Who's the current maintainer of the SIBO port, and is there any work
I've been keeping it compilable for elks, so I guess that's me. however
without workable psion at the moment as it was stolen :( Will replace
shortly, as my brother may be giving me his.
> being done on it? I think at very least putting a bloody big warning in
> the FAQ along the lines of: "If you don't know exactly what you're
> doing, you're likely to wipe everything, so backup NOW!" rather than
> the kinda weak "It's not worth installing" message in /INSTALLATION
OK - will add a better warning for the sibo stuff and some better
instructions.
Things I want do - enable support for larger ssd's, ensure it doesn't
run out of memory after a few commands. Try to make work with psions
with lower memory
Paul
^ permalink raw reply
* PROBLEM: /dev/initctl not working
From: Martin Zoubek @ 2002-12-17 21:43 UTC (permalink / raw)
To: linux-kernel
1. /dev/initctl not working
2. Init says "timeout opening/writing control channel /dev/initctl"
3. ?
4. Linux version 2.5.52bk1 (root@kryten) (gcc version 3.2.1) #1 Tue
Dec 17 16:14:49 CET 2002
5. no Oops
6. eg. "init 3"
7. BASH=/os/bash/bin/bash
BASH_VERSINFO=([0]="2" [1]="05a" [2]="0" [3]="1" [4]="release"
[5]="i686-pc-linux-gnu")
BASH_VERSION='2.05a.0(1)-release'
BOOT_IMAGE=bzimage2
COLUMNS=80
DIRSTACK=()
EUID=0
GROUPS=()
HISTFILE=//.bash_history
HISTFILESIZE=500
HISTSIZE=500
HOME=/
HOSTNAME='(none)'
HOSTTYPE=i686
IFS=$' \t\n'
LD_LIBRARY_PATH=/os/glibc/lib:/os/gcc/lib:/os/ncurses/lib:/os/perl/lib:/os/flex/lib:/os/binutils/lib:/os/bzip2/lib:/os/e2fsprogs/lib:/os/libtool/lib:/os/procps/lib:/os/gettext/lib:/os/shadow/lib
LD_RUN_PATH=/os/glibc/lib:/os/gcc/lib:/os/ncurses/lib:/os/perl/lib:/os/flex/lib:/os/binutils/lib:/os/bzip2/lib:/os/e2fsprogs/lib:/os/libtool/lib:/os/procps/lib:/os/gettext/lib:/os/shadow/lib
LINES=25
MACHTYPE=i686-pc-linux-gnu
MAILCHECK=60
OLDPWD=/
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/os/glibc/libexec:/os/glibc/sbin:/os/glibc/bin:/os/m4/bin:/os/autoconf/bin:/os/bison/bin:/os/mawk/bin:/os/gcc/bin:/os/findutils/libexec:/os/findutils/bin:/os/ncurses/bin:/os/less/bin:/os/groff/bin:/os/perl/bin:/os/textutils/bin:/os/sed/bin:/os/flex/bin:/os/binutils/bin:/os/fileutils/bin:/os/sh-utils/bin:/os/texinfo/bin:/os/bash/bin:/os/bzip2/bin:/os/diffutils/bin:/os/e2fsprogs/sbin:/os/e2fsprogs/bin:/os/grep/bin:/os/gzip/bin:/os/make/bin:/os/patch/bin:/os/tar/libexec:/os/tar/bin:/os/byacc/bin:/os/man/sbin:/os/man/bin:/os/automake/bin:/os/file/bin:/os/libtool/bin:/os/kbd/bin:/os/modutils/sbin:/os/netkit-base/sbin:/os/netkit-base/bin:/os/procinfo/bin:/os/procps/sbin:/os/procps/bin:/os/psmisc/bin:/os/gettext/bin:/os/net-tools/sbin:/os/net-tools/bin:/os/shadow/sbin:/os/shadow/bin:/os/sysklogd/sbin:/os/sysvinit/sbin:/os/sysvinit/bin:/os/util-linux/sbin:/os/util-linux/bin:/os/devfsd/sbin
PIPESTATUS=([0]="0")
PPID=1
PS1='\s-\v\$ '
PS2='> '
PS4='+ '
PWD=/os/linux/src
SHELL=/os/bash/bin/bash
SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comments:emacs
SHLVL=1
TERM=linux
UID=0
_=ls
init=/linuxrc
7.1. If some fields are empty or look unusual you may have an old
version.
Compare to the current minimal requirements in Documentation/Changes.
Linux (none) 2.5.52bk1 #1 Tue Dec 17 16:14:49 CET 2002 i686 unknown
Gnu C 3.2.1
Gnu make 3.79.1
binutils 2.11.2
util-linux 2.11n
mount 2.11n
modutils 2.4.13
e2fsprogs 1.26-WIP
Linux C Library 2.2.5
Linux C Library 2.2.5
Linux C Library 2.2.5
Dynamic linker (ldd) 2.2.5
Procps mounted
Net-tools 1.60
Kbd 1.06
Sh-utils 2.0
7.2. processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping : 2
cpu MHz : 751.127
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1470.46
7.4. 0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
4000-40ff : VIA Technologies, In VT82C686 [Apollo Sup
5000-500f : VIA Technologies, In VT82C686 [Apollo Sup
6000-607f : VIA Technologies, In VT82C686 [Apollo Sup
d000-d00f : VIA Technologies, In VT82C586B PIPC Bus M
d000-d007 : ide0
d008-d00f : ide1
dc00-dcff : VIA Technologies, In VT82C686 AC97 Audio
e000-e003 : VIA Technologies, In VT82C686 AC97 Audio
e400-e403 : VIA Technologies, In VT82C686 AC97 Audio
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-00efffff : System RAM
00100000-00364fc1 : Kernel code
00364fc2-003f097f : Kernel data
00f00000-00ffffff : reserved
01000000-07feffff : System RAM
07ff0000-07ff2fff : ACPI Non-volatile Storage
07ff3000-07ffffff : ACPI Tables
d0000000-d7ffffff : PCI Bus #01
d0000000-d7ffffff : nVidia Corporation NV11 [GeForce2 MX]
d8000000-dbffffff : VIA Technologies, In VT8363/8365 [KT133/K
dc000000-ddffffff : PCI Bus #01
dc000000-dcffffff : nVidia Corporation NV11 [GeForce2 MX]
de000000-de0001ff : Philips Semiconducto SAA7146
de001000-de001fff : Brooktree Corporatio Bt878 Video Capture
de002000-de002fff : Brooktree Corporatio Bt878 Audio Capture
ffff0000-ffffffff : reserved
7.5. PCI devices found:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies, In VT8363/8365 [KT133/K (rev 3).
Prefetchable 32 bit memory at 0xd8000000 [0xdbffffff].
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies, In VT8363/8365 [KT133/K (rev 0).
Master Capable. No bursts. Min Gnt=12.
Bus 0, device 7, function 0:
ISA bridge: VIA Technologies, In VT82C686 [Apollo Sup (rev 34).
Bus 0, device 7, function 1:
IDE interface: VIA Technologies, In VT82C586B PIPC Bus M (rev
16).
Master Capable. Latency=32.
I/O at 0xd000 [0xd00f].
Bus 0, device 7, function 4:
Host bridge: VIA Technologies, In VT82C686 [Apollo Sup (rev 48).
IRQ 11.
Bus 0, device 7, function 5:
Multimedia audio controller: VIA Technologies, In VT82C686 AC97
Audio (rev 32).
IRQ 12.
I/O at 0xdc00 [0xdcff].
I/O at 0xe000 [0xe003].
I/O at 0xe400 [0xe403].
Bus 0, device 10, function 0:
Multimedia controller: Philips Semiconducto SAA7146 (rev 1).
IRQ 9.
Master Capable. Latency=32. Min Gnt=15.Max Lat=38.
Non-prefetchable 32 bit memory at 0xde000000 [0xde0001ff].
Bus 0, device 12, function 0:
Multimedia video controller: Brooktree Corporatio Bt878 Video
Capture (rev 2).
IRQ 10.
Master Capable. Latency=32. Min Gnt=16.Max Lat=40.
Prefetchable 32 bit memory at 0xde001000 [0xde001fff].
Bus 0, device 12, function 1:
Multimedia controller: Brooktree Corporatio Bt878 Audio Capture
(rev 2).
IRQ 10.
Master Capable. Latency=32. Min Gnt=4.Max Lat=255.
Prefetchable 32 bit memory at 0xde002000 [0xde002fff].
Bus 1, device 0, function 0:
VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX]
(rev 161).
IRQ 11.
Master Capable. Latency=32. Min Gnt=5.Max Lat=1.
Non-prefetchable 32 bit memory at 0xdc000000 [0xdcffffff].
Prefetchable 32 bit memory at 0xd0000000 [0xd7ffffff].
X. With my 2.5.3 kernel (compiled under the same compiler,
environment, etc.) there is no such problem. I could not find which
procedures in kernel are responsible for this, so I could not make a
patch.
Bye,
Martin Zoubek
zoubek@seznam.cz
______________________________________________________________________
Reklama:
FIMFARUM - Cesky celovecerni loutkovy film na motivy pohadek Jana Wericha. www.fimfarum.cz V kinech od 28. listopadu. http://www.fimfarum.cz
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 21:41 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: dean gaudet, Linus Torvalds, Dave Jones, Ingo Molnar,
linux-kernel
In-Reply-To: <20021217163954.D10781@redhat.com>
Benjamin LaHaise wrote:
> On Tue, Dec 17, 2002 at 11:11:19AM -0800, H. Peter Anvin wrote:
>
>>>against 0xfffffxxx and "rollback" (or complete) any incomplete
>>>gettimeofday call prior to saving a task's state. but i bet that test is
>>>undesirable on all interrupt paths.
>>>
>>
>>Exactly. This is a real problem.
>
>
> No, just take the number of context switches before and after the attempt
> to read the time of day.
>
How do you do that from userspace, atomically? A counter in the shared
page?
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 21:41 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Ulrich Drepper, Alan Cox, Linus Torvalds, Matti Aarnio,
Hugh Dickins, Dave Jones, Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <20021217163838.C10781@redhat.com>
Benjamin LaHaise wrote:
> On Tue, Dec 17, 2002 at 10:57:29AM -0800, Ulrich Drepper wrote:
>
>>But this is exactly what I expect to happen. If you want to implement
>>gettimeofday() at user-level you need to modify the page. Some of the
>>information the kernel has to keep for the thread group can be stored in
>>this place and eventually be used by some uerlevel code executed by
>>jumping to 0xfffff000 or whatever the address is.
>
>
> You don't actually need to modify the page, rather the data for the user
> level gettimeofday needs to be in a shared page and some register (like
> %tr) must expose the current cpu number to index into the data. Either
> way, it's an internal implementation detail for the kernel to take care
> of, with multiple potential solutions.
>
That's not the problem... the problem is that the userland code can get
preempted at any time and rescheduled on another CPU.
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Benjamin LaHaise @ 2002-12-17 21:39 UTC (permalink / raw)
To: H. Peter Anvin
Cc: dean gaudet, Linus Torvalds, Dave Jones, Ingo Molnar,
linux-kernel
In-Reply-To: <3DFF76D7.2050403@transmeta.com>
On Tue, Dec 17, 2002 at 11:11:19AM -0800, H. Peter Anvin wrote:
> > against 0xfffffxxx and "rollback" (or complete) any incomplete
> > gettimeofday call prior to saving a task's state. but i bet that test is
> > undesirable on all interrupt paths.
> >
>
> Exactly. This is a real problem.
No, just take the number of context switches before and after the attempt
to read the time of day.
-ben
--
"Do you seek knowledge in time travel?"
^ permalink raw reply
* RE: [PATCH] S4bios for 2.5.52.
From: Grover, Andrew @ 2002-12-17 21:39 UTC (permalink / raw)
To: 'Ducrot Bruno', linux-kernel; +Cc: Pavel Machek, acpi-devel
> From: Ducrot Bruno [mailto:poup@poupinou.org]
> This patch add s4bios support for 2.5.52.
>
> S4bios is an alternative for the ACPI S4 system suspend
> state, but is a bit
> more easy to implement. It suppose though that the BIOS
> support this feature.
> For some BIOS, creating a so-called suspend partition with the help
> of lphdisk is OK.
>
> Plus, it permit for Pavel to have a nice graphic display at
> suspend/resume.
>
> echo 4 > /proc/acpi/sleep is for swsusp;
> echo 4b > /proc/acpi/sleep is for s4bios.
I still am not clear on why we would want s4bios in 2.5.x, since we have S4.
Like you said, S4bios is easier to implement, but since Pavel has done much
of the heavy lifting required for S4 proper, I don't see the need.
Regards -- Andy
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Benjamin LaHaise @ 2002-12-17 21:38 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Alan Cox, Linus Torvalds, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List, hpa
In-Reply-To: <3DFF7399.40708@redhat.com>
On Tue, Dec 17, 2002 at 10:57:29AM -0800, Ulrich Drepper wrote:
> But this is exactly what I expect to happen. If you want to implement
> gettimeofday() at user-level you need to modify the page. Some of the
> information the kernel has to keep for the thread group can be stored in
> this place and eventually be used by some uerlevel code executed by
> jumping to 0xfffff000 or whatever the address is.
You don't actually need to modify the page, rather the data for the user
level gettimeofday needs to be in a shared page and some register (like
%tr) must expose the current cpu number to index into the data. Either
way, it's an internal implementation detail for the kernel to take care
of, with multiple potential solutions.
-ben
--
"Do you seek knowledge in time travel?"
^ permalink raw reply
* Re: Alsa-devel digest, Vol 1 #896 - 15 msgs
From: Pedro Lopez-Cabanillas @ 2002-12-17 21:29 UTC (permalink / raw)
To: alsa-devel; +Cc: Takashi Iwai
In-Reply-To: <E18OFZy-0000Ic-00@sc8-sf-list2.sourceforge.net>
Hi,
On Tuesday 17 December 2002 12:07, Takashi Iwai wrote:
> the behavior depends on the order of booting.
> if the hotplug service is booted before the alsasound init script,
> hotplug will start the snd-usbaudio module, which will be assigned as
> the first empty device, i.e. device #0, unless you specify the index
> option. and afterwards, the alsasound script is started, and it
> results in the confliction of devices.
>
> setting an index option is one of the solutions.
> in this case, the first usb-audio/midi device will be forced to be
> assigned to #1. so, it's safe to start it beforehand.
>
> but, when we take a deeper look at this, we find another problem.
> the alsasound init script checks whether the ALSA was already started
> by checking the existence of /proc/asound directory. and, if hotplug
> started the usb-audio/midi before alsasound, this directory would be
> also created because the alsa core was started without help of
> alsasound init script, too. this leads to the skip of loading of any
> other soundcards, because alsasound will quit immediately.
>
> after all, a simple solution for this is to make sure that alsasound
> starts before hotplug. then, even the index option for snd-usbaudio
> wouldn't be necessary (in theory).
I'm running a Mandrake 8.something here, where usb is started before alsa, and
this order is good IMHO. The usb init script loads the HCD driver (uhci,
ohci...) and related modules, then mounts usbfs (/proc/bus/usb filesystem).
This enables hotplug, needed if you want to use a Midiman2x2 or any other
device requiring firmware loading.
But, as you said, hotplug can load snd-usb-audio driver by itself, (if some
usb midi or audio device is plugged at boot time) and then the alsasound
script fails to load other drivers, as it finds /proc/asound already mounted.
My easy and ugly workaround is to add one more line to the bottom of
/etc/hotplug/blacklist file with a "snd-usb-audio" string. This prevents
hotplug from loading that module, which is done by the alsasound script some
time later.
Regards,
Pedro
--
ALSA Library Bindings for Pascal
http://alsapas.alturl.com
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 21:36 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Linus Torvalds, Alan Cox, Ulrich Drepper, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <20021217163458.B10781@redhat.com>
Benjamin LaHaise wrote:
>
> The stubs I used for the vsyscall bits just did an absolute jump to
> the vsyscall page, which would then do a ret to the original calling
> userspace code (since that provided library symbols for the user to
> bind against).
>
What kind of "absolute jumps" were this?
-hpa
^ permalink raw reply
* Re: 2.5.52 compile error
From: Richard B. Tilley (Brad) @ 2002-12-17 21:34 UTC (permalink / raw)
To: Steven Cole; +Cc: Bob Miller, Linux Kernel
In-Reply-To: <1040160551.16547.27.camel@spc9.esa.lanl.gov>
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
Yes, my fingers need a keyboard. You are a very intelligent person to
understand this. May your knowledge rub off onto me.
All of these options are modules in my config file, *must* they be built
into the kernel in order to compile?
On Tue, 2002-12-17 at 16:29, Steven Cole wrote:
> On Tue, 2002-12-17 at 14:16, Bob Miller wrote:
> > On Tue, Dec 17, 2002 at 03:57:01PM -0500, rtilley wrote:
> > > Using RH's default *i686.config to build a vanilla 2.5.52 kernel. It keeps
> > > returning this error on 2 totally different x86 PCs:
> > >
> > >
> > > drivers/built-in.o: In function `kd_nosound':
> > > drivers/built-in.o(.text+0x1883f): undefined reference to `input_event'
> [more errors snipped]
> > >
> > > Where is the fix for this?
> > >
> > At your finger tips ;-). Turn on CONFIG_INPUT via "Input device support"
> > off the main page.
>
> And if you want to use your keyboard or mouse, something similar to the
> following may be helpful, depending on your system.
>
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ATKBD=y
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=y
> CONFIG_INPUT_MISC=y
>
> Steven
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Benjamin LaHaise @ 2002-12-17 21:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alan Cox, Ulrich Drepper, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <Pine.LNX.4.44.0212171046550.1095-100000@home.transmeta.com>
On Tue, Dec 17, 2002 at 10:49:31AM -0800, Linus Torvalds wrote:
> There is only a "call relative" or "call indirect-absolute". So you either
> have to indirect through memory or a register, or you have to fix up the
> call at link-time.
>
> Yeah, I know it sounds strange, but it makes sense. Absolute calls are
> actually very unusual, and using relative calls is _usually_ the right
> thing to do. It's only in cases like this that we really want to call a
> specific address.
The stubs I used for the vsyscall bits just did an absolute jump to
the vsyscall page, which would then do a ret to the original calling
userspace code (since that provided library symbols for the user to
bind against).
-ben
--
"Do you seek knowledge in time travel?"
^ permalink raw reply
* [PATCH 2.5.52] Optimize include/asm-ARCH/page.h:get_order() (take 1.0)
From: Inaky Perez-Gonzalez @ 2002-12-17 21:25 UTC (permalink / raw)
To: falk.hueffner, torvalds, linux-kernel
Hi all
This patch is a reorganization and optimization of the get_order()
function.
Currently each architecture defines its version in
asm-${ARCH}/page.h, being most of them the same function. I have
unified the implementation in asm-generic/page.h, as
generic_get_order(). Then each arch can implement it's own version
or use the generic one [as the patch stands now, every
architecture that had the generic version uses
generic_get_oder()].
The optimization is done in the way the generic_get_order() is
implemented; currently it is a loop - however, that can be highly
optimized by using fls() [available on each architecture or as
generic_fls() where not optimized].
On my tests in a tight loop doing repeated get_order() calls (see
included test program), I got an aprox average run time of 6m24s
for the unoptimized version (the old one, executing "time ./goo -v
speed-new") and 2m32s for the optimized version (executing "time
./goo -v speed-old"). The test machine is a 2xP3 933MHhz 1.5GB.
Even using generic_fls() on ia32 yields better results - my guess
is it caused for it being a fixed-path function instead of a for()
loop.
I was only able to test it and try it in ia32, so I don't know if
I broke anything else in other archs; reports welcome.
CAVEATS:
- the #include <asm-generic/page.h> ... I don't know if it is the
best way to do it. Any ideas?
- Some arches still define fls() as the generic_fls(), instead of
using bit-searching ASM instructions - I lack the knowledge to
fix it, though.
Changelog:
- Pull up to 2.5.52
- Fixes some obvious, blatant and stupid errors I did in the
first release.
- Increase the speed up.
Test program (patch follows):
compile with 'cc -Iinclude/ -Wall -g -O2 goo.c -o goo' from the
root of the patched linux kernel tree.
#define __KERNEL__
#define __ASSEMBLY__
#include "asm-i386/bitops.h"
#include "asm-i386/page.h"
#include "asm-generic/page.h"
#include <stdio.h>
#include <getopt.h>
#include <stdlib.h>
/* Old, unoptimized version */
static __inline__
int get_order_0 (unsigned long size)
{
int order;
size = (size-1) >> (PAGE_SHIFT-1);
order = -1;
do {
size >>= 1;
order++;
} while (size);
return order;
}
unsigned long verbose_step = 0;
static __inline__
void progress (unsigned long cnt)
{
if (verbose_step && (cnt % verbose_step) == 0)
printf ("Going through %lu\n", cnt);
}
void help (FILE *f)
{
fprintf (f,
"Usage: goo [-b BOTTOM] [-t TOP] [-s STEP] [-v VSTEP] [-h]\n"
" {verify,speed-new,speed-old}\n"
"\n"
"-b BOTTOM where to start counting [0]\n"
"-t TOP where to stop counting [~0UL]\n"
"-s STEP count increment [1]\n"
"-v VSTEP Every VSTEP report the count [0]\n"
"\n"
"verify Verify that the old and new implementations behave the same\n"
" from BOTTOM to TOP with STEP.\n"
"\n"
"speed-new Call the optimized get_order() for all the numbers from\n"
" BOTTOM to TOP with STEP.\n"
"\n"
"speed-old Call the original get_order() for all the numbers from\n"
" BOTTOM to TOP with STEP.\n"
"\n"
"It is nice to have a wide range, so that the timing is better; use -v\n"
"if you want reporting because it feels nice. The default range covers\n"
"all that an unsigned long can hold.\n"
);
}
/* Test driver
**
** We just count from 0 to ~0UL; in verify mode, we verify that
** _every_ number get's the same order with the old and new
** versions. In the speed mode we just run in a tight loop so that
** it can be rawly measured how fast is the new version (speed-new)
** against the old version (speed-old). time(1) is your friend.
*/
int main (int argc, char **argv)
{
const char *mode;
int opterr, c;
unsigned long bottom = 0,
top = ~0UL,
step = 1,
dummy = 0,
cnt;
opterr = 0;
while ((c = getopt (argc, argv, "b:t:s:v:h")) != -1)
switch (c) {
case 'b':
bottom = strtoul (optarg, NULL, 10);
break;
case 't':
top = strtoul (optarg, NULL, 10);
break;
case 's':
step = strtoul (optarg, NULL, 10);
break;
case 'v':
verbose_step = strtoul (optarg, NULL, 10);
break;
case 'h':
help (stdout);
exit (0);
break;
case '?':
default:
fprintf (stderr, "Unknown option %s\n", argv[optind]);
help (stderr);
exit (1);
}
if (argc < 2) {
help (stderr);
return 1;
}
mode = argv[optind];
if (!strcmp (mode, "verify")) {
for (cnt = bottom; cnt < top; cnt += step) {
if (get_order_0 (cnt) != generic_get_order (cnt))
printf ("error: %lu - different results\n", cnt);
progress (cnt);
}
}
else if (!strcmp (mode, "speed-old")) {
for (cnt = bottom; cnt < top; cnt += step) {
dummy += get_order_0 (cnt);
progress (cnt);
}
}
else if (!strcmp (mode, "speed-new")) {
for (cnt = bottom; cnt < top; cnt += step) {
dummy += generic_get_order (cnt);
progress (cnt);
}
}
else {
fprintf (stderr, "Unknown mode\n");
help (stderr);
exit (1);
}
printf ("accumulated dummy = %lu\n", dummy);
return 0;
}
/*
** Local Variables:
** compile-command: "cc -Iinclude/ -Wall -g -O2 goo.c -o goo"
** End:
*/
diff -u include/asm-alpha/page.h:1.1.1.1 include/asm-alpha/page.h:1.1.1.1.6.1
--- include/asm-alpha/page.h:1.1.1.1 Wed Dec 11 11:06:01 2002
+++ include/asm-alpha/page.h Mon Dec 16 20:36:48 2002
@@ -67,18 +67,17 @@
#define PAGE_BUG(page) BUG()
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
+
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
#endif /* !__ASSEMBLY__ */
diff -u include/asm-arm/page.h:1.1.1.1 include/asm-arm/page.h:1.1.1.1.6.1
--- include/asm-arm/page.h:1.1.1.1 Wed Dec 11 11:06:01 2002
+++ include/asm-arm/page.h Mon Dec 16 20:36:48 2002
@@ -175,18 +175,16 @@
#endif
-/* Pure 2^n version of get_order */
-static inline int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
#include <asm/memory.h>
diff -u /dev/null include/asm-generic/page.h:1.1.2.1
--- /dev/null Tue Dec 17 13:20:35 2002
+++ include/asm-generic/page.h Mon Dec 16 20:36:48 2002
@@ -0,0 +1,20 @@
+#ifndef _GENERIC_PAGE_H
+#define _GENERIC_PAGE_H
+
+#include <asm/bitops.h>
+
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+static __inline__
+int generic_get_order (unsigned long s)
+{
+ s = (s - 1) >> PAGE_SHIFT;
+ if (s == 0)
+ return 0;
+ return fls (s);
+}
+
+#endif _GENERIC_PAGE_H
+
diff -u include/asm-i386/bitops.h:1.1.1.3 include/asm-i386/bitops.h:1.1.1.3.2.1
--- include/asm-i386/bitops.h:1.1.1.3 Wed Dec 11 11:13:36 2002
+++ include/asm-i386/bitops.h Mon Dec 16 20:36:48 2002
@@ -416,11 +416,19 @@
return word;
}
-/*
- * fls: find last bit set.
+/**
+ * __fls - find last bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
*/
-
-#define fls(x) generic_fls(x)
+static __inline__ unsigned long __fls(unsigned long word)
+{
+ __asm__("bsrl %1,%0"
+ :"=r" (word)
+ :"rm" (word));
+ return word;
+}
#ifdef __KERNEL__
@@ -456,6 +464,23 @@
int r;
__asm__("bsfl %1,%0\n\t"
+ "jnz 1f\n\t"
+ "movl $-1,%0\n"
+ "1:" : "=r" (r) : "g" (x));
+ return r+1;
+}
+
+/**
+ * fls - find last bit set
+ * @x: the word to search
+ *
+ * Check out comments for ffs()
+ */
+static __inline__ int fls(int x)
+{
+ int r;
+
+ __asm__("bsrl %1,%0\n\t"
"jnz 1f\n\t"
"movl $-1,%0\n"
"1:" : "=r" (r) : "g" (x));
diff -u include/asm-i386/page.h:1.1.1.1 include/asm-i386/page.h:1.1.1.1.6.1
--- include/asm-i386/page.h:1.1.1.1 Wed Dec 11 11:06:01 2002
+++ include/asm-i386/page.h Mon Dec 16 20:36:48 2002
@@ -120,18 +120,17 @@
BUG(); \
} while (0)
-/* Pure 2^n version of get_order */
-static __inline__ int get_order(unsigned long size)
-{
- int order;
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
+
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
#endif /* __ASSEMBLY__ */
diff -u include/asm-m68k/page.h:1.1.1.2 include/asm-m68k/page.h:1.1.1.2.2.1
--- include/asm-m68k/page.h:1.1.1.2 Wed Dec 11 11:07:56 2002
+++ include/asm-m68k/page.h Mon Dec 16 20:36:48 2002
@@ -100,18 +100,17 @@
/* to align the pointer to the (next) page boundary */
#define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK)
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
+
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
#endif /* !__ASSEMBLY__ */
diff -u include/asm-m68knommu/page.h:1.1.2.1 include/asm-m68knommu/page.h:1.1.2.1.2.1
--- include/asm-m68knommu/page.h:1.1.2.1 Wed Dec 11 11:07:56 2002
+++ include/asm-m68knommu/page.h Mon Dec 16 20:36:48 2002
@@ -51,19 +51,18 @@
/* to align the pointer to the (next) page boundary */
#define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK)
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
+
extern unsigned long memory_start;
extern unsigned long memory_end;
diff -u include/asm-mips/page.h:1.1.1.1 include/asm-mips/page.h:1.1.1.1.6.1
--- include/asm-mips/page.h:1.1.1.1 Wed Dec 11 11:06:01 2002
+++ include/asm-mips/page.h Mon Dec 16 20:36:48 2002
@@ -49,18 +49,16 @@
#define __pgd(x) ((pgd_t) { (x) } )
#define __pgprot(x) ((pgprot_t) { (x) } )
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
#endif /* _LANGUAGE_ASSEMBLY */
diff -u include/asm-parisc/page.h:1.1.1.1 include/asm-parisc/page.h:1.1.1.1.6.1
--- include/asm-parisc/page.h:1.1.1.1 Wed Dec 11 11:06:00 2002
+++ include/asm-parisc/page.h Mon Dec 16 20:36:48 2002
@@ -53,19 +53,18 @@
#define __pgd(x) ((pgd_t) { (x) } )
#define __pgprot(x) ((pgprot_t) { (x) } )
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
+
#ifdef __LP64__
#define MAX_PHYSMEM_RANGES 8 /* Fix the size for now (current known max is 3) */
diff -u include/asm-ppc64/page.h:1.1.1.2 include/asm-ppc64/page.h:1.1.1.2.2.1
--- include/asm-ppc64/page.h:1.1.1.2 Wed Dec 11 11:13:36 2002
+++ include/asm-ppc64/page.h Mon Dec 16 20:36:48 2002
@@ -119,19 +119,18 @@
#define PAGE_BUG(page) do { BUG(); } while (0)
-/* Pure 2^n version of get_order */
-static inline int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
+
#define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
diff -u include/asm-s390/page.h:1.1.1.2 include/asm-s390/page.h:1.1.1.2.2.1
--- include/asm-s390/page.h:1.1.1.2 Mon Dec 16 18:44:31 2002
+++ include/asm-s390/page.h Mon Dec 16 20:36:48 2002
@@ -71,18 +71,16 @@
BUG(); \
} while (0)
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
/*
diff -u include/asm-s390x/page.h:1.1.1.1 include/asm-s390x/page.h:1.1.1.1.6.1
--- include/asm-s390x/page.h:1.1.1.1 Wed Dec 11 11:06:00 2002
+++ include/asm-s390x/page.h Mon Dec 16 20:36:48 2002
@@ -69,18 +69,16 @@
BUG(); \
} while (0)
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
/*
diff -u include/asm-sh/page.h:1.1.1.1 include/asm-sh/page.h:1.1.1.1.6.1
--- include/asm-sh/page.h:1.1.1.1 Wed Dec 11 11:06:01 2002
+++ include/asm-sh/page.h Mon Dec 16 20:36:48 2002
@@ -102,19 +102,18 @@
BUG(); \
} while (0)
-/* Pure 2^n version of get_order */
-static __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
+
#endif
diff -u include/asm-sparc/page.h:1.1.1.2 include/asm-sparc/page.h:1.1.1.2.2.1
--- include/asm-sparc/page.h:1.1.1.2 Wed Dec 11 11:13:36 2002
+++ include/asm-sparc/page.h Mon Dec 16 20:36:48 2002
@@ -147,19 +147,18 @@
#define TASK_UNMAPPED_BASE BTFIXUP_SETHI(sparc_unmapped_base)
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
+
#else /* !(__ASSEMBLY__) */
diff -u include/asm-sparc64/page.h:1.1.1.1 include/asm-sparc64/page.h:1.1.1.1.6.1
--- include/asm-sparc64/page.h:1.1.1.1 Wed Dec 11 11:06:01 2002
+++ include/asm-sparc64/page.h Mon Dec 16 20:36:48 2002
@@ -161,18 +161,16 @@
extern struct sparc_phys_banks sp_banks[SPARC_PHYS_BANKS];
-/* Pure 2^n version of get_order */
-static __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
#endif /* !(__ASSEMBLY__) */
diff -u include/asm-v850/page.h:1.1.2.1 include/asm-v850/page.h:1.1.2.1.2.1
--- include/asm-v850/page.h:1.1.2.1 Wed Dec 11 11:07:56 2002
+++ include/asm-v850/page.h Mon Dec 16 20:36:48 2002
@@ -98,19 +98,18 @@
#define BUG() __bug()
#define PAGE_BUG(page) __bug()
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order (unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
+
#endif /* !__ASSEMBLY__ */
diff -u include/asm-x86_64/page.h:1.1.1.1 include/asm-x86_64/page.h:1.1.1.1.6.1
--- include/asm-x86_64/page.h:1.1.1.1 Wed Dec 11 11:06:01 2002
+++ include/asm-x86_64/page.h Mon Dec 16 20:36:48 2002
@@ -80,19 +80,18 @@
#define PAGE_BUG(page) BUG()
void out_of_line_bug(void);
-/* Pure 2^n version of get_order */
-extern __inline__ int get_order(unsigned long size)
-{
- int order;
+/* Return 'n' in how many 2^n pages are needed to store s bytes.
+** (n == 0 for s == 0)
+*/
+
+#include <asm-generic/page.h>
- size = (size-1) >> (PAGE_SHIFT-1);
- order = -1;
- do {
- size >>= 1;
- order++;
- } while (size);
- return order;
+static __inline__
+int get_order (unsigned long s)
+{
+ return generic_get_order (s);
}
+
#endif /* __ASSEMBLY__ */
--
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my fault]
^ permalink raw reply
* Re: 2.5.52 compile error
From: Steven Cole @ 2002-12-17 21:29 UTC (permalink / raw)
To: Bob Miller; +Cc: rtilley, Linux Kernel
In-Reply-To: <20021217211618.GB1069@doc.pdx.osdl.net>
On Tue, 2002-12-17 at 14:16, Bob Miller wrote:
> On Tue, Dec 17, 2002 at 03:57:01PM -0500, rtilley wrote:
> > Using RH's default *i686.config to build a vanilla 2.5.52 kernel. It keeps
> > returning this error on 2 totally different x86 PCs:
> >
> >
> > drivers/built-in.o: In function `kd_nosound':
> > drivers/built-in.o(.text+0x1883f): undefined reference to `input_event'
[more errors snipped]
> >
> > Where is the fix for this?
> >
> At your finger tips ;-). Turn on CONFIG_INPUT via "Input device support"
> off the main page.
And if you want to use your keyboard or mouse, something similar to the
following may be helpful, depending on your system.
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_INPUT_MISC=y
Steven
^ permalink raw reply
* mdadm -D shows incorrect working devices ?
From: raid @ 2002-12-17 21:22 UTC (permalink / raw)
To: linux-raid
after a failure i recovered using mdadm -A :
mdadm -A /dev/md0 --force /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
/dev/sdf1 /dev/sdg1 /dev/sdh1
i still miss one device in my raid5 (will be there tomorrow)
/proc/mdstat show me :
md0 : active raid5 sdh1[6] sdg1[5] sdf1[4] sde1[3] sdd1[2] sdc1[1] sdb1[0]
820527232 blocks level 5, 64k chunk, algorithm 0 [8/7] [UUUUUUU_]
but mdadm -D /dev/md0 show me incorrect info
look at the ammount of working devices/failed devices
/dev/md0:
Version : 00.90.00
Creation Time : Fri Oct 18 23:11:09 2002
Raid Level : raid5
Array Size : 820527232 (782.51 GiB 840.21 GB)
Device Size : 117218176 (111.78 GiB 120.03 GB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Tue Dec 17 22:12:24 2002
State : dirty, no-errors
Active Devices : 7
Working Devices : 6
Failed Devices : 2
Spare Devices : 0
Layout : left-asymmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
3 8 65 3 active sync /dev/sde1
4 8 81 4 active sync /dev/sdf1
5 8 97 5 active sync /dev/sdg1
6 8 113 6 active sync /dev/sdh1
7 0 0 7 faulty
UUID : 316793d2:5e51db22:3607b944:6aeb5e01
7 devices active/6 working/2 failed ??
but only 1 is failed ?
i restarted about 5 times after recoveringing using mdadm -A
(reboot, so this info should be updated already...)
kernel 2.4.20
mdadm v1.0.1
^ permalink raw reply
* Re: 2.5.52 compile error
From: Richard B. Tilley (Brad) @ 2002-12-17 21:27 UTC (permalink / raw)
To: Bob Miller; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20021217211618.GB1069@doc.pdx.osdl.net>
[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]
CONFIG_INPUT is modular, do I *have* to build it in inorder to compile?
On Tue, 2002-12-17 at 16:16, Bob Miller wrote:
> On Tue, Dec 17, 2002 at 03:57:01PM -0500, rtilley wrote:
> > Using RH's default *i686.config to build a vanilla 2.5.52 kernel. It keeps
> > returning this error on 2 totally different x86 PCs:
> >
> >
> > drivers/built-in.o: In function `kd_nosound':
> > drivers/built-in.o(.text+0x1883f): undefined reference to `input_event'
> > drivers/built-in.o(.text+0x18861): undefined reference to `input_event'
> > drivers/built-in.o: In function `kd_mksound':
> > drivers/built-in.o(.text+0x1890a): undefined reference to `input_event'
> > drivers/built-in.o: In function `kbd_bh':
> > drivers/built-in.o(.text+0x197a2): undefined reference to `input_event'
> > drivers/built-in.o(.text+0x197c1): undefined reference to `input_event'
> > drivers/built-in.o(.text+0x197e0): more undefined references to `input_event'
> > follow
> > drivers/built-in.o: In function `kbd_connect':
> > drivers/built-in.o(.text+0x19d54): undefined reference to `input_open_device'
> > drivers/built-in.o: In function `kbd_disconnect':
> > drivers/built-in.o(.text+0x19d7f): undefined reference to `input_close_device'
> > drivers/built-in.o: In function `kbd_init':
> > drivers/built-in.o(.init.text+0x12c1): undefined reference to
> > `input_register_handler'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> >
> > Where is the fix for this?
> >
> At your finger tips ;-). Turn on CONFIG_INPUT via "Input device support"
> off the main page.
>
> --
> Bob Miller Email: rem@osdl.org
> Open Source Development Lab Phone: 503.626.2455 Ext. 17
> -
> 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/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ 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.