Re: [PATCH] drop page cache of a single file
On Wed, Dec 27, 2006 at 07:49:59PM -0800, Andrew Morton wrote: > On Thu, 28 Dec 2006 11:17:25 +0800 > "Zhang, Yanmin" <[EMAIL PROTECTED]> wrote: > > > Currently, by /proc/sys/vm/drop_caches, applications could drop pagecache, > > slab(dentries and inodes), or both, but applications couldn't choose to > > just drop the page cache of one file. An user of VOD (Video-On-Demand) > > needs this capability to have more detailed control on page cache release. > > The posix_fadvise() system call should be used for this. Probably in > combination with sys_sync_file_range(). Yanmin: I've been using the fadvise tool from http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz It's a nice tool: % fadvise Usage: fadvise filename offset length advice [loops] advice: normal sequential willneed noreuse dontneed asyncwrite writewait % fadvise /var/sparse 0 0x7fff dontneed Regards, Wu - 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] mm: fix page_mkclean_one
From: "Chen, Kenneth W" <[EMAIL PROTECTED]> Date: Wed, 27 Dec 2006 22:10:52 -0800 > Chen, Kenneth wrote on Wednesday, December 27, 2006 9:55 PM > > Linus Torvalds wrote on Wednesday, December 27, 2006 7:05 PM > > > On Wed, 27 Dec 2006, David Miller wrote: > > > > > > > > > > I still don't see _why_, though. But maybe smarter people than me can > > > > > see > > > > > it.. > > > > > > > > FWIW this program definitely triggers the bug for me. > > > > > > Ok, now that I have something simple to do repeatable stuff with, I can > > > say what the pattern is.. It's not all that surprising, but it's still > > > worth just stating for the record. > > > > > > Running the test code, git bisect points its finger at this commit. > > Reverting > > this commit on top of 2.6.20-rc2 doesn't trigger the bug from the test code. > > > > edc79b2a46ed854595e40edcf3f8b37f9f14aa3f is first bad commit > > commit edc79b2a46ed854595e40edcf3f8b37f9f14aa3f > > Author: Peter Zijlstra <[EMAIL PROTECTED]> > > Date: Mon Sep 25 23:30:58 2006 -0700 > > > > [PATCH] mm: balance dirty pages > > > > Now that we can detect writers of shared mappings, throttle them. > > Avoids OOM > > by surprise. > > > Oh, never mind :-( I just didn't create enough write out pressure when > test this. I just saw bug got triggered on a kernel I previously thought > was OK. Besides, I'm pretty sure that from the Debian bug entry it's been established that the dirty-page tracking changes from a few releases ago introduced this problem. - 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] mm: fix page_mkclean_one
Chen, Kenneth wrote on Wednesday, December 27, 2006 9:55 PM > Linus Torvalds wrote on Wednesday, December 27, 2006 7:05 PM > > On Wed, 27 Dec 2006, David Miller wrote: > > > > > > > > I still don't see _why_, though. But maybe smarter people than me can > > > > see > > > > it.. > > > > > > FWIW this program definitely triggers the bug for me. > > > > Ok, now that I have something simple to do repeatable stuff with, I can > > say what the pattern is.. It's not all that surprising, but it's still > > worth just stating for the record. > > > Running the test code, git bisect points its finger at this commit. Reverting > this commit on top of 2.6.20-rc2 doesn't trigger the bug from the test code. > > edc79b2a46ed854595e40edcf3f8b37f9f14aa3f is first bad commit > commit edc79b2a46ed854595e40edcf3f8b37f9f14aa3f > Author: Peter Zijlstra <[EMAIL PROTECTED]> > Date: Mon Sep 25 23:30:58 2006 -0700 > > [PATCH] mm: balance dirty pages > > Now that we can detect writers of shared mappings, throttle them. Avoids > OOM > by surprise. Oh, never mind :-( I just didn't create enough write out pressure when test this. I just saw bug got triggered on a kernel I previously thought was OK. - 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] mm: fix page_mkclean_one
On 12/27/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: That's just 400kB! There's no way you should see corruption with that kind of value. It should all stay solidly in the cache. 100kB and 200kB files always succeed on the ARM system. 400kB and larger always seem to fail. Does the following help interpret the results on ARM at all ? $ free total used free sharedbuffers cached Mem: 3 23620 6380 0808 15676 -/+ buffers/cache: 7136 22864 Swap:88316 3664 84652 Gordon -- Gordon Farquharson - 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] mm: fix page_mkclean_one
Linus Torvalds wrote on Wednesday, December 27, 2006 7:05 PM > On Wed, 27 Dec 2006, David Miller wrote: > > > > > > I still don't see _why_, though. But maybe smarter people than me can see > > > it.. > > > > FWIW this program definitely triggers the bug for me. > > Ok, now that I have something simple to do repeatable stuff with, I can > say what the pattern is.. It's not all that surprising, but it's still > worth just stating for the record. Running the test code, git bisect points its finger at this commit. Reverting this commit on top of 2.6.20-rc2 doesn't trigger the bug from the test code. edc79b2a46ed854595e40edcf3f8b37f9f14aa3f is first bad commit commit edc79b2a46ed854595e40edcf3f8b37f9f14aa3f Author: Peter Zijlstra <[EMAIL PROTECTED]> Date: Mon Sep 25 23:30:58 2006 -0700 [PATCH] mm: balance dirty pages Now that we can detect writers of shared mappings, throttle them. Avoids OOM by surprise. Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]> Cc: Hugh Dickins <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[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] mm: fix page_mkclean_one
Hi David On 12/27/06, David Miller <[EMAIL PROTECTED]> wrote: Me too, I added "-D_POSIX_C_SOURCE=200112" to "fix" this. That works for me. Thanks for the tip. Gordon -- Gordon Farquharson - 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] mm: fix page_mkclean_one
From: "Gordon Farquharson" <[EMAIL PROTECTED]> Date: Wed, 27 Dec 2006 22:20:20 -0700 > and for some reason I get > > linus-test.c: In function 'remap': > linus-test.c:61: error: 'POSIX_FADV_DONTNEED' undeclared (first use in > this function) > > when I compile the program, so I replaced POSIX_FADV_DONTNEED with 4 > as defined in /usr/include/bits/fcntl.h. Me too, I added "-D_POSIX_C_SOURCE=200112" to "fix" this. Perhaps Linus's GCC sets that by default and our's doesn't. - 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] mm: fix page_mkclean_one
On 12/27/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Wed, 27 Dec 2006, Gordon Farquharson wrote: > > I don't think so. I did reduce the target size > > #define TARGETSIZE (100 << 12) That's just 400kB! There's no way you should see corruption with that kind of value. It should all stay solidly in the cache. Is this perhaps with ARM nommu or something else strange? It may be that the program just doesn't work at all if mmap() is faked out with a malloc or similar. Definitely a question for the ARM gurus. I'm out of my depth. Gordon -- Gordon Farquharson - 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: Feature request: exec self for NOMMU.
On Wednesday 27 December 2006 9:48 pm, Denis Vlasenko wrote:
> Yes Rob, I know it can be done like this. But we don't want this.
> In the tar example, we want :
>
> 'Run my own binary again, with parameters: "zcat" "a.tar.gz",
> even if there is no [/usr][/local]/bin/zcat -> busybox link anywhere'
>
> We do not want to _search for_ zcat. We want to reexec our own binary.
If we find our own binary, we can reexec it. What we search for isn't zcat,
it's argv[0], and the search needs to be done in main() before any logic that
can chdir or set $PATH gets called. Then save that path until we need it.
The kernel does not currently provide an easy way to do exec ourselves, but we
can do it ourself. (And this is a way to do it _without_ proc.)
The problem is, there's no guarante that argv[0] is actually the first
argument to exec(), it can be any arbitrary string. (In fact, if tar wants
to re-exec itself as zcat, we can take advantage of this with
execv("/blah/tar", ["zcat", "-"]);) So it's still a hack. It should work if
we're called from a shell, but not necessarily from elsewhere.
*shrug* Kernel support for re-execing ourself would be nice, especially in
combination with vfork(). If not, I'll figure something out and make it work
in toybox. There are a half-dozen non-kernel approaches, all varying degrees
of hackish. (And daemonize() can probably be done with clone().)
Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
-
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] mm: fix page_mkclean_one
[Oops - forgot to hit "Reply to All" first time round.]
Hi Linus
On 12/27/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
For all I know, my test-program is buggy wrt the ordering printouts,
though. Did you perhaps change the logic in any way?
I don't think so. I did reduce the target size
#define TARGETSIZE (100 << 12)
to make the program finish a little quicker, and for some reason I get
linus-test.c: In function 'remap':
linus-test.c:61: error: 'POSIX_FADV_DONTNEED' undeclared (first use in
this function)
when I compile the program, so I replaced POSIX_FADV_DONTNEED with 4
as defined in /usr/include/bits/fcntl.h.
Other than these two changes, the program is identical to the version
you posted.
I have run the program a few times, and the output is pretty
consistent. However, when I increase the target size, the difference
between the expected and actual values is larger.
Written as (749)935(738)
Chunk 1113 corrupted (1-1455) (2965-323)
Expected 89, got 93
Written as (935)738(538)
Chunk 1114 corrupted (1-1455) (329-1783)
Expected 90, got 94
Written as (738)538(678)
Chunk 1115 corrupted (1-1455) (1789-3243)
Expected 91, got 95
Written as (538)678(989)
Chunk 1120 corrupted (1-1455) (897-2351)
Expected 96, got 100
Written as (537)265(1005)
Chunk 1121 corrupted (1-1455) (2357-3811)
Expected 97, got 101
Written as (265)1005(-1)
--- linus-test.c.orig 2006-12-28 06:17:24.0 +0100
+++ linus-test.c2006-12-28 06:18:24.0 +0100
@@ -6,7 +6,7 @@
#include
#include
-#define TARGETSIZE (100 << 20)
+#define TARGETSIZE (100 << 14)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
@@ -61,7 +61,7 @@
{
if (mapping) {
munmap(mapping, SIZE);
-posix_fadvise(fd, 0, SIZE, POSIX_FADV_DONTNEED);
+posix_fadvise(fd, 0, SIZE, 4);
}
return mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
Gordon
--
Gordon Farquharson
-
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] mm: fix page_mkclean_one
On Wed, 27 Dec 2006, Gordon Farquharson wrote: > > It is at all suprising that the second offset within a page can be > less than the first offset within a page ? e.g. > > Chunk 260 corrupted (1-1455) (2769-127) No, that just means that it went over to the next page (so you actually had two consecutive pages that weren't written out). That said, your output is very different from mine in another way. You don't have zeroes in your pages, rather the thing seems to have data from the next block (ie the chunk that should have 20 is reported as having 21 etc). You also have your offsets shifted up by one (ie offset 0 looks ok for you, and then you have a strange pattern of corruption at bytes 1...1455 instead of 0..1459. You also seem to have an example of the _earlier_ writes being corrupted, rather than the later ones. For example (but it's also a page-crosser, so maybe that's part of it): Chunk 274 corrupted (1-1455) (2729-87) Expected 18, got 19 Written as (154)11(85) says that block chunk 274 is the corrupt one, but it was written fairly early as #11, and the blocks around it (chunks 273 and 275) were actually written later. For all I know, my test-program is buggy wrt the ordering printouts, though. Did you perhaps change the logic in any way? Linus - 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 2.4.32: kernel BUG in slab.c:1582
Hi !
On Wed, Dec 20, 2006 at 12:21:59PM -0700, Sebastian Kuzminsky wrote:
> Hi folks, I've got an old PC (Pentium 133 MHz, 64 MB RAM, no swap)
> running Linux 2.4.32, and lately I've been getting kernel BUGs like this:
>
> kernel: kernel BUG at slab.c:1582!
> kernel: invalid operand:
> kernel: CPU:0
> kernel: EIP:0010:[kmem_cache_free+105/624]Not tainted
> kernel: EFLAGS: 00010293
> kernel: eax: c10b7354 ebx: 3ef0 ecx: 0002b450 edx: c11c
> kernel: esi: 000ad140 edi: c3ef0634 ebp: 0023 esp: c10c3f4c
> kernel: ds: 0018 es: 0018 ss: 0018
> kernel: Process kswapd (pid: 4, stackpage=c10c3000)
> kernel: Stack: c10b7354 c2c13e3c c3ef0634 c036dd3c 0023 c01426ca
> c10b7354 c3ef0634
> kernel:003c 01d0 0009 c0232f18 c01429b5 0379
> c012a7b8 0006
> kernel:01d0 c0232f18 0001 c10c2000
> c012a947
> kernel: Call Trace:[prune_dcache+266/320]
> [shrink_dcache_memory+37/64] [try_to_free_pages_zone+104/208]
> [kswapd_balance_pgdat+87/160] [kswapd_balance+22/48]
> kernel: [kswapd+143/176] [_stext+0/48] [arch_kernel_thread+35/48]
> [kswapd+0/176]
> kernel:
> kernel: Code: 0f 0b 2e 06 7a c0 20 c0 9c 8f 04 24 fa 3b 1d 20 82 28 c0 89
>
>
> The system is a bit tight on memory, but /proc/meminfo reports MemFree +
> Buffers + Cached > 10 MB.
>
> After kswapd stepped on the BUG, it happened several more times by
> different processes and different code paths, but always ending with this:
>
> Call Trace:[prune_dcache+266/320] [shrink_dcache_memory+37/64]
> [try_to_free_pages_zone+104/208] [balance_classzone+76/560]
> [__alloc_pages+363/624]
>
>
> The BUG is this one:
>
> /**
> * kmem_cache_free - Deallocate an object
> * @cachep: The cache the allocation was from.
> * @objp: The previously allocated object.
> *
> * Free an object which was previously allocated from this
> * cache.
> */
> void kmem_cache_free (kmem_cache_t *cachep, void *objp)
> {
> unsigned long flags;
> #if DEBUG
> CHECK_PAGE(virt_to_page(objp));
> if (cachep != GET_PAGE_CACHE(virt_to_page(objp)))
> BUG();
> #endif
>
> local_irq_save(flags);
> __kmem_cache_free(cachep, objp);
> local_irq_restore(flags);
> }
>
>
> So prune_dcache() gets called to free up some memory, but then it hands
> kmem_cache_free an inconsistent object to free? Is this indicative of
> memory corruption?
Could be. Especially on such a machine, it was the era of unreliable
memory busses between RAM, chipsets and CPUs, unreliable cache sticks,
unreliable RAM sticks, and unreliable voltage regulators causing
lockups and cache corruption. I don't think the problem is related to
low memory because you should get OOM messages if this was the case.
Have you tried running memtest on this machine ? I would bet that it
could find errors. I do still run a P133 which stayed up for 2 years
before the mains was cut, but I've encountered many of them showing
frequent lockups in the past, particularly on those with a small
cache card plugged into a special slot close to the CPU. You may try
to disable the cache in the BIOS, because I suspect that performance
is less of a problem for you on such a machine than reliability.
Slightly increasing the CPU voltage might also compensate for an aging
regulator.
Best regards,
Willy
-
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] fix typo in i2c smbus documentation
the i2c smbus documentation has a typo ... when it describes the "SMBus Write Word Data" function, it says that it is meant to "read from a device" when in reality it should obviously be writing to the device btw, the i2c/smbus docs in Documentation/i2c/ are superb, thanks all :) -mike linux-i2c-smbus-doc-typo.patch Description: Binary data
Re: [PATCH] mm: fix page_mkclean_one
On 12/27/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: [ Modified test-program that tells you where the corruption happens (and when the missing parts were supposed to be written out) appended, in case people care. ] For the record, this is the output from a run on our ARM machine (32 MB RAM) with 2.6.18 + the following patches: mm: tracking shared dirty pages mm: balance dirty pages mm: optimize the new mprotect() code a bit mm: small cleanup of install_page() mm: fixup do_wp_page() mm: msync() cleanup It is at all suprising that the second offset within a page can be less than the first offset within a page ? e.g. Chunk 260 corrupted (1-1455) (2769-127) $ ./linus-test Writing chunk 279/280 (99%) Chunk 256 corrupted (1-1455) (1025-2479) Expected 0, got 1 Written as (82)175(56) Chunk 258 corrupted (1-1455) (3945-1303) Expected 2, got 3 Written as (56)51(20) Chunk 260 corrupted (1-1455) (2769-127) Expected 4, got 5 Written as (20)30(18) Chunk 262 corrupted (1-1455) (1593-3047) Expected 6, got 7 Written as (18)196(158) Chunk 264 corrupted (1-1455) (417-1871) Expected 8, got 9 Written as (158)133(146) Chunk 266 corrupted (1-1455) (3337-695) Expected 10, got 11 Written as (146)43(77) Chunk 268 corrupted (1-1455) (2161-3615) Expected 12, got 13 Written as (77)251(211) Chunk 270 corrupted (1-1455) (985-2439) Expected 14, got 15 Written as (211)257(231) Chunk 272 corrupted (1-1455) (3905-1263) Expected 16, got 17 Written as (231)254(154) Chunk 274 corrupted (1-1455) (2729-87) Expected 18, got 19 Written as (154)11(85) Chunk 276 corrupted (1-1455) (1553-3007) Expected 20, got 21 Written as (85)230(134) Chunk 278 corrupted (1-1455) (377-1831) Expected 22, got 23 Written as (134)233(103) Checking chunk 279/280 (99%) Gordon -- Gordon Farquharson - 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.19.1, sata_sil: sata dvd writer doesn't work
Tejun Heo wrote:
> Harald Dunkel wrote:
>> Hi Tejun,
>>
>> Tejun Heo wrote:
>>> * dmesg is truncated, please post the content of file /var/log/boot.msg.
>>>
>>> * Please post the result of 'lspci -nnvvv'
>>>
>>> * Please try the attached patch and see if it makes any difference and
>>> post the result of 'dmesg' after trying to play a problematic dvd.
>>>
>> It still doesn't work, but the dmesg output looks less
>> weird. See attachments.
>>
>>
>> Hope this helps. Please mail.
>
> Okay, Hmmm... Weird. I tried to reproduce it here w/ LG dvd ram and
> sil3114 (almost identical, just two more ports) with no success. I just
> ordered SH-S183A and it should arrive later today (zero-day shipping
> just at USD 3.5!).
>
> I'll write again when I know more.
>
Failed to reproduce here. Please do the following two things.
1. Post the result of "mplayer -v dvd:// > out 2>&1"
2. Apply the attached patch to v2.6.19 and report dmesg after playing dvd.
Happy new year.
--
tejun
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 02b2b27..cd92a70 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1139,6 +1139,7 @@ static unsigned int ata_eh_analyze_tf(struct
ata_queued_cmd *qc,
tmp = atapi_eh_request_sense(qc->dev,
qc->scsicmd->sense_buffer);
if (!tmp) {
+ const u8 *c = qc->cdb;
/* ATA_QCFLAG_SENSE_VALID is used to tell
* atapi_qc_complete() that sense data is
* already valid.
@@ -1146,6 +1147,17 @@ static unsigned int ata_eh_analyze_tf(struct
ata_queued_cmd *qc,
* TODO: interpret sense data and set
* appropriate err_mask.
*/
+ ata_dev_printk(qc->dev, KERN_ERR,
+ "CDB:
%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x "
+ "%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x
p=%d\n",
+ c[0], c[1], c[2], c[3], c[4], c[5],
c[6], c[7],
+ c[8], c[9], c[10], c[11], c[12], c[13],
c[14], c[15],
+ qc->tf.protocol);
+ ata_dev_printk(qc->dev, KERN_ERR,
+ "SENSE: k %02x a %02x:%02x\n",
+ qc->scsicmd->sense_buffer[2],
+ qc->scsicmd->sense_buffer[12],
+ qc->scsicmd->sense_buffer[13]);
qc->flags |= ATA_QCFLAG_SENSE_VALID;
} else
qc->err_mask |= tmp;
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 47ea111..bb8b860 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -51,7 +51,7 @@
#define SECTOR_SIZE512
-typedef unsigned int (*ata_xlat_func_t)(struct ata_queued_cmd *qc, const u8
*scsicmd);
+typedef unsigned int (*ata_xlat_func_t)(struct ata_queued_cmd *qc);
static struct ata_device * __ata_scsi_find_dev(struct ata_port *ap,
const struct scsi_device *scsidev);
@@ -951,7 +951,6 @@ int ata_scsi_change_queue_depth(struct scsi_device *sdev,
int queue_depth)
/**
* ata_scsi_start_stop_xlat - Translate SCSI START STOP UNIT command
* @qc: Storage for translated ATA taskfile
- * @scsicmd: SCSI command to translate
*
* Sets up an ATA taskfile to issue STANDBY (to stop) or READ VERIFY
* (to start). Perhaps these commands should be preceded by
@@ -964,22 +963,25 @@ int ata_scsi_change_queue_depth(struct scsi_device *sdev,
int queue_depth)
* RETURNS:
* Zero on success, non-zero on error.
*/
-
-static unsigned int ata_scsi_start_stop_xlat(struct ata_queued_cmd *qc,
-const u8 *scsicmd)
+static unsigned int ata_scsi_start_stop_xlat(struct ata_queued_cmd *qc)
{
+ struct scsi_cmnd *scmd = qc->scsicmd;
struct ata_taskfile *tf = >tf;
+ const u8 *cdb = scmd->cmnd;
+
+ if (scmd->cmd_len < 5)
+ goto invalid_fld;
tf->flags |= ATA_TFLAG_DEVICE | ATA_TFLAG_ISADDR;
tf->protocol = ATA_PROT_NODATA;
- if (scsicmd[1] & 0x1) {
+ if (cdb[1] & 0x1) {
; /* ignore IMMED bit, violates sat-r05 */
}
- if (scsicmd[4] & 0x2)
+ if (cdb[4] & 0x2)
goto invalid_fld; /* LOEJ bit set not supported */
- if (((scsicmd[4] >> 4) & 0xf) != 0)
+ if (((cdb[4] >> 4) & 0xf) != 0)
goto invalid_fld; /* power conditions not supported */
- if (scsicmd[4] & 0x1) {
+ if (cdb[4] & 0x1) {
tf->nsect = 1; /* 1 sector, lba=0 */
if (qc->dev->flags & ATA_DFLAG_LBA) {
@@ -1012,7 +1014,7 @@ static
Re: Oops in 2.6.19.1
On Thursday 28 December 2006 04:02, Alistair John Strachan wrote: > On Thursday 28 December 2006 02:41, Zhang, Yanmin wrote: > [snip] > > > > Here's a current decompilation of vmlinux/pipe_poll() from the running > > > kernel, the addresses have changed slightly. There's no xchg there > > > either: > > > > Could you reproduce the bug by the new kernel, so we could get the exact > > address and instruction of the bug? > > It crashed again, but this time with no output (machine locked solid). To > be honest, the disassembly looks right (it's like Chuck said, it's jumping > back half way through an instruction): > > c0156f5f: 3b 87 68 01 00 00 cmp0x168(%edi),%eax > > So c0156f60 is 87 68 01 00 00.. > > This is with the GCC recompile, so it's not a distro problem. It could > still either be GCC 4.x, or a 2.6.19.1 specific bug, but it's serious. > 2.6.19 with GCC 3.4.3 is 100% stable. Looks like a similar crash here: http://ubuntuforums.org/showthread.php?p=1803389 -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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 2.6.19.1
On Thursday 28 December 2006 02:41, Zhang, Yanmin wrote: [snip] > > Here's a current decompilation of vmlinux/pipe_poll() from the running > > kernel, the addresses have changed slightly. There's no xchg there > > either: > > Could you reproduce the bug by the new kernel, so we could get the exact > address and instruction of the bug? It crashed again, but this time with no output (machine locked solid). To be honest, the disassembly looks right (it's like Chuck said, it's jumping back half way through an instruction): c0156f5f: 3b 87 68 01 00 00 cmp0x168(%edi),%eax So c0156f60 is 87 68 01 00 00.. This is with the GCC recompile, so it's not a distro problem. It could still either be GCC 4.x, or a 2.6.19.1 specific bug, but it's serious. 2.6.19 with GCC 3.4.3 is 100% stable. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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 2.6.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2
On 12/22/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote: Well thinking more about it, this wouldn't work for all cache types. For example, if your cache is not a direct maped one, this workaround won't work. So this is definitely not a portable solution. From asking peterz on #mm, I think page_mkclean will do the right thing and call something like flush_cache_page. I think that resolves the issue which I think you identified where the end symptom on archs with virtually tagged caches could be a line of pixels written by userspace through one PTE remain in-cache and therefore "undisplayed" when the kernel reads through another PTE that may fall on a different cacheline. Thanks, jayakumar - 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] drop page cache of a single file
On Thu, 28 Dec 2006 11:17:25 +0800 "Zhang, Yanmin" <[EMAIL PROTECTED]> wrote: > Currently, by /proc/sys/vm/drop_caches, applications could drop pagecache, > slab(dentries and inodes), or both, but applications couldn't choose to > just drop the page cache of one file. An user of VOD (Video-On-Demand) > needs this capability to have more detailed control on page cache release. The posix_fadvise() system call should be used for this. Probably in combination with sys_sync_file_range(). - 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: Page alignment issue
On 12/27/06, Aubrey <[EMAIL PROTECTED]> wrote: As for the buddy system, much of docs mention the physical address of the first page frame of a block should be a multiple of the group size. For example, the initial address of a 16-page-frame block should be 16-page aligned. I happened to encounted an issue that the physical addresss pf the block is not 4-page aligned(0x36c9000) while the order of the block is 2. I want to know what out of buddy algorithm depend on this feature? My problem seems to happen in schedule()->context_switch() call, but so far I didn't figure out the root cause. It seems nothing depend on this feature. the problem you encounted is the kernel task stack should be 2-page aligned. -Aubrey - 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/
PL2303 module
Greetings; Rather offtopic, but: Is there available anyplace, a document that describes how to configure the PL2303 USB<->serial adaptor to match up with all the hardware and flow control variations inherent in the basic rs-232 spec? Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. - 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: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) r0xj0
Andrew Lyon wrote:
> Hi,
>
> My system is gigabyte ds3 motherboard with onboard SATA JMicron
> 20360/20363 AHCI Controller (rev 02), drive connected is WDC
> WD740ADFD-00 20.0, I am running 2.6.18.6 32 bit, under heavy i/o I get
> the following messaegs:
>
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
> ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0)
>
> Is this condition dangerous?
Not usually. Might indicate something is going wrong in some really
rare cases. I think vendors are getting NCQ right these days. Maybe
it's time to remove that printk.
> I plan to upgrade to 2.6.19 soon as I have problems with a sata dvd
> writer but I have to wait for a driver that I need to catch up, this
> system cannot be down for long as it runs mythtv.
Can you apply the attached patch and report what the kernel says?
Please include full dmesg.
Thanks.
--
tejun
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index b517d24..13f5853 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1162,10 +1162,21 @@ static void ahci_host_intr(struct ata_port *ap)
if (ata_tag_valid(ap->active_tag) && (status & PORT_IRQ_PIOS_FIS))
return;
- if (ata_ratelimit())
+ if (ata_ratelimit()) {
+ struct ahci_port_priv *pp = ap->private_data;
+ const u32 *f = pp->rx_fis + 0x58;
+
ata_port_printk(ap, KERN_INFO, "spurious interrupt "
- "(irq_stat 0x%x active_tag %d sactive 0x%x)\n",
+ "(irq_stat 0x%x active_tag 0x%x sactive
0x%x)\n",
status, ap->active_tag, ap->sactive);
+ if (status & PORT_IRQ_SDB_FIS) {
+ ata_port_printk(ap, KERN_INFO, "issue=0x%x SAct=0x%x "
+ "SDB_FIS=%08x:%08x\n",
+ readl(port_mmio + PORT_CMD_ISSUE),
+ readl(port_mmio + PORT_SCR_ACT),
+ f[0], f[1]);
+ }
+ }
}
static void ahci_irq_clear(struct ata_port *ap)
[PATCH] drop page cache of a single file
Currently, by /proc/sys/vm/drop_caches, applications could drop pagecache,
slab(dentries and inodes), or both, but applications couldn't choose to
just drop the page cache of one file. An user of VOD (Video-On-Demand)
needs this capability to have more detailed control on page cache release.
Below patch against 2.6.19 implements it.
Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>
---
diff -Nraup linux-2.6.19/Documentation/filesystems/proc.txt
linux-2.6.19_dropcache/Documentation/filesystems/proc.txt
--- linux-2.6.19/Documentation/filesystems/proc.txt 2006-12-08
15:32:44.0 +0800
+++ linux-2.6.19_dropcache/Documentation/filesystems/proc.txt 2006-12-28
10:20:39.0 +0800
@@ -1320,6 +1320,8 @@ To free dentries and inodes:
echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
echo 3 > /proc/sys/vm/drop_caches
+To free the pagecache of one file:
+ echo "4 /path/to/filename" > /proc/sys/vm/drop_caches
As this is a non-destructive operation and dirty objects are not freeable, the
user should run `sync' first.
diff -Nraup linux-2.6.19/fs/drop_caches.c
linux-2.6.19_dropcache/fs/drop_caches.c
--- linux-2.6.19/fs/drop_caches.c 2006-12-08 15:31:58.0 +0800
+++ linux-2.6.19_dropcache/fs/drop_caches.c 2006-12-28 11:04:22.0
+0800
@@ -8,9 +8,9 @@
#include
#include
#include
+#include
-/* A global variable is a bit ugly, but it keeps the code simple */
-int sysctl_drop_caches;
+char sysctl_drop_caches[PATH_MAX+2];
static void drop_pagecache_sb(struct super_block *sb)
{
@@ -54,15 +54,70 @@ void drop_slab(void)
} while (nr_objects > 10);
}
+void drop_file_pagecache(char *path)
+{
+ struct inode *inode;
+ struct nameidata nd;
+ int error;
+
+ if (!path || !*path)
+ return;
+
+ error = path_lookup(path, LOOKUP_FOLLOW, );
+ if (error)
+ return;
+
+ inode = nd.dentry->d_inode;
+ if (!(inode->i_state & (I_FREEING|I_WILL_FREE)))
+ invalidate_inode_pages(inode->i_mapping);
+ path_release();
+
+ return;
+}
+
int drop_caches_sysctl_handler(ctl_table *table, int write,
struct file *file, void __user *buffer, size_t *length, loff_t *ppos)
{
- proc_dointvec_minmax(table, write, file, buffer, length, ppos);
- if (write) {
- if (sysctl_drop_caches & 1)
+ int error;
+ char *path;
+ int operation;
+
+ error = proc_dostring(table, write, file, buffer, length, ppos);
+ if (write && !error) {
+ sscanf(sysctl_drop_caches, "%d", );
+
+ switch (operation) {
+ case 1:
drop_pagecache();
- if (sysctl_drop_caches & 2)
+ break;
+ case 2:
drop_slab();
+ break;
+ case 3:
+ drop_pagecache();
+ drop_slab();
+ break;
+ case 4:
+ /*
+* The format in sysctl_drop_caches is:
+* 4 /path/to/filename
+*/
+ path = strchr(sysctl_drop_caches, '4');
+ if (!path)
+ break;
+
+ path ++;
+ while (*path) {
+ if (*path == ' ' || *path == '\t')
+ path ++;
+ else
+ break;
+ }
+
+ drop_file_pagecache(path);
+ break;
+ }
}
return 0;
}
+
diff -Nraup linux-2.6.19/include/linux/mm.h
linux-2.6.19_dropcache/include/linux/mm.h
--- linux-2.6.19/include/linux/mm.h 2006-12-08 15:32:49.0 +0800
+++ linux-2.6.19_dropcache/include/linux/mm.h 2006-12-28 09:59:10.0
+0800
@@ -1121,6 +1121,7 @@ unsigned long shrink_slab(unsigned long
unsigned long lru_pages);
void drop_pagecache(void);
void drop_slab(void);
+void drop_file_pagecache(char *path);
#ifndef CONFIG_MMU
#define randomize_va_space 0
diff -Nraup linux-2.6.19/kernel/sysctl.c linux-2.6.19_dropcache/kernel/sysctl.c
--- linux-2.6.19/kernel/sysctl.c2006-12-08 15:32:49.0 +0800
+++ linux-2.6.19_dropcache/kernel/sysctl.c 2006-12-28 09:50:18.0
+0800
@@ -73,7 +73,7 @@ extern int min_free_kbytes;
extern int printk_ratelimit_jiffies;
extern int printk_ratelimit_burst;
extern int pid_max_min, pid_max_max;
-extern int sysctl_drop_caches;
+extern char sysctl_drop_caches[PATH_MAX+2];
extern int percpu_pagelist_fraction;
extern int compat_log;
@@ -901,10 +901,10 @@ static ctl_table vm_table[] = {
.ctl_name = VM_DROP_PAGECACHE,
.procname =
Re: [PATCH] mm: fix page_mkclean_one
On Wed, 27 Dec 2006, David Miller wrote:
> >
> > I still don't see _why_, though. But maybe smarter people than me can see
> > it..
>
> FWIW this program definitely triggers the bug for me.
Ok, now that I have something simple to do repeatable stuff with, I can
say what the pattern is.. It's not all that surprising, but it's still
worth just stating for the record.
What happens is that when I do the "packetized writes" in random order,
the _last_ write to a page occasionally just goes missing. It's not always
at the end of a page, as shown by for example:
- A whole chunk got dropped:
Chunk 2094 corrupted (0-1459) (1624-3083)
Expected 46, got 0
Written as (30912)55414(1)
That "Written as (x)y(z)" line means that the corrupted chunk was
written as chunk #y, and the preceding and following chunks (that were
_not_ corrupt) on the page was written as #x and #z respectively.
In other words, the missing chunk (which is still zero) was written
much later than the ones that were ok, and never hit the disk. It's a
contiguous chunk in the middle of the page (chunks are 1460 bytes in
size)
The first line means that all bytes of the chunk (0-1459) were
corrupted, and the values in parenthesis are the offsets within a page.
In other words, this was a chunk in the _middle_ of a page.
- The missing data can also be at the beginning or ends of pages:
Beginning of the chunk missing, it was at the end of a page (page
offsets 3288-4095) and the _next_ page got written out fine:
Chunk 2126 corrupted (0-807) (3288-4095)
Expected 78, got 0
Written as (32713)55573(14301)
End of a chunk missing, it was the beginning of a page (and the
_previous_ page that contained the beginning of the chunk was written
out fine)
Chunk 2179 corrupted (1252-1459) (0-207)
Expected 131, got 0
Written as (45189)55489(15515)
Now, the reason I say this isn't surprising is that this is entirely
consistent with the dirty bit being dropped on the floor somewhere, and
likely through some interaction with the previous changes being in the
process of being written out.
Something (incorrectly) ends up deciding that it doesn't need to write the
page, since it's already written, or alternatively clears the dirty bit
too late (clears it because an _earlier_ write finished, never mind that
the new dirty data didn't make it).
I also figured out that it's not the low-memory situation that does it, it
really must be the "page_mkclean()" triggering. Becuase I can do
echo 5 > /proc/sys/vm/dirty_ratio
echo 3 > /proc/sys/vm/dirty_background_ratio
to make it clean the pages much more aggressively than the default, and I
can see corruption on my 256MB machine with just a 40MB shared file, and
70MB of memory consistently free.
So this thing is definitely giving some answers. It's NOT about low
memory, and it very much seems to be about the whole "balance_dirty_ratio"
thing. I don't think I triggered the actual low-memory stuff once in that
situation..
So I have some more data on the behaviour, but I _still_ don't see the
reason behind it. It's probably something really obvious once it's pointed
out..
[ Modified test-program that tells you where the corruption happens (and
when the missing parts were supposed to be written out) appended, in
case people care. ]
Linus
---
#include
#include
#include
#include
#include
#include
#include
#define TARGETSIZE (100 << 20)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
static void fillmem(void *start, int nr)
{
memset(start, nr, CHUNKSIZE);
}
#define page_offset(buf, off) (0xfff & ((unsigned)(unsigned long)(buf)+(off)))
static int chunkorder[NRCHUNKS];
static int order(int nr)
{
int i;
if (nr < 0 || nr >= NRCHUNKS)
return -1;
for (i = 0; i < NRCHUNKS; i++)
if (chunkorder[i] == nr)
return i;
return -2;
}
static void checkmem(void *buf, int nr)
{
unsigned int start = ~0u, end = 0;
unsigned char c = nr, *p = buf, differs = 0;
int i;
for (i = 0; i < CHUNKSIZE; i++) {
unsigned char got = *p++;
if (got != c) {
if (i < start)
start = i;
if (i > end)
end = i;
differs = got;
}
}
if (start < end) {
printf("Chunk %d corrupted (%u-%u) (%u-%u)\n", nr,
start, end,
page_offset(buf, start), page_offset(buf, end));
printf("Expected %u, got %u\n", c, differs);
printf("Written as (%d)%d(%d)\n", order(nr-1), order(nr),
order(nr+1));
}
}
static char
Re: Feature request: exec self for NOMMU.
On Wednesday 27 December 2006 22:03, Rob Landley wrote: > On Wednesday 27 December 2006 1:35 pm, Denis Vlasenko wrote: > > This solves chroot problem. How to find path-to-yourself reliably > > (for one, without using /proc/self/exe) is not obvious to me. > > Been there, done that. Both my toybox and Firmware Linux projects do this. > In FWL it's line 115 of this file: > http://landley.net/hg/firmware?f=937346748ff4;file=sources/toys/gcc-uClibc.c > > It's essentially the logic of the command line "which" utility applied to > argv[0]. If argv[0] has a relative or absolute path, then it's vs cwd (this > has to happen when you first run the program, before you cd). If argv[0] has > no path then look at $PATH. Yes Rob, I know it can be done like this. But we don't want this. In the tar example, we want : 'Run my own binary again, with parameters: "zcat" "a.tar.gz", even if there is no [/usr][/local]/bin/zcat -> busybox link anywhere' We do not want to _search for_ zcat. We want to reexec our own binary. -- vda - 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 2.6.19.1
On Wed, 2006-12-27 at 12:35 +, Alistair John Strachan wrote: > On Wednesday 27 December 2006 02:07, Zhang, Yanmin wrote: > [snip] > > > Call Trace: > > > [] do_sys_poll+0x253/0x480 > > > [] sys_poll+0x33/0x50 > > > [] syscall_call+0x7/0xb > > > [] 0xb7f26402 > > > === > > > Code: 58 01 00 00 0f 4f c2 09 c1 89 c8 83 c8 08 85 db 0f 44 c8 8b 5d f4 > > > 89 c8 8b 75 > > > f8 8b 7d fc 89 ec 5d c3 89 ca 8b 46 6c 83 ca 10 3b <87> 68 01 00 00 0f 45 > > > ca eb b6 8d b6 00 00 00 00 55 b8 01 00 00 > > > > Above codes look weird. Could you disassemble kernel image and post > > the part around address 0xc0156f60? > > > > "87 68 01 00 00" is instruction xchg, but if I disassemble from the > > begining, I couldn't see instruct xchg. > > > > > EIP: [] pipe_poll+0xa0/0xb0 SS:ESP 0068:ee1b9c0c > > Unfortunately, after suspecting the toolchain, I did a manual rebuild of > binutils, gcc and glibc from the official sites, and then rebuilt 2.6.19.1. > This might upset the decompile below, versus the original report. > > Assuming it's NOT a bug in my distro's toolchain (because I am now running > the > GNU stuff), it'll crash again, so this is still useful. > > Here's a current decompilation of vmlinux/pipe_poll() from the running > kernel, > the addresses have changed slightly. There's no xchg there either: Could you reproduce the bug by the new kernel, so we could get the exact address and instruction of the bug? - 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/
kobject_add failed for card0, ALSA and USB
Something has stopped working between usb_audio and ALSA. When I boot my USB audio won't work, but if I remove it and plug it in again it works. I posted this on usb-dev and alsa-dev but everyone is gone. The error occurs when the device is plugged in a again. usb 2-1: new full speed USB device using uhci_hcd and address 3 usb 2-1: configuration #1 chosen from 1 choice ALSA sound/usb/usbaudio.c:2739: 3:1:1: add audio endpoint 0x1 ALSA sound/usb/usbaudio.c:2739: 3:2:1: add audio endpoint 0x82 ALSA sound/usb/usbmixer.c:989: [2] FU [PCM Playback Switch] ch = 1, val = 0/1/1 ALSA sound/usb/usbmixer.c:989: [2] FU [PCM Playback Volume] ch = 6, val = 0/32512/127 ALSA sound/usb/usbmixer.c:989: [5] FU [PCM Capture Switch] ch = 1, val = 0/1/1 ALSA sound/usb/usbmixer.c:989: [5] FU [PCM Capture Volume] ch = 2, val = 0/6144/768 kobject_add failed for card0 with -EEXIST, don't try to register things with the same name in the same directory. [] kobject_add+0x10f/0x190 [] device_add+0xb7/0x530 [] kobject_get+0xf/0x20 [] kobject_init+0x2b/0x40 [] device_create+0x88/0xc0 [] snd_card_register+0x2e7/0x3c0 [snd] [] usb_driver_claim_interface+0x84/0xb0 [usbcore] [] usb_audio_probe+0x5dc/0xa30 [snd_usb_audio] [] try_to_del_timer_sync+0x47/0x50 [] usb_probe_interface+0x96/0xe0 [usbcore] [] really_probe+0x54/0x140 [] driver_probe_device+0x49/0xc0 [] klist_next+0x53/0xa0 [] bus_for_each_drv+0x44/0x70 [] device_attach+0x7a/0x80 [] __device_attach+0x0/0x10 [] bus_attach_device+0x26/0x60 [] device_add+0x455/0x530 [] usb_set_configuration+0x3f1/0x4d0 [usbcore] [] generic_probe+0x157/0x210 [usbcore] [] usb_probe_device+0x33/0x40 [usbcore] [] really_probe+0x54/0x140 [] driver_probe_device+0x49/0xc0 [] klist_next+0x53/0xa0 [] bus_for_each_drv+0x44/0x70 [] device_attach+0x7a/0x80 [] __device_attach+0x0/0x10 [] bus_attach_device+0x26/0x60 [] device_add+0x455/0x530 [] __usb_new_device+0x92/0x120 [usbcore] [] hub_thread+0x74b/0xc10 [usbcore] [] autoremove_wake_function+0x0/0x50 [] hub_thread+0x0/0xc10 [usbcore] [] kthread+0xba/0xf0 [] kthread+0x0/0xf0 [] kernel_thread_helper+0x7/0x1c === input: Philips Electronics Philips PSC805 as /class/input/input6 input,hiddev96: USB HID v1.00 Device [Philips Electronics Philips PSC805] on usb-:00:1d.1-1 ALSA sound/usb/usbaudio.c:1317: setting usb interface 1:1 ALSA sound/usb/usbaudio.c:1317: setting usb interface 1:1 -- 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: PATA -- pata_amd on 2.6.19 fails to IDENTIFY my DVD-ROM
Rene Herman wrote: > Tejun Heo wrote: > >> Rene Herman wrote: > >>> I just tried the PATA driver for my AMD756 chip. During boot, it hangs >>> for 3 minutes failing to identify my DVD-ROM (secondary slave) and does >>> not give me access to it after it timed out. >> >> Please give a shot at v2.6.20-rc2 and report what the kernel says. > > This IDENTIFY issue seems already fixed in -rc2. No more pause, and my > DVD-ROM works fine again. Great. > Unfortunately, another issue seems to have > cropped up. On 2.6.20-rc2, hdparm -t /dev/sda gets me ~ 24 M/s while > both the old IDE driver and the 2.6.19 PATA driver do ~ 50 M/s > > 2.6.20-rc2-ata: > > # hdparm -t /dev/sda > > /dev/sda: > Timing buffered disk reads: 72 MB in 3.03 seconds = 23.75 MB/sec > > 2.6.19-ata: > > # hdparm -t /dev/sda > > /dev/sda: > Timing buffered disk reads: 150 MB in 3.00 seconds = 49.94 MB/sec Everything seems fine in the dmesg. Performance degradation is probably some other issue in -rc kernel. I'm suspecting recently fixed block layer bug. If it's still the same in the next -rc, please report. Thanks. -- tejun - 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: scheduling while atomic, new libata code
Still getting the bug with patch applied. BUG: scheduling while atomic: hald-addon-stor/0x2000/5078 [] __sched_text_start+0x5f9/0xb00 [] net_rx_action+0xb3/0x180 [] __do_softirq+0x72/0xe0 [] do_IRQ+0x45/0x80 [] common_interrupt+0x23/0x28 [] __cond_resched+0x16/0x40 [] cond_resched+0x23/0x30 [] __reacquire_kernel_lock+0x1c/0x3c [] __sched_text_start+0x629/0xb00 [] wait_for_completion+0x8e/0xc0 [] default_wake_function+0x0/0x10 [] blk_execute_rq+0x7c/0xe0 [] __cond_resched+0x16/0x40 [] cond_resched+0x23/0x30 [] kmem_cache_zalloc+0x76/0x90 [] scsi_execute_req+0x3d/0xf0 [] sg_io+0x2a9/0x340 [] scsi_test_unit_ready+0x56/0xa0 [] sr_media_change+0x52/0x220 [sr_mod] [] reschedule_interrupt+0x28/0x30 [] sr_block_media_changed+0x0/0x10 [sr_mod] [] media_changed+0x5d/0xa0 [cdrom] [] check_disk_change+0x1c/0x80 [] cdrom_open+0x152/0xa90 [cdrom] [] scsi_test_unit_ready+0x56/0xa0 [] __d_lookup+0x89/0x100 [] dput+0xb5/0x130 [] do_lookup+0x65/0x190 [] ext3_permission+0x0/0x10 [ext3] [] dput+0xb5/0x130 [] __link_path_walk+0xc1a/0xc90 [] touch_atime+0x9e/0x110 [] mntput_no_expire+0x1b/0x80 [] link_path_walk+0x65/0xc0 [] hrtimer_cancel+0xe/0x20 [] hrtimer_nanosleep+0x49/0x110 [] kobject_get+0xf/0x20 [] get_disk+0x39/0x70 [] exact_lock+0x7/0x10 [] kobject_get+0xf/0x20 [] sr_block_open+0x5c/0xa0 [sr_mod] [] blkdev_open+0x0/0x70 [] do_open+0x1e9/0x290 [] blkdev_open+0x0/0x70 [] blkdev_open+0x30/0x70 [] __dentry_open+0xba/0x1c0 [] nameidata_to_filp+0x35/0x40 [] do_filp_open+0x4b/0x60 [] hrtimer_cancel+0xe/0x20 [] hrtimer_nanosleep+0x49/0x110 [] do_sys_open+0x4a/0xe0 [] sys_open+0x1c/0x20 [] sysenter_past_esp+0x5f/0x85 === -- 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/
ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) r0xj0
Hi, My system is gigabyte ds3 motherboard with onboard SATA JMicron 20360/20363 AHCI Controller (rev 02), drive connected is WDC WD740ADFD-00 20.0, I am running 2.6.18.6 32 bit, under heavy i/o I get the following messaegs: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive 0x0) Is this condition dangerous? I plan to upgrade to 2.6.19 soon as I have problems with a sata dvd writer but I have to wait for a driver that I need to catch up, this system cannot be down for long as it runs mythtv. Andy - 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 -mm 4/5][time][x86_64] Convert x86_64 to use GENERIC_TIME
On Wed, 20 Dec 2006 17:13:43 -0500 john stultz <[EMAIL PROTECTED]> wrote: > This patch converts x86_64 to use the GENERIC_TIME infrastructure and > adds clocksource structures for both TSC and HPET (ACPI PM is shared w/ > i386). printk timestamping shows a time of zero all the time, because nothing calls set_cyc2ns_scale() any more. I stuck it in time_init(): --- a/arch/x86_64/kernel/time.c~time-x86_64-convert-x86_64-to-use-generic_time-fix +++ a/arch/x86_64/kernel/time.c @@ -361,6 +361,7 @@ void __init time_init(void) else vgetcpu_mode = VGETCPU_LSL; + set_cyc2ns_scale(cpu_khz); printk(KERN_INFO "time.c: Detected %d.%03d MHz processor.\n", cpu_khz / 1000, cpu_khz % 1000); setup_irq(0, ); _ - 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: Happy Birthday to Our Fearless Leader
On Wednesday 27 December 2006 18:39, David R. Meyer wrote: > I hope it doesn't get me kicked off the list for unnecessary traffic, > but Happy Birthday Linus. Thanks for making computing fun again > > Dave > Oh, wow, I totally missed the initial post. Happy Birthday, Linus! DRH > Loye Young wrote: > > Be it remembered that on the 28th day of December in the year of our Lord > > 1969, there was born in the town of Helsinki, Finland, Linus Benedict > > Torvalds. > > > > Long live the king. > > > > - > > 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/
OOPS - KVM in 2.6.20-rc2
Running qemu with 512M ram out of available 480M total invoked the OOM killer (that's obvious along with other OOM-killer stupidities like killing totally irrelevant processes) followed by the below OOPS. Killed process 19271 (trashapplet)Out of memory: kill process 12475 (qemu) score 7899 or a childOut of memory: kill process 12475 (qemu) score 7899 or a childKilled process 12475 (qemu)Killed process 12475 (qemu) BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip:c0153aa2*pde = 17339067*pte = Oops: 0002 [#1]SMPModules linked in: kvm_intel kvm cpufreq_ondemand i915 drm hci_usb autofs4 hidp rfcomm l2cap bluetooth cpufreq_userspace acpi_cpufreq freq_table binfmt_misc nls_utf8 ntfs dm_mirror dm_multipath sbs i2c_ec sbp2 snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm ohci1394 ieee1394 shpchp snd_timer snd intel_agp i2c_i801 agpgart soundcore i2c_core snd_page_alloc ata_piix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010206 (2.6.20-rc2-dirty #4) EIP is at __free_pages+0x2/0x30 eax: ebx: 0001c0c9 ecx: edx: esi: c95aff20 edi: c95aff34 ebp: c7e5c000 esp: c95afd6c ds: 007b es: 007b ss: 0068 Process qemu (pid: 12475, ti=c95ae000 task=ddcff030 task.ti=c95ae000) Stack: df443723 fff4 df4d8320 0001c0c8 df444d41 20793000 000207a0 bf8436d8 c94c9140 c1684a00 c01c56d9 c01b55d9 ce2f89e8 0580 0006 00020793 0001 c7e5c008 00020793 Call Trace: [] kvm_free_physmem_slot+0x33/0x80 [kvm] [] kvm_dev_ioctl+0xf11/0x1080 [kvm] [] journal_stop+0x159/0x1e0 [] ext3_mark_inode_dirty+0x29/0x40 [] __mark_inode_dirty+0x5c/0x190 [] do_generic_mapping_read+0x44a/0x550 [] get_page_from_freelist+0x257/0x320 [] __alloc_pages+0x57/0x2f0 [] __handle_mm_fault+0x7c6/0x8f0 [] unmap_region+0xf6/0x110 [] kvm_dev_ioctl+0x0/0x1080 [kvm] [] do_ioctl+0x2b/0x90 [] vfs_ioctl+0x5c/0x2a0 [] sys_ioctl+0x3d/0x70 [] sysenter_past_esp+0x5f/0x85 === Code: e9 ad fd ff ff 8b 4b 0c 90 e9 7d fd ff ff 0f 0b eb fe 89 f2 89 e8 e8 0e f8 ff ff e9 5d fe ff ff 8b 4c 24 04 e9 72 ff ff ff 89 c1 ff 48 04 0f 94 c0 84 c0 74 13 85 d2 74 07 89 c8 e9 08 fd ff EIP: [] __free_pages+0x2/0x30 SS:ESP 0068:c95afd6c - 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] mm: fix page_mkclean_one
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed, 27 Dec 2006 16:39:43 -0800 (PST) > > > On Wed, 27 Dec 2006, Linus Torvalds wrote: > > > > I think the test-case could probably be improved by having a munmap() and > > page-cache flush in between the writing and the checking, to see whether > > that shows the corruption easier (and possibly without having to start > > paging in order to throw the pages out, which would simplify testing a > > lot). > > I think the page-writeout is implicated, because I do seem to need it, but > the page-cache flush does seem to make corruption _easier_ to see. I now > seem about to trigger it with a 100MB file on a 256MB machine in a minute > or so, with this slight modification. > > I still don't see _why_, though. But maybe smarter people than me can see > it.. FWIW this program definitely triggers the bug for me. - 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] mm: fix page_mkclean_one
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed, 27 Dec 2006 16:42:40 -0800 (PST) > That's fine. In that situation, you shouldn't need any atomic ops at all, > I think all our sw page-table operations are already done under the pte > lock. This is true, but there is one subtlety to this I want to point out in passing. That lock can possibly only protect a page of PTEs. When NR_CPUS >= CONFIG_SPLIT_PTLOCK_CPUS, the locking is done per page of PTEs, not for all of the page tables of an address space at once. What this means is that it's really difficult to forcefully block out all page table operations for a given mm, and I actually needed to do something like this on sparc64 (when growing the TLB lookup hash table, you can't let any PTEs change state while the table is changing). For my case, I added a spinlock to mm->context since actually what I need is to block modifications to the hash table itself during PTE changes. - 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] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Thu, 28 Dec 2006, Martin Schwidefsky wrote: > > For s390 there are two aspects to consider: > 1) the pte values are 100% software controlled. That's fine. In that situation, you shouldn't need any atomic ops at all, I think all our sw page-table operations are already done under the pte lock. The reason x86 needs to be careful is exactly the fact that the hardware will obviously do a lot on its own, and the hardware is _not_ going to honor our page table locking ;) In an all-sw situation, a lot of this should be easier. S390 has _other_ things that are inconvenient (the strange "dirty bit is not in the page tables" thing that makes it look different from everybody else), but hey, it's a balance.. So for s390, ptep_exchange() in my example should be able to be a simple "load old value and store new one", assuming everybody honors the pte lock (and they _should_). Linus - 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] mm: fix page_mkclean_one
On Wed, 27 Dec 2006, Linus Torvalds wrote:
>
> I think the test-case could probably be improved by having a munmap() and
> page-cache flush in between the writing and the checking, to see whether
> that shows the corruption easier (and possibly without having to start
> paging in order to throw the pages out, which would simplify testing a
> lot).
I think the page-writeout is implicated, because I do seem to need it, but
the page-cache flush does seem to make corruption _easier_ to see. I now
seem about to trigger it with a 100MB file on a 256MB machine in a minute
or so, with this slight modification.
I still don't see _why_, though. But maybe smarter people than me can see
it..
Linus
---
#include
#include
#include
#include
#include
#include
#include
#define TARGETSIZE (100 << 20)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
static void fillmem(void *start, int nr)
{
memset(start, nr, CHUNKSIZE);
}
static void checkmem(void *start, int nr)
{
unsigned char c = nr, *p = start;
int i;
for (i = 0; i < CHUNKSIZE; i++) {
if (*p++ != c) {
printf("Chunk %d corrupted \n", nr);
return;
}
}
}
static char *remap(int fd, char *mapping)
{
if (mapping) {
munmap(mapping, SIZE);
posix_fadvise(fd, 0, SIZE, POSIX_FADV_DONTNEED);
}
return mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
}
int main(int argc, char **argv)
{
char *mapping;
int fd, i;
static int chunkorder[NRCHUNKS];
/*
* Make some random ordering of writing the chunks to the
* memory map..
*
* Start with fully ordered..
*/
for (i = 0; i < NRCHUNKS; i++)
chunkorder[i] = i;
/* ..and then mix it up randomly */
srandom(time(NULL));
for (i = 0; i < NRCHUNKS; i++) {
int index = (unsigned int) random() % NRCHUNKS;
int nr = chunkorder[index];
chunkorder[index] = chunkorder[i];
chunkorder[i] = nr;
}
fd = open("mapfile", O_RDWR | O_TRUNC | O_CREAT, 0666);
if (fd < 0)
return -1;
if (ftruncate(fd, SIZE) < 0)
return -1;
mapping = remap(fd, NULL);
if (-1 == (int)(long)mapping)
return -1;
for (i = 0; i < NRCHUNKS; i++) {
int chunk = chunkorder[i];
printf("Writing chunk %d/%d (%d%%) \r", i, NRCHUNKS,
100*i/NRCHUNKS);
fillmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
/* Unmap, drop, and remap.. */
mapping = remap(fd, mapping);
/* .. and check */
for (i = 0; i < NRCHUNKS; i++) {
int chunk = i;
printf("Checking chunk %d/%d (%d%%) \r", i, NRCHUNKS,
100*i/NRCHUNKS);
checkmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
return 0;
}
-
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] romsignature/checksum cleanup
Rusty Russell wrote: On Mon, 2006-12-25 at 01:53 +0100, Rene Herman wrote: Rene Herman wrote: Use adding __init to romsignature() (it's only called from probe_roms() which is itself __init) as an excuse to submit a pedantic cleanup. Hmm, by the way, if romsignature() needs this probe_kernel_address() thing, why doesn't romchecksum()? I assume it's all in the same page, but CC'ing Zach is easier than reading the code 8) Some hypervisors don't emulate the traditional physical layout of the first 1M of memory, so those pages might never get physical mappings established during the boot process, causing access to them to fault. Presumably, if the first page is there with a good signature, the entire ROM is mapped. I think Jeremy added this for Xen, and it's harmless on native hardware. Zach - 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] Sanely size hash tables when using large base pages.
On Tue, Dec 26, 2006 at 03:42:57PM +0800, Fengguang Wu wrote:
> On Tue, Dec 26, 2006 at 03:16:52PM +0900, Paul Mundt wrote:
> > pidhash_shift = max(4, fls(megabytes * 4));
> > pidhash_shift = min(12, pidhash_shift);
> > pidhash_size = 1 << pidhash_shift;
> >
> > + size = pidhash_size * sizeof(struct hlist_head);
> > + if (unlikely(size < PAGE_SIZE)) {
> > + size = PAGE_SIZE;
> > + pidhash_size = size / sizeof(struct hlist_head);
> > + pidhash_shift = 0;
>
> But pidhash_shift is not the order of page ;-)
>
Ah, you're right. I'll drop the pidhash changes and resubmit. Thanks.
-
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] mm: fix page_mkclean_one
On Tue, 26 Dec 2006, David Miller wrote:
>
> I've seen it on sparc64, UP kernel, no preempt.
Ok, I still don't have a clue, but I think I at least have a new
test-case.
It can probably be improved upon, but this would _seem_ to trigger the
problem. Can people check?
You'd want to make sure you get page-put activity, by making TARGETSIZE be
big enough to cause memory pressure (and rather than making it bigger, you
might want to make your memory smaller instead, to make it run more
quickly. Either using "mem=128M" or big compiles or something...).
If it finds corruption, you'll see something like
Writing chunk 183858/183859 (99%)
Chunk ..
Chunk 120887 corrupted
Chunk 122372 corrupted
Chunk ...
Checking chunk 183858/183859 (99%)
otherwise it will just say
Writing chunk 183858/183859 (99%)
Checking chunk 183858/183859 (99%)
and exit.
I didn't spend a lot of time verifying this, but I _was_ able to cause
those "Chunk xxx corrupted" messages with this. There's probably a more
efficient better way to do it, but this is better than trying to use
rtorrent, and also makes any worries about what rtorrent does go away.
Of course, maybe it's this test-program that is buggy now, although it
looks trivial enough that I don't think it is.
I think my earlier stress-tester may not have triggered this, because it
just did all its writing in a linear order, so any LRU logic will happen
to write back old pages that we are no longer touching. The randomization
(and using a chunksize that isn't a multiple of a page-size) makes sure
that we're actually going to have lots of rewriting going on.
I think the test-case could probably be improved by having a munmap() and
page-cache flush in between the writing and the checking, to see whether
that shows the corruption easier (and possibly without having to start
paging in order to throw the pages out, which would simplify testing a
lot). But I haven't tested. I decided to post this asap, now that I've
recreated the corruption with something else, and something that is
possibly easier to analyze..
Linus
#include
#include
#include
#include
#include
#include
#include
#define TARGETSIZE (256 << 20)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
static void fillmem(void *start, int nr)
{
memset(start, nr, CHUNKSIZE);
}
static void checkmem(void *start, int nr)
{
unsigned char c = nr, *p = start;
int i;
for (i = 0; i < CHUNKSIZE; i++) {
if (*p++ != c) {
printf("Chunk %d corrupted \n", nr);
return;
}
}
}
int main(int argc, char **argv)
{
char *mapping;
int fd, i;
static int chunkorder[NRCHUNKS];
/*
* Make some random ordering of writing the chunks to the
* memory map..
*
* Start with fully ordered..
*/
for (i = 0; i < NRCHUNKS; i++)
chunkorder[i] = i;
/* ..and then mix it up randomly */
srandom(time(NULL));
for (i = 0; i < NRCHUNKS; i++) {
int index = (unsigned int) random() % NRCHUNKS;
int nr = chunkorder[index];
chunkorder[index] = chunkorder[i];
chunkorder[i] = nr;
}
fd = open("mapfile", O_RDWR | O_TRUNC | O_CREAT, 0666);
if (fd < 0)
return -1;
if (ftruncate(fd, SIZE) < 0)
return -1;
mapping = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (-1 == (int)(long)mapping)
return -1;
for (i = 0; i < NRCHUNKS; i++) {
int chunk = chunkorder[i];
printf("Writing chunk %d/%d (%d%%) \r", i, NRCHUNKS,
100*i/NRCHUNKS);
fillmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
for (i = 0; i < NRCHUNKS; i++) {
int chunk = i;
printf("Checking chunk %d/%d (%d%%) \r", i, NRCHUNKS,
100*i/NRCHUNKS);
checkmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
return 0;
}
-
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 2.6.20-rc1 00/10] Kernel memory leak detector 0.13
On 27/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote: * Ingo Molnar <[EMAIL PROTECTED]> wrote: > The pure per-CPU design would have to embedd the CPU ID the object is > attached to into the allocated object. If that is not feasible then > only the global hash remains i think. embedding the info shouldnt be /that/ hard in case of the SLAB: if the memleak info is at a negative offset from the allocated pointer. I.e. that if kmalloc() returns 'ptr', the memleak info could be at ptr-sizeof(memleak_info). That way you dont have to know the size of the object beforehand and there's absolutely no need for a global hash of any sort. It would probably need to be just a pointer embedded in the allocated block. With the current design, the memleak objects have a lifetime longer than the tracked block. This is mainly to avoid long locking during memory scanning and reporting. (it gets a bit more complex for page aligned allocations for the buddy and for vmalloc - but that could be solved by adding one extra pointer into struct page. [...] This still leaves the issue of marking objects as not being leaks or being of a different type. This is done by calling memleak_* functions at the allocation point (outside allocator) where only the pointer is known. In the vmalloc case, it would need to call find_vm_area. This might not be a big problem, only that memory resources are no longer treated in a unified way by kmemleak (and might not be trivial to add support for new allocators). [...] That is a far more preferable cost than the locking/cache overhead of a global hash.) A global hash would need to be re-built for every scan (and destroyed afterwards), making this operation longer since the pointer values together with their aliases (resulted from using container_of) are added to the hash. I understand the benefits but I personally favor simplicity over performance, especially for code used as a debugging tool. DEBUG_SLAB already introduces an overhead by poisoning the allocated blocks. Generating the backtrace and filling in the memleak objects for every allocation is another overhead. Global structures are indeed a scalability problem but for a reasonable number of CPUs their overhead might not be that big. Anyway, I can't be sure without some benchmarking and this is probably highly dependent on the system (caches, snoop control unit etc.). -- Catalin - 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 -rt] update kmap_atomic on !HIGHMEM
On Wed, 2006-12-27 at 22:25 +0100, Ingo Molnar wrote: > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > I got some scheduling while atomic on x86-64 , and since x86-64 > > doesn't seem to have HIGHMEM there's no workaround for kmap_atomic() . > > > > This patch adds the same as i386 HIGHMEM for !HIGHMEM. > > the problem is that this does not disable pagefaulting while > kmap-atomic. Could you try the patch below, does it solve the assert? > It hasn't crashed after about an hour of stress.. One comment on the patch tho , the pagefault_enable/pagefault_disable need module exports, I saw the build complaining about them. 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: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
On Thu, 2006-12-21 at 12:01 -0800, Linus Torvalds wrote: > What do you guys think? Does something like this work out for S/390 too? I > tried to make that "ptep_flush_dirty()" concept work for architectures > that hide the dirty bit somewhere else too, but.. For s390 there are two aspects to consider: 1) the pte values are 100% software controlled. They only change because a cpu stored a value to it or issued one of the specialized instructions (csp, ipte and idte). The ptep_flush_dirty would be a nop for s390. 2) ptep_exchange is a bit dangerous. For s390 we need a lock that protects the software controlled updates of the ptes. The reason is the ipte instruction. It is implemented by the machine microcode in a non-atomic way in regard to the memory. It reads the byte of the pte that contains the invalid bit, flushes the tlb entries for it and then writes back the byte with the invalid bit set. The microcode makes sure that this pte cannot be used for form a new tlb on any cpu while the ipte is in progress. That means a compare-and-swap semantics on ptes won't work together with the ipte optimization. As long as there is the pte lock that protects all software accesses to the pte we are fine. But if any code expects that ptep_exchange does something like an xchg things break. -- blue skies, Martin. Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH "Reality continues to ruin my life." - Calvin. - 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 2.6.12-rc2] PNP: export pnp_bus_type
On Wednesday 27 December 2006 2:30 pm, Arjan van de Ven wrote: > On Wed, 2006-12-27 at 13:47 -0800, David Brownell wrote: > > The PNP framework doesn't export "pnp_bus_type", which is an unfortunate > > exception to the policy followed by pretty much every other bus. I noticed > > this when I had to find a device in order to provide its platform_data. > > can you please merge the export together with the driver? I'll send that stuff along; providing the platform data is actually an update to ACPI glue, not the driver, so the driver won't need to become needlessly coupled to ACPI. (Driver = rtc_cmos, I'll resend it in a few days.) > We already > have way too many unused exports, and the only sane way is to merge the > export with the user. (and yes exports are not free, they take up > 100 to 150 bytes of kernel size for example) Hmm, then maybe it'd be worth updating that patch I just sent so that the only change is to switch #includes for the extern decl ... i.e. to "export" it only to other statically linked kernel code, rather than to modules. I'll do that. My own question about that EXPORT_SYMBOL was whether it instead be an EXPORT_SYMBOL_GPL, but if either one costs bytes ... I'm happy to avoid that cost! - 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: Happy Birthday to Our Fearless Leader
Happy Birthday to the leader of the penguins ;) Since Linus can't necessarily hear us, lets all type in harmony. "For he's a jolly good fellow..." Loye Young wrote: > Be it remembered that on the 28th day of December in the year of our Lord > 1969, there was born in the town of Helsinki, Finland, Linus Benedict > Torvalds. > > Long live the king. > > - > 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: The Input Layer and the Serial Port
"Nothing is hard if you already know how." -- Unknown
"Nadie nace enseñó." -- Mexican proverb. ("Nobody is born taught.")
>All you need to do is write the device interface.
I wish that I knew how to program in C, and that I knew how to recompile the
kernel. But C is Greek to me. Besides, it is a language so holy that it cannot
be spoken.
Surely this has been done before. Perhaps you have already, because you say:
>Take for example the AT keyboard which is
>one of the most common keyboards in the world. I have seen and
>used it attached to a PC via parport, serial port and the standard
>PS/2 port. So to handle cases like this the input layer created a
>serio interface.
If plain ASCII text is coming in the serial port, would the kernel know or even
care what device was generating the characters? Could I just use whatever
interface you did?
How does the input subsystem and udev know how to populate /dev/input? Does
evdev automagically pick up everything in /dev/input?
>I recommend you take a look at sermouse.c
>in the drivers/input.mouse directory
>for a guide.
I looked, but the source code I have (2.6.17, Debian) doesn't have anything
called sermouse.c in the /drivers/input directory.
I'm still Clue Minus One on how to make my scanner work.
[Warning Will Robinson! Danger! Rant mode ON!]
"Cobbler, you have no shoes."
Perhaps I am misunderstanding something, but why does the world need a unique,
handwritten, geek-speak device driver for every gadget in the universe? I have
to think that writing the device drivers and interfaces for most input devices
is a huge exercise in reinventing the wheel all over again. (This is admittedly
the luxury of one such as myself, who has never written one.) And, even
assuming there are such instances, why should the kernel developers be the only
ones writing them.
(The following was written by someone who doesn't know what he is talking
about, to those who do. It is likely that the latter will think the former is
ignorant in whole or in part, because such are the facts. Suspension of
critical thinking at the micro level is consequently necessary.)
When I read (though not understood) Linux Device Drivers, 3d edition, the
question that kept coming to my mind is "Why can't this be automated? Can the
Three Wise Men most of LDD3 in C instead of English?"
The kernel has a discrete, documented set of inputs. Well, they will be
documented when OSDL hires that technical writer. Or maybe sometime else. In
any event, there are specific, well-known actions that the kernel can be told
to do. The King Penguin and his Court know ex ante the complete list of such
actions. Code has or can be written for each possible command to the kernel.
Let the count of such kernel commands be equal to K.
Likewise, there are a limited number of buses over which the information to and
fro all the various devices can be sent. Again, we know ex ante what they are
and should be able to code the translations between what comes in from the bus
and what commands get issued. Let the count of such buses be equal to B.
The count of all possible input commands for all buses (let such count be equal
to I) is K times B. (K x B = I) "I" may be a large number, but not an
insurmountable one.
In particular, input devices such as character generators and pointers have a
discrete set of outputs. Engineers of the devices design their widgets with a
target set of outputs in mind. They know that the devices will be attached to
computers and design the devices for a particular bus. They know the
requirements for the bus they are designing for. (Pardon the ending
preposition.) Consequently, it must be possible to anticipate the possible
universe of outputs from most devices on a particular bus and allow a user to
map the device outputs to the appropriate command. In most cases, we know what
the device will send, or most of it anyway, so a default list of commands will
work just fine.
All that is remaining is to configure the idiosyncratic events that some
engineer felt was way-cool and different. A generic program can be written to
listen for what the device sends and map it to one of I commands. There are
"snoop" programs available for most, if not all, buses. It must be possible,
therefore, to automate the entire process in a user-space program. First, the
program would interview the user. It would start off by making an attempt to
discover all devices connected and presenting a list to the user. "Which device
do you want to configure?" The user would have an "Other Device" option to tell
the machine which connection on which bus the device is using. Next, the
program would ask for the type of device being configured (character generator,
pointer, etc.) and for any relevant information not obtainable via PnP
(manufacturer, model, etc.). Now the program knows quite a bit about the device
and can narrow the field of likely choices from I to a subset of K.
Re: Happy Birthday to Our Fearless Leader
I hope it doesn't get me kicked off the list for unnecessary traffic, but Happy Birthday Linus. Thanks for making computing fun again Dave Loye Young wrote: Be it remembered that on the 28th day of December in the year of our Lord 1969, there was born in the town of Helsinki, Finland, Linus Benedict Torvalds. Long live the king. - 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/ -- David R. Meyer http://www.davidmeyer.org - 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] Remove logically superfluous comparisons from Kconfig files.
On Wed, 27 Dec 2006, Horst H. von Brand wrote: > Robert P. J. Day <[EMAIL PROTECTED]> wrote: > > Remove Kconfig comparisons of the form FUBAR || FUBAR=n, since they > > appear to be superfluous. > > > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > > > --- > > > > based on what i read in kconfig-language.txt, it would *appear* that > > those comparisons are redundant, but i'm willing to be convinced > > otherwise. (unless the developer specifically wanted the case of > > "!=m", which i'm fairly sure is not the same thing, yes?) > > Would be clearer written that way if so. > > > drivers/char/drm/Kconfig |2 +- > > fs/dlm/Kconfig |1 - > > net/ipv4/netfilter/Kconfig |1 - > > net/sctp/Kconfig |1 - > > 4 files changed, 1 insertion(+), 4 deletions(-) > > > > diff --git a/drivers/char/drm/Kconfig b/drivers/char/drm/Kconfig > > index ef833a1..d681e68 100644 > > --- a/drivers/char/drm/Kconfig > > +++ b/drivers/char/drm/Kconfig > > @@ -6,7 +6,7 @@ > > # > > config DRM > > tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI > > support)" > > - depends on (AGP || AGP=n) && PCI > > + depends on && PCI >^^ ??? the stuff above is *very* old and also incorrect -- the only outstanding patch i have in the queue should be to remove the final 3 "depends" directives in Kconfig files, nothing more. rday - 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/
Happy Birthday to Our Fearless Leader
Be it remembered that on the 28th day of December in the year of our Lord 1969, there was born in the town of Helsinki, Finland, Linus Benedict Torvalds. Long live the king. - 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 1/4] Add
Zack Weinberg wrote:
This patch introduces with symbolic constants for the
various sys_syslog() opcodes, and changes all in-kernel references to
those opcodes to use the constants. The header is added to the set of
user/kernel interface headers.
[...]
-/*
- * Commands to do_syslog:
+/**
+ * do_syslog - operate on the log of kernel messages
+ * @type: operation to perform
+ * @buf: user-space buffer to copy data into
+ * @len: number of bytes of space available at @buf
+ *
+ * See include/linux/klog.h for the command numbers passed as @type.
+ * The @buf and @len parameters are used with the above meanings for
+ * @type values %KLOG_READ, %KLOG_READ_HIST and %KLOG_READ_CLEAR_HIST.
+ * @len is reused with a different meaning, and @buf ignored, for
+ * %KLOG_SET_CONSOLE_LVL. Both @buf and @len are ignored for all
+ * other @type values.
*
- * 0 -- Close the log. Currently a NOP.
- * 1 -- Open the log. Currently a NOP.
- * 2 -- Read from the log.
- * 3 -- Read all messages remaining in the ring buffer.
- * 4 -- Read and clear all messages remaining in the ring buffer
- * 5 -- Clear ring buffer.
- * 6 -- Disable printk's to console
- * 7 -- Enable printk's to console
- * 8 -- Set level of messages printed to console
- * 9 -- Return number of unread characters in the log buffer
- * 10 -- Return size of the log buffer
+ * On failure, returns a negative errno code. On success, returns a
+ * nonnegative integer whose meaning depends on @type.
*/
int do_syslog(int type, char __user *buf, int len)
{
@@ -190,11 +192,11 @@
That part looks good to me, and the kernel-doc hunks from
"[patch 3/4] Refactor do_syslog interface"
too, are:
Acked-by: Vincent Legoll <[EMAIL PROTECTED]>
thanks for handling that.
--
Vincent Legoll
-
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/
OpenSolaris under KVM?
Has anybody succeded running OpenSolaris under KVM virtualization? Before I download OS install DVD in vain... Windows XP obviously runs great (http://linux.inet.hr/finally-user-friendly-virtualization-for-linux.html, but I would like to play with other Unix a little bit, without having to dual boot. Thanks for any info. - 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 2.6.12-rc2] PNP: export pnp_bus_type
On Wed, 2006-12-27 at 13:47 -0800, David Brownell wrote: > The PNP framework doesn't export "pnp_bus_type", which is an unfortunate > exception to the policy followed by pretty much every other bus. I noticed > this when I had to find a device in order to provide its platform_data. can you please merge the export together with the driver? We already have way too many unused exports, and the only sane way is to merge the export with the user. (and yes exports are not free, they take up 100 to 150 bytes of kernel size for example) - 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: util-linux: orphan
Karel Zak wrote: For example for my laptop is it true that "life is too short to enable SELinux", but it's probably not true for servers in the bank where I have money. (I hope so:-) You'd be surprised how many banks run Windows, and not even the most recent versions. -hpa - 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 2.6.20-rc1 00/10] TURBOchannel update to the driver model
> And last but not least, thanks to James Simmons for beginning this work a > while ago as his code was great to start with. Wow!! I thought the work was dropped along time ago. Thanks for bring it back. - 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: util-linux: orphan
On Wed, Dec 27, 2006 at 03:42:13PM -0500, Theodore Tso wrote: > On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote: > > Frankly, it wasn't always easy to use SeLinux in previous FC > > releases, but there is huge progress and I think it's much better in > > FC6. > > I've never tried SELinux, but at one point there were all sorts of > horror stories that if you enabled SELinux, the moment you installed > any 3rd party software packages, whether it's Oracle or Websphere or > some other commercial application program, the application would break > because of all sorts of SELinux policy violations, and that it > required an SELinux wizard to configure SELinux policy to enable a 3rd > party application to actually work correctly. Given that I tried > enabling SELinux, witnessed things break spectacularly and with no > hints about how to fix things, I've always had the attitude of "life > is too short to enable SELinux", and so my limited experience is The level of security is always your choice. The real security is pretty expensive and you have to invest your time to make your system really safe. IMHO people who provides simple and cheap solutions are liars or marketing-agents or both. For example for my laptop is it true that "life is too short to enable SELinux", but it's probably not true for servers in the bank where I have money. (I hope so:-) > consistent with all of the horror stories that I've heard. > > It sounds like SELinux has gotten better, according to your I'm really occasional selinux enduser only. So don't ask me for details. > description. Will handle arbitrary 3rd party software without running > wild, or is it still the case that the moment you want anything other > than software that was shipped with the distribution, it's "abandon > all hope, all ye who enter here"? There is possible customization of the existing selinux policy. You can generate a new loadable policy module from system audit logs (see audit2allow util). In the other words -- your system in the permissive mode is monitoring your 3rd party software and from the logs you can generate new selinux rules. And when you switch system to the enforcing mode the application should be run as expected with your new rules. Karel -- Karel Zak <[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 -rt] update kmap_atomic on !HIGHMEM
On Wed, 2006-12-27 at 22:25 +0100, Ingo Molnar wrote:
>
> +void pagefault_disable(void)
> +{
> + current->pagefault_disabled++;
> + /*
> +* make sure to have issued the store before a pagefault
> +* can hit.
> +*/
> + barrier();
> +}
> +
> +void pagefault_enable(void)
> +{
> + /*
> +* make sure to issue those last loads/stores before enabling
> +* the pagefault handler again.
> +*/
> + barrier();
> + current->pagefault_disabled--;
> +}
> +
I'll test it, but clearly I'm not going to get the same scheduling while
atomic using this change.. So may as well just put it in -rt and see if
something crashes ..
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/
[patch 2.6.12-rc2] PNP: export pnp_bus_type
The PNP framework doesn't export "pnp_bus_type", which is an unfortunate
exception to the policy followed by pretty much every other bus. I noticed
this when I had to find a device in order to provide its platform_data.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/pnp/base.h
===
--- g26.orig/drivers/pnp/base.h 2006-12-18 05:45:29.0 -0800
+++ g26/drivers/pnp/base.h 2006-12-18 05:45:41.0 -0800
@@ -1,4 +1,3 @@
-extern struct bus_type pnp_bus_type;
extern spinlock_t pnp_lock;
void *pnp_alloc(long size);
int pnp_interface_attach_device(struct pnp_dev *dev);
Index: g26/drivers/pnp/driver.c
===
--- g26.orig/drivers/pnp/driver.c 2006-07-03 10:45:14.0 -0700
+++ g26/drivers/pnp/driver.c2006-12-18 05:41:56.0 -0800
@@ -199,6 +199,7 @@ struct bus_type pnp_bus_type = {
.suspend = pnp_bus_suspend,
.resume = pnp_bus_resume,
};
+EXPORT_SYMBOL(pnp_bus_type);
int pnp_register_driver(struct pnp_driver *drv)
{
Index: g26/include/linux/pnp.h
===
--- g26.orig/include/linux/pnp.h2006-12-18 05:45:29.0 -0800
+++ g26/include/linux/pnp.h 2006-12-27 13:22:58.0 -0800
@@ -352,6 +352,8 @@ struct pnp_protocol {
(dev) = protocol_to_pnp_dev((dev)->protocol_list.next))
+extern struct bus_type pnp_bus_type;
+
#if defined(CONFIG_PNP)
/* device management */
-
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 -rt] update kmap_atomic on !HIGHMEM
* Daniel Walker <[EMAIL PROTECTED]> wrote: > On Wed, 2006-12-27 at 22:31 +0100, Ingo Molnar wrote: > > plus on i386 the fix below is needed as well. > > > > We do it on most other arches .. PowerPC , and I think ARM too. I dont think they currently work with PREEMPT_RT and HIGHMEM enabled, but if/once they do they'll need a similar fix. 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: [PATCH -rt] update kmap_atomic on !HIGHMEM
On Wed, 2006-12-27 at 22:25 +0100, Ingo Molnar wrote: > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > I got some scheduling while atomic on x86-64 , and since x86-64 > > doesn't seem to have HIGHMEM there's no workaround for kmap_atomic() . > > > > This patch adds the same as i386 HIGHMEM for !HIGHMEM. > > the problem is that this does not disable pagefaulting while > kmap-atomic. Could you try the patch below, does it solve the assert? > That goes for the other CONFIG_HIGHMEM changes also? I mean if we can't do it here we shouldn't do it else where.. (note, I just used testscripts/ltpstress.sh from LTP to reproduce this.) 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: [PATCH -rt] update kmap_atomic on !HIGHMEM
On Wed, 2006-12-27 at 22:31 +0100, Ingo Molnar wrote: > plus on i386 the fix below is needed as well. > We do it on most other arches .. PowerPC , and I think ARM too. 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: [PATCH -rt] update kmap_atomic on !HIGHMEM
plus on i386 the fix below is needed as well.
Ingo
---
include/asm-i386/highmem.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux/include/asm-i386/highmem.h
===
--- linux.orig/include/asm-i386/highmem.h
+++ linux/include/asm-i386/highmem.h
@@ -81,9 +81,9 @@ struct page *__kmap_atomic_to_page(void
* on PREEMPT_RT kmap_atomic() is a wrapper that uses kmap():
*/
#ifdef CONFIG_PREEMPT_RT
-# define kmap_atomic(page, type) kmap(page)
-# define kmap_atomic_pfn(pfn, type) kmap(pfn_to_page(pfn))
-# define kunmap_atomic(kvaddr, type) kunmap_virt(kvaddr)
+# define kmap_atomic(page, type) ({ pagefault_disable(); kmap(page); })
+# define kmap_atomic_pfn(pfn, type) kmap_atomic(pfn_to_page(pfn), type)
+# define kunmap_atomic(kvaddr, type) do { pagefault_enable();
kunmap_virt(kvaddr); } while (0)
# define kmap_atomic_to_page(kvaddr) kmap_to_page(kvaddr)
#else
# define kmap_atomic(page, type) __kmap_atomic(page, type)
-
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/
[BUG 2.6.20-rc2] atkbd.c: Spurious ACK
Good day. The bug where the kernel repetitively emits "atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly" (sic) on a panic, thereby scrolling away the information that would help in seeing what exactly the problem was (ie, "Unable to mount root fs" or something) is still present in 2.6.20-rc2. Rene. - 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 -rt] update kmap_atomic on !HIGHMEM
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> I got some scheduling while atomic on x86-64 , and since x86-64
> doesn't seem to have HIGHMEM there's no workaround for kmap_atomic() .
>
> This patch adds the same as i386 HIGHMEM for !HIGHMEM.
the problem is that this does not disable pagefaulting while
kmap-atomic. Could you try the patch below, does it solve the assert?
Ingo
->
Subject: [patch] clean up the page fault disabling logic
From: Ingo Molnar <[EMAIL PROTECTED]>
decouple the pagefault-disabled logic from the preempt count.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/arm/mm/fault.c |2 +-
arch/i386/mm/fault.c|2 +-
arch/mips/mm/fault.c|2 +-
arch/powerpc/mm/fault.c |2 +-
arch/x86_64/mm/fault.c |2 +-
include/linux/sched.h |1 +
include/linux/uaccess.h | 33 +++--
kernel/fork.c |1 +
mm/memory.c | 20
9 files changed, 30 insertions(+), 35 deletions(-)
Index: linux/arch/arm/mm/fault.c
===
--- linux.orig/arch/arm/mm/fault.c
+++ linux/arch/arm/mm/fault.c
@@ -230,7 +230,7 @@ do_page_fault(unsigned long addr, unsign
* If we're in an interrupt or have no user
* context, we must not take the fault..
*/
- if (in_atomic() || !mm)
+ if (in_atomic() || !mm || current->pagefault_disabled)
goto no_context;
/*
Index: linux/arch/i386/mm/fault.c
===
--- linux.orig/arch/i386/mm/fault.c
+++ linux/arch/i386/mm/fault.c
@@ -382,7 +382,7 @@ fastcall notrace void __kprobes do_page_
* If we're in an interrupt, have no user context or are running in an
* atomic region then we must not take the fault..
*/
- if (in_atomic() || !mm)
+ if (in_atomic() || !mm || current->pagefault_disabled)
goto bad_area_nosemaphore;
/* When running in the kernel we expect faults to occur only to
Index: linux/arch/mips/mm/fault.c
===
--- linux.orig/arch/mips/mm/fault.c
+++ linux/arch/mips/mm/fault.c
@@ -69,7 +69,7 @@ asmlinkage void do_page_fault(struct pt_
* If we're in an interrupt or have no user
* context, we must not take the fault..
*/
- if (in_atomic() || !mm)
+ if (in_atomic() || !mm || current->pagefault_disabled)
goto bad_area_nosemaphore;
down_read(>mmap_sem);
Index: linux/arch/powerpc/mm/fault.c
===
--- linux.orig/arch/powerpc/mm/fault.c
+++ linux/arch/powerpc/mm/fault.c
@@ -196,7 +196,7 @@ int __kprobes notrace do_page_fault(stru
}
#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
- if (in_atomic() || mm == NULL) {
+ if (in_atomic() || mm == NULL || current->pagefault_disabled) {
if (!user_mode(regs))
return SIGSEGV;
/* in_atomic() in user mode is really bad,
Index: linux/arch/x86_64/mm/fault.c
===
--- linux.orig/arch/x86_64/mm/fault.c
+++ linux/arch/x86_64/mm/fault.c
@@ -405,7 +405,7 @@ asmlinkage void __kprobes do_page_fault(
* If we're in an interrupt or have no user
* context, we must not take the fault..
*/
- if (unlikely(in_atomic() || !mm))
+ if (unlikely(in_atomic() || !mm || current->pagefault_disabled))
goto bad_area_nosemaphore;
again:
Index: linux/include/linux/sched.h
===
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -1147,6 +1147,7 @@ struct task_struct {
/* mutex deadlock detection */
struct mutex_waiter *blocked_on;
#endif
+ int pagefault_disabled;
#ifdef CONFIG_TRACE_IRQFLAGS
unsigned int irq_events;
int hardirqs_enabled;
Index: linux/include/linux/uaccess.h
===
--- linux.orig/include/linux/uaccess.h
+++ linux/include/linux/uaccess.h
@@ -6,37 +6,10 @@
/*
* These routines enable/disable the pagefault handler in that
- * it will not take any locks and go straight to the fixup table.
- *
- * They have great resemblance to the preempt_disable/enable calls
- * and in fact they are identical; this is because currently there is
- * no other way to make the pagefault handlers do this. So we do
- * disable preemption but we don't necessarily care about that.
+ * it will not take any MM locks and go straight to the fixup table.
*/
-static inline void pagefault_disable(void)
-{
- inc_preempt_count();
- /*
-* make sure to have issued the store before a pagefault
-* can hit.
-*/
-
Re: Feature request: exec self for NOMMU.
On Wednesday 27 December 2006 1:49 pm, Ray Lee wrote: > >>> I haven't got a man page for fexecve. Does libc have it? > >> It's implemented inside glibc, and uses /proc to execve() the file that > >> the fd points to. > > Oh, hmm. Then I think it won't work, will it? I'd assumed fexecve was > implemented in kernel. It sort of is. Through the /proc filesystem, the kernel provides a path through which to open any arbitrary file descriptor, thus providing the "path" argument that the exec syscall requires. > > Cute, and I can do that. Assuming /proc is mounted in the chroot > > environment... > > Maybe I'm just confused -- wouldn't be the first time -- but if it's > implemented inside userspace, then once you chroot() you won't be able > to execute the path you find via /proc, will you? You need /proc mounted in the new chroot for it to work. It's not a complete solution, but an incremental improvement over the previous hack. Of course today what you can do is copy busybox into the top directory of the new chroot directory, execute that via the standard chroot command, run "/busybox mount -n -t procfs /proc /proc", and then let the current /proc/self/exe logic handle things from there. (Or configure busybox to use /busybox instead of /proc/self/exe as the re-exec-self path.) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery - 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: The Input Layer and the Serial Port
> To the King of Penguins and the Wise Architects of the Kernel: > > Greetings and Smooth Compiling to All, > > I, a humble pilgrim in the Land of Tux, have spent over a year > seeking a simple answer to what seems to me a simple question: > How do I expose my RS232 barcode scanner to the input layer so > that the scanned information shows up in applications? Basically, > I need the scanner to act like another keyboard. Scan a code, > see the numbers. By the magic of serio. Take for example the AT keyboard which is one of the most common keyboards in the world. I have seen and used it attached to a PC via parport, serial port and the standard PS/2 port. So to handle cases like this the input layer created a serio interface. This way it does matter what bus the keyboard is attached to the same code can be used to drive the keyboard. The good news for you is that a serial port serio exist already. All you need to do is write the device interface. I recommend you take a look at sermouse.c in the drivers/input.mouse directory for a guide. P.S In fact I have been playing with serio for a way to work with LCD panels that can be wired via parport, gpio etc. Its just so flexiable :-) - 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 -rt] update kmap_atomic on !HIGHMEM
On Wed, 2006-12-27 at 21:54 +0100, Ingo Molnar wrote: > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > I got some scheduling while atomic on x86-64 , [...] > > please post those messages too. > > Ingo Ok .. This is from 2.6.20-rc2-rt0 tho . BUG: scheduling while atomic: kswapd0/0x0001/244, CPU#1 Call Trace: [] __sched_text_start+0xb0/0xb9f [] task_rq_lock+0x4c/0x90 [] rt_mutex_setprio+0xb3/0xd0 [] add_preempt_count+0x14/0xf0 [] task_blocks_on_rt_mutex+0x163/0x1d0 [] schedule+0xe5/0x110 [] rt_spin_lock_slowlock+0x102/0x1b0 [] swap_duplicate+0x51/0x100 [] move_to_swap_cache+0x32/0x70 [] shmem_writepage+0xaa/0x1a0 [] shrink_inactive_list+0x430/0x950 [] shrink_zone+0xe4/0x110 [] kswapd+0x379/0x510 [] autoremove_wake_function+0x0/0x30 [] kswapd+0x0/0x510 [] kthread+0xd9/0x120 [] schedule_tail+0xdc/0x130 [] keventd_create_kthread+0x0/0x90 [] child_rip+0xa/0x12 [] keventd_create_kthread+0x0/0x90 [] kthread+0x0/0x120 [] child_rip+0x0/0x12 --- | preempt count: 0001 ] | 1-level deep critical section nesting: .. [] shmem_swp_entry+0x31/0x1a0 .[<>] .. ( <= 0x0) - 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: Feature request: exec self for NOMMU.
On Wednesday 27 December 2006 1:35 pm, Denis Vlasenko wrote: > This solves chroot problem. How to find path-to-yourself reliably > (for one, without using /proc/self/exe) is not obvious to me. Been there, done that. Both my toybox and Firmware Linux projects do this. In FWL it's line 115 of this file: http://landley.net/hg/firmware?f=937346748ff4;file=sources/toys/gcc-uClibc.c It's essentially the logic of the command line "which" utility applied to argv[0]. If argv[0] has a relative or absolute path, then it's vs cwd (this has to happen when you first run the program, before you cd). If argv[0] has no path then look at $PATH. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery - 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 -rt] update kmap_atomic on !HIGHMEM
* Daniel Walker <[EMAIL PROTECTED]> wrote: > I got some scheduling while atomic on x86-64 , [...] please post those messages too. 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: [take24 0/6] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: > Why do we want to inject _ready_ event, when it is possible to mark > event as ready and wakeup thread parked in syscall? Going back to this old one: How do you want to mark an event ready if you don't want to introduce yet another layer of data structures? The event notification happens through entries in the ring buffer. Userlevel code should never add anything to the ring buffer directly, this would mean huge synchronization problems. Yes, one could add additional data structures accompanying the ring buffer which can specify userlevel-generated events. But this is a) clumsy and b) a pain to use when the same ring buffer is used in multiple threads (you'd have to have another shared memory segment). It's much cleaner if the userlevel code can get the kernel to inject a userlevel-generated event. This is the equivalent of userlevel code generating a signal with kill(). -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
Please attach patches as inline text, not as a binary file, so that we can all read it. Thomas Maier wrote: Hello, this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: - update documentation - use clear_bdi_congested/set_bdi_congested functions directly instead of old wrappers - removed DECLARE_BUF_AS_STRING macro Signed-off-by: Thomas Maier <[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: util-linux: orphan
On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote: > Frankly, it wasn't always easy to use SeLinux in previous FC > releases, but there is huge progress and I think it's much better in > FC6. I've never tried SELinux, but at one point there were all sorts of horror stories that if you enabled SELinux, the moment you installed any 3rd party software packages, whether it's Oracle or Websphere or some other commercial application program, the application would break because of all sorts of SELinux policy violations, and that it required an SELinux wizard to configure SELinux policy to enable a 3rd party application to actually work correctly. Given that I tried enabling SELinux, witnessed things break spectacularly and with no hints about how to fix things, I've always had the attitude of "life is too short to enable SELinux", and so my limited experience is consistent with all of the horror stories that I've heard. It sounds like SELinux has gotten better, according to your description. Will handle arbitrary 3rd party software without running wild, or is it still the case that the moment you want anything other than software that was shipped with the distribution, it's "abandon all hope, all ye who enter here"? - Ted - 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.19 (current from git) on SPARC64: Can't mount /
Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Wed, Dec 13, 2006 at 03:56:46PM -0300, Horst H. von Brand wrote: > > I've been running kernel du jour straight from git on my SPARC Ultra 1 for > > some time now on Aurora Corona (Fedora relative, development branch). For a > > few days now 2.6.19 panics on boot, it can't mount /. 2.6.19 worked fine, > > as does 2.6.19.1 (Aurora changed gcc, mkinitrd, ... in between, so I had to > > rebuild a kernel to check if the problem lay elsewhere). Unpacking the > > initrds for 2.6.19 and 2.6.19.1 shows the same (nash script) /init and the > > same modules in both (ext3 + jbd, scsi_mod, sd_mod, esp, others). > > I'm stumped. Any clue? > Is this issue still present in the latest -git? Sorry, got sidetracked by other stuff. Still no boot with 2.9.20-rc1 and -rc2, and none of the kernels I tried in between. initrd is sane (the only differences between the one built for working 2.6.19.1 and broken 2.6.20-rc2 are among the modules themselves). What I did was: cd /tmp mkdir ird-$version cd ird-$version zcat /boot/initrd-$version.img | cpio -i and then "diff -Nur ird-$1 ird-$2". Now to teach diff(1) to compare devices reasonably... Tried latest from Fedora rawhide (mkinitrd-6.0.6-1), no boot. initrd is huge, so I went back to mkinitrd-5.1.19-1. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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] Add MMC Password Protection (lock/unlock) support V8: mmc_sysfs.diff
[EMAIL PROTECTED] wrote: > Did you see this patch at V9 series? This bug is fixed. > I also fixed this code according the latest Russel's comments and will send > again at V9, just this patch. > > The V9 you sent me on the 15th was before Russell pointed out the dangling lock, and doesn't contain a fix for it. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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: How to detect multi-core and/or HT-enabled CPUs in 2.4.x and 2.6.x kernels
On Wed, Dec 27, 2006 at 09:52:02AM -0800, Martin Knoblauch wrote:
> For sizing purposes, doing benchmarks is the only way. For the purpose
> of Ganglia the sockets/cores/threads info is purely for inventory. And
> we are likely going to add the new information to our metrics.
>
> But - we still need to find a way to extract the infor :-)
Only the 2.4 x86_64 kernels are exporting limited info("physical id",
"siblings") through /proc/cpuinfo.
Some of the distos based on 2.4 kernels have the complete topology
(physical id, core id, cpu cores, siblings) exported through /proc/cpuinfo.
thanks,
suresh
-
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/
The Input Layer and the Serial Port
To the King of Penguins and the Wise Architects of the Kernel: Greetings and Smooth Compiling to All, I, a humble pilgrim in the Land of Tux, have spent over a year seeking a simple answer to what seems to me a simple question: How do I expose my RS232 barcode scanner to the input layer so that the scanned information shows up in applications? Basically, I need the scanner to act like another keyboard. Scan a code, see the numbers. This can't be difficult. I must be overlooking something. Every cash register in America has a barcode scanner. Surely SOME of them must run Linux or Unix. Someone out there knows something I don't. The lowly serial port is still very much a fact of life in industry. I believe I recall reading the judgment of The King of Penguins himself that the kernel must continue support for serial ports generally, and barcode scanners in particular, but I can't find the edict now so maybe my memory is playing tricks on me. Reading ASCII characters coming in the serial port should be as easy as selling donuts to cops. I have learned, however, that when it comes to the Mysteries of the Kernel, simple answers are sometimes hard to find. +I have studied the writings of the Weekly Pundit, Little Redstone, and the One-With-Two-Last-Names. http://lwn.net/Kernel/LDD3. +I have consulted the Oracles of Mepis. http://www.mepis.org/node/9104. +I have wandered in the Valley of X. http://lists.freedesktop.org/archives/xorg/2006-December/020579.html. +I have read under the Scribe of the Text Terminal How-To. http://www.linux.com/howtos/Text-Terminal-HOWTO.shtml +I have been to the Source. /usr/src/linux-source-2.6.17/drivers/input/*. +I have searched the chronicles of the children of Debra and Ian. http://lists.debian.org/search.html Alas and alack, knowledge of the secret still eludes me, and I am not alone. What follows is a partial list of what I have found. Apparently, the input layer has been cussed and discussed for several years now. See, e.g., http://linuxconsole.sourceforge.net/input/input.html (2000), http://kerneltrap.org/node/2947 (2004), http://kerneltrap.org/node/2199 (2004), http://www.frogmouth.net/hid-doco/linux-hid.html (??). I have found no final announcement of "The Way Things Are" or "The Way Things Ought To Be," however. The USB bus admittedly provides a much more robust technical platform upon which to build new devices, and it is well documented and integrated into the input layer. http://www.usb.org/developers/hidpage/. Vojtech Pavlik has written a plethora of input device drivers for the serial port, and much of the input layer itself. His work on the joystick included inputattach. Although the man page says it is to "attach a serial line to a joystick device," inputattach also configures a variety of serial character devices. Unfortunately, inputattach has options for specific brands of devices (re-mapping various keys and functions), but doesn't have a generic character input device option that I can tell. When I read the source code, I see that generic keycodes are in the code, but each option changes the generic list in some way. (Is it mere coincidence that VP is from a land that limits the use of vowels? Does the path to understanding input run through Prague? Is Alan Cox really the alter ego of the evil leader of the underground gnomes? Mysteries too great for me.) "Do you pine for the days when men were men and wrote their own device drivers?" I wish that I knew how to program in C, and that I knew how to recompile the kernel. If I did, I could probably write the "trivial keyboard driver" that has been suggested. http://lists.freedesktop.org/archives/xorg/2006-December/020596.html. I'd probably even make a patch to inputattach or some other userspace program to bring barcode scanners to Linux. I might even would write a generic driver specifically for barcodes. But C is Greek to me. Besides, it is a language so holy that it cannot be spoken. I may be quacking up the wrong tree. (Do penguins quack? Squawk? Yet another mystery . . .) The kernel's serial driver seems to work just fine. If I issue from the command line "cat /dev/ttyS0" and then scan something, I get my numbers. (I did have to wander around in the dark for many months until I found that stty must throttle the port speed down to 9600.) However, seeing the number in the console doesn't help me much. I need the information in applications. If the input layer recognized the data coming in through the serial port as data from an input device (or if I could somehow tell it to do so), and if it showed up as an event under /dev/input/, I could use evdev to send the information through the X server as an InputDevice. But I don't know how to tell evdev what to do, and I can't find documentation that tells me how. There is much written about the big fracas over the CueCat scanner, which was a serial barcode scanner, but the related drivers around are
Re: idle RAID1 cpu usage
On Wednesday 27 December 2006 18:09, Paul Slootman wrote: [snip] > My question is: why is CPU being used by the RAID1 threads, even for > those devices that are otherwise unused? What are they doing? > I even started distributed-net to check that it wasn't just idle CPU > cycles that were being used :-) > > Note: it did seem that the activity was a bit more during the first > day after booting; in fact, the mdX_raid1 threads together had used > about one hour's worth of CPU in the first 24 hours, i.e. 4% CPU > (according to ps and top). Sounds like a bug to me. My box is x86_64, but it's been up for 2 days and one unmounted md_raid5 has used 0 minutes, 0 seconds of CPU, which is what I'd expect. Maybe it's some sort of accounting problem on SPARC? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: idle RAID1 cpu usage
Jan Engelhardt <[EMAIL PROTECTED]> wrote: >On Dec 27 2006 19:09, Paul Slootman wrote: >> >>This works fine, but I noticed that quite some time was being used by >>the mdX_raid1 threads; even on a partition that's not even being used at >>this time... (it was an empty mounted filesystem, but I umounted it to >>be sure the filesystem code wasn't causing some IO). >> >>My question is: why is CPU being used by the RAID1 threads, even for >>those devices that are otherwise unused? What are they doing? > >First-time synchronization (if applies), otherwise I suspect some >housekeeping (bitmap perhaps?). No, I had rebooted after the initial synchronization was complete. >Otherwise it seems like a question who does what. On a raid5 array (i.e. >cpu-heavy), both smbd and mdx_raid5 accumulate time for, of course, xor >calculation. On those devices that are actually in use, I'd understand CPU being used; but where the device is not even mounted or used for swap or whatever, I find that amount of CPU usage very high for just checking the bitmap... I may take the idle device apart and reassemble without a bitmap to see whether that makes any difference. Paul Slootman - 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 -rt] update kmap_atomic on !HIGHMEM
I got some scheduling while atomic on x86-64 , and since x86-64 doesn't seem
to have HIGHMEM there's no workaround for kmap_atomic() .
This patch adds the same as i386 HIGHMEM for !HIGHMEM.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/highmem.h | 14 +-
1 files changed, 13 insertions(+), 1 deletion(-)
Index: linux-2.6.19/include/linux/highmem.h
===
--- linux-2.6.19.orig/include/linux/highmem.h
+++ linux-2.6.19/include/linux/highmem.h
@@ -42,13 +42,25 @@ static inline void *kmap(struct page *pa
#define kunmap(page) do { (void) (page); } while (0)
+#ifdef CONFIG_PREEMPT_RT
+/*
+ * kmap and kmunmap are above, and they don't really do anything
+ * interesting.
+ */
+# define kmap_atomic(page, idx)kmap(page)
+# define kmap_atomic_pfn(pfn, idx) kmap(pfn_to_page(pfn))
+# define kunmap_atomic(kvaddr, idx)kunmap(kvaddr)
+#else
#define kmap_atomic(page, idx) \
({ pagefault_disable(); page_address(page); })
#define kunmap_atomic(addr, idx) do { pagefault_enable(); } while (0)
#define kmap_atomic_pfn(pfn, idx) kmap_atomic(pfn_to_page(pfn), (idx))
-#define kmap_atomic_to_page(ptr) virt_to_page(ptr)
#endif
+#define kmap_atomic_to_page(ptr) virt_to_page(ptr)
+
+#endif /* ARCH_HAS_KMAP */
+
#endif /* CONFIG_HIGHMEM */
/* when CONFIG_HIGHMEM is not set these will be plain clear/copy_page */
--
-
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 tcp stack behavior change
On Dec 27 2006 03:03, Jan Engelhardt wrote: > >I have been noticing that running nmap -sF on oneself does not generate >a reply from the TCP stack on 2.6.18(.5). In other words: [...] Alright same behavior on 2.6.13 and nmap 3.81, so the problem is somewhere on my side having misdocumented something back then. -`J' -- - 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: util-linux: orphan
On Wed, Dec 27, 2006 at 07:39:47PM +0100, Arnd Bergmann wrote:
> On Wednesday 27 December 2006 19:15, Karel Zak wrote:
> >
> > On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> > > On Monday 18 December 2006 08:17, Karel Zak wrote:
> > > > - remove FS/device detection code
> > > > (libblkid from e2fsprogs or libvolumeid is replacement)
> > >
> > > I saw that the current Fedora already dynamically links /bin/mount
> > > against /usr/lib/libblkid.so.
> >
> > Sorry, but it's nonsense.
> >
> > $ grep -r %{_root_libdir}/libblkid.so *
> >
> > devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
>
> Right, please accept my apologies for spreading confusion about this.
No problem ;-)
> I currently don't have access to the machine that broke, so I could
> not check the exact problem, and must have misremembered the bug.
>
> > > This obviously does not work if /usr is a separate partition that
> > > needs to be mounted with /bin/mount.
> >
> > Yes, I have /usr on a separate partition for many years :-)
> >
> > > I'd suggest that you make sure that mount always gets statically linked
> > > against libblkid to avoid these problems.
> >
> > It's dynamically linked in many distributions without a problem.
>
> The problem that I saw was because of selinux going wild. Statically linking
Yes, I remember the bug (or bugs). Fixed now.
> would have avoided the problem for me, but I guess this is just one
> more reason for me to disable selinux and be done with it.
Frankly, it wasn't always easy to use SeLinux in previous FC
releases, but there is huge progress and I think it's much better in
FC6.
Karel
--
Karel Zak <[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: Feature request: exec self for NOMMU.
Rob Landley wrote: > On Wednesday 27 December 2006 1:08 am, Vadim Lobanov wrote: >> On Wed, 2006-12-27 at 00:51 -0500, Rob Landley wrote: >>> On Wednesday 27 December 2006 12:13 am, Ray Lee wrote: How about openning an fd to yourself at the beginning of execution, then calling fexecve later? >>> I haven't got a man page for fexecve. Does libc have it? >> It's implemented inside glibc, and uses /proc to execve() the file that >> the fd points to. Oh, hmm. Then I think it won't work, will it? I'd assumed fexecve was implemented in kernel. > Cute, and I can do that. Assuming /proc is mounted in the chroot > environment... Maybe I'm just confused -- wouldn't be the first time -- but if it's implemented inside userspace, then once you chroot() you won't be able to execute the path you find via /proc, will you? - 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: util-linux: orphan
On Wednesday 27 December 2006 19:15, Karel Zak wrote:
>
> On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> > On Monday 18 December 2006 08:17, Karel Zak wrote:
> > > - remove FS/device detection code
> > > (libblkid from e2fsprogs or libvolumeid is replacement)
> >
> > I saw that the current Fedora already dynamically links /bin/mount
> > against /usr/lib/libblkid.so.
>
> Sorry, but it's nonsense.
>
> $ grep -r %{_root_libdir}/libblkid.so *
>
> devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
Right, please accept my apologies for spreading confusion about this.
I currently don't have access to the machine that broke, so I could
not check the exact problem, and must have misremembered the bug.
> > This obviously does not work if /usr is a separate partition that
> > needs to be mounted with /bin/mount.
>
> Yes, I have /usr on a separate partition for many years :-)
>
> > I'd suggest that you make sure that mount always gets statically linked
> > against libblkid to avoid these problems.
>
> It's dynamically linked in many distributions without a problem.
The problem that I saw was because of selinux going wild. Statically linking
would have avoided the problem for me, but I guess this is just one
more reason for me to disable selinux and be done with it.
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 -rt] disconnect warp check from hrtimers
On Wed, 2006-12-27 at 10:04 -0800, Daniel Walker wrote: > On Wed, 2006-12-27 at 09:53 -0800, Daniel Walker wrote: > > > The system hang was resolved by changing the irq threads to all prio > > 50 .. > > Guess I was wrong about this.. The hang was resolved, but I's not sure > how yet .. Looks like it was the irq thread priority _and_ the softirq prio needed to be raised. softirq was at SCHED_FIFO 1 which caused the hang (or that's how it looks). 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: Feature request: exec self for NOMMU.
On Wednesday 27 December 2006 06:13, Ray Lee wrote: > On 12/26/06, Rob Landley <[EMAIL PROTECTED]> wrote: > > I'm trying to make some nommu-friendly busybox-like tools, which means using > > vfork() instead of fork(). This means that after I fork I have to exec in > > the child to unblock the parent, and if I want to exec my current executable > > I have to find out where it lives so I can feed the path to exec(). This is > > nontrivial. > > > > Worse, it's not always possible. If chroot() has happened since the program > > started, there may not _be_ a path to my current executable available from > > this process's current or root directories. > > How about openning an fd to yourself at the beginning of execution, then > calling > fexecve later? This solves chroot problem. How to find path-to-yourself reliably (for one, without using /proc/self/exe) is not obvious to me. -- vda - 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 1/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
Hello, this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: - update documentation - use clear_bdi_congested/set_bdi_congested functions directly instead of old wrappers - removed DECLARE_BUF_AS_STRING macro Signed-off-by: Thomas Maier <[EMAIL PROTECTED]> pktcdvd-2.6.20-rc1-mm1.patch Description: Binary data
Re: idle RAID1 cpu usage
On Dec 27 2006 19:09, Paul Slootman wrote: > >This works fine, but I noticed that quite some time was being used by >the mdX_raid1 threads; even on a partition that's not even being used at >this time... (it was an empty mounted filesystem, but I umounted it to >be sure the filesystem code wasn't causing some IO). > >My question is: why is CPU being used by the RAID1 threads, even for >those devices that are otherwise unused? What are they doing? First-time synchronization (if applies), otherwise I suspect some housekeeping (bitmap perhaps?). Otherwise it seems like a question who does what. On a raid5 array (i.e. cpu-heavy), both smbd and mdx_raid5 accumulate time for, of course, xor calculation. >I even started distributed-net to check that it wasn't just idle CPU >cycles that were being used :-) > >Note: it did seem that the activity was a bit more during the first >day after booting; in fact, the mdX_raid1 threads together had used >about one hour's worth of CPU in the first 24 hours, i.e. 4% CPU >(according to ps and top). -`J' -- - 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: util-linux: orphan
On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> On Monday 18 December 2006 08:17, Karel Zak wrote:
> > - remove FS/device detection code
> > (libblkid from e2fsprogs or libvolumeid is replacement)
>
> I saw that the current Fedora already dynamically links /bin/mount
> against /usr/lib/libblkid.so.
Sorry, but it's nonsense.
$ grep -r %{_root_libdir}/libblkid.so *
devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-1/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-2/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-3/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-4/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-5/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-5/e2fsprogs.spec~:%{_root_libdir}/libblkid.so.*
FC-6/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
RHEL-4/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
RHEL-5/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
(where %{_root_libdir} = /lib)
> This obviously does not work if /usr is a separate partition that
> needs to be mounted with /bin/mount.
Yes, I have /usr on a separate partition for many years :-)
> I'd suggest that you make sure that mount always gets statically linked
> against libblkid to avoid these problems.
It's dynamically linked in many distributions without a problem.
Karel
--
Karel Zak <[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/
idle RAID1 cpu usage
Summary: why are idle RAID1 devices using CPU? I have a Sun Netra X1 (ultrasparc @ 440MHz) running 2.6.19.1. There's one little modification I made to it: instead of 2 SCSI disks, it has one SCSI and one SATA disk (and a PCI SII 3512 card to connect it). Both disks are basically partitioned identically except for the remaining space on the SATA disk (200GB whereas the SCSI is 72GB), that space is a separate partition. I've made a couple of RAID1 devices, using the "pairs" of partitions, with a bitmap for quick resync in case of problems. This works fine, but I noticed that quite some time was being used by the mdX_raid1 threads; even on a partition that's not even being used at this time... (it was an empty mounted filesystem, but I umounted it to be sure the filesystem code wasn't causing some IO). My question is: why is CPU being used by the RAID1 threads, even for those devices that are otherwise unused? What are they doing? I even started distributed-net to check that it wasn't just idle CPU cycles that were being used :-) Note: it did seem that the activity was a bit more during the first day after booting; in fact, the mdX_raid1 threads together had used about one hour's worth of CPU in the first 24 hours, i.e. 4% CPU (according to ps and top). thanks, Paul Slootman # cat /proc/version Linux version 2.6.19.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) #1 Sat Dec 16 15:48:45 CET 2006 # cat /proc/cpuinfo cpu : TI UltraSparc IIi (Sabre) fpu : UltraSparc IIi integrated FPU prom: OBP 3.10.25 2000/01/17 21:26 type: sun4u ncpus probed: 1 ncpus active: 1 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0Bogo: 880.36 Cpu0ClkTck : 1a3a62fe MMU Type: Spitfire # cat /proc/mdstat Personalities : [raid1] md2 : active raid1 sda2[1] sdb2[0] 2931776 blocks [2/2] [UU] bitmap: 1/90 pages [8KB], 8KB chunk md4 : active raid1 sdb4[0] sda4[1] 2931776 blocks [2/2] [UU] bitmap: 0/90 pages [0KB], 8KB chunk md5 : active raid1 sdb5[0] sda5[1] 7815552 blocks [2/2] [UU] bitmap: 2/120 pages [16KB], 16KB chunk md6 : active raid1 sdb6[0] sda6[1] 57906176 blocks [2/2] [UU] bitmap: 0/111 pages [0KB], 128KB chunk unused devices: # cat /proc/cmdline root=/dev/md2 ro # mount /dev/md2 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw,errors=remount-ro) /dev/md5 on /var type ext3 (rw,errors=remount-ro,data=writeback) /dev/sdb7 on /backup type xfs (rw) openprom on /proc/openprom type openpromfs (rw) # cat /boot/config-2.6.19.1 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19.1 # Sat Dec 16 15:18:34 2006 # CONFIG_SPARC=y CONFIG_SPARC64=y CONFIG_64BIT=y CONFIG_MMU=y CONFIG_TIME_INTERPOLATION=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_AUDIT_ARCH=y CONFIG_SPARC64_PAGE_SIZE_8KB=y # CONFIG_SPARC64_PAGE_SIZE_64KB is not set # CONFIG_SPARC64_PAGE_SIZE_512KB is not set # CONFIG_SPARC64_PAGE_SIZE_4MB is not set CONFIG_SECCOMP=y CONFIG_HZ_100=y # CONFIG_HZ_250 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=100 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set # CONFIG_UTS_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_IKCONFIG is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_TASK_XACCT is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set
Re: [PATCH -rt] disconnect warp check from hrtimers
On Wed, 2006-12-27 at 09:53 -0800, Daniel Walker wrote: > The system hang was resolved by changing the irq threads to all prio > 50 .. Guess I was wrong about this.. The hang was resolved, but I's not sure how yet .. 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: How to detect multi-core and/or HT-enabled CPUs in 2.4.x and 2.6.x kernels
>In article <[EMAIL PROTECTED]> you wrote: >> once your program (and many others) have such a check, then the next >> step will be pressure on the kernel code to "fake" the old situation >> when there is a processor where no longer >> holds. It's basically a road to madness :-( > > I agree that for HPC sizing a benchmark with various levels of > parallelity are better. The question is, if the code in question > only is for inventory reasons. In that case I would do something > like x sockets, y cores and z cm threads. > > Bernd For sizing purposes, doing benchmarks is the only way. For the purpose of Ganglia the sockets/cores/threads info is purely for inventory. And we are likely going to add the new information to our metrics. But - we still need to find a way to extract the infor :-) Cheers Martin PS: I have likely killed the CC this time. Sorry. -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.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 -rt] disconnect warp check from hrtimers
On Wed, 2006-12-27 at 18:39 +0100, Ingo Molnar wrote: > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > These calls were getting inconsistent wrt. the xtime_lock. The > > xtime_lock should be held when doing the warp check update, and > > interrupts should be off. > > thanks, applied. Does this solve some warnings that you saw trigger? I saw some unexplained time warping while using the source at this url, http://www.atnf.csiro.au/people/rgooch/benchmarks/linux-scheduler.html it was on an older 2.6.18 based -rt .. The system would print the time warp warning, then hang .. I applied something similar to the patch I just sent, and the time warp warning was gone but the system still hung. New -rt version don't hang, and I don't see the warning .. However, I suspect the time warp warning was a side effect of the hang.. The system hang was resolved by changing the irq threads to all prio 50 .. 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: PATA -- pata_amd on 2.6.19 fails to IDENTIFY my DVD-ROM
Tejun Heo wrote: Rene Herman wrote: I just tried the PATA driver for my AMD756 chip. During boot, it hangs for 3 minutes failing to identify my DVD-ROM (secondary slave) and does not give me access to it after it timed out. Please give a shot at v2.6.20-rc2 and report what the kernel says. This IDENTIFY issue seems already fixed in -rc2. No more pause, and my DVD-ROM works fine again. Unfortunately, another issue seems to have cropped up. On 2.6.20-rc2, hdparm -t /dev/sda gets me ~ 24 M/s while both the old IDE driver and the 2.6.19 PATA driver do ~ 50 M/s 2.6.20-rc2-ata: # hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 72 MB in 3.03 seconds = 23.75 MB/sec 2.6.19-ata: # hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 150 MB in 3.00 seconds = 49.94 MB/sec Here's the ata part of the 2.6.20-rc2 dmesg: === ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi0 : pata_amd ata1.00: ATA-7, max UDMA/133, 240121728 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/66 scsi1 : pata_amd ata2.00: ATAPI, max UDMA/33 ata2.01: ATAPI, max UDMA/66 ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/66 scsi 0:0:0:0: Direct-Access ATA Maxtor 6Y120P0 YAR4 PQ: 0 ANSI: 5 SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 < sda5 sda6 sda7 sda8 > sda2 sda3 sda4 sda2: sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: CD-ROMPLEXTOR CD-R PREMIUM 1.07 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 sr 1:0:0:0: Attached scsi generic sg1 type 5 scsi 1:0:1:0: CD-ROMPLEXTOR DVD-ROM PX-116A 1.00 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr1 sr 1:0:1:0: Attached scsi generic sg2 type 5 === There's some difference with respect to caching versus 2.6.19 it seems? The same bit for 2.6.19: === pata_amd :00:07.1: version 0.2.4 ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi0 : pata_amd ata1.00: ATA-7, max UDMA/133, 240121728 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/66 scsi1 : pata_amd ata2.00: ATAPI, max UDMA/33 ata2.01: qc timeout (cmd 0xa1) ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: failed to recover some devices, retrying in 5 secs ata2: port is slow to respond, please be patient (Status 0xd8) ata2: port failed to respond (30 secs, Status 0xd8) ata2.01: qc timeout (cmd 0xa1) ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: failed to recover some devices, retrying in 5 secs ata2: port is slow to respond, please be patient (Status 0xd8) ata2: port failed to respond (30 secs, Status 0xd8) ata2.01: qc timeout (cmd 0xa1) ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: failed to recover some devices, retrying in 5 secs ata2: port is slow to respond, please be patient (Status 0xd8) ata2: port failed to respond (30 secs, Status 0xd8) ata2.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA Maxtor 6Y120P0 YAR4 PQ: 0 ANSI: 5 SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 < sda5 sda6 sda7 sda8 > sda2 sda3 sda4 sda2: sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: CD-ROMPLEXTOR CD-R PREMIUM 1.07 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 sr 1:0:0:0: Attached scsi generic sg1 type 5 === Rene. - 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] respect srctree/objtree in Documentation/DocBook/Makefile
the KERNELDOC and DOCPROC variables are relative to the $(srctree)/$(objtree) and expect to be run only from there ... attached patch adds proper srctree/objtree prefixes to both variables -mike linux-docbook-trees.patch Description: Binary data
Re: [PATCH -rt] disconnect warp check from hrtimers
* Daniel Walker <[EMAIL PROTECTED]> wrote: > These calls were getting inconsistent wrt. the xtime_lock. The > xtime_lock should be held when doing the warp check update, and > interrupts should be off. thanks, applied. Does this solve some warnings that you saw trigger? 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: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > As I mentioned in a different e-mail, a way to remove the global > > hash table is to create per-cpu hashes. The only problem is that in > > these 8-10% of the cases, freeing would need to look up the other > > hashes. This would become a problem with a high number of CPUs but > > I'm not sure whether it would overtake the performance issues > > introduced by cacheline ping-ponging in the single-hash case. > > i dont think it's worth doing that. So we should either do the current > global lock & hash (bad for scalability), or a pure per-CPU design. > The pure per-CPU design would have to embedd the CPU ID the object is > attached to into the allocated object. If that is not feasible then > only the global hash remains i think. embedding the info shouldnt be /that/ hard in case of the SLAB: if the memleak info is at a negative offset from the allocated pointer. I.e. that if kmalloc() returns 'ptr', the memleak info could be at ptr-sizeof(memleak_info). That way you dont have to know the size of the object beforehand and there's absolutely no need for a global hash of any sort. (it gets a bit more complex for page aligned allocations for the buddy and for vmalloc - but that could be solved by adding one extra pointer into struct page. That is a far more preferable cost than the locking/cache overhead of a global hash.) 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/
[PATCH -rt] disconnect warp check from hrtimers
These calls were getting inconsistent wrt. the xtime_lock. The xtime_lock should
be held when doing the warp check update, and interrupts should be off.
In some places the warp update was getting called twice, once under the
xtime_lock
then again right outside the xtime_lock.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/hrtimer.h |2 +-
kernel/hrtimer.c|2 --
kernel/time/ntp.c |2 ++
kernel/timer.c |1 +
4 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6.19/include/linux/hrtimer.h
===
--- linux-2.6.19.orig/include/linux/hrtimer.h
+++ linux-2.6.19/include/linux/hrtimer.h
@@ -262,7 +262,7 @@ static inline ktime_t hrtimer_cb_get_tim
* is expired in the next softirq when the clock was advanced.
* (we still call the warp-check debugging code)
*/
-static inline void clock_was_set(void) { warp_check_clock_was_changed(); }
+static inline void clock_was_set(void) { }
static inline void hrtimer_clock_notify(void) { }
/*
Index: linux-2.6.19/kernel/hrtimer.c
===
--- linux-2.6.19.orig/kernel/hrtimer.c
+++ linux-2.6.19/kernel/hrtimer.c
@@ -452,8 +452,6 @@ static void retrigger_next_event(void *a
*/
void clock_was_set(void)
{
- warp_check_clock_was_changed();
-
/* Retrigger the CPU local events everywhere */
on_each_cpu(retrigger_next_event, NULL, 0, 1);
}
Index: linux-2.6.19/kernel/time/ntp.c
===
--- linux-2.6.19.orig/kernel/time/ntp.c
+++ linux-2.6.19/kernel/time/ntp.c
@@ -116,6 +116,7 @@ void second_overflow(void)
*/
time_interpolator_update(-NSEC_PER_SEC);
time_state = TIME_OOP;
+ warp_check_clock_was_changed();
clock_was_set();
printk(KERN_NOTICE "Clock: inserting leap second "
"23:59:60 UTC\n");
@@ -131,6 +132,7 @@ void second_overflow(void)
*/
time_interpolator_update(NSEC_PER_SEC);
time_state = TIME_WAIT;
+ warp_check_clock_was_changed();
clock_was_set();
printk(KERN_NOTICE "Clock: deleting leap second "
"23:59:59 UTC\n");
Index: linux-2.6.19/kernel/timer.c
===
--- linux-2.6.19.orig/kernel/timer.c
+++ linux-2.6.19/kernel/timer.c
@@ -1162,6 +1162,7 @@ static int timekeeping_resume(struct sys
clock->cycle_last = clocksource_read(clock);
clock->error = 0;
timekeeping_suspended = 0;
+ warp_check_clock_was_changed();
write_sequnlock_irqrestore(_lock, flags);
hrtimer_notify_resume();
--
-
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] Heads up on a series of AIO patchsets
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > unified event system for Linux we need people to help out with > > straightening out these even provides as Evgeny seems to be > > unwilling/unable to do the work himself and the duplication is > > simply not acceptable. > > yeah. The internal machinery should be as unified as possible - but > different sets of APIs can be offered, to make it easy for people to > extend their existing apps in the most straightforward way. just to expand on this: i dont think this should be an impediment to the POSIX AIO patches. We should get some movement into this and should give the capability to glibc and applications. Kernel-internal unification is something we are pretty good at doing after the fact. (and if any of the APIs dies or gets very uncommon we know in which direction to unify) 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: 2.6.19-rc5 libata PATA ATAPI CDROM SiS 5513 NOT WORKING
Hello Alan, Jeff, Reading a paper on this new libata, I just want to try but failled yet for what said this thread "ATAPI CDROM" ;_(. I first test the latest stable 2.6.19.1 without luck, so I also want to try latest 2.6.20-rc2 unfortunately without more success. Here it was the test of new libata with 2.6.19.1: [snip] ata_piix :00:07.1: version 2.00ac6 ata1: PATA max UDMA/33 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi3 : ata_piix ata1.00: ATA-4, max UDMA/66, 29336832 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.01: ATAPI, max MWDMA1 ata1.00: configured for UDMA/33 ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1.01: limiting speed to PIO3 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1.01: disabled ata1: failed to recover some devices, retrying in 5 secs ata1.00: failed to set xfermode (err_mask=0x40) ata1.00: limiting speed to UDMA/25 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.00: configured for UDMA/25 scsi4 : ata_piix scsi 3:0:0:0: Direct-Access ATA QUANTUM FIREBALL A03. PQ: 0 ANSI: 5 SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 sdc12 sdc13 sdc14 sdc15 > sd 3:0:0:0: Attached scsi disk sdc sd 3:0:0:0: Attached scsi generic sg2 type 0 [snip] And today with 2.6.20-rc2: ata_piix :00:07.1: version 2.00ac7 ata1: PATA max UDMA/33 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi3 : ata_piix ata1.00: ATA-4, max UDMA/66, 29336832 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.01: ATAPI, max MWDMA1 ata1.00: configured for UDMA/33 ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1.01: limiting speed to PIO3 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.01: qc timeout (cmd 0xa1) ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.01: revalidation failed (errno=-5) ata1.01: disabled ata1: failed to recover some devices, retrying in 5 secs ata1.00: failed to set xfermode (err_mask=0x40) ata1.00: limiting speed to UDMA/25 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1.00: configured for UDMA/25 scsi4 : ata_piix scsi 3:0:0:0: Direct-Access ATA QUANTUM FIREBALL A03. PQ: 0 ANSI: 5 SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 29336832 512-byte hdwr sectors (15020 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 sdc12 sdc13 sdc14 sdc15 > sd 3:0:0:0: Attached scsi disk sdc sd 3:0:0:0: Attached scsi generic sg2 type 0 [snip] seems to look like same kind of pb this thread speak about (i.e. hd seems to works fine but not atapi cdrom (r/w)) but not sure? Any idea/advise? Tia, Joel PS0: I check that scsi cdrom was well selected PS1: with traditional ide support I get (with same 2.6.19.1 kernel): [snip] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot :00:07.1 PIIX4: chipset revision 1 PIIX4: not 100%
[PATCH 15/28] V4L/DVB (4983): Force temporal filter to 0 when scaling to prevent ghosting.
From: Hans Verkuil <[EMAIL PROTECTED]>
Change the code to unconditionally turn off the temporal filter when scaling.
If the window is not full screen the filter will introduce a nasty ghosting
effect.
Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
---
drivers/media/video/cx2341x.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/cx2341x.c b/drivers/media/video/cx2341x.c
index 657e0b9..e796afd 100644
--- a/drivers/media/video/cx2341x.c
+++ b/drivers/media/video/cx2341x.c
@@ -742,7 +742,6 @@ int cx2341x_update(void *priv, cx2341x_m
if (old == NULL || old->width != new->width || old->height !=
new->height ||
old->video_encoding != new->video_encoding) {
- int is_scaling;
u16 w = new->width;
u16 h = new->height;
@@ -752,20 +751,18 @@ int cx2341x_update(void *priv, cx2341x_m
}
err = cx2341x_api(priv, func, CX2341X_ENC_SET_FRAME_SIZE, 2, h,
w);
if (err) return err;
+ }
+ if (new->width != 720 || new->height != (new->is_50hz ? 576 : 480)) {
/* Adjust temporal filter if necessary. The problem with the
temporal
filter is that it works well with full resolution capturing,
but
not when the capture window is scaled (the filter introduces
- a ghosting effect). So if the capture window changed, and
there is
- no updated filter value, then the filter is set depending on
whether
- the new window is full resolution or not.
+ a ghosting effect). So if the capture window is scaled, then
+ force the filter to 0.
- For full resolution a setting of 8 really improves the video
+ For full resolution the filter really improves the video
quality, especially if the original video quality is
suboptimal. */
- is_scaling = new->width != 720 || new->height != (new->is_50hz
? 576 : 480);
- if (old && old->video_temporal_filter == temporal) {
- temporal = is_scaling ? 0 : 8;
- }
+ temporal = 0;
}
if (old == NULL || old->stream_type != new->stream_type) {
-
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: How to detect multi-core and/or HT-enabled CPUs in 2.4.x and 2.6.x kernels
In article <[EMAIL PROTECTED]> you wrote: > once your program (and many others) have such a check, then the next > step will be pressure on the kernel code to "fake" the old situation > when there is a processor where no longer > holds. It's basically a road to madness :-( I agree that for HPC sizing a benchmark with various levels of parallelity are better. The question is, if the code in question only is for inventory reasons. In that case I would do something like x sockets, y cores and z cm threads. Bernd - 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/
