* (2.4) ext3 - commit=NNN overridden by laptopmode (bdflush)
From: Micha Feigin @ 2004-01-28 23:30 UTC (permalink / raw)
To: lkml
When looking into the ext3 commit code I saw that it has a commit=NNN
mount option for specifying the log update time (same as in 2.6). The
problem is that this value is overridden by the laptopmode code that
was added which uses the value of get_buffer_flushtime which takes its
value from bdflush, which makes that option obsolete.
It looks to me that the bdflush code should be taken back out of the
ext3 code.
I don't mind doing it but only if there is interest.
^ permalink raw reply
* Re: Typo (Re: [PATCH] i2c driver fixes for 2.6.2-rc2)
From: Greg KH @ 2004-01-28 23:23 UTC (permalink / raw)
To: David Martínez Moreno; +Cc: linux-kernel, sensors
In-Reply-To: <200401281408.34364.ender@debian.org>
On Wed, Jan 28, 2004 at 02:08:34PM +0100, David Martínez Moreno wrote:
> El Miércoles, 28 de Enero de 2004 00:34, Greg KH escribió:
> > + dev_err(&adapter->dev, "Unrecgonized version/stepping 0x%02x"
> > + " Defaulting to LM85.\n", verstep);
>
> Hello, Greg.
>
> Just noticed, please s,recgonized,recognized,g all over the file.
Care to send me a spelling fix patch?
thanks,
greg k-h
^ permalink raw reply
* RE: MPC852 suppor
From: Kerl, John @ 2004-01-28 23:27 UTC (permalink / raw)
To: 'peter.grubmaier@chello.at', linuxppc-embedded
If you mean the FEC, then yes, this has been supported
for some time.
-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]
Sent: Wednesday, January 28, 2004 4:26 PM
To: linuxppc-embedded@lists.linuxppc.org
Subject: MPC852 suppor
Hi,
I just wanted to ask if somebody
knows wether MPC852 (especially
its 10/100Mbit ethernet IF )
is already supported in 2.4 or 2.6 kernel
Thanks in advance
Peter
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* MPC852 suppor
From: peter.grubmaier @ 2004-01-28 23:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I just wanted to ask if somebody
knows wether MPC852 (especially
its 10/100Mbit ethernet IF )
is already supported in 2.4 or 2.6 kernel
Thanks in advance
Peter
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* MPC852 suppor
From: peter.grubmaier @ 2004-01-28 23:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I just wanted to ask if somebody
knows wether MPC852 (especially
its 10/100Mbit ethernet IF )
is already supported in 2.4 or 2.6 kernel
Thanks in advance
Peter
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: NetBSD port and a couple of remarks
From: Andi Kleen @ 2004-01-28 23:24 UTC (permalink / raw)
To: Kip Macy; +Cc: Ian.Pratt, xen-devel, lm
In-Reply-To: <20040128150607.M49402@demos.bsdclusters.com>
On Wed, 28 Jan 2004 15:10:08 -0800 (PST)
Kip Macy <kmacy@fsmware.com> wrote:
> Well, then Larry needs to clarify the license. However, he has received
> so much pointless criticism over the years for what in end effect was
> meant to be a favor to Linus that I wouldn't be surprised if he didn't
> consider it worth his while.
He won't do it. This nasty paragraph was actually added quite late and subject
to much discussion.
At least for me it tipped over the BitKeeper license from merely being annoying
(OpenLogging for my test trees etc.) to totally unacceptable. Of course you
can ignore it and hope he or whoever owns BitKeeper at some point won't sue you, but I
wouldn't bet on that.
-Andi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Need help recovering lost partitions
From: Matt Stegman @ 2004-01-28 23:22 UTC (permalink / raw)
To: dan; +Cc: reiserfs-list
In-Reply-To: <20040128143848.27765.h003.c001.wm@mail.ngenllc.com.criticalpath.net>
Hmmm.
It seems that mkreiserfs leaves the first 64kB of the partition blank.
The magic is "ReIsEr2Fs", and it is bytes 53 - 61 in the 17th block (the
filesystem blocksize being 4kB).
I imagine there's a GUID in the superblock you could also look at, but
I'll have to go looking for the format. This is just gleaned from
`od -c /dev/hda1`.
So the quickly written, but slowly executed way to find this is
(nnn is the number of 4kB blocks your disk has):
for n in `seq 0 nnn`; do
magic=`dd if=/dev/hda bs=1 skip=$((4096 * $n + 52)) count=9 2>/dev/null`
if [ "$magic" == "ReIsEr2Fs" ]; then
echo Block $n \(sector $(($n * 8))\) is Reiserfs magic block
fi
done
If you're good with C, you could probably whip up a single program to do
this which will work much faster (doesn't have the overhead of starting
new processes to read each block).
Now each of the listed sectors in the output (minus 64kB; remember the
blank spot) could be a starting sector for the filesystem. You should
have some idea how big your partitions were; do some math to figure out if
any numbers are unlikely to be the right blocks.
This isn't a complete answer for your problem. I may have skipped
over some things that I assume you know already. And, of course, I may
just be wrong.
And never underestimate which blocks may have been overwritten. Even if
you do manage to locate and recreate all your old partitions, you may not
be able to get any data back. And as Phil said, you should work from a
backup; if at all possible, STOP WRITING TO THE ORIGINAL DISK.
There may even be data recovery places who do this sort of thing
professionally.
--
Matt Stegman
On Wed, 28 Jan 2004 dan@ngenllc.com wrote:
> So how can I scan the partition for the old
> superblocks? gpart and parted weren't picking them up,
> but I know they were there. And the 6GB of data it
> found is much less then the size of the partition
> (50GB), which makes me think that some data might still
> be there (i.e. only 100 * (6/50) % of the data could
> have been overwritten).
>
> -Dan
^ permalink raw reply
* DNAT based on domain name instead of IP address
From: Glen Lee Edwards @ 2004-01-28 23:22 UTC (permalink / raw)
To: netfilter
I have several domains that use the same IP address. Can I DNAT them to
different servers based on domain name instead of IP address using
iptables? I've tried the following, but it isn't working:
iptables -t nat -A PREROUTING -p tcp -d 1st.domain.com --dport 80 -j
DNAT --to-destination 192.168.1.12:80
iptables -t nat -A PREROUTING -p tcp -d 2nd.domain.com --dport 80 -j
DNAT --to-destination 192.168.1.13:80
Everything is being forwarded to 192.168.1.12 no matter which domain is
used. It appears that the domains are first being translated into the
IP address, which is used instead.
Glen
^ permalink raw reply
* Re: PNP depends on ISA ? (2.6.2-rc2
From: Micha Feigin @ 2004-01-28 23:16 UTC (permalink / raw)
To: linux-kernel; +Cc: Adam Belay, Micha Feigin
In-Reply-To: <20040126161746.GA3180@neo.rr.com>
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
On Mon, Jan 26, 2004 at 04:17:46PM +0000, Adam Belay wrote:
> On Mon, Jan 26, 2004 at 09:31:44PM +0200, Micha Feigin wrote:
> > I was wondering why pnp depends on isa being selected in 2.6.2-rc2, is
> > pnp really only relevant to isa? What happens with pci etc. ?
> > This may explain why using pnpbios locks up my machine (at least as of 2.6.0-test9).
>
> Yes, it only is related to isa devices, but they include onboard devices
> such as serial ports. It will, however, prevent resource conflicts
> between pci and system devices, especially with unusual configurations.
> Does using pnpbios cause your machine to lockup at boot? If so, around
> where does it occur? DMI information would also be useful for blacklisting
> purposes.
>
I just checked again with 2.6.2-rc2. It occurs right after pnpbios
starts up. I wrote the oops down by hand since the computer went into a
hard lockup (no sysrq key), but couldn't get any results out of
ksymoops for some reason (maybe I am misusing it, any way to disable
pnpbios on a kernel compiled with so I can run it from the running
kernel?).
I attached the oops log and the dmi data (didn't know what is needed of
it).
> Thanks,
> Adam
>
[-- Attachment #2: dump.txt --]
[-- Type: text/plain, Size: 662 bytes --]
pnpbios: scanning system for pnpbios support ...
pnpbios: found pnp bios instellation structure at 0xc00f7760
pnpbios: pnp bios version 1.0, entry 0xf0000:0xaad2, dseg 0x400
general protection fault: 0000 [#1]
cpu: 0
eip: 0098:[<00003fb8>] not tainted
eflags: 00010082
eip is at 3fb8
[...]
process swapper (pid: 1, threadinfo=cffa8000 task=cffa38c0)
stack: 00001002 0002000f 556a0000 8d350000 541c0000 8d2fc65c c64d0c40 0000005a
9e829e96 00008d2e 020b000f 0000bade 9231cc70 cc70c520 003fcbad 00010000
67df0000 0007c020 02120000 1f0e0000 50000000 0000c129 ff380000 0246c037
call trace:
code: bad eip value
<0> kernel panic: attempted to kill init!
[-- Attachment #3: dmi_data.bz2 --]
[-- Type: application/octet-stream, Size: 2949 bytes --]
^ permalink raw reply
* Re: [Bluez-devel] [PATCH] Bluetooth address specific device configuration
From: Achim Bohnet @ 2004-01-28 23:16 UTC (permalink / raw)
To: BlueZ Mailing List
In-Reply-To: <1075317841.553.22.camel@akka.yeti.nocrew.org>
On Wednesday 28 January 2004 20:24, Fredrik Noring wrote:
> ons 2004-01-28 klockan 19.56 skrev Fredrik Noring:
> > device 00:11:22:33:44:55
> > {
> > # Device options for bdaddr 00:11:22:33:44:55...
> > }
>
> Btw., a variation on the theme is to allow:
>
> device hci0
> {
> # Device options for interface hci0...
> }
>
> I don't know which one is most useful or if both should be allowed.
I've a laptop with buildin bt and an external bt stick. It depends on the
order I switch internal one on or connect the stick what interface is
assigned to the same hardware. If there is a need (no idea yet I'm
a bt newbie) for this feature selection by bdaddr is therefore useful
to support. Selection by interface would be useless for me.
On the other hand if I ever take the another identical stick with me
by accident, bdaddr would be different and the settings would not
apply without a notice. Maybe a
device default
{
complain loudly
}
is useful ;)
Achim
>
> Fredrik
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- reddy@lion.austin.ibm.com
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* Re: [parisc-linux] fyi: parted now creates parisc boot partitions
From: Carlos O'Donell @ 2004-01-28 23:14 UTC (permalink / raw)
To: Richard Hirst; +Cc: parisc-linux, debian-hppa
In-Reply-To: <20040128212524.GD17946@sleepie.demon.co.uk>
On Wed, Jan 28, 2004 at 09:25:24PM +0000, Richard Hirst wrote:
> As of parted-1.6.6-7 from your debian mirror you can now use it to set a
> partition type to 'F0' for palo use. This is done via "set N palo on",
> where N is the partition number. Thanks to Sven Luther for accepting my
> patch and uploading.
Cool!
c.
^ permalink raw reply
* Re: [parisc-linux] fyi: parted now creates parisc boot partitions
From: Carlos O'Donell @ 2004-01-28 23:14 UTC (permalink / raw)
To: Richard Hirst; +Cc: parisc-linux, debian-hppa
In-Reply-To: <20040128212524.GD17946@sleepie.demon.co.uk>
On Wed, Jan 28, 2004 at 09:25:24PM +0000, Richard Hirst wrote:
> As of parted-1.6.6-7 from your debian mirror you can now use it to set a
> partition type to 'F0' for palo use. This is done via "set N palo on",
> where N is the partition number. Thanks to Sven Luther for accepting my
> patch and uploading.
Cool!
c.
^ permalink raw reply
* Problem compiling for linux 2.6
From: Giuliano Pochini @ 2004-01-28 23:14 UTC (permalink / raw)
To: Alsa-devel
It fails at line #113 of /Makefile :
@for d in $(SUBDIRS); do if ! $(MAKE) -C $$d prepare; then exit 1; fi; done
I have no idea why $(SUBDIRS) is an empty string:
[Giu@Jay alsa-driver-1.0.2]$ ./cvscompile --with-cards=powermac --with-isapnp=no --with-sequencer=no --with-oss=no --with-kernel=/opt/KernelSrc/l26 --with-debug=full
[...]
copying file alsa-kernel/core/memalloc.c
patching file memalloc.c
/bin/sh: -c: line 1: syntax error near unexpected token `;'
/bin/sh: -c: line 1: `for d in ; do make -C $d prepare; done'
make[1]: *** [prepare] Error 2
make[1]: Leaving directory `/home/Giu/soft/alsa-driver-1.0.2/acore'
make: *** [dep] Error 1
[Giu@Jay alsa-driver-1.0.2]$ uname -a
Linux Jay 2.6.2-rc1-ben1 #2 SMP Wed Jan 28 22:19:17 CET 2004 ppc unknown
I'm using ALSA-1.0.2 after it was reuploaded. With linux 2.4 is compile just
fine as usual. I'm using 2.6 for the first time... maybe I forgot to
install/update something. :)
--
Giuliano.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* RE: [PATCH] cpqarray update
From: Wiran, Francis @ 2004-01-28 23:10 UTC (permalink / raw)
To: Greg KH, Hollis Blanchard, Marcelo Tosatti
Cc: Jeff Garzik, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Ok. Here's the patch for that. At least until vio_module_init comes :)
thanks
-francis-
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, January 28, 2004 11:41 AM
> To: Hollis Blanchard
> Cc: Jeff Garzik; Linux Kernel Mailing List; Wiran, Francis
> Subject: Re: [PATCH] cpqarray update
>
>...
> Well, changing it back to pci_register_driver() and actually checking
> the return value would be a good idea :)
>
> thanks,
>
> greg k-h
>
[-- Attachment #2: cpqarray_pci_unregister.patch --]
[-- Type: application/octet-stream, Size: 638 bytes --]
* Checks the rc of pci_register_driver and unregister when necessary
drivers/block/cpqarray.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
--- linux-2.4.24/drivers/block/cpqarray.c~cpqarray_pci_unregister Wed Jan 28 16:56:39 2004
+++ linux-2.4.24-root/drivers/block/cpqarray.c Wed Jan 28 17:01:10 2004
@@ -623,7 +623,8 @@ int __init cpqarray_init(void)
/* detect controllers */
printk(DRIVER_NAME "\n");
- pci_register_driver(&cpqarray_pci_driver);
+ if (!pci_register_driver(&cpqarray_pci_driver))
+ pci_unregister_driver(&cpqarray_pci_driver);
cpqarray_eisa_detect();
for(i=0; i< MAX_CTLR; i++) {
_
^ permalink raw reply
* Re: [parisc-linux] RE: [parisc-linux-cvs] linux-2.6 carlos
From: Carlos O'Donell @ 2004-01-28 23:11 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
In-Reply-To: <400CB8A1000067CB@ocpmta3.freegates.net>
On Wed, Jan 28, 2004 at 03:00:48PM +0100, Joel Soete wrote:
> Hi all,
>
> This boot fine on the b180 (32bit kernel), the b2k (32bit kernel only even
> with CONFIG_PA20 is Ok but failed with 64bit kernel?) and N4000-55 (same
> 64bit kernel build with my own kgcc-3.3.3 :)).
>
> Any way this last test set aside any pb with _my_ gcc compiler :).
Undo the patch, rebuild, and see if it still fails?
Could you explain more about the failure?
c.
^ permalink raw reply
* Re: NetBSD port and a couple of remarks
From: Kip Macy @ 2004-01-28 23:10 UTC (permalink / raw)
To: Andi Kleen; +Cc: Ian.Pratt, xen-devel, lm
In-Reply-To: <20040128235938.7f44f970.ak@suse.de>
On Wed, 28 Jan 2004, Andi Kleen wrote:
> This one is the killer.
For the individual in question, certainly.
>
> If you ever touched the source of any VCS or work for a company who might ship
> one (and many big software companies have similar programs) then you cannot use it.
> Also it is vague enough that you could basically get sued anytime. They just
> have to define some product you're involved in as "competing with bitkeeper"
Well, then Larry needs to clarify the license. However, he has received
so much pointless criticism over the years for what in end effect was
meant to be a favor to Linus that I wouldn't be surprised if he didn't
consider it worth his while.
> Who knows, maybe Xen will compete with some obscure feature of BitKeeper at some point?
I wholly doubt it.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Is there a way to keep the 2.6 kjournald from writing to idle disks? (to allow spin-downs)
From: Micha Feigin @ 2004-01-28 23:06 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <4017B98C.2040603@isg.de>
On Wed, Jan 28, 2004 at 02:30:52PM +0100, Lutz Vieweg wrote:
> Bart Samwel wrote:
>
> >>Well, it's the o.p. system, not mine, but I don't see how noatime will
> >>help him, the atime shouldn't change unless he's doing disk access, and
> >>if he's doing disk access the disk will spin up anyway.
>
> That's what I thought, too... and I really killed everything that I could
> imagine accessing the disk... but...
>
> >If something really is accessing the drive, noatime might still help as
> >long as the accesses are from the cache.
>
> ... that really helped! I'm kind of surprised, since I didn't use noatime
> before the update, and I still don't know of any process that might do
> the reading, but since mounting / with noatime helped, I'm happy for now.
>
> My curiosity isn't completely gone, though, so maybe one day I'll try to
> find out who-is-trying-to-read-what, "find -atime ..." didn't reveal the
> secret
> yet.
>
It might help you find the culprit. There is a laptopmode patch
for 2.6. If you echo a number n larger then 1 into
/proc/sys/vm/laptopmode it will dump the first n disk accesses to the
console (The docs that come with the patch have the complete
description).
> Regards,
>
> Lutz Vieweg
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: NFS: giant filename in readdir
From: Trond Myklebust @ 2004-01-28 23:06 UTC (permalink / raw)
To: Jussi Hamalainen; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.58.0401272233490.10626@mir.senv.net>
På ty , 27/01/2004 klokka 21:53, skreiv Jussi Hamalainen:
> Both boxes have an almost identical setup of Slackware 9.1 and were
> running 2.4.23-pac1+security bugfixes. The boxes are connected to the
> same switch and VLAN. They mount filesystems from each other (yeah, I
> know cross-mounting with NFS is a bad idea...) and the problem
> occurred on both servers simultaineously.
>
> The mounts look like this:
>
> mir:/home on /home type nfs
> (rw,rsize=8192,wsize=8192,hard,intr,lock,addr=XXX)
> mir:/archive on /archive type nfs
> (rw,rsize=8192,wsize=8192,soft,intr,addr=XXX)
>
> sputnik:/var/spool/mail on /var/spool/mail type nfs
> (rw,rsize=8192,wsize=8192,hard,intr,lock,nfsvers=2,addr=XXX)
> sputnik:/files on /files type nfs
> (rw,rsize=8192,wsize=8192,soft,intr,nfsvers=2,addr=XXX)
Any info forthcoming on the filesystem you used and/or a binary tcpdump
demonstrating the problem? (remember to use a large snaplen in the
tcpdump - something like "-s 9000").
Does the problem still occur when you change "soft" to "hard"? Note that
the default setting for "retrans" as set by the nfs-utils "mount"
program is way too low for "soft" on UDP.
Cheers,
Trond
BTW: 2.4.23 has no readdir changes at all compared to 2.4.21. I've no
idea WTF 2.4.23-pac1 contains...
^ permalink raw reply
* Re: p4_clockmod or speedstep_ich | acpi?
From: Marcus Grando @ 2004-01-28 23:06 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: Ducrot Bruno, cpufreq
In-Reply-To: <20040128224106.GA5987@dominikbrodowski.de>
[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]
Now it's work.
I Attach my new dmesg.
Regards
Dominik Brodowski wrote:
> On Tue, Jan 27, 2004 at 12:41:44AM -0200, Marcus Grando wrote:
>
>>Hi,
>>
>>But why my kernel show this messages, if celeron not support speedstep-ich?
>>
>>cpufreq: P4/Xeon(TM) CPU On-Demand Clock Modulation available
>>cpufreq: Warning: Pentium 4-M detected. The speedstep-ich or acpi cpufreq
>>cpufreq: modules offers voltage scaling in addition of frequency
>>scaling. You
>>cpufreq: should use either one instead of p4-clockmod, if possible.
>>
>>Regards
>>
>>Ducrot Bruno wrote:
>>
>>>On Sat, Jan 24, 2004 at 01:53:57AM -0200, Marcus Grando wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I have a toshiba satellite a10 127, and use p4 clockmod in cpufreq. I
>>>>look this kernel messages:
>>>>
>>>>cpufreq: P4/Xeon(TM) CPU On-Demand Clock Modulation available
>>>>cpufreq: Warning: Pentium 4-M detected. The speedstep-ich or acpi cpufreq
>>>>cpufreq: modules offers voltage scaling in addition of frequency
>>>>scaling. You
>>>>cpufreq: should use either one instead of p4-clockmod, if possible.
>>>>
>>>
>>>
>>>...
>>>
>>>
>>>>CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000
>>>>CPU: After vendor identify, caps: bfebf9ff 00000000 00000000 00000000
>>>>CPU: Trace cache: 12K uops, L1 D cache: 8K
>>>>CPU: L2 cache: 256K
>>>>CPU: After all inits, caps: bfebf9ff 00000000 00000000 00000080
>>>>CPU: Intel Mobile Intel(R) Celeron(R) CPU 2.00GHz stepping 09
>>>
>>> ^^^^^^^
>>> A celeron is not speedstep capable.
>>>
>
>
> Could you try out this patch, please?
>
> Dominik
>
>
> ------------------------------------------------------------------------
>
> diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
> --- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c 2004-01-16 20:30:36.000000000 +0100
> +++ linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c 2004-01-28 23:32:49.637733272 +0100
> @@ -184,17 +184,55 @@
> if (c->x86_model != 2)
> return 0;
>
> - if ((c->x86_mask != 4) && /* B-stepping [M-P4-M] */
> - (c->x86_mask != 7) && /* C-stepping [M-P4-M] */
> - (c->x86_mask != 9)) /* D-stepping [M-P4-M or M-P4/533] */
> - return 0;
> -
> ebx = cpuid_ebx(0x00000001);
> ebx &= 0x000000FF;
> - if ((ebx != 0x0e) && (ebx != 0x0f))
> - return 0;
>
> - return SPEEDSTEP_PROCESSOR_P4M;
> + dprintk(KERN_INFO "ebx value is %x, x86_mask is %x\n", ebx, c->86_mask);
> +
> + switch (c->x86_mask) {
> + case 4:
> + /*
> + * B-stepping [M-P4-M]
> + * sample has ebx = 0x0f, production has 0x0e.
> + */
> + if ((ebx == 0x0e) || (ebx == 0x0f))
> + return SPEEDSTEP_PROCESSOR_P4M;
> + break;
> + case 7:
> + /*
> + * C-stepping [M-P4-M]
> + * needs to have ebx=0x0e, else it's a celeron:
> + * cf. 25130917.pdf / page 7, footnote 5 even
> + * though 25072120.pdf / page 7 doesn't say
> + * samples are only of B-stepping...
> + */
> + if (ebx == 0x0e)
> + return SPEEDSTEP_PROCESSOR_P4M;
> + break;
> + case 9:
> + /*
> + * D-stepping [M-P4-M or M-P4/533]
> + *
> + * this is totally strange: CPUID 0x0F29 is
> + * used by M-P4-M, M-P4/533 and(!) Celeron CPUs.
> + * The latter need to be sorted out as they don't
> + * support speedstep.
> + * Celerons with CPUID 0x0F29 may have either
> + * ebx=0x8 or 0xf -- 25130917.pdf doesn't say anything
> + * specific.
> + * M-P4-Ms may have either ebx=0xe or 0xf [see above]
> + * M-P4/533 have either ebx=0xe or 0xf. [25317607.pdf]
> + * So, how to distinguish all those processors with
> + * ebx=0xf? I don't know. Sort them out, and wait
> + * whether someone complains.
> + */
> + if (ebx == 0x0e)
> + return SPEEDSTEP_PROCESSOR_P4M;
> + break;
> + default:
> + break;
> + }
> + return 0;
> }
>
> switch (c->x86_model) {
--
Marcus Grando
Grupos Internet S/A
marcus(at)corp.grupos.com.br
[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 10215 bytes --]
Linux version 2.6.2-bk2 (root@marcusg.house) (gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)) #4 Wed Jan 28 21:00:42 BRST 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 00000000000eee00 (reserved)
BIOS-e820: 00000000000eee00 - 00000000000ef000 (ACPI NVS)
BIOS-e820: 00000000000ef000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000ef40000 (usable)
BIOS-e820: 000000000ef40000 - 000000000ef50000 (ACPI data)
BIOS-e820: 000000000ef50000 - 000000000f000000 (reserved)
BIOS-e820: 00000000fec10000 - 00000000fec20000 (reserved)
BIOS-e820: 00000000feda0000 - 00000000fedc0000 (reserved)
BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
239MB LOWMEM available.
On node 0 totalpages: 61248
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 57152 pages, LIFO batch:13
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 TOSHIB ) @ 0x000f0180
ACPI: RSDT (v001 TOSHIB 750 0x00970814 TASM 0x04010000) @ 0x0ef40000
ACPI: FADT (v002 TOSHIB 750 0x00970814 TASM 0x04010000) @ 0x0ef40058
ACPI: DBGP (v001 TOSHIB 750 0x00970814 TASM 0x04010000) @ 0x0ef400dc
ACPI: BOOT (v001 TOSHIB 750 0x00970814 TASM 0x04010000) @ 0x0ef40030
ACPI: DSDT (v001 TOSHIB AFCF7 0x20030326 MSFT 0x0100000e) @ 0x00000000
Building zonelist for node : 0
Kernel command line: ro root=/dev/hda3 norhgb nomodules
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 1995.509 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Memory: 238236k/244992k available (2432k kernel code, 6080k reserved, 873k data, 140k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 3891.20 BogoMIPS
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000
CPU: After vendor identify, caps: bfebf9ff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 256K
CPU: After all inits, caps: bfebf9ff 00000000 00000000 00000080
CPU: Intel Mobile Intel(R) Celeron(R) CPU 2.00GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd317, last bus=3
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040116
ACPI: IRQ9 SCI: Level Trigger.
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *11)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: Power Resource [PFAN] (off)
Toshiba System Managment Mode driver v1.11 26/9/2001
SCSI subsystem initialized
Linux Kernel Card Services
options: [pci] [cardbus] [pm]
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
SBF: Simple Boot Flag extension found and enabled.
SBF: Setting boot flags 0x1
ikconfig 0.7 with /proc/config*
udf: registering filesystem
ACPI: AC Adapter [ADP1] (off-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (off)
ACPI: Processor [CPU0] (supports C1 C2 C3)
ACPI: Thermal Zone [THRM] (65 C)
Toshiba Laptop ACPI Extras version 0.16
pty: 256 Unix98 ptys configured
lp: driver loaded but no devices found
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 855 Chipset.
agpgart: Maximum main memory to use for agp memory: 189M
agpgart: Detected 16252K stolen memory.
agpgart: AGP aperture is 128M @ 0xd8000000
[drm] Initialized i830 1.3.2 20021108 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
PCI: Enabling device 0000:00:1f.6 (0000 -> 0001)
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
floppy0: no floppy controllers found
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
Intel(R) PRO/100 Network Driver - version 2.3.30-k1
Copyright (c) 2003 Intel Corporation
e100: selftest OK.
e100: eth0: Intel(R) PRO/100 Network Connection
Hardware receive checksums enabled
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
NET: Registered protocol family 24
orinoco.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
orinoco_cs.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> and others)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
ICH4: chipset revision 3
ICH4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:DMA, hdd:pio
hda: TOSHIBA MK3021GAS, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: TOSHIBA DVD-ROM SD-R2412, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 58605120 sectors (30005 MB), CHS=58140/16/63, UDMA(100)
hda: hda1 hda2 hda3 hda4
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
PCI: Enabling device 0000:01:0b.0 (0000 -> 0002)
Yenta: CardBus bridge found at 0000:01:0b.0 [1179:0001]
Yenta: ISA IRQ mask 0x00b8, PCI irq 11
Socket status: 30000007
PCI: Enabling device 0000:00:1d.7 (0000 -> 0002)
ehci_hcd 0000:00:1d.7: EHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 11, pci mem cf890000
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2003-Dec-29
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
ohci_hcd: 2003 Oct 13 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1
uhci_hcd 0000:00:1d.0: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 10, io base 0000cfe0
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
drivers/usb/core/usb.c: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
drivers/usb/core/usb.c: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
drivers/usb/core/usb.c: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
drivers/usb/serial/usb-serial.c: USB Serial support registered for PocketPC PDA
drivers/usb/serial/ipaq.c: USB PocketPC PDA driver v0.5
drivers/usb/core/usb.c: registered new driver ipaq
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
input: PS/2 Generic Mouse on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
Advanced Linux Sound Architecture Driver Version 0.9.7 (Thu Sep 25 19:16:36 2003 UTC).
PCI: Enabling device 0000:00:1f.5 (0000 -> 0003)
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0: clocking to 48000
ALSA device list:
#0: Intel 82801DB-ICH4 at 0x18080800, irq 11
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
ip_conntrack version 2.1 (1914 buckets, 15312 max) - 300 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. http://snowman.net/projects/ipt_recent/
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
NET: Registered protocol family 17
cpufreq: P4/Xeon(TM) CPU On-Demand Clock Modulation available
PM: Reading pmdisk image.
PM: Resume from disk failed.
ACPI: (supports S0 S3 S4 S5)
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 140k freed
EXT3 FS on hda3, internal journal
Adding 522104k swap on /dev/hda4. Priority:-1 extents:1
mtrr: base(0xd8000000) is not aligned on a size(0x180000) boundary
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply
* Re: [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future
From: Fredrik Noring @ 2004-01-28 23:04 UTC (permalink / raw)
To: Edd Dumbill; +Cc: GNOME Bluetooth Mailing List, BlueZ Mailing List
In-Reply-To: <1067906859.15607.48.camel@saag>
Edd,
tis 2003-11-04 klockan 01.47 skrev Edd Dumbill:
> We need a way of finding out for which bdaddrs it has a key. Currently
> this information is stored in /etc/bluetooth/link_key and readable only
> by root, so we've some progress to make there.
I believe it would be helpful to change the link_key binary file format
to ascii.
This would make the file more accessible and also simplify debugging,
manual recovery, endianess compatibility, future data type compatibility
and compiler issues such as the size of "time_t". Current format is:
struct link_key {
bdaddr_t sba;
bdaddr_t dba;
uint8_t key[16];
uint8_t type;
time_t time;
};
An ascii version could be row based. What about like this?
00:11:22:33:44:55 66:77:88:99:00:11 6d450822cf944dcedd7a5b2e347e606f key_type 1075330902
Works with grep, awk, perl, emacs and so on too. :)
Fredrik
_______________________________________________
gnome-bluetooth mailing list
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
^ permalink raw reply
* Re: [PATCH] crypto/sha256.c crypto/sha512.c
From: David S. Miller @ 2004-01-28 23:03 UTC (permalink / raw)
To: James Morris; +Cc: jlcooke, linux-kernel
In-Reply-To: <Xine.LNX.4.44.0401281706181.8922-100000@thoron.boston.redhat.com>
On Wed, 28 Jan 2004 17:08:58 -0500 (EST)
James Morris <jmorris@redhat.com> wrote:
> On Wed, 28 Jan 2004, Jean-Luc Cooke wrote:
>
> > Pardon my ignorance, but does silence mean "yes"?
>
> No, but the patch looks fine to me and passes the test vectors.
>
> Dave, I've included it below.
Applied, thanks guys.
^ permalink raw reply
* Re: NetBSD port and a couple of remarks
From: Andi Kleen @ 2004-01-28 22:59 UTC (permalink / raw)
To: Kip Macy; +Cc: Ian.Pratt, xen-devel
In-Reply-To: <20040128132614.A49402@demos.bsdclusters.com>
On Wed, 28 Jan 2004 13:28:32 -0800 (PST)
Kip Macy <kmacy@fsmware.com> wrote:
> > (c) Notwithstanding any other terms in this License, this License is not
> > available to You if You and/or your employer develop, produce, sell,
> > and/or resell a product which contains substantially similar capabili-
> > ties of the BitKeeper Software, or, in the reasonable opinion of Bit-
> > Mover, competes with the BitKeeper Software.
This one is the killer.
If you ever touched the source of any VCS or work for a company who might ship
one (and many big software companies have similar programs) then you cannot use it.
Also it is vague enough that you could basically get sued anytime. They just
have to define some product you're involved in as "competing with bitkeeper"
Who knows, maybe Xen will compete with some obscure feature of BitKeeper at some point?
-Andi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: 2.6.2-rc2-mm1:Badness in try_to_wake_up at kernel/sched.c:722
From: Daniel Andersen @ 2004-01-28 22:59 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: linux-kernel
In-Reply-To: <1075319562.796.0.camel@teapot.felipe-alfaro.com>
> On Wed, 2004-01-28 at 18:55, Adam Koszela wrote:
> > So here's my problem:
> > Performance, especially when switching/launching/killing apps is awful,
> > and dmesg spits out:
> >
> > Badness in try_to_wake_up at kernel/sched.c:722
> > Call Trace:
> > [<c011aac5>] try_to_wake_up+0x91/0x1c9
>
> C'mon people, this has been reported at least four times ;-)
> I'm sure Andrew is looking into it right now.
I get the same message myself when using xmms.
AFAICS this is not much to worry about. It is only a new debug message which did not exist in 2.6.2-rc2 or earlier.
Daniel Andersen
^ permalink raw reply
* Re: [RFC/PATCH, 2/4] readX_check() performance evaluation
From: Linus Torvalds @ 2004-01-28 22:59 UTC (permalink / raw)
To: Andi Kleen; +Cc: willy, ishii.hironobu, linux-kernel, linux-ia64
In-Reply-To: <20040128233948.26a36ff7.ak@suse.de>
On Wed, 28 Jan 2004, Andi Kleen wrote:
> > Doing a status read from the device should do it (just read the config
> > space, for example).
>
> The device is just not known. iirc you only get a bit in the bridge, which
> leaves a wide choice.
read_pcix_error() _does_ know the device. The driver tells it.
Remember: none of this should be done at machine check time.
Linus
^ permalink raw reply
* Re: [RFC/PATCH, 2/4] readX_check() performance evaluation
From: Linus Torvalds @ 2004-01-28 22:59 UTC (permalink / raw)
To: Andi Kleen; +Cc: willy, ishii.hironobu, linux-kernel, linux-ia64
In-Reply-To: <20040128233948.26a36ff7.ak@suse.de>
On Wed, 28 Jan 2004, Andi Kleen wrote:
> > Doing a status read from the device should do it (just read the config
> > space, for example).
>
> The device is just not known. iirc you only get a bit in the bridge, which
> leaves a wide choice.
read_pcix_error() _does_ know the device. The driver tells it.
Remember: none of this should be done at machine check time.
Linus
^ 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.