* Re: Dump http servers still slow?
From: Darrin Thompson @ 2005-07-29 14:57 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <20050729144802.GA2280@mythryan2.michonline.com>
On Fri, 2005-07-29 at 10:48 -0400, Ryan Anderson wrote:
> On Fri, Jul 29, 2005 at 09:03:41AM -0500, Darrin Thompson wrote:
> >
> > Where is the code for gitweb? (i.e. http://kernel.org/git ) Seems like
> > it could benefit from some git-send-pack superpowers.
>
> http://www.kernel.org/pub/software/scm/gitweb/
>
> It occurs to me that pulling this into the main git repository might not
> be a bad idea, since it is currently living outside any revision
> tracking at the moment.
>
Can't see the code.
http://www.kernel.org/pub/software/scm/gitweb/gitweb.cgi
Internal Server Error
--
Darrin
^ permalink raw reply
* errno usage.
From: Luiz Fernando Capitulino @ 2005-07-29 15:00 UTC (permalink / raw)
To: linux-c-programming
Hi, hi, hi there!
I have a question about 'errno' which I'm postponing for some
time: is it a bad pratice to set 'errno' by hand in libraries
and even in ordinary programs?
I mean, AFAIK 'errno' was created to store error codes from system
calls, but it's widely used by several libraries. Sometimes is even
helpful to set 'errno' in the program itself, something like:
int get_foobar_info(char *value)
{
if (!value) {
errno = EINVAL;
return -1;
}
...
return 0;
}
Is it a bad pratice? Is there a 'limit' for 'errno' usage?
Thank you!
^ permalink raw reply
* [sched, patch] better wake-balancing, #2
From: Ingo Molnar @ 2005-07-29 15:02 UTC (permalink / raw)
To: Chen, Kenneth W
Cc: 'Nick Piggin', linux-kernel, linux-ia64, Andrew Morton
In-Reply-To: <20050729141311.GA4154@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> another approach would be the patch below, to do wakeup-balancing only
> if the wakeup CPU or the task CPU is idle.
there's an even simpler way: only do wakeup-balancing if this_cpu is
idle. (tbench results are still OK, and other workloads improved.)
Ingo
--------
do wakeup-balancing only if the wakeup-CPU is idle.
this prevents excessive wakeup-balancing while the system is highly
loaded, but helps spread out the workload on partly idle systems.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
kernel/sched.c | 6 ++++++
1 files changed, 6 insertions(+)
Index: linux-sched-curr/kernel/sched.c
=================================--- linux-sched-curr.orig/kernel/sched.c
+++ linux-sched-curr/kernel/sched.c
@@ -1253,7 +1253,13 @@ static int try_to_wake_up(task_t *p, uns
if (unlikely(task_running(rq, p)))
goto out_activate;
+ /*
+ * Only do wakeup-balancing (= potentially migrate the task)
+ * if this CPU is idle:
+ */
new_cpu = cpu;
+ if (!idle_cpu(this_cpu))
+ goto out_set_cpu;
schedstat_inc(rq, ttwu_cnt);
if (cpu = this_cpu) {
^ permalink raw reply
* [sched, patch] better wake-balancing, #2
From: Ingo Molnar @ 2005-07-29 15:02 UTC (permalink / raw)
To: Chen, Kenneth W
Cc: 'Nick Piggin', linux-kernel, linux-ia64, Andrew Morton
In-Reply-To: <20050729141311.GA4154@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> another approach would be the patch below, to do wakeup-balancing only
> if the wakeup CPU or the task CPU is idle.
there's an even simpler way: only do wakeup-balancing if this_cpu is
idle. (tbench results are still OK, and other workloads improved.)
Ingo
--------
do wakeup-balancing only if the wakeup-CPU is idle.
this prevents excessive wakeup-balancing while the system is highly
loaded, but helps spread out the workload on partly idle systems.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
kernel/sched.c | 6 ++++++
1 files changed, 6 insertions(+)
Index: linux-sched-curr/kernel/sched.c
===================================================================
--- linux-sched-curr.orig/kernel/sched.c
+++ linux-sched-curr/kernel/sched.c
@@ -1253,7 +1253,13 @@ static int try_to_wake_up(task_t *p, uns
if (unlikely(task_running(rq, p)))
goto out_activate;
+ /*
+ * Only do wakeup-balancing (== potentially migrate the task)
+ * if this CPU is idle:
+ */
new_cpu = cpu;
+ if (!idle_cpu(this_cpu))
+ goto out_set_cpu;
schedstat_inc(rq, ttwu_cnt);
if (cpu == this_cpu) {
^ permalink raw reply
* How to get dentry from inode number?
From: 墳墓 @ 2005-07-29 15:02 UTC (permalink / raw)
To: linux-kernel
Hello, every body.
How can I get a full pathname from an inode number ? (Our data
structure only keep track inode number instead of pathname in
order to keep thin, so don't have any information but inode
number.)
I used iget_locked() to get a struct inode * from an inode number,
and use d_find_alias() to get a dentry, finally use d_path() to get
a absoulte path to the file.
But it only works when I opened the target file before I run
my program, or the d_find_alias() will return NULL.
I also tried d_alloc_anno() and d_splice_alias(), but it crashed
in the d_splice_alias().
So, which function should I check to find the answer?
^ permalink raw reply
* [U-Boot-Users] Best Point for initialization
From: Wolfgang Denk @ 2005-07-29 15:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <dcdfh8$tua$1@sea.gmane.org>
In message <dcdfh8$tua$1@sea.gmane.org> you wrote:
>
> my u-boot port runs. But I want to initialize a very spezial non
> standard device. Where is the best point to do this?
> My first intension is checkboard?
Please do not misuse code. checkboard() is, as the name suggests,
intended to check and print the board version etc. Please use one of
the *init() routined for initialization stuff. misc_init_f() and
misc_init_r() are probably best choice.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A star captain's most solemn oath is that he will give his life, even
his entire crew, rather than violate the Prime Directive.
-- Kirk, "The Omega Glory", stardate unknown
^ permalink raw reply
* Re: Dump http servers still slow?
From: Radoslaw AstralStorm Szkodzinski @ 2005-07-29 15:08 UTC (permalink / raw)
To: Darrin Thompson; +Cc: ryan, junkio, git
In-Reply-To: <1122649056.4263.13.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
On Fri, 29 Jul 2005 09:57:36 -0500
Darrin Thompson <darrint@progeny.com> wrote:
> Can't see the code.
>
> http://www.kernel.org/pub/software/scm/gitweb/gitweb.cgi
>
> Internal Server Error
>
Use FTP.
--
AstralStorm
GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
Please encrypt if you can.
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] speed up on find_first_bit for i386 (let compiler do the work)
From: linux-os (Dick Johnson) @ 2005-07-29 15:08 UTC (permalink / raw)
To: linux; +Cc: linux-kernel, rostedt
In-Reply-To: <20050729143726.24317.qmail@science.horizon.com>
On Fri, 29 Jul 2005 linux@horizon.com wrote:
>> OK, I guess when I get some time, I'll start testing all the i386 bitop
>> functions, comparing the asm with the gcc versions. Now could someone
>> explain to me what's wrong with testing hot cache code. Can one
>> instruction retrieve from memory better than others?
>
Yes! Intel has more than 'load' and 'store' instructions. If
memory is in the cache, the following memory operations are
shown fastest to slowest...
movl (%ebx), %eax # Index-register indirect. Note that
# ebx needs to be loaded so the overall
# access might be slower. Also some
# index registers are faster on
# some CPUs (486-> eax is fastest)
movl (mem), %eax # Direct from memory into register
movl 0x04(%ebx), %eax # Index-register plus displacment
movl (%esi, %ebx), %eax # Two register indirect
movl 0x04(%esi, %ebx), %eax # Two register plus displacement
When using 'movl (men), %eax', "mem" is a 32-bit word that is fetched
from the instruction stream while 'movl (%ebx), %eax' is only 2 bytes.
Therefore, if an index register can remain loaded with the correct offset
or manipulated with 'lea', then single-register indirect memory
access is fastest on current ix86 processors.
> To add one to Linus' list, note that all current AMD & Intel chips
> record instruction boundaries in L1 cache, either predecoding on
> L1 cache load, or marking the boundaries on first execution.
>
> The P4 takes it to an extreme, but P3 and K7/K8 do it too.
>
> The result is that there are additional instruction decode limits
> that apply to cold-cache code.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: Re: [ALSA - driver 0001138]: errors when installing au8820 modules
From: Takashi Iwai @ 2005-07-29 15:09 UTC (permalink / raw)
To: Raymond; +Cc: alsa-devel, openvortex-dev
In-Reply-To: <42EA4086.6030702@netvigator.com>
At Fri, 29 Jul 2005 22:43:18 +0800,
Raymond wrote:
>
> Takashi Iwai wrote:
> > At Wed, 08 Jun 2005 17:06:39 +0800,
> > Raymond wrote:
> >
> >
> >>Is there any reason to make this change ?
> >>
> >>alsa-kernel/pci/au88x0/au88x0.c
> >>@@ -144,15 +144,18 @@
> >> // check PCI availability (DMA).
> >> if ((err = pci_enable_device(pci)) < 0)
> >> return err;
> >>- if (!pci_dma_supported(pci, VORTEX_DMA_MASK)) {
> >>+ if (pci_set_dma_mask(pci, VORTEX_DMA_MASK) < 0 ||
> >>+ pci_set_consistent_dma_mask(pci, VORTEX_DMA_MASK) < 0) {
> >> printk(KERN_ERR "error to set DMA mask\n");
> >>+ pci_disable_device(pci);
> >> return -ENXIO;
> >> }
> >>- pci_set_dma_mask(pci, VORTEX_DMA_MASK);
> >
> >
> > This is clean up.
> >
> >
> >> chip = kcalloc(1, sizeof(*chip), GFP_KERNEL);
> >>- if (chip == NULL)
> >>+ if (chip == NULL) {
> >>+ pci_disable_device(pci);
> >> return -ENOMEM;
> >>+ }
> >
> >
> > This fixes the PCI state in the error path.
> >
> >
> >> chip->card = card;
> >>
> >>@@ -202,6 +205,8 @@
> >> goto alloc_out;
> >> }
> >>
> >>+ snd_card_set_dev(card, &pci->dev);
> >>+
> >> *rchip = chip;
> >
> >
> > And this sets up the missing sysfs stuff.
> >
> >
>
> It seem that these two patches for Kernel 2.6 were lost when au88x0
> migrate from alsa-driver to alsa-kernel.
You're right. It seems dropped at that time accidentally.
Could you care to post a patch to fix them?
thanks,
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: [PATCH] speed up on find_first_bit for i386 (let compiler do the work)
From: Maciej W. Rozycki @ 2005-07-29 15:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, Nick Piggin, Ingo Molnar, Andrew Morton, LKML,
Daniel Walker
In-Reply-To: <Pine.LNX.4.58.0507281017130.3227@g5.osdl.org>
On Thu, 28 Jul 2005, Linus Torvalds wrote:
> > Since you're considering GCC-generated code for ffs(), ffz() and friends,
> > how about trying __builtin_ffs(), __builtin_clz() and __builtin_ctz() as
> > apropriate?
>
> Please don't. Try again in three years when everybody has them.
Well, __builtin_ffs() has been there since at least gcc 2.95. The two
others are quite recent, indeed -- apparently only since GCC 3.4. They
may still be considered to be used conditionally if there is justified
benefit.
Maciej
^ permalink raw reply
* Re: ATI Radeon with PPC 440 GX and kernel 2.6.12
From: Wolfgang Denk @ 2005-07-29 15:10 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <001f01c59417$fe81b840$f201a8c0@SN7606>
In message <001f01c59417$fe81b840$f201a8c0@SN7606> you wrote:
>
> i´m using on my custom board a ATI M6 Mobility Radeon with kernel 2.6.12.
> Now i have to initialize the ati and configure the kernel to support it. Did
> someone use this combination (ppc + ati radeon)? It would be appreciating to
> get some help or tipps in configuring to get the ati functioning. Especially
> the BIOS of the ATI chip, because i have actually found only x86 binaries.
> Is it also possible to set up the bios settings for the ati chip without an
> bios eeprom attached via the radeon driver?
If you use U-Boot as boot loader you can enable and use the x86
emulator taht comes included with it. But don't expect to much help
with that - except for the Amiga One (where I was told this is
working) I don't know of any other board using this feature.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Two wrongs don't make a right, but three rights make a left.
^ permalink raw reply
* Re: How to get dentry from inode number?
From: Jörn Engel @ 2005-07-29 15:11 UTC (permalink / raw)
To: ?X??; +Cc: linux-kernel
In-Reply-To: <615cd8d10507290802690dd50f@mail.gmail.com>
On Fri, 29 July 2005 23:02:53 +0800, ?X?? wrote:
>
> How can I get a full pathname from an inode number ?
That's fundamentally impossible to do. Any given inode may have
multiple paths associated to it. Think of hard links.
Jörn
--
"[One] doesn't need to know [...] how to cause a headache in order
to take an aspirin."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
^ permalink raw reply
* 2.6.13-rc3: cache flush missing from somewhere
From: Russell King @ 2005-07-29 15:13 UTC (permalink / raw)
To: linux-kernel
Hi,
I've been trying for the last 4 or 5 days to get the kernel stable on
an ARM SMP platform. This platform has harvard PIPT caches with no
aliasing issues inside the separate I/D caches, except for the lack
of snooping between the I and D cache. The caches are in write allocate
mode.
This means we need to ensure that the I/D coherency is handled, and
we do this via flush_dcache_page(). We actually do this lazily using
the Sparc64 method, so __flush_dcache_page() actually does the cache
operations.
My current patch to get this working is below. The only thing which
really seems to fix the issue is the __flush_dcache_page call in
read_pages() - if I remove this, I get spurious segfaults and illegal
instruction faults.
If I make flush_dcache_page() non-lazy, this also fixes it, but this
is not desirable. The problem also goes away if I disable the write
allocate cache mode.
If I call __flush_dcache_page() from update_mmu_cache() (iow, always
ensure that we have I/D coherency when the page is mapped into user
space) the effect is the same - I see random faults.
This is using cramfs as the filesystem, which does call flush_dcache_page()
on pages returned via its readpages implementation.
Unfortunately, I've only recently obtained this hardware, but I know
a previous kernel (2.6.7-based) works fine on it (already supplied by
others.) However, there's a massive delta from mainline for this
which makes it totally impractical to try other mainline kernels.
To me, it feels like there's a path which results in pages mapped into
user space without update_mmu_cache() being called, but I'm unable to
find it. Ideas?
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r orig/mm/filemap.c linux/mm/filemap.c
--- orig/mm/filemap.c Wed Jun 29 15:52:51 2005
+++ linux/mm/filemap.c Fri Jul 29 15:32:40 2005
@@ -849,6 +849,8 @@ readpage:
unlock_page(page);
}
+if (page->mapping && !mapping_mapped(page->mapping)) BUG_ON(!test_bit(PG_dcache_dirty, &page->flags));
+{ void __flush_dcache_page(struct address_space *mapping, struct page *page); __flush_dcache_page(page->mapping, page); }
/*
* i_size must be checked after we have done ->readpage.
*
@@ -1158,6 +1160,8 @@ static int fastcall page_cache_read(stru
error = add_to_page_cache_lru(page, mapping, offset, GFP_KERNEL);
if (!error) {
error = mapping->a_ops->readpage(file, page);
+if (page->mapping && !mapping_mapped(page->mapping)) BUG_ON(!test_bit(PG_dcache_dirty, &page->flags));
+{ void __flush_dcache_page(struct address_space *mapping, struct page *page); __flush_dcache_page(page->mapping, page); }
page_cache_release(page);
return error;
}
@@ -1254,7 +1258,9 @@ retry_find:
page = find_get_page(mapping, pgoff);
if (!page)
goto no_cached_page;
+if (page->mapping && !mapping_mapped(page->mapping)) BUG_ON(!test_bit(PG_dcache_dirty, &page->flags));
}
+if (page->mapping && !mapping_mapped(page->mapping)) BUG_ON(!test_bit(PG_dcache_dirty, &page->flags));
if (!did_readaround)
ra->mmap_hit++;
@@ -1267,6 +1273,8 @@ retry_find:
goto page_not_uptodate;
success:
+if (page->mapping && !mapping_mapped(page->mapping)) BUG_ON(!test_bit(PG_dcache_dirty, &page->flags));
+{ void __flush_dcache_page(struct address_space *mapping, struct page *page); __flush_dcache_page(page->mapping, page); }
/*
* Found the page and have a reference on it.
*/
@@ -1402,6 +1410,8 @@ retry_find:
}
success:
+if (page->mapping && !mapping_mapped(page->mapping)) BUG_ON(!test_bit(PG_dcache_dirty, &page->flags));
+{ void __flush_dcache_page(struct address_space *mapping, struct page *page); __flush_dcache_page(page->mapping, page); }
/*
* Found the page and have a reference on it.
*/
@@ -1508,6 +1518,7 @@ repeat:
if (!page && !nonblock)
return -ENOMEM;
if (page) {
+{ void __flush_dcache_page(struct address_space *mapping, struct page *page); __flush_dcache_page(page->mapping, page); }
err = install_page(mm, vma, addr, page, prot);
if (err) {
page_cache_release(page);
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r orig/mm/memory.c linux/mm/memory.c
--- orig/mm/memory.c Wed Jun 29 15:52:51 2005
+++ linux/mm/memory.c Fri Jul 29 15:41:11 2005
@@ -1821,6 +1821,7 @@ do_no_page(struct mm_struct *mm, struct
retry:
cond_resched();
new_page = vma->vm_ops->nopage(vma, address & PAGE_MASK, &ret);
+{ void __flush_dcache_page(struct address_space *mapping, struct page *page); __flush_dcache_page(new_page->mapping, new_page); }
/*
* No smp_rmb is needed here as long as there's a full
* spin_lock/unlock sequence inside the ->nopage callback
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r orig/mm/readahead.c linux/mm/readahead.c
--- orig/mm/readahead.c Mon Apr 4 22:54:55 2005
+++ linux/mm/readahead.c Fri Jul 29 15:57:18 2005
@@ -172,6 +172,7 @@ static int read_pages(struct address_spa
if (!add_to_page_cache(page, mapping,
page->index, GFP_KERNEL)) {
mapping->a_ops->readpage(filp, page);
+{ void __flush_dcache_page(struct address_space *mapping, struct page *page); __flush_dcache_page(page->mapping, page); }
if (!pagevec_add(&lru_pvec, page))
__pagevec_lru_add(&lru_pvec);
} else {
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal
From: Adrian Bunk @ 2005-07-29 15:16 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Thorsten Knabe, linux-kernel, alsa-devel, linux-sound
In-Reply-To: <Pine.LNX.4.61.0507290849050.8400@tm8103.perex-int.cz>
On Fri, Jul 29, 2005 at 08:52:45AM +0200, Jaroslav Kysela wrote:
>
> The problem is that nobody reported us mentioned problems. We have no
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea
> to add a notice to the help file and/or driver that the ALSA driver should
> be tested and bugs reported to the ALSA bug-tracking-system.
Although it wouldn't have helped with this driver, could you review the
currently 35 open ALSA bugs in the kernel Bugzilla [1]?
- Some might first require a question to the submitter whether the
problem is still present in recent kernels.
- Some might be problems in other parts of the kernel
(e.g. ACPI interrupt configuration problems).
- But some bugs might be bugs still present in recent ALSA.
The Gentoo people are using a pretty easy and nice way for forwarding
their bugs to the kernel Bugzilla, that would work the following way for
forwarding Bugs from the kernel Bugzilla to the ALSA BTS:
- open a new bug in the ALSA BTS:
- short description of the issue
- more information is at
http://bugzilla.kernel.org/show_bug.cgi?id\x12345
- add a comment to the kernel Bugzilla (but leave the bug open):
this bug is now handled at the ALSA BTS at
https://bugtrack.alsa-project.org/alsa-bug/view.php?id#456
You could also do this the other way round if e.g. a ACPI interrupt
configuration problem was reported to the ALSA BTS.
> Thanks,
> Jaroslav
cu
Adrian
[1] http://bugzilla.kernel.org/
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal
From: Adrian Bunk @ 2005-07-29 15:16 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Thorsten Knabe, linux-kernel, alsa-devel, linux-sound
In-Reply-To: <Pine.LNX.4.61.0507290849050.8400@tm8103.perex-int.cz>
On Fri, Jul 29, 2005 at 08:52:45AM +0200, Jaroslav Kysela wrote:
>
> The problem is that nobody reported us mentioned problems. We have no
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea
> to add a notice to the help file and/or driver that the ALSA driver should
> be tested and bugs reported to the ALSA bug-tracking-system.
Although it wouldn't have helped with this driver, could you review the
currently 35 open ALSA bugs in the kernel Bugzilla [1]?
- Some might first require a question to the submitter whether the
problem is still present in recent kernels.
- Some might be problems in other parts of the kernel
(e.g. ACPI interrupt configuration problems).
- But some bugs might be bugs still present in recent ALSA.
The Gentoo people are using a pretty easy and nice way for forwarding
their bugs to the kernel Bugzilla, that would work the following way for
forwarding Bugs from the kernel Bugzilla to the ALSA BTS:
- open a new bug in the ALSA BTS:
- short description of the issue
- more information is at
http://bugzilla.kernel.org/show_bug.cgi?id=12345
- add a comment to the kernel Bugzilla (but leave the bug open):
this bug is now handled at the ALSA BTS at
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=23456
You could also do this the other way round if e.g. a ACPI interrupt
configuration problem was reported to the ALSA BTS.
> Thanks,
> Jaroslav
cu
Adrian
[1] http://bugzilla.kernel.org/
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* RE: [PATCH 1/1] Provide support for 6 bit FID codes
From: Langsdorf, Mark @ 2005-07-29 15:16 UTC (permalink / raw)
To: Dave Jones; +Cc: cpufreq
[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]
> -----Original Message-----
> From: Dave Jones [mailto:davej@redhat.com]
> Sent: Thursday, July 28, 2005 10:08 PM
> To: Langsdorf, Mark
> Cc: cpufreq@lists.linux.org.uk
> Subject: Re: [PATCH 1/1] Provide support for 6 bit FID codes
>
>
> On Thu, Jun 23, 2005 at 05:39:04PM -0500, Langsdorf, Mark
> wrote: > Opteron revision F will support higher frequencies
> than > can be encoded in the current driver's 4 bit
> frequency > field. This patch updates the driver to support
> Rev F > including 6 bit FIDs and processor ID updates. >
> > This should apply cleanly whether or not the dual-core
> > bugfix I sent out last week is applied. I'd prefer
> > that both get applied, of course.
> >
> > Signed-off-by: David Keck <david.keck@amd.com>
> > Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
> >
> > -Mark Langsdorf
> > AMD, Inc.
>
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c: In function
> `powernow_k8_acpi_pst_values':
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:698:
> `EXT_TYPE_SHIFT' undeclared (first use in this function)
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:698: (Each
> undeclared identifier is reported only once
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:698: for each
> function it appears in.)
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:698:
> `EXT_TYPE_MASK' undeclared (first use in this function)
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c: In function
> `powernow_k8_cpu_init_acpi':
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:740: warning:
> unused variable `vid'
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:739: warning:
> unused variable `fid'
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:743: warning:
> unused variable `vid'
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:742: warning:
> unused variable `fid'
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:746: `fid'
> undeclared (first use in this function)
> arch/i386/kernel/cpu/cpufreq/powernow-k8.c:746: `vid'
> undeclared (first use in this function)
> make[1]: *** [arch/i386/kernel/cpu/cpufreq/powernow-k8.o] Error 1
> make: *** [arch/i386/kernel/cpu/cpufreq/powernow-k8.o] Error 2
>
> Looks like there's a chunk of this missing ? Can you send an
> incremental fixing this up please ? I'll leave the previous
> diff in the cpufreq git tree, and just send the fix along
> with it when Linus pulls.
>
> Thanks,
>
> Dave
>
>
[-- Attachment #2: rfpn2-2.6.12.patch --]
[-- Type: application/octet-stream, Size: 668 bytes --]
--- linux-rfpn/arch/i386/kernel/cpu/cpufreq/powernow-k8.h.orig 2005-07-15 00:12:08.000000000 -0600
+++ linux-rfpn/arch/i386/kernel/cpu/cpufreq/powernow-k8.h 2005-07-15 00:14:52.000000000 -0600
@@ -125,12 +125,14 @@
#define IRT_SHIFT 30
#define RVO_SHIFT 28
+#define EXT_TYPE_SHIFT 27
#define PLL_L_SHIFT 20
#define MVS_SHIFT 18
#define VST_SHIFT 11
#define VID_SHIFT 6
#define IRT_MASK 3
#define RVO_MASK 3
+#define EXT_TYPE_MASK 1
#define PLL_L_MASK 0x7f
#define MVS_MASK 3
#define VST_MASK 0x7f
[-- Attachment #3: Type: text/plain, Size: 147 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply
* Re: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal
From: Adrian Bunk @ 2005-07-29 15:16 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Thorsten Knabe, linux-kernel, alsa-devel, linux-sound
In-Reply-To: <Pine.LNX.4.61.0507290849050.8400@tm8103.perex-int.cz>
On Fri, Jul 29, 2005 at 08:52:45AM +0200, Jaroslav Kysela wrote:
>
> The problem is that nobody reported us mentioned problems. We have no
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea
> to add a notice to the help file and/or driver that the ALSA driver should
> be tested and bugs reported to the ALSA bug-tracking-system.
Although it wouldn't have helped with this driver, could you review the
currently 35 open ALSA bugs in the kernel Bugzilla [1]?
- Some might first require a question to the submitter whether the
problem is still present in recent kernels.
- Some might be problems in other parts of the kernel
(e.g. ACPI interrupt configuration problems).
- But some bugs might be bugs still present in recent ALSA.
The Gentoo people are using a pretty easy and nice way for forwarding
their bugs to the kernel Bugzilla, that would work the following way for
forwarding Bugs from the kernel Bugzilla to the ALSA BTS:
- open a new bug in the ALSA BTS:
- short description of the issue
- more information is at
http://bugzilla.kernel.org/show_bug.cgi?id=12345
- add a comment to the kernel Bugzilla (but leave the bug open):
this bug is now handled at the ALSA BTS at
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=23456
You could also do this the other way round if e.g. a ACPI interrupt
configuration problem was reported to the ALSA BTS.
> Thanks,
> Jaroslav
cu
Adrian
[1] http://bugzilla.kernel.org/
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] enforce dom0 cpus and balloon out memory
From: Ryan Harper @ 2005-07-29 15:17 UTC (permalink / raw)
To: aq; +Cc: Ian Pratt, xen-devel
In-Reply-To: <9cde8bff05072820043a496e14@mail.gmail.com>
* aq <aquynh@gmail.com> [2005-07-29 09:01]:
> This patch does 2 jobs:
>
> - Enforce the number of CPUs dom0 will take. See the new variable
> "dom0-cpus" in xend-config.sxp (you will want to set this variable to
> 1 on SMP systems)
You could use vcpu-hotplug to drop the extra cpus from dom0 instead of
writing directly into sysfs. The only stopper to that approach is the
fact that dom0's self.channel is not initialized when xend starts and
subsequently doesn't send the control message. Channels are initialized
when a domain is built, but since dom0 is built by xen, the routine
which sets up channels isn't called for dom0. Haven't found a good place
for xend to initialized the channel for dom0 yet either.
See vcpu_hotplug() in xen/xend/XendDomInfo.py
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
^ permalink raw reply
* Re: Broke nice range for RLIMIT NICE
From: Michael Kerrisk @ 2005-07-29 15:14 UTC (permalink / raw)
To: Nix; +Cc: mingo, mpm, linux-kernel, michael.kerrisk, akpm, chrisw
In-Reply-To: <87u0idhdju.fsf@amaterasu.srvr.nix>
> On 29 Jul 2005, Michael Kerrisk stated:
> > Yes, as noted in my earlier message -- at the moment RLIMIT_NICE
> > still isn't in the current glibc snapshot...
>
> According to traffic on libc-hacker, Ulrich committed it on Jun 20
> (along with RLIMIT_RTPRIO support).
I (now) see the message that you mean on libc-hacker, nevertheless,
looking at the glibc-2.3-20050725 snapshot, these two constants do
not appear anywhere. (Strange!)
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest
tarball at ftp://ftp.win.tue.nl/pub/linux-local/manpages/
and grep the source files for 'FIXME'.
^ permalink raw reply
* Re: Add prefetch switch stack hook in scheduler function
From: linux @ 2005-07-29 15:18 UTC (permalink / raw)
To: linux-kernel; +Cc: mingo
> include/asm-alpha/mmu_context.h | 6 ++++++
> include/asm-arm/mmu_context.h | 6 ++++++
> include/asm-arm26/mmu_context.h | 6 ++++++
> include/asm-cris/mmu_context.h | 6 ++++++
> include/asm-frv/mmu_context.h | 6 ++++++
> include/asm-h8300/mmu_context.h | 6 ++++++
> include/asm-i386/mmu_context.h | 6 ++++++
> include/asm-ia64/mmu_context.h | 6 ++++++
> include/asm-m32r/mmu_context.h | 6 ++++++
> include/asm-m68k/mmu_context.h | 6 ++++++
> include/asm-m68knommu/mmu_context.h | 6 ++++++
> include/asm-mips/mmu_context.h | 6 ++++++
> include/asm-parisc/mmu_context.h | 6 ++++++
> include/asm-ppc/mmu_context.h | 6 ++++++
> include/asm-ppc64/mmu_context.h | 6 ++++++
> include/asm-s390/mmu_context.h | 6 ++++++
> include/asm-sh/mmu_context.h | 6 ++++++
> include/asm-sh64/mmu_context.h | 6 ++++++
> include/asm-sparc/mmu_context.h | 6 ++++++
> include/asm-sparc64/mmu_context.h | 6 ++++++
> include/asm-um/mmu_context.h | 6 ++++++
> include/asm-v850/mmu_context.h | 6 ++++++
> include/asm-x86_64/mmu_context.h | 5 +++++
> include/asm-xtensa/mmu_context.h | 6 ++++++
> kernel/sched.c | 9 ++++++++-
> 25 files changed, 151 insertions(+), 1 deletion(-)
I think this pretty clearly points out the need for some arch-generic
infrastructure in Linux. An awful lot of arch hooks are for one
or two architectures with some peculiarities, and the other 90% of
the implementations are identical.
For example, this is 22 repetitions of
#define MIN_KERNEL_STACK_FOOTPRINT L1_CACHE_BYTES
with one different case.
It would be awfully nice if there was a standard way to provide a default
implementation that was automatically picked up by any architecture that
didn't explicitly override it.
One possibility is to use #ifndef:
/* asm-$PLATFORM/foo.h */
#define MIN_KERNEL_STACK_FOOTPRINT IA64_SWITCH_STACK_SIZE
inline void
prefetch_task(struct task_struct const *task)
{
...
}
#define prefetch_task prefetch_task
/* asm-generic/foo.h */
#include <asm/foo.h>
#ifndef MIN_KERNEL_STACK_FOOTPRINT
#define MIN_KERNEL_STACK_FOOTPRINT L1_CACHE_BYTES
#endif
#ifndef prefetch_task
inline void prefetch_task(struct task_struct const *task) { }
/* The #define is OPTIONAL... */
#define prefetch_task prefetch_task
#endif
But both understanding and maintaining the arch code could be
much easier if the shared parts were collapsed. A comment in the
generic versions can explain what the assumptions are.
If there are cases where there is more than one implementation with
multiple users, it can be stuffed into a third category of headers.
E.g. <asm-generic/noiommu/foo.h> and <asm-generic/iommu/foo.h> or some
such, using the same duplicate-suppression technique and #included at
the end of <asm-$PLATFORM/foo.h>
^ permalink raw reply
* FW: Debugging X based programs
From: Kirkwood, David A @ 2005-07-29 15:19 UTC (permalink / raw)
To: linux-c-programming
> I need to debug an X windows program which goes through many levels of
> windos on the screen. I tried using ddd but the ddd display captures all
> of the window events instead of the application I'm trying to debug
> capturing them. Is there some standard way to debug X apps or, is there
> some particular debugger better suited to this requirement? I'm using
> ddd.
>
> Thanks
>
> Dave
^ permalink raw reply
* [uml-devel] [PATCH] UML - Fix vsyscall brokenness
From: Jeff Dike @ 2005-07-29 15:13 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, user-mode-linux-devel, Bodo Stroesser
The #if/#ifdef cleanup exposed a bug in UML's ELF header processing. With
this bug fixed, UML recognizes the vsyscall info coming from the host. On
FC4, there is a vsyscall page low in the address space, which UML doesn't
provide. This causes an infinite page fault loop and a hang on boot.
This patch works around that by making this look like a no-vsyscall system.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Index: linux-2.6.12-rc3-mm2/arch/um/os-Linux/elf_aux.c
===================================================================
--- linux-2.6.12-rc3-mm2.orig/arch/um/os-Linux/elf_aux.c 2005-07-28 12:08:54.000000000 -0400
+++ linux-2.6.12-rc3-mm2/arch/um/os-Linux/elf_aux.c 2005-07-28 18:47:31.000000000 -0400
@@ -9,9 +9,10 @@
*/
#include <elf.h>
#include <stddef.h>
+#include <asm/elf.h>
#include "init.h"
#include "elf_user.h"
-#include <asm/elf.h>
+#include "mem_user.h"
#if ELF_CLASS == ELFCLASS32
typedef Elf32_auxv_t elf_auxv_t;
@@ -41,6 +42,9 @@
break;
case AT_SYSINFO_EHDR:
vsyscall_ehdr = auxv->a_un.a_val;
+ /* See if the page is under TASK_SIZE */
+ if (vsyscall_ehdr < (unsigned long) envp)
+ vsyscall_ehdr = 0;
break;
case AT_HWCAP:
elf_aux_hwcap = auxv->a_un.a_val;
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [PATCH] AC97 bus interface for ad-hoc drivers
From: Takashi Iwai @ 2005-07-29 15:19 UTC (permalink / raw)
To: Liam Girdwood; +Cc: Nicolas Pitre, alsa-devel, Bill Gatliff
In-Reply-To: <1122641516.3117.38.camel@localhost.localdomain>
At Fri, 29 Jul 2005 13:51:56 +0100,
Liam Girdwood wrote:
>
> I've made the review changes and as requested I've pasted the RFC by
> Nicolas below:-
>
> "I would like to know what people think of the following patch. It
> allows for a codec on an AC97 bus to be shared with other drivers which
> are completely unrelated to audio. It registers a new bus type, and
> whenever a codec instance is created then a device for it is also
> registered with the driver model using that bus type. This allows, for
> example, to use the extra features of the UCB1400 like the touchscreen
> interface and the additional GPIOs and ADCs available on that chip for
> battery monitoring. I have a working UCB1400 touchscreen driver here
> that simply registers with the driver model happily working alongside
> with audio features using this."
>
> Changes over RFC:-
>
> o Now matches codec name within codec group.
> o Added ac97_dev_release() to stop kernel complaining about no release
> method for device.
> o Added "config SND_AC97_BUS" to sound/pci/Kconfig and moved "config
> SND_AC97_CODEC" out with the PCI=n statement.
> o module is now called snd-ac97-bus
>
> Signed-off-by: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
Thanks. I applied it to CVS with some modifications.
- the registration and unregistration to ac97_bus is done in
dev_register and dev_unregister callbacks. This assures that
card->dev is set.
- 2.2/2.4 workaronds in alsa-driver tree.
Please check whether it's OK (later, after cvs tree is sync'ed)
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* FW:
From: Kirkwood, David A @ 2005-07-29 15:22 UTC (permalink / raw)
To: 'linux-c-programming@vger.kernel.org'
I need to debug an X windows program which goes through many levels of
windos on the screen. I tried using ddd but the ddd display captures all of
the window events instead of the application I'm trying to debug capturing
them. Is there some standard way to debug X apps or, is there some
particular debugger better suited to this requirement? I'm using ddd.
Thanks
Dave
^ permalink raw reply
* Re: 2.6.13-rc3-mm3
From: Martin J. Bligh @ 2005-07-29 15:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ebiederm
In-Reply-To: <20050728230820.236cba84.akpm@osdl.org>
>> > - There's a pretty large x86_64 update here which naughty maintainer wants
>> > in 2.6.13. Extra testing, please.
>>
>> Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
>> Talked to Andi about it at OLS, but then drank too much to remember the
>> conclusion ... however, it's still broken ;-)
>>
>> Matrix is here (see left hand column).
>>
>> http://test.kernel.org/
>>
>> Example boot log is here:
>>
>> http://test.kernel.org/9447/debug/console.log
>
> Does Eric's recent fix fix it?
>
>
> From: Eric W. Biederman <ebiederm@xmission.com>
>
> sync_tsc was using smp_call_function to ask the boot processor to report
> it's tsc value. smp_call_function performs an IPI_send_allbutself which is
> a broadcast ipi. There is a window during processor startup during which
> the target cpu has started and before it has initialized it's interrupt
> vectors so it can properly process an interrupt. Receveing an interrupt
> during that window will triple fault the cpu and do other nasty things.
Wheeeeeeee! that does indeed seem to work. Nice job.
> I believe this patch suffers from apicid versus logical cpu number
> confusion. I copied the basic logic from smp_send_reschedule and I can't
> find where that translates from the logical cpuid to apicid. So it isn't
> quite correct yet. It should be close enough that it shouldn't be too hard
> to finish it up.
>
> More bug fixes after I have slept but I figured I needed to get this
> one out for review.
Eric, when you have a final version, throw it over to me, and I'll give
that one a spin-test too ...
Thanks!
M.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.