gt;>> idx = IDX_PKG_ENERGY;
>>> break;
>>> case MSR_DRAM_ENERGY_STATUS:
>>> @@ -353,7 +357,7 @@ int idx_valid(int idx)
>>> {
>>> switch (idx) {
>>> case IDX_PKG_ENERGY:
>>> - return do_rapl & RAPL_PKG;
>>> + return do_rapl & (RAPL_PKG | RAPL_AMD_F17H);
>>> case IDX_DRAM_ENERGY:
>>> return do_rapl & RAPL_DRAM;
>>> case IDX_PP0_ENERGY:
>>> --
>>> 2.25.1
Unsurprisingly, the patch from Bas works for me as well.
(Tested on a Zen 3 and an embedded Zen.)
Tested-by: Kurt Garloff
Signed-off-by: Kurt Garloff
Thanks,
--
Kurt Garloff , Cologne, Germany
gain, despite current libblkid.
(Fortunately, most use cdrom these days.)
Best,
--
Kurt Garloff , Cologne, Germany
commit 5d399d05df42ffcaa2b3836b580631c4024487a0
Author: Kurt Garloff
Date: Mon Feb 1 09:01:47 2021 +
turbostat: Fix Pkg Power tracking on Zen
AMD Zen processors use a different MSR (MSR_PKG_ENERGY_STAT) than intel
(MSR_PKG_ENERGY_STATUS) to track package power; however we
98.80 0.06
1 17 9 0.40 2329 3400 308 0 38 282
0.00 0.35 99.29
[...]
--
Kurt Garloff
Cologne, Germany
On 26/12/2020 13:13, Kurt Garloff wrote:
> Hi Len,
>
> find attached fix to avoid exiting with -13 on Zen. Patch is against
&g
MODE) to fail. It turns out that
>> this is being used setfdprm userspace for ioctl-only open().
>>
>> Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
>> modes, while still keeping the original O_NDELAY bug fixed.
>>
>> Cc: sta...@vger.kernel.o
Hi Trond,
Am 08.01.21 um 15:39 schrieb Kurt Garloff:
> Hi Trond,
>
> On 08/01/2021 12:58, Trond Myklebust wrote:
>> On Fri, 2021-01-08 at 12:41 +0100, Kurt Garloff wrote:
>>> [...]
>>> The kernel tree is on an NFS share, and I run 5.10.5 client kernel
>&g
Hi Trond,
On 08/01/2021 12:58, Trond Myklebust wrote:
> On Fri, 2021-01-08 at 12:41 +0100, Kurt Garloff wrote:
>> Hi Neil, Anna, Trond,
>>
>> compiling a kernel, I suddenly started getting errors from objtool
>> orc.
>> (This first occurs on init/main.o.)
>
be able to see right away what's wrong.
Best,
--
Kurt Garloff
Cologne, Germany
/* testpwrite.c
* reproduces issue on NFS 4.2 client on Linux 5.10.5
* (c) Kurt Garloff , 1/2021
* License: GNU GPL 2 or later
*/
#include
#include
#include
#include
#include
#include
#include
#define MAXBUF
Hi Len,
find attached fix to avoid exiting with -13 on Zen. Patch is against turbostat
as included in Linux-5.10.2.
Please merge.
PS: This is probably material for -stable, as it used to work before on Zen
(Zen2 aka Ryzen 3000 in my case).
--
Kurt Garloff
Cologne, Germany
commit
mode] (rev 61)
Looks like we'd need some quirks to actually create a pci_device handle for the
embedded AMD eMMC controller?
Thoughts?
PS: Please copy me on responses, I'm off LKML for half a decade now :-O
--
Kurt Garloff
Cologne, Germany
Hi,
this has been discussed on linux-usb and Alan Stern provided very
helpful feedback.
Please merge this patch ...
From: Kurt Garloff
Date: Mon, 23 Sep 2013 14:19:02 +0200
Subject: Tolerate wrong direction bit in endpoint address for control messages
Trying to read data from the Pegasus
Hi,
this has been discussed on linux-usb and Alan Stern provided very
helpful feedback.
Please merge this patch ...
From: Kurt Garloff k...@garloff.de
Date: Mon, 23 Sep 2013 14:19:02 +0200
Subject: Tolerate wrong direction bit in endpoint address for control messages
Trying to read data
Hi Alan,
Alan Stern schrieb:
> On Mon, 23 Sep 2013, Kurt Garloff wrote:
>
> > >> that qualifies as a bug or not. Maybe it should not claim to be a
> > >> HID device then?
> > > Maybe not. This particular combination of bRequestType and
> bRequest
Hi Alan,
On 09/23/2013 04:28 AM, Alan Stern wrote:
> On Sun, 22 Sep 2013, Kurt Garloff wrote:
>
>> Well, this seems to be a question of terminology, no?
>> I saw the endpoint byte as consisting of endpoint index plus the direction
>> bit.
> See the entry for &quo
Hi Alan,
On 09/23/2013 04:28 AM, Alan Stern wrote:
On Sun, 22 Sep 2013, Kurt Garloff wrote:
Well, this seems to be a question of terminology, no?
I saw the endpoint byte as consisting of endpoint index plus the direction
bit.
See the entry for Endpoint Address in Chapter 2 (Terms
Hi Alan,
Alan Stern st...@rowland.harvard.edu schrieb:
On Mon, 23 Sep 2013, Kurt Garloff wrote:
that qualifies as a bug or not. Maybe it should not claim to be a
HID device then?
Maybe not. This particular combination of bRequestType and
bRequest
values (0x22, 0x09
Hi Alan,
thanks for your review and your constructive comments!
Alan Stern schrieb:
>On Sun, 22 Sep 2013, Kurt Garloff wrote:
>
>> Hi,
>>
>> USB devio rejects control messages when the index does not have the
>> direction bit set correctly.
>
>I woul
keep me in copy for the discussion, my participation on LKML is
mostly reading summaries
from Jonathan and Thorsten these days, unfortunately.
--
Kurt Garloff
Cologne, Germany
commit bc1e4e1ae1d5a4f9b2d263f22c651dd5ba4f8ff9
Author: Kurt Garloff
Date: Sun Sep 22 11:54:59 2013 +0200
From
keep me in copy for the discussion, my participation on LKML is
mostly reading summaries
from Jonathan and Thorsten these days, unfortunately.
--
Kurt Garloff k...@garloff.de
Cologne, Germany
commit bc1e4e1ae1d5a4f9b2d263f22c651dd5ba4f8ff9
Author: Kurt Garloff k...@garloff.de
Date: Sun Sep 22
Hi Alan,
thanks for your review and your constructive comments!
Alan Stern st...@rowland.harvard.edu schrieb:
On Sun, 22 Sep 2013, Kurt Garloff wrote:
Hi,
USB devio rejects control messages when the index does not have the
direction bit set correctly.
I wouldn't describe it that way
overkill for something that does
not tend to change.
Please merge.
(Patch applied against latest 2.6.20rc version that I tested.)
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: [SCSI SCAN] Fix logging message for PQ3 devices
The blacklist flags BLIST_ATTACH_PQ3 has value 0x100,
not 0x
overkill for something that does
not tend to change.
Please merge.
(Patch applied against latest 2.6.20rc version that I tested.)
From: Kurt Garloff [EMAIL PROTECTED]
Subject: [SCSI SCAN] Fix logging message for PQ3 devices
The blacklist flags BLIST_ATTACH_PQ3 has value 0x100,
not 0x80
On Wed, Aug 24, 2005 at 06:20:31PM -0700, Chris Wright wrote:
> Call security hooks conditionally if the security_op is filled out.
> Branches can be more efficient than the unconditional indirect function
> call. Inspired by patch from Kurt Garloff <[EMAIL PROTECTED]>.
>
>
On Wed, Aug 24, 2005 at 06:20:31PM -0700, Chris Wright wrote:
Call security hooks conditionally if the security_op is filled out.
Branches can be more efficient than the unconditional indirect function
call. Inspired by patch from Kurt Garloff [EMAIL PROTECTED].
Signed-off-by: Chris Wright
Hi James,
On Tue, Jul 05, 2005 at 11:40:40AM -0400, James Morris wrote:
> On Tue, 5 Jul 2005, Kurt Garloff wrote:
>
> > # define COND_SECURITY(seop, def) \
> > (security_opt->seop == NULL) || \
> > security_ops == _securi
Hi Tony,
On Sun, Jul 03, 2005 at 03:51:52PM -0700, Tony Jones wrote:
> On Sun, Jul 03, 2005 at 05:43:33PM +0200, Kurt Garloff wrote:
>
> > Note that we could think of getting rid of dummy; however, it's
> > still used as fallback for stubs that are not implemented by an
>
Hi Tony,
On Sun, Jul 03, 2005 at 03:51:52PM -0700, Tony Jones wrote:
On Sun, Jul 03, 2005 at 05:43:33PM +0200, Kurt Garloff wrote:
Note that we could think of getting rid of dummy; however, it's
still used as fallback for stubs that are not implemented by an
LSM. I did not want to change
Hi James,
On Tue, Jul 05, 2005 at 11:40:40AM -0400, James Morris wrote:
On Tue, 5 Jul 2005, Kurt Garloff wrote:
# define COND_SECURITY(seop, def) \
(security_opt-seop == NULL) || \
security_ops == capability_security_ops)? \
def
Hi Serge,
On Mon, Jul 04, 2005 at 07:37:21AM -0500, [EMAIL PROTECTED] wrote:
> Quoting Kurt Garloff ([EMAIL PROTECTED]):
> > Getting rid of dummy entirely would be better, I agree, but someone
> > needs to review that this won't break anything.
>
> Unfortunately I th
Hi Serge,
On Mon, Jul 04, 2005 at 07:01:05AM -0500, [EMAIL PROTECTED] wrote:
> Quoting Tony Jones ([EMAIL PROTECTED]):
> > On Mon, Jul 04, 2005 at 08:59:02AM +0200, Kurt Garloff wrote:
> >
> > > > The topic of replacing dummy (with capability) was discus
Hi Serge,
On Mon, Jul 04, 2005 at 07:01:05AM -0500, [EMAIL PROTECTED] wrote:
Quoting Tony Jones ([EMAIL PROTECTED]):
On Mon, Jul 04, 2005 at 08:59:02AM +0200, Kurt Garloff wrote:
The topic of replacing dummy (with capability) was discussed there
last week, in the context of stacker
Hi Serge,
On Mon, Jul 04, 2005 at 07:37:21AM -0500, [EMAIL PROTECTED] wrote:
Quoting Kurt Garloff ([EMAIL PROTECTED]):
Getting rid of dummy entirely would be better, I agree, but someone
needs to review that this won't break anything.
Unfortunately I think it's way too soon
6.10.
> If not, complain again :)
Is there a clean patchset that we should look at to test?
Regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgp77K575xjBf.pgp
Description: PGP signature
at to test?
Regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgp77K575xjBf.pgp
Description: PGP signature
Hi Amon,
On Thu, Feb 24, 2005 at 09:28:38AM +0100, Amon Ott wrote:
> On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote:
> > If you apply them (and I hope Linus will), capabilities is default
> > and you can replace that by loading an LSM. You can stack capability
> >
Hi Amon,
On Thu, Feb 24, 2005 at 09:28:38AM +0100, Amon Ott wrote:
On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote:
If you apply them (and I hope Linus will), capabilities is default
and you can replace that by loading an LSM. You can stack capability
on top of the primary LSM
default
and you can replace that by loading an LSM. You can stack capability
on top of the primary LSM again, if the latter supports this.
Best regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgpoRQjzM1H0i.pgp
Description: PGP signature
supports this.
Best regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgpoRQjzM1H0i.pgp
Description: PGP signature
Hi,
On Sun, Feb 13, 2005 at 04:11:09PM -0500, Kurt Garloff wrote:
> From: Kurt Garloff <[EMAIL PROTECTED]>
> Subject: Clean LSM stub file
[...]
So, for convenience, I merged Andreas' fix on top
of this patch into a new patch 2, which is attached.
So CONFIG_SECURITY_NETWORK disabled
Hi Rik,
On Mon, Feb 14, 2005 at 11:54:07AM -0500, Rik van Riel wrote:
> On Sun, 13 Feb 2005, Kurt Garloff wrote:
>
> >The case that security_ops points to the default capability_
> >security_ops is the fast path and arguably the more likely one
> >on most systems.
>
Hi James,
On Mon, Feb 14, 2005 at 11:50:01AM -0500, James Morris wrote:
> On Sun, 13 Feb 2005, Kurt Garloff wrote:
>
> > /* Condition for invocation of non-default security_op */
> > #define COND_SECURITY(seop, def) \
> > - (likely(security_ops == _security_ops))
Hi Andreas,
On Mon, Feb 14, 2005 at 03:30:33PM +0100, Andreas Gruenbacher wrote:
> On Sun, 2005-02-13 at 22:11, Kurt Garloff wrote:
> > Rather than having every LSM hook twice, once for the case with
> > CONFIG_SECURITY enabled and once for the disabled case, put
> > eve
Hi Andreas,
On Mon, Feb 14, 2005 at 03:30:33PM +0100, Andreas Gruenbacher wrote:
On Sun, 2005-02-13 at 22:11, Kurt Garloff wrote:
Rather than having every LSM hook twice, once for the case with
CONFIG_SECURITY enabled and once for the disabled case, put
everything in one inline function
Hi James,
On Mon, Feb 14, 2005 at 11:50:01AM -0500, James Morris wrote:
On Sun, 13 Feb 2005, Kurt Garloff wrote:
/* Condition for invocation of non-default security_op */
#define COND_SECURITY(seop, def) \
- (likely(security_ops == capability_security_ops))? def:
security_ops
Hi Rik,
On Mon, Feb 14, 2005 at 11:54:07AM -0500, Rik van Riel wrote:
On Sun, 13 Feb 2005, Kurt Garloff wrote:
The case that security_ops points to the default capability_
security_ops is the fast path and arguably the more likely one
on most systems.
Quite a few distributions ship
Hi,
On Sun, Feb 13, 2005 at 04:11:09PM -0500, Kurt Garloff wrote:
From: Kurt Garloff [EMAIL PROTECTED]
Subject: Clean LSM stub file
[...]
So, for convenience, I merged Andreas' fix on top
of this patch into a new patch 2, which is attached.
So CONFIG_SECURITY_NETWORK disabled should work again
1 channel 0 id 8 lun 0x0200080c0400 has a LUN larger than
> currently supported.
LUN flattening issue?
> I noticed that these LUN hex values decode to text fragments:
> Easy RAID decodes to: 'e.syRAID'
> Vendor=Transtec, lun decodes to 't.anstec'.
Ask them to fix it.
Regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgpgtc8QYpG6h.pgp
Description: PGP signature
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Test security_enabled var rather than security_ops pointer
References: 40217, 39439
Rather than doing a pointer comparison, test an integer var
for being null. Should be slightly faster.
I consider this patch as optional.
Note that i
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Consider the capability case the likely one
References: 40217, 39439
The case that security_ops points to the default capability_
security_ops is the fast path and arguably the more likely one
on most systems. So mark it likely to tell the co
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Clean LSM stub file
References: 40217, 39439
Rather than having every LSM hook twice, once for the case with
CONFIG_SECURITY enabled and once for the disabled case, put
everything in one inline function. This reduces the chance of
the two to
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Replace indirect calls by a branch
References: 40217, 39439
In the LSM stub collection, rather do a branch than an indirect
call. Many of the functions called do only return 0 or do nothing
for the default (capability) case.
This is a fas
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Default to capability rather than dummy if no LSM is loaded
References: 40217, 39439
If a kernel is compiled with CONFIG_SECURITY to enable LSM, the
default behaviour changes unless a user load capability.
This is undesirable. This patch
hes are against 2.6.11-rc4 and follow in subsequent mails.
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgpmSdj323S6S.pgp
Description: PGP signature
are against 2.6.11-rc4 and follow in subsequent mails.
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgpmSdj323S6S.pgp
Description: PGP signature
From: Kurt Garloff [EMAIL PROTECTED]
Subject: Default to capability rather than dummy if no LSM is loaded
References: 40217, 39439
If a kernel is compiled with CONFIG_SECURITY to enable LSM, the
default behaviour changes unless a user load capability.
This is undesirable. This patch makes
From: Kurt Garloff [EMAIL PROTECTED]
Subject: Replace indirect calls by a branch
References: 40217, 39439
In the LSM stub collection, rather do a branch than an indirect
call. Many of the functions called do only return 0 or do nothing
for the default (capability) case.
This is a fast-path
From: Kurt Garloff [EMAIL PROTECTED]
Subject: Clean LSM stub file
References: 40217, 39439
Rather than having every LSM hook twice, once for the case with
CONFIG_SECURITY enabled and once for the disabled case, put
everything in one inline function. This reduces the chance of
the two to go out
From: Kurt Garloff [EMAIL PROTECTED]
Subject: Consider the capability case the likely one
References: 40217, 39439
The case that security_ops points to the default capability_
security_ops is the fast path and arguably the more likely one
on most systems. So mark it likely to tell the compiler
From: Kurt Garloff [EMAIL PROTECTED]
Subject: Test security_enabled var rather than security_ops pointer
References: 40217, 39439
Rather than doing a pointer comparison, test an integer var
for being null. Should be slightly faster.
I consider this patch as optional.
Note that it does
that these LUN hex values decode to text fragments:
Easy RAID decodes to: 'e.syRAID'
Vendor=Transtec, lun decodes to 't.anstec'.
Ask them to fix it.
Regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgpgtc8QYpG6h.pgp
Description: PGP signature
On Thu, Jun 14, 2001 at 01:26:05PM -0400, Richard B. Johnson wrote:
> Question 2: What is the purpose of the code sequence, "repz nop"
Puts iP4 into low power mode.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail
On Thu, Jun 14, 2001 at 01:26:05PM -0400, Richard B. Johnson wrote:
Question 2: What is the purpose of the code sequence, repz nop
Puts iP4 into low power mode.
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers
ch faster than thread creation.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
.
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
D3130AT, 12417MB w/512kB Cache, CHS=1583/255/63, (U)DMA
hdc: st3144AT, 124MB w/32kB Cache, CHS=1001/15/17
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> [Eindhoven, NL]
Physics: Plasma simulations <[EMAIL PROTECTED]> [TU Eindhoven, NL]
Linux: SCSI, Sec
,
--
Kurt Garloff [EMAIL PROTECTED] [Eindhoven, NL]
Physics: Plasma simulations [EMAIL PROTECTED] [TU Eindhoven, NL]
Linux: SCSI, Security [EMAIL PROTECTED] [SuSE Nuernberg, FRG]
(See mail header or public key servers for PGP2 and GPG public keys.)
--- linux
red applying this policy change right now
within 2.4, Linus. Well, ignore my posting then, if you like.
Best regards,
--
Kurt Garloff <[EMAIL PROTECTED]> [Eindhoven, NL]
Physics: Plasma simulations <[EMAIL PROTECTED]> [TU Eindhoven, NL]
Linux: SCSI, Se
within 2.4, Linus. Well, ignore my posting then, if you like.
Best regards,
--
Kurt Garloff [EMAIL PROTECTED] [Eindhoven, NL]
Physics: Plasma simulations [EMAIL PROTECTED] [TU Eindhoven, NL]
Linux: SCSI, Security [EMAIL PROTECTED] [SuSE Nuernberg, FRG]
(See
, Trond.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
/** test_nfs_shared_map.c
*
* Creates a file, e
, Trond.
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
/** test_nfs_shared_map.c
*
* Creates a file, expands
+len-1) */
/* Try adding here: msync (adr, len, MS_SYNC); */
munmap (adr, len);
close (fd);
The code works on files on local harddisks and on NFS volumes on a 2.2
kernel, but breaks on NFS drives on a 2.4.4 kernel.
msync() works around the bug.
Andrea's patch did help as well.
Regards,
--
Kurt G
) */
/* Try adding here: msync (adr, len, MS_SYNC); */
munmap (adr, len);
close (fd);
The code works on files on local harddisks and on NFS volumes on a 2.2
kernel, but breaks on NFS drives on a 2.4.4 kernel.
msync() works around the bug.
Andrea's patch did help as well.
Regards,
--
Kurt Garloff
rminal you
want to. I already sent it to Andries.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--- linux
you
want to. I already sent it to Andries.
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--- linux-244.compile/drivers
knfsd, linux-2.4.4, 8139too-0.9.16
> linux-2.4.4, 8139too-0.9.16
>
> transfers seem to start with about 2 MB/s but drop
> immediatly to about 20 K/s.
PS: If you send your .config, pipe it via grep -v "^#"
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]>
, 8139too-0.9.16
linux-2.4.4, 8139too-0.9.16
transfers seem to start with about 2 MB/s but drop
immediatly to about 20 K/s.
PS: If you send your .config, pipe it via grep -v ^#
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers
64, see README.)
Newer versions of osst overcome this block size limitation, but those
have not yet been merged to the mainstream kernel.
If you find trouble, please also report to [EMAIL PROTECTED]
Enjoy!
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key:
versions of osst overcome this block size limitation, but those
have not yet been merged to the mainstream kernel.
If you find trouble, please also report to [EMAIL PROTECTED]
Enjoy!
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers
On Tue, Apr 24, 2001 at 10:58:58AM +0200, Jens Axboe wrote:
> On Tue, Apr 24 2001, Kurt Garloff wrote:
> > There are enough partitions to see a clear pattern: Those with mounted ext2
> > filesystems perform better. Umounting them does not harm, they just need to
> > have been
On Tue, Apr 24, 2001 at 10:58:58AM +0200, Jens Axboe wrote:
On Tue, Apr 24 2001, Kurt Garloff wrote:
There are enough partitions to see a clear pattern: Those with mounted ext2
filesystems perform better. Umounting them does not harm, they just need to
have been mounted once. reiser or (v
, they just need to
have been mounted once. reiser or (v)fat however don't improve anything.
swap does, as does a ext2 over raid5.
Kernel 2.4.3pre7; Dual iPIII-700 system; i440BX MoBo.
Is this to be expected? Blocksize issues? Readahead behaviour? What's
changed on ext2 mounting ... ?
Regards,
--
Kurt
, they just need to
have been mounted once. reiser or (v)fat however don't improve anything.
swap does, as does a ext2 over raid5.
Kernel 2.4.3pre7; Dual iPIII-700 system; i440BX MoBo.
Is this to be expected? Blocksize issues? Readahead behaviour? What's
changed on ext2 mounting ... ?
Regards,
--
Kurt
design stuff and have to wait for stabilization ...
Good luck!
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
stuff and have to wait for stabilization ...
Good luck!
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
me timing stuff at the local APICs ...
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
at the local APICs ...
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
his patch found? I am not seeing it so far on kernel.org.
Attached, as I assume more people are interested in it ...
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG
;BROKEN_IO_APIC")?
Same for me.
Maciej, did you submit the patch to Linus? It really seems to solve the
(occurence of the) problems with these boards...
Where is this patch found? I am not seeing it so far on kernel.org.
Attached, as I assume more people are interested in it ...
Regar
truction. Your CPU was reading some machine insn from memory it
never heard about. => exception 6 => signal 4 (SIGILL)
If your main memory is not faulty, it's your cache or your CPU. Or your
compiler.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
was reading some machine insn from memory it
never heard about. = exception 6 = signal 4 (SIGILL)
If your main memory is not faulty, it's your cache or your CPU. Or your
compiler.
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers
a summary to LKML.)
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> [Eindhoven, NL]
Physics: Plasma simulations <[EMAIL PROTECTED]> [TU Eindhoven, NL]
Linux: SCSI, Security <[EMAIL PROTECTED]> [SuSE Nuernberg, FRG]
(See mail header or public ke
a summary to LKML.)
Regards,
--
Kurt Garloff [EMAIL PROTECTED] [Eindhoven, NL]
Physics: Plasma simulations [EMAIL PROTECTED] [TU Eindhoven, NL]
Linux: SCSI, Security [EMAIL PROTECTED] [SuSE Nuernberg, FRG]
(See mail header or public key servers for PGP2 and GPG
killer choose the right processes?
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
choose the right processes?
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
Very nice work! Keep on going!
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
On Thu, Mar 22, 2001 at 01:20:40PM +, Pavel Machek wrote:
> > Kurt Garloff <[EMAIL PROTECTED]> wrote:
> Notice, that one of your CPUs is twice as fast as second one. You'll
> need some heavy updates in scheduler.
I know that making sure to have a fair schedulin
ed.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--- linux.compile.old/drivers/char/pc_keyb.cTue Ju
if it's related, but new keyboards tend to have those annoying
APM keys. On my keyboard, they generate the scan sequences e0 5e (Power
OFF), e0 5f (Sleep) and e0 63 (Wake Up). I guess the USB kbd also has those
toy keys.
Patch to support those keys on a normal PS/2 kbd attached.
Regards,
--
Kurt
On Thu, Mar 22, 2001 at 01:20:40PM +, Pavel Machek wrote:
Kurt Garloff [EMAIL PROTECTED] wrote:
Notice, that one of your CPUs is twice as fast as second one. You'll
need some heavy updates in scheduler.
I know that making sure to have a fair scheduling on non-symmetric
multiprocessor
,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
1 - 100 of 208 matches
Mail list logo
