Re: -mm merge plans for 2.6.20
Dave Jones wrote:
On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:
> Dave Jones wrote:
>
> > Eeek! page_mapcount(page) went negative! (-2)
>
> Hmm, probably happened once before, too.
You're right. Going back further in the log, I noticed
that it had happened again exactly at the time that cron restarted vpnc.
The first time, the flags were different..
Dec 4 00:01:03 firewall kernel: Eeek! page_mapcount(page) went negative! (-1)
Dec 4 00:01:03 firewall kernel: page->flags = 400
Dec 4 00:01:03 firewall kernel: page->count = 1
Dec 4 00:01:03 firewall kernel: page->mapping =
Still reserved, with a NULL mapping. I'd say it could be the same page.
> > page->flags = 404
>
> What's that? PG_referenced|PG_reserved? So I'd say it is likely
> that some driver has got its refcounting wrong.
At the time that it bit me, here's what was loaded..
tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac
parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine
via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd
The scary ones (i2c, irda) weren't in use at all, and had never been opened
afaik,
so the potential for those to be corrupting memory is slim, but not out of the
question. (Why the hell asus_acpi is loaded is a mystery, this isn't an Asus,
or a laptop. Probably dumb initscripts).
OK that could be useful if I do some grepping and see which ones are
setting PG_reserved.
> And I see we've got another report for 2.6.19.1 from Chris, which
> is equally vague.
I'll be moving that box to 2.6.19.x at some point real soon, so I'll holler
if I see it again on a later kernel.
> IMO the pattern is much too consistent to be able to attribute
> them all to hardware problems. And considering it takes so long
> for these things to appear, can we get something like the attached
> patch upstream at least until we manage to stamp them out?
Sounds like a good idea to me.
ACKed-by: Dave Jones <[EMAIL PROTECTED]>
Thanks.
> Any other debugging info we can add?
Would it be useful to print the pfn of the page ?
In cases like mine, where it bit twice before it killed the box, it
might be interesting to see if its always the same page. Not sure
what that would prove/disprove though.
Might help. I guess the site where it is allocated from might be
another one, although I'm hoping that if we know what ->nopage is
being used then we'll be able to track it. OTOH it may be using
remap_pfn_range from fops->mmap, rather than nopage... I wonder
how we could get at that info? vma->vm_file->f_op->mmap?
--
SUSE Labs, Novell Inc.
Index: linux-2.6/include/linux/rmap.h
===
--- linux-2.6.orig/include/linux/rmap.h 2006-12-04 19:56:17.0 +1100
+++ linux-2.6/include/linux/rmap.h 2006-12-19 16:14:30.0 +1100
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned
long);
void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *);
/**
* page_dup_rmap - duplicate pte mapping to a page
Index: linux-2.6/mm/filemap_xip.c
===
--- linux-2.6.orig/mm/filemap_xip.c 2006-12-04 19:07:10.0 +1100
+++ linux-2.6/mm/filemap_xip.c 2006-12-19 16:14:30.0 +1100
@@ -189,7 +189,7 @@ __xip_unmap (struct address_space * mapp
/* Nuke the page table entry. */
flush_cache_page(vma, address, pte_pfn(*pte));
pteval = ptep_clear_flush(vma, address, pte);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
dec_mm_counter(mm, file_rss);
BUG_ON(pte_dirty(pteval));
pte_unmap_unlock(pte, ptl);
Index: linux-2.6/mm/fremap.c
===
--- linux-2.6.orig/mm/fremap.c 2006-12-04 19:56:20.0 +1100
+++ linux-2.6/mm/fremap.c 2006-12-19 16:14:30.0 +1100
@@ -33,7 +33,7 @@ static int zap_pte(struct mm_struct *mm,
if (page) {
if (pte_dirty(pte))
set_page_dirty(page);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);
}
} else {
Index: linux-2.6/mm/memory.c
Re: -mm merge plans for 2.6.20
On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote: > Dave Jones wrote: > > > Eeek! page_mapcount(page) went negative! (-2) > > Hmm, probably happened once before, too. You're right. Going back further in the log, I noticed that it had happened again exactly at the time that cron restarted vpnc. The first time, the flags were different.. Dec 4 00:01:03 firewall kernel: Eeek! page_mapcount(page) went negative! (-1) Dec 4 00:01:03 firewall kernel: page->flags = 400 Dec 4 00:01:03 firewall kernel: page->count = 1 Dec 4 00:01:03 firewall kernel: page->mapping = > > page->flags = 404 > > What's that? PG_referenced|PG_reserved? So I'd say it is likely > that some driver has got its refcounting wrong. At the time that it bit me, here's what was loaded.. tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6 ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd The scary ones (i2c, irda) weren't in use at all, and had never been opened afaik, so the potential for those to be corrupting memory is slim, but not out of the question. (Why the hell asus_acpi is loaded is a mystery, this isn't an Asus, or a laptop. Probably dumb initscripts). > And I see we've got another report for 2.6.19.1 from Chris, which > is equally vague. I'll be moving that box to 2.6.19.x at some point real soon, so I'll holler if I see it again on a later kernel. > IMO the pattern is much too consistent to be able to attribute > them all to hardware problems. And considering it takes so long > for these things to appear, can we get something like the attached > patch upstream at least until we manage to stamp them out? Sounds like a good idea to me. ACKed-by: Dave Jones <[EMAIL PROTECTED]> > Any other debugging info we can add? Would it be useful to print the pfn of the page ? In cases like mine, where it bit twice before it killed the box, it might be interesting to see if its always the same page. Not sure what that would prove/disprove though. Dave -- http://www.codemonkey.org.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: -mm merge plans for 2.6.20
Dave Jones wrote:
Eeek! page_mapcount(page) went negative! (-2)
Hmm, probably happened once before, too.
page->flags = 404
What's that? PG_referenced|PG_reserved? So I'd say it is likely
that some driver has got its refcounting wrong.
Unfortunately, this debugging output is almost useless when it
comes to trying to track down the problem any further.
And I see we've got another report for 2.6.19.1 from Chris, which
is equally vague.
IMO the pattern is much too consistent to be able to attribute
them all to hardware problems. And considering it takes so long
for these things to appear, can we get something like the attached
patch upstream at least until we manage to stamp them out? Any
other debugging info we can add?
--
SUSE Labs, Novell Inc.
Index: linux-2.6/include/linux/rmap.h
===
--- linux-2.6.orig/include/linux/rmap.h 2006-12-04 19:56:17.0 +1100
+++ linux-2.6/include/linux/rmap.h 2006-12-19 16:14:30.0 +1100
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned
long);
void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *);
/**
* page_dup_rmap - duplicate pte mapping to a page
Index: linux-2.6/mm/filemap_xip.c
===
--- linux-2.6.orig/mm/filemap_xip.c 2006-12-04 19:07:10.0 +1100
+++ linux-2.6/mm/filemap_xip.c 2006-12-19 16:14:30.0 +1100
@@ -189,7 +189,7 @@ __xip_unmap (struct address_space * mapp
/* Nuke the page table entry. */
flush_cache_page(vma, address, pte_pfn(*pte));
pteval = ptep_clear_flush(vma, address, pte);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
dec_mm_counter(mm, file_rss);
BUG_ON(pte_dirty(pteval));
pte_unmap_unlock(pte, ptl);
Index: linux-2.6/mm/fremap.c
===
--- linux-2.6.orig/mm/fremap.c 2006-12-04 19:56:20.0 +1100
+++ linux-2.6/mm/fremap.c 2006-12-19 16:14:30.0 +1100
@@ -33,7 +33,7 @@ static int zap_pte(struct mm_struct *mm,
if (page) {
if (pte_dirty(pte))
set_page_dirty(page);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);
}
} else {
Index: linux-2.6/mm/memory.c
===
--- linux-2.6.orig/mm/memory.c 2006-12-04 19:56:21.0 +1100
+++ linux-2.6/mm/memory.c 2006-12-19 16:14:30.0 +1100
@@ -681,7 +681,7 @@ static unsigned long zap_pte_range(struc
mark_page_accessed(page);
file_rss--;
}
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
tlb_remove_page(tlb, page);
continue;
}
@@ -1576,7 +1576,7 @@ gotten:
page_table = pte_offset_map_lock(mm, pmd, address, );
if (likely(pte_same(*page_table, orig_pte))) {
if (old_page) {
- page_remove_rmap(old_page);
+ page_remove_rmap(old_page, vma);
if (!PageAnon(old_page)) {
dec_mm_counter(mm, file_rss);
inc_mm_counter(mm, anon_rss);
Index: linux-2.6/mm/rmap.c
===
--- linux-2.6.orig/mm/rmap.c2006-12-04 19:56:21.0 +1100
+++ linux-2.6/mm/rmap.c 2006-12-19 16:20:13.0 +1100
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
@@ -567,7 +568,7 @@ void page_add_file_rmap(struct page *pag
*
* The caller needs to hold the pte lock.
*/
-void page_remove_rmap(struct page *page)
+void page_remove_rmap(struct page *page, struct vm_area_struct *vma)
{
if (atomic_add_negative(-1, >_mapcount)) {
if (unlikely(page_mapcount(page) < 0)) {
@@ -575,6 +576,9 @@ void page_remove_rmap(struct page *page)
printk (KERN_EMERG " page->flags = %lx\n",
page->flags);
printk (KERN_EMERG " page->count = %x\n",
page_count(page));
printk (KERN_EMERG " page->mapping = %p\n",
page->mapping);
+ print_symbol (KERN_EMERG " vma->vm_ops = %s\n",
(unsigned long)vma->vm_ops);
+
Re: -mm merge plans for 2.6.20
Dave Jones wrote:
Eeek! page_mapcount(page) went negative! (-2)
Hmm, probably happened once before, too.
page-flags = 404
What's that? PG_referenced|PG_reserved? So I'd say it is likely
that some driver has got its refcounting wrong.
Unfortunately, this debugging output is almost useless when it
comes to trying to track down the problem any further.
And I see we've got another report for 2.6.19.1 from Chris, which
is equally vague.
IMO the pattern is much too consistent to be able to attribute
them all to hardware problems. And considering it takes so long
for these things to appear, can we get something like the attached
patch upstream at least until we manage to stamp them out? Any
other debugging info we can add?
--
SUSE Labs, Novell Inc.
Index: linux-2.6/include/linux/rmap.h
===
--- linux-2.6.orig/include/linux/rmap.h 2006-12-04 19:56:17.0 +1100
+++ linux-2.6/include/linux/rmap.h 2006-12-19 16:14:30.0 +1100
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned
long);
void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *);
/**
* page_dup_rmap - duplicate pte mapping to a page
Index: linux-2.6/mm/filemap_xip.c
===
--- linux-2.6.orig/mm/filemap_xip.c 2006-12-04 19:07:10.0 +1100
+++ linux-2.6/mm/filemap_xip.c 2006-12-19 16:14:30.0 +1100
@@ -189,7 +189,7 @@ __xip_unmap (struct address_space * mapp
/* Nuke the page table entry. */
flush_cache_page(vma, address, pte_pfn(*pte));
pteval = ptep_clear_flush(vma, address, pte);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
dec_mm_counter(mm, file_rss);
BUG_ON(pte_dirty(pteval));
pte_unmap_unlock(pte, ptl);
Index: linux-2.6/mm/fremap.c
===
--- linux-2.6.orig/mm/fremap.c 2006-12-04 19:56:20.0 +1100
+++ linux-2.6/mm/fremap.c 2006-12-19 16:14:30.0 +1100
@@ -33,7 +33,7 @@ static int zap_pte(struct mm_struct *mm,
if (page) {
if (pte_dirty(pte))
set_page_dirty(page);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);
}
} else {
Index: linux-2.6/mm/memory.c
===
--- linux-2.6.orig/mm/memory.c 2006-12-04 19:56:21.0 +1100
+++ linux-2.6/mm/memory.c 2006-12-19 16:14:30.0 +1100
@@ -681,7 +681,7 @@ static unsigned long zap_pte_range(struc
mark_page_accessed(page);
file_rss--;
}
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
tlb_remove_page(tlb, page);
continue;
}
@@ -1576,7 +1576,7 @@ gotten:
page_table = pte_offset_map_lock(mm, pmd, address, ptl);
if (likely(pte_same(*page_table, orig_pte))) {
if (old_page) {
- page_remove_rmap(old_page);
+ page_remove_rmap(old_page, vma);
if (!PageAnon(old_page)) {
dec_mm_counter(mm, file_rss);
inc_mm_counter(mm, anon_rss);
Index: linux-2.6/mm/rmap.c
===
--- linux-2.6.orig/mm/rmap.c2006-12-04 19:56:21.0 +1100
+++ linux-2.6/mm/rmap.c 2006-12-19 16:20:13.0 +1100
@@ -47,6 +47,7 @@
#include linux/rmap.h
#include linux/rcupdate.h
#include linux/module.h
+#include linux/kallsyms.h
#include asm/tlbflush.h
@@ -567,7 +568,7 @@ void page_add_file_rmap(struct page *pag
*
* The caller needs to hold the pte lock.
*/
-void page_remove_rmap(struct page *page)
+void page_remove_rmap(struct page *page, struct vm_area_struct *vma)
{
if (atomic_add_negative(-1, page-_mapcount)) {
if (unlikely(page_mapcount(page) 0)) {
@@ -575,6 +576,9 @@ void page_remove_rmap(struct page *page)
printk (KERN_EMERG page-flags = %lx\n,
page-flags);
printk (KERN_EMERG page-count = %x\n,
page_count(page));
printk (KERN_EMERG page-mapping = %p\n,
page-mapping);
+ print_symbol (KERN_EMERG
Re: -mm merge plans for 2.6.20
On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote: Dave Jones wrote: Eeek! page_mapcount(page) went negative! (-2) Hmm, probably happened once before, too. You're right. Going back further in the log, I noticed that it had happened again exactly at the time that cron restarted vpnc. The first time, the flags were different.. Dec 4 00:01:03 firewall kernel: Eeek! page_mapcount(page) went negative! (-1) Dec 4 00:01:03 firewall kernel: page-flags = 400 Dec 4 00:01:03 firewall kernel: page-count = 1 Dec 4 00:01:03 firewall kernel: page-mapping = page-flags = 404 What's that? PG_referenced|PG_reserved? So I'd say it is likely that some driver has got its refcounting wrong. At the time that it bit me, here's what was loaded.. tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6 ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd The scary ones (i2c, irda) weren't in use at all, and had never been opened afaik, so the potential for those to be corrupting memory is slim, but not out of the question. (Why the hell asus_acpi is loaded is a mystery, this isn't an Asus, or a laptop. Probably dumb initscripts). And I see we've got another report for 2.6.19.1 from Chris, which is equally vague. I'll be moving that box to 2.6.19.x at some point real soon, so I'll holler if I see it again on a later kernel. IMO the pattern is much too consistent to be able to attribute them all to hardware problems. And considering it takes so long for these things to appear, can we get something like the attached patch upstream at least until we manage to stamp them out? Sounds like a good idea to me. ACKed-by: Dave Jones [EMAIL PROTECTED] Any other debugging info we can add? Would it be useful to print the pfn of the page ? In cases like mine, where it bit twice before it killed the box, it might be interesting to see if its always the same page. Not sure what that would prove/disprove though. Dave -- http://www.codemonkey.org.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: -mm merge plans for 2.6.20
Dave Jones wrote:
On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:
Dave Jones wrote:
Eeek! page_mapcount(page) went negative! (-2)
Hmm, probably happened once before, too.
You're right. Going back further in the log, I noticed
that it had happened again exactly at the time that cron restarted vpnc.
The first time, the flags were different..
Dec 4 00:01:03 firewall kernel: Eeek! page_mapcount(page) went negative! (-1)
Dec 4 00:01:03 firewall kernel: page-flags = 400
Dec 4 00:01:03 firewall kernel: page-count = 1
Dec 4 00:01:03 firewall kernel: page-mapping =
Still reserved, with a NULL mapping. I'd say it could be the same page.
page-flags = 404
What's that? PG_referenced|PG_reserved? So I'd say it is likely
that some driver has got its refcounting wrong.
At the time that it bit me, here's what was loaded..
tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac
parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine
via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd
The scary ones (i2c, irda) weren't in use at all, and had never been opened
afaik,
so the potential for those to be corrupting memory is slim, but not out of the
question. (Why the hell asus_acpi is loaded is a mystery, this isn't an Asus,
or a laptop. Probably dumb initscripts).
OK that could be useful if I do some grepping and see which ones are
setting PG_reserved.
And I see we've got another report for 2.6.19.1 from Chris, which
is equally vague.
I'll be moving that box to 2.6.19.x at some point real soon, so I'll holler
if I see it again on a later kernel.
IMO the pattern is much too consistent to be able to attribute
them all to hardware problems. And considering it takes so long
for these things to appear, can we get something like the attached
patch upstream at least until we manage to stamp them out?
Sounds like a good idea to me.
ACKed-by: Dave Jones [EMAIL PROTECTED]
Thanks.
Any other debugging info we can add?
Would it be useful to print the pfn of the page ?
In cases like mine, where it bit twice before it killed the box, it
might be interesting to see if its always the same page. Not sure
what that would prove/disprove though.
Might help. I guess the site where it is allocated from might be
another one, although I'm hoping that if we know what -nopage is
being used then we'll be able to track it. OTOH it may be using
remap_pfn_range from fops-mmap, rather than nopage... I wonder
how we could get at that info? vma-vm_file-f_op-mmap?
--
SUSE Labs, Novell Inc.
Index: linux-2.6/include/linux/rmap.h
===
--- linux-2.6.orig/include/linux/rmap.h 2006-12-04 19:56:17.0 +1100
+++ linux-2.6/include/linux/rmap.h 2006-12-19 16:14:30.0 +1100
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned
long);
void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *);
/**
* page_dup_rmap - duplicate pte mapping to a page
Index: linux-2.6/mm/filemap_xip.c
===
--- linux-2.6.orig/mm/filemap_xip.c 2006-12-04 19:07:10.0 +1100
+++ linux-2.6/mm/filemap_xip.c 2006-12-19 16:14:30.0 +1100
@@ -189,7 +189,7 @@ __xip_unmap (struct address_space * mapp
/* Nuke the page table entry. */
flush_cache_page(vma, address, pte_pfn(*pte));
pteval = ptep_clear_flush(vma, address, pte);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
dec_mm_counter(mm, file_rss);
BUG_ON(pte_dirty(pteval));
pte_unmap_unlock(pte, ptl);
Index: linux-2.6/mm/fremap.c
===
--- linux-2.6.orig/mm/fremap.c 2006-12-04 19:56:20.0 +1100
+++ linux-2.6/mm/fremap.c 2006-12-19 16:14:30.0 +1100
@@ -33,7 +33,7 @@ static int zap_pte(struct mm_struct *mm,
if (page) {
if (pte_dirty(pte))
set_page_dirty(page);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma);
page_cache_release(page);
}
} else {
Index: linux-2.6/mm/memory.c
===
---
Re: -mm merge plans for 2.6.20
In-Reply-To: <[EMAIL PROTECTED]> On Tue, 12 Dec 2006 12:49:09 -0500, Dave Jones wrote: > EFLAGS: 00010246 (2.6.18-1.2849.fc6 #1) > That was from a 2.6.18.3 kernel iirc. Here's an idea from Michael Tokarev <[EMAIL PROTECTED]>: since .version always contains 1 when you build an RPM, you can modify it and put your base kernel version there during the build. Then you would see: EFLAGS: 00010246 (2.6.18-1.2849.fc6 #2.6.18.3) -- MBTI: IXTP - 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: -mm merge plans for 2.6.20
On Tue, Dec 05, 2006 at 11:02:50AM -0500, Dave Jones wrote:
> On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:
>
> > cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
> > remove-hotplug-cpu-crap-from-cpufreq.patch
> > cpufreq-select-consistently-re-2619-rc5-mm1.patch
> > cpufreq-set-policy-curfreq-on-initialization.patch
> >
> bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch
> >
> > Sent to cpufreq maintainer
>
> I'm travelling right now, and somehow managed to oops my home router
> 3000 miles away making it hard for me to access mail & stuff.
> (That "page count went negative" BUG() bit me when I did a killall -9 vpnc)
Finally managed to fish this out of the logs..
Eeek! page_mapcount(page) went negative! (-2)
page->flags = 404
page->count = 1
page->mapping =
[ cut here ]
kernel BUG at mm/rmap.c:587!
invalid opcode: [#2]
SMP
last sysfs file: /class/net/lo/type
Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac
parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine
via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.18-1.2849.fc6 #1)
EIP is at page_remove_rmap+0x8b/0xac
eax: ebx: c100 ecx: edx: 0046
esi: dcaa2f98 edi: 0020 ebp: cd3f7f00 esp: cd3e4ddc
ds: 007b es: 007b ss: 0068
Process vpnc (pid: 3367, ti=cd3e4000 task=cd3a0b50 task.ti=cd3e4000)
Stack: c0638bad c100 09bc c045e199 dcaa2f98 cd3e4e54
003ebff8 0001 09bdb000 cd377098 c1624a80 c13e5f60 fffa
c1624ad4 cd377098 09bdb000 cd3e4e54 c1485d4c c1624a80
Call Trace:
[] unmap_vmas+0x28e/0x504
[] exit_mmap+0x77/0xf1
[] mmput+0x34/0x7a
[] do_exit+0x20b/0x776
[] sys_exit_group+0x0/0xd
[] 0xcd39a644
DWARF2 unwinder stuck at 0xcd39a644
Leftover inexact backtrace:
[] do_page_fault+0x0/0x4db
[] get_signal_to_deliver+0x38b/0x3b3
[] do_IRQ+0xb0/0xbc
[] do_page_fault+0x0/0x4db
[] do_notify_resume+0x7e/0x6c1
[] __handle_mm_fault+0x82c/0x860
[] do_IRQ+0xb0/0xbc
[] _spin_unlock_irq+0x5/0x7
[] schedule+0x960/0x9dd
[] do_page_fault+0x0/0x4db
[] work_notifysig+0x13/0x19
===
Code: 82 1e fc ff 8b 43 10 c7 04 24 ad 8b 63 c0 89 44 24 04 e8 6f 1e fc ff 8b
46 40 85 c0 74 0d 8b 50 08 b8 c6 8b 63 c0 e8 07 ce fd ff <0f> 0b 4b 02 42 8b 63
c0 8b 53 10 89 d8 59 5b 5b 5e 83 f2 01 83
EIP: [] page_remove_rmap+0x8b/0xac SS:ESP 0068:cd3e4ddc
<3>BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():1, irqs_disabled():0
[] dump_trace+0x69/0x1af
[] show_trace_log_lvl+0x18/0x2c
[] show_trace+0xf/0x11
[] dump_stack+0x15/0x17
[] down_read+0x12/0x20
[] blocking_notifier_call_chain+0xe/0x29
[] do_exit+0x1b/0x776
[] die+0x29d/0x2c2
[] do_invalid_op+0xa2/0xab
[] error_code+0x39/0x40
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
[] page_remove_rmap+0x8b/0xac
[] unmap_vmas+0x28e/0x504
[] exit_mmap+0x77/0xf1
[] mmput+0x34/0x7a
[] do_exit+0x20b/0x776
[] __dequeue_signal+0x151/0x15c
[] do_page_fault+0x0/0x4db
[] sys_exit_group+0x0/0xd
[] do_page_fault+0x0/0x4db
[] get_signal_to_deliver+0x38b/0x3b3
[] do_IRQ+0xb0/0xbc
[] do_page_fault+0x0/0x4db
[] do_notify_resume+0x7e/0x6c1
[] __handle_mm_fault+0x82c/0x860
[] do_IRQ+0xb0/0xbc
[] _spin_unlock_irq+0x5/0x7
[] schedule+0x960/0x9dd
[] do_page_fault+0x0/0x4db
[] work_notifysig+0x13/0x19
===
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: vpnc/0x0001/3367
[] dump_trace+0x69/0x1af
[] show_trace_log_lvl+0x18/0x2c
[] show_trace+0xf/0x11
[] dump_stack+0x15/0x17
[] schedule+0x43/0x9dd
[] do_exit+0xea/0x776
[] die+0x29d/0x2c2
[] do_invalid_op+0xa2/0xab
[] error_code+0x39/0x40
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
[] page_remove_rmap+0x8b/0xac
[] unmap_vmas+0x28e/0x504
[] exit_mmap+0x77/0xf1
[] mmput+0x34/0x7a
[] do_exit+0x20b/0x776
[] __dequeue_signal+0x151/0x15c
[] do_page_fault+0x0/0x4db
[] sys_exit_group+0x0/0xd
[] do_page_fault+0x0/0x4db
[] get_signal_to_deliver+0x38b/0x3b3
[] do_IRQ+0xb0/0xbc
[] do_page_fault+0x0/0x4db
[] do_notify_resume+0x7e/0x6c1
[] __handle_mm_fault+0x82c/0x860
[] do_IRQ+0xb0/0xbc
[] _spin_unlock_irq+0x5/0x7
[] schedule+0x960/0x9dd
[] do_page_fault+0x0/0x4db
[] work_notifysig+0x13/0x19
===
That was from a 2.6.18.3 kernel iirc.
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: -mm merge plans for 2.6.20
On Tue, Dec 05, 2006 at 11:02:50AM -0500, Dave Jones wrote:
On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:
cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
remove-hotplug-cpu-crap-from-cpufreq.patch
cpufreq-select-consistently-re-2619-rc5-mm1.patch
cpufreq-set-policy-curfreq-on-initialization.patch
bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch
Sent to cpufreq maintainer
I'm travelling right now, and somehow managed to oops my home router
3000 miles away making it hard for me to access mail stuff.
(That page count went negative BUG() bit me when I did a killall -9 vpnc)
Finally managed to fish this out of the logs..
Eeek! page_mapcount(page) went negative! (-2)
page-flags = 404
page-count = 1
page-mapping =
[ cut here ]
kernel BUG at mm/rmap.c:587!
invalid opcode: [#2]
SMP
last sysfs file: /class/net/lo/type
Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac
parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine
via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd
CPU:0
EIP:0060:[c046396c]Not tainted VLI
EFLAGS: 00010246 (2.6.18-1.2849.fc6 #1)
EIP is at page_remove_rmap+0x8b/0xac
eax: ebx: c100 ecx: edx: 0046
esi: dcaa2f98 edi: 0020 ebp: cd3f7f00 esp: cd3e4ddc
ds: 007b es: 007b ss: 0068
Process vpnc (pid: 3367, ti=cd3e4000 task=cd3a0b50 task.ti=cd3e4000)
Stack: c0638bad c100 09bc c045e199 dcaa2f98 cd3e4e54
003ebff8 0001 09bdb000 cd377098 c1624a80 c13e5f60 fffa
c1624ad4 cd377098 09bdb000 cd3e4e54 c1485d4c c1624a80
Call Trace:
[c045e199] unmap_vmas+0x28e/0x504
[c0460c0f] exit_mmap+0x77/0xf1
[c0422d75] mmput+0x34/0x7a
[c0427818] do_exit+0x20b/0x776
[c0427df9] sys_exit_group+0x0/0xd
[cd39a644] 0xcd39a644
DWARF2 unwinder stuck at 0xcd39a644
Leftover inexact backtrace:
[c0615375] do_page_fault+0x0/0x4db
[c0430828] get_signal_to_deliver+0x38b/0x3b3
[c04068d1] do_IRQ+0xb0/0xbc
[c0615375] do_page_fault+0x0/0x4db
[c0403626] do_notify_resume+0x7e/0x6c1
[c045f135] __handle_mm_fault+0x82c/0x860
[c04068d1] do_IRQ+0xb0/0xbc
[c061455e] _spin_unlock_irq+0x5/0x7
[c0612ccc] schedule+0x960/0x9dd
[c0615375] do_page_fault+0x0/0x4db
[c04040a2] work_notifysig+0x13/0x19
===
Code: 82 1e fc ff 8b 43 10 c7 04 24 ad 8b 63 c0 89 44 24 04 e8 6f 1e fc ff 8b
46 40 85 c0 74 0d 8b 50 08 b8 c6 8b 63 c0 e8 07 ce fd ff 0f 0b 4b 02 42 8b 63
c0 8b 53 10 89 d8 59 5b 5b 5e 83 f2 01 83
EIP: [c046396c] page_remove_rmap+0x8b/0xac SS:ESP 0068:cd3e4ddc
3BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():1, irqs_disabled():0
[c04051db] dump_trace+0x69/0x1af
[c0405339] show_trace_log_lvl+0x18/0x2c
[c04058ed] show_trace+0xf/0x11
[c04059ea] dump_stack+0x15/0x17
[c04394a2] down_read+0x12/0x20
[c0431601] blocking_notifier_call_chain+0xe/0x29
[c0427628] do_exit+0x1b/0x776
[c040588e] die+0x29d/0x2c2
[c0405fd3] do_invalid_op+0xa2/0xab
[c0404b85] error_code+0x39/0x40
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
[c046396c] page_remove_rmap+0x8b/0xac
[c045e199] unmap_vmas+0x28e/0x504
[c0460c0f] exit_mmap+0x77/0xf1
[c0422d75] mmput+0x34/0x7a
[c0427818] do_exit+0x20b/0x776
[c042f153] __dequeue_signal+0x151/0x15c
[c0615375] do_page_fault+0x0/0x4db
[c0427df9] sys_exit_group+0x0/0xd
[c0615375] do_page_fault+0x0/0x4db
[c0430828] get_signal_to_deliver+0x38b/0x3b3
[c04068d1] do_IRQ+0xb0/0xbc
[c0615375] do_page_fault+0x0/0x4db
[c0403626] do_notify_resume+0x7e/0x6c1
[c045f135] __handle_mm_fault+0x82c/0x860
[c04068d1] do_IRQ+0xb0/0xbc
[c061455e] _spin_unlock_irq+0x5/0x7
[c0612ccc] schedule+0x960/0x9dd
[c0615375] do_page_fault+0x0/0x4db
[c04040a2] work_notifysig+0x13/0x19
===
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: vpnc/0x0001/3367
[c04051db] dump_trace+0x69/0x1af
[c0405339] show_trace_log_lvl+0x18/0x2c
[c04058ed] show_trace+0xf/0x11
[c04059ea] dump_stack+0x15/0x17
[c06123af] schedule+0x43/0x9dd
[c04276f7] do_exit+0xea/0x776
[c040588e] die+0x29d/0x2c2
[c0405fd3] do_invalid_op+0xa2/0xab
[c0404b85] error_code+0x39/0x40
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
[c046396c] page_remove_rmap+0x8b/0xac
[c045e199] unmap_vmas+0x28e/0x504
[c0460c0f] exit_mmap+0x77/0xf1
[c0422d75] mmput+0x34/0x7a
[c0427818] do_exit+0x20b/0x776
[c042f153] __dequeue_signal+0x151/0x15c
[c0615375] do_page_fault+0x0/0x4db
[c0427df9] sys_exit_group+0x0/0xd
[c0615375] do_page_fault+0x0/0x4db
Re: -mm merge plans for 2.6.20
In-Reply-To: [EMAIL PROTECTED] On Tue, 12 Dec 2006 12:49:09 -0500, Dave Jones wrote: EFLAGS: 00010246 (2.6.18-1.2849.fc6 #1) That was from a 2.6.18.3 kernel iirc. Here's an idea from Michael Tokarev [EMAIL PROTECTED]: since .version always contains 1 when you build an RPM, you can modify it and put your base kernel version there during the build. Then you would see: EFLAGS: 00010246 (2.6.18-1.2849.fc6 #2.6.18.3) -- MBTI: IXTP - 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: -mm merge plans for 2.6.20
In-Reply-To: <[EMAIL PROTECTED]> On Sun, 10 Dec 2006 22:19:04 -0600, Steve French wrote: > I don't remember any problems reported with plain text password > support on current cifs and I have certainly seen it negotiated with no > problem, > but I will double check with your reported flag combination. I played around with it some more. With SecurityFlags = 0x7 (default) the server asks for a plaintext password and the client refuses. That's fine. With 0x37 the client agrees to send a plaintext password (or at least fails to reject the server's request for one,) but actually sends: < ANSI Password Length: 24 < Unicode Password Length: 24 < ANSI Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C < Unicode Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C (my password was ). This fails with error -13 (invalid password.) With 0x30 the client sends: > Password Length: 24 > Password: 6161616161616161681C1DCF2200 and everything works. > > Also, the client doesn't automatically pick up the domain name from > > smb.conf like smbfs does. > > > > > That is true, and is intentional. cifs sends a domain of null (ie use > the server's > default domain) - but it can be overridden on mount That's OK then. I just happened to notice it when I was comparing traces of smbfs mounts to the ones from cifs. Maybe the manpage should mention this difference for those who are converting, though. -- MBTI: IXTP - 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: -mm merge plans for 2.6.20
In-Reply-To: [EMAIL PROTECTED] On Sun, 10 Dec 2006 22:19:04 -0600, Steve French wrote: I don't remember any problems reported with plain text password support on current cifs and I have certainly seen it negotiated with no problem, but I will double check with your reported flag combination. I played around with it some more. With SecurityFlags = 0x7 (default) the server asks for a plaintext password and the client refuses. That's fine. With 0x37 the client agrees to send a plaintext password (or at least fails to reject the server's request for one,) but actually sends: ANSI Password Length: 24 Unicode Password Length: 24 ANSI Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C Unicode Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C (my password was ). This fails with error -13 (invalid password.) With 0x30 the client sends: Password Length: 24 Password: 6161616161616161681C1DCF2200 and everything works. Also, the client doesn't automatically pick up the domain name from smb.conf like smbfs does. That is true, and is intentional. cifs sends a domain of null (ie use the server's default domain) - but it can be overridden on mount That's OK then. I just happened to notice it when I was comparing traces of smbfs mounts to the ones from cifs. Maybe the manpage should mention this difference for those who are converting, though. -- MBTI: IXTP - 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: -mm merge plans for 2.6.20
In-Reply-To: <[EMAIL PROTECTED]> On Fri, 08 Dec 2006 12:32:05 -0600, Steve French wrote: > smbfs deprecation is ok but there are a few things to consider: > 2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support How well-tested is the plaintext password support? By default the /proc/fs/cifs/SecurityFlags setting is 0x7 (MAY_SIGN | MAY_NTLM | MAYNTLMV2). Trying to connect to an old Samba server with that, I got a message that the server requested a plain text password but client support was disabled. After changing the flags to 0x37 (adding MAY_LANMAN | MAY_PLNTXT), I got "invalid password." Looking at the ethereal traces, it seemed that the password was being sent as encrypted Unicode, and the only way to make it connect was to set the flags to 0x30. Also, the client doesn't automatically pick up the domain name from smb.conf like smbfs does. -- Chuck "Even supernovas have their duller moments." - 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: -mm merge plans for 2.6.20
On Sat, 9 Dec 2006 01:30:55 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote: > > > kconfig-new-function-bool-conf_get_changedvoid.patch > > kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch > > kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch > > kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch > > pa-risc-fix-bogus-warnings-from-modpost.patch > > kconfig-refactoring-for-better-menu-nesting.patch > > kbuild-fix-rr-is-now-default.patch > > kbuild-dont-put-temp-files-in-the-source-tree.patch > > actually-delete-the-as-instr-ld-option-tmp-file.patch > > > > Sent to Sam, but Sam's presently busy. I might need to make some kbuild > > decisions.. > > /me digs thru 65 KB email. > > > I can/will help on some of these if you want it... > feel free. I'm planning on going through the above, see which of then have a sufficiently high obviousness*urgency product. - 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: -mm merge plans for 2.6.20
On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote: > kconfig-new-function-bool-conf_get_changedvoid.patch > kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch > kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch > kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch > pa-risc-fix-bogus-warnings-from-modpost.patch > kconfig-refactoring-for-better-menu-nesting.patch > kbuild-fix-rr-is-now-default.patch > kbuild-dont-put-temp-files-in-the-source-tree.patch > actually-delete-the-as-instr-ld-option-tmp-file.patch > > Sent to Sam, but Sam's presently busy. I might need to make some kbuild > decisions.. /me digs thru 65 KB email. I can/will help on some of these if you want it... --- ~Randy - 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: -mm merge plans for 2.6.20
On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote: kconfig-new-function-bool-conf_get_changedvoid.patch kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch pa-risc-fix-bogus-warnings-from-modpost.patch kconfig-refactoring-for-better-menu-nesting.patch kbuild-fix-rr-is-now-default.patch kbuild-dont-put-temp-files-in-the-source-tree.patch actually-delete-the-as-instr-ld-option-tmp-file.patch Sent to Sam, but Sam's presently busy. I might need to make some kbuild decisions.. groan /me digs thru 65 KB email. I can/will help on some of these if you want it... --- ~Randy - 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: -mm merge plans for 2.6.20
On Sat, 9 Dec 2006 01:30:55 -0800 Randy Dunlap [EMAIL PROTECTED] wrote: On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote: kconfig-new-function-bool-conf_get_changedvoid.patch kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch pa-risc-fix-bogus-warnings-from-modpost.patch kconfig-refactoring-for-better-menu-nesting.patch kbuild-fix-rr-is-now-default.patch kbuild-dont-put-temp-files-in-the-source-tree.patch actually-delete-the-as-instr-ld-option-tmp-file.patch Sent to Sam, but Sam's presently busy. I might need to make some kbuild decisions.. groan /me digs thru 65 KB email. I can/will help on some of these if you want it... feel free. I'm planning on going through the above, see which of then have a sufficiently high obviousness*urgency product. - 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: -mm merge plans for 2.6.20
In-Reply-To: [EMAIL PROTECTED] On Fri, 08 Dec 2006 12:32:05 -0600, Steve French wrote: smbfs deprecation is ok but there are a few things to consider: 2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support How well-tested is the plaintext password support? By default the /proc/fs/cifs/SecurityFlags setting is 0x7 (MAY_SIGN | MAY_NTLM | MAYNTLMV2). Trying to connect to an old Samba server with that, I got a message that the server requested a plain text password but client support was disabled. After changing the flags to 0x37 (adding MAY_LANMAN | MAY_PLNTXT), I got invalid password. Looking at the ethereal traces, it seemed that the password was being sent as encrypted Unicode, and the only way to make it connect was to set the flags to 0x30. Also, the client doesn't automatically pick up the domain name from smb.conf like smbfs does. -- Chuck Even supernovas have their duller moments. - 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: -mm merge plans for 2.6.20
On Fri, 08 Dec 2006 12:32:05 -0600
Steve French <[EMAIL PROTECTED]> wrote:
> akpm wrote:
> >deprecate-smbfs-in-favour-of-cifs.patch
> >deprecate-smbfs-in-favour-of-cifs-docs.patch
> >
> > Am still waiting to hear from sfrench on the appropriateness of this.
>
>
> smbfs deprecation is ok but there are a few things to consider:
OK, thanks for the update. We would like to make smbfs go away asap, but
from my POV it's up to you to say when we should do that.
otoh, it might be a good idea to merge a variant of that patch which
doesn't mention a specific data. Say,
if (warn_count < 5) {
warn_count++;
printk(KERN_EMERG "smbfs is not being maintained."
" Please migrate to cifs\n");
}
?
>
> ...
>
> Running simple tests on smbfs, I run into so many problems now though, it
> is probably time to mark it as deprecated as Fedora etc. apparently
> already have.
No, smbfs is not in very good shape.
-
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: -mm merge plans for 2.6.20
On Fri, 08 Dec 2006 09:09:34 -0500 Stephen Smalley <[EMAIL PROTECTED]> wrote: > On Mon, 2006-12-04 at 20:40 -0800, Andrew Morton wrote: > > mprotect-patch-for-use-by-slim.patch > > integrity-service-api-and-dummy-provider.patch > > integrity-service-api-and-dummy-provider-cleanup-use-of-configh.patch > > integrity-service-api-and-dummy-provider-compilation-warning-fix.patch > > slim-main-patch.patch > > slim-main-patch-socket_post_create-hook-return-code.patch > > slim-main-patch-misc-cleanups-requested-at-inclusion-time.patch > > slim-main-patch-handle-failure-to-register.patch > > slim-main-patch-fix-bug-with-mm_users-usage.patch > > slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch > > slim-secfs-patch.patch > > slim-secfs-patch-slim-correct-use-of-snprintf.patch > > slim-secfs-patch-cleanup-use-of-configh.patch > > slim-make-and-config-stuff.patch > > slim-make-and-config-stuff-makefile-fix.patch > > slim-debug-output.patch > > slim-fix-security-issue-with-the-task_post_setuid-hook.patch > > slim-secfs-inode-i_private-build-fix.patch > > slim-documentation.patch > > fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch > > > > Shall hold in -mm. > > Why? They're on hold awaiting further development and awaiting a merge/no-merge decision. They're not causing me any trouble. > I haven't seen any evidence that prior review comments have been > addressed so far, and a fresh patch set would be beneficial anyway to > facilitate full review of the updated code and to allow them to fix > their patch descriptions as well (as they were wrong in some instances, > describing older versions of the code). If/when the developers start doing more work, we can then decide whether to use incremental patches or to take a drop-them-and-start-again approach. (If a whole new patch series comes out, I have tricks which allow me to check that none of the above fixup patches got lost. Those tricks don't work if I drop all the patches first) But yes, it has been pretty quiet. If there's no intention to proceed with these patches, someone please tell 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: -mm merge plans for 2.6.20
akpm wrote:
deprecate-smbfs-in-favour-of-cifs.patch
deprecate-smbfs-in-favour-of-cifs-docs.patch
Am still waiting to hear from sfrench on the appropriateness of this.
smbfs deprecation is ok but there are a few things to consider:
1) Secure mounts: although more secure mounts are possible now to
Windows (not just Samba) with the most recent NTLMv2 patch in the cifs
tree, implementation of Kerberized mounts are stuck in debates about the
right upcall mechanisms (gssapi/spnego blobs can be almost 64K in size,
and userspace turned out to need to keep state across a sequence of two
to three
upcalls before discarding its state which complicates things). smbfs
can handle
kerberos mounts in some cases so this is critical, even though in
practice ntlmv2
is often good enough.
2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support
cifs is better in many cases than smbfs for this now, but cifs does
not handle utimes() remotely to them yet ie setting date/time the old
style
DOS or OS/2 way (cifs can of course query the time fine). This may not
matter
for most cases and would be pretty easy to finish up
3) Documentation - minor cifs vs. smbfs differences in
syntax/behavior. I have
added some of this to the cifs documentation .odt file but have not
posted the
pdf yet nor updated the shorter fs/cifs/README with some of this
helpful information (differences in syntax to help users migrating from
smbfs).
I will post that to the cifs project site as PDF and .ODT this weekend.
4) Hot bugs ... For most users we should be ok here, but there is one major
unresolved bug that worries me: the cache_reap bug ("sleeping function
called from invalid context" in list_del+0x9/0x6c)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214622
Not sure whose bug that will turn out to be and ACPI settings seem to
affect it but it obviously affects some 2.6.19 users.
Running simple tests on smbfs, I run into so many problems now though, it
is probably time to mark it as deprecated as Fedora etc. apparently
already have.
-
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: -mm merge plans for 2.6.20
On Mon, 2006-12-04 at 20:40 -0800, Andrew Morton wrote: > mprotect-patch-for-use-by-slim.patch > integrity-service-api-and-dummy-provider.patch > integrity-service-api-and-dummy-provider-cleanup-use-of-configh.patch > integrity-service-api-and-dummy-provider-compilation-warning-fix.patch > slim-main-patch.patch > slim-main-patch-socket_post_create-hook-return-code.patch > slim-main-patch-misc-cleanups-requested-at-inclusion-time.patch > slim-main-patch-handle-failure-to-register.patch > slim-main-patch-fix-bug-with-mm_users-usage.patch > slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch > slim-secfs-patch.patch > slim-secfs-patch-slim-correct-use-of-snprintf.patch > slim-secfs-patch-cleanup-use-of-configh.patch > slim-make-and-config-stuff.patch > slim-make-and-config-stuff-makefile-fix.patch > slim-debug-output.patch > slim-fix-security-issue-with-the-task_post_setuid-hook.patch > slim-secfs-inode-i_private-build-fix.patch > slim-documentation.patch > fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch > > Shall hold in -mm. Why? I haven't seen any evidence that prior review comments have been addressed so far, and a fresh patch set would be beneficial anyway to facilitate full review of the updated code and to allow them to fix their patch descriptions as well (as they were wrong in some instances, describing older versions of the code). -- Stephen Smalley National Security Agency - 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: -mm merge plans for 2.6.20
On Mon, 2006-12-04 at 20:40 -0800, Andrew Morton wrote: mprotect-patch-for-use-by-slim.patch integrity-service-api-and-dummy-provider.patch integrity-service-api-and-dummy-provider-cleanup-use-of-configh.patch integrity-service-api-and-dummy-provider-compilation-warning-fix.patch slim-main-patch.patch slim-main-patch-socket_post_create-hook-return-code.patch slim-main-patch-misc-cleanups-requested-at-inclusion-time.patch slim-main-patch-handle-failure-to-register.patch slim-main-patch-fix-bug-with-mm_users-usage.patch slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch slim-secfs-patch.patch slim-secfs-patch-slim-correct-use-of-snprintf.patch slim-secfs-patch-cleanup-use-of-configh.patch slim-make-and-config-stuff.patch slim-make-and-config-stuff-makefile-fix.patch slim-debug-output.patch slim-fix-security-issue-with-the-task_post_setuid-hook.patch slim-secfs-inode-i_private-build-fix.patch slim-documentation.patch fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch Shall hold in -mm. Why? I haven't seen any evidence that prior review comments have been addressed so far, and a fresh patch set would be beneficial anyway to facilitate full review of the updated code and to allow them to fix their patch descriptions as well (as they were wrong in some instances, describing older versions of the code). -- Stephen Smalley National Security Agency - 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: -mm merge plans for 2.6.20
akpm wrote: deprecate-smbfs-in-favour-of-cifs.patch deprecate-smbfs-in-favour-of-cifs-docs.patch Am still waiting to hear from sfrench on the appropriateness of this. smbfs deprecation is ok but there are a few things to consider: 1) Secure mounts: although more secure mounts are possible now to Windows (not just Samba) with the most recent NTLMv2 patch in the cifs tree, implementation of Kerberized mounts are stuck in debates about the right upcall mechanisms (gssapi/spnego blobs can be almost 64K in size, and userspace turned out to need to keep state across a sequence of two to three upcalls before discarding its state which complicates things). smbfs can handle kerberos mounts in some cases so this is critical, even though in practice ntlmv2 is often good enough. 2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support cifs is better in many cases than smbfs for this now, but cifs does not handle utimes() remotely to them yet ie setting date/time the old style DOS or OS/2 way (cifs can of course query the time fine). This may not matter for most cases and would be pretty easy to finish up 3) Documentation - minor cifs vs. smbfs differences in syntax/behavior. I have added some of this to the cifs documentation .odt file but have not posted the pdf yet nor updated the shorter fs/cifs/README with some of this helpful information (differences in syntax to help users migrating from smbfs). I will post that to the cifs project site as PDF and .ODT this weekend. 4) Hot bugs ... For most users we should be ok here, but there is one major unresolved bug that worries me: the cache_reap bug (sleeping function called from invalid context in list_del+0x9/0x6c) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214622 Not sure whose bug that will turn out to be and ACPI settings seem to affect it but it obviously affects some 2.6.19 users. Running simple tests on smbfs, I run into so many problems now though, it is probably time to mark it as deprecated as Fedora etc. apparently already have. - 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: -mm merge plans for 2.6.20
On Fri, 08 Dec 2006 09:09:34 -0500 Stephen Smalley [EMAIL PROTECTED] wrote: On Mon, 2006-12-04 at 20:40 -0800, Andrew Morton wrote: mprotect-patch-for-use-by-slim.patch integrity-service-api-and-dummy-provider.patch integrity-service-api-and-dummy-provider-cleanup-use-of-configh.patch integrity-service-api-and-dummy-provider-compilation-warning-fix.patch slim-main-patch.patch slim-main-patch-socket_post_create-hook-return-code.patch slim-main-patch-misc-cleanups-requested-at-inclusion-time.patch slim-main-patch-handle-failure-to-register.patch slim-main-patch-fix-bug-with-mm_users-usage.patch slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch slim-secfs-patch.patch slim-secfs-patch-slim-correct-use-of-snprintf.patch slim-secfs-patch-cleanup-use-of-configh.patch slim-make-and-config-stuff.patch slim-make-and-config-stuff-makefile-fix.patch slim-debug-output.patch slim-fix-security-issue-with-the-task_post_setuid-hook.patch slim-secfs-inode-i_private-build-fix.patch slim-documentation.patch fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch Shall hold in -mm. Why? They're on hold awaiting further development and awaiting a merge/no-merge decision. They're not causing me any trouble. I haven't seen any evidence that prior review comments have been addressed so far, and a fresh patch set would be beneficial anyway to facilitate full review of the updated code and to allow them to fix their patch descriptions as well (as they were wrong in some instances, describing older versions of the code). If/when the developers start doing more work, we can then decide whether to use incremental patches or to take a drop-them-and-start-again approach. (If a whole new patch series comes out, I have tricks which allow me to check that none of the above fixup patches got lost. Those tricks don't work if I drop all the patches first) But yes, it has been pretty quiet. If there's no intention to proceed with these patches, someone please tell 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: -mm merge plans for 2.6.20
On Fri, 08 Dec 2006 12:32:05 -0600
Steve French [EMAIL PROTECTED] wrote:
akpm wrote:
deprecate-smbfs-in-favour-of-cifs.patch
deprecate-smbfs-in-favour-of-cifs-docs.patch
Am still waiting to hear from sfrench on the appropriateness of this.
smbfs deprecation is ok but there are a few things to consider:
OK, thanks for the update. We would like to make smbfs go away asap, but
from my POV it's up to you to say when we should do that.
otoh, it might be a good idea to merge a variant of that patch which
doesn't mention a specific data. Say,
if (warn_count 5) {
warn_count++;
printk(KERN_EMERG smbfs is not being maintained.
Please migrate to cifs\n);
}
?
...
Running simple tests on smbfs, I run into so many problems now though, it
is probably time to mark it as deprecated as Fedora etc. apparently
already have.
No, smbfs is not in very good shape.
-
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: -mm merge plans for 2.6.20
> Anyway, it seems all screwed up - I'll drop the patch. I'm working on a new patch. The build system has changed quite a bit from the last time I worked with it 2 years ago. - 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: -mm merge plans for 2.6.20
Anyway, it seems all screwed up - I'll drop the patch. I'm working on a new patch. The build system has changed quite a bit from the last time I worked with it 2 years ago. - 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: -mm merge plans for 2.6.20
On Tue, 5 Dec 2006 21:34:16 + (GMT) James Simmons <[EMAIL PROTECTED]> wrote: > Here you go. This patch places the backlight before the framebuffers. You > will now be able to select using the backlight with various framebuffer > drivers. This doesn't work right for me. x86_64 allmodconfig enables CONFIG_FB_ATY_BACKLIGHT but fails to enable FB_BACKLIGHT so things won't build. drivers/video/aty/atyfb_base.c: In function 'aty_bl_get_level_brightness': drivers/video/aty/atyfb_base.c:2130: error: 'struct fb_info' has no member named 'bl_curve' I'm not sure how to fix it, either. Are things like CONFIG_FB_ATY_BACKLIGHT _really_ supposed to be pmac-only? menuconfig says: Symbol: FB_BACKLIGHT [=FB_BACKLIGHT] Selected by: PMAC_BACKLIGHT && (PPC || MAC) && ADB_PMU && FB=y && (BROKEN || !PPC64) Surely CONFIG_FB_ATY_BACKLIGHT should depend upon FB_BACKLIGHT? How come I have CONFIG_BACKLIGHT_CLASS_DEVICE and things like that but CONFIG_FB_BACKLIGHT=n? And a `make oldconfig' says drivers/macintosh/Kconfig:126:warning: 'select' used by config symbol 'PMAC_BACKLIGHT' refer to undefined symbol 'FB_BACKLIGHT' Here's what allmodconfig gave: akpm2:/usr/src/25> grep BACKL .config CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_BACKLIGHT_DEVICE=y CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA_BACKLIGHT=y CONFIG_FB_RADEON_BACKLIGHT=y CONFIG_FB_ATY128_BACKLIGHT=y CONFIG_FB_ATY_BACKLIGHT=y Anyway, it seems all screwed up - I'll drop the patch. - 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: -mm merge plans for 2.6.20
On Thu, 07 Dec 2006 03:19:40 +0800
Conke Hu <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> > On Mon, 04 Dec 2006 23:56:42 -0500
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > > Andrew Morton wrote:
> > > > via-pata-controller-xfer-fixes.patch
> > > > via-pata-controller-xfer-fixes-fix.patch
> > >
> > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
> > > reporter as fixing things, so these two shouldn't be needed.
> >
> > OK thanks, I dropped it.
> >
> > >
> > > > libata_resume_fix.patch
> > >
> > > I thought this was resolved long ago? Are there still open reports that
> > > this solves, where upstream doesn't work?
> >
> > Heck, I don't know.
> >
> > >
> > > > ahci-ati-sb600-sata-support-for-various-modes.patch
> > >
> > > With the PCI quirk, I thought ATI was finally sorted?
> >
> > Was it? I don't know that either.
> >
> > I'll drop these too.
> > -
>
> Hi Jeff, Andrew
> The following patch is ATI's final solution. It was ACKed by Alan.
> Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
> Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)
>
>
> Best regards,
> Conke @AMD/ATI
Please send a signed-off-by: for this work, and a changelog which tells us
what it does and why the kernel needs this change.
I shall then remove the ifdef (it's __devinit, and other quirks don't do
this, and vmlinux doesn't know whether or not this driver will later be
loaded) and I shall fix up the word wrapping and I shall convert the spaces
back into tabs and I shall then send it on to Greg, thanks.
> [--PATCH--]
>
> --- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
> 19:45:49.0 +0800
> +++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
> 19:34:23.0 +0800
> @@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
>}
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
> PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
> +
> +#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
> +static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
> +{
> + /* set sb600 sata to ahci mode */
> + if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> + u8 tmp;
> +
> + pci_read_config_byte(pdev, 0x40, );
> + pci_write_config_byte(pdev, 0x40, tmp|1);
> + pci_write_config_byte(pdev, 0x9, 1);
> + pci_write_config_byte(pdev, 0xa, 6);
> + pci_write_config_byte(pdev, 0x40, tmp);
> +
> + pdev->class = 0x010601;
> + }
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
> PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
> +#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Conke Hu wrote: The following patch is ATI's final solution. It was ACKed by Alan. Jeff, you're the maintainer of libata, but this patch is based on pci/quirks.c, so I don't know who will apply this patch? You or somebody else? Andrew, could you please drop ATI's previous patch and add this one in next -mm patch? The previous patch I sent (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as this one :) I ACK'd it as well, though probably Andrew or Greg should push it. Jeff - 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: -mm merge plans for 2.6.20
On Thu, 07 Dec 2006 03:19:40 +0800 Conke Hu wrote:
> On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> > On Mon, 04 Dec 2006 23:56:42 -0500
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > > Andrew Morton wrote:
> > > > via-pata-controller-xfer-fixes.patch
> > > > via-pata-controller-xfer-fixes-fix.patch
> > >
> > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
> > > reporter as fixing things, so these two shouldn't be needed.
> >
> > OK thanks, I dropped it.
> >
> > >
> > > > libata_resume_fix.patch
> > >
> > > I thought this was resolved long ago? Are there still open reports that
> > > this solves, where upstream doesn't work?
> >
> > Heck, I don't know.
> >
> > >
> > > > ahci-ati-sb600-sata-support-for-various-modes.patch
> > >
> > > With the PCI quirk, I thought ATI was finally sorted?
> >
> > Was it? I don't know that either.
> >
> > I'll drop these too.
> > -
>
> Hi Jeff, Andrew
> The following patch is ATI's final solution. It was ACKed by Alan.
> Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
> Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)
>
>
> Best regards,
> Conke @AMD/ATI
>
>
> [--PATCH--]
>
> --- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
> 19:45:49.0 +0800
> +++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
> 19:34:23.0 +0800
> @@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
>}
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
> PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
> +
> +#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
> +static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
> +{
> + /* set sb600 sata to ahci mode */
> + if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> + u8 tmp;
> +
> + pci_read_config_byte(pdev, 0x40, );
> + pci_write_config_byte(pdev, 0x40, tmp|1);
> + pci_write_config_byte(pdev, 0x9, 1);
> + pci_write_config_byte(pdev, 0xa, 6);
> + pci_write_config_byte(pdev, 0x40, tmp);
> +
> + pdev->class = 0x010601;
> + }
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
> PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
> +#endif
>
> /*
> * As per PCI spec, ignore base address registers 0-3 of the IDE
> controllers
Can you use fewer magic numbers, please?
At least some of those are already #defined in
include/linux/pci_regs.h.
---
~Randy
-
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: -mm merge plans for 2.6.20
On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> On Mon, 04 Dec 2006 23:56:42 -0500
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton wrote:
> > > via-pata-controller-xfer-fixes.patch
> > > via-pata-controller-xfer-fixes-fix.patch
> >
> > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
> > reporter as fixing things, so these two shouldn't be needed.
>
> OK thanks, I dropped it.
>
> >
> > > libata_resume_fix.patch
> >
> > I thought this was resolved long ago? Are there still open reports that
> > this solves, where upstream doesn't work?
>
> Heck, I don't know.
>
> >
> > > ahci-ati-sb600-sata-support-for-various-modes.patch
> >
> > With the PCI quirk, I thought ATI was finally sorted?
>
> Was it? I don't know that either.
>
> I'll drop these too.
> -
Hi Jeff, Andrew
The following patch is ATI's final solution. It was ACKed by Alan.
Jeff, you're the maintainer of libata, but this patch is based on
pci/quirks.c, so I don't know who will apply this patch? You or somebody
else?
Andrew, could you please drop ATI's previous patch and add this one
in next -mm patch? The previous patch I sent
(ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
this one :)
Best regards,
Conke @AMD/ATI
[--PATCH--]
--- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
19:45:49.0 +0800
+++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
19:34:23.0 +0800
@@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
+
+#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
+static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+{
+ /* set sb600 sata to ahci mode */
+ if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
+ u8 tmp;
+
+ pci_read_config_byte(pdev, 0x40, );
+ pci_write_config_byte(pdev, 0x40, tmp|1);
+ pci_write_config_byte(pdev, 0x9, 1);
+ pci_write_config_byte(pdev, 0xa, 6);
+ pci_write_config_byte(pdev, 0x40, tmp);
+
+ pdev->class = 0x010601;
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
+#endif
/*
* As per PCI spec, ignore base address registers 0-3 of the IDE
controllers
-
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: -mm merge plans for 2.6.20
* Roman Zippel <[EMAIL PROTECTED]> wrote: > > It cannot be had both ways: either we stay simpler and less > > intrusive, or we go more generic but more intrusive. > > You miss the point, I don't care how intrusive this is, [...] we do care about how intrusive this is. I guess we'll have to agree to disagree on that. 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: -mm merge plans for 2.6.20
* Roman Zippel <[EMAIL PROTECTED]> wrote: > > > > > [...] one obvious user would be the scheduler, [...] > > > > but that is not a refutation of what Thomas said, at all. You say > > that the scheduler /could/ use such a facility. What Thomas said was > > that /there are no current users of such a facility/. It is a really > > simple (and unconditionally true) observation from Thomas. Yes, we > > could change other kernel code not directly related to high-res > > timers, but we chose not to. > > I didn't say "/could/", the scheduler _needs_ such a facility. [...] i disagree that the scheduler unconditionally 'needs' such a facility. The scheduler clock is pretty special and has other requirements and constraints than generic timekeeping clocks. It /might/ and /could/ utilize such an infrastructure, but it's not at all clear that it 'needs' such a facility. in any case, i very much entertain the possibility of more synergy in this space, but it's far from obvious and it's definitely not unconditionally 'necessary'. The scheduler and profiling code certainly worked for 15 years without such synergy. What we concentrated on in this patchset is high-resolution timers and dynticks, not scheduler or profiler clock cleanups. We cleaned up everything that we impacted directly, but we also tried to limit the scope of the changes wherever possible. 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: -mm merge plans for 2.6.20
Hi, On Wed, 6 Dec 2006, Ingo Molnar wrote: > > > > > If I understand it correctly, Roman wants clockevents to be usable > > > > > for other things aside hrtimer/dyntick, i.e. let other code request > > > > > unused timer event hardware for special purposes. I thought about > > > > > that in the originally but I stayed away from it, as there are no > > > > > users at the moment and I wanted to avoid the usual "who needs that" > > > > > comment. > > > > > > > > Nonsense, [...] > > > > > > why do you call Thomas' observation nonsense? > > > > What's the point of this question? [...] > > the point of my question was what it said: to ask you why you called > Thomas' pretty fair observation 'nonsense'. The nonsense comment was regarding the 'the usual "who needs that" comment', how is it possible that Thomas can observe something that hasn't happened yet? > > [...] Your answer is/was in the "[...]" part. > > meaning: > > > > > [...] one obvious user would be the scheduler, [...] > > but that is not a refutation of what Thomas said, at all. You say that > the scheduler /could/ use such a facility. What Thomas said was that > /there are no current users of such a facility/. It is a really simple > (and unconditionally true) observation from Thomas. Yes, we could change > other kernel code not directly related to high-res timers, but we chose > not to. I didn't say "/could/", the scheduler _needs_ such a facility. If hrtimer and scheduler have to use the same facility, they have to be coordinated somehow. The current patches don't clean up anything here and actually introduce extra complexity via the scheduler tick emulation, with little to no indication how this will be cleaned up. Others may have more faith, that it will somehow work out, but I'd like to get a bit more information beforehand. > > > Fact: there is no current user of such a facility. What we > > > implemented, high-res timers and dynticks does not need such a > > > facility. > > > > Fact: there _are_ users which need a timer facility (e.g. the > > scheduler). > > this is something we are not contesting at all: that a new timer > facility /could/ be used by /other/ kernel code, which does /not/ use it > right now. > > our point is simple: the code we add does not in itself necessiate the > new facility, hence we didnt add it. We didnt want to impact other > kernel code, just yet. We repeat: we agree (in theory) with such a > facility, but we wanted to do it separately. You don't really refute that this eventually will impact other code. The problem here is that there is pretty much no plan how this will happen. Without this information most developers cannot tell (without diving deep into these issues), how this will impact existing code (e.g. all the arch timer code) or how much more cruft this is going to add, which may have to be cleaned up later again. Maybe this code is perfect, but how is anyone going to tell? > > > we wholeheartedly agree that such a facility 'would be nice', and > > > 'could be used by existing kernel code' but we didnt want to chew > > > too much at a time. > > > > Maybe the existing code should have been cleaned up first? > > yes, we'll do that, and we have a good track record doing such cleanups. You didn't answer my question, how are you going to do this _first_? > > > > [...] one obvious user would be the scheduler, [...] > > > > > > But cleaning up the scheduler tick was not our purpose with high-res > > > timers nor with dynticks. One of your previous complaints was that the > > > patches are too intrusive to be trusted. Now they are too simple? > > > > Would you please stop these personal attacks? > > please point it out which portion of the above two sentences you > consider a personal attack - or if you cannot, please retract your > baseless accusation. Ingo, above it's you who makes a baseless accusation in the first place. Your accusation is so generic, that I have no other way than to take this personally. > Fact: you did complain in the past about the complexity and/or > intrusiveness of our high-res timers patches - we've been working on > getting high-res timers upstream for more than a year now. > > Fact: you did complain about unused facilities in past patches of ours, > and your feedback caused us significant extra work to remove those > facilities, just to reintroduce them later again. As long as you see my comments only as "complaining", I'm not really surprised we don't get nowhere... > this time around we chose the minimalistic approach, we didnt add > anything that is not immediately needed, and we didnt want to increase > intrusiveness by "cleaning up" other code and changing it over to the > new facilities. At the risk of repeating myself: Since this is very important code, it would be rather useful to know what's coming and to get to an agreement about the general direction this code is taking. This code has to cover
Re: -mm merge plans for 2.6.20
* Roman Zippel <[EMAIL PROTECTED]> wrote: > > > > If I understand it correctly, Roman wants clockevents to be usable > > > > for other things aside hrtimer/dyntick, i.e. let other code request > > > > unused timer event hardware for special purposes. I thought about > > > > that in the originally but I stayed away from it, as there are no > > > > users at the moment and I wanted to avoid the usual "who needs that" > > > > comment. > > > > > > Nonsense, [...] > > > > why do you call Thomas' observation nonsense? > > What's the point of this question? [...] the point of my question was what it said: to ask you why you called Thomas' pretty fair observation 'nonsense'. > [...] Your answer is/was in the "[...]" part. meaning: > > > [...] one obvious user would be the scheduler, [...] but that is not a refutation of what Thomas said, at all. You say that the scheduler /could/ use such a facility. What Thomas said was that /there are no current users of such a facility/. It is a really simple (and unconditionally true) observation from Thomas. Yes, we could change other kernel code not directly related to high-res timers, but we chose not to. [ The word 'nonsense' is in general a negative descriptor and implies that what Thomas said was 'obviously false' - while in reality what we have is /at most/ a difference in opinion. I.e. even if our opinion differs you shouldnt call his opinion "nonsense", unless you are willing to prove that it's false - which you didnt do so far. I claim that what Thomas said is /unconditionally true/, and i can prove it: it is unconditionally true that such a new facility is not needed by our code, and that no other kernel code is using it at the moment - because the facility does not exist yet. If you misunderstood what Thomas said then please point that out, or prove that his claims are untrue - thanks. ] > > Fact: there is no current user of such a facility. What we > > implemented, high-res timers and dynticks does not need such a > > facility. > > Fact: there _are_ users which need a timer facility (e.g. the > scheduler). this is something we are not contesting at all: that a new timer facility /could/ be used by /other/ kernel code, which does /not/ use it right now. our point is simple: the code we add does not in itself necessiate the new facility, hence we didnt add it. We didnt want to impact other kernel code, just yet. We repeat: we agree (in theory) with such a facility, but we wanted to do it separately. > > we wholeheartedly agree that such a facility 'would be nice', and > > 'could be used by existing kernel code' but we didnt want to chew > > too much at a time. > > Maybe the existing code should have been cleaned up first? yes, we'll do that, and we have a good track record doing such cleanups. > Unfortunately the dynticks feature seems to more appealing than clean > code... i think this accusation against us is very unfair. > > > [...] one obvious user would be the scheduler, [...] > > > > But cleaning up the scheduler tick was not our purpose with high-res > > timers nor with dynticks. One of your previous complaints was that the > > patches are too intrusive to be trusted. Now they are too simple? > > Would you please stop these personal attacks? please point it out which portion of the above two sentences you consider a personal attack - or if you cannot, please retract your baseless accusation. Fact: you did complain in the past about the complexity and/or intrusiveness of our high-res timers patches - we've been working on getting high-res timers upstream for more than a year now. Fact: you did complain about unused facilities in past patches of ours, and your feedback caused us significant extra work to remove those facilities, just to reintroduce them later again. (i can provide URLs and Message-IDs for these facts) this time around we chose the minimalistic approach, we didnt add anything that is not immediately needed, and we didnt want to increase intrusiveness by "cleaning up" other code and changing it over to the new facilities. It cannot be had both ways: either we stay simpler and less intrusive, or we go more generic but more intrusive. 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: -mm merge plans for 2.6.20
> > Right back from exams and with lots of spare time :) > > I got your patch, so I'm going to try your patch and exchange all the > "platform_device_*" stuff with your display class and move ks0108, > cfag12864b and cfag12864bfb to drivers/video/display/ Thanks. I will post a new patch soon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Hi, On Wed, 6 Dec 2006, Ingo Molnar wrote: > * Roman Zippel <[EMAIL PROTECTED]> wrote: > > > On Wed, 6 Dec 2006, Thomas Gleixner wrote: > > > > > If I understand it correctly, Roman wants clockevents to be usable > > > for other things aside hrtimer/dyntick, i.e. let other code request > > > unused timer event hardware for special purposes. I thought about > > > that in the originally but I stayed away from it, as there are no > > > users at the moment and I wanted to avoid the usual "who needs that" > > > comment. > > > > Nonsense, [...] > > why do you call Thomas' observation nonsense? What's the point of this question? Your answer is/was in the "[...]" part. > Fact: there is no current > user of such a facility. What we implemented, high-res timers and > dynticks does not need such a facility. Fact: there _are_ users which need a timer facility (e.g. the scheduler). > we wholeheartedly agree that such a facility 'would be nice', and 'could > be used by existing kernel code' but we didnt want to chew too much at a > time. Maybe the existing code should have been cleaned up first? Unfortunately the dynticks feature seems to more appealing than clean code... > > [...] one obvious user would be the scheduler, [...] > > But cleaning up the scheduler tick was not our purpose with high-res > timers nor with dynticks. One of your previous complaints was that the > patches are too intrusive to be trusted. Now they are too simple? Would you please stop these personal attacks? > We'll clean up the scheduler tick and profiling too, but not now. Since this is very important code, it would be rather useful to know what's coming and to get to an agreement about the general direction this code is taking. This code has to cover a wide range of applications, where as you guys are rather focused on realtime applications, which is ok, but we need to _carefully_ rethink how time is managed within the kernel, instead of randomly poking around in the kernel. > > [...] the current scheduler tick emulation is rather ugly [...] > > i disagree with you and it's pretty low-impact anyway. There's still > quite many HZ/tick assumptions all around the time code (NTP being one > example), we'll deal with those via other patches. Why do you pick on the NTP code? That's actually one of the places where assumptions about HZ are largely gone. NTP state is updated incrementally and this won't change, but the update frequency can now be easily disconnected from HZ. bye, Roman - 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: -mm merge plans for 2.6.20
* Roman Zippel <[EMAIL PROTECTED]> wrote: > On Wed, 6 Dec 2006, Thomas Gleixner wrote: > > > If I understand it correctly, Roman wants clockevents to be usable > > for other things aside hrtimer/dyntick, i.e. let other code request > > unused timer event hardware for special purposes. I thought about > > that in the originally but I stayed away from it, as there are no > > users at the moment and I wanted to avoid the usual "who needs that" > > comment. > > Nonsense, [...] why do you call Thomas' observation nonsense? Fact: there is no current user of such a facility. What we implemented, high-res timers and dynticks does not need such a facility. we wholeheartedly agree that such a facility 'would be nice', and 'could be used by existing kernel code' but we didnt want to chew too much at a time. > [...] one obvious user would be the scheduler, [...] But cleaning up the scheduler tick was not our purpose with high-res timers nor with dynticks. One of your previous complaints was that the patches are too intrusive to be trusted. Now they are too simple? We'll clean up the scheduler tick and profiling too, but not now. > [...] the current scheduler tick emulation is rather ugly [...] i disagree with you and it's pretty low-impact anyway. There's still quite many HZ/tick assumptions all around the time code (NTP being one example), we'll deal with those via other patches. 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: -mm merge plans for 2.6.20
Hi, On Wed, 6 Dec 2006, Thomas Gleixner wrote: > If I understand it correctly, Roman wants clockevents to be usable for > other things aside hrtimer/dyntick, i.e. let other code request unused > timer event hardware for special purposes. I thought about that in the > originally but I stayed away from it, as there are no users at the > moment and I wanted to avoid the usual "who needs that" comment. Nonsense, one obvious user would be the scheduler, the current scheduler tick emulation is rather ugly and sort of explains why you need the special wakeup logic I saw in previous versions. The scheduler should be completely separate from hrtimer, in the long term they might optionally not even use the same clock source (e.g. the scheduler would use a low resolution, but fast clock, while posix timer whould use the high resolution timer). bye, Roman - 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: -mm merge plans for 2.6.20
Hi, On Tue, 5 Dec 2006, Andrew Morton wrote: > > IMO it least at needs one more iteration to address the comments that > > were made (not just mine), in the short term the less it touches > > unconditionally the less I care right now. > > I don't have a clue which review comments remain unaddressed - do you recall? Outside clockevents I'd like to see at least the flag handling fixed before it gets merged. Inside clockevents I could poke around forever... > > In the long term IMO this might need a major rework, the basic problem I > > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how > > to dynamically manage multiple timer. > > I'm not sure I understand that. Are you referring to multiple, > concurrently-operating hardware clock sources? work> If so, that's more a clocksource thing than a dynticks/hrtimer thing, > isn't it? A rather simple example would be profiling, where a separate timer is useful to see stuff that runs from the main timer, which is currently invisible. It's insofar a clocksource thing as clock source and clock events should form a union, currently it's separate and that's a big problem. It's not really problem to have multiple clock sources and they don't really have to be synchronized with each other, but events _are_ connected to the source they are coming from. In the end we could even expose multiple clocks via the posix clock/timer interface, but with the current design I don't see how this is possible. bye, Roman - 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: -mm merge plans for 2.6.20
On Tue, 2006-12-05 at 20:30 -0800, Andrew Morton wrote: > I don't have a clue which review comments remain unaddressed - do you recall? > > I never saw an item-by-item accounting of my own (extensive) review > comments, actually. And then an avalanche of new stuff got sent and I > didn't have time to go through it all at the same level of detail. Arjan did a review of the replacement and I'm in the process to go through that and Romans comments again. I'll add a complete list of the review issues and the resolution state. Sorry that this was delayed, but I was busy regression testing and hunting nasty details in the last weeks. > So yeah, I don't have a lot of confidence from that POV either. But otoh, > I'm confident that Ingo and Thomas will competently and promptly address > regressions, so the risk factor isn't too bad. And changing APIC and > timekeeping code sure is risky. Timekeeping is mostly untouched and the APIC change was done to solve real world issues: - lapic verification gets stuck for ever - lapic timer runs too fast > > In the long term IMO this might need a major rework, the basic problem I > > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how > > to dynamically manage multiple timer. > > I'm not sure I understand that. Are you referring to multiple, > concurrently-operating hardware clock sources? work> If so, that's more a clocksource thing than a dynticks/hrtimer thing, > isn't it? If I understand it correctly, Roman wants clockevents to be usable for other things aside hrtimer/dyntick, i.e. let other code request unused timer event hardware for special purposes. I thought about that in the originally but I stayed away from it, as there are no users at the moment and I wanted to avoid the usual "who needs that" comment. Granted that clockevents is not perfect, but it's rather self contained and has no user space exposure, so it can be replaced by something better anytime. tglx - 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: -mm merge plans for 2.6.20
On Tue, 2006-12-05 at 20:30 -0800, Andrew Morton wrote: I don't have a clue which review comments remain unaddressed - do you recall? I never saw an item-by-item accounting of my own (extensive) review comments, actually. And then an avalanche of new stuff got sent and I didn't have time to go through it all at the same level of detail. Arjan did a review of the replacement and I'm in the process to go through that and Romans comments again. I'll add a complete list of the review issues and the resolution state. Sorry that this was delayed, but I was busy regression testing and hunting nasty details in the last weeks. So yeah, I don't have a lot of confidence from that POV either. But otoh, I'm confident that Ingo and Thomas will competently and promptly address regressions, so the risk factor isn't too bad. And changing APIC and timekeeping code sure is risky. Timekeeping is mostly untouched and the APIC change was done to solve real world issues: - lapic verification gets stuck for ever - lapic timer runs too fast In the long term IMO this might need a major rework, the basic problem I have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how to dynamically manage multiple timer. I'm not sure I understand that. Are you referring to multiple, concurrently-operating hardware clock sources? wonders how that could work If so, that's more a clocksource thing than a dynticks/hrtimer thing, isn't it? If I understand it correctly, Roman wants clockevents to be usable for other things aside hrtimer/dyntick, i.e. let other code request unused timer event hardware for special purposes. I thought about that in the originally but I stayed away from it, as there are no users at the moment and I wanted to avoid the usual who needs that comment. Granted that clockevents is not perfect, but it's rather self contained and has no user space exposure, so it can be replaced by something better anytime. tglx - 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: -mm merge plans for 2.6.20
Hi, On Tue, 5 Dec 2006, Andrew Morton wrote: IMO it least at needs one more iteration to address the comments that were made (not just mine), in the short term the less it touches unconditionally the less I care right now. I don't have a clue which review comments remain unaddressed - do you recall? Outside clockevents I'd like to see at least the flag handling fixed before it gets merged. Inside clockevents I could poke around forever... In the long term IMO this might need a major rework, the basic problem I have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how to dynamically manage multiple timer. I'm not sure I understand that. Are you referring to multiple, concurrently-operating hardware clock sources? wonders how that could work If so, that's more a clocksource thing than a dynticks/hrtimer thing, isn't it? A rather simple example would be profiling, where a separate timer is useful to see stuff that runs from the main timer, which is currently invisible. It's insofar a clocksource thing as clock source and clock events should form a union, currently it's separate and that's a big problem. It's not really problem to have multiple clock sources and they don't really have to be synchronized with each other, but events _are_ connected to the source they are coming from. In the end we could even expose multiple clocks via the posix clock/timer interface, but with the current design I don't see how this is possible. bye, Roman - 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: -mm merge plans for 2.6.20
Hi, On Wed, 6 Dec 2006, Thomas Gleixner wrote: If I understand it correctly, Roman wants clockevents to be usable for other things aside hrtimer/dyntick, i.e. let other code request unused timer event hardware for special purposes. I thought about that in the originally but I stayed away from it, as there are no users at the moment and I wanted to avoid the usual who needs that comment. Nonsense, one obvious user would be the scheduler, the current scheduler tick emulation is rather ugly and sort of explains why you need the special wakeup logic I saw in previous versions. The scheduler should be completely separate from hrtimer, in the long term they might optionally not even use the same clock source (e.g. the scheduler would use a low resolution, but fast clock, while posix timer whould use the high resolution timer). bye, Roman - 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: -mm merge plans for 2.6.20
* Roman Zippel [EMAIL PROTECTED] wrote: On Wed, 6 Dec 2006, Thomas Gleixner wrote: If I understand it correctly, Roman wants clockevents to be usable for other things aside hrtimer/dyntick, i.e. let other code request unused timer event hardware for special purposes. I thought about that in the originally but I stayed away from it, as there are no users at the moment and I wanted to avoid the usual who needs that comment. Nonsense, [...] why do you call Thomas' observation nonsense? Fact: there is no current user of such a facility. What we implemented, high-res timers and dynticks does not need such a facility. we wholeheartedly agree that such a facility 'would be nice', and 'could be used by existing kernel code' but we didnt want to chew too much at a time. [...] one obvious user would be the scheduler, [...] But cleaning up the scheduler tick was not our purpose with high-res timers nor with dynticks. One of your previous complaints was that the patches are too intrusive to be trusted. Now they are too simple? We'll clean up the scheduler tick and profiling too, but not now. [...] the current scheduler tick emulation is rather ugly [...] i disagree with you and it's pretty low-impact anyway. There's still quite many HZ/tick assumptions all around the time code (NTP being one example), we'll deal with those via other patches. 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: -mm merge plans for 2.6.20
Hi, On Wed, 6 Dec 2006, Ingo Molnar wrote: * Roman Zippel [EMAIL PROTECTED] wrote: On Wed, 6 Dec 2006, Thomas Gleixner wrote: If I understand it correctly, Roman wants clockevents to be usable for other things aside hrtimer/dyntick, i.e. let other code request unused timer event hardware for special purposes. I thought about that in the originally but I stayed away from it, as there are no users at the moment and I wanted to avoid the usual who needs that comment. Nonsense, [...] why do you call Thomas' observation nonsense? What's the point of this question? Your answer is/was in the [...] part. Fact: there is no current user of such a facility. What we implemented, high-res timers and dynticks does not need such a facility. Fact: there _are_ users which need a timer facility (e.g. the scheduler). we wholeheartedly agree that such a facility 'would be nice', and 'could be used by existing kernel code' but we didnt want to chew too much at a time. Maybe the existing code should have been cleaned up first? Unfortunately the dynticks feature seems to more appealing than clean code... [...] one obvious user would be the scheduler, [...] But cleaning up the scheduler tick was not our purpose with high-res timers nor with dynticks. One of your previous complaints was that the patches are too intrusive to be trusted. Now they are too simple? Would you please stop these personal attacks? We'll clean up the scheduler tick and profiling too, but not now. Since this is very important code, it would be rather useful to know what's coming and to get to an agreement about the general direction this code is taking. This code has to cover a wide range of applications, where as you guys are rather focused on realtime applications, which is ok, but we need to _carefully_ rethink how time is managed within the kernel, instead of randomly poking around in the kernel. [...] the current scheduler tick emulation is rather ugly [...] i disagree with you and it's pretty low-impact anyway. There's still quite many HZ/tick assumptions all around the time code (NTP being one example), we'll deal with those via other patches. Why do you pick on the NTP code? That's actually one of the places where assumptions about HZ are largely gone. NTP state is updated incrementally and this won't change, but the update frequency can now be easily disconnected from HZ. bye, Roman - 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: -mm merge plans for 2.6.20
Right back from exams and with lots of spare time :) I got your patch, so I'm going to try your patch and exchange all the platform_device_* stuff with your display class and move ks0108, cfag12864b and cfag12864bfb to drivers/video/display/ Thanks. I will post a new patch soon. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
* Roman Zippel [EMAIL PROTECTED] wrote: If I understand it correctly, Roman wants clockevents to be usable for other things aside hrtimer/dyntick, i.e. let other code request unused timer event hardware for special purposes. I thought about that in the originally but I stayed away from it, as there are no users at the moment and I wanted to avoid the usual who needs that comment. Nonsense, [...] why do you call Thomas' observation nonsense? What's the point of this question? [...] the point of my question was what it said: to ask you why you called Thomas' pretty fair observation 'nonsense'. [...] Your answer is/was in the [...] part. meaning: [...] one obvious user would be the scheduler, [...] but that is not a refutation of what Thomas said, at all. You say that the scheduler /could/ use such a facility. What Thomas said was that /there are no current users of such a facility/. It is a really simple (and unconditionally true) observation from Thomas. Yes, we could change other kernel code not directly related to high-res timers, but we chose not to. [ The word 'nonsense' is in general a negative descriptor and implies that what Thomas said was 'obviously false' - while in reality what we have is /at most/ a difference in opinion. I.e. even if our opinion differs you shouldnt call his opinion nonsense, unless you are willing to prove that it's false - which you didnt do so far. I claim that what Thomas said is /unconditionally true/, and i can prove it: it is unconditionally true that such a new facility is not needed by our code, and that no other kernel code is using it at the moment - because the facility does not exist yet. If you misunderstood what Thomas said then please point that out, or prove that his claims are untrue - thanks. ] Fact: there is no current user of such a facility. What we implemented, high-res timers and dynticks does not need such a facility. Fact: there _are_ users which need a timer facility (e.g. the scheduler). this is something we are not contesting at all: that a new timer facility /could/ be used by /other/ kernel code, which does /not/ use it right now. our point is simple: the code we add does not in itself necessiate the new facility, hence we didnt add it. We didnt want to impact other kernel code, just yet. We repeat: we agree (in theory) with such a facility, but we wanted to do it separately. we wholeheartedly agree that such a facility 'would be nice', and 'could be used by existing kernel code' but we didnt want to chew too much at a time. Maybe the existing code should have been cleaned up first? yes, we'll do that, and we have a good track record doing such cleanups. Unfortunately the dynticks feature seems to more appealing than clean code... i think this accusation against us is very unfair. [...] one obvious user would be the scheduler, [...] But cleaning up the scheduler tick was not our purpose with high-res timers nor with dynticks. One of your previous complaints was that the patches are too intrusive to be trusted. Now they are too simple? Would you please stop these personal attacks? please point it out which portion of the above two sentences you consider a personal attack - or if you cannot, please retract your baseless accusation. Fact: you did complain in the past about the complexity and/or intrusiveness of our high-res timers patches - we've been working on getting high-res timers upstream for more than a year now. Fact: you did complain about unused facilities in past patches of ours, and your feedback caused us significant extra work to remove those facilities, just to reintroduce them later again. (i can provide URLs and Message-IDs for these facts) this time around we chose the minimalistic approach, we didnt add anything that is not immediately needed, and we didnt want to increase intrusiveness by cleaning up other code and changing it over to the new facilities. It cannot be had both ways: either we stay simpler and less intrusive, or we go more generic but more intrusive. 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: -mm merge plans for 2.6.20
Hi, On Wed, 6 Dec 2006, Ingo Molnar wrote: If I understand it correctly, Roman wants clockevents to be usable for other things aside hrtimer/dyntick, i.e. let other code request unused timer event hardware for special purposes. I thought about that in the originally but I stayed away from it, as there are no users at the moment and I wanted to avoid the usual who needs that comment. Nonsense, [...] why do you call Thomas' observation nonsense? What's the point of this question? [...] the point of my question was what it said: to ask you why you called Thomas' pretty fair observation 'nonsense'. The nonsense comment was regarding the 'the usual who needs that comment', how is it possible that Thomas can observe something that hasn't happened yet? [...] Your answer is/was in the [...] part. meaning: [...] one obvious user would be the scheduler, [...] but that is not a refutation of what Thomas said, at all. You say that the scheduler /could/ use such a facility. What Thomas said was that /there are no current users of such a facility/. It is a really simple (and unconditionally true) observation from Thomas. Yes, we could change other kernel code not directly related to high-res timers, but we chose not to. I didn't say /could/, the scheduler _needs_ such a facility. If hrtimer and scheduler have to use the same facility, they have to be coordinated somehow. The current patches don't clean up anything here and actually introduce extra complexity via the scheduler tick emulation, with little to no indication how this will be cleaned up. Others may have more faith, that it will somehow work out, but I'd like to get a bit more information beforehand. Fact: there is no current user of such a facility. What we implemented, high-res timers and dynticks does not need such a facility. Fact: there _are_ users which need a timer facility (e.g. the scheduler). this is something we are not contesting at all: that a new timer facility /could/ be used by /other/ kernel code, which does /not/ use it right now. our point is simple: the code we add does not in itself necessiate the new facility, hence we didnt add it. We didnt want to impact other kernel code, just yet. We repeat: we agree (in theory) with such a facility, but we wanted to do it separately. You don't really refute that this eventually will impact other code. The problem here is that there is pretty much no plan how this will happen. Without this information most developers cannot tell (without diving deep into these issues), how this will impact existing code (e.g. all the arch timer code) or how much more cruft this is going to add, which may have to be cleaned up later again. Maybe this code is perfect, but how is anyone going to tell? we wholeheartedly agree that such a facility 'would be nice', and 'could be used by existing kernel code' but we didnt want to chew too much at a time. Maybe the existing code should have been cleaned up first? yes, we'll do that, and we have a good track record doing such cleanups. You didn't answer my question, how are you going to do this _first_? [...] one obvious user would be the scheduler, [...] But cleaning up the scheduler tick was not our purpose with high-res timers nor with dynticks. One of your previous complaints was that the patches are too intrusive to be trusted. Now they are too simple? Would you please stop these personal attacks? please point it out which portion of the above two sentences you consider a personal attack - or if you cannot, please retract your baseless accusation. Ingo, above it's you who makes a baseless accusation in the first place. Your accusation is so generic, that I have no other way than to take this personally. Fact: you did complain in the past about the complexity and/or intrusiveness of our high-res timers patches - we've been working on getting high-res timers upstream for more than a year now. Fact: you did complain about unused facilities in past patches of ours, and your feedback caused us significant extra work to remove those facilities, just to reintroduce them later again. As long as you see my comments only as complaining, I'm not really surprised we don't get nowhere... this time around we chose the minimalistic approach, we didnt add anything that is not immediately needed, and we didnt want to increase intrusiveness by cleaning up other code and changing it over to the new facilities. At the risk of repeating myself: Since this is very important code, it would be rather useful to know what's coming and to get to an agreement about the general direction this code is taking. This code has to cover a wide range of applications, where as you guys are rather focused on realtime applications, which is ok, but we need to _carefully_ rethink how time is
Re: -mm merge plans for 2.6.20
* Roman Zippel [EMAIL PROTECTED] wrote: [...] one obvious user would be the scheduler, [...] but that is not a refutation of what Thomas said, at all. You say that the scheduler /could/ use such a facility. What Thomas said was that /there are no current users of such a facility/. It is a really simple (and unconditionally true) observation from Thomas. Yes, we could change other kernel code not directly related to high-res timers, but we chose not to. I didn't say /could/, the scheduler _needs_ such a facility. [...] i disagree that the scheduler unconditionally 'needs' such a facility. The scheduler clock is pretty special and has other requirements and constraints than generic timekeeping clocks. It /might/ and /could/ utilize such an infrastructure, but it's not at all clear that it 'needs' such a facility. in any case, i very much entertain the possibility of more synergy in this space, but it's far from obvious and it's definitely not unconditionally 'necessary'. The scheduler and profiling code certainly worked for 15 years without such synergy. What we concentrated on in this patchset is high-resolution timers and dynticks, not scheduler or profiler clock cleanups. We cleaned up everything that we impacted directly, but we also tried to limit the scope of the changes wherever possible. 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: -mm merge plans for 2.6.20
* Roman Zippel [EMAIL PROTECTED] wrote: It cannot be had both ways: either we stay simpler and less intrusive, or we go more generic but more intrusive. You miss the point, I don't care how intrusive this is, [...] we do care about how intrusive this is. I guess we'll have to agree to disagree on that. 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: -mm merge plans for 2.6.20
On Tue, 5 Dec 2006 21:34:16 + (GMT) James Simmons [EMAIL PROTECTED] wrote: Here you go. This patch places the backlight before the framebuffers. You will now be able to select using the backlight with various framebuffer drivers. This doesn't work right for me. x86_64 allmodconfig enables CONFIG_FB_ATY_BACKLIGHT but fails to enable FB_BACKLIGHT so things won't build. drivers/video/aty/atyfb_base.c: In function 'aty_bl_get_level_brightness': drivers/video/aty/atyfb_base.c:2130: error: 'struct fb_info' has no member named 'bl_curve' I'm not sure how to fix it, either. Are things like CONFIG_FB_ATY_BACKLIGHT _really_ supposed to be pmac-only? menuconfig says: Symbol: FB_BACKLIGHT [=FB_BACKLIGHT] Selected by: PMAC_BACKLIGHT (PPC || MAC) ADB_PMU FB=y (BROKEN || !PPC64) Surely CONFIG_FB_ATY_BACKLIGHT should depend upon FB_BACKLIGHT? How come I have CONFIG_BACKLIGHT_CLASS_DEVICE and things like that but CONFIG_FB_BACKLIGHT=n? And a `make oldconfig' says drivers/macintosh/Kconfig:126:warning: 'select' used by config symbol 'PMAC_BACKLIGHT' refer to undefined symbol 'FB_BACKLIGHT' Here's what allmodconfig gave: akpm2:/usr/src/25 grep BACKL .config CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_BACKLIGHT_DEVICE=y CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA_BACKLIGHT=y CONFIG_FB_RADEON_BACKLIGHT=y CONFIG_FB_ATY128_BACKLIGHT=y CONFIG_FB_ATY_BACKLIGHT=y Anyway, it seems all screwed up - I'll drop the patch. - 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: -mm merge plans for 2.6.20
On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
On Mon, 04 Dec 2006 23:56:42 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
via-pata-controller-xfer-fixes.patch
via-pata-controller-xfer-fixes-fix.patch
Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
reporter as fixing things, so these two shouldn't be needed.
OK thanks, I dropped it.
libata_resume_fix.patch
I thought this was resolved long ago? Are there still open reports that
this solves, where upstream doesn't work?
Heck, I don't know.
ahci-ati-sb600-sata-support-for-various-modes.patch
With the PCI quirk, I thought ATI was finally sorted?
Was it? I don't know that either.
I'll drop these too.
-
Hi Jeff, Andrew
The following patch is ATI's final solution. It was ACKed by Alan.
Jeff, you're the maintainer of libata, but this patch is based on
pci/quirks.c, so I don't know who will apply this patch? You or somebody
else?
Andrew, could you please drop ATI's previous patch and add this one
in next -mm patch? The previous patch I sent
(ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
this one :)
Best regards,
Conke @AMD/ATI
[--PATCH--]
--- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
19:45:49.0 +0800
+++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
19:34:23.0 +0800
@@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
+
+#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
+static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+{
+ /* set sb600 sata to ahci mode */
+ if ((pdev-class 8) == PCI_CLASS_STORAGE_IDE) {
+ u8 tmp;
+
+ pci_read_config_byte(pdev, 0x40, tmp);
+ pci_write_config_byte(pdev, 0x40, tmp|1);
+ pci_write_config_byte(pdev, 0x9, 1);
+ pci_write_config_byte(pdev, 0xa, 6);
+ pci_write_config_byte(pdev, 0x40, tmp);
+
+ pdev-class = 0x010601;
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
+#endif
/*
* As per PCI spec, ignore base address registers 0-3 of the IDE
controllers
-
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: -mm merge plans for 2.6.20
On Thu, 07 Dec 2006 03:19:40 +0800 Conke Hu wrote:
On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
On Mon, 04 Dec 2006 23:56:42 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
via-pata-controller-xfer-fixes.patch
via-pata-controller-xfer-fixes-fix.patch
Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
reporter as fixing things, so these two shouldn't be needed.
OK thanks, I dropped it.
libata_resume_fix.patch
I thought this was resolved long ago? Are there still open reports that
this solves, where upstream doesn't work?
Heck, I don't know.
ahci-ati-sb600-sata-support-for-various-modes.patch
With the PCI quirk, I thought ATI was finally sorted?
Was it? I don't know that either.
I'll drop these too.
-
Hi Jeff, Andrew
The following patch is ATI's final solution. It was ACKed by Alan.
Jeff, you're the maintainer of libata, but this patch is based on
pci/quirks.c, so I don't know who will apply this patch? You or somebody
else?
Andrew, could you please drop ATI's previous patch and add this one
in next -mm patch? The previous patch I sent
(ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
this one :)
Best regards,
Conke @AMD/ATI
[--PATCH--]
--- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
19:45:49.0 +0800
+++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
19:34:23.0 +0800
@@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
+
+#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
+static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+{
+ /* set sb600 sata to ahci mode */
+ if ((pdev-class 8) == PCI_CLASS_STORAGE_IDE) {
+ u8 tmp;
+
+ pci_read_config_byte(pdev, 0x40, tmp);
+ pci_write_config_byte(pdev, 0x40, tmp|1);
+ pci_write_config_byte(pdev, 0x9, 1);
+ pci_write_config_byte(pdev, 0xa, 6);
+ pci_write_config_byte(pdev, 0x40, tmp);
+
+ pdev-class = 0x010601;
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
+#endif
/*
* As per PCI spec, ignore base address registers 0-3 of the IDE
controllers
Can you use fewer magic numbers, please?
At least some of those are already #defined in
include/linux/pci_regs.h.
---
~Randy
-
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: -mm merge plans for 2.6.20
Conke Hu wrote: The following patch is ATI's final solution. It was ACKed by Alan. Jeff, you're the maintainer of libata, but this patch is based on pci/quirks.c, so I don't know who will apply this patch? You or somebody else? Andrew, could you please drop ATI's previous patch and add this one in next -mm patch? The previous patch I sent (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as this one :) I ACK'd it as well, though probably Andrew or Greg should push it. Jeff - 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: -mm merge plans for 2.6.20
On Thu, 07 Dec 2006 03:19:40 +0800
Conke Hu [EMAIL PROTECTED] wrote:
On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
On Mon, 04 Dec 2006 23:56:42 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
via-pata-controller-xfer-fixes.patch
via-pata-controller-xfer-fixes-fix.patch
Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
reporter as fixing things, so these two shouldn't be needed.
OK thanks, I dropped it.
libata_resume_fix.patch
I thought this was resolved long ago? Are there still open reports that
this solves, where upstream doesn't work?
Heck, I don't know.
ahci-ati-sb600-sata-support-for-various-modes.patch
With the PCI quirk, I thought ATI was finally sorted?
Was it? I don't know that either.
I'll drop these too.
-
Hi Jeff, Andrew
The following patch is ATI's final solution. It was ACKed by Alan.
Jeff, you're the maintainer of libata, but this patch is based on
pci/quirks.c, so I don't know who will apply this patch? You or somebody
else?
Andrew, could you please drop ATI's previous patch and add this one
in next -mm patch? The previous patch I sent
(ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
this one :)
Best regards,
Conke @AMD/ATI
Please send a signed-off-by: for this work, and a changelog which tells us
what it does and why the kernel needs this change.
I shall then remove the ifdef (it's __devinit, and other quirks don't do
this, and vmlinux doesn't know whether or not this driver will later be
loaded) and I shall fix up the word wrapping and I shall convert the spaces
back into tabs and I shall then send it on to Greg, thanks.
[--PATCH--]
--- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
19:45:49.0 +0800
+++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
19:34:23.0 +0800
@@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
+
+#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
+static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+{
+ /* set sb600 sata to ahci mode */
+ if ((pdev-class 8) == PCI_CLASS_STORAGE_IDE) {
+ u8 tmp;
+
+ pci_read_config_byte(pdev, 0x40, tmp);
+ pci_write_config_byte(pdev, 0x40, tmp|1);
+ pci_write_config_byte(pdev, 0x9, 1);
+ pci_write_config_byte(pdev, 0xa, 6);
+ pci_write_config_byte(pdev, 0x40, tmp);
+
+ pdev-class = 0x010601;
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
+#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Hi, On Tue, 05 Dec 2006, Roman Zippel wrote: > On Mon, 4 Dec 2006, Andrew Morton wrote: > > kbuild-dont-put-temp-files-in-the-source-tree.patch > > actually-delete-the-as-instr-ld-option-tmp-file.patch > > Andi had objections about the mktemp usage and I agree with him. > The proposed patch in bugzilla didn't have this and no further > justification was given for why it's needed. > Below is a replacement patch with some improvements: > - kbuild doesn't use $(AS), so use $(CC) > - tmp dir needs only to be calculated once > - reformat a bit to keep it under 80 columns and to be more readable > > bye, Roman > > Signed-off-by: Roman Zippel <[EMAIL PROTECTED]> This patch looks good to me, and I'd prefer it over the (twice corrected) one currently in -mm. - It's close to what Daniel Drake proposed recently [1] (main difference: corrects the very same problem for ld-option, which might otherwise bite us later) and what's already in Gentoo's patchkernel, - it abstains from using mktemp, hopefully making Andi happy ;), - resolves the current Gentoo sandbox issues without touching more kbuild code than necessary. Kind regards, Horst [1]Message-Id: <[EMAIL PROTECTED]> -- PGP-Key 0xD40E0E7A signature.asc Description: Digital signature
Re: -mm merge plans for 2.6.20
> On Wed, 6 Dec 2006 03:59:41 +0100 (CET) Roman Zippel <[EMAIL PROTECTED]> > wrote: > Hi, > > On Mon, 4 Dec 2006, Andrew Morton wrote: > > > [dyntick] > > > > Shall merge, I guess. My confidence is low, but it's Kconfigurable and it > > needs to get sorted out. > > IMO it least at needs one more iteration to address the comments that > were made (not just mine), in the short term the less it touches > unconditionally the less I care right now. I don't have a clue which review comments remain unaddressed - do you recall? I never saw an item-by-item accounting of my own (extensive) review comments, actually. And then an avalanche of new stuff got sent and I didn't have time to go through it all at the same level of detail. So yeah, I don't have a lot of confidence from that POV either. But otoh, I'm confident that Ingo and Thomas will competently and promptly address regressions, so the risk factor isn't too bad. And changing APIC and timekeeping code sure is risky. Yes, I too am wobbly about a 2.6.20 merge. But otoh I doubt if much will get changed if it sits in -mm for another two months. As long as it's heading in the right direction and doesn't break things when it is configged-off then OK. > In the long term IMO this might need a major rework, the basic problem I > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how > to dynamically manage multiple timer. I'm not sure I understand that. Are you referring to multiple, concurrently-operating hardware clock sources? If so, that's more a clocksource thing than a dynticks/hrtimer thing, isn't it? - 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: -mm merge plans for 2.6.20
Hi, On Mon, 4 Dec 2006, Andrew Morton wrote: > [dyntick] > > Shall merge, I guess. My confidence is low, but it's Kconfigurable and it > needs to get sorted out. IMO it least at needs one more iteration to address the comments that were made (not just mine), in the short term the less it touches unconditionally the less I care right now. In the long term IMO this might need a major rework, the basic problem I have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how to dynamically manage multiple timer. bye, Roman - 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: -mm merge plans for 2.6.20
On Wed, 6 Dec 2006 00:55:29 +0100 Alessandro Guido <[EMAIL PROTECTED]> wrote: > Sorry, I didn't find in your list the patches regarding the sony_acpi > driver that were present in 2.6.19-rc6-mm2. I'm talking about: > > 2.6-sony_acpi4.patch > sony_apci-resume.patch > acpi-add-backlight-support-to-the-sony_acpi.patch > acpi-add-backlight-support-to-the-sony_acpi-v2.patch > > What is the future of these? > I spose I need to talk Len into merging the sony-acpi driver. Before that I need to work out why /sys/class/backlight/sony/brightness magically vanished on me after a suspend-to-ram operation. - 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: -mm merge plans for 2.6.20
Sorry, I didn't find in your list the patches regarding the sony_acpi driver that were present in 2.6.19-rc6-mm2. I'm talking about: 2.6-sony_acpi4.patch sony_apci-resume.patch acpi-add-backlight-support-to-the-sony_acpi.patch acpi-add-backlight-support-to-the-sony_acpi-v2.patch What is the future of these? Thanks. Alessandro - 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: -mm merge plans for 2.6.20, scheduler bits
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote: > On Tue, Dec 05, 2006 at 10:17:23PM +0100, Ingo Molnar wrote: > > > sched-decrease-number-of-load-balances.patch > > > > this one goes away as per Ken's observation. > > Not really. Ken posted a cleanup patch on top of the above patch. Ken > pointed one more cleanup which I will work on it and send it across in > a day. ok. 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: -mm merge plans for 2.6.20
> > Ug. Kconfig in drivers/video has all the above drivers enable the > > backlight only if PMAC_BACKLIGHT is set. > > erp, I grepped for CONFIG_foo and not foo. Again. > > > The problem is backlight > > is after the framebuffer. We should move the backlight menu before > > the framebuffer configuration. > > OK. Can you do a patch sometime please? Here you go. This patch places the backlight before the framebuffers. You will now be able to select using the backlight with various framebuffer drivers. Signed-off: James Simmons <[EMAIL PROTECTED]> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 7a43020..40f6bea 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -4,20 +4,9 @@ menu "Graphics support" -config FIRMWARE_EDID - bool "Enable firmware EDID" - default y - ---help--- - This enables access to the EDID transferred from the firmware. -On the i386, this is from the Video BIOS. Enable this if DDC/I2C -transfers do not work for your driver and if you are using -nvidiafb, i810fb or savagefb. - -In general, choosing Y for this option is safe. If you -experience extremely long delays while booting before you get -something on your display, try setting this to N. Matrox cards in -combination with certain motherboards and monitors are known to -suffer from this problem. +if SYSFS + source "drivers/video/backlight/Kconfig" +endif config FB tristate "Support for frame buffer devices" @@ -53,6 +42,22 @@ config FB (e.g. an accelerated X server) and that are not frame buffer device-aware may cause unexpected results. If unsure, say N. +config FIRMWARE_EDID + bool "Enable firmware EDID" + depends on FB + default n + ---help--- + This enables access to the EDID transferred from the firmware. +On the i386, this is from the Video BIOS. Enable this if DDC/I2C +transfers do not work for your driver and if you are using +nvidiafb, i810fb or savagefb. + +In general, choosing Y for this option is safe. If you +experience extremely long delays while booting before you get +something on your display, try setting this to N. Matrox cards in +combination with certain motherboards and monitors are known to +suffer from this problem. + config FB_DDC tristate depends on FB && I2C && I2C_ALGOBIT @@ -90,13 +95,6 @@ config FB_MACMODES depends on FB default n -config FB_BACKLIGHT - bool - depends on FB - select BACKLIGHT_LCD_SUPPORT - select BACKLIGHT_CLASS_DEVICE - default n - config FB_MODE_HELPERS bool "Enable Video Mode Handling Helpers" depends on FB @@ -126,6 +124,9 @@ config FB_TILEBLITTING This is particularly important to one driver, matroxfb. If unsure, say N. +comment "Frambuffer hardware drivers" + depends on FB + config FB_CIRRUS tristate "Cirrus Logic support" depends on FB && (ZORRO || PCI) @@ -728,8 +729,7 @@ config FB_NVIDIA_I2C config FB_NVIDIA_BACKLIGHT bool "Support for backlight control" - depends on FB_NVIDIA && PMAC_BACKLIGHT - select FB_BACKLIGHT + depends on FB_NVIDIA && BACKLIGHT_CLASS_DEVICE default y help Say Y here if you want to control the backlight of your display. @@ -775,8 +775,7 @@ config FB_RIVA_DEBUG config FB_RIVA_BACKLIGHT bool "Support for backlight control" - depends on FB_RIVA && PMAC_BACKLIGHT - select FB_BACKLIGHT + depends on FB_RIVA && BACKLIGHT_CLASS_DEVICE default y help Say Y here if you want to control the backlight of your display. @@ -1049,8 +1048,7 @@ config FB_RADEON_I2C config FB_RADEON_BACKLIGHT bool "Support for backlight control" - depends on FB_RADEON && PMAC_BACKLIGHT - select FB_BACKLIGHT + depends on FB_RADEON && BACKLIGHT_CLASS_DEVICE default y help Say Y here if you want to control the backlight of your display. @@ -1081,8 +1079,7 @@ config FB_ATY128 config FB_ATY128_BACKLIGHT bool "Support for backlight control" - depends on FB_ATY128 && PMAC_BACKLIGHT - select FB_BACKLIGHT + depends on FB_ATY128 && BACKLIGHT_CLASS_DEVICE default y help Say Y here if you want to control the backlight of your display. @@ -1131,8 +1128,7 @@ config FB_ATY_GX config FB_ATY_BACKLIGHT bool "Support for backlight control" - depends on FB_ATY && PMAC_BACKLIGHT - select FB_BACKLIGHT + depends on FB_ATY && BACKLIGHT_CLASS_DEVICE default y help Say Y here if you want to control the backlight of your display. @@ -1632,6 +1628,7 @@ config FB_VIRTUAL the vfb_enable=1 option. If unsure, say N. + if VT
Re: -mm merge plans for 2.6.20, scheduler bits
On 12/5/06, Ingo Molnar <[EMAIL PROTECTED]> wrote: > kernel-schedc-whitespace-cleanups.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> i dont like these: - cost1 += measure_one(cache, size - i*1024, cpu1, cpu2); + cost1 += measure_one(cache, size - i * 1024, cpu1, cpu2); as it's quite OK to have no spaces in "i*1024", just to indicate precedence of arithmetic ops. But the good bits dominate in this patch so lets have it and i'll undo the bad ones. Ok, I will take care of that for future whitespace cleanups, as I see they are welcome :) -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm - 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: -mm merge plans for 2.6.20, scheduler bits
On Tue, Dec 05, 2006 at 10:17:23PM +0100, Ingo Molnar wrote: > > sched-decrease-number-of-load-balances.patch > > this one goes away as per Ken's observation. Not really. Ken posted a cleanup patch on top of the above patch. Ken pointed one more cleanup which I will work on it and send it across in a day. 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/
Re: -mm merge plans for 2.6.20, scheduler bits
* Andrew Morton <[EMAIL PROTECTED]> wrote: > schedc-correct-comment-for-this_rq_lock-routine.patch > sched-fix-migration-cost-estimator.patch > sched-domain-move-sched-group-allocations-to-percpu-area.patch (already acked) > move_task_off_dead_cpu-should-be-called-with-disabled-ints.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-domain-increase-the-smt-busy-rebalance-interval.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-avoid-taking-rq-lock-in-wake_priority_sleeper.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-remove-staggering-of-load-balancing.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-disable-interrupts-for-locking-in-load_balance.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-extract-load-calculation-from-rebalance_tick.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-move-idle-status-calculation-into-rebalance_tick.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-use-softirq-for-load-balancing.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-call-tasklet-less-frequently.patch patch is misnamed, otherwise: Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-add-option-to-serialize-load-balancing.patch > sched-add-option-to-serialize-load-balancing-fix.patch (please merge these two patches into one, the first one is not bisectable.) Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-improve-migration-accuracy.patch > sched-improve-migration-accuracy-tidy.patch > sched-improve-migration-accuracy-fix.patch please merge into one patch. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > sched-decrease-number-of-load-balances.patch this one goes away as per Ken's observation. > sched-optimize-activate_task-for-rt-task.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > kernel-schedc-whitespace-cleanups.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> i dont like these: - cost1 += measure_one(cache, size - i*1024, cpu1, cpu2); + cost1 += measure_one(cache, size - i * 1024, cpu1, cpu2); as it's quite OK to have no spaces in "i*1024", just to indicate precedence of arithmetic ops. But the good bits dominate in this patch so lets have it and i'll undo the bad ones. > kernel-schedc-whitespace-cleanups-more.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> 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: -mm merge plans for 2.6.20
* Andrew Morton <[EMAIL PROTECTED]> wrote: > gtod-exponential-update_wall_time.patch > > Roman wanted this dropped, and afaik that's unresolved. please drop this one for now, we'll rework it. It's an optimization, not a showstopper must-have component. 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: -mm merge plans for 2.6.20
On 12/5/06, James Simmons <[EMAIL PROTECTED]> wrote: > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > > > Does this patch update the fbdev drivers? > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > Seems not. Should it? Yes. Its bizarre. The drivers compile with the wrong method prototype. I updated the fbdev drivers to the new backlight_device_register and it compiled as expect. There are a few other problems with teh fbdev drivers. I will send a patch. > > > add-display-output-class-support.patch > > > add-output-class-document.patch > > > drivers-add-lcd-support-3.patch > > > drivers-add-lcd-support-3-Kconfig-fix.patch > > > drivers-add-lcd-support-update-4.patch > > > drivers-add-lcd-support-update-5.patch > > > drivers-add-lcd-support-update6.patch > > > drivers-add-lcd-support-update-7.patch > > > drivers-add-lcd-support-update-8.patch > > > > Ug. We have alot of interfaces attempting to do the same thing. We also > > have the lcd class_dev in drivers/video/backlight. I did some work which I > > will post to interested parties in the hopes of getting one interface to > > make everyone happy. > > Well can you please work out what we should do with Miguel? I sent a email already. The details will be hammered out. Right back from exams and with lots of spare time :) I got your patch, so I'm going to try your patch and exchange all the "platform_device_*" stuff with your display class and move ks0108, cfag12864b and cfag12864bfb to drivers/video/display/ -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm - 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: -mm merge plans for 2.6.20
On Tue, 5 Dec 2006 19:59:01 + (GMT) James Simmons <[EMAIL PROTECTED]> wrote: > > > > > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > > > > > > > > > Does this patch update the fbdev drivers? > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > > > > > > > Seems not. Should it? > > > > > > Yes. Its bizarre. > > > > It is. > > > > > The drivers compile with the wrong method prototype. > > > > No, it doesn't get compiled at all. > > > > CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all. > > > > CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all. > > > > CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all. > > > > So this is all dead code. There is no way to enable any of it within the > > config system. > > Ug. Kconfig in drivers/video has all the above drivers enable the > backlight only if PMAC_BACKLIGHT is set. erp, I grepped for CONFIG_foo and not foo. Again. > The problem is backlight > is after the framebuffer. We should move the backlight menu before > the framebuffer configuration. OK. Can you do a patch sometime please? - 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: -mm merge plans for 2.6.20
> > > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > > > > > > > Does this patch update the fbdev drivers? > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > > > > > Seems not. Should it? > > > > Yes. Its bizarre. > > It is. > > > The drivers compile with the wrong method prototype. > > No, it doesn't get compiled at all. > > CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all. > > CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all. > > CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all. > > So this is all dead code. There is no way to enable any of it within the > config system. Ug. Kconfig in drivers/video has all the above drivers enable the backlight only if PMAC_BACKLIGHT is set. The problem is backlight is after the framebuffer. We should move the backlight menu before the framebuffer configuration. - 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: -mm merge plans for 2.6.20
On Tue, 5 Dec 2006 18:25:58 + (GMT) James Simmons <[EMAIL PROTECTED]> wrote: > > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > > > > > Does this patch update the fbdev drivers? > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > > > Seems not. Should it? > > Yes. Its bizarre. It is. > The drivers compile with the wrong method prototype. No, it doesn't get compiled at all. CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all. CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all. CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all. So this is all dead code. There is no way to enable any of it within the config system. > I > updated the fbdev drivers to the new backlight_device_register and it > compiled as expect. There are a few other problems with teh fbdev drivers. > I will send a patch. It's a start ;) - 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: -mm merge plans for 2.6.20
On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote: ... > fsstack-introduce-fsstack_copy_attrinode_.patch > fsstack-introduce-fsstack_copy_attrinode_-tidy.patch > fsstack-introduce-fsstack_copy_attrinode_-fs-stackc-should-include-linux-fs_stackh.patch > ecryptfs-use-fsstacks-generic-copy-inode-attr.patch > ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix.patch > ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix-fix.patch > struct-path-rename-reiserfss-struct-path.patch > struct-path-rename-dms-struct-path.patch > struct-path-move-struct-path-from-fs-nameic-into.patch > struct-path-make-ecryptfs-a-user-of-struct-path.patch > vfs-change-struct-file-to-use-struct-path.patch ... > > Shall merge. I guess. Doesn't seem very useful. I have two more fixes for fsstack/ecryptfs. I'll send them as a reply to this email... Josef "Jeff" Sipek. -- FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #19 A: To be or not to be. Q: What is the square root of 4b^2? - 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: -mm merge plans for 2.6.20
> > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > > > Does this patch update the fbdev drivers? > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > Seems not. Should it? Yes. Its bizarre. The drivers compile with the wrong method prototype. I updated the fbdev drivers to the new backlight_device_register and it compiled as expect. There are a few other problems with teh fbdev drivers. I will send a patch. > > > add-display-output-class-support.patch > > > add-output-class-document.patch > > > drivers-add-lcd-support-3.patch > > > drivers-add-lcd-support-3-Kconfig-fix.patch > > > drivers-add-lcd-support-update-4.patch > > > drivers-add-lcd-support-update-5.patch > > > drivers-add-lcd-support-update6.patch > > > drivers-add-lcd-support-update-7.patch > > > drivers-add-lcd-support-update-8.patch > > > > Ug. We have alot of interfaces attempting to do the same thing. We also > > have the lcd class_dev in drivers/video/backlight. I did some work which I > > will post to interested parties in the hopes of getting one interface to > > make everyone happy. > > Well can you please work out what we should do with Miguel? I sent a email already. The details will be hammered out. - 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: -mm merge plans for 2.6.20
On Tue, 5 Dec 2006 17:35:20 + (GMT) James Simmons <[EMAIL PROTECTED]> wrote: > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch > > Does this patch update the fbdev drivers? ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch Seems not. Should it? > > add-display-output-class-support.patch > > add-output-class-document.patch > > drivers-add-lcd-support-3.patch > > drivers-add-lcd-support-3-Kconfig-fix.patch > > drivers-add-lcd-support-update-4.patch > > drivers-add-lcd-support-update-5.patch > > drivers-add-lcd-support-update6.patch > > drivers-add-lcd-support-update-7.patch > > drivers-add-lcd-support-update-8.patch > > Ug. We have alot of interfaces attempting to do the same thing. We also > have the lcd class_dev in drivers/video/backlight. I did some work which I > will post to interested parties in the hopes of getting one interface to > make everyone happy. Well can you please work out what we should do with Miguel? - 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: -mm merge plans for 2.6.20
> video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch Does this patch update the fbdev drivers? > add-display-output-class-support.patch > add-output-class-document.patch > drivers-add-lcd-support-3.patch > drivers-add-lcd-support-3-Kconfig-fix.patch > drivers-add-lcd-support-update-4.patch > drivers-add-lcd-support-update-5.patch > drivers-add-lcd-support-update6.patch > drivers-add-lcd-support-update-7.patch > drivers-add-lcd-support-update-8.patch Ug. We have alot of interfaces attempting to do the same thing. We also have the lcd class_dev in drivers/video/backlight. I did some work which I will post to interested parties in the hopes of getting one interface to make everyone happy. - 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: -mm merge plans for 2.6.20
On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote: > cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch > remove-hotplug-cpu-crap-from-cpufreq.patch > cpufreq-select-consistently-re-2619-rc5-mm1.patch > cpufreq-set-policy-curfreq-on-initialization.patch > bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch > > Sent to cpufreq maintainer I'm travelling right now, and somehow managed to oops my home router 3000 miles away making it hard for me to access mail & stuff. (That "page count went negative" BUG() bit me when I did a killall -9 vpnc) Full bug report, and processing of this backlog will happen as soon as I get back on Sunday :) 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: -mm merge plans for 2.6.20
Andrew Morton wrote: On Mon, 04 Dec 2006 23:56:42 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Andrew Morton wrote: libata_resume_fix.patch I thought this was resolved long ago? Are there still open reports that this solves, where upstream doesn't work? Heck, I don't know. You probably pinched it from my website originally, and I nabbed it from an LKML posting 18 months ago. It's a patch that was required here back in the 2.6.12 - 2.6.16 era, and it is no longer needed now. Drop it. - 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: -mm merge plans for 2.6.20
Hi, On Mon, 4 Dec 2006, Andrew Morton wrote: > kbuild-dont-put-temp-files-in-the-source-tree.patch > actually-delete-the-as-instr-ld-option-tmp-file.patch Andi had objections about the mktemp usage and I agree with him. The proposed patch in bugzilla didn't have this and no further justification was given for why it's needed. Below is a replacement patch with some improvements: - kbuild doesn't use $(AS), so use $(CC) - tmp dir needs only to be calculated once - reformat a bit to keep it under 80 columns and to be more readable bye, Roman Signed-off-by: Roman Zippel <[EMAIL PROTECTED]> --- scripts/Kbuild.include | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) Index: linux-2.6-git/scripts/Kbuild.include === --- linux-2.6-git.orig/scripts/Kbuild.include 2006-12-05 13:44:50.0 +0100 +++ linux-2.6-git/scripts/Kbuild.include2006-12-05 15:09:09.0 +0100 @@ -56,6 +56,9 @@ endef # gcc support functions # See documentation in Documentation/kbuild/makefiles.txt +# output directory for tests below +TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/) + # as-option # Usage: cflags-y += $(call as-option, -Wa$(comma)-isa=foo,) @@ -66,9 +69,11 @@ as-option = $(shell if $(CC) $(CFLAGS) $ # as-instr # Usage: cflags-y += $(call as-instr, instr, option1, option2) -as-instr = $(shell if echo -e "$(1)" | $(AS) >/dev/null 2>&1 -W -Z -o astest.out ; \ - then echo "$(2)"; else echo "$(3)"; fi; \ - rm -f astest.out) +as-instr = $(shell if echo -e "$(1)" | \ + $(CC) $(AFLAGS) -c -xassembler - \ + -o $(TMPOUT)astest.out > /dev/null 2>&1; \ + then rm $(TMPOUT)astest.out; echo "$(2)"; \ + else echo "$(3)"; fi) # cc-option # Usage: cflags-y += $(call cc-option, -march=winchip-c6, -march=i586) @@ -97,10 +102,10 @@ cc-ifversion = $(shell if [ $(call cc-ve # ld-option # Usage: ldflags += $(call ld-option, -Wl$(comma)--hash-style=both) -ld-option = $(shell if $(CC) $(1) \ --nostdlib -o ldtest.out -xc /dev/null \ - > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi; \ -rm -f ldtest.out) +ld-option = $(shell if $(CC) $(1) -nostdlib -xc /dev/null \ +-o $(TMPOUT)ldtest.out > /dev/null 2>&1; \ + then rm $(TMPOUT)ldtest.out; echo "$(1)"; \ + else echo "$(2)"; fi) ### # Shorthand for $(Q)$(MAKE) -f scripts/Makefile.build obj= - 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: -mm merge plans for 2.6.20
On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote: > hostap-replace-kmallocmemset-with-kzalloc.patch > prism54-replace-kmallocmemset-with-kzalloc.patch > ipw2200-replace-kmallocmemset-with-kcalloc.patch > softmac-fix-unbalanced-mutex_lock-unlock-in-ieee80211softmac_wx_set_mlme.patch > > Not sent to John - I forgot. I've got them, and I plan to merge them. Thanks, John -- John W. Linville [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/
ext2 future [was Re: -mm merge plans for 2.6.20]
Hi! > ext2-reservations.patch > ext2-fix-reservation-extension.patch > make-ext2_get_blocks-static.patch > ext2-balloc-fix-_with_rsv-freeze.patch > ext2-balloc-reset-windowsz-when-full.patch > ext2-balloc-fix-off-by-one-against-rsv_end.patch > ext2-balloc-fix-off-by-one-against-grp_goal.patch > ext2-balloc-say-rb_entry-not-list_entry.patch > ext2-balloc-use-io_error-label.patch > > Not for 2.6.20. In fact it's unclear whether this should ever be merged - > ext2 is more an "example filesytem" nowadays. We'll see. If ext2 is "example filesystem"... perhaps we should add "no journal" mode to ext3 or something? We still want high-performance, not-journalled filesystem, I believe. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: -mm merge plans for 2.6.20
> mm-call-into-direct-reclaim-without-pf_memalloc-set.patch > mm-cleanup-and-document-reclaim-recursion.patch Drop these, I'm not sure of them anymore. And I am starting to grow a nagging feeling they are wrong. - 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: -mm merge plans for 2.6.20
Hi Andrew, > remove-hotplug-cpu-crap-from-cpufreq.patch > > Sent to cpufreq maintainer I suspect that Davej posted this patch because he was getting lockdep warnings-reports from people complaining of ondemand-governor performing spurious unlock_cpu_hotplug. That problem has been fixed in the mainline by the commit http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4b96b1a10cb00c867103b21f0f2a6c91b705db11 If there are any other issues with cpufreq-cpuhotplug in the mainline, I'm more than willing to help out fix them. As of now, I cannot seem to spot anything serious in the mainline as such. Hence, merging this isn't an immediate need IMHO. > hotplug-cpu-clean-up-hotcpu_notifier-use.patch > hotplug-cpu-clean-up-hotcpu_notifier-use-vs-gregkh-driver-cpu-topology-consider-sysfs_create_group-return-value.patch > > extend-notifier_call_chain-to-count-nr_calls-made.patch > extend-notifier_call_chain-to-count-nr_calls-made-fixes.patch > extend-notifier_call_chain-to-count-nr_calls-made-fixes-2.patch > define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release.patch > define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release-fix.patch > eliminate-lock_cpu_hotplug-in-kernel-schedc.patch > eliminate-lock_cpu_hotplug-in-kernel-schedc-fix.patch > handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch > > Shall merge. > Merging this would still give the circular-locking dependency warnings which I posted the other day. Unless we have a clean way to get cpu-hotplug-protection for cpufreq, I don't see a point in merging this stuff. Cpufreq hotplug-interactions can be sorted out. I have a few patches which I need to test out before posting them. Other than that, there are issues regarding the workqueue-hotplug-"locking" which needs to be addressed, probably in a seperate thread. So could you please reconsider this decision to merge the hotplug-locking rework, and let it stabilize in -mm for sometime ? Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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: -mm merge plans for 2.6.20
Andrew Morton wrote: On Mon, 04 Dec 2006 23:56:42 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: Andrew Morton wrote: libata_resume_fix.patch I thought this was resolved long ago? Are there still open reports that this solves, where upstream doesn't work? Heck, I don't know. You probably pinched it from my website originally, and I nabbed it from an LKML posting 18 months ago. It's a patch that was required here back in the 2.6.12 - 2.6.16 era, and it is no longer needed now. Drop it. - 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: -mm merge plans for 2.6.20
Sorry, I didn't find in your list the patches regarding the sony_acpi driver that were present in 2.6.19-rc6-mm2. I'm talking about: 2.6-sony_acpi4.patch sony_apci-resume.patch acpi-add-backlight-support-to-the-sony_acpi.patch acpi-add-backlight-support-to-the-sony_acpi-v2.patch What is the future of these? Thanks. Alessandro - 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: -mm merge plans for 2.6.20
On Wed, 6 Dec 2006 00:55:29 +0100 Alessandro Guido [EMAIL PROTECTED] wrote: Sorry, I didn't find in your list the patches regarding the sony_acpi driver that were present in 2.6.19-rc6-mm2. I'm talking about: 2.6-sony_acpi4.patch sony_apci-resume.patch acpi-add-backlight-support-to-the-sony_acpi.patch acpi-add-backlight-support-to-the-sony_acpi-v2.patch What is the future of these? I spose I need to talk Len into merging the sony-acpi driver. Before that I need to work out why /sys/class/backlight/sony/brightness magically vanished on me after a suspend-to-ram operation. - 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: -mm merge plans for 2.6.20
Hi, On Mon, 4 Dec 2006, Andrew Morton wrote: [dyntick] Shall merge, I guess. My confidence is low, but it's Kconfigurable and it needs to get sorted out. IMO it least at needs one more iteration to address the comments that were made (not just mine), in the short term the less it touches unconditionally the less I care right now. In the long term IMO this might need a major rework, the basic problem I have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how to dynamically manage multiple timer. bye, Roman - 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: -mm merge plans for 2.6.20
On Wed, 6 Dec 2006 03:59:41 +0100 (CET) Roman Zippel [EMAIL PROTECTED] wrote: Hi, On Mon, 4 Dec 2006, Andrew Morton wrote: [dyntick] Shall merge, I guess. My confidence is low, but it's Kconfigurable and it needs to get sorted out. IMO it least at needs one more iteration to address the comments that were made (not just mine), in the short term the less it touches unconditionally the less I care right now. I don't have a clue which review comments remain unaddressed - do you recall? I never saw an item-by-item accounting of my own (extensive) review comments, actually. And then an avalanche of new stuff got sent and I didn't have time to go through it all at the same level of detail. So yeah, I don't have a lot of confidence from that POV either. But otoh, I'm confident that Ingo and Thomas will competently and promptly address regressions, so the risk factor isn't too bad. And changing APIC and timekeeping code sure is risky. Yes, I too am wobbly about a 2.6.20 merge. But otoh I doubt if much will get changed if it sits in -mm for another two months. As long as it's heading in the right direction and doesn't break things when it is configged-off then OK. In the long term IMO this might need a major rework, the basic problem I have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how to dynamically manage multiple timer. I'm not sure I understand that. Are you referring to multiple, concurrently-operating hardware clock sources? wonders how that could work If so, that's more a clocksource thing than a dynticks/hrtimer thing, isn't it? - 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: -mm merge plans for 2.6.20
Hi, On Tue, 05 Dec 2006, Roman Zippel wrote: On Mon, 4 Dec 2006, Andrew Morton wrote: kbuild-dont-put-temp-files-in-the-source-tree.patch actually-delete-the-as-instr-ld-option-tmp-file.patch Andi had objections about the mktemp usage and I agree with him. The proposed patch in bugzilla didn't have this and no further justification was given for why it's needed. Below is a replacement patch with some improvements: - kbuild doesn't use $(AS), so use $(CC) - tmp dir needs only to be calculated once - reformat a bit to keep it under 80 columns and to be more readable bye, Roman Signed-off-by: Roman Zippel [EMAIL PROTECTED] This patch looks good to me, and I'd prefer it over the (twice corrected) one currently in -mm. - It's close to what Daniel Drake proposed recently [1] (main difference: corrects the very same problem for ld-option, which might otherwise bite us later) and what's already in Gentoo's patchkernel, - it abstains from using mktemp, hopefully making Andi happy ;), - resolves the current Gentoo sandbox issues without touching more kbuild code than necessary. Kind regards, Horst [1]Message-Id: [EMAIL PROTECTED] -- PGP-Key 0xD40E0E7A signature.asc Description: Digital signature
Re: -mm merge plans for 2.6.20
Hi Andrew, remove-hotplug-cpu-crap-from-cpufreq.patch Sent to cpufreq maintainer I suspect that Davej posted this patch because he was getting lockdep warnings-reports from people complaining of ondemand-governor performing spurious unlock_cpu_hotplug. That problem has been fixed in the mainline by the commit http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4b96b1a10cb00c867103b21f0f2a6c91b705db11 If there are any other issues with cpufreq-cpuhotplug in the mainline, I'm more than willing to help out fix them. As of now, I cannot seem to spot anything serious in the mainline as such. Hence, merging this isn't an immediate need IMHO. hotplug-cpu-clean-up-hotcpu_notifier-use.patch hotplug-cpu-clean-up-hotcpu_notifier-use-vs-gregkh-driver-cpu-topology-consider-sysfs_create_group-return-value.patch extend-notifier_call_chain-to-count-nr_calls-made.patch extend-notifier_call_chain-to-count-nr_calls-made-fixes.patch extend-notifier_call_chain-to-count-nr_calls-made-fixes-2.patch define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release.patch define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release-fix.patch eliminate-lock_cpu_hotplug-in-kernel-schedc.patch eliminate-lock_cpu_hotplug-in-kernel-schedc-fix.patch handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch Shall merge. Merging this would still give the circular-locking dependency warnings which I posted the other day. Unless we have a clean way to get cpu-hotplug-protection for cpufreq, I don't see a point in merging this stuff. Cpufreq hotplug-interactions can be sorted out. I have a few patches which I need to test out before posting them. Other than that, there are issues regarding the workqueue-hotplug-locking which needs to be addressed, probably in a seperate thread. So could you please reconsider this decision to merge the hotplug-locking rework, and let it stabilize in -mm for sometime ? Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless! - 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: -mm merge plans for 2.6.20
mm-call-into-direct-reclaim-without-pf_memalloc-set.patch mm-cleanup-and-document-reclaim-recursion.patch Drop these, I'm not sure of them anymore. And I am starting to grow a nagging feeling they are wrong. - 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/
ext2 future [was Re: -mm merge plans for 2.6.20]
Hi! ext2-reservations.patch ext2-fix-reservation-extension.patch make-ext2_get_blocks-static.patch ext2-balloc-fix-_with_rsv-freeze.patch ext2-balloc-reset-windowsz-when-full.patch ext2-balloc-fix-off-by-one-against-rsv_end.patch ext2-balloc-fix-off-by-one-against-grp_goal.patch ext2-balloc-say-rb_entry-not-list_entry.patch ext2-balloc-use-io_error-label.patch Not for 2.6.20. In fact it's unclear whether this should ever be merged - ext2 is more an example filesytem nowadays. We'll see. If ext2 is example filesystem... perhaps we should add no journal mode to ext3 or something? We still want high-performance, not-journalled filesystem, I believe. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: -mm merge plans for 2.6.20
On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote: hostap-replace-kmallocmemset-with-kzalloc.patch prism54-replace-kmallocmemset-with-kzalloc.patch ipw2200-replace-kmallocmemset-with-kcalloc.patch softmac-fix-unbalanced-mutex_lock-unlock-in-ieee80211softmac_wx_set_mlme.patch Not sent to John - I forgot. I've got them, and I plan to merge them. Thanks, John -- John W. Linville [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: -mm merge plans for 2.6.20
Hi, On Mon, 4 Dec 2006, Andrew Morton wrote: kbuild-dont-put-temp-files-in-the-source-tree.patch actually-delete-the-as-instr-ld-option-tmp-file.patch Andi had objections about the mktemp usage and I agree with him. The proposed patch in bugzilla didn't have this and no further justification was given for why it's needed. Below is a replacement patch with some improvements: - kbuild doesn't use $(AS), so use $(CC) - tmp dir needs only to be calculated once - reformat a bit to keep it under 80 columns and to be more readable bye, Roman Signed-off-by: Roman Zippel [EMAIL PROTECTED] --- scripts/Kbuild.include | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) Index: linux-2.6-git/scripts/Kbuild.include === --- linux-2.6-git.orig/scripts/Kbuild.include 2006-12-05 13:44:50.0 +0100 +++ linux-2.6-git/scripts/Kbuild.include2006-12-05 15:09:09.0 +0100 @@ -56,6 +56,9 @@ endef # gcc support functions # See documentation in Documentation/kbuild/makefiles.txt +# output directory for tests below +TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/) + # as-option # Usage: cflags-y += $(call as-option, -Wa$(comma)-isa=foo,) @@ -66,9 +69,11 @@ as-option = $(shell if $(CC) $(CFLAGS) $ # as-instr # Usage: cflags-y += $(call as-instr, instr, option1, option2) -as-instr = $(shell if echo -e $(1) | $(AS) /dev/null 21 -W -Z -o astest.out ; \ - then echo $(2); else echo $(3); fi; \ - rm -f astest.out) +as-instr = $(shell if echo -e $(1) | \ + $(CC) $(AFLAGS) -c -xassembler - \ + -o $(TMPOUT)astest.out /dev/null 21; \ + then rm $(TMPOUT)astest.out; echo $(2); \ + else echo $(3); fi) # cc-option # Usage: cflags-y += $(call cc-option, -march=winchip-c6, -march=i586) @@ -97,10 +102,10 @@ cc-ifversion = $(shell if [ $(call cc-ve # ld-option # Usage: ldflags += $(call ld-option, -Wl$(comma)--hash-style=both) -ld-option = $(shell if $(CC) $(1) \ --nostdlib -o ldtest.out -xc /dev/null \ - /dev/null 21; then echo $(1); else echo $(2); fi; \ -rm -f ldtest.out) +ld-option = $(shell if $(CC) $(1) -nostdlib -xc /dev/null \ +-o $(TMPOUT)ldtest.out /dev/null 21; \ + then rm $(TMPOUT)ldtest.out; echo $(1); \ + else echo $(2); fi) ### # Shorthand for $(Q)$(MAKE) -f scripts/Makefile.build obj= - 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: -mm merge plans for 2.6.20
On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote: cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch remove-hotplug-cpu-crap-from-cpufreq.patch cpufreq-select-consistently-re-2619-rc5-mm1.patch cpufreq-set-policy-curfreq-on-initialization.patch bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch Sent to cpufreq maintainer I'm travelling right now, and somehow managed to oops my home router 3000 miles away making it hard for me to access mail stuff. (That page count went negative BUG() bit me when I did a killall -9 vpnc) Full bug report, and processing of this backlog will happen as soon as I get back on Sunday :) 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: -mm merge plans for 2.6.20
video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch Does this patch update the fbdev drivers? add-display-output-class-support.patch add-output-class-document.patch drivers-add-lcd-support-3.patch drivers-add-lcd-support-3-Kconfig-fix.patch drivers-add-lcd-support-update-4.patch drivers-add-lcd-support-update-5.patch drivers-add-lcd-support-update6.patch drivers-add-lcd-support-update-7.patch drivers-add-lcd-support-update-8.patch Ug. We have alot of interfaces attempting to do the same thing. We also have the lcd class_dev in drivers/video/backlight. I did some work which I will post to interested parties in the hopes of getting one interface to make everyone happy. - 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: -mm merge plans for 2.6.20
On Tue, 5 Dec 2006 17:35:20 + (GMT) James Simmons [EMAIL PROTECTED] wrote: video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch Does this patch update the fbdev drivers? ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch Seems not. Should it? add-display-output-class-support.patch add-output-class-document.patch drivers-add-lcd-support-3.patch drivers-add-lcd-support-3-Kconfig-fix.patch drivers-add-lcd-support-update-4.patch drivers-add-lcd-support-update-5.patch drivers-add-lcd-support-update6.patch drivers-add-lcd-support-update-7.patch drivers-add-lcd-support-update-8.patch Ug. We have alot of interfaces attempting to do the same thing. We also have the lcd class_dev in drivers/video/backlight. I did some work which I will post to interested parties in the hopes of getting one interface to make everyone happy. Well can you please work out what we should do with Miguel? - 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: -mm merge plans for 2.6.20
video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch Does this patch update the fbdev drivers? ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch Seems not. Should it? Yes. Its bizarre. The drivers compile with the wrong method prototype. I updated the fbdev drivers to the new backlight_device_register and it compiled as expect. There are a few other problems with teh fbdev drivers. I will send a patch. add-display-output-class-support.patch add-output-class-document.patch drivers-add-lcd-support-3.patch drivers-add-lcd-support-3-Kconfig-fix.patch drivers-add-lcd-support-update-4.patch drivers-add-lcd-support-update-5.patch drivers-add-lcd-support-update6.patch drivers-add-lcd-support-update-7.patch drivers-add-lcd-support-update-8.patch Ug. We have alot of interfaces attempting to do the same thing. We also have the lcd class_dev in drivers/video/backlight. I did some work which I will post to interested parties in the hopes of getting one interface to make everyone happy. Well can you please work out what we should do with Miguel? I sent a email already. The details will be hammered out. - 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: -mm merge plans for 2.6.20
On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote: ... fsstack-introduce-fsstack_copy_attrinode_.patch fsstack-introduce-fsstack_copy_attrinode_-tidy.patch fsstack-introduce-fsstack_copy_attrinode_-fs-stackc-should-include-linux-fs_stackh.patch ecryptfs-use-fsstacks-generic-copy-inode-attr.patch ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix.patch ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix-fix.patch struct-path-rename-reiserfss-struct-path.patch struct-path-rename-dms-struct-path.patch struct-path-move-struct-path-from-fs-nameic-into.patch struct-path-make-ecryptfs-a-user-of-struct-path.patch vfs-change-struct-file-to-use-struct-path.patch ... Shall merge. I guess. Doesn't seem very useful. I have two more fixes for fsstack/ecryptfs. I'll send them as a reply to this email... Josef Jeff Sipek. -- FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #19 A: To be or not to be. Q: What is the square root of 4b^2? - 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/
