* Kernel for Pentium 4 hyperthreading?
From: Scott Robert Ladd @ 2002-12-15 1:11 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021215005654.GE27658@fs.tum.de>
Okay, I'm going bald even faster than usual.
I've just received a new computer based on a 2.8 GHz Pentium 4 with
hyper-threading enabled. Yes, HT is enabled in the BIOS; yes, /proc/cpuinfo
shows the 'ht' flag; yes, I've compiled 2.4.20 (stock) with SMP and ACPI
enabled.
No, it doesn't work. cat /proc/cpuinfo reports a single CPU.
I've also tried a 2.5.51 kernel -- and it, indeed, does find "both"
processors, listing them in cpuinfo as siblings. Looking at the boot logs,
2.5.51 seems to work just fien with my CPU.
For many reasons, I'd prefer to be running the 2.4.20 kernel (if nothing
else, I'm having trouble getting loadable modules -- the nVidia drivers for
one -- to work on 2.5.51.)
Can 2.4.20 handle a Pentium 4 (not Xeon, mind you) with HT? What could I be
missing in my kernel build?
What is especially frustrating is that the factory-installed Windows XP had
no trouble at all using the HT-enable P4 (until I sent WinXP to the great
bit-bucket in the sky).
Thanks in advance.
..Scott
^ permalink raw reply
* Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Matthew Bell @ 2002-12-15 1:05 UTC (permalink / raw)
To: kai-germaschewski, mwsb; +Cc: linux-parport, linux-kernel
Oh bum. I had it that way originally, for that reason, then left for a while, wondered what I was doing and removed the 'superflous' bit.
+#if defined(CONFIG_ISAPNP) || (defined (MODULE) && defined (CONFIG_ISAPNP_MODULE))
Matthew Bell
----- Original Message -----
From: Kai Germaschewski <kai-germaschewski@uiowa.edu>
Date: Sat, 14 Dec 2002 17:11:49 -0600 (CST)
To: Matthew Bell <mwsb@operamail.com>
Subject: Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
> On Sun, 15 Dec 2002, Matthew Bell wrote:
>
> > This is valid for at least 2.4.20 and earlier; it works for me, and I
> > can't see any exceptional reason why it shouldn't work when ISAPNP is a
> > module.
>
> > --- linux-2.4.19.orig/drivers/net/3c515.c 2002-02-25 19:37:59.000000000 +0000
> > +++ linux-2.4.19/drivers/net/3c515.c 2002-08-03 18:24:05.000000000 +0100
> > @@ -370,7 +370,7 @@
> > { "Default", 0, 0xFF, XCVR_10baseT, 10000},
> > };
> >
> > -#ifdef CONFIG_ISAPNP
> > +#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
> > static struct isapnp_device_id corkscrew_isapnp_adapters[] = {
> > { ISAPNP_ANY_ID, ISAPNP_ANY_ID,
> > ISAPNP_VENDOR('T', 'C', 'M'), ISAPNP_FUNCTION(0x5051),
> [...]
>
> It's really only obvious*ish*: If isapnp is a module but 3c515 built-in,
> you'll get link errors. The real fix for this is to do
>
> +#ifdef __ISAPNP__
>
> which will get all cases right.
>
> --Kai
>
>
--
_______________________________________________
Get your free email from http://mymail.operamail.com
Powered by Outblaze
^ permalink raw reply
* Re: Why does the _DoubleTalk card_ not have a major assigned?
From: Adrian Bunk @ 2002-12-15 1:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: George G. Davis, Jim Van Zandt, device, lkml
In-Reply-To: <Pine.LNX.4.44.0212041646190.775-100000@xanadu.home>
On Wed, Dec 04, 2002 at 04:50:50PM -0500, Nicolas Pitre wrote:
> On Wed, 4 Dec 2002, Adrian Bunk wrote:
>
> > This is indeed true for the Comtrol Rocketport card but there's no
> > major for the DoubleTalk card (and this is the card I wanted to write
> > about).
>
> Maybe because it doesn't need a static major? For funky hardware like the
> Doubletalk for which the number of Linux users worldwide can probably be
> counted on your fingers you can just grep /proc/devices for its allocated
> major and create the /dev node on the fly.
Thanks for your answer, I knew that this might have been a silly
question (and my confusing first mail didn't make it better...).
> Nicolas
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Linux-2.4.20: bug with radeonfb
From: Adrian Bunk @ 2002-12-15 0:56 UTC (permalink / raw)
To: José Luis Tallón; +Cc: linux-kernel
In-Reply-To: <5.1.1.6.0.20021203004621.00b5a770@mail.adv-solutions.net>
On Tue, Dec 03, 2002 at 01:52:09AM +0100, José Luis Tallón wrote:
> Environment: gcc-2.95.4, latest dev tools from Debian "Sarge"( testing )
> Kernel: 2.4.20 + patch-2.4.20-ac1 from ftp.kernel.org
>...
> "No Go's":
> Radeon M7 AGP:
> - Framebuffer: unreadable output ( did work _perfectly_ with
> Linux-2.4.19 ).
> Looks like there's a bug somewhere in the rendering code( kernel
> autodetects and configures a 175x65 framebuffer, as previously):
> output seems to be "misplaced" -- might be a little assumption when
> calculating line offsets.
> Text lines, although bent to the right( 60º angle or so ), look _extremely
> long_ (might be a wrong appreciation)
> "Tux" logo is unrecogniceable too :(
>
> - DRM 4.1( v20020828 ) works nicely with XFree 4.2.1
> - Xvid extension works
>
> dmesg gives this ( double-checked with 2.4.19 ): relevant sections are
> identical to 2.4.19
> ---
> Pentium 4 Mobility - stepping 04
> [...]
> ref_clk=2700, ref_div=12, xclk=16600 from BIOS
> Samsung LTN-1050P1-L02 flatpanel
> DFP 1400x1050 from BIOS
> Radeon M7 LW DDR SGRAM 64MB
> colour framebuffer 175x65
>...
Does it work if you revert the patch against drivers/video/radeonfb.c
that is in -ac?
Does it work in plain 2.4.20 (without the -ac patch)?
> TIA
> Regards,
> J.L.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Zwane Mwaikambo @ 2002-12-15 0:55 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Matthew Bell, linux-parport, linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212141944400.32566-100000@montezuma.mastecende.com>
On Sat, 14 Dec 2002, Zwane Mwaikambo wrote:
> > +#ifdef __ISAPNP__
> >
> > which will get all cases right.
>
> ... but unfortunately thats currently going away ;) to make way for
> CONFIG_PNP
>
> Zwane
>
Someone needs their coffee...
--
function.linuxpower.ca
^ permalink raw reply
* Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Zwane Mwaikambo @ 2002-12-15 0:45 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Matthew Bell, linux-parport, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212141709250.7099-100000@chaos.physics.uiowa.edu>
On Sat, 14 Dec 2002, Kai Germaschewski wrote:
> On Sun, 15 Dec 2002, Matthew Bell wrote:
>
> > This is valid for at least 2.4.20 and earlier; it works for me, and I
> > can't see any exceptional reason why it shouldn't work when ISAPNP is a
> > module.
>
> > --- linux-2.4.19.orig/drivers/net/3c515.c 2002-02-25 19:37:59.000000000 +0000
> > +++ linux-2.4.19/drivers/net/3c515.c 2002-08-03 18:24:05.000000000 +0100
> > @@ -370,7 +370,7 @@
> > { "Default", 0, 0xFF, XCVR_10baseT, 10000},
> > };
> >
> > -#ifdef CONFIG_ISAPNP
> > +#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
> > static struct isapnp_device_id corkscrew_isapnp_adapters[] = {
> > { ISAPNP_ANY_ID, ISAPNP_ANY_ID,
> > ISAPNP_VENDOR('T', 'C', 'M'), ISAPNP_FUNCTION(0x5051),
> [...]
>
> It's really only obvious*ish*: If isapnp is a module but 3c515 built-in,
> you'll get link errors. The real fix for this is to do
>
> +#ifdef __ISAPNP__
>
> which will get all cases right.
... but unfortunately thats currently going away ;) to make way for
CONFIG_PNP
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* Re: Symlink indirection
From: Andrew Walrond @ 2002-12-15 0:41 UTC (permalink / raw)
To: Stephen Wille Padnos; +Cc: linux-kernel
In-Reply-To: <3DFB8B7C.10802@verizon.net>
Hi steve
Stephen Wille Padnos wrote:
>
> What would you expect to happen if you then did:
> echo "d/w" > d/w
>
> Which physical directory would you expect a new file to go into?
>
Using my example:
mkdir a
echo "a/x" > a/x
echo "a/y" > a/y
echo "a/z" > a/z
mkdir b
echo "b/y" > b/y
mkdir c
echo "c/z" > c/z
mkdir d
mount --bind a d
mount --bind --overlay b d
mount --bind --overlay c d
cat d/x
"a/x"
cat d/y
"b/y"
cat d/z
"c/z"
Then...
echo "d/w" > d/w would create a new file in directory a.
echo "d/y" > d/y would replace the file b/y
etc...
Is this sort of thing possible, or are there fundamental reasons that
would make it difficult?
Andrew
^ permalink raw reply
* Re: Re: pci-skeleton duplex check
From: Steffen Persvold @ 2002-12-15 0:37 UTC (permalink / raw)
To: Russell King
Cc: arun4linux, Michael Richardson, netdev, Linux Kernel Mailing List
In-Reply-To: <20021214161446.B23020@flint.arm.linux.org.uk>
On Sat, 14 Dec 2002, Russell King wrote:
> On Sat, Dec 14, 2002 at 08:05:30PM +0530, arun4linux wrote:
> > Interfaces should NEVER change in patch level versions.
> > Just *DO NOT DO IT*.
> > I do agree on this.
>
> Rubbish.
>
> Think about what you've just said. Patch level version changes are
> things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.
>
> You are saying that we shouldn't change any interfaces between (eg)
> 2.5.43 and 2.5.44, but we should change every interface we want to
> change between 2.4.15 and 2.5.0.
>
> This is obviously completely bogus. 2.5 is a _development_ tree.
> Everyone should expect anything, including interfaces to change
> between each development patch level.
>
> > This is a common complaint about linux kernel developers. And this always
> > gives an insecure feeling :-) for the device driver or kernel module
> > programmers.
>
> If interfaces are changed without extremely good reason between two
> _stable_ patch level versions, that would be a bug.
>
There have been a few during 2.4... The alloc_kiovec stuff for instance
and zap_page_range. 2.2 was much more stable.
Interface changes in development series is (or atleast should be to
everyone using linux) a known "feature".
Regards,
--
Steffen Persvold | Scali AS
mailto:sp@scali.com | http://www.scali.com
Tel: (+47) 2262 8950 | Olaf Helsets vei 6
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY
^ permalink raw reply
* Re: new Debian packages
From: Brian May @ 2002-12-15 0:24 UTC (permalink / raw)
To: Les Bell; +Cc: Russell Coker, selinux
In-Reply-To: <OFABDD1FCC.C3C23AF2-ONCA256C90.00007F8A@lesbell.com.au>
On Sun, Dec 15, 2002 at 11:10:06AM +1100, Les Bell wrote:
> The FreeS/WAN developers seem mostly unconcerned by this - their view is
> that the kernel IPSec code is just one small part of a complete IPSec
> implementation; there's also a lot of user-space code for key management,
> authentication via X.509 certificates, etc. which they've been working on
errr.... FreeS/WAN project aren't interested in X.509, X.509 is an extra
unsupported patch to the FreeS/WAN patch (although both are integrated
in the Debian packaging).
I asked (in person) one of the FreeS/WAN developers about this at
OLS2002, and was told that they aren't currently interested in
supporting X.509 and have no plans to support it in the future.
(please correct me if I am mistaken though).
--
Brian May <bam@snoopy.apana.org.au>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: new Debian packages
From: Les Bell @ 2002-12-15 0:10 UTC (permalink / raw)
To: Russell Coker; +Cc: Brian May, selinux
Russell Coker <russell@coker.com.au> wrote:
>>
FreeS/WAN is in a similar situation, it's never going into the main kernel
tree and there's already a replacement for 2.6.
<<
The FreeS/WAN developers seem mostly unconcerned by this - their view is
that the kernel IPSec code is just one small part of a complete IPSec
implementation; there's also a lot of user-space code for key management,
authentication via X.509 certificates, etc. which they've been working on
for a long time now. FWIW, I'm sticking with FreeS/WAN for the time being.
. .
Best,
--- Les Bell, CISSP
[http://www.lesbell.com.au]
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: MCE 7 / Athlon / 2.4.20
From: Dave Jones @ 2002-12-15 0:11 UTC (permalink / raw)
To: Sapan Bhatia; +Cc: linux-kernel, reveillere
In-Reply-To: <20021214222816.A487@enseirb.fr>
On Sat, Dec 14, 2002 at 10:28:16PM +0100, Sapan Bhatia wrote:
> Hi,
>
> I'm using a Compaq Evo N1005v: Athlon 1.5GHz/256MB RAM.
> I get the following MCE when trying to boot 2.4.20, followed by a kernel
> panic:
>
> MCE 7
> Bank: 3
> Code: b40000000000083b
> Addr: 00000001fc0003b3
Ahh, I have the 1015v and I bet it has the same problem.
There are bits of isa space we probe that cause machine checks.
Fixed in 2.4.20-ac, and 2.4.21pre/bitkeeper.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply
* zipdisk file problems
From: Heimo Claasen @ 2002-12-15 0:00 UTC (permalink / raw)
To: linux-newbie
On a Zipdisk-ette, where directories and files had been changed and
shoveled around - both with running DOS and Linux -, some files (jpg.s)
suddenly became inaccessible with a Linux pixel application (in case,
good old XView: it hangs "hard", not only X but the whole machine is
frozen, only way out it with the ugly red buton).
Though from DOS there is no whatsoever access problem, the files
themselves appear integer. And under Linux, the trouble does not seem
to be specific with one distinct file - some re-arrangement of files in
that specific directory would (eventually but not necessarily) make
reappear that total hung-up with another file.
The (internal, SCSI) Zipdrive is mounted as (filesystem-)"type msdos" in
"fstab".
I suspect some pecularities of the DOS/FAT16 filetables. Straight xcopy
to HD, then xcopy back the entire zipdisk (under DOS) on a new or hard
formatted zipdisk does away with the problem. With erasing files or
directories, however, DOS does not really "wipe" an entry in the file
allocation table but merely sets a marker (8-bit) byte for "deleted"
files. Could it be this which irritates the Linux application ?
// Heimo Claasen // <hammer at revobild dot net> // Brussels 2002-12-14
The WebPlace of ReRead - and much to read ==> http://www.revobild.net
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: RAM and swap partition
From: Heimo Claasen @ 2002-12-15 0:00 UTC (permalink / raw)
To: linux-newbie
Ok, ok, Chuck - sure "it depends" ;)
(and oops, hwo do I use a swap _file_ instead of the "prescribed"
partition ?)
From your list, I conclude that it depends on all those six-and-a-half
factors, even if I'm not soooo convinced what for instance, "distro
AND version" (on top of the kernel number), the BogoMIPS or even the
HD speed, would have to do with it.
And then I have this experience with one (notabene experimental) sound
application which just doesn't care for how much swap there is - but
it is a darn memhog in itself: it crashes if the data file (or too many
together) loaded need too much _RAM_, regardless of how large I dimension
the swap.
So this real and practical example would tell me: no swap partition
needed (EXACTLY for this one app.)
Another real-life case is with that not-so-brandnew laptop and its
"small" HD of 2 GB and "poor" RAM (48 MB) installed, where Linux has
to share space with a windoze and a small DOS partition. This runs
vanilla apps in Linux - a GUI + a browser (including the connectivity
gears) + a plug-in pic viewer at most, simultaneously. Here, seen HD
space and RAM available (both hugely enormous, seen from my past-&-present
DOS uses; all real work, including almost all net-work needed, is done
in text mode and in the miniscule DOS compartment), the volume to set
aside for a swap partition is even a "critical" decision.
Then there is one factor which you did not mention but which might be
of decisive importance: if a unit is used by one person, it would most
probably have just one user (and a very few "user accounts" only) and
simultaneous use of different apps would be probably limited or rather,
the user-"system-owner-administrator" could be enabled to establish a
reasonable estimate of the real need for swap space on the perhaps
not-so-enormously-new/big-HD -- _if_ s/he had some ways or indications
for calculating it.
I think this is a reasonable demand, and I'm looking for some means to
answer to this. So, how would I measure how much swap this kernel or
that application (in combination with what GUI, for instance) would
need, in fact ?
> it may be suggested EXACTLY how much swap space you will need.
Hmm, for that laptop for instance, running yet a much too FAT Mandrake 8.2
with kernel 2.4.18 (because Debian would not find the good video driver
for the trickish LCD). I would gladly dish the mem-(and how much swap-?)
hogging KDE and Nutsrape with it; though, regrettably, it must be able to
run X and a SSL-capable net connection.
I understood James' earlier questions quite similar to what I would ask
for this example; and feel the are still not answered:
> "if said user had less than X MB RAM, they will definitely need a swap
> partition"? And what about guidelines for swap partition size in such a
> case: can such be stated as well? Like, say, "if this individual has
> only 32 MB RAM, he should have a 64 MB swap partition" or "if he has 64
> MB RAM he'll only need a 64 MB swap partition"?
<besides>IMNSO too many of the posts especially on this list here -
where I suppose are precisely quite a lot of "single-users" listening,
and quite some who did or want to change away from Winno$ with their
existing, "old" PCs - are geared towards conditions of illimited means
(e.g., permanent/broadband net connection, units with huge mem and dito
HDs); which might well be a misconception.</besides>
// Heimo Claasen // <hammer at revobild dot net> // Brussels 2002-12-14
The WebPlace of ReRead - and much to read ==> http://www.revobild.net
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: [PATCH] kexec for 2.5.51....
From: Ed Tomlinson @ 2002-12-14 23:59 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-kernel, Greg KH
In-Reply-To: <m14r9gv1c8.fsf@frodo.biederman.org>
On December 14, 2002 02:37 pm, Eric W. Biederman wrote:
>
> Hurray! a bug report :)
Feels good huh.
> > One other datum. Without the --append line a kernel booted with kexec
> > hangs when
> >
> > tring to mount the real root - it cannot find the device.
>
> I suspect you want to specify --append="root=/dev/xyz" when calling kexec.
This helps - see below.
> > Am I using kexec correctly? What else can I try? Is there any debug
> > info I can gather?
>
> Generally you want to put kexec -e your shutdown scripts just before
> the call to reboot. And then you can just say: kexec ...
> and the you get a clean system shutdown. Dropping to run level 1
Why not include this info in kexec -h ? Bet it would prevent a few
failure reports...
> before calling kexec tends to get most of the user space shutdown
> called as well. It is definitely a good idea to be certain X is
> shutdown before calling kexec.
droping to init 1, then calling kexec -e (with the root= and the rest
of the appended parms) works and boots 2.5.51 just fine. <grin>
Two more possible additions to the kexec command.
1. kexec -q which returns rc=1 and types the pending selection and
its command/append string if one exists and returns rc=0 if nothing
is pending.
2. kexec -c which clears any pending kernels.
> With respect to USB it is quite possible something in the USB drivers
> does not shutdown correctly on a reboot, and the driver then has trouble
> reinitializing the device.
Very possible since I did not do an init 0/1/6 before the kexec -e. Usb
was probably being asked to do something very unexpected...
> Since you got to the point of mounting root earlier when you did not
> specify anything I wonder if you some of your command line arguments
> made the situation worse.
>
> Which kernel are you booting with kexec anyway?
2.5.51 + fbcon(bk) + usb(bk) + kexec
> This is actually an expected failure mode, but one I have not seen
> much of yet. The new kernel not coming up because the old drivers
> left the hardware in a state the new drivers cannot handle
> Greg kh asked:
>Could you enable CONFIG_USB_DEBUG to hopefully see more debugging
>messages from the uhci driver during boot, so we could narrow this down?
Done. I will see if I get this to reoccur and will send you debug
output.
TIA,
Ed Tomlinson
^ permalink raw reply
* Re: IDE-CD and VT8235 issue!!!
From: AnonimoVeneziano @ 2002-12-14 23:55 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200212142019.14449.black666@inode.at>
Patrick Petermair wrote:
>Hi!
>
>Same problem here. I have addressed this issue several times...so far no
>solution.
>
>My specs:
>MSI KT3 Ultra2 (VT8235)
>TOSHIBA DVD-ROM SD-M1302
>YAMAHA CRW8424E
>
>Kernel 2.4.19:
>The one I'm currently using. It doesn't detect the VT8235 and therefore
>I have no dma. But I can access/mount my DVD without a problem.
>
>Kernel 2.4.20:
>Detects the VT8235 at boot but hangs with my DVD Rom (hdc) --> doesn't
>boot. I have posted my problem here an Alan Cox suggested that I should
>try the -ac tree.
>
>Kernel 2.4.20-ac2:
>Some improvements - It detects the VT8235 at boot, also my DVD and CDRW.
>It boots fine and I have DMA on all my discs. But as soon as I try to
>mount a CD/DVD (mount /cdrom) the system hangs and I get this:
>
>hdc: status timeout: status=0xd1 { Busy }
>hdc: status timeout: error=0x60LastFailedSense 0x06
>hdc: DMA disabled
>hdc: ATAPI reset timed-out, status=0x80
>hdd: DMA disabled
>ide1: reset: success
>hdc: status timeout: status=0x80 { Busy }
>hdc: status timeout: error=0x01IllegalLengthIndication
>hdc: ATAPI reset timed-out, status=0xd1
>ide1: reset: success
>hdc: status timeout: status=0x80 { Busy }
>hdc: status timeout: error=0x01IllegalLengthIndication
>end_request: I/O error, dev 16:00 (hdc), sector 0
>hdc: status timeout: status=0xd0 { Busy }
>
>and so on...
>
>My guess is the DVD-drive. I know many people with the same southbridge
>(VT8235), who have dma since 2.4.20 an no problem at all at boot-time
>or mounting a CD/DVD.
>
>Any hints?
>
>Patrick
>
>-
>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/
>
>
>
Please, anyone help us, I can't live with a 6 MB HD bandwith!!!:-D
Ciao
^ permalink raw reply
* Re: PCMCIA: pre-compiled driver packages
From: Chuck Gelm @ 2002-12-14 23:44 UTC (permalink / raw)
To: Linux Newbie
In-Reply-To: <Pine.LNX.4.50.0212141538300.260-100000@athame.gmpexpress.net>
Hi, Jude: Thanks.
kernel 2.2.19 is coming up on 1 year 9 months. ;-)
I'm compiling kernel 2.4.20 now.
I have found that PCMCIA requires a pcmcia-cs package;
if not the userspace modules, at least the tools.
Here is an excerpt from
http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-HOWTO-2.html#ss2.1
"The kernel PCMCIA code has the same functionality as the driver side
of the pcmcia-cs package. It does not eliminate the need to install
the pcmcia-cs package, since it requires the same user tools
(cardmgr, cardctl, /etc/pcmcia/* files). The drivers in pcmcia-cs can
still be built for 2.4 kernels, so you have a choice of using either
the in-kernel PCMCIA drivers, or the drivers included in pcmcia-cs.
With 2.5 and later kernels, the standalone drivers cannot be used."
I'll try to use the kernel drivers so as to be compatible with
kernel-2.6.x, when it is released.
Later, Chuck
dashielljt wrote:
>
> kernel 2.2.19 is at least two years old. To the best of my knowledge it
> did not and does not provide drivers for any of your pcmcia cards. I have
> never heard any of them being tested for on boot up at any rate. I also
> do not know if any of the more recent kernel releases offer these drivers
> either. Probably your best bet would be to set up a freshmeat.net account
> and subscribe to the newsletters and check them out. It's like windows
> update for linux but far less intrusive.
>
> Jude <dashielljt(at)gmpexpress-dot-net>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-14 23:29 UTC (permalink / raw)
To: Gérard Roudier, Christoph Hellwig; +Cc: James Bottomley, linux-scsi
In-Reply-To: <20021214223934.P3547-100000@localhost.my.domain>
> Btw, people who want to learn about how to design and maintain a smart
> driver interface that can evolve gracefully without breaking driver
> zillions of times should ask Justin how it does this so well with
> FreeBSD/CAM, in my opinion.
>
> Gérard.
Gerard,
The whole reason CAM has been sucessful was that the decision was made,
however painful it was, to completely redo a subsystem to fix the blatent
architectural flaws in it. CAM was only integrated once all of the drivers
were ported and it had received extensive external testing. I don't know
that I or anyone else can do much better with the Linux SCSI layer until
such time that someone decides to just nuke the whole thing and start over.
A hack, on top of a hack, on top of a hack is no way to build a solid
foundation. What's even more frustrating for me is that the hacks show up
in places you never expect and in forms that don't warn you if you are out
of compliance with the "new hack". It makes it very difficult to follow
interface changes successfully.
--
Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* boot_cpu_data problem
From: Manfred Spraul @ 2002-12-14 23:29 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
I ran into two problems with boot_cpu_data:
- boot_cpu_data doesn't contain the common capabilities of all cpus, it
contains the capabilities of the last booted cpu:
head.S is called by the trampoline code, and that overwrites
boot_cpu_data. [Untested due to lack of hardware]
- "mem=nopentium" disables the pse bit, but that is lost when
identify_cpu calls cpuid again.
What about the attached patch?
it creates an __initdata structure for head.S and adds a flag that
informs identify_cpu that pse is disabled.
--
Manfred
[-- Attachment #2: patch-boot --]
[-- Type: text/plain, Size: 2668 bytes --]
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 5
// SUBLEVEL = 51
// EXTRAVERSION =
--- 2.5/arch/i386/kernel/setup.c 2002-12-14 22:57:48.000000000 +0100
+++ build-2.5/arch/i386/kernel/setup.c 2002-12-15 00:23:06.000000000 +0100
@@ -48,6 +48,9 @@
*/
char ignore_irq13; /* set if exception 16 works */
+/* cpu data as detected by the assembly code in head.S */
+struct cpuinfo_x86 early_cpu_data = { 0, 0, 0, 0, -1, 1, 0, 0, -1 };
+/* common cpu data for all cpus */
struct cpuinfo_x86 boot_cpu_data = { 0, 0, 0, 0, -1, 1, 0, 0, -1 };
unsigned long mmu_cr4_features;
@@ -87,6 +90,7 @@
extern int root_mountflags;
extern char _text, _etext, _edata, _end;
extern int blk_nohighio;
+extern int pse_disable;
void __init visws_get_board_type_and_rev(void);
unsigned long saved_videomode;
@@ -523,6 +527,7 @@
if (!memcmp(from+4, "nopentium", 9)) {
from += 9+4;
clear_bit(X86_FEATURE_PSE, boot_cpu_data.x86_capability);
+ pse_disable = 1;
} else if (!memcmp(from+4, "exactmap", 8)) {
from += 8+4;
e820.nr_map = 0;
@@ -837,6 +842,7 @@
{
unsigned long max_low_pfn;
+ memcpy(&boot_cpu_data, &early_cpu_data, sizeof(early_cpu_data));
pre_setup_arch_hook();
early_cpu_init();
--- 2.5/arch/i386/kernel/cpu/common.c 2002-11-20 19:13:03.000000000 +0100
+++ build-2.5/arch/i386/kernel/cpu/common.c 2002-12-15 00:00:45.000000000 +0100
@@ -42,6 +42,7 @@
}
__setup("cachesize=", cachesize_setup);
+int pse_disable __initdata = 0;
#ifndef CONFIG_X86_TSC
static int tsc_disable __initdata = 0;
@@ -313,6 +314,9 @@
if ( tsc_disable )
clear_bit(X86_FEATURE_TSC, c->x86_capability);
+ if ( pse_disable )
+ clear_bit(X86_FEATURE_PSE, c->x86_capability);
+
/* FXSR disabled? */
if (disable_x86_fxsr) {
clear_bit(X86_FEATURE_FXSR, c->x86_capability);
--- 2.5/arch/i386/kernel/head.S 2002-12-14 10:06:55.000000000 +0100
+++ build-2.5/arch/i386/kernel/head.S 2002-12-15 00:05:33.000000000 +0100
@@ -23,10 +23,10 @@
#define NEW_CL_POINTER 0x228 /* Relative to real mode data */
/*
- * References to members of the boot_cpu_data structure.
+ * References to members of the early_cpu_data structure.
*/
-#define CPU_PARAMS boot_cpu_data
+#define CPU_PARAMS early_cpu_data
#define X86 CPU_PARAMS+0
#define X86_VENDOR CPU_PARAMS+1
#define X86_MODEL CPU_PARAMS+2
--- 2.5/include/asm-i386/processor.h 2002-11-30 10:52:22.000000000 +0100
+++ build-2.5/include/asm-i386/processor.h 2002-12-14 23:52:40.000000000 +0100
@@ -77,6 +77,7 @@
*/
extern struct cpuinfo_x86 boot_cpu_data;
+extern struct cpuinfo_x86 early_cpu_data;
extern struct tss_struct init_tss[NR_CPUS];
#ifdef CONFIG_SMP
^ permalink raw reply
* Re: Reiserfs with Samba vs NetApp Filer (purely performance)
From: Hans Reiser @ 2002-12-14 23:21 UTC (permalink / raw)
To: Ragnar Kjørstad
Cc: Richard Sharpe, darren, 'Russell Coker', reiserfs-list
In-Reply-To: <20021215001126.J2727@vestdata.no>
Ragnar Kjørstad wrote:
>On Sat, Dec 14, 2002 at 02:34:06PM -0800, Richard Sharpe wrote:
>
>
>>If those are your choices, then I would rank them:
>>
>> NetApp F870, Linux with ReiserFS and Samba, Win2K
>>
>>John Terpstra has done some testing with a modified cifs_bm which confirms
>>that Linux with EXT2/3 or ReiserFS outperforms Win2K on the same hardware.
>>
>>However, my testing of the NetApp suggests it will outperform the other
>>two choices.
>>
>>
>
>What kind of benchmarks, and what were the results?
>
>
>
>>If you choose to use Samba, you will want to make sure that the sendfile
>>stuff is implemented. Unfortunately, the directory indexing in Reiser does
>>not help that much a lot of the time because Samba is forced to do
>>directory scans because it has to implement case-independent
>>lookups/searches.
>>
>>
>
>Isn't that an configuration-option?
>
>As a sidenote, I think it wouldn't be too hard to make reiserfs
>optionally case-insensitive, but still able to use indexes. Perhaps it
>would even be possible to have two virtual directories pr traditional
>directory? one that has a regular index and one that has a
>case-insensitive index. Of course this is not relevant for the
>right-here right-now choice of fileservers, but....
>
>
>
>
There is quite a lot that could be done to optimize for Samba, but
nobody is sponsoring it unfortunately. Seems like some money could be
made by a clever appliance vendor....
^ permalink raw reply
* Re: Reiserfs with Samba vs NetApp Filer (purely performance)
From: Ragnar Kjørstad @ 2002-12-14 23:11 UTC (permalink / raw)
To: Richard Sharpe
Cc: Hans Reiser, darren, 'Russell Coker', reiserfs-list
In-Reply-To: <Pine.LNX.4.33.0212141429010.2681-100000@ns.aus.com>
On Sat, Dec 14, 2002 at 02:34:06PM -0800, Richard Sharpe wrote:
> If those are your choices, then I would rank them:
>
> NetApp F870, Linux with ReiserFS and Samba, Win2K
>
> John Terpstra has done some testing with a modified cifs_bm which confirms
> that Linux with EXT2/3 or ReiserFS outperforms Win2K on the same hardware.
>
> However, my testing of the NetApp suggests it will outperform the other
> two choices.
What kind of benchmarks, and what were the results?
> If you choose to use Samba, you will want to make sure that the sendfile
> stuff is implemented. Unfortunately, the directory indexing in Reiser does
> not help that much a lot of the time because Samba is forced to do
> directory scans because it has to implement case-independent
> lookups/searches.
Isn't that an configuration-option?
As a sidenote, I think it wouldn't be too hard to make reiserfs
optionally case-insensitive, but still able to use indexes. Perhaps it
would even be possible to have two virtual directories pr traditional
directory? one that has a regular index and one that has a
case-insensitive index. Of course this is not relevant for the
right-here right-now choice of fileservers, but....
--
Ragnar Kjørstad
^ permalink raw reply
* Re: new Debian packages
From: Brian May @ 2002-12-14 23:13 UTC (permalink / raw)
To: Russell Coker; +Cc: selinux
In-Reply-To: <200212142245.15413.russell@coker.com.au>
On Sat, Dec 14, 2002 at 10:45:15PM +0100, Russell Coker wrote:
> That'll keep you busy!
The main reason I haven't been racing to do 2.4.20!
> I've given up on EVMS as Linus is not accepting the full EVMS thing and they
> have been forced to radically change their plans. As this happened before I
> got around to doing anything serious with EVMS I decided to skip it until
> it's all settled down.
EVMS looks pretty good, the reason it wouldn't work on my test
machine was because the lvm EVMS module wasn't going to autoload.
All EVMS modules need to be manually loaded, it appears.
I will be interested to see what happens with EVMS now, apparently
the user front ends will remain identical, just the backend will use
existing kernel components, like LVM2 and device mapper, instead
of "re-inventing the wheel".
> FreeS/WAN is in a similar situation, it's never going into the main kernel
> tree and there's already a replacement for 2.6.
Agreed here, it may be that I never get FreeS/WAN working as a result
(although I came pretty close on my last attempt).
> I've been thinking that it may be time to start moving some of my machines to
> 2.5.x. I think that 2.5.x development has slowed down enough for me to port
> the LSM patches between kernels.
>
> I'm just looking at 2.5 now. It appears to have IPSec, it has device-mapper
> (not sure if this means LVM2 is in), it has ACLs, and lots of other nice
> things such as CryptoAPI.
My impression was that LVM2 was in already, but I might be mistaken.
> Maybe next time I run SE play machines I'll run one on a 2.4.x kernel and one
> on 2.5.x (Sun gave me a RaQ to use for this sort of thing - thanks Sun).
>
> > I am not sure if there are version of these patches that will work
> > with 2.4.20 yet, that is something I need to investigate (DOV at least
> > is suppost to have been integrated into the kernel by now).
>
> What is DOV?
Data-Over-Voice, an ugly hack for ISDN in Australia to get cheaper ISDN
call rates (Telstra thinks it is a voice call, not a data call...).
Getting back to SE-Linux, and my private archive, I have been
experimentating with DAK (the official Debian archive scripts).
I have almost entirely converted my archive to use these scripts
instead of my own (which had certain limitations that were going
to be hard to fix).
This means that I can:
- Support automatic package installs, without manual intervention.
- Better checks new files, eg. to make sure the version is correct
and there is a copy of the *.orig.tar.gz file available.
- Support automatically deleting obsolete files.
- Cryptographic signing of Release file, which can be used to ensure
that all other files in the archive are valid.
- Support automatic building on other architectures (except
I don't have any spare non-i386 computers to do this...).
- Automatic notifications to a mailing list for new uploads
(would anybody be interested in subscribing to such a mailing list?).
- There are 3 distributions: unstable (where new uploads will go),
testing (only there because some of the scripts stupidly hardcode it),
and stable (where packages go when there appear to be working).
What I still have to do:
- Create announce mailing list?
- Fix packages that DAK rejects, due to technical errors in packaging.
- Learn who to move packages from "unstable" to "stable"
(I suspect I know how; not tested yet).
- Think of some use for the "testing" distribution.
--
Brian May <bam@snoopy.apana.org.au>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: New device-mapper patchset for 2.5.51
From: Paul @ 2002-12-14 23:17 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linux Mailing List, lvm-devel, linux-lvm
In-Reply-To: <20021213115014.GA15675@reti>
Joe Thornber <joe@fib011235813.fsnet.co.uk>, on Fri Dec 13, 2002 [11:50:14 AM] said:
> If anyone was experiencing problems with dm could they please try this
> patchset and give me feedback.
>
> Thanks,
>
> - Joe
>
>
>
> http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-3.tar.bz2
>
Hi;
I havent tried 2.5.51 vanila, but 2.5.51 with dm-3 patch
is working well so far for me on LVM system. (All other 2.5
kernels tried would hit a BUG()-- already reported.)
If anyone wants me to recommend some sort of stress test
let me know; Ive simpley constructed and populated several
fileystems, md5sum'ed all the files, bzip2'd them, rm'd them,
etc. Then several hours of looping kernel compiles.
Thanks for the work of the contributers.
Paul
set@pobox.com
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: James Simmons @ 2002-12-14 23:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0212131707350.6750-100000@home.transmeta.com>
> > 1) Its the same place on the screen or a different place every time?
>
> I think it's at the last line of the screen every time.
I think I might now what the problem is. scrup is using memcpy even when
the memory areas src, dest overlap. The key is to use memmove which
handles overlapping memory gracefully. Tell me if the following patch
works for you.
--- vt.c.orig Sat Dec 14 13:32:42 2002
+++ vt.c Sat Dec 14 13:34:46 2002
@@ -262,7 +262,7 @@
return;
d = (unsigned short *) (origin+video_size_row*t);
s = (unsigned short *) (origin+video_size_row*(t+nr));
- scr_memcpyw(d, s, (b-t-nr) * video_size_row);
+ scr_memmovew(d, s, (b-t-nr) * video_size_row);
scr_memsetw(d + (b-t-nr) * video_num_columns, video_erase_char, video_size_row*nr);
}
^ permalink raw reply
* Re: i4l dtmf errors
From: Kai Germaschewski @ 2002-12-14 23:14 UTC (permalink / raw)
To: Wolfgang Fritz; +Cc: linux-kernel
In-Reply-To: <atg5jv$d73$1@fritz38552.news.dfncis.de>
On Sat, 14 Dec 2002, Wolfgang Fritz wrote:
> > it seems isdn4linux detects DTMF tones from normal speach. This is
> > rather annoying when using i4l for voice with Asterisk.org. This is
> > tested on all recent kernels
>
> The DTMF detection is broken since kernel 2.0.x. I have a patch for a
> 2.2 kernel which may manually be applied 2.4 kernels with some manual
> work. It fixes an overflow problem in the goertzel algorithm (which
> does the basic tone detection) and changes the algorithm to detect the
> DTMF pairs. If interested, I can try to recover that patch.
If you dig out that patch and submit it (to me), I'm pretty sure there's
a good chance of it going into the official kernel. ISTR there was talk
about that earlier, but nothing ever happened.
--Kai
^ permalink raw reply
* Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Kai Germaschewski @ 2002-12-14 23:11 UTC (permalink / raw)
To: Matthew Bell; +Cc: linux-parport, linux-kernel
In-Reply-To: <20021214201220.31330.qmail@operamail.com>
On Sun, 15 Dec 2002, Matthew Bell wrote:
> This is valid for at least 2.4.20 and earlier; it works for me, and I
> can't see any exceptional reason why it shouldn't work when ISAPNP is a
> module.
> --- linux-2.4.19.orig/drivers/net/3c515.c 2002-02-25 19:37:59.000000000 +0000
> +++ linux-2.4.19/drivers/net/3c515.c 2002-08-03 18:24:05.000000000 +0100
> @@ -370,7 +370,7 @@
> { "Default", 0, 0xFF, XCVR_10baseT, 10000},
> };
>
> -#ifdef CONFIG_ISAPNP
> +#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
> static struct isapnp_device_id corkscrew_isapnp_adapters[] = {
> { ISAPNP_ANY_ID, ISAPNP_ANY_ID,
> ISAPNP_VENDOR('T', 'C', 'M'), ISAPNP_FUNCTION(0x5051),
[...]
It's really only obvious*ish*: If isapnp is a module but 3c515 built-in,
you'll get link errors. The real fix for this is to do
+#ifdef __ISAPNP__
which will get all cases right.
--Kai
^ 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.