Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
> the default on ia64 (32MB) was way too large Agreed. It took about 9 minutes to search the first pair of cpus (cpu 0 to cpu 1) from a size of 67107840 down to a size of 62906, based on some prints I added since my last message. > it seems the screen blanking timer hit Ah - yes. That makes sense. > do a search from 10MB downwards. This > should speed up the search. That will help (I'm guessing not enough - will see shortly.) > verbose printouts I will put them to good use. Thanks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: The question is what happens when you compress 1 1GiB input buffer into a 1GiB output buffer. If user provides 1 GB output buffer then either we successfully compress all the 1 GB input or we compress just a part of it. In the former case user may provide a second output buffer and crypto_comp_pcompress() will compress the rest of the input to it. And the user will have two independently de-compressible buffers. The latter case is possible if the input isn't compressible and it is up to user to detect that handle this situation properly (i.e., just not to compress this). So, IMO, there are no problems here at least for the crypto_comp_pcompress() function. In case of crypto_comp_pcompress() if the input isn't compressible, error will be returned. If somebody needs a more flexible compression interface, he may think about implementing an deflate-like Crypto API interface. Or something else like crypto_comp_compress() which saves its internal state between calls and may be called several times with more input/output. I didn't think on it but we might as well. It'd be a good idea to use /dev/urandom as your input. Yes, this is what I think about. I'm going to extend the tcrypt.ko test. -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Artem B. Bityuckiy wrote: In the former case user may provide a second output buffer and s/former/latter/ -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Sorry :-) Artem B. Bityuckiy wrote: In case of crypto_comp_pcompress() if the input isn't compressible, s/crypto_comp_pcompress()/crypto_comp_compress()/ -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 12:22:12PM +0400, Artem B. Bityuckiy wrote:
>
> The latter case is possible if the input isn't compressible and it is up
> to user to detect that handle this situation properly (i.e., just not to
> compress this). So, IMO, there are no problems here at least for the
> crypto_comp_pcompress() function.
Surely that defeats the purpose of pcompress? I thought the whole point
was to compress as much of the input as possible into the output?
So 1G into 1G doesn't make sense here. But 1G into 1M does and you
want to put as much as you can in there. Otherwise we might as well
delete crypto_comp_pcompress :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Jörn Engel wrote: > Absolutely. You can argue that 4KiB is too small and 8|16|32|64|... > would be much better, yielding in better compression ratio. But > having to read and uncompress the whole file when appending a few > bytes is utter madness. > Dear Joern, I meant that JFFS2 always reads by portions of PAGE_SIZE bytes due to the Page Cache. Consequently, nodes cotaining the peaces of the same page don't have to be independently uncompressible. Yes, there are some difficulties. But this is off-topic anyway and I don't think it is worth to discuss this here :-) -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.11.6] Oops trying to remove module "bttv"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday, 03 April 2005, at 01:31:30 +0200, Jesper Juhl wrote: > Have you tried 2.6.12-rc1-bk5 or 2.6.12-rc1-mm4 to see if the bug has > already been fixed ? > Just tried 2.6.12-rc1-bk5, and it works OK. Sorry for the noise. Greetings, - -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.12-rc1-bk5) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCT641ao1/w/yPYI0RAkfWAJ4xk4+n4VhIfCza+QUFH49u5HewNwCfebxR o7upS2+7eI9DkJ9E5spjEbA= =Ez+Q -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 2/4] Deprecate synchronize_kernel, GPL replacement
On Sat, Apr 02, 2005 at 10:21:50PM -0800, Paul E. McKenney wrote:
> The synchronize_kernel() primitive is used for quite a few different
> purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
> and so on. This makes RCU code harder to read, since synchronize_kernel()
> might or might not have matching rcu_read_lock()s. This patch creates
> a new synchronize_rcu() that is to be used for RCU readers and a new
> synchronize_sched() that is used for the rest. These two new primitives
> currently have the same implementation, but this is might well change
> with additional real-time support. Both new primitives are GPL-only,
> the old primitive is deprecated.
>
> Signed-off-by: <[EMAIL PROTECTED]>
> ---
> Depends on earlier "Add deprecated_for_modules" patch.
>
> +/*
> + * Deprecated, use synchronize_rcu() or synchronize_sched() instead.
> + */
> +void synchronize_kernel(void)
> +{
> + synchronize_rcu();
> +}
> +
We should probably mark it deprecated -
void __deprecated synchronize_kernel(void)
{
synchronize_rcu();
}
Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: Surely that defeats the purpose of pcompress? I thought the whole point was to compress as much of the input as possible into the output? Absolutely correct. So 1G into 1G doesn't make sense here. I thought you are afraid about the case of a totally random input which may *grow* after it has been compressed. But 1G into 1M does and you want to put as much as you can in there. Otherwise we might as well delete crypto_comp_pcompress :) Err, it looks like we've lost the conversation flow. :-) I commented your phrase: "The question is what happens when you compress 1 1GiB input buffer into a 1GiB output buffer." Then could you please in a nutshell write what worries you or what issue you would like to clarify? IIRC, you worried that in case of a large input and output 12 bytes won't be enough. I argued it should. I'm even going to check this soon :-) -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
Earlier, Paul wrote: > Note the first 3 chars of the panic message "4.5". This looks like it > might be the [00]-[01] entry of Ingo's table, flushed out when the > newlines of the panic came through. For the record, the above speculation is probably wrong. More likely, the first six characters "4.5(0)" of my quoted panic message came out some time before the panic, and represent the the [0]-[1] entry of the table. These six chars came out at approx. nine minutes into the calculation, and the timer panic'd the system at ten minutes. I didn't look at the screen between the 9th and 10th minute, to realize that it had finally computed one table entry. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix u32 vs. pm_message_t in arm
On Tue, Mar 29, 2005 at 09:15:43PM +0200, Pavel Machek wrote: > This fixes u32 vs. pm_message_t confusion in arm. I was not able to > even compile it, but it should not cause any problems. Please apply, Applied, thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: On Sun, Apr 03, 2005 at 12:22:12PM +0400, Artem B. Bityuckiy wrote: The latter case is possible if the input isn't compressible and it is up to user to detect that handle this situation properly (i.e., just not to compress this). So, IMO, there are no problems here at least for the crypto_comp_pcompress() function. I meant here, that user a-priori doesn't always know how good will his data be compressed. So, he *may* provide the output buffer of the same size as the input buffer (as you wrote, both are of 1GiB). So, if the input data *grows* after the compression, then crypto_comp_pcompress() will fill the output buffer fully and return OK, indicating that not all the input was compressed. And it is up to user to handle this situation. Probably he will just leave his data uncompressed. Probably he will provide more output buffers. I just wanted to say, that crypto_comp_pcompress() will work OK even in the case of uncompressible data because I thought something worries you in this case :-) Surely that defeats the purpose of pcompress? I thought the whole point was to compress as much of the input as possible into the output? So 1G into 1G doesn't make sense here. But 1G into 1M does and you want to put as much as you can in there. Otherwise we might as well delete crypto_comp_pcompress :) -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 12:59:23PM +0400, Artem B. Bityuckiy wrote:
>
> Err, it looks like we've lost the conversation flow. :-) I commented
> your phrase: "The question is what happens when you compress 1 1GiB
> input buffer into a 1GiB output buffer."
>
> Then could you please in a nutshell write what worries you or what issue
> you would like to clarify?
>
> IIRC, you worried that in case of a large input and output 12 bytes
> won't be enough. I argued it should. I'm even going to check this soon :-)
You can't compress 1M-12bytes into 1M using zlib when the block size
is 64K.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][SELINUX] Add name_connect permission check
On Mar 24, 2005 12:41 AM, Stephen Smalley <[EMAIL PROTECTED]> wrote: > On Wed, 2005-03-23 at 09:40 -0500, Stephen Smalley wrote: > > This patch adds a name_connect permission check to SELinux to provide > > control over outbound TCP connections to particular ports distinct > > from the general controls over sending and receiving packets. Please > > apply. > > On a standard FC3 with selinux enabled, booting the latest -bk breaks all my outgoing TCP connections at a guess due to this patch.. this probably isn't something that people really want to happen.. or maybe Fedora can release an updated policy to deal with it? Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: You can't compress 1M-12bytes into 1M using zlib when the block size is 64K. Here is a cite from RFC-1951 (page 4): A compressed data set consists of a series of blocks, corresponding to successive blocks of input data. The block sizes are arbitrary, except that non-compressible blocks are limited to 65,535 bytes. Thus, 1. 64K is only applied to non-compressible data, in which case zlib just copies it as it is, adding a 1-byte header and a 1-byte EOB marker. 2. 64K is just the *upper limit*, and blocks may be shorter. 3. If zlib compressed data (i.e., applied LZ77 & Huffman), blocks may have arbitrary length. So, I don't see any reason why I can't. -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem mounting dvd if the drive spin down
On Sat, 2005-04-02 at 11:30 -0800, Andrew Morton wrote:
> Did it work OK under any other kernel versions? If so, which?
At least it works in 2.6.7, I jump from .7 to .9 then .10 and
finally .11, I notice this problem in 2.6.10 firstly.
If you need addictional info about the drive just ask.
I forgot to say that at boot time hdparm is run on the device:
hdparm -c1 -d1 -u1 -X66 /dev/hdc
Thank you.
P.S.
hdc: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hdc: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hdc: ide_intr: huh? expected NULL handler on exit
hdc: ATAPI reset complete
end_request: I/O error, dev hdc, sector 64
isofs_fill_super: bread failed, dev=hdc, iso_blknum=16, block=16
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 01:45:58PM +0400, Artem B. Bityuckiy wrote:
>
> Here is a cite from RFC-1951 (page 4):
>
>A compressed data set consists of a series of blocks, corresponding
>to successive blocks of input data. The block sizes are arbitrary,
>except that non-compressible blocks are limited to 65,535 bytes.
>
> Thus,
>
> 1. 64K is only applied to non-compressible data, in which case zlib just
> copies it as it is, adding a 1-byte header and a 1-byte EOB marker.
I think the overhead could be higher. But even if it is 2 bytes
per block, then for 1M of incompressible input the total overhead is
2 * 1048576 / 65536 = 32
bytes.
Also I'm not certain if it will actually create 64K blocks. It might
be as low as 16K according to the zlib documentation.
> 3. If zlib compressed data (i.e., applied LZ77 & Huffman), blocks may
> have arbitrary length.
Actually there is a limit on that too but that's not relevant to
this discussion.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, 2005-04-03 at 20:00 +1000, Herbert Xu wrote: > > 1. 64K is only applied to non-compressible data, in which case zlib just > > copies it as it is, adding a 1-byte header and a 1-byte EOB marker. > > I think the overhead could be higher. But even if it is 2 bytes > per block, then for 1M of incompressible input the total overhead is > > 2 * 1048576 / 65536 = 32 We're not interested in the _total_ overhead, in this context. We're interested in the number of bytes we have to have available in the output buffer in order to let zlib finish its stream. In the case of a 1MiB input generating 32 uncompressable 64KiB blocks, the end markers for the first 31 blocks are going to be in our output buffer already, so we don't need to leave space for them. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 11:06:01AM +0100, David Woodhouse wrote:
>
> We're not interested in the _total_ overhead, in this context. We're
> interested in the number of bytes we have to have available in the
> output buffer in order to let zlib finish its stream.
>
> In the case of a 1MiB input generating 32 uncompressable 64KiB blocks,
> the end markers for the first 31 blocks are going to be in our output
> buffer already, so we don't need to leave space for them.
You might be right. But I'm not sure yet.
If we use the current code and supply zlib_deflate with 1048576-12 bytes
of (incompressible) input and 1048576 bytes of output buffer, wouldn't
zlib keep writing incompressible blocks and return when it can't do that
anymore because the output buffer has been exhausted?
When it does return it has to finish writing the last block it's on.
So if the total overhead is 32 bytes then the last block would need
another 20 bytes of output space which we don't have, no?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: On Sun, Apr 03, 2005 at 01:45:58PM +0400, Artem B. Bityuckiy wrote: I think the overhead could be higher. IIUC, not. But I'll check this in practice. But even if it is 2 bytes Ok, suppose. per block, then for 1M of incompressible input the total overhead is 2 * 1048576 / 65536 = 32 bytes. I've given an example why is this OK. Shortly, because we need to reserve space only for the EOB marker of the *last* block (1 byte) and for the adler32 (4 bytes). Look closer to the algorithm. It consists of 2 parts. 1. We reserve 12 bytes And compress as much as possible to the output buffer with Z_SYNC_FLUSH. Zlib produces: | stream header | Block 1 () | -> more | Block 2 () | ... etc ... |-> more | Block N () | -> more | Last block ( Here zlib stops on, say 25 KiB because there is no more room for output. 2. We call zlib_deflate() with Z_FINISH and provide additional 12 bytes. After zlib_deflate() has finished, the output stream is: | stream header | Block 1 () | -> more | Block 2 () | ... etc ... |-> more | Block N () | -> more | Last block () | adler32 | And all is OK. Actually there is a limit on that too but that's not relevant to this discussion. Agreed :-) -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in set_spdif_output in i810_audio
try turning off your internal modem in bios until someone works out whats going
on here
SuD (Alex) wrote:
Hi, i got a new ahtec laptop and i get null pointer oops everytime i
load i810_audio on 2.4 and 2.6 (including 2.6.11.6) kernels.
*** These are init messages & oops:
i810_audio: Unknown symbol ac97_set_dac_rate
i810_audio: Unknown symbol ac97_release_codec
i810_audio: Unknown symbol ac97_set_adc_rate
i810_audio: Unknown symbol ac97_alloc_codec
i810_audio: Unknown symbol ac97_probe_codec
Intel 810 + AC97 Audio, version 1.01, 04:15:45 Jan 24 2005
ACPI: PCI interrupt :00:1f.5[B] -> GSI 10 (level, low) -> IRQ 10
i810: Intel ICH4 found at IO 0x18c0 and 0x1c00, MEM 0xe0100c00 and
0xe0100800, IRQ 10
i810: Intel ICH4 mmio at 0xde9f3c00 and 0xdea84800
i810_audio: Primary codec has ID 0
i810_audio: Audio Controller supports 6 channels.
i810_audio: Defaulting to base 2 channel mode.
i810_audio: Resetting connection 0
i810_audio: Connection 0 with codec id 0
ac97_codec: AC97 Modem codec, id: CXT48 (Unknown)
i810_audio: codec 0 is a softmodem - skipping.
...
EIP:0060:[]Not tainted
EFLAGS: 00010246 (2.6.8-2-686)
EIP is at i810_set_spdif_output+0x22/0x160 [i810_audio]
eax: ebx: ecx: d9c28400 edx: d9c28400
esi: edi: ebp: d6edfb80 esp: d7383e30
ds: 007b es: 007b ss: 0068
Process insmod (pid: 3358, threadinfo=d7382000 task=dca643b0)
Stack: 4461 ffce c011c7f4 d6edfb80 d6edfc18
dec4ff9f d6edfb80 dec51740 d7383e7c dda3c240
0a04
d9c28400 dec4fdb0 d6edfbb0 d9c28400 0001
0001
Call Trace:
[] release_console_sem+0xc4/0xd0
[] i810_configure_clocking+0xbf/0x4c0 [i810_audio]
[] i810_ac97_init+0x4a0/0x5d0 [i810_audio]
[] i810_probe+0x4af/0x690 [i810_audio]
*** This is my device:
:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
Subsystem: QUANTA Computer Inc: Unknown device 0707
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at 1c00 [size=256]
I/O ports at 18c0 [size=64]
Memory at e0100c00 (32-bit, non-prefetchable) [size=512]
Memory at e0100800 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
*** What happened in set_spdif_output:
struct ac97_codec *codec = state->card->ac97_codec[0];
// ... for some reason codec is NULL, and then
if(!codec->codec_ops->digital)
// ... oops
*** Why is that null?
Perhaps it is because the driver thinks that the card is a modem and
releases it. So no codecs are available, but some functions expect at
least one codec to exist.
if(codec->modem)
{
printk(KERN_WARNING "i810_audio: codec %d is a
softmodem - skipping.\n", ac97_id);
ac97_release_codec(codec);
And is detected as modem because of this condition (in ac97_codec.c):
/* Check for an AC97 1.0 soft modem (ID1) */
if(codec->codec_read(codec, AC97_RESET) & 2)
I don't know much about ac97, i also have an ac97 modem. Anybody knows
what is wrong?
Btw, Alsa snd-intel8x0 driver works, but as many distros still default
to Oss i think this bug should be hunt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote:
You might be right. But I'm not sure yet.
If we use the current code and supply zlib_deflate with 1048576-12 bytes
of (incompressible) input and 1048576 bytes of output buffer, wouldn't
zlib keep writing incompressible blocks and return when it can't do that
anymore because the output buffer has been exhausted?
It must not. Look at the algoritm closer.
stream->next_in = (u8 *)src;
stream->next_out = dst;
while (stream->total_in < *slen
&& stream->total_out < *dlen - DEFLATE_PCOMPR_RESERVE) {
stream->avail_out = *dlen - DEFLATE_PCOMPR_RESERVE -
stream->total_out;
stream->avail_in = min((unsigned int)(*slen -
stream->total_in), stream->avail_out);
ret = zlib_deflate(stream, Z_SYNC_FLUSH);
if (ret != Z_OK)
return -EINVAL;
}
stream->avail_out += DEFLATE_PCOMPR_RESERVE;
stream->avail_in = 0; /* <-- no more input ! -- */
ret = zlib_deflate(stream, Z_FINISH);
if (ret != Z_STREAM_END)
return -EINVAL;
When it does return it has to finish writing the last block it's on.
No, it must only put EOB and adler32, we won't give it more input.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix u32 vs. pm_message_t in arm
On Tue, Mar 29, 2005 at 09:15:43PM +0200, Pavel Machek wrote: > This fixes u32 vs. pm_message_t confusion in arm. I was not able to > even compile it, but it should not cause any problems. Please apply, On testing this patch, it doesn't build. You need to include linux/pm.h into linux/sysdev.h for starters, and fix sysdev.h to also use pm_message_t in it's function pointers. Therefore, I'd like the following patch either to be in mainline first, or in my ARM tree for Linus to pull so ARM doesn't completely break on my next merge. = include/linux/sysdev.h 1.7 vs edited = --- 1.7/include/linux/sysdev.h 2004-02-13 06:18:02 +00:00 +++ edited/include/linux/sysdev.h 2005-04-03 11:30:13 +01:00 @@ -22,6 +22,7 @@ #define _SYSDEV_H_ #include +#include struct sys_device; -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix u32 vs. pm_message_t in arm
Hi! > > This fixes u32 vs. pm_message_t confusion in arm. I was not able to > > even compile it, but it should not cause any problems. Please apply, > > On testing this patch, it doesn't build. You need to include > linux/pm.h into linux/sysdev.h for starters, and fix sysdev.h > to also use pm_message_t in it's function pointers. > > Therefore, I'd like the following patch either to be in mainline first, > or in my ARM tree for Linus to pull so ARM doesn't completely break > on my next merge. That patch was recently merged into -mm, so I hope its okay... Thanks for testing. (And sorry, I did not realize patches depend on each other this way). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: LaCie SilverScreen Runs Linux, But No Source
In their comapany blurb to investors, they also claim "in-house approach to R&D and design", "The design of most product components", including "control software". No mention is made of Linux and an equally hard rub, it's only supposed to talk to Windows and Mac. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux for all Computing Tasks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched /HT processor
On Sun, 3 Apr 2005, Arun Srinivas wrote: > > I looked at my "include/asm-i386/param.h" and the HZ value is 1000.So, I > suppose the timer interrupt frequency is 1000 times per sec. or once every 1 > millisec. > > So, is scheduler_tick() ( for resceduling) called only once every 1 ms?? I am > measuring the time when 2 of my processes are scheduled in a HT processor.So, > the possible timedifference of when my 2 processes are scheduled can be only > the following: > > 1) 0 (if both of my processes are scheduled @ the same time since its a HT) > 2) 1ms ( this is the min. possible time diff. > 3) some value greater than 1 ms > Is the above argument correct? A reschedule can happen once every ms, but also upon returning to userspace and when returning from an interrupt handler, and also when something in the kernel explicitly calls schedule() or sleeps (which in turn results in a call to schedule()). And each CPU runs schedule() independently. At least that's my understanding of it - if I'm wrong I hope someone on the list will correct me. -- Jesper Juhl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, 2005-04-03 at 20:17 +1000, Herbert Xu wrote: > You might be right. But I'm not sure yet. > > If we use the current code and supply zlib_deflate with 1048576-12 > bytes of (incompressible) input and 1048576 bytes of output buffer, > wouldn't zlib keep writing incompressible blocks and return when it > can't do that anymore because the output buffer has been exhausted? > > When it does return it has to finish writing the last block it's on. > > So if the total overhead is 32 bytes then the last block would need > another 20 bytes of output space which we don't have, no? Right. We shouldn't feed 1048576-12 bytes into zlib and expect the output to fit into our 1048576-byte buffer. We could get away with that kind of thing when we were using Z_SYNC_FLUSH but we can't now. But now we're not using Z_SYNC_FLUSH it doesn't matter if we feed the input in smaller chunks. We can calculate a conservative estimate of the amount we'll fit, and keep feeding it input till the amount of space left in the output buffer is 12 bytes. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
Ok - that flies, or at least walks. It took 53 seconds to compute this cost matrix. Here's what it prints, on a small 8 CPU ia64 SN2 Altix, with the migration_debug prints formatted separately from the primary table, for ease of reading: Total of 8 processors activated (15548.60 BogoMIPS). - migration cost matrix (max_cache_size: 0, cpu: -1 MHz): - [00][01][02][03][04][05][06][07] [00]: - 4.0(0) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) [01]: 4.0(0)-21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) [02]: 21.7(1) 21.7(1)- 4.0(0) 21.7(1) 21.7(1) 21.7(1) 21.7(1) [03]: 21.7(1) 21.7(1) 4.0(0)-21.7(1) 21.7(1) 21.7(1) 21.7(1) [04]: 21.7(1) 21.7(1) 21.7(1) 21.7(1)- 4.0(0) 21.7(1) 21.7(1) [05]: 21.7(1) 21.7(1) 21.7(1) 21.7(1) 4.0(0)-21.7(1) 21.7(1) [06]: 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1)- 4.0(0) [07]: 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 4.0(0)- - cacheflush times [2]: 4.0 (4059264) 21.7 (21764604) - -> [0][1][10485760] 0.0 (0): (236441590 260844347 -24402757) -> [0][1][9961472] 0.0 (0): (223517112 247446351 -23929239) -> [0][1][9463398] 0.0 (0): (210676318 234128642 -23452324) -> [0][1][8990228] 0.0 (0): (199150391 222962366 -23811975) -> [0][1][8540716] 0.0 (0): (188000682 211792893 -23792211) -> [0][1][8113680] 0.0 (0): (177705384 201661649 -23956265) -> [0][1][7707996] 0.0 (0): (167300335 190993072 -23692737) -> [0][1][7322596] 0.0 (0): (157792762 181764189 -23971427) -> [0][1][6956466] 0.0 (0): (148554966 172428430 -23873464) -> [0][1][6608642] 0.0 (0): (140208195 163875201 -23667006) -> [0][1][6278209] 0.0 (0): (131352820 155083956 -23731136) -> [0][1][5964298] 0.0 (0): (123604215 147567322 -23963107) -> [0][1][5666083] 0.0 (0): (116411565 140028494 -23616929) -> [0][1][5382778] 0.0 (0): (109268755 133013626 -23744871) -> [0][1][5113639] 0.0 (0): (102398180 126017425 -23619245) -> [0][1][4857957] 0.0 (0): (95917364 119835534 -23918170) -> [0][1][4615059] 0.0 (0): (90016707 114103575 -24086868) -> [0][1][4384306] 0.0 (0): (84323765 108006547 -23682782) -> [0][1][4165090] 0.0 (0): (79059754 102627005 -23567251) -> [0][1][3956835] 0.0 (0): (73688423 97291492 -23603069) -> [0][1][3758993] 0.0 (0): (68716008 88560989 -19844981) -> [0][1][3571043] 0.0 (0): (63733160 81897350 -18164190) -> [0][1][3392490] 0.0 (0): (59879383 74232277 -14352894) -> [0][1][3222865] 0.0 (0): (56841544 66555118 -9713574) -> [0][1][3061721] 0.0 (0): (52946522 56831787 -3885265) -> [0][1][2908634] 2.1 (0): (48782033 46610015 2172018) -> [0][1][2763202] 7.4 (0): (45641483 38180422 7461061) -> [0][1][2625041] 8.1 (0): (42666487 34547956 8118531) -> [0][1][2493788] 8.1 (0): (40480659 32408260 8072399) -> [0][1][2369098] 8.1 (0): (37962874 30163246 7799628) -> [0][1][2250643] 8.1 (0): (34472406 26857206 7615200) -> [0][1][2138110] 8.1 (0): (31271314 23649223 7622091) -> [0][1][2031204] 8.1 (0): (28089754 21439413 6650341) -> [0][1][1929643] 8.1 (0): (26354009 18543359 7810650) -> [0][1][1833160] 8.1 (0): (21147235 14447434 6699801) -> [0][1][1741502] 8.1 (0): (18121355 12206595 5914760) -> [0][1][1654426] 8.1 (0): (15329605 10598656 4730949) -> [0][1][1571704] 8.1 (0): (13611633 8689517 4922116) -> [0][1][1493118] 8.1 (0): (11372044 6757841 4614203) -> [0][1][1418462] 8.1 (0): ( 9444150 4882452 4561698) -> [0][1][1347538] 8.1 (0): ( 8191406 4085242 4106164) -> [0][1][1280161] 8.1 (0): ( 7790609 3898213 3892396) -> [0][1][1216152] 8.1 (0): ( 7374407 3707184 3667223) -> [0][1][1155344] 8.1 (0): ( 6999015 3515903 3483112) -> [0][1][1097576] 8.1 (0): ( 6673248 3322754 3350494) -> [0][1][1042697] 8.1 (0): ( 6335524 3161843 3173681) -> [0][1][ 990562] 8.1 (0): ( 6004402 3008483 2995919) -> [0][1][ 941033] 8.1 (0): ( 5725906 2863829 2862077) -> [0][1][ 893981] 8.1 (0): ( 5426110 2734901 2691209) -> [0][1][ 849281] 8.1 (0): ( 5140906 2596169 2544737) -> [0][1][ 806816] 8.1 (0): ( 4898502 2465125 2433377) -> [0][1][ 766475] 8.1 (0): ( 4649361 2349720 2299641) -> [0][1][ 728151] 8.1 (0): ( 4427640 2224358 2203282) -> [0][1][ 691743] 8.1 (0): ( 4205722 2113134 2092588) -> [0][1][ 657155] 8.1 (0): ( 3991213 1997003 1994210) -> [0][1][ 624297] 8.1 (0): ( 3808184 1922251 1885933) -> [0][1][ 593082] 8.1 (0): ( 3637960 1824619 1813341) -> [0][1][ 563427] 8.1 (0): ( 3436507 1717571 1718936) -> [0][1][ 535255] 8.1 (0): ( 3258815 1638947 1619868) -> [0][1][ 508492] 8.1 (0): ( 310 1554970 1552807) -> [0][1][ 483067] 8.1 (0): ( 2947291 1476728 1470563) -> [0][1][ 458913] 8.1 (0): ( 2791433 1408435 1382998) -> [0][1][ 435967] 8.1 (0): ( 2652944 1322870 1330074) -> [0][1][ 414168] 8.1 (0): ( 2535588 1270619 1264969) -> [0][1][ 393459] 8.1 (0): ( 241221
Re: [PATCH] Reduce stack usage in acct.c
Yum Rayan <[EMAIL PROTECTED]> writes:
> Attempt to reduce stack usage in acct.c (linux-2.6.12-rc1-mm3). Stack
> usage was noted using checkstack.pl. Specifically:
>
> Before patch
>
> check_free_space - 128
>
> After patch
> ---
> check_free_space - 36
>
> Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>
>
> --- a/kernel/acct.c 2005-03-25 22:11:06.0 -0800
> +++ b/kernel/acct.c 2005-03-30 15:33:05.0 -0800
> @@ -103,30 +103,32 @@
> */
> static int check_free_space(struct file *file)
> {
> - struct kstatfs sbuf;
> - int res;
> - int act;
> - sector_t resume;
> - sector_t suspend;
> + struct kstatfs *sbuf = NULL;
> + int res, act;
> + sector_t resume, suspend;
I can't see how you expect to save 128-36=92 bytes here. You replace
sizeof(struct kstatfs)=64 with sizeof(struct kstatfs*)=4, which would
be a saving of 60 bytes. But the call to kmalloc()/kfree() reduces
your stack saving further, not to mention the runtime penalty,
introduced by allocating dynamic memory.
Regards, Olaf.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 12:19:17PM +0100, David Woodhouse wrote:
>
> But now we're not using Z_SYNC_FLUSH it doesn't matter if we feed the
> input in smaller chunks. We can calculate a conservative estimate of the
> amount we'll fit, and keep feeding it input till the amount of space
> left in the output buffer is 12 bytes.
Yes that's what we should do. In fact newer versions of zlib carries
a deflateBound function which we can invert to calculate the conservative
estimate.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert,
I also wonder, does it at all correct to use negative windowBits in
crypto API? I mean, if windowBits is negative, zlib doesn't produce the
proper zstream header, which is incorrect according to RFC-1950. It also
doesn't calculate adler32.
For example, if we work over an IP network (RFC-2384), the receiving
side may be confused by such a "stripped" zstream.
Isn't it conceptually right to produce *correct* zstream, with the
header and the proper adler32 ?
Yes, for JFFS2 we would like to have no adler32, we anyway protect our
data by CRC32. But I suppose this should be an additional feature.
Comments?
Herbert Xu wrote:
I made the changes to deflate_decompr() because the old version doesn't
work properly for me. There are 2 changes.
1. I've added the following code:
if (slen > 2 && !(src[1] & PRESET_DICT) /* No preset dictionary */
&& ((src[0] & 0x0f) == Z_DEFLATED) /* Comp. method byte is OK */
&& !(((src[0] << 8) + src[1]) % 31)) { /* CMF*256 + FLG */
stream->next_in += 2;
stream->avail_in -= 2;
}
The reason you need to add this is because the window bits that
was used to produce the compressed data is positive while the window
bits crypto/deflate is using to perform the decompression isn't.
So what we should do here is turn window bits into a configurable
parameter.
Once you supply the correct window bits information, the above is
then simply an optimisation.
Rather than keeping the above optimisation, JFFS should simply do
the compression with a negative window bits value.
Of course to maintain backwards compatibility you'll need to do this
as a new compression type.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 02:23:42PM +0400, Artem B. Bityuckiy wrote:
>
> It must not. Look at the algoritm closer.
This relies on implementation details within zlib_deflate, which may
or may not be the case.
It should be easy to test though. Just write a user-space program
which does exactly this and feed it something from /dev/urandom.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 03:41:07PM +0400, Artem B. Bityuckiy wrote:
>
> I also wonder, does it at all correct to use negative windowBits in
> crypto API? I mean, if windowBits is negative, zlib doesn't produce the
It's absolutely correct for IPComp. For other uses it may or may not
be correct.
For instance for JFFS2 it's absolutely incorrect since it breaks
compatibility. Incidentally, JFFS should create a new compression
type that doesn't include the zlib header so that we don't need the
head-skipping speed hack.
> proper zstream header, which is incorrect according to RFC-1950. It also
Can you please point me to the paragraph in RFC 1950 that says this?
> Isn't it conceptually right to produce *correct* zstream, with the
> header and the proper adler32 ?
Not really. However it should be possible if the user needs it which
is why we should make windowBits configurable.
> Yes, for JFFS2 we would like to have no adler32, we anyway protect our
> data by CRC32. But I suppose this should be an additional feature.
Yes, I'd love to see a patch that makes windowBits configurable in
crypto/deflate.c.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: Can you please point me to the paragraph in RFC 1950 that says this? Ok, if to do s/correct/compliant/, here it is: Section 2.3, page 7 --- A compliant compressor must produce streams with correct CMF, FLG and ADLER32, but need not support preset dictionaries. ... A compliant decompressor must check CMF, FLG, and ADLER32, and provide an error indication if any of these have incorrect values. A compliant decompressor must give an error indication if CM is not one of the values defined in this specification (only the value 8 is permitted in this version), since another value could indicate the presence of new features that would cause subsequent data to be interpreted incorrectly --- -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Use of C99 int types
Hi, I've been working on a new DES implementation for Linux, and ran into the problem of how to get access to C99 types like uint_fast32_t for internal (not interface) use. In my tests, key setup on Athlon 64 slows down by 40% when using u32 instead of uint_fast32_t. So I wonder if there is any standard way of, say, including stdint.h for internal use in kernel code? Dag Arne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: On Sun, Apr 03, 2005 at 03:41:07PM +0400, Artem B. Bityuckiy wrote: I also wonder, does it at all correct to use negative windowBits in crypto API? I mean, if windowBits is negative, zlib doesn't produce the It's absolutely correct for IPComp. For other uses it may or may not be correct. I've looked through RFC-2394 quickly, but didn't found any mention about non-complient zstreams. I suppose they must be complient by default. Although I'm far not an expert in the area. For instance for JFFS2 it's absolutely incorrect since it breaks compatibility. Incidentally, JFFS should create a new compression type that doesn't include the zlib header so that we don't need the head-skipping speed hack. Anyway, in JFFS2 we may do that "hack" before calling pcompress(), so it isn't big problem. Yes, I'd love to see a patch that makes windowBits configurable in crypto/deflate.c. I wonder, do we really want this? Imagine we have 100 different compressors, and each is differently configurable. It may make cryptoAPI messy. May be it is better to stand that user must use deflate (and the other 99 compressors) directly if he wants something not standard/compliant? -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 03:53:40PM +0400, Artem B. Bityuckiy wrote:
> Herbert Xu wrote:
> >Can you please point me to the paragraph in RFC 1950 that says this?
>
> Ok, if to do s/correct/compliant/, here it is:
>
> Section 2.3, page 7
Sorry, I thought you were referring to an RFC that defined IPComp/deflate.
RFC 1950 only defines what a zlib compressed data stream should
look like, it does not define what a deflate compressed data
stream is.
RFC 2394 which defines IPComp/deflate only refers to the deflate
document, and not zlib.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote: > > I've been working on a new DES implementation for Linux, and ran into > the problem of how to get access to C99 types like uint_fast32_t for > internal (not interface) use. In my tests, key setup on Athlon 64 slows > down by 40% when using u32 instead of uint_fast32_t. If you look in stdint.h you may find that uint_fast32_t is actually 64 bits on Athlon 64 ... so does it help if you use u64? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp2IDM7zeS3Z.pgp Description: PGP signature
Re: [RFC] CryptoAPI & Compression
On Sun, Apr 03, 2005 at 04:01:19PM +0400, Artem B. Bityuckiy wrote:
>
> >For instance for JFFS2 it's absolutely incorrect since it breaks
> >compatibility. Incidentally, JFFS should create a new compression
> >type that doesn't include the zlib header so that we don't need the
> >head-skipping speed hack.
>
> Anyway, in JFFS2 we may do that "hack" before calling pcompress(), so it
> isn't big problem.
It still makes sense to use a negative window bits for JFFS since it
means that you don't have to calculate the adler checksum in the
first place AND you don't have to store the zlib header/trailer on
disk.
BTW, that hack can only be applied when there is no preset dictionary.
Although the Linux implementation of JFFS probably never used a preset
dictionary, it is theoretically possible that someone out there may
have generated a JFFS image which contains a compressed stream that has
a preset dictionary.
In that case if you don't set the window bits to a postive value it
won't work at all.
> >Yes, I'd love to see a patch that makes windowBits configurable in
> >crypto/deflate.c.
>
> I wonder, do we really want this?
Yes since the the window bits determines the compression quality and
the amount of memory used. This is going to differ depending on the
application.
> Imagine we have 100 different compressors, and each is differently
> configurable. It may make cryptoAPI messy. May be it is better to stand
> that user must use deflate (and the other 99 compressors) directly if he
> wants something not standard/compliant?
Each crypto/deflate user gets their own private zlib instance.
Where is the problem?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Oops in set_spdif_output in i810_audio
On Sat, Apr 02, 2005 at 04:28:40PM -0800, Andrew Morton wrote:
>
> *** These are init messages & oops:
> i810_audio: Unknown symbol ac97_set_dac_rate
> i810_audio: Unknown symbol ac97_release_codec
> i810_audio: Unknown symbol ac97_set_adc_rate
> i810_audio: Unknown symbol ac97_alloc_codec
> i810_audio: Unknown symbol ac97_probe_codec
The codec initialisation failed so the codec is NULL.
> EIP is at i810_set_spdif_output+0x22/0x160 [i810_audio]
Boom as we dereferenced the codec.
Is there any reason why we should allow i810_probe to succeed
when there is no codec?
If not we can make i810_ac97_init fail in this case.
If so then we'll have to make sure that every dereference of
codec in this driver checks whether it's NULL.
I personally don't see a reason why we should allow it to
continue when the codec doesn't exist. What do you guys think?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: Each crypto/deflate user gets their own private zlib instance. Where is the problem? Hmm, OK. No problems, that was just RFC. :-) -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Oops in set_spdif_output in i810_audio
On Sun, Apr 03, 2005 at 10:14:27PM +1000, herbert wrote:
>
> I personally don't see a reason why we should allow it to
> continue when the codec doesn't exist. What do you guys think?
Actually, anybody trying to use this driver without a codec
would've hit the same crash. Since nobody has complained
before, we should just fail the registration if there is
no codec.
Then we can get rid of all the existing codec != NULL checks.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
Stephen Rothwell wrote: On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote: I've been working on a new DES implementation for Linux, and ran into the problem of how to get access to C99 types like uint_fast32_t for internal (not interface) use. In my tests, key setup on Athlon 64 slows down by 40% when using u32 instead of uint_fast32_t. If you look in stdint.h you may find that uint_fast32_t is actually 64 bits on Athlon 64 ... so does it help if you use u64? Yes, but wouldn't it be much better to avoid code like the following, which may also be wrong (in terms of speed)? #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64? #define fast_u32 u64 #else #define fast_u32 u32 #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clock runs at double speed on x86_64 system w/ATI RS200 chipset
On Sat, 2 Apr 2005 13:19:44 -0500 (EST), Christopher Allen Wing wrote: >On Sat, 2 Apr 2005, Mikael Pettersson wrote: > >> >APIC error on CPU0: 00(40) >> >APIC error on CPU0: 40(40) >> >> Those are "received illegal vector" errors, and they >> typically indicate hardware flakiness or BIOS issues. >> >> Could be inadequate power supply, inadequate cooling, >> a BIOS bug (please check for updates), a too new CPU >> (again, check for a BIOS update), or simply a poorly- >> designed mainboard. > > >Thanks. I tried the latest BIOS for the board but that did not resolve the >problem. The clock still runs at double speed (2000 timer >interrupts/second instead of 1000) and I still get the APIC errors. > >I'll enter a support request with the manufacturer. > > > >I was able to get the problem to go away by using a BIOS option to >"disable APIC mode". When I do this the kernel outputs at boot: > > ACPI: Using PIC for interrupt routing > >and the output of /proc/interrupts reads 'XT-PIC' for everything. > > >If anyone has a suggestion for debugging the clock problem in APIC mode >I'd be interested. I'm guessing that something is causing the timer >interrupt to be mapped twice- are there any tools for looking at the ACPI >tables that may help, or are there kernel boot options to give more detail >about how the interrupt routing is being set up? Well, first step is to try w/o ACPI. ACPI is inherently fragile and bugs there can easily explain your timer problems. Either recompile with CONFIG_ACPI=n, or boot with "acpi=off pci=noacpi". /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RCU in kernel/intermodule.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch, compiled against version 2.6.12-rc1, implements RCU mechanism in
intermodule functions.
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
- --- ./kernel/intermodule.c.orig 2005-04-01 19:25:26.0 +
+++ ./kernel/intermodule.c 2005-04-02 02:46:22.0 +
@@ -3,7 +3,7 @@
/* Written by Keith Owens Oct 2000 */
#include
#include
- -#include
+#include
#include
#include
@@ -14,7 +14,6 @@
*/
static struct list_head ime_list = LIST_HEAD_INIT(ime_list);
- -static DEFINE_SPINLOCK(ime_lock);
static int kmalloc_failed;
struct inter_module_entry {
@@ -22,8 +21,17 @@ struct inter_module_entry {
const char *im_name;
struct module *owner;
const void *userdata;
+ struct rcu_head rcu;
};
+static void inter_module_free(struct rcu_head *rcu)
+{
+ struct inter_module_entry *ime;
+
+ ime = container_of(rcu, struct inter_module_entry, rcu);
+ kfree(ime);
+}
+
/**
* inter_module_register - register a new set of inter module data.
* @im_name: an arbitrary string to identify the data, must be unique
@@ -36,7 +44,6 @@ struct inter_module_entry {
*/
void inter_module_register(const char *im_name, struct module *owner, const
void *userdata)
{
- - struct list_head *tmp;
struct inter_module_entry *ime, *ime_new;
if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
@@ -52,19 +59,15 @@ void inter_module_register(const char *i
ime_new->owner = owner;
ime_new->userdata = userdata;
- - spin_lock(&ime_lock);
- - list_for_each(tmp, &ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ list_for_each_entry(ime, &ime_list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
- - spin_unlock(&ime_lock);
kfree(ime_new);
/* Program logic error, fatal */
printk(KERN_ERR "inter_module_register: duplicate
im_name '%s'", im_name);
BUG();
}
}
- - list_add(&(ime_new->list), &ime_list);
- - spin_unlock(&ime_lock);
+ list_add_rcu(&ime_new->list, &ime_list);
}
/**
@@ -77,20 +80,15 @@ void inter_module_register(const char *i
*/
void inter_module_unregister(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
- - spin_lock(&ime_lock);
- - list_for_each(tmp, &ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ list_for_each_entry(ime, &ime_list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
- - list_del(&(ime->list));
- - spin_unlock(&ime_lock);
- - kfree(ime);
+ list_del_rcu(&(ime->list));
+ call_rcu(&ime->rcu, inter_module_free);
return;
}
}
- - spin_unlock(&ime_lock);
if (kmalloc_failed) {
printk(KERN_ERR
"inter_module_unregister: no entry for '%s', "
@@ -115,20 +113,18 @@ void inter_module_unregister(const char
*/
static const void *inter_module_get(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
const void *result = NULL;
- - spin_lock(&ime_lock);
- - list_for_each(tmp, &ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ rcu_read_lock();
+ list_for_each_entry_rcu(ime, &ime_list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
if (try_module_get(ime->owner))
result = ime->userdata;
break;
}
}
- - spin_unlock(&ime_lock);
+ rcu_read_unlock();
return(result);
}
@@ -158,20 +154,18 @@ const void *inter_module_get_request(con
*/
void inter_module_put(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
- - spin_lock(&ime_lock);
- - list_for_each(tmp, &ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ rcu_read_lock();
+ list_for_each_entry(ime, &ime_list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
if (ime->owner)
module_put(ime->owner);
- - spin_unlock(&ime_lock);
+ rcu_read_unlock();
return;
}
}
- - spin_unlock(&ime_lock);
+ rcu_read_unlock();
printk(KERN_ERR "inter_module_put: no entry for '%s'", im_name);
BUG();
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQk6BzMzkDT3RfMB6AQI+BggAu476K
2.6.12-rc1-bk does not boot x86_64
Hello, I tried the recent 2.6.12-rc1-bk5 snapshot from kernel.org. When I want to boot my x86_64 system only a green line appears on screen. The config is the same as in 2.6.12-rc1-bk4 which works flawlessly on my system. I only saw the message that CPU0 and CPU1 where initialized. And then there was Brinnging up CPUs and it stopped. Its an Intel Pentium4 640 with (EMT64,HT,EIST,CIE enabled). The graphic card is an Nvidia 6600GT PCIe device. Thanks Best regards - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-bk does not boot x86_64
> I tried the recent 2.6.12-rc1-bk5 snapshot from kernel.org. > When I want to boot my x86_64 system only a green line appears on screen. > The config is the same as in 2.6.12-rc1-bk4 which works flawlessly on my > system. > > I only saw the message that CPU0 and CPU1 where initialized. And then > there was > Brinnging up CPUs and it stopped. > > Its an Intel Pentium4 640 with (EMT64,HT,EIST,CIE enabled). > The graphic card is an Nvidia 6600GT PCIe device. I had the same nasty surprise this morning, this will probably help: Well, this is a brown paper bag for someone. The new protocol registration locking uses a rwlock to limit access to the protocol list. Unfortunately, the initialisation: static rwlock_t proto_list_lock; Only works to initialise the lock as unlocked on platforms whose unlock signal is all zeros. On other platforms, they think it's already locked and hang forever. Signed-off-by: James Bottomley <[EMAIL PROTECTED]> = net/core/sock.c 1.67 vs edited = --- 1.67/net/core/sock.c2005-03-26 17:04:35 -06:00 +++ edited/net/core/sock.c 2005-04-02 13:37:20 -06:00 @@ -1352,7 +1352,7 @@ EXPORT_SYMBOL(sk_common_release); -static rwlock_t proto_list_lock; +static DEFINE_RWLOCK(proto_list_lock); static LIST_HEAD(proto_list); int proto_register(struct proto *prot, int alloc_slab) - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch][rfc] optimise resched, idle task
Nick Piggin wrote: This actually improves performance noticably (ie. a % or so) on schedule / wakeup happy benchmarks (tbench, on a dual Xeon with HT using mwait idle). Here are some numbers on a 2 socket Xeon with HT and mwait idle. Average of 3 runs, tbench, single client and single server processes on: samethread samecpu othercpu before patch: 188.684 MB/s189.237 MB/s172.306 MB/s after patch : 188.425 MB/s191.628 MB/s174.224 MB/s The improvement on other CPUs should be due to the removal of RMW operations in resched_task. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
Dag Arne Osvik <[EMAIL PROTECTED]> writes: > Yes, but wouldn't it be much better to avoid code like the following, > which may also be wrong (in terms of speed)? > > #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64? > #define fast_u32 u64 > #else > #define fast_u32 u32 > #endif How about using just unsigned long instead? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug] invalid mac address after rebooting (kernel 2.6.11.5)
Peter Baumann wrote:
On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
Peter Baumann <[EMAIL PROTECTED]> wrote:
I'm hitting an annoying bug in kernel 2.6.11.5
Every time I _reboot_ (warmstart) my pc my two network cards won't get
recognized any longer.
Following error message appears on my screen:
PCI: Enabling device :00:0b.0 ( -> 0003)
ACPI: PCI interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
PCI: Setting latency timer of device :00:0b.0 to 64
*** EEPROM MAC address is invalid.
3c59x: vortex_probe1 fails. Returns -22
3c59x: probe of :00:0b.0 failed with error -22
PCI: Enabling device :00:0d.0 ( -> 0003)
ACPI: PCI interrupt :00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19
:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19
PCI: Setting latency timer of device :00:0d.0 to 64
*** EEPROM MAC address is invalid.
3c59x: vortex_probe1 fails. Returns -22
3c59x: probe of :00:0d.0 failed with error -22
This doesn't happen with older kernels (especially with 2.6.10) and so
I've done a binary search and narrowed it down to 2.6.11-rc5 where it
first hits me.
My config, lspci output and the dmesg output of the working and non-working
version can be found at [1]
Feel free to ask if any information is missing or if I am supposed to try
a patch.
Thanks for doing the bsearch - it helps.
There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5.
The only PCI change I see is
--- drivers/pci/pci.c 22 Jan 2005 03:20:37 - 1.71
+++ drivers/pci/pci.c 24 Feb 2005 18:02:37 - 1.72
@@ -268,7 +268,7 @@
return -EIO;
pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc);
- if ((pmc & PCI_PM_CAP_VER_MASK) != 2) {
+ if ((pmc & PCI_PM_CAP_VER_MASK) > 2) {
printk(KERN_DEBUG
"PCI: %s has unsupported PM cap regs version (%u)\n",
dev->slot_name, pmc & PCI_PM_CAP_VER_MASK);
and you're not getting that message (are you?)
Reverting the above patch solved it.
A gentoo user also reported this, but according to the bug report, this
happens on every bootup (as opposed to only every warm boot)
http://bugs.gentoo.org/87142
I asked him to try reverting the patch shown above and that helped his
situation too.
What's next towards getting this fixed for real?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-bk does not boot x86_64
Thanks Alexander this sort this out. No system boots w/o problems :-) Alexander Nyberg wrote: >>I tried the recent 2.6.12-rc1-bk5 snapshot from kernel.org. >>When I want to boot my x86_64 system only a green line appears on screen. >>The config is the same as in 2.6.12-rc1-bk4 which works flawlessly on my >>system. >> >>I only saw the message that CPU0 and CPU1 where initialized. And then >>there was >>Brinnging up CPUs and it stopped. >> >>Its an Intel Pentium4 640 with (EMT64,HT,EIST,CIE enabled). >>The graphic card is an Nvidia 6600GT PCIe device. >> >> > >I had the same nasty surprise this morning, this will probably help: > > >Well, this is a brown paper bag for someone. The new protocol >registration locking uses a rwlock to limit access to the protocol list. >Unfortunately, the initialisation: > >static rwlock_t proto_list_lock; > >Only works to initialise the lock as unlocked on platforms whose unlock >signal is all zeros. On other platforms, they think it's already locked >and hang forever. > >Signed-off-by: James Bottomley <[EMAIL PROTECTED]> > > >= net/core/sock.c 1.67 vs edited = >--- 1.67/net/core/sock.c 2005-03-26 17:04:35 -06:00 >+++ edited/net/core/sock.c 2005-04-02 13:37:20 -06:00 >@@ -1352,7 +1352,7 @@ > > EXPORT_SYMBOL(sk_common_release); > >-static rwlock_t proto_list_lock; >+static DEFINE_RWLOCK(proto_list_lock); > static LIST_HEAD(proto_list); > > int proto_register(struct proto *prot, int alloc_slab) > > >- > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc1-mm4] mips: remove obsolete VR41xx RTC function from vr41xx.h
This patch had removed obsolete VR41xx RTC function from vr41xx.h .
I forgot to put this change in "update VR41xx RTC support".
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h
rc1-mm4/include/asm-mips/vr41xx/vr41xx.h
--- rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h Fri Apr 1 21:21:37 2005
+++ rc1-mm4/include/asm-mips/vr41xx/vr41xx.hSat Apr 2 19:26:58 2005
@@ -198,22 +198,6 @@
extern void vr41xx_disable_bcuint(void);
/*
- * Power Management Unit
- */
-
-/*
- * RTC
- */
-extern void vr41xx_set_rtclong1_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_rtclong1_counter(void);
-
-extern void vr41xx_set_rtclong2_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_rtclong2_counter(void);
-
-extern void vr41xx_set_tclock_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_tclock_counter(void);
-
-/*
* General-Purpose I/O Unit
*/
enum {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Can't use SYSFS for "Proprietry" driver modules !!!.
On 31/3/2005, at 08:30, John Pearson wrote: E.g.: suppose there are 2 snack bars within 100 yards of a school; one is out of sight, across an intersection and down a side street, and one is clearly visible across an empty lot. For years the lot has been unfenced and, human nature being what it is, kids just walk across the open lot. The owner of the lot then decides to put up a high fence around it with a combination lock on the gate (now he's raising chinchillas, or peaches; he won't say) so all the kids start going to the other snackbar, except for a few that he trusts with the combination. It seems to me you're suggesting that the snackbar owner who's lost out would have an action for restraint of trade; I can't see it myself. Well in Austria there is a law: if you walk through an area that is not public and do this for a very long time years and suddenly the owner stops you from doing this, you could sue him for stopping you doing a usual thing. But real life issues and software laws are more than two kind of shoes. They are two kind of universes. Right and Code changes always happens, some approve i some not. And there will be always people not like it. Fact is the kernel is a GPL thing so logically the coders want to keep it GPL, lg, clemens PGP.sig Description: This is a digitally signed message part
Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
Three more observations.
1) The slowest measure_one() calls are, not surprisingly, those for the
largest sizes. At least on my test system of the moment, the plot
of cost versus size has one major maximum (a one hump camel, not two).
Seems like if we computed from smallest size upward, instead of largest
downward, and stopped whenever two consecutive measurements were less
than say 70% of the max seen so far, then we could save a nice chunk
of the time.
Of course, if two hump systems exist, this is not reliable on them.
2) Trivial warning fix for printf format mismatch:
=== begin ===
--- 2.6.12-rc1-mm4.orig/kernel/sched.c 2005-04-03 06:32:34.0 -0700
+++ 2.6.12-rc1-mm4/kernel/sched.c 2005-04-03 06:34:07.0 -0700
@@ -5211,7 +5211,7 @@ void __devinit calibrate_migration_costs
#ifdef CONFIG_X86
cpu_khz/1000
#else
- -1
+ -1L
#endif
);
printk("-\n");
end
3) I was noticing that my test system was only showing a couple of distinct
values for cpu_distance, even though it has 4 distinct distances for
values of node_distance. So I coded up a variant of cpu_distance that
converts the problem to a node_distance problem, and got the following
cost matrix:
=== begin ===
Total of 8 processors activated (15515.64 BogoMIPS).
-
migration cost matrix (max_cache_size: 0, cpu: -1 MHz):
-
[00][01][02][03][04][05][06][07]
[00]: - 4.0(0) 21.7(1) 21.7(1) 25.2(2) 25.2(2) 25.3(3) 25.3(3)
[01]: 4.0(0)-21.7(1) 21.7(1) 25.2(2) 25.2(2) 25.3(3) 25.3(3)
[02]: 21.7(1) 21.7(1)- 4.0(0) 25.3(3) 25.3(3) 25.2(2) 25.2(2)
[03]: 21.7(1) 21.7(1) 4.0(0)-25.3(3) 25.3(3) 25.2(2) 25.2(2)
[04]: 25.2(2) 25.2(2) 25.3(3) 25.3(3)- 4.0(0) 21.7(1) 21.7(1)
[05]: 25.2(2) 25.2(2) 25.3(3) 25.3(3) 4.0(0)-21.7(1) 21.7(1)
[06]: 25.3(3) 25.3(3) 25.2(2) 25.2(2) 21.7(1) 21.7(1)- 4.0(0)
[07]: 25.3(3) 25.3(3) 25.2(2) 25.2(2) 21.7(1) 21.7(1) 4.0(0)-
-
cacheflush times [4]: 4.0 (4080540) 21.7 (21781380) 25.2 (25259428) 25.3
(25372682)
-
end
The code (below) is twice as complicated, the runtime twice as long,
and it's less intuitive - sched_domains seems more appropriate as
the basis for migration costs than the node distances in SLIT tables.
Finally, I don't know if distinguishing between costs of 21.7 and
25.3 is worth much.
So the case for switching to this node_distance base is less than
persuasive, to put it politely.
Perhaps it's only real value is in highlighting that perhaps the
code to setup the sched_domain topology on our ia64 SN2 Altix systems
is too coarse, given that it only found two distance values, not four.
If that's the case, I will have to call in someone else to examine
whether it's appropriate to refine the sched_domains setup for this
kind of system. I'm not competent to determine that, nor to code it.
Here's the code that bases cpu_distance on node_distance:
=== begin ===
__init static int cmpint(const void *a, const void *b)
{
return *(int *)a - *(int *)b;
}
/*
* Estimate distance of two CPUs based on their node_distance,
* mapping to sequential integers 0, 1, ... N-1, for the N
* distinct values of distances (closest CPUs are distance 0,
* farthest CPUs are distance N-1). If there are more than
* MAX_DOMAIN_DISTANCE distinct different distance values,
* collapse the larger distances to one value.
*/
__init static unsigned long cpu_distance(int cpu1, int cpu2)
{
static int num_dist_vals;
static int node_distances[MAX_DOMAIN_DISTANCE];
int dist = node_distance(cpu_to_node(cpu1), cpu_to_node(cpu2));
int v;
if (num_dist_vals == 0) {
int i, j, k;
/*
* For each dist not already in node_distances[], if there's
* room or it's less than an existing 'luser' entry, add it.
*/
for_each_online_node(i) {
for_each_online_node(j) {
int dist = node_distance(i, j);
int luser = -1;
for (k = 0; k < num_dist_vals; k++) {
if (node_distances[k] == dist)
break;
if (dist < node_distances[k])
Re: [RFC,PATCH 2/4] Deprecate synchronize_kernel, GPL replacement
Hi Paul, I'm not quite clear on the difference between the two synchronize functions , the comment for synchronize_sched() seems to have a bit missing? (see below) cheers On Sun, 3 Apr 2005 16:21, Paul E. McKenney wrote: > +/** > + * synchronize_sched - block until all CPUs have exited any non-preemptive > + * kernel code sequences. > + * > + * This means that all preempt_disable code sequences, including NMI and > + * hardware-interrupt handlers, in progress on entry will have completed > + * before this primitive returns. However, this does not guarantee that > + * softirq handlers will have completed, since in some kernels ?? > + * > + * This primitive provides the guarantees made by the (deprecated) > + * synchronize_kernel() API. In contrast, synchronize_rcu() only > + * guarantees that rcu_read_lock() sections will have completed. > + */ > +#define synchronize_sched() synchronize_rcu() pgpCQU2pvnW4Y.pgp Description: PGP signature
Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Ok - that flies, or at least walks. It took 53 seconds to compute
> this cost matrix.
53 seconds is too much - i'm working on reducing it.
> Here's what it prints, on a small 8 CPU ia64 SN2 Altix, with
> the migration_debug prints formatted separately from the primary
> table, for ease of reading:
>
> Total of 8 processors activated (15548.60 BogoMIPS).
> -
> migration cost matrix (max_cache_size: 0, cpu: -1 MHz):
> -
> [00][01][02][03][04][05][06][07]
> [00]: - 4.0(0) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1)
> [01]: 4.0(0)-21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1)
> [02]: 21.7(1) 21.7(1)- 4.0(0) 21.7(1) 21.7(1) 21.7(1) 21.7(1)
> [03]: 21.7(1) 21.7(1) 4.0(0)-21.7(1) 21.7(1) 21.7(1) 21.7(1)
> [04]: 21.7(1) 21.7(1) 21.7(1) 21.7(1)- 4.0(0) 21.7(1) 21.7(1)
> [05]: 21.7(1) 21.7(1) 21.7(1) 21.7(1) 4.0(0)-21.7(1) 21.7(1)
> [06]: 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1)- 4.0(0)
> [07]: 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 21.7(1) 4.0(0)-
how close are these numbers to the real worst-case migration costs on
that box? What are the cache sizes and what is their hierarchies?
i've attached another snapshot - there is no speedup yet, but i've
changed the debug printout to be separate from the matrix printout, and
i've fixed the cache_size printout. (the printout of a 68K cache was
incorrect - that was just the last iteration step)
it will be interesting to see what effect the above assymetry in
migration costs will have on scheduling. With 4msec intra-node cutoff it
should be pretty migration-happy, inter-node 21 msec is rather high and
should avoid unnecessary migration.
is there any workload that shows the same scheduling related performance
regressions, other than Ken's $1m+ benchmark kit?
Ingo
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
@@ -4639,6 +4640,453 @@ void __devinit init_sched_build_groups(s
last->next = first;
}
+/*
+ * Self-tuning task migration cost measurement between source and target CPUs.
+ *
+ * This is done by measuring the cost of manipulating buffers of varying
+ * sizes. For a given buffer-size here are the steps that are taken:
+ *
+ * 1) the source CPU reads a big buffer to flush caches
+ * 2) the source CPU reads+dirties a shared buffer
+ * 3) the target CPU reads+dirties the same shared buffer
+ * 4) the target CPU reads a big buffer to flush caches
+ *
+ * We measure how long steps #2 and #3 take (step #1 and #4 is not
+ * measured), in the following 4 scenarios:
+ *
+ * - source: CPU1, target: CPU2 | cost1
+ * - source: CPU2, target: CPU1 | cost2
+ * - source: CPU1, target: CPU1 | cost3
+ * - source: CPU2, target: CPU2 | cost4
+ *
+ * We then calculate the cost3+cost4-cost1-cost2 difference - this is
+ * the cost of migration.
+ *
+ * We then start off from a large buffer-size and iterate down to smaller
+ * buffer sizes, in 5% steps - measuring each buffer-size separately, and
+ * do a maximum search for the cost. The maximum cost for a migration
+ * occurs when the working set is just below the effective cache size.
+ */
+
+
+/*
+ * Flush the cache by reading a big buffer. (We want all writeback
+ * activities to subside. Works only if cache size is larger than
+ * 2*size, but that is good enough as the biggest migration effect
+ * is around cachesize size.)
+ */
+__init static void read_cache(void *__cache, unsigned long __size)
+{
+ unsigned long size = __size/sizeof(long);
+ unsigned long *cache = __cache;
+ volatile unsigned long data;
+ int i;
+
+ for (i = 0; i < 2*size; i += 4)
+ data = cache[i];
+}
+
+
+/*
+ * Dirty a big buffer in a hard-to-predict (for the L2 cache) way. This
+ * is the operation that is timed, so we try to generate unpredictable
+ * cachemisses that still end up filling the L2 cache:
+ */
+__init static void touch_cache(void *__cache, unsigned long __size)
+{
+ unsigned long size = __size/sizeof(long), chunk1 = size/3,
+ chunk2 = 2*size/3;
+ unsigned long *cache = __cache;
+ int i;
+
+ for (i = 0; i < size/6; i += 4) {
+ switch (i % 6) {
+ case 0: cache[i]++;
+ case 1: cache[size-1-i]++;
+ case 2: cache[chunk1-i]++;
+ case 3: cache[chunk1+i]++;
+ case 4: cache[chunk2-i]++;
+ case 5: cache[chunk2+i]++;
+ }
+ }
+}
+
+struct flush_data {
+ unsigned long source, target;
+ void (*fn)(void *, unsigned long);
+ void *cache;
+ unsigned long size;
+ unsigned long long delta;
+};
+
+/*
+ * Dirty L2 on the source CPU:
+ */
+__init static voi
AIM9 slowdowns between 2.6.11 and 2.6.12-rc1
While testing the page placement policy patches on 2.6.12-rc1, I noticed that aim9 is showing significant slowdowns on page allocation-related tests. An excerpt of the results is at the end of this mail but it shows that page_test is allocating 18000 less pages. I did not check who has been recently changing the buddy allocator but they might want to run a benchmark or two to make sure this is not something specific to my setup. [EMAIL PROTECTED]:~# grep _test vmregressbench-2.6.11-standard/aim9/log.txt 7 page_test 60.01 4420 73.65439 125212.46 System Allocations & Pages/second 8 brk_test60.00 1732 28.86667 490733.33 System Memory Allocations/second 9 jmp_test60.01 252898 4214.26429 4214264.29 Non-local gotos/second 10 signal_test 60.00 5983 99.7166799716.67 Signal Traps/second 11 exec_test 60.01788 13.13114 65.66 Program Loads/second 12 fork_test 60.06986 16.41692 1641.69 Task Creations/second 13 link_test 60.00 6302 105.0 6617.10 Link/Unlink Pairs/second [EMAIL PROTECTED]:~# grep _test vmregressbench-2.6.12-rc1-standard/aim9/log.txt 7 page_test 60.01 3784 63.05616 107195.47 System Allocations & Pages/second 8 brk_test60.02 1194 19.89337 338187.27 System Memory Allocations/second 9 jmp_test60.00 252312 4205.2 4205200.00 Non-local gotos/second 10 signal_test 60.00 3731 62.1833362183.33 Signal Traps/second 11 exec_test 60.08762 12.68309 63.42 Program Loads/second 12 fork_test 60.04864 14.39041 1439.04 Task Creations/second 13 link_test 60.01 4723 78.70355 4958.32 Link/Unlink Pairs/second -- Mel Gorman Part-time Phd Student Java Applications Developer University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] resend, unneeded cli/sti in ret_from_intr path
i386/kernel/entry.S:resume_kernel: is used on return path from do_IRQ() which leaves interrupts disabled. And we have preempt_stop == cli in ret_from_exception: case, before ret_from_intr. So this 'cli' is unneeded. It is ok to enter schedule() with interrupts disabled, so this 'sti' in preempt_schedule_irq() seems to be unneeded too. Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> --- 2.6.12-rc1/arch/i386/kernel/entry.S~CLI 2005-03-21 19:55:51.0 +0300 +++ 2.6.12-rc1/arch/i386/kernel/entry.S 2005-03-21 19:57:58.0 +0300 @@ -176,7 +176,6 @@ ENTRY(resume_userspace) #ifdef CONFIG_PREEMPT ENTRY(resume_kernel) - cli cmpl $0,TI_preempt_count(%ebp) # non-zero preempt_count ? jnz restore_all need_resched: --- 2.6.12-rc1/kernel/sched.c~CLI 2005-03-19 14:16:53.0 +0300 +++ 2.6.12-rc1/kernel/sched.c 2005-03-21 19:57:58.0 +0300 @@ -2851,7 +2851,6 @@ need_resched: saved_lock_depth = task->lock_depth; task->lock_depth = -1; #endif - local_irq_enable(); schedule(); local_irq_disable(); #ifdef CONFIG_PREEMPT_BKL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
* Paul Jackson <[EMAIL PROTECTED]> wrote: > Three more observations. > > 1) The slowest measure_one() calls are, not surprisingly, those for the > largest sizes. At least on my test system of the moment, the plot > of cost versus size has one major maximum (a one hump camel, not two). > > Seems like if we computed from smallest size upward, instead of largest > downward, and stopped whenever two consecutive measurements were less > than say 70% of the max seen so far, then we could save a nice chunk > of the time. > > Of course, if two hump systems exist, this is not reliable on them. yes, this is the approach i'm currently working on, but it's not reliable yet. (one of the systems i have drifts its cost into infinity after the hump, which shouldnt happen) > 2) Trivial warning fix for printf format mismatch: thx. > 3) I was noticing that my test system was only showing a couple of > distinct values for cpu_distance, even though it has 4 distinct > distances for values of node_distance. So I coded up a variant of > cpu_distance that converts the problem to a node_distance problem, > and got the following cost matrix: > > === begin === > Total of 8 processors activated (15515.64 BogoMIPS). > - > migration cost matrix (max_cache_size: 0, cpu: -1 MHz): > - > [00][01][02][03][04][05][06][07] > [00]: - 4.0(0) 21.7(1) 21.7(1) 25.2(2) 25.2(2) 25.3(3) 25.3(3) > [01]: 4.0(0)-21.7(1) 21.7(1) 25.2(2) 25.2(2) 25.3(3) 25.3(3) > [02]: 21.7(1) 21.7(1)- 4.0(0) 25.3(3) 25.3(3) 25.2(2) 25.2(2) > [03]: 21.7(1) 21.7(1) 4.0(0)-25.3(3) 25.3(3) 25.2(2) 25.2(2) > [04]: 25.2(2) 25.2(2) 25.3(3) 25.3(3)- 4.0(0) 21.7(1) 21.7(1) > [05]: 25.2(2) 25.2(2) 25.3(3) 25.3(3) 4.0(0)-21.7(1) 21.7(1) > [06]: 25.3(3) 25.3(3) 25.2(2) 25.2(2) 21.7(1) 21.7(1)- 4.0(0) > [07]: 25.3(3) 25.3(3) 25.2(2) 25.2(2) 21.7(1) 21.7(1) 4.0(0)- > - > cacheflush times [4]: 4.0 (4080540) 21.7 (21781380) 25.2 (25259428) 25.3 > (25372682) i'll first try the bottom-up approach to speed up detection (getting to the hump is very fast most of the time). The hard part was to create a workload that generates the hump reliably on a number of boxes - i'm happy it works on ia64 too. then we can let the arch override the cpu_distance() method, although i do think that _if_ there is a significant hierarchy between CPUs it should be represented via a matching sched-domains hierarchy, and the full hierarchy should be tuned accordingly. btw., the migration cost matrix we can later use to tune all the other sched-domains balancing related tunables as well - cache_hot_time is just the first obvious step. (which also happens to make the most difference.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: initramfs linus tree breakage in last day
Em Fri, Apr 01, 2005 at 10:44:31PM -0800, Andrew Morton escreveu: > Jon Smirl <[EMAIL PROTECTED]> wrote: > > > > This will let me boot again. It is not obvious to me where the problem > > is, it may have something to do with netlink or maybe memory > > corruption? > > > > bk export -tpatch -r1.2326,1.2327 >../foo.patch > > patch -p1 -R <../foo.patch > > > > # ChangeSet > > # 2005/03/31 21:14:28-08:00 [EMAIL PROTECTED] > > # Merge bk://kernel.bkbits.net/acme/net-2.6 > > # into sunset.davemloft.net:/home/davem/src/BK/net-2.6 > > # > > # ChangeSet > > # 2005/03/26 20:04:49-03:00 [EMAIL PROTECTED] > > # [NET] make all protos partially use sk_prot > > Cute. I assume you have all the memory debug options enabled? > > You could try disabling net features in .config, see if you can work out > which one causes it. Question, what are the config choices for netlink? - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix boot hang on some architectures
Em Sat, Apr 02, 2005 at 01:46:03PM -0600, James Bottomley escreveu: > Well, this is a brown paper bag for someone. The new protocol /me using such bag now :( Thanks a lot for the fix. David, Please apply. > registration locking uses a rwlock to limit access to the protocol list. > Unfortunately, the initialisation: > > static rwlock_t proto_list_lock; > > Only works to initialise the lock as unlocked on platforms whose unlock > signal is all zeros. On other platforms, they think it's already locked > and hang forever. > > Signed-off-by: James Bottomley <[EMAIL PROTECTED]> > > > = net/core/sock.c 1.67 vs edited = > --- 1.67/net/core/sock.c 2005-03-26 17:04:35 -06:00 > +++ edited/net/core/sock.c2005-04-02 13:37:20 -06:00 > @@ -1352,7 +1352,7 @@ > > EXPORT_SYMBOL(sk_common_release); > > -static rwlock_t proto_list_lock; > +static DEFINE_RWLOCK(proto_list_lock); > static LIST_HEAD(proto_list); > > int proto_register(struct proto *prot, int alloc_slab) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
* Paul Jackson <[EMAIL PROTECTED]> wrote: > > 3) I was noticing that my test system was only showing a couple of > distinct values for cpu_distance, even though it has 4 distinct > distances for values of node_distance. So I coded up a variant of > cpu_distance that converts the problem to a node_distance problem, > and got the following cost matrix: > The code (below) is twice as complicated, the runtime twice as long, > and it's less intuitive - sched_domains seems more appropriate as > the basis for migration costs than the node distances in SLIT tables. > Finally, I don't know if distinguishing between costs of 21.7 and > 25.3 is worth much. the main problem is that we can do nothing with this matrix: we only print it, but then the values get written into a 0/1 sched-domains hierarchy - so the information is lost. if you create a sched-domains hierarchy (based on the SLIT tables, or in whatever other way) that matches the CPU hierarchy then you'll automatically get the proper distances detected. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] CryptoAPI & Compression
Herbert Xu wrote: This relies on implementation details within zlib_deflate, which may or may not be the case. It should be easy to test though. Just write a user-space program which does exactly this and feed it something from /dev/urandom. Well, Herbert, you're right. In case of non-compressible data things are bad. I'll continue investigating this. -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched /HT processor
On Sun, 2005-04-03 at 13:17 +0200, Jesper Juhl wrote: > > A reschedule can happen once every ms, but also upon returning to > userspace and when returning from an interrupt handler, and also when > something in the kernel explicitly calls schedule() or sleeps (which in > turn results in a call to schedule()). And each CPU runs schedule() > independently. > At least that's my understanding of it - if I'm wrong I hope someone on > the list will correct me. You're correct, but I'll add some more details here. The actual schedule happens when needed. A schedule may not take place at every ms, if the task running is not done with its time slice and no events happened where another task should preempt it. If an RT task is running in a FIFO policy, then it will continue to run until it calls schedule itself or another process of higher priority preempts it. Now if you don't have PREEMPT turned on, than the schedule won't take place at all while a task is in the kernel, unless the task explicitly calls schedule. What happens on a timer interrupt where a task is done with its time slice or another event where a schedule should take place, is just the need_resched flag is set for the task. On return from the interrupt the flag is checked, and if set a schedule is called. This is still a pretty basic description of what really happens, and if you want to learn more, just start searching the kernel code for schedule and need_resched. Don't forget to look in the asm code (ie entry.S, and dependent on your arch other *.S files). -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Hi, I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. (Everyting run smoothly using 2.6.11-mm1) It seems to be related with mounting a reiserfs3 filesystem. Please also note that this kernel was compiled using gcc-4.0-0pre9 (from Debian) I'm using mount 2.12p Please CC: me. Here the OOPs (netconsole captured): input: AT Translated Set 2 keyboard on isa0060/serio0 ReiserFS: hda5: using ordered data mode ReiserFS: hda5: journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda5: checking transaction log (hda5) ReiserFS: hda5: Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Freeing unused kernel memory: 136k freed Adding 497972k swap on /dev/hda6. Priority:-1 extents:1 reiserfs: enabling write barrier flush mode reiserfs: disabling flush barriers on hda5 Real Time Clock Driver v1.12 WDT driver for the Winbond(TM) W83627HF Super I/O chip initialising. w83627hf WDT: initialized. timeout=60 sec (nowayout=0) CSLIP: code copyright 1989 Regents of the University of California PPP generic driver version 2.4.2 ACPI: No ACPI bus support for 0-0290 ReiserFS: hda7: found reiserfs format "3.6" with standard journal ReiserFS: hda7: using ordered data mode reiserfs: using flush barriers ReiserFS: hda7: journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda7: checking transaction log (hda7) reiserfs: disabling flush barriers on hda7 ReiserFS: hda7: Using r5 hash to sort names ReiserFS: hda8: found reiserfs format "3.6" with standard journal ReiserFS: hda8: using ordered data mode reiserfs: using flush barriers ReiserFS: hda8: journal params: device hda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda8: checking transaction log (hda8) reiserfs: disabling flush barriers on hda8 ReiserFS: hda8: Using r5 hash to sort names ReiserFS: hdg1: found reiserfs format "3.6" with standard journal ReiserFS: hdg1: using ordered data mode reiserfs: using flush barriers ReiserFS: hdg1: journal params: device hdg1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hdg1: checking transaction log (hdg1) Unable to handle kernel paging request at virtual address 0a373138 printing eip: df6d1211 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at 0xdf6d1211 eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 ds: 007b es: 007b ss: 0068 Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 c0223051 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c c022333e df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 c0212260 Call Trace: [] flagged_taskfile+0x125/0x380 [] start_request+0x1f1/0x2a0 [] ide_do_request+0x20e/0x3c0 [] __generic_unplug_device+0x20/0x30 [] generic_unplug_device+0x11/0x30 [] blk_backing_dev_unplug+0xc/0x10 [] sync_buffer+0x26/0x40 [] __wait_on_bit+0x42/0x70 [] sync_buffer+0x0/0x40 [] sync_buffer+0x0/0x40 [] out_of_line_wait_on_bit+0x7d/0x90 [] wake_bit_function+0x0/0x60 [] __wait_on_buffer+0x29/0x30 [] _update_journal_header_block+0xf7/0x140 [] journal_read+0x31d/0x470 [] journal_init+0x4e1/0x650 [] printk+0x1b/0x20 [] reiserfs_fill_super+0x34d/0x770 [] snprintf+0x20/0x30 [] disk_name+0x96/0xf0 [] get_sb_bdev+0xe5/0x130 [] link_path_walk+0x65/0x140 [] get_super_block+0x18/0x20 [] reiserfs_fill_super+0x0/0x770 [] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 <1>general p rotection fault: [#2] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010012 (2.6.12-rc1-mm4) EIP is at 0xdf6d1dae eax: df6d1d54 ebx: df6d1d1c ecx: edx: 0003 esi: df62190c edi: ebp: df7a3e80 esp: df7a3e60 ds: 007b es: 007b ss: 0068 Process fsck.reiserfs (pid: 1126, threadinfo=df7a3000 task=df711030) Stack: c0113849 df7a3ea8 0001 0003 c14007f0 df7a3000 df7a3ea8 0286 df7a3e9c c011389f df7a3ea8 c14007f0 c138be00 dfd36330 da0db42c c012c00a df7a3ea8 c138be00 0001 c0145b47 0054 000f Call Trace: [] __wake_up_common+0x39/0x60 [] __wake_up+0x2f/0x60 [] __wake_up_bit+0x2a/0x30 [] do_wp_page+0x1e7/0x340 [] handle_mm_fault+0x184/0x1c0 [] do_page_fault+0x268/0x657 [] free_pgtables+0x82/0xb0 [] unmap_region+0xb2/0x120 [] unmap_vma_list+0xe/0x20 [] do_munmap+
Re: initramfs linus tree breakage in last day
Em Fri, Apr 01, 2005 at 10:30:42PM -0500, Jon Smirl escreveu: > This is what I see on boot. > > -- > Jon Smirl > [EMAIL PROTECTED] > > Linux version 2.6.12-rc1 ([EMAIL PROTECTED]) (gcc version > 3.4.2 200410 > 17 (Red Hat 3.4.2-6.fc3)) #21 SMP Fri Apr 1 22:09:28 EST 2005 > found SMP MP-table at 000fe710 OK, SMP, could you please try this patch by James Bottomley that fixes a brown paper bag bug in my proto_register patch? Regards, - Arnaldo = net/core/sock.c 1.67 vs edited = --- 1.67/net/core/sock.c2005-03-26 17:04:35 -06:00 +++ edited/net/core/sock.c 2005-04-02 13:37:20 -06:00 @@ -1352,7 +1352,7 @@ EXPORT_SYMBOL(sk_common_release); -static rwlock_t proto_list_lock; +static DEFINE_RWLOCK(proto_list_lock); static LIST_HEAD(proto_list); int proto_register(struct proto *prot, int alloc_slab) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech MX1000 Horizontal Scrolling
Esben Stien <[EMAIL PROTECTED]> writes: > Jeremy Nickurak <[EMAIL PROTECTED]> writes: > >> I'm playing with this under 2.6.11.4 > > I got 2.6.12-rc1 > >> The vertical cruise control buttons work properly, with the >> exception of the extra button press. > > Yup, nice, I see the same Same here. >> But the horizontal buttons are mapping to 6/7 as non-repeat >> buttons, and adding simulateously the 4/5 events auto-repeated for >> as long as the button is down. That is to say, pressing the the >> horizontal scroll in a 2d scrolling area will scroll *diagonally* >> one step, then vertically until the button is released. > > Yup, seeing exactly the same here. Horizontal scrolling works fine for me. I just get repeated 6/7 events, nothing else. I'm using the configuration described at: http://blog.blackdown.de/2005/04/03/logitech-mx1000-configuration/ Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://blog.blackdown.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] fix subarch breakage in intel_cacheinfo.c
Errr. That was my oversight. I will compile-test the patches against all sub-archs in future. Thanks for catching this and sending the patch. Thanks, Venki >-Original Message- >From: James Bottomley [mailto:[EMAIL PROTECTED] >Sent: Saturday, April 02, 2005 10:10 AM >To: Andrew Morton >Cc: Pallipadi, Venkatesh; Linux Kernel >Subject: [PATCH] fix subarch breakage in intel_cacheinfo.c > >Not all x86 subarchitectures have support for hyperthreading, so every >piece you add for it has to be predicated on checks for CONFIG_X86_HT. > >The patch corrects this hyperthreading leakage problem in >intel_cacheinfo.c > >Signed-off-by: James Bottomley <[EMAIL PROTECTED]> > >= arch/i386/kernel/cpu/intel_cacheinfo.c 1.3 vs edited = >--- 1.3/arch/i386/kernel/cpu/intel_cacheinfo.c 2005-03-31 >05:06:44 -06:00 >+++ edited/arch/i386/kernel/cpu/intel_cacheinfo.c >2005-04-02 12:03:39 -06:00 >@@ -311,8 +311,10 @@ > > if (num_threads_sharing == 1) > cpu_set(cpu, this_leaf->shared_cpu_map); >+#ifdef CONFIG_X86_HT > else if (num_threads_sharing == smp_num_siblings) > this_leaf->shared_cpu_map = cpu_sibling_map[cpu]; >+#endif > else > printk(KERN_INFO "Number of CPUs sharing cache >didn't match " > "any known set of CPUs\n"); > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: initramfs linus tree breakage in last day
On Apr 3, 2005 11:51 AM, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote: > Em Fri, Apr 01, 2005 at 10:30:42PM -0500, Jon Smirl escreveu: > > This is what I see on boot. > > > > -- > > Jon Smirl > > [EMAIL PROTECTED] > > > > Linux version 2.6.12-rc1 ([EMAIL PROTECTED]) (gcc version > > 3.4.2 200410 > > 17 (Red Hat 3.4.2-6.fc3)) #21 SMP Fri Apr 1 22:09:28 EST 2005 > > found SMP MP-table at 000fe710 > > OK, SMP, could you please try this patch by James Bottomley that fixes > a brown paper bag bug in my proto_register patch? > > Regards, > > - Arnaldo > > = net/core/sock.c 1.67 vs edited = > --- 1.67/net/core/sock.c2005-03-26 17:04:35 -06:00 > +++ edited/net/core/sock.c 2005-04-02 13:37:20 -06:00 > @@ -1352,7 +1352,7 @@ > > EXPORT_SYMBOL(sk_common_release); > > -static rwlock_t proto_list_lock; > +static DEFINE_RWLOCK(proto_list_lock); > static LIST_HEAD(proto_list); > > int proto_register(struct proto *prot, int alloc_slab) > This patch fixes the boot problem. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RCU in kernel/intermodule.c
On Sat, Apr 02, 2005 at 11:28:12AM +, Luca Falavigna wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This patch, compiled against version 2.6.12-rc1, implements RCU mechanism in > intermodule functions. There's no point as these functions are going to go away soon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.12-rc-bk5] Avermedia TV/Phone98 remote control problem (input layer)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all:
I am trying to make my Avermedia TV/Phone 98 remote control work with
linux kernel 2.6.x input layer support (driver ir-kbd-gpio). Module bttv
detects the remote ("bttv0: add subdevice "remote0"), and "ir-kbd-gpio"
makes the remote control show under /proc/bus/input/devices:
I: Bus=0001 Vendor=1461 Product=0001 Version=0001
N: Name="bttv IR (card=41)"
P: Phys=pci-:00:0b.0/ir0
H: Handlers=kbd event3
B: EV=13
B: KEY=fc304 80100040 0 0 3 0 2008000 82 1 9e 7bb80 0 0
I tried Gerd's input layer utilities "input-20040421-115547.tar.gz" to
check if everything was working ok. "lsinput" shows the following:
/dev/input/event3
bustype : BUS_PCI
vendor : 0x1461
product : 0x1
version : 1
name: "bttv IR (card=41)"
phys: "pci-:00:0b.0/ir0"
bits ev : EV_SYN EV_KEY EV_REP
Then I tried "input-events" to check if keypresses in the remote where
detected OK. I get a neverending flow of "ghost" keypresses, because I
didn't touch any key at that time:
waiting for events
11:30:11.198718: EV_KEY KEY_KP0 pressed
11:30:11.198719: EV_SYN code=0 value=0
11:30:11.231712: EV_KEY KEY_KP0 pressed
11:30:11.231714: EV_SYN code=0 value=0
11:30:11.264705: EV_KEY KEY_KP0 pressed
...
Damnit!. So next I unloaded "ir-kbd-gpio", and loaded it again passing the
(undocumented) "debug" parameter to it (modprobe ir-kbd-gpio debug=1), and
the following shows in the logs. Checking the sources at
"drivers/media/video/ir-kbd-gpio.c" it seems that the key supposedly being
pressed is KEY_KP0 from "ir_codes_avermedia", exactly code 34 as shown below:
kernel: ir-kbd-gpio: ir-kbd-gpio: irq gpio=0x8d77c5 code=34 | poll down
kernel: ir-kbd-gpio: bttv IR (card=41) detected at pci-:00:0b.0/ir0
Just for completeness, here is the "lspci" output for the PCI device
"associated" to the remote:
:00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video
Capture (rev 02)
I also tried reading from the input device with "lircd" version 0.7.0 with
support for "devinput", and the same happens. However, this time the "key
code" detected was another one, but this happened after a reboot.
I compiled a 2.4.26 kernel with lirc 0.7.1-pre3 lirc-dev and lirc-gpio
kernel module, and version 0.7.1-pre2 lirc userspace, and it works.
Comparing the sources of "lirc-gpio" in lirc-0.7.1-pre3" and linux kernel
2.6.12-rc1-bk5 "ir-kbd-gpio.c" I see a possible cause for the problem.
Under 2.4.26 the card is detected as "id=0x11461", and under
2.6.12-rc1-bk5 it is detected as "PCI subsystem ID is 1461:0001". It seems
to me that both are the same.
For 2.4.26 this assigns the card's remote the following configuration
(file lirc_gpio.c). The second line I understand describes newer versions
of the same card (mine is from year 1999):
bttv_id card_id gpio_mask gpio_enable gpio_lock_mask
gpio_xor_mask soft_gap sample_rate code_length
{BTTV_AVPHONE98, 0x00011461, 0x003b8000, 0x4000, 0x080,
0x0080, 0,10, 0}
{BTTV_AVPHONE98, 0x00031461, 0x00f88000, 0, 0x001,
0x0001, 0,10, 32}
For 2.6.12-rc1-bk5, any card that is recognized as BTTV_AVERMEDIA,
BTTV_AVPHONE98 or BTTV_AVERMEDIA98, gets assigned the _same_ configuration
(file drivers/media/video/ir-kbd-gpio.c starting at line 313):
ir_codes = ir_codes_avermedia;
ir->mask_keycode = 0xf88000;
ir->mask_keydown = 0x01;
ir->polling = 50; // ms
I am no expert at lirc kernel internals, nor at input layer in kernels
2.6.x, but maybe the problem with my remote comes from being "initialized"
with a generic parameter set that doesn't work at all for it. My knowledge
doesn't go much further, so I thank any additional help to fix this issue.
Greetings,
- --
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.10-rc3)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCUCJ3ao1/w/yPYI0RAuzjAJ4grc8aiFlpN8WtkrgJGZRbPXO3PQCfaWus
DcVUyPVVeKVxOCrREkd4WAI=
=LmCk
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RCU in kernel/intermodule.c
On Apr 02, 2005, at 06:28, Luca Falavigna wrote: -BEGIN PGP SIGNED MESSAGE- - --- ./kernel/intermodule.c.orig 2005-04-01 19:25:26.0 + +++ ./kernel/intermodule.c 2005-04-02 02:46:22.0 + @@ -3,7 +3,7 @@ /* Written by Keith Owens Oct 2000 */ #include #include - -#include ^ Ugh, mangled patch +#include #include #include Please don't sign patches with PGP, it mangles them and makes them much harder to apply. Also, the intermodule stuff is slated for removal, as soon as MTD and such are fixed; the interface has been deprecated for a while. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SCSI] Driver broken in 2.6.x?
Hi, As told, I tested it w/o nvidia module loaded, here's what I found: 1. It now doesn't hang on scanning for devices. 2. It now hangs on acquiring preview, logs will follow. 2a.Not it hanged on scanning for devices again, don't know why. 3. It's true for both module loaded and w/o it. 4. xsane badly reports my scanner as Plustek 12000 or such. 5. Turning on "partial updates"(or such) in view->updates, coused whole machine to hang up, hard reset was needed. W/o this, only xsane hanged. Shoudln't kernel protect form that somehow? 6. Anytime xsane fails/hangs, it hangs the scanner, making it blink it's lamp all the time, and it needt to be dissconnected form electricity to work. 7. As a side question: any way to "reload" the whole SCSI subsystem, so I don't hjave to reboot if I connect something new? Apr 3 15:36:38 techno kernel: scsi0 : aborting command Apr 3 15:36:38 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:36:38 techno kernel: Apr 3 15:36:38 techno kernel: NCR5380 core release=7. Apr 3 15:36:38 techno kernel: Base Addr: 0x0io_port: d800 IRQ: 11. Apr 3 15:36:38 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:36:38 techno kernel: command = 42 (0x2a)00 03 00 00 00 01 10 00 00 Apr 3 15:36:38 techno kernel: scsi0: issue_queue Apr 3 15:36:38 techno kernel: scsi0: disconnected_queue Apr 3 15:36:38 techno kernel: Apr 3 15:36:38 techno kernel: scsi0 : aborting command Apr 3 15:36:38 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:36:38 techno kernel: Apr 3 15:36:38 techno kernel: NCR5380 core release=7. Apr 3 15:36:38 techno kernel: Base Addr: 0x0io_port: d800 IRQ: 11. Apr 3 15:36:38 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:36:38 techno kernel: command = 42 (0x2a)00 03 00 00 00 01 10 00 00 Apr 3 15:36:38 techno kernel: scsi0: issue_queue Apr 3 15:36:38 techno kernel: scsi0: disconnected_queue Apr 3 15:36:38 techno kernel: Apr 3 15:36:38 techno kernel: Apr 3 15:36:38 techno kernel: NCR5380 core release=7. Apr 3 15:36:38 techno kernel: Base Addr: 0x0io_port: d800 IRQ: 11. Apr 3 15:36:38 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:36:38 techno kernel: command = 42 (0x2a)00 03 00 00 00 01 10 00 00 Apr 3 15:36:39 techno kernel: scsi0: issue_queue Apr 3 15:36:39 techno kernel: scsi0: disconnected_queue Apr 3 15:36:39 techno kernel: Apr 3 15:40:26 techno kernel: Linux version 2.6.11.3 ([EMAIL PROTECTED]) (gcc version 3.3.5) #1 Tue Mar 15 14:23:17 CET 2005 Apr 3 15:54:07 techno kernel: scsi0 : aborting command Apr 3 15:54:07 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:54:07 techno kernel: Apr 3 15:54:07 techno kernel: NCR5380 core release=7. Apr 3 15:54:07 techno kernel: Base Addr: 0x0io_port: d800 IRQ: 11. Apr 3 15:54:07 techno kernel: scsi0: no currently connected command Apr 3 15:54:07 techno kernel: scsi0: issue_queue Apr 3 15:54:07 techno kernel: scsi0: disconnected_queue Apr 3 15:54:07 techno kernel: Apr 3 15:54:07 techno kernel: scsi0 : aborting command Apr 3 15:54:07 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:54:07 techno kernel: Apr 3 15:54:07 techno kernel: NCR5380 core release=7. Apr 3 15:54:07 techno kernel: Base Addr: 0x0io_port: d800 IRQ: 11. Apr 3 15:54:07 techno kernel: scsi0: no currently connected command Apr 3 15:54:07 techno kernel: scsi0: issue_queue Apr 3 15:54:07 techno kernel: scsi0: disconnected_queue Apr 3 15:54:07 techno kernel: Apr 3 15:54:07 techno kernel: scsi0 : warning : SCSI command probably completed successfully Apr 3 15:54:07 techno kernel: before abortion Apr 3 15:54:07 techno kernel: Apr 3 15:54:07 techno kernel: NCR5380 core release=7. Apr 3 15:54:07 techno kernel: Base Addr: 0x0io_port: d800 IRQ: 11. Apr 3 15:54:07 techno kernel: scsi0: no currently connected command Apr 3 15:54:07 techno kernel: scsi0: issue_queue Apr 3 15:54:07 techno kernel: scsi0: disconnected_queue Apr 3 15:54:07 techno kernel: Apr 3 15:54:27 techno kernel: scsi0 : aborting command Apr 3 15:54:27 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:54:27 techno kernel: Apr 3 15:54:27 techno kernel: NCR5380 core release=7. Apr 3 15:54:27 techno kernel: Base Addr: 0x0io_port: d800 IRQ: 11. Apr 3 15:54:27 techno kernel: scsi0: no currently connected command Apr 3 15:54:27 techno kernel: scsi0: issue_queue Apr 3 15:54:27 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:54:27 techno kernel: command = 0 (0x00)00 00 00 00 00 Apr 3 15:54:27 techno kernel: scsi0: disconnected_queue Apr 3 15:54:27 techno kernel: Apr 3 15:54:27 techno kernel: scsi0 : aborting command Apr 3 15:54:27 techno kernel: scsi0 : destination target 6, lun 0 Apr 3 15:54:27 techno kernel: Apr 3 15:54:27 techno kernel: NCR5380 core release=7. Apr 3 15:54:27 techno kernel: Base Addr: 0x0io_port: d800 IRQ: 11. Apr 3 15:54:27 techno kernel: scsi0:
Re: kernel stack size
On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote: > Yes - sem or spin locks are quicker as long as no cache line transfers > are necessary. If the semaphore is accessed by multiple cpus, then > kmalloc would be faster: slab tries hard to avoid taking global locks. > I'm not speaking about contention, just the cache line ping pong for > acquiring a free semaphore. Without contention, is there still a problem with cache line ping pong of acquiring a free semaphore? I mean, say only one task is using a given semaphore. Is there still going to be cache line transfers for acquiring it? Even if the task in question stays on a CPU. Is the "LOCK" on an instruction that expensive even if the other CPUs haven't accessed that location of memory. Sorry for my ignorance, I don't know all the interworkings of the Cache on SMP systems. Is there any good references on the Internet? I definitely want to know so that my coding practices for SMP improve. Thanks, -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fix u32 vs. pm_message_t in usb
Actually, please do NOT apply this. It conflicts with other patches, which have been in the past few MM releases, have also been circulated on linux-usb-devel, and actually address some of the bugs which crept in as things have changed around the USB stack. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
On Sun, Apr 03, 2005 at 02:30:11PM +0200, Dag Arne Osvik wrote: > Yes, but wouldn't it be much better to avoid code like the following, > which may also be wrong (in terms of speed)? > > #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64? > #define fast_u32 u64 > #else > #define fast_u32 u32 > #endif ... and with such name 99% will assume (at least at the first reading) that it _is_ 32bits. We have more than enough portability bugs as it is, no need to invite more by bad names. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 2/4] Deprecate synchronize_kernel, GPL replacement
On Sun, Apr 03, 2005 at 02:26:50PM +0530, Dipankar Sarma wrote:
> On Sat, Apr 02, 2005 at 10:21:50PM -0800, Paul E. McKenney wrote:
> > The synchronize_kernel() primitive is used for quite a few different
> > purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
> > and so on. This makes RCU code harder to read, since synchronize_kernel()
> > might or might not have matching rcu_read_lock()s. This patch creates
> > a new synchronize_rcu() that is to be used for RCU readers and a new
> > synchronize_sched() that is used for the rest. These two new primitives
> > currently have the same implementation, but this is might well change
> > with additional real-time support. Both new primitives are GPL-only,
> > the old primitive is deprecated.
> >
> > Signed-off-by: <[EMAIL PROTECTED]>
> > ---
> > Depends on earlier "Add deprecated_for_modules" patch.
> >
> > +/*
> > + * Deprecated, use synchronize_rcu() or synchronize_sched() instead.
> > + */
> > +void synchronize_kernel(void)
> > +{
> > + synchronize_rcu();
> > +}
> > +
>
> We should probably mark it deprecated -
>
> void __deprecated synchronize_kernel(void)
> {
> synchronize_rcu();
> }
Hello, Dipankar,
That was the first thing I tried. ;-)
When I did that, I got a "deprecated" warning from gcc on the
EXPORT_SYMBOL() later in that same file. After futzing around a
bit, I hit on the compromise of marking the rcupdate.h declaration
of synchronize_kernel() as "__deprecated_for_modules".
That said, you are quite right that it would be better if gcc also gave
the "deprecated" warning for use of synchronize_kernel() within in-tree
non-module code. I suppose I could do something like the following
before the #includes in rcupdate.c:
#define SUPPRESS_DEPRECATION_OF_SYNCHRONIZE_KERNEL
and then something like this in rcupdate.h:
#ifdef SUPPRESS_DEPRECATION_OF_SYNCHRONIZE_KERNEL
extern void synchronize_kernel(void);
#else /* #ifdef SUPPRESS_DEPRECATION_OF_SYNCHRONIZE_KERNEL */
extern __deprecated void synchronize_kernel(void);
#endif /* #else #ifdef SUPPRESS_DEPRECATION_OF_SYNCHRONIZE_KERNEL */
but this seemed a bit ugly at the time. Maybe it is worthwhile.
I couldn't find any way to suppress the "deprecated" warning that is
generated by the "&sym" in the last line of the __EXPORT_SYMBOL()
macro. Anyone know a way of doing this? There doesn't seem to me
to be any point to giving the warning on the EXPORT_SYMBOL() -- and
it does clutter up compiler output with useless "deprecated" warnings.
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 2/4] Deprecate synchronize_kernel, GPL replacement
On Mon, Apr 04, 2005 at 12:11:56AM +1000, Michael Ellerman wrote:
> Hi Paul,
>
> I'm not quite clear on the difference between the two synchronize functions ,
> the comment for synchronize_sched() seems to have a bit missing? (see below)
>
> cheers
>
> On Sun, 3 Apr 2005 16:21, Paul E. McKenney wrote:
> > +/**
> > + * synchronize_sched - block until all CPUs have exited any non-preemptive
> > + * kernel code sequences.
> > + *
> > + * This means that all preempt_disable code sequences, including NMI and
> > + * hardware-interrupt handlers, in progress on entry will have completed
> > + * before this primitive returns. However, this does not guarantee that
> > + * softirq handlers will have completed, since in some kernels
>
> ??
>
> > + *
> > + * This primitive provides the guarantees made by the (deprecated)
> > + * synchronize_kernel() API. In contrast, synchronize_rcu() only
> > + * guarantees that rcu_read_lock() sections will have completed.
> > + */
> > +#define synchronize_sched() synchronize_rcu()
Good catch! How about the following?
+ * This means that all preempt_disable code sequences, including NMI and
+ * hardware-interrupt handlers, in progress on entry will have completed
+ * before this primitive returns. However, this does not guarantee softirq
+ * handlers have completed, since some configs run them in process context.
Updated patch below.
Thanx, Paul
Signed-off-by: <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.12-rc1/include/linux/rcupdate.h
linux-2.6.12-rc1-bettersk/include/linux/rcupdate.h
--- linux-2.6.12-rc1/include/linux/rcupdate.h Tue Mar 1 23:37:50 2005
+++ linux-2.6.12-rc1-bettersk/include/linux/rcupdate.h Sat Apr 2 13:06:15 2005
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
/**
* struct rcu_head - callback structure for use with RCU
@@ -157,9 +158,9 @@ static inline int rcu_pending(int cpu)
/**
* rcu_read_lock - mark the beginning of an RCU read-side critical section.
*
- * When synchronize_kernel() is invoked on one CPU while other CPUs
+ * When synchronize_rcu() is invoked on one CPU while other CPUs
* are within RCU read-side critical sections, then the
- * synchronize_kernel() is guaranteed to block until after all the other
+ * synchronize_rcu() is guaranteed to block until after all the other
* CPUs exit their critical sections. Similarly, if call_rcu() is invoked
* on one CPU while other CPUs are within RCU read-side critical
* sections, invocation of the corresponding RCU callback is deferred
@@ -256,6 +257,21 @@ static inline int rcu_pending(int cpu)
(p) = (v); \
})
+/**
+ * synchronize_sched - block until all CPUs have exited any non-preemptive
+ * kernel code sequences.
+ *
+ * This means that all preempt_disable code sequences, including NMI and
+ * hardware-interrupt handlers, in progress on entry will have completed
+ * before this primitive returns. However, this does not guarantee softirq
+ * handlers have completed, since some configs run them in process context.
+ *
+ * This primitive provides the guarantees made by the (deprecated)
+ * synchronize_kernel() API. In contrast, synchronize_rcu() only
+ * guarantees that rcu_read_lock() sections will have completed.
+ */
+#define synchronize_sched() synchronize_rcu()
+
extern void rcu_init(void);
extern void rcu_check_callbacks(int cpu, int user);
extern void rcu_restart_cpu(int cpu);
@@ -265,7 +281,9 @@ extern void FASTCALL(call_rcu(struct rcu
void (*func)(struct rcu_head *head)));
extern void FASTCALL(call_rcu_bh(struct rcu_head *head,
void (*func)(struct rcu_head *head)));
-extern void synchronize_kernel(void);
+extern __deprecated_for_modules void synchronize_kernel(void);
+extern void synchronize_rcu(void);
+void synchronize_idle(void);
#endif /* __KERNEL__ */
#endif /* __LINUX_RCUPDATE_H */
diff -urpN -X dontdiff linux-2.6.12-rc1/kernel/rcupdate.c
linux-2.6.12-rc1-bettersk/kernel/rcupdate.c
--- linux-2.6.12-rc1/kernel/rcupdate.c Tue Mar 1 23:37:30 2005
+++ linux-2.6.12-rc1-bettersk/kernel/rcupdate.c Sat Apr 2 13:10:09 2005
@@ -444,15 +444,18 @@ static void wakeme_after_rcu(struct rcu_
}
/**
- * synchronize_kernel - wait until a grace period has elapsed.
+ * synchronize_rcu - wait until a grace period has elapsed.
*
* Control will return to the caller some time after a full grace
* period has elapsed, in other words after all currently executing RCU
* read-side critical sections have completed. RCU read-side critical
* sections are delimited by rcu_read_lock() and rcu_read_unlock(),
* and may be nested.
+ *
+ * If your read-side code is not protected by rcu_read_lock(), do -not-
+ * use synchronize_rcu().
*/
-void synchronize_kernel(void)
+void synchronize_rcu(void)
{
struct rcu_synchronize rcu;
@@ -464,
Re: AIM9 slowdowns between 2.6.11 and 2.6.12-rc1
On Sun, 2005-04-03 at 15:37 +0100, Mel Gorman wrote: > While testing the page placement policy patches on 2.6.12-rc1, I noticed > that aim9 is showing significant slowdowns on page allocation-related > tests. An excerpt of the results is at the end of this mail but it shows > that page_test is allocating 18000 less pages. > > I did not check who has been recently changing the buddy allocator but > they might want to run a benchmark or two to make sure this is not > something specific to my setup. Can you get some kernel profiles to see what, exactly, is causing the decreased performance? Also, what kind of system do you have? Does backing this out help? If not, can you test some BK snapshots to see when this started occurring? http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED] -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Auto-append localversion for BK users needs to use CONFIG_SHELL
On Sat, Mar 12, 2005 at 11:32:29PM -0500, Ryan Anderson wrote: > > Sam, you'll probably want this on top of the patch I sent. (I haven't > built in a clean tree in a while, found a minor problem when I was > transitioning to quilt today.) Combined this to one patch and applied it. Let's see what feedback lkml gives. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote: Stephen Rothwell wrote: On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote: I've been working on a new DES implementation for Linux, and ran into the problem of how to get access to C99 types like uint_fast32_t for internal (not interface) use. In my tests, key setup on Athlon 64 slows down by 40% when using u32 instead of uint_fast32_t. If you look in stdint.h you may find that uint_fast32_t is actually 64 bits on Athlon 64 ... so does it help if you use u64? Yes, but wouldn't it be much better to avoid code like the following, which may also be wrong (in terms of speed)? #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64? #define fast_u32 u64 #else #define fast_u32 u32 #endif Isn't it better to use a general integer type, reflecting the cpu's native register-size and let the compiler sort it out? Restrict all uses of explicit width types to where it's *really* needed, that is, in drivers, network-code, etc. I firmly oppose any definition of "#define fast_u32 u64". This kind of definitions will only create needless confusion. I wonder how much other code is suffering from this kind of overly explicit typing. It's much easier to make assumptions about integer size unwittingly than it is to avoid them. I used to assume (for instance) that sizeof(int) == sizeof(long) == sizeof(void *) at one point in my career. Fortunately, reality soon asserted itself again. Regards, Renate Meijer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel stack size
Steven Rostedt wrote: On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote: Yes - sem or spin locks are quicker as long as no cache line transfers are necessary. If the semaphore is accessed by multiple cpus, then kmalloc would be faster: slab tries hard to avoid taking global locks. I'm not speaking about contention, just the cache line ping pong for acquiring a free semaphore. Without contention, is there still a problem with cache line ping pong of acquiring a free semaphore? I mean, say only one task is using a given semaphore. Is there still going to be cache line transfers for acquiring it? Even if the task in question stays on a CPU. Is the "LOCK" on an instruction that expensive even if the other CPUs haven't accessed that location of memory. No. If everything is cpu-local, then there are obviously no cache line transfers. LOCK is not that expensive. On a Pentium 3, it was 20 cpu cycles. On an Athlon 64, it's virtually free. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] Bug in make deb-pkg when using seperate source and object directories
On Sat, Mar 19, 2005 at 07:28:00PM -0500, Ryan Anderson wrote: > On Mon, Mar 14, 2005 at 11:59:26AM -0800, Ajay Patel wrote: > > I had a similar problem building binrpm-pkg. > > Try following patch. It worked for me. > > My problem wasn't actually resolved by this - the make in builddeb still > caused issues. > > So, a normal, unified diff form of the patch, fixed up, is attached. > > Signed-off-By: Ryan Anderson <[EMAIL PROTECTED]> Applied. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] psmouse: dynamic protocol switching via sysfs
Patches 1-3 are fine. Protocol switching via sysfs works too but if I switch from LBPS/2 to PS/2 the device name changes from "/dev/event1" to "/dev/event2" -- is this intended? If I do "echo -n 50 > resolution" "0xe8 0x01" is sent. I don't know if this is correct for "usual" PS/2-devices but for the lifebook it's wrong. For the lifebook the parameters are as following: 50cpi <=> 0x00 100cpi <=> 0x01 200cpi <=> 0x02 400cpi <=> 0x03 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] configfs, a filesystem for userspace-driven kernel object configuration
Folks,
I humbly submit configfs. With configfs, a configfs
config_item is created via an explicit userspace operation: mkdir(2).
It is destroyed via rmdir(2). The attributes appear at mkdir(2) time,
and can be read or modified via read(2) and write(2). readdir(3)
queries the list of items and/or attributes.
The lifetime of the filesystem representation is completely
driven by userspace. The lifetime of the objects themselves are managed
by a kref, but at rmdir(2) time they disappear from the filesystem.
configfs is not intended to replace sysfs or procfs, merely to
coexist with them.
An interface in /proc where the API is:
# echo "create foo 1 3 0x00013" > /proc/mythingy
or an ioctl(2) interface where the API is:
struct mythingy_create {
char *name;
int index;
int count;
unsigned long address;
}
do_create {
mythingy_create = {"foo", 1, 3, 0x0013};
return ioctl(fd, MYTHINGY_CREATE, &mythingy_create);
}
becomes this in configfs:
# cd /config/mythingy
# mkdir foo
# echo 1 > foo/index
# echo 3 > foo/count
# echo 0x00013 > foo/address
Instead of a binary blob that's passed around or a cryptic
string that has to be formatted just so, configfs provides an interface
that's completely scriptable and navigable.
Patch is against 2.6.12-rc1-bk3.
http://oss.oracle.com/~jlbec/files/configfs/2.6.12-rc1-bk3/configfs-2.6.12-rc1-bk3-1.patch
Joel
--
"Not everything that can be counted counts, and not everything
that counts can be counted."
- Albert Einstein
Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re(2): fix u32 vs. pm message t in usb
On Sunday 03 April 2005 12:31 pm, [EMAIL PROTECTED] wrote: > Okay, you obviously have easy access to usb development trees... > Do you think you could just take this patch as a basis and fix > remaining u32 vs pm-message-t in usb? --p Fixing the "sparse -Wbitwise" messages, and addressing some other behavior changes/bugs that crept in, was the idea. That's already done, but _without_ taking this as a basis (or breaking the sysfs support etc). The patches I sent fix everything I had time to test (just a subset of the dozens of cases previously tested, probably covering the main stuff that got broken) except the non-PCI platform_bus drivers where pm_message_t has discarded essential functionality. (Notably, info about whether device clocks and/or power must be turned off.) Fixing those will be more work than seems reasonable for 2.6.12 kernels. Among other things, there's still a lot of stuff that needs to percolate out to arch trees; designing and testing such fixes takes time, as does percolating it back. - Dave p.s. PCI-express patches don't belong with USB patches. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-lvm] Re: 2.6.11ac5 oops while reconstructing md array and moving volumegroup with pvmove
On Sat, Apr 02, 2005 at 09:09:37AM +0300, Antti Salmela wrote: > % mdadm --create -l 1 -n 2 /dev/md2 /dev/hde /dev/hdg > % pvcreate /dev/md2 > % vgextend vg1 /dev/md2 > % pvmove /dev/hdf /dev/md2 A few similar reports still appearing, possibly still related to the md bio_clone changes that fixed some bugs for md but created new ones for dm... Would be good if you could re-test with a current 2.6.12- I'll look into later this week if nobody beats me to it - please! Alasdair - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AIM9 slowdowns between 2.6.11 and 2.6.12-rc1 (probably false positive)
On Sun, 3 Apr 2005, Dave Hansen wrote: > On Sun, 2005-04-03 at 15:37 +0100, Mel Gorman wrote: > > While testing the page placement policy patches on 2.6.12-rc1, I noticed > > that aim9 is showing significant slowdowns on page allocation-related > > tests. An excerpt of the results is at the end of this mail but it shows > > that page_test is allocating 18000 less pages. > > > > I did not check who has been recently changing the buddy allocator but > > they might want to run a benchmark or two to make sure this is not > > something specific to my setup. > > Can you get some kernel profiles to see what, exactly, is causing the > decreased performance? Also, what kind of system do you have? Does > backing this out help? If not, can you test some BK snapshots to see > when this started occurring? > > http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED] > The machine is a quad xeon with P III 733 processors. I don't have profile information available as I wasn't collecting as I went along. However, backing out the patch made little difference However, I reran the test on 2.6.11 and this time the performance difference was a lot less. Something else must have been happening when I collected the first set of poor results. I'll revisit this when I'm next working on kernel stuff and see can I reproduce it again reliably. -- Mel Gorman Part-time Phd Student Java Applications Developer University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech MX1000 Horizontal Scrolling
Jeremy Nickurak <[EMAIL PROTECTED]> writes: > On Tue, 2005-03-08 at 21:52 +0100, Vojtech Pavlik wrote: > > The problem is that the mouse really does reports all the double-button > > stuff and autorepeat, and horizontal wheel together with button press on > > wheel tilt. > > Okay, I'm playing with this under 2.6.11.4 some more, and it really > seems out of whack. The vertical cruise control buttons work properly, > with the exception of the extra button press. But the horizontal buttons > are mapping to 6/7 as non-repeat buttons, and adding simulateously the > 4/5 events auto-repeated for as long as the button is down. That is to > say, pressing the the horizontal scroll in a 2d scrolling area will > scroll *diagonally* one step, then vertically until the button is > released. Have you tried the Logitech mouse applet? http://freshmeat.net/projects/logitech_applet/ "logitech_applet --disable-cc" used to work for me when I owned an MX1000 mouse. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
On Sun, 2005-04-03 at 21:23 +0200, Renate Meijer wrote: > On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote: > > > Stephen Rothwell wrote: > > > >> On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> > >> wrote: > >> > >>> I've been working on a new DES implementation for Linux, and ran into > >>> the problem of how to get access to C99 types like uint_fast32_t for > >>> internal (not interface) use. In my tests, key setup on Athlon 64 > >>> slows > >>> down by 40% when using u32 instead of uint_fast32_t. > >>> > >> > >> If you look in stdint.h you may find that uint_fast32_t is actually > >> 64 bits on Athlon 64 ... so does it help if you use u64? > >> > >> > > > > Yes, but wouldn't it be much better to avoid code like the following, > > which may also be wrong (in terms of speed)? > > > > #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64? > > #define fast_u32 u64 > > #else > > #define fast_u32 u32 > > #endif > > Isn't it better to use a general integer type, reflecting the cpu's > native register-size and let the compiler sort it out? Restrict all > uses of explicit width types to where it's *really* needed, that is, in But is this not exactly what Dag Arne Osvik was trying to do ?? uint_fast32_t means that we want at least 32 bits but it's OK with more if that happens to be faster on this particular architecture. The problem was that the C99 standard types are not defined anywhere in the kernel headers so they can not be used. Perhaps they should be added to asm/types.h ? signature.asc Description: This is a digitally signed message part
Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration
On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote: > I humbly submit configfs. With configfs, a configfs > ... > Patch is against 2.6.12-rc1-bk3. Updated for bk5 and the new backing_dev capabilites mask: http://oss.oracle.com/~jlbec/files/configfs/2.6.12-rc1-bk5/configfs-2.6.12-rc1-bk5-1.patch Joel -- "Against stupidity the Gods themselves contend in vain." - Freidrich von Schiller Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix boot hang on some architectures
On Sun, 3 Apr 2005 12:21:01 -0300 Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote: > Em Sat, Apr 02, 2005 at 01:46:03PM -0600, James Bottomley escreveu: > > Well, this is a brown paper bag for someone. The new protocol > > /me using such bag now :( > > Thanks a lot for the fix. > > David, Please apply. Done, thanks everyone. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Mathieu Bérard <[EMAIL PROTECTED]> wrote: > > Hi, > I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. > (Everyting run smoothly using 2.6.11-mm1) > It seems to be related with mounting a reiserfs3 filesystem. It looks more like an IDE bug. > ReiserFS: hdg1: checking transaction log (hdg1) > Unable to handle kernel paging request at virtual address 0a373138 > printing eip: > df6d1211 > *pde = > Oops: 0002 [#1] > PREEMPT > Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic > slhc w83627hf_wdt msr cpuid > rtc > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010202 (2.6.12-rc1-mm4) > EIP is at 0xdf6d1211 > eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 > esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 > ds: 007b es: 007b ss: 0068 > Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) > Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 > c0223051 > 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c > c022333e > df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 > c0212260 > Call Trace: > [] flagged_taskfile+0x125/0x380 > [] start_request+0x1f1/0x2a0 > [] ide_do_request+0x20e/0x3c0 > [] __generic_unplug_device+0x20/0x30 > [] generic_unplug_device+0x11/0x30 > [] blk_backing_dev_unplug+0xc/0x10 > [] sync_buffer+0x26/0x40 > [] __wait_on_bit+0x42/0x70 > [] sync_buffer+0x0/0x40 > [] sync_buffer+0x0/0x40 > [] out_of_line_wait_on_bit+0x7d/0x90 > [] wake_bit_function+0x0/0x60 > [] __wait_on_buffer+0x29/0x30 > [] _update_journal_header_block+0xf7/0x140 > [] journal_read+0x31d/0x470 > [] journal_init+0x4e1/0x650 > [] printk+0x1b/0x20 > [] reiserfs_fill_super+0x34d/0x770 > [] snprintf+0x20/0x30 > [] disk_name+0x96/0xf0 > [] get_sb_bdev+0xe5/0x130 > [] link_path_walk+0x65/0x140 > [] get_super_block+0x18/0x20 > [] reiserfs_fill_super+0x0/0x770 > [] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 > 30 20 30 20 30 20 <1>general p It appears that we might have jumped from flagged_taskfile into something at 0xdf6d1211, which is rather odd. You have two different low-level IDE drivers configured. Which one is driving that filesystem? VIA or Promise? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote: But is this not exactly what Dag Arne Osvik was trying to do ?? uint_fast32_t means that we want at least 32 bits but it's OK with more if that happens to be faster on this particular architecture. The problem was that the C99 standard types are not defined anywhere in the kernel headers so they can not be used. Uhh, so what's wrong with "int" or "long"? On all existing archs supported by linux, "int" is 32 bits, "long long" is 64 bits, and "long" is an efficient word-sized value that can hold a casted pointer. I suppose it's theoretical that linux could be ported to some arch where int is 16 bits, but so much stuff implicitly depends on at least 32-bits in int that I think that's unlikely. GCC will generally do the right thing if you just tell it "int". Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH 2/4] Deprecate synchronize_kernel, GPL replacement
On Sünndag 03 April 2005 20:50, Paul E. McKenney wrote:
> I couldn't find any way to suppress the "deprecated" warning that is
> generated by the "&sym" in the last line of the __EXPORT_SYMBOL()
> macro. Anyone know a way of doing this? There doesn't seem to me
> to be any point to giving the warning on the EXPORT_SYMBOL() -- and
> it does clutter up compiler output with useless "deprecated" warnings.
You can define an inline function that is marked __deprecated and calls
the exported function:
extern void __synchronize_kernel(void);
static inline __deprecated synchronize_kernel(void)
{
__synchronize_kernel();
}
===
void __synchronize_kernel(void)
{
synchronize_rcu();
}
EXPORT_SYMBOL(__synchronize_kernel);
You could even make __synchronize_kernel() static to let it only be used
by modules, but that might create some confusion about the interface.
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
Ingo wrote: > if_ there is a significant hierarchy between CPUs it > should be represented via a matching sched-domains hierarchy, Agreed. I'll see how the sched domains hierarchy looks on a bigger SN2 systems. If the CPU hierarchy is not reflected in the sched-domain hierarchy any better there, then I will look to involve the "SN2 sched domain hierarchy experts" in improving SN2 the sched-domain hierarchy. Ok - that works. Your patch of yesterday provides just the tool I need to measure this. Cool. > i'll first try the bottom-up approach to speed up detection (getting to > the hump is very fast most of the time). Good. > then we can let the arch override the cpu_distance() method I'm not aware we need that, yet anyway. First I should see if the SN2 sched_domains need improving. Take a shot at doing it 'the right way' before we go inventing overrides. I suspect you agree. > the migration cost matrix we can later use to tune all the other > sched-domains balancing related tunables as well That comes close to my actual motivation here. I hope to expose a "cpu_distance" such as based on this cost matrix, to userland. We already expose the SLIT table node distances (using SN2 specific /proc files today, others are working on an arch-neutral mechanism). As we push more cores and hyperthreads into a single package on one end, and more complex numa topologies on the other end, this becomes increasingly interesting to NUMA aware user software. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
On Fre, 01 Apr 2005, Pavel Machek wrote: > > I suspends fine, but never resumes. No CapsLock, no sysrq, no network is > > working. Nothing in the log files. Is there anything which may cause > > these troubles when compiled into the kernel and not loaded as module? > > (as it was with my usb stuff until 2.6.11-mm2, after this I had to stop > > hotplug, before I could go with usb running). > > Try suspend2disk, first, and try suspend2ram with minimal kernel > config. suspend2disk runs without any problem, even with X running. it is only suspend2ram which stopped working after 2.6.11-mm4 (at least in 2.6.12-rc1-mm3,4). Concerning tests with minimal kernel config: I guess since it *was* working there should not be a change necessary -- but well, from 2.6.11-mm2 to 2.6.11-mm4 I had to stop hotplug/usb to get ot working, so maybe now I have to stop all the other things. G. This is not what I want! Isn't there a different way? Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DORRIDGE (n.) Technical term for one of the lame excuses written in very small print on the side of packets of food or washing powder to explain why there's hardly anything inside. Examples include 'Contents may have settled in transit' and 'To keep each biscuit fresh they have been individually wrapped in silver paper and cellophane and separated with corrugated lining, a cardboard flap, and heavy industrial tyres'. --- Douglas Adams, The Meaning of Liff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of C99 int types
Andreas Schwab wrote: Dag Arne Osvik <[EMAIL PROTECTED]> writes: Yes, but wouldn't it be much better to avoid code like the following, which may also be wrong (in terms of speed)? #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64? #define fast_u32 u64 #else #define fast_u32 u32 #endif How about using just unsigned long instead? unsigned long happens to coincide with uint_fast32_t for x86 and x86-64, but there's no guarantee that it will on other architectures. And, at least in theory, long may even provide less than 32 bits. -- Dag Arne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched /HT processor
From: Steven Rostedt <[EMAIL PROTECTED]> To: Jesper Juhl <[EMAIL PROTECTED]> CC: Arun Srinivas <[EMAIL PROTECTED]>,LKML Subject: Re: sched /HT processor Date: Sun, 03 Apr 2005 11:31:03 -0400 On Sun, 2005-04-03 at 13:17 +0200, Jesper Juhl wrote: > > A reschedule can happen once every ms, but also upon returning to > userspace and when returning from an interrupt handler, and also when > something in the kernel explicitly calls schedule() or sleeps (which in > turn results in a call to schedule()). And each CPU runs schedule() > independently. > At least that's my understanding of it - if I'm wrong I hope someone on > the list will correct me. You're correct, but I'll add some more details here. The actual schedule happens when needed. A schedule may not take place at every ms, if the task running is not done with its time slice and no events happened where another task should preempt it. If an RT task is running in a FIFO policy, then it will continue to run until it calls schedule itself or another process of higher priority preempts it. Now if you don't have PREEMPT turned on, than the schedule won't take place at all while a task is in the kernel, unless the task explicitly calls schedule. What happens on a timer interrupt where a task is done with its time slice or another event where a schedule should take place, is just the need_resched flag is set for the task. On return from the interrupt the flag is checked, and if set a schedule is called. This is still a pretty basic description of what really happens, and if you want to learn more, just start searching the kernel code for schedule and need_resched. Don't forget to look in the asm code (ie entry.S, and dependent on your arch other *.S files). -- Steve _ News, views and gossip. http://www.msn.co.in/Cinema/ Get it all at MSN Cinema! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched /HT processor
Thanks. yes, a reschedule may not take place after a ms, if the currently running task cannot be preempted by another task. (1) But, can a reschedule happen within a millisec (or once a process is scheduled can schedule() be called before the next millisec.) ? 2) Also in case argument (1) is not true, and I want rescheduling to be done (i.e., schedule() called) in less than 1 ms , can I directly change the HZ value in and recompile my kernel so that my timer interrupt will occur frequently? Thanks Arun From: Steven Rostedt <[EMAIL PROTECTED]> To: Jesper Juhl <[EMAIL PROTECTED]> CC: Arun Srinivas <[EMAIL PROTECTED]>,LKML Subject: Re: sched /HT processor Date: Sun, 03 Apr 2005 11:31:03 -0400 On Sun, 2005-04-03 at 13:17 +0200, Jesper Juhl wrote: > > A reschedule can happen once every ms, but also upon returning to > userspace and when returning from an interrupt handler, and also when > something in the kernel explicitly calls schedule() or sleeps (which in > turn results in a call to schedule()). And each CPU runs schedule() > independently. > At least that's my understanding of it - if I'm wrong I hope someone on > the list will correct me. You're correct, but I'll add some more details here. The actual schedule happens when needed. A schedule may not take place at every ms, if the task running is not done with its time slice and no events happened where another task should preempt it. If an RT task is running in a FIFO policy, then it will continue to run until it calls schedule itself or another process of higher priority preempts it. Now if you don't have PREEMPT turned on, than the schedule won't take place at all while a task is in the kernel, unless the task explicitly calls schedule. What happens on a timer interrupt where a task is done with its time slice or another event where a schedule should take place, is just the need_resched flag is set for the task. On return from the interrupt the flag is checked, and if set a schedule is called. This is still a pretty basic description of what really happens, and if you want to learn more, just start searching the kernel code for schedule and need_resched. Don't forget to look in the asm code (ie entry.S, and dependent on your arch other *.S files). -- Steve _ The MSN Survey! http://www.cross-tab.com/surveys/run/test.asp?sid=2026&respid=1 Help us help you better! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
