Re: what does "busses" (drivers/i2c/busses) mean?
On Mon, 2007-02-05 at 08:17 -0800, Randy Dunlap wrote: > On Mon, 5 Feb 2007 14:23:35 +0800 Conke Hu wrote: > > > what does the directory name drivers/i2c/busses mean? did it mean bus(es)? > > "busses" is an acceptable spelling of "buses" in some places, > so Yes, I believe that it means "bus(es)". > > or is your question more than that? > > --- > ~Randy Thank you, Randy I look up in www.stardict.org which tells me the word "buss" means "kiss", so i was confused :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][0/5] floppy.c: first round of cleanup patches - the simple stuff
On Tuesday 06 February 2007 00:28, Jesper Juhl wrote: > Greetings people, > > Here is, as promised, the first round of cleanup patches for floppy.c > (more will follow later). I think the real problem with floppy.c is the basic code logic, not the coding style. While cleaning the later up is nice, I'm afraid it doesn't really help all that much because that code has to be replaced anyways. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/3] 2.6.20 fix for PageUptodate memorder problem
Still no independent confirmation as to whether this is a problem or not. I think it is, so I'll propose this patchset to fix it. Patch 1/3 has a reasonable description of the problem. Thanks, Nick -- SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/3] mm: fix PageUptodate memorder
After running SetPageUptodate, preceeding stores to the page contents to
actually bring it uptodate may not be ordered with the store to set the page
uptodate.
Therefore, another CPU which checks PageUptodate is true, then reads the
page contents can get stale data.
Fix this by ensuring SetPageUptodate is always called with the page locked
(except in the case of a new page that cannot be visible to other CPUs), and
requiring PageUptodate be checked only when the page is locked.
To facilitate lockless checks, SetPageUptodate contains an smp_wmb to order
preceeding stores before the store to page flags, and a new PageUptodate_NoLock
is introduced, which issues a smp_rmb after the page flags are loaded for the
test.
I'm still not sure that a DMA memory barrier is not required, however I think
the logical place to put such a barrier would be in the IO completion routines,
when they come back to tell us that they have succeeded. (Help? Anyone?)
One thing I like about it is that it unifies the anonymous page handling
with the rest of the page management, by marking anon pages as uptodate
when they _are_ uptodate, rather than when our implementation requires
that they be marked as such. Doing this let me get rid of the smp_wmb's
in the page copying functions, which were specially added for anonymous
pages for a closely related issue, always vaguely troubled me.
Convert core code and some filesystems to use PageUptodate_NoLock, just for
reference (a more complete patch follows).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/include/linux/highmem.h
===
--- linux-2.6.orig/include/linux/highmem.h
+++ linux-2.6/include/linux/highmem.h
@@ -57,8 +57,6 @@ static inline void clear_user_highpage(s
void *addr = kmap_atomic(page, KM_USER0);
clear_user_page(addr, vaddr, page);
kunmap_atomic(addr, KM_USER0);
- /* Make sure this page is cleared on other CPU's too before using it */
- smp_wmb();
}
#ifndef __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
@@ -108,8 +106,6 @@ static inline void copy_user_highpage(st
copy_user_page(vto, vfrom, vaddr, to);
kunmap_atomic(vfrom, KM_USER0);
kunmap_atomic(vto, KM_USER1);
- /* Make sure this page is cleared on other CPU's too before using it */
- smp_wmb();
}
#endif
Index: linux-2.6/include/linux/page-flags.h
===
--- linux-2.6.orig/include/linux/page-flags.h
+++ linux-2.6/include/linux/page-flags.h
@@ -126,16 +126,62 @@
#define ClearPageReferenced(page) clear_bit(PG_referenced, &(page)->flags)
#define TestClearPageReferenced(page) test_and_clear_bit(PG_referenced,
&(page)->flags)
-#define PageUptodate(page) test_bit(PG_uptodate, &(page)->flags)
-#ifdef CONFIG_S390
-static inline void SetPageUptodate(struct page *page)
+static inline int PageUptodate(struct page *page)
+{
+ WARN_ON(!PageLocked(page));
+ return test_bit(PG_uptodate, &(page)->flags);
+}
+
+/*
+ * PageUptodate to be used when not holding the page lock.
+ */
+static inline int PageUptodate_NoLock(struct page *page)
{
+ int ret = test_bit(PG_uptodate, &(page)->flags);
+
+ /*
+* Must ensure that the data we read out of the page is loaded
+* _after_ we've loaded page->flags to check for PageUptodate.
+* See SetPageUptodate() for the other side of the story.
+*/
+ smp_rmb();
+
+ return ret;
+}
+
+static inline void __SetPageUptodate(struct page *page)
+{
+#ifdef CONFIG_S390
if (!test_and_set_bit(PG_uptodate, &page->flags))
page_test_and_clear_dirty(page);
-}
#else
-#define SetPageUptodate(page) set_bit(PG_uptodate, &(page)->flags)
+ /*
+* Memory barrier must be issued before setting the PG_uptodate bit,
+* so all previous writes that served to bring the page uptodate are
+* visible before PageUptodate becomes true.
+*
+* S390 is guaranteed to have a barrier in the test_and_set operation
+* (see Documentation/atomic_ops.txt).
+*
+* XXX: does this memory barrier need to be anything special to
+* handle things like DMA writes into the page?
+*/
+ smp_wmb();
+ set_bit(PG_uptodate, &(page)->flags);
#endif
+}
+
+static inline void SetPageUptodate(struct page *page)
+{
+ WARN_ON(!PageLocked(page));
+ __SetPageUptodate(page);
+}
+
+static inline void SetNewPageUptodate(struct page *page)
+{
+ __SetPageUptodate(page);
+}
+
#define ClearPageUptodate(page)clear_bit(PG_uptodate, &(page)->flags)
#define PageDirty(page)test_bit(PG_dirty, &(page)->flags)
Index: linux-2.6/mm/hugetlb.c
===
--- linux-2.6.orig/mm/hugetlb.c
+++ linux-2.6/mm/hugetlb.c
@@ -443,6 +443,7 @@ static int hugetlb_cow(struct mm_struct
[patch 2/3] fs: buffer don't PageUptodate without page locked
__block_write_full_page is calling SetPageUptodate without the page locked.
This is unusual, but not incorrect, as PG_writeback is still set.
However with the previous patch, this is now a problem: so don't bother
setting the page uptodate in this case (it is weird that the write path
does such a thing anyway). Instead just leave it to the read side to bring
the page uptodate when it notices that all buffers are uptodate.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/buffer.c
===
--- linux-2.6.orig/fs/buffer.c
+++ linux-2.6/fs/buffer.c
@@ -1679,6 +1679,7 @@ static int __block_write_full_page(struc
*/
BUG_ON(PageWriteback(page));
set_page_writeback(page);
+ unlock_page(page);
do {
struct buffer_head *next = bh->b_this_page;
@@ -1688,7 +1689,6 @@ static int __block_write_full_page(struc
}
bh = next;
} while (bh != head);
- unlock_page(page);
err = 0;
done:
@@ -1698,17 +1698,8 @@ done:
* clean. Someone wrote them back by hand with
* ll_rw_block/submit_bh. A rare case.
*/
- int uptodate = 1;
- do {
- if (!buffer_uptodate(bh)) {
- uptodate = 0;
- break;
- }
- bh = bh->b_this_page;
- } while (bh != head);
- if (uptodate)
- SetPageUptodate(page);
end_page_writeback(page);
+
/*
* The page and buffer_heads can be released at any time from
* here on.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 3/3] mm: make read_cache_page synchronous
Ensure pages are uptodate after returning from read_cache_page, which allows
us to cut out most of the filesystem-internal PageUptodate_NoLock calls.
I didn't have a great look down the call chains, but this appears to fixes 7
possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in ecryptfs,
1 in jffs2, and a possible cleared data overwritten with readpage in block2mtd.
All depending on whether the filler is async and/or can return with a !uptodate
page.
Also, a memory leak in sys_swapon().
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/afs/dir.c
===
--- linux-2.6.orig/fs/afs/dir.c
+++ linux-2.6/fs/afs/dir.c
@@ -187,10 +187,7 @@ static struct page *afs_dir_get_page(str
page = read_mapping_page(dir->i_mapping, index, NULL);
if (!IS_ERR(page)) {
- wait_on_page_locked(page);
kmap(page);
- if (!PageUptodate(page))
- goto fail;
if (!PageChecked(page))
afs_dir_check_page(dir, page);
if (PageError(page))
Index: linux-2.6/fs/afs/mntpt.c
===
--- linux-2.6.orig/fs/afs/mntpt.c
+++ linux-2.6/fs/afs/mntpt.c
@@ -77,13 +77,11 @@ int afs_mntpt_check_symlink(struct afs_v
}
ret = -EIO;
- wait_on_page_locked(page);
- buf = kmap(page);
- if (!PageUptodate(page))
- goto out_free;
if (PageError(page))
goto out_free;
+ buf = kmap(page);
+
/* examine the symlink's contents */
size = vnode->status.size;
_debug("symlink to %*.*s", size, (int) size, buf);
@@ -100,8 +98,8 @@ int afs_mntpt_check_symlink(struct afs_v
ret = 0;
- out_free:
kunmap(page);
+ out_free:
page_cache_release(page);
out:
_leave(" = %d", ret);
@@ -184,8 +182,7 @@ static struct vfsmount *afs_mntpt_do_aut
}
ret = -EIO;
- wait_on_page_locked(page);
- if (!PageUptodate(page) || PageError(page))
+ if (PageError(page))
goto error;
buf = kmap(page);
Index: linux-2.6/fs/cramfs/inode.c
===
--- linux-2.6.orig/fs/cramfs/inode.c
+++ linux-2.6/fs/cramfs/inode.c
@@ -180,7 +180,8 @@ static void *cramfs_read(struct super_bl
struct page *page = NULL;
if (blocknr + i < devsize) {
- page = read_mapping_page(mapping, blocknr + i, NULL);
+ page = read_mapping_page_async(mapping, blocknr + i,
+ NULL);
/* synchronous error? */
if (IS_ERR(page))
page = NULL;
Index: linux-2.6/fs/ext2/dir.c
===
--- linux-2.6.orig/fs/ext2/dir.c
+++ linux-2.6/fs/ext2/dir.c
@@ -161,10 +161,7 @@ static struct page * ext2_get_page(struc
struct address_space *mapping = dir->i_mapping;
struct page *page = read_mapping_page(mapping, n, NULL);
if (!IS_ERR(page)) {
- wait_on_page_locked(page);
kmap(page);
- if (!PageUptodate_NoLock(page))
- goto fail;
if (!PageChecked(page))
ext2_check_page(page);
if (PageError(page))
Index: linux-2.6/fs/freevxfs/vxfs_subr.c
===
--- linux-2.6.orig/fs/freevxfs/vxfs_subr.c
+++ linux-2.6/fs/freevxfs/vxfs_subr.c
@@ -74,10 +74,7 @@ vxfs_get_page(struct address_space *mapp
pp = read_mapping_page(mapping, n, NULL);
if (!IS_ERR(pp)) {
- wait_on_page_locked(pp);
kmap(pp);
- if (!PageUptodate(pp))
- goto fail;
/** if (!PageChecked(pp)) **/
/** vxfs_check_page(pp); **/
if (PageError(pp))
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -1756,7 +1756,7 @@ int generic_file_readonly_mmap(struct fi
EXPORT_SYMBOL(generic_file_mmap);
EXPORT_SYMBOL(generic_file_readonly_mmap);
-static inline struct page *__read_cache_page(struct address_space *mapping,
+static struct page *__read_cache_page(struct address_space *mapping,
unsigned long index,
int (*filler)(void *,struct page*),
void *data)
@@ -1793,17 +1793,11 @@ repeat:
return page;
}
-/**
- * read_cache_page - read into page cache, fill it if needed
- * @mapping: the page's address_space
- * @index: the page index
- * @filler:f
Re: [patch 2/3] fs: buffer don't PageUptodate without page locked
On Tue, 6 Feb 2007 09:02:23 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
> __block_write_full_page is calling SetPageUptodate without the page locked.
> This is unusual, but not incorrect, as PG_writeback is still set.
>
> However with the previous patch, this is now a problem: so don't bother
> setting the page uptodate in this case (it is weird that the write path
> does such a thing anyway). Instead just leave it to the read side to bring
> the page uptodate when it notices that all buffers are uptodate.
>
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
>
> Index: linux-2.6/fs/buffer.c
> ===
> --- linux-2.6.orig/fs/buffer.c
> +++ linux-2.6/fs/buffer.c
> @@ -1679,6 +1679,7 @@ static int __block_write_full_page(struc
>*/
> BUG_ON(PageWriteback(page));
> set_page_writeback(page);
> + unlock_page(page);
>
> do {
> struct buffer_head *next = bh->b_this_page;
> @@ -1688,7 +1689,6 @@ static int __block_write_full_page(struc
> }
> bh = next;
> } while (bh != head);
> - unlock_page(page);
>
> err = 0;
> done:
Why this change? Without looking at it too hard, it seems that if
submit_bh() completes synchronously, this thread can end up playing with
the buffers on a non-locked, non-PageWriteback page. Someone else could
whip the buffers away and oops?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] mm: fix PageUptodate memorder
On Tue, 6 Feb 2007 09:02:11 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
> +static inline void __SetPageUptodate(struct page *page)
> +{
> +#ifdef CONFIG_S390
> if (!test_and_set_bit(PG_uptodate, &page->flags))
> page_test_and_clear_dirty(page);
> -}
> #else
> -#define SetPageUptodate(page)set_bit(PG_uptodate, &(page)->flags)
> + /*
> + * Memory barrier must be issued before setting the PG_uptodate bit,
> + * so all previous writes that served to bring the page uptodate are
> + * visible before PageUptodate becomes true.
> + *
> + * S390 is guaranteed to have a barrier in the test_and_set operation
> + * (see Documentation/atomic_ops.txt).
> + *
> + * XXX: does this memory barrier need to be anything special to
> + * handle things like DMA writes into the page?
> + */
> + smp_wmb();
> + set_bit(PG_uptodate, &(page)->flags);
> #endif
> +}
> +
> +static inline void SetPageUptodate(struct page *page)
> +{
> + WARN_ON(!PageLocked(page));
> + __SetPageUptodate(page);
> +}
> +
> +static inline void SetNewPageUptodate(struct page *page)
> +{
> + __SetPageUptodate(page);
> +}
I was panicing for a minute when I saw that __SetPageUptodate() in there.
Conventionally the __SetPageFoo namespace is for nonatomic updates to
page->flags. Can we call this something different?
What a fugly patchset :(
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On Tue, Feb 06, 2007 at 09:20:15AM +0400, Manu Abraham wrote: ... > >BIST is required to complete in 2 seconds. Either with success or failure. > >I expect BIOS to have complained before launching grub/lilo. ... > BIST is supposed to terminate before, say the OS kernel is loaded? Yes - that's what I was trying to imply above. > or does it mean that it can keep running still ? Don't know. Either it's still running (for much longer that 2 seconds), linux is causing it run _again_, or linux is has terribly confused the device somehow. More on this in an email I'm still working on...will send that out in a bit. > >> Region 0: Memory at f7ee (32-bit, non-prefetchable) [disabled] > >[size=4K] > >> Region 2: Memory at e9b0 (32-bit, prefetchable) [disabled] > >[size=4K] > >> Region 3: Memory at (32-bit, prefetchable) [disabled] > >> Region 4: Memory at (32-bit, non-prefetchable) [disabled] > >> Region 5: Memory at (64-bit, > >non-prefetchable) [disabled] > > > >This is obviously garbage. 64-bit registers can only be represented with > >two consecutive "BAR" and region 5 is the last one. > >There is no way this can be a 64-bit BAR. > >Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten > >again if that's just convention or a requirement) > > > > was just wondering how it could be a 64 bit device. 64-bit BAR is seperate from 64-bit Device (data path). PCI has three different 32 vs 64-bit areas: o BARs o DMA o HW/data path width. "32-bit device" generally only refers to the latter. The three attributes are generally all "32-bit" for "32-bit device". That's less likely to be true for "64-bit devices". Several "64-bit devices" can only DMA to 32-bit host memory and at least a few only support 32-bit BARs (even if the device claims it has a 64-bit BAR). hth, grant > > >hth, > >grant > > > > > Thanks a lot for the valuable info. I had not ruled out the option > that it could be broken. > I will try the device in the other OS also, to confirm this. Will post > the status after that. > But most probably as you said, could be broken. > > Thanks, > Manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Free Linux Driver Development!
On 2/6/07, Greg KH <[EMAIL PROTECTED]> wrote: On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote: > Hi Greg, > > Although I am a bit of a cynic, I really hope that this endeavor works > the way you hope. > > I'd also like to offer my services to this quest of yours. If you get > any SD, MMC or SDIO requests, feel free to pass them along to me. I am > not a big fan of debug-by-email though, so I'd prefer vendors who either > can provide samples or where the hardware is cheap and freely available > so I can just go out and by one. Great, thanks for letting me know, I've added you to the list. for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to offer sample device and specs, would like to join the bandwagon. regards, manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm][AIO] Fix AIO completion signal notification possible ref leak
On Mon, 5 Feb 2007 20:13:35 +0300 Oleg Nesterov <[EMAIL PROTECTED]> wrote: > On 02/05, S?bastien Dugu? wrote: > > > > Make sure we only accept valid sigev_notify values in > > aio_setup_sigevent(), > > namely SIGEV_NONE, SIGEV_THREAD_ID or SIGEV_SIGNAL. > > I think this is correct, but I have another concern (most probably I just > confused looking at non-applied patch), could you re-check? > > > @@ -959,6 +959,10 @@ static long aio_setup_sigevent(struct ai > > if (event.sigev_notify == SIGEV_NONE) > > return 0; > > > > + if (event.sigev_notify != SIGEV_SIGNAL && > > + event.sigev_notify != SIGEV_THREAD_ID) > > + return -EINVAL; > > + > > notify->notify = event.sigev_notify; > > notify->signo = event.sigev_signo; > > notify->value = event.sigev_value; > > Ok. But what if sigevent_find_task() fails after that? Doesn't this mean > that really_put_req() will do put_task_struct(NULL) ? > Argh, right, a patch to fix that and a couple of other corner cases to follow soon. Thanks Oleg for looking through this. Sébastien. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] fs: fix __block_write_full_page error case buffer submission
OK, I had initially been going to send a patch to bring the common case
into line with the error case to reduce the chance of rare bugs, but
that's stupid because the common case is obviously the better tested one!
Oh, and the error case seems to have a bug as well.
--
Andrew noticed that unlocking the page before submitting all buffers for
writeout could cause problems if the IO completes before we've finished
messing around with the page buffers, and they subsequently get freed.
Even if there were no bug, it is a good idea to bring the error case
into line with the common case here.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/buffer.c
===
--- linux-2.6.orig/fs/buffer.c
+++ linux-2.6/fs/buffer.c
@@ -1732,7 +1732,6 @@ recover:
SetPageError(page);
BUG_ON(PageWriteback(page));
set_page_writeback(page);
- unlock_page(page);
do {
struct buffer_head *next = bh->b_this_page;
if (buffer_async_write(bh)) {
@@ -1742,6 +1741,7 @@ recover:
}
bh = next;
} while (bh != head);
+ unlock_page(page);
goto done;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote: > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[EMAIL PROTECTED]> wrote: > > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > > ... > > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > > > > ParErr- Stepping- SERR- FastB2B- > > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium > > > > >TAbort- SERR+ > > > Latency: 0, Cache Line Size 0c > > > > BIST is running > > > > > > BIST is required to complete in 2 seconds. Either with success or failure. > > > I expect BIOS to have complained before launching grub/lilo. > > > > Gregkh, > > I just realized linux-pci bus scan should ignore devices (print a warning) > > which have BIST set. Want a patch for this? > > > > Slight risk some previously "working" device which violates the > > spec might get ignored...but I hope there aren't too many of those. > > Should we wait two seconds before declaring the device dead? > To see whether it will come back? Hrm...my thought was BIOS should already be doing that...but I just realised 2 seconds have elapsed if Manu can collect "lspci" output showing "BIST is running". I think the fact that BIST is not "running" in the 2.6.20-rc7 lspci output is just coincidental. The config space for that device is full of similar garbage in both cases regardless how long it took. Maybe BIOS is clobbering BIST when writing latency timer or cacheline size register and BIOS is not being careful to clear or disable the other bytes in that same 32-bit word? PCI is by nature a 32-bit wide config space and "byte enables" are used to mask off bytes we want to ignore. If the chipset or BIOS config access routines aren't careful, they could accidentally modify other values in the same 32-bit word when only one byte was intended to be changed. The code in pci_set_cacheline_size() uses byte enables but is only called by pci_set_mwi(). 82 different .c files (124 instances) access PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls. But I really only care about the calls what would apply get invoked for 1822:4e35. My guess is this one always gets invoked: ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat); since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]". (http://pci-ids.ucw.cz/iii/?i=1822) pci_enable_bridges() -> pci_set_master() -> pcibios_set_master(). Manu, can you add code to pci_enable_bridges() to dump information about which bridges are getting enabled _before_ pci_set_master() is called? I'm interested in a hex dump of the first 8 32-bit words of PCI config space for each device. BTW, I wasn't planning declaring the device as dead. I just wanted to pretend it didn't exist and then let something else (user space? timeout?) trigger a rescan of that bus/"slot". That trigger could come in a successive patch which also removes the 2 second polling loop. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On 2/6/07, Grant Grundler <[EMAIL PROTECTED]> wrote: On Tue, Feb 06, 2007 at 09:20:15AM +0400, Manu Abraham wrote: ... > >BIST is required to complete in 2 seconds. Either with success or failure. > >I expect BIOS to have complained before launching grub/lilo. ... > BIST is supposed to terminate before, say the OS kernel is loaded? Yes - that's what I was trying to imply above. > or does it mean that it can keep running still ? Don't know. Either it's still running (for much longer that 2 seconds), linux is causing it run _again_, or linux is has terribly confused the device somehow. More on this in an email I'm still working on...will send that out in a bit. i think probably, Linux is causing it to run again .. ? > >> Region 0: Memory at f7ee (32-bit, non-prefetchable) [disabled] > >[size=4K] > >> Region 2: Memory at e9b0 (32-bit, prefetchable) [disabled] > >[size=4K] > >> Region 3: Memory at (32-bit, prefetchable) [disabled] > >> Region 4: Memory at (32-bit, non-prefetchable) [disabled] > >> Region 5: Memory at (64-bit, > >non-prefetchable) [disabled] > > > >This is obviously garbage. 64-bit registers can only be represented with > >two consecutive "BAR" and region 5 is the last one. > >There is no way this can be a 64-bit BAR. > >Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten > >again if that's just convention or a requirement) > > > > was just wondering how it could be a 64 bit device. 64-bit BAR is seperate from 64-bit Device (data path). PCI has three different 32 vs 64-bit areas: o BARs o DMA o HW/data path width. "32-bit device" generally only refers to the latter. The three attributes are generally all "32-bit" for "32-bit device". According to the information i have on this device .. Configuration Register 00H : Device_ID / Vendor_ID Register Bit [31:16] R Device_ID Device ID = 16'h4e35 Bit [15:0] R Vendor_ID Vendor ID = 16'h1822 Configuration Register 04H : Status / Command Register Bit 31 R Detpar_rpt Detect Parity Report Bit 30 W/R System_err Indicate System Error Bit 29 R Master_abort Indicate Master Abort Bit 28 R Target_abort Indicate Target Abort Bit [27:25] Default = 3'b001 Bit 24 R Datapar_rpt Data Parity Report Bit [23:20] Default = 4'b Bit [19:16] Default = 4'b Bit [15:9] Default = 7'h0 Bit 8 W/R Pci_serr_en PCI system error enable Bit 7 Default = 1'b0 Bit 6 W/R Pci_perr_en PCI parity error enable Bit [5:3] Default = 3'h0 Bit 2 W/R Pci_master_en PCI master mode enable Bit 1 W/R Pci_target_en PCI target mode enable Bit 0 Default = 1'b0 Configuration Register 08H : Class_Code / Revision_ID Register Bit [31:8] R Class_Code Class_Code = 24'h048000 Bit [7:0] R Revision_ID Revision_ID = 8'h01 Configuration Register 0CH : Latency Timer Register Bit [31:16] Default = 16'h0 Bit [15:11] W/R Pci_lat_timer Indicate PCI latency timer Bit [10:8] Default = 3'h0 Bit [7:0] Default = 8'b0 Configuration Register 10H : Base_Address / Memory&Prep Register Bit [31:12] W/R Pci_base_addr Indicate PCI Base Address Bit [31:0] R Default = 12'h008 Configuration Register 2CH : I2C Subsystem_ID / Subsystem_Vendor_ID Register Bit [31:0] W/R I2c_ssid_ssvid Indicate I2C subsystem_ID / subsystem_vendor_ID Configuration Register 38H : Test PCI Connection Register Bit [31:0] W/R Test_pci_conn Indicate to test PCI connection Configuration Register 3CH : Max_Latency / Min_Gnt / Int_Pin / Int_Line Register Bit [31:24] W Max_lat Default = 8'hFF Bit [23:16] W Min_gnt Default = 8'h08 Bit [15:8] W Int_pin Default = 8'h01 Bit [7:0] W/R Int_line Indicate interrupt line That's less likely to be true for "64-bit devices". Several "64-bit devices" can only DMA to 32-bit host memory and at least a few only support 32-bit BARs (even if the device claims it has a 64-bit BAR). AFAIK, the device does 32 bit DMA, but it is not completely hardware driven DMA. it just uses a RISC core which just jumps to the pointer allocated in software. The other devices using the same chip, works that way. hth, grant thanks, manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.
Ingo thanks for the review.
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> When making the interrupt vectors per cpu I failed to handle a case
>> during irq migration. If the same interrupt comes in while we are
>> servicing the irq but before we migrate it the pending bit in the
>> local apic IRR register will be set for that irq.
>
> hm. I think this needs more work. For example this part of the fix looks
> quite ugly to me:
I'm not at all certain I can make an ugly reality look beautiful.
>> +static unsigned apic_in_service_vector(void)
>> +{
>> +unsigned isr, vector;
>> +/* Figure out which vector we are servicing */
>> + for (vector = FIRST_EXTERNAL_VECTOR; vector < FIRST_SYSTEM_VECTOR; vector
>> +=
> 32) {
>> +isr = apic_read(APIC_ISR + ((vector/32) * 0x10));
>> +if (isr)
>> +break;
>> +}
>> +/* Find the low bits of the vector we are servicing */
>> +vector += __ffs(isr);
>> +return vector;
>
> so we read the hardware to figure out what the hell we are doing. The
> problem is - why doesnt the kernel know at this point what it is doing?
> It knows the CPU and it should know all the vector numbers. It also has
> an irq number.
Yes. And by adding a percpu global I can do this. If figured since this
should be a rare case it would be equally simple to read this from
the hardware, as it already has the information stored in roughly the
form I would need to store it in. If there errata in this area and I
am likely to hit them then it is probably a good idea to look at a
different implementation.
>> +/* If the irq we are servicing has moved and is not pending
>> + * free it's vector.
>> + */
>> +irr = apic_read(APIC_IRR + ((vector/32) * 0x10));
>
> the IRR is quite fragile. It's a rarely used hardware field and it has
> erratums attached to it. Again, it seems like this function too tries to
> recover information it /should/ already have.
If I am servicing an interrupt and that same interrupt comes in again
before I acknowledge it how /should/ I know that?
The only way I know to find that information is to ask the hardware.
>> @@ -1400,19 +1439,24 @@ static int ioapic_retrigger_irq(unsigned int irq)
>>
>> static void ack_apic_edge(unsigned int irq)
>> {
>> -move_native_irq(irq);
>> +if (unlikely(irq_desc[irq].status & IRQ_MOVE_PENDING)) {
>> +move_native_irq(irq);
>> +apic_handle_pending_vector(apic_in_service_vector());
>> +}
>> ack_APIC_irq();
>
> this looks a bit ugly and a bit fragile. We had a simple
> 'move_native_irq()' call for IRQ balancing, which is straightforward,
> but now we've got this complex condition open coded.
Well the condition is testing a single bit so I don't think it is that
complex. Maybe taking it out of line will help or maybe that will obscure
things. I'm inclined to believe hiding the irq migration logic will
obscure things and make it harder to debug.
Now part of the reason I did it this way is I have at least 3
set_affinity implementations and this issue really has nothing to do
with the external interrupt controller but everything to do with the
cpu local interrupt controller, so this did not seem like something
that was reasonably buried in set_affinity.
> If then this should be done in some sort of helper - but even then, the
> whole approach looks a bit erroneous.
>
> To me the cleanest way to migrate an IRQ between two different vectors
> on two different CPUs would be to first mask the IRQ source in the PIC,
> then to do the migration /atomically/ (no intermediary state), and then
> unmask. If the PIC loses edges while masked then that's a problem of the
> irq chip implementation of the PIC: its ->set_affinity() method should
> refuse to migrate edge-triggered IRQs if it can lose edges while
> unmasked!
Ingo I believe what you have described is essentially what we are
doing before my patches, or what we were doing in even older versions
that had other races and problems.
To some extent I have inherited the current design that mostly works. The
only known reliable way to block and edge triggered irq is to be servicing it.
The practical problem there is that when we sit on an irq the irq can come
in again and queue up in irr. Which means that once we have updated the
data structures acked the irq and returned the irq will come in again
in the old location because the io_apic has a 1 deep queue for each
irq. Of course for the irq controllers that can be masked safely your
proposed change to disable irq is unfortunate.
You appear to be lobbying for disabling the irq asynchronously to all
of the irq reception activity. That would seem to me to require
running on the cpu where the irq is currently programmed to be
delivered disabling local interrupts, as well as disabling the irq in
the interrupt controller before reprogramming it. For the irqs that
applies
Re: 2.6.19.2, 2.6.20 Kernel oops
On Mon, Feb 05, 2007 at 07:57:39PM -0800, Andrew Morton wrote: these are lines above: kernel: [ 144.639984] ACPI: Power Button (FF) [PWRF] kernel: [ 144.640006] input: Power Button (CM) as /class/input/input3 kernel: [ 144.640017] ACPI: Power Button (CM) [PWRB] kernel: [ 222.002010] PGD 253115067 PUD 0 > > kernel: [ 222.002013] CPU 0 > > kernel: [ 222.002014] Modules linked in: container fan button ac thermal > > processor myri10ge megaraid_sas serio_raw psmouse evdev > > kernel: [ 222.002020] Pid: 3234, comm: java Not tainted 2.6.20 #1 > > kernel: [ 222.002021] RIP: 0010:[page_to_pfn+0/64] [page_to_pfn+0/64] > > page_to_pfn+0x0/0x40 > > kernel: [ 222.002024] RSP: 0018:81024ebf9ac0 EFLAGS: 00010246 > > kernel: [ 222.002026] RAX: 8102574213c0 RBX: 810256f07800 RCX: > > 81022e5600c0 > > kernel: [ 222.002027] RDX: 0740 RSI: RDI: > > > > kernel: [ 222.002028] RBP: 0740 R08: 0002 R09: > > 8102536b9a40 > > kernel: [ 222.002030] R10: 0007 R11: 80259650 R12: > > > > kernel: [ 222.002031] R13: 810257422460 R14: 0002 R15: > > 81022e5600c0 > > kernel: [ 222.002033] FS: 41061950(0063) > > GS:80649000() knlGS: > > kernel: [ 222.002034] CS: 0010 DS: ES: CR0: 8005003b > > kernel: [ 222.002036] CR2: CR3: 000251dbb000 CR4: > > 06e0 > > kernel: [ 222.002037] Process java (pid: 3234, threadinfo > > 81024ebf8000, task 81024ebdc7a0) > > kernel: [ 222.002038] Stack: 804c4f77 810257422400 > > 0002 81024ebf9f28 > > kernel: [ 222.002042] f240 0740 810257422460 > > 0002 > > kernel: [ 222.002044] 804c3ba5 0010 81022e5600c0 > > 8102536b9a40 > > kernel: [ 222.002046] Call Trace: > > kernel: [ 222.002051] [ioat_dma_memcpy_buf_to_pg+71/224] > > ioat_dma_memcpy_buf_to_pg+0x47/0xe0 > > kernel: [ 222.002053] [dma_memcpy_to_iovec+613/768] > > dma_memcpy_to_iovec+0x265/0x300 > > kernel: [ 222.002057] [dma_skb_copy_datagram_iovec+115/656] > > dma_skb_copy_datagram_iovec+0x73/0x290 > > kernel: [ 222.002060] [tcp_recvmsg+1764/3296] tcp_recvmsg+0x6e4/0xce0 > > kernel: [ 222.002063] [sock_common_recvmsg+48/80] > > sock_common_recvmsg+0x30/0x50 > > kernel: [ 222.002065] [sock_recvmsg+281/352] sock_recvmsg+0x119/0x160 > > kernel: [ 222.002069] [autoremove_wake_function+0/48] > > autoremove_wake_function+0x0/0x30 > > kernel: [ 222.002071] [autoremove_wake_function+0/48] > > autoremove_wake_function+0x0/0x30 > > kernel: [ 222.002073] [__handle_mm_fault+1741/2896] > > __handle_mm_fault+0x6cd/0xb50 > > kernel: [ 222.002076] [sys_recvfrom+250/400] sys_recvfrom+0xfa/0x190 > > kernel: [ 222.002078] [tty_ldisc_deref+100/128] tty_ldisc_deref+0x64/0x80 > > kernel: [ 222.002080] [tty_write+540/592] tty_write+0x21c/0x250 > > kernel: [ 222.002083] [system_call+126/131] system_call+0x7e/0x83 > > kernel: [ 222.002084] > > kernel: [ 222.002085] > > kernel: [ 222.002085] Code: 48 8b 07 48 c1 e8 3a 48 8b 14 c5 80 b8 65 80 > > 48 b8 b7 6d db > > kernel: [ 222.002092] RSP > > > > Is that the whole oops message? There should have been a few interesting > lines preceding the above. I've posted it above. -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Missing critical phys_to_virt in lib/swiotlb.c
On 2/6/2007 8:56 AM, Andi Kleen wrote: >> > From: David Moore <[EMAIL PROTECTED]> ... >> > It fixes real crashes: >> > http://lists.opensuse.org/opensuse-bugs/2006-12/msg02943.html >> > http://qa.mandriva.com/show_bug.cgi?id=28224 >> > http://www.pchdtv.com/forum/viewtopic.php?t=2063&sid=a959a14a4c2db0eebaab7b0df56103ce >> > >> > --- linux-2.6.19.x86_64/lib/swiotlb.c.orig 2007-02-04 13:18:41.0 >> > -0500 >> > +++ linux-2.6.19.x86_64/lib/swiotlb.c 2007-02-04 13:19:43.0 >> > -0500 >> > @@ -750,7 +750,7 @@ swiotlb_sync_sg(struct device *hwdev, st >> > >> >for (i = 0; i < nelems; i++, sg++) >> >if (sg->dma_address != SG_ENT_PHYS_ADDRESS(sg)) >> > - sync_single(hwdev, (void *) sg->dma_address, >> > + sync_single(hwdev, phys_to_virt(sg->dma_address), >> >sg->dma_length, dir, target); >> > } ... > Sounds weird. If this really didn't work much more should be broken > (e.g. no cdroms/sound on Intel x86-64 boxes with >4GB) Yes, it's weird; e.g. it seems that reports of that on linux1394-user and -devel came in only recently. But I may have missed something. (OTOH, this bug was partially hidden for FireWire users because one of the relevant FireWire drivers was lacking respective _sync_sg calls.) > I'm a little sceptical. Perhaps the TV driver is doing something bogus > here? sync_single() definitely wants a virtual address there. sg->dma_address is a physical address. The bug and the fix are obvious. Unfortunately an author of lib/swiotlb.c chose to call many variables holding *virtual* addresses "dma_addr". Note how that file at the same time contains variables like "dma_addr_t dma_handle". A recipe for disaster. > Also I haven't heard of this problem before at all and I'm sure I would > have if sounds/cdroms were broken. > > Shouldn't be applied without further analysis. Maybe some recent changes elsewhere cause more frequent use of swiotlb-driven bounce buffers? That should be verified. Or maybe people are deploying affected hardware more often now? -- Stefan Richter -=-=-=== --=- --==- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On 2/6/07, Grant Grundler <[EMAIL PROTECTED]> wrote: On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote: > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[EMAIL PROTECTED]> wrote: > > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > > ... > > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ > > > Latency: 0, Cache Line Size 0c > > > > BIST is running > > > > > > BIST is required to complete in 2 seconds. Either with success or failure. > > > I expect BIOS to have complained before launching grub/lilo. > > > > Gregkh, > > I just realized linux-pci bus scan should ignore devices (print a warning) > > which have BIST set. Want a patch for this? > > > > Slight risk some previously "working" device which violates the > > spec might get ignored...but I hope there aren't too many of those. > > Should we wait two seconds before declaring the device dead? > To see whether it will come back? Hrm...my thought was BIOS should already be doing that...but I just realised 2 seconds have elapsed if Manu can collect "lspci" output showing "BIST is running". I think the fact that BIST is not "running" in the 2.6.20-rc7 lspci output is just coincidental. The config space for that device is full of similar garbage in both cases regardless how long it took. waited for more than 30 mins as well, well almost the entire night, BIST didn't stop Maybe BIOS is clobbering BIST when writing latency timer or cacheline size register and BIOS is not being careful to clear or disable the other bytes in that same 32-bit word? If the BIOS is clobbering the BIST, then the same should happen in the other OS as well ? Just plugging in the card, without any drivers, got me the PCI vendor info. PCI is by nature a 32-bit wide config space and "byte enables" are used to mask off bytes we want to ignore. If the chipset or BIOS config access routines aren't careful, they could accidentally modify other values in the same 32-bit word when only one byte was intended to be changed. The code in pci_set_cacheline_size() uses byte enables but is only called by pci_set_mwi(). 82 different .c files (124 instances) access PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls. But I really only care about the calls what would apply get invoked for 1822:4e35. My guess is this one always gets invoked: ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat); since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]". (http://pci-ids.ucw.cz/iii/?i=1822) pci_enable_bridges() -> pci_set_master() -> pcibios_set_master(). Manu, can you add code to pci_enable_bridges() to dump information about which bridges are getting enabled _before_ pci_set_master() is called? I'm interested in a hex dump of the first 8 32-bit words of PCI config space for each device. let me give it a shot. BTW, I wasn't planning declaring the device as dead. I just wanted to pretend it didn't exist and then let something else (user space? timeout?) trigger a rescan of that bus/"slot". That trigger could come in a successive patch which also removes the 2 second polling loop. maybe the driver can do a rescan ? grant thanks, manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
On Tue, 2007-02-06 at 16:11 +1100, Rusty Russell wrote: > On Mon, 2007-02-05 at 20:54 -0800, Zachary Amsden wrote: > > Rusty Russell wrote: > > > Indeed, I'm expecting to push lguest this week, and this code will > > > effect me, so I'd like to see this in a -mm soon... > > > > Yes, I took a look at the lguest changes today and I think these won't > > generate conflicts, just make stuff easier for you ;) Course you've now > > got a couple new paravirt-ops to support, but the native ones are fine > > for temporary use. > > Implementing stolen time is something I'd like to do, since it'd be a > nice self-contained example the expectations. hmm stolen time could even be useful without virtualization; to a large degree, if cpufreq reduces the speed of your cpu you have "stolen cycles" that way... I wonder if this concept can be used for that as well... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Missing critical phys_to_virt in lib/swiotlb.c
I wrote:
> Unfortunately an author of lib/swiotlb.c chose to call many variables
> holding *virtual* addresses "dma_addr". Note how that file at the same
> time contains variables like "dma_addr_t dma_handle".
And there is even one occurrence of a "dma_addr" holding a physical
address/ bus address, unlike the other dma_addr's:
int
swiotlb_dma_mapping_error(dma_addr_t dma_addr)
{
return (dma_addr == virt_to_phys(io_tlb_overflow_buffer));
}
--
Stefan Richter
-=-=-=== --=- --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19.2, 2.6.20 Kernel oops
On Tue, 6 Feb 2007 09:59:43 +0100 Lukas Hejtmanek <[EMAIL PROTECTED]> wrote: > On Mon, Feb 05, 2007 at 07:57:39PM -0800, Andrew Morton wrote: > > these are lines above: > > kernel: [ 144.639984] ACPI: Power Button (FF) [PWRF] > kernel: [ 144.640006] input: Power Button (CM) as /class/input/input3 > kernel: [ 144.640017] ACPI: Power Button (CM) [PWRB] > kernel: [ 222.002010] PGD 253115067 PUD 0 > > > > > kernel: [ 222.002013] CPU 0 > > > kernel: [ 222.002014] Modules linked in: container fan button ac thermal > > > processor myri10ge megaraid_sas serio_raw psmouse evdev > > > kernel: [ 222.002020] Pid: 3234, comm: java Not tainted 2.6.20 #1 > > > kernel: [ 222.002021] RIP: 0010:[page_to_pfn+0/64] [page_to_pfn+0/64] > > > page_to_pfn+0x0/0x40 > > > kernel: [ 222.002024] RSP: 0018:81024ebf9ac0 EFLAGS: 00010246 > > > kernel: [ 222.002026] RAX: 8102574213c0 RBX: 810256f07800 RCX: > > > 81022e5600c0 > > > kernel: [ 222.002027] RDX: 0740 RSI: RDI: > > > > > > kernel: [ 222.002028] RBP: 0740 R08: 0002 R09: > > > 8102536b9a40 > > > kernel: [ 222.002030] R10: 0007 R11: 80259650 R12: > > > > > > kernel: [ 222.002031] R13: 810257422460 R14: 0002 R15: > > > 81022e5600c0 > > > kernel: [ 222.002033] FS: 41061950(0063) > > > GS:80649000() knlGS: > > > kernel: [ 222.002034] CS: 0010 DS: ES: CR0: 8005003b > > > kernel: [ 222.002036] CR2: CR3: 000251dbb000 CR4: > > > 06e0 > > > kernel: [ 222.002037] Process java (pid: 3234, threadinfo > > > 81024ebf8000, task 81024ebdc7a0) > > > kernel: [ 222.002038] Stack: 804c4f77 810257422400 > > > 0002 81024ebf9f28 > > > kernel: [ 222.002042] f240 0740 > > > 810257422460 0002 > > > kernel: [ 222.002044] 804c3ba5 0010 > > > 81022e5600c0 8102536b9a40 > > > kernel: [ 222.002046] Call Trace: > > > kernel: [ 222.002051] [ioat_dma_memcpy_buf_to_pg+71/224] > > > ioat_dma_memcpy_buf_to_pg+0x47/0xe0 > > > kernel: [ 222.002053] [dma_memcpy_to_iovec+613/768] > > > dma_memcpy_to_iovec+0x265/0x300 > > > kernel: [ 222.002057] [dma_skb_copy_datagram_iovec+115/656] > > > dma_skb_copy_datagram_iovec+0x73/0x290 > > > kernel: [ 222.002060] [tcp_recvmsg+1764/3296] tcp_recvmsg+0x6e4/0xce0 > > > kernel: [ 222.002063] [sock_common_recvmsg+48/80] > > > sock_common_recvmsg+0x30/0x50 > > > kernel: [ 222.002065] [sock_recvmsg+281/352] sock_recvmsg+0x119/0x160 > > > kernel: [ 222.002069] [autoremove_wake_function+0/48] > > > autoremove_wake_function+0x0/0x30 > > > kernel: [ 222.002071] [autoremove_wake_function+0/48] > > > autoremove_wake_function+0x0/0x30 > > > kernel: [ 222.002073] [__handle_mm_fault+1741/2896] > > > __handle_mm_fault+0x6cd/0xb50 > > > kernel: [ 222.002076] [sys_recvfrom+250/400] sys_recvfrom+0xfa/0x190 > > > kernel: [ 222.002078] [tty_ldisc_deref+100/128] > > > tty_ldisc_deref+0x64/0x80 > > > kernel: [ 222.002080] [tty_write+540/592] tty_write+0x21c/0x250 > > > kernel: [ 222.002083] [system_call+126/131] system_call+0x7e/0x83 > > > kernel: [ 222.002084] > > > kernel: [ 222.002085] > > > kernel: [ 222.002085] Code: 48 8b 07 48 c1 e8 3a 48 8b 14 c5 80 b8 65 80 > > > 48 b8 b7 6d db > > > kernel: [ 222.002092] RSP > > > > > > > Is that the whole oops message? There should have been a few interesting > > lines preceding the above. > > I've posted it above. That's peculiar. Normally an oops on x86_64 looks like: Unable to handle kernel NULL pointer dereference at 0038 RIP: [] iput+0x18/0x80 PGD 3a607067 PUD 27b20067 PMD 0 Oops: [1] SMP CPU 0 Modules linked in: psmouse battery ac thermal fan button ... but you seem to have lost the first few lines. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][0/5] floppy.c: first round of cleanup patches - the simple stuff
On 06/02/07, Andi Kleen <[EMAIL PROTECTED]> wrote: On Tuesday 06 February 2007 00:28, Jesper Juhl wrote: > Greetings people, > > Here is, as promised, the first round of cleanup patches for floppy.c > (more will follow later). I think the real problem with floppy.c is the basic code logic, not the coding style. While cleaning the later up is nice, I'm afraid it doesn't really help all that much because that code has to be replaced anyways. And I will get to the logic later, don't worry :-) I just wanted to get all the simple little things out of the way first. Thank you for commenting. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: 2.6.19.2, 2.6.20 Kernel oops
On Tue, Feb 06, 2007 at 01:09:07AM -0800, Andrew Morton wrote: > > these are lines above: > > > > kernel: [ 144.639984] ACPI: Power Button (FF) [PWRF] > > kernel: [ 144.640006] input: Power Button (CM) as /class/input/input3 > > kernel: [ 144.640017] ACPI: Power Button (CM) [PWRB] > > kernel: [ 222.002010] PGD 253115067 PUD 0 > > > > > > > > kernel: [ 222.002013] CPU 0 > > > > kernel: [ 222.002014] Modules linked in: container fan button ac > > > > thermal processor myri10ge megaraid_sas serio_raw psmouse evdev > > > > kernel: [ 222.002020] Pid: 3234, comm: java Not tainted 2.6.20 #1 > > > > kernel: [ 222.002021] RIP: 0010:[page_to_pfn+0/64] [page_to_pfn+0/64] > > > > page_to_pfn+0x0/0x40 > > > > kernel: [ 222.002024] RSP: 0018:81024ebf9ac0 EFLAGS: 00010246 > > > > kernel: [ 222.002026] RAX: 8102574213c0 RBX: 810256f07800 RCX: > > > > 81022e5600c0 > > > > kernel: [ 222.002027] RDX: 0740 RSI: RDI: > > > > > > > > kernel: [ 222.002028] RBP: 0740 R08: 0002 R09: > > > > 8102536b9a40 > > > > kernel: [ 222.002030] R10: 0007 R11: 80259650 R12: > > > > > > > > kernel: [ 222.002031] R13: 810257422460 R14: 0002 R15: > > > > 81022e5600c0 > > > > kernel: [ 222.002033] FS: 41061950(0063) > > > > GS:80649000() knlGS: > > > > kernel: [ 222.002034] CS: 0010 DS: ES: CR0: 8005003b > > > > kernel: [ 222.002036] CR2: CR3: 000251dbb000 CR4: > > > > 06e0 > > > > kernel: [ 222.002037] Process java (pid: 3234, threadinfo > > > > 81024ebf8000, task 81024ebdc7a0) > > > > kernel: [ 222.002038] Stack: 804c4f77 810257422400 > > > > 0002 81024ebf9f28 > > > > kernel: [ 222.002042] f240 0740 > > > > 810257422460 0002 > > > > kernel: [ 222.002044] 804c3ba5 0010 > > > > 81022e5600c0 8102536b9a40 > > > > kernel: [ 222.002046] Call Trace: > > > > kernel: [ 222.002051] [ioat_dma_memcpy_buf_to_pg+71/224] > > > > ioat_dma_memcpy_buf_to_pg+0x47/0xe0 > > > > kernel: [ 222.002053] [dma_memcpy_to_iovec+613/768] > > > > dma_memcpy_to_iovec+0x265/0x300 > > > > kernel: [ 222.002057] [dma_skb_copy_datagram_iovec+115/656] > > > > dma_skb_copy_datagram_iovec+0x73/0x290 > > > > kernel: [ 222.002060] [tcp_recvmsg+1764/3296] tcp_recvmsg+0x6e4/0xce0 > > > > kernel: [ 222.002063] [sock_common_recvmsg+48/80] > > > > sock_common_recvmsg+0x30/0x50 > > > > kernel: [ 222.002065] [sock_recvmsg+281/352] sock_recvmsg+0x119/0x160 > > > > kernel: [ 222.002069] [autoremove_wake_function+0/48] > > > > autoremove_wake_function+0x0/0x30 > > > > kernel: [ 222.002071] [autoremove_wake_function+0/48] > > > > autoremove_wake_function+0x0/0x30 > > > > kernel: [ 222.002073] [__handle_mm_fault+1741/2896] > > > > __handle_mm_fault+0x6cd/0xb50 > > > > kernel: [ 222.002076] [sys_recvfrom+250/400] sys_recvfrom+0xfa/0x190 > > > > kernel: [ 222.002078] [tty_ldisc_deref+100/128] > > > > tty_ldisc_deref+0x64/0x80 > > > > kernel: [ 222.002080] [tty_write+540/592] tty_write+0x21c/0x250 > > > > kernel: [ 222.002083] [system_call+126/131] system_call+0x7e/0x83 > > > > kernel: [ 222.002084] > > > > kernel: [ 222.002085] > > > > kernel: [ 222.002085] Code: 48 8b 07 48 c1 e8 3a 48 8b 14 c5 80 b8 65 > > > > 80 48 b8 b7 6d db > > > > kernel: [ 222.002092] RSP > > > > > > > > > > Is that the whole oops message? There should have been a few interesting > > > lines preceding the above. > > > > I've posted it above. > > That's peculiar. > > Normally an oops on x86_64 looks like: > > Unable to handle kernel NULL pointer dereference at 0038 > RIP: [] iput+0x18/0x80 > PGD 3a607067 PUD 27b20067 PMD 0 > Oops: [1] SMP > CPU 0 > Modules linked in: psmouse battery ac thermal fan button > ... > > but you seem to have lost the first few lines. It looks like some of these messages have different priority. These lines have been in different log file... kernel: [ 222.002000] Unable to handle kernel NULL pointer dereference at RIP: kernel: [ 222.002004] [page_to_pfn+0/64] page_to_pfn+0x0/0x40 kernel: [ 222.002010] PGD 253115067 PUD 0 kernel: [ 222.002011] Oops: [1] PREEMPT SMP kernel: [ 222.002013] CPU 0 -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm][AIO] AIO completion signal notification fixes and cleanups
Andrew, here is another incremental patch which does a bit of cleanup
as well as fixing a possible release on a task ref that was not taken.
Thanks,
Sébastien.
From: Sébastien Dugué <[EMAIL PROTECTED]>
AIO completion signal notification misc fixes and cleanups
This patches cleans up the notification path and fixes a possible
release on a task ref that was not taken in aio_setup_sigevent().
aio.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc6-mm3/fs/aio.c
===
--- linux-2.6.20-rc6-mm3.orig/fs/aio.c 2007-02-05 16:53:43.0 +0100
+++ linux-2.6.20-rc6-mm3/fs/aio.c 2007-02-06 09:33:55.0 +0100
@@ -469,8 +469,7 @@ static inline void really_put_req(struct
kfree(req->ki_iovec);
/* Release task ref */
- if (req->ki_notify.notify == SIGEV_THREAD_ID ||
- req->ki_notify.notify == SIGEV_SIGNAL)
+ if (req->ki_notify.notify != SIGEV_NONE)
put_task_struct(req->ki_notify.target);
kmem_cache_free(kiocb_cachep, req);
@@ -970,8 +969,14 @@ static long aio_setup_sigevent(struct ai
rcu_read_lock();
target = sigevent_find_task(&event);
- if (unlikely(!target))
+ if (unlikely(!target)) {
+ /*
+* Revert notify to SIGEV_NONE so that really_put_req()
+* knows that no ref has been taken on a task.
+*/
+ notify->notify = SIGEV_NONE;
goto out_unlock;
+ }
/*
* At this point, we know that notify is either SIGEV_SIGNAL or
@@ -996,7 +1001,7 @@ static long aio_setup_sigevent(struct ai
return 0;
out_unlock:
- read_unlock(&tasklist_lock);
+ rcu_read_unlock();
return -EINVAL;
}
@@ -1763,7 +1768,7 @@ int fastcall io_submit_one(struct kioctx
(struct sigevent __user *)(unsigned
long)
iocb->aio_sigeventp);
if (ret)
- goto out_put_req;
+ goto out_sigqfree;
}
/* Attach this iocb to its lio */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
Arjan van de Ven wrote: On Tue, 2007-02-06 at 16:11 +1100, Rusty Russell wrote: On Mon, 2007-02-05 at 20:54 -0800, Zachary Amsden wrote: Rusty Russell wrote: Indeed, I'm expecting to push lguest this week, and this code will effect me, so I'd like to see this in a -mm soon... Yes, I took a look at the lguest changes today and I think these won't generate conflicts, just make stuff easier for you ;) Course you've now got a couple new paravirt-ops to support, but the native ones are fine for temporary use. Implementing stolen time is something I'd like to do, since it'd be a nice self-contained example the expectations. hmm stolen time could even be useful without virtualization; to a large degree, if cpufreq reduces the speed of your cpu you have "stolen cycles" that way... I wonder if this concept can be used for that as well... Yes, stolen time happens in most moderns systems as a result of power management (and you can probably count SMM cycles as stolen if only there was a way to count them). It would be useful to report on a laptop, for instance, how many cycles have been stolen by running off battery or on a server because of heat issues. Having an interface for Linux to report this seems useful. It is a covert channel, however, in a virtualized environment, so there should be some provision in the hypervisor to turn it off. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On 2/6/07, Manu Abraham <[EMAIL PROTECTED]> wrote: On 2/6/07, Grant Grundler <[EMAIL PROTECTED]> wrote: > On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote: > > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > > > ... > > > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > > > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ > > > > Latency: 0, Cache Line Size 0c > > > > > BIST is running > > > > > > > > BIST is required to complete in 2 seconds. Either with success or failure. > > > > I expect BIOS to have complained before launching grub/lilo. > > > > > > Gregkh, > > > I just realized linux-pci bus scan should ignore devices (print a warning) > > > which have BIST set. Want a patch for this? > > > > > > Slight risk some previously "working" device which violates the > > > spec might get ignored...but I hope there aren't too many of those. > > > > Should we wait two seconds before declaring the device dead? > > To see whether it will come back? > > Hrm...my thought was BIOS should already be doing that...but I just > realised 2 seconds have elapsed if Manu can collect "lspci" output showing > "BIST is running". I think the fact that BIST is not "running" in the > 2.6.20-rc7 lspci output is just coincidental. The config space for that > device is full of similar garbage in both cases regardless how long > it took. > waited for more than 30 mins as well, well almost the entire night, BIST didn't stop > Maybe BIOS is clobbering BIST when writing latency timer or cacheline size > register and BIOS is not being careful to clear or disable the other > bytes in that same 32-bit word? > If the BIOS is clobbering the BIST, then the same should happen in the other OS as well ? Just plugging in the card, without any drivers, got me the PCI vendor info. > PCI is by nature a 32-bit wide config space and "byte enables" > are used to mask off bytes we want to ignore. If the chipset > or BIOS config access routines aren't careful, they could accidentally > modify other values in the same 32-bit word when only one byte was > intended to be changed. > > The code in pci_set_cacheline_size() uses byte enables but is only > called by pci_set_mwi(). 82 different .c files (124 instances) access > PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls. > But I really only care about the calls what would apply get invoked > for 1822:4e35. My guess is this one always gets invoked: > ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat); > > since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]". > (http://pci-ids.ucw.cz/iii/?i=1822) > pci_enable_bridges() -> pci_set_master() -> pcibios_set_master(). > > Manu, can you add code to pci_enable_bridges() to dump information about > which bridges are getting enabled _before_ pci_set_master() is called? > I'm interested in a hex dump of the first 8 32-bit words of > PCI config space for each device. > let me give it a shot. dang ! rebooted it into 2.6.17.7 no errors, during a bootup, BIST isn't running anymore running M$ did change the status from dead to alive ??? shocked !! attached lspci output in the very same setup as earlier, no difference in anything, except that it was rebooted into windows. the PCI config dump would help ? regards, manu 00:00.0 0600: 8086:2578 (rev 02) Subsystem: 1043:80f6 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 0604: 8086:2579 (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- 00:1d.0 0c03: 8086:24d2 (rev 02) Subsystem: 1043:80a6 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- 00:1f.0 0601: 8086:24d0 (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 02:03.0 0c00: 1106:3044 (rev 80) (prog-if 10) Subsystem: 1043:808a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-
Re: [discuss] [patch] mtrr: fix issues with large addresses
>>> Andi Kleen <[EMAIL PROTECTED]> 06.02.07 08:53 >>> >On Monday 05 February 2007 23:50, Siddha, Suresh B wrote: >> On Mon, Feb 05, 2007 at 06:19:59PM +0100, Andreas Herrmann wrote: >> > o added check to restrict base address to 36 bit on i386 >> >> Why is this? It can go upto implemented physical bits, right? > >In theory it can, but Linux doesn't support it. I don't think I remember a restriction here, at least not below 44 bits (that's where pfn-s would need to become 64-bit wide). Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Missing critical phys_to_virt in lib/swiotlb.c
>Shouldn't be applied without further analysis. I don't think further analysis is required before this change be done, the missing conversion is rather obvious when comparing to all other functions in that file. Whether the observed crashes really origin from the missing bits here is a different question. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3, try #2] Blackfin: serial driver for Blackfin architecture against Linux kernel 2.6.20
I think you have a bit of work to do on this driver; it seems to be
missing all termios handling apart from setting the baud rate.
Moreover, it's re-using the 8250 driver port range despite claiming
to have a proper allocation.
(I don't maintain serial anymore but I do reserve the right to
occasionally review serial code.)
On Tue, Feb 06, 2007 at 11:20:11AM +0800, Wu, Bryan wrote:
> +/* We've been assigned a range on the "Low-density serial ports" major */
> +#define SERIAL_BFIN_MAJORTTY_MAJOR
> +#define MINOR_START 64
If you've been assigned a range in the low density serial ports major,
why aren't you using it instead of taking the 8250 drivers range (thereby
preventing PCMCIA cards from ever being used) ?
> +#if defined(CONFIG_BAUD_9600)
> +#define CONSOLE_BAUD_RATE 9600
> +#elif defined(CONFIG_BAUD_19200)
> +#define CONSOLE_BAUD_RATE 19200
> +#elif defined(CONFIG_BAUD_38400)
> +#define CONSOLE_BAUD_RATE 38400
> +#elif defined(CONFIG_BAUD_57600)
> +#define CONSOLE_BAUD_RATE 57600
> +#elif defined(CONFIG_BAUD_115200)
> +#define CONSOLE_BAUD_RATE 115200
> +#endif
What's wrong with passing console=ttyblackfin0,115200 to the kernel or
via some default command line?
> +/*
> + * interrupts are disabled on entry
> + */
> +static void bfin_serial_stop_tx(struct uart_port *port)
> +{
> + struct bfin_serial_port *uart = (struct bfin_serial_port *)port;
> +
> +#ifdef CONFIG_SERIAL_BFIN_DMA
> +disable_dma(uart->tx_dma_channel);
It's far better to stop transmission as soon as possible to prevent
overruns at the remote end. I doubt disabling DMA achieves that.
> +#else
> + unsigned short ier;
> +
> + ier = UART_GET_IER(uart);
> + ier &= ~ETBEI;
> + UART_PUT_IER(uart, ier);
> +#endif
> +}
...
> +static void bfin_serial_rx_chars(struct bfin_serial_port *uart)
> +{
> + struct tty_struct *tty = uart->port.info?uart->port.info->tty:0;
> + unsigned int status, ch, flg;
> +#if defined(CONFIG_BF531) || defined(CONFIG_BF532) || defined(CONFIG_BF533)
> + static int in_break = 0;
> +#endif
> +
> + status = UART_GET_LSR(uart);
> + ch = UART_GET_CHAR(uart);
> + uart->port.icount.rx++;
> +
> +#if defined(CONFIG_BF531) || defined(CONFIG_BF532) || defined(CONFIG_BF533)
> + if (in_break) {
> + if (ch != 0) {
> + in_break = 0;
> + ch = UART_GET_CHAR(uart);
> + }
> + return;
> + }
> +#endif
> +
> + if (status & BI) {
> +#if defined(CONFIG_BF531) || defined(CONFIG_BF532) || defined(CONFIG_BF533)
> + in_break = 1;
> +#endif
> + uart->port.icount.brk++;
> + if (uart_handle_break(&uart->port))
> + goto ignore_char;
> + flg = TTY_BREAK;
> + } else if (status & PE) {
> + flg = TTY_PARITY;
> + uart->port.icount.parity++;
> + } else if (status & OE) {
> + flg = TTY_OVERRUN;
> + uart->port.icount.overrun++;
> + } else if (status & FE) {
> + flg = TTY_FRAME;
> + uart->port.icount.frame++;
> + } else
> + flg = TTY_NORMAL;
Why do many serial drivers when they're first written utterly ignore
termios modes in their reception path by not using port.read_status_mask?
It's broken as stands.
> +
> + if (uart_handle_sysrq_char(&uart->port, ch))
> + goto ignore_char;
> + if (tty)
> + uart_insert_char(&uart->port, status, 2, ch, flg);
> +
> +ignore_char:
> + if (tty)
> + tty_flip_buffer_push(tty);
> +}
...
> +static irqreturn_t bfin_serial_int(int irq, void *dev_id)
> +{
> + struct bfin_serial_port *uart = dev_id;
> + unsigned short status;
> +
> + spin_lock(&uart->port.lock);
> + status = UART_GET_IIR(uart);
> + do {
> + if ((status & IIR_STATUS) == IIR_TX_READY)
> + bfin_serial_tx_chars(uart);
> + if ((status & IIR_STATUS) == IIR_RX_READY)
> + bfin_serial_rx_chars(uart);
> + status = UART_GET_IIR(uart);
> + } while (status &(IIR_TX_READY | IIR_RX_READY));
Space between '&' and '(' please.
> + spin_unlock(&uart->port.lock);
> + return IRQ_HANDLED;
> +}
...
> +static void bfin_serial_dma_rx_chars(struct bfin_serial_port * uart)
> +{
> + struct tty_struct *tty = uart->port.info->tty;
> + int i, flg, status;
> +
> + status = UART_GET_LSR(uart);
> + uart->port.icount.rx += CIRC_CNT(uart->rx_dma_buf.head,
> uart->rx_dma_buf.tail, UART_XMIT_SIZE);;
> +
> +if (status & BI) {
> +uart->port.icount.brk++;
> +if (uart_handle_break(&uart->port))
> +goto dma_ignore_char;
> +flg = TTY_BREAK;
> +} else if (status & PE) {
> +flg = TTY_PARITY;
> +uart->port.icount.parity++;
> +} else if (status & OE) {
> +
Re: 2.6.19.2, 2.6.20 Kernel oops
On Tue, 6 Feb 2007 10:16:17 +0100 Lukas Hejtmanek <[EMAIL PROTECTED]> wrote: > On Tue, Feb 06, 2007 at 01:09:07AM -0800, Andrew Morton wrote: > > > these are lines above: > > > > > > kernel: [ 144.639984] ACPI: Power Button (FF) [PWRF] > > > kernel: [ 144.640006] input: Power Button (CM) as /class/input/input3 > > > kernel: [ 144.640017] ACPI: Power Button (CM) [PWRB] > > > kernel: [ 222.002010] PGD 253115067 PUD 0 > > > > > > > > > > > kernel: [ 222.002013] CPU 0 > > > > > kernel: [ 222.002014] Modules linked in: container fan button ac > > > > > thermal processor myri10ge megaraid_sas serio_raw psmouse evdev > > > > > kernel: [ 222.002020] Pid: 3234, comm: java Not tainted 2.6.20 #1 > > > > > kernel: [ 222.002021] RIP: 0010:[page_to_pfn+0/64] > > > > > [page_to_pfn+0/64] page_to_pfn+0x0/0x40 > > > > > kernel: [ 222.002024] RSP: 0018:81024ebf9ac0 EFLAGS: 00010246 > > > > > kernel: [ 222.002026] RAX: 8102574213c0 RBX: 810256f07800 > > > > > RCX: 81022e5600c0 > > > > > kernel: [ 222.002027] RDX: 0740 RSI: > > > > > RDI: > > > > > kernel: [ 222.002028] RBP: 0740 R08: 0002 > > > > > R09: 8102536b9a40 > > > > > kernel: [ 222.002030] R10: 0007 R11: 80259650 > > > > > R12: > > > > > kernel: [ 222.002031] R13: 810257422460 R14: 0002 > > > > > R15: 81022e5600c0 > > > > > kernel: [ 222.002033] FS: 41061950(0063) > > > > > GS:80649000() knlGS: > > > > > kernel: [ 222.002034] CS: 0010 DS: ES: CR0: > > > > > 8005003b > > > > > kernel: [ 222.002036] CR2: CR3: 000251dbb000 > > > > > CR4: 06e0 > > > > > kernel: [ 222.002037] Process java (pid: 3234, threadinfo > > > > > 81024ebf8000, task 81024ebdc7a0) > > > > > kernel: [ 222.002038] Stack: 804c4f77 810257422400 > > > > > 0002 81024ebf9f28 > > > > > kernel: [ 222.002042] f240 0740 > > > > > 810257422460 0002 > > > > > kernel: [ 222.002044] 804c3ba5 0010 > > > > > 81022e5600c0 8102536b9a40 > > > > > kernel: [ 222.002046] Call Trace: > > > > > kernel: [ 222.002051] [ioat_dma_memcpy_buf_to_pg+71/224] > > > > > ioat_dma_memcpy_buf_to_pg+0x47/0xe0 > > > > > kernel: [ 222.002053] [dma_memcpy_to_iovec+613/768] > > > > > dma_memcpy_to_iovec+0x265/0x300 > > > > > kernel: [ 222.002057] [dma_skb_copy_datagram_iovec+115/656] > > > > > dma_skb_copy_datagram_iovec+0x73/0x290 > > > > > kernel: [ 222.002060] [tcp_recvmsg+1764/3296] > > > > > tcp_recvmsg+0x6e4/0xce0 > > > > > kernel: [ 222.002063] [sock_common_recvmsg+48/80] > > > > > sock_common_recvmsg+0x30/0x50 > > > > > kernel: [ 222.002065] [sock_recvmsg+281/352] > > > > > sock_recvmsg+0x119/0x160 > > > > > kernel: [ 222.002069] [autoremove_wake_function+0/48] > > > > > autoremove_wake_function+0x0/0x30 > > > > > kernel: [ 222.002071] [autoremove_wake_function+0/48] > > > > > autoremove_wake_function+0x0/0x30 > > > > > kernel: [ 222.002073] [__handle_mm_fault+1741/2896] > > > > > __handle_mm_fault+0x6cd/0xb50 > > > > > kernel: [ 222.002076] [sys_recvfrom+250/400] sys_recvfrom+0xfa/0x190 > > > > > kernel: [ 222.002078] [tty_ldisc_deref+100/128] > > > > > tty_ldisc_deref+0x64/0x80 > > > > > kernel: [ 222.002080] [tty_write+540/592] tty_write+0x21c/0x250 > > > > > kernel: [ 222.002083] [system_call+126/131] system_call+0x7e/0x83 > > > > > kernel: [ 222.002084] > > > > > kernel: [ 222.002085] > > > > > kernel: [ 222.002085] Code: 48 8b 07 48 c1 e8 3a 48 8b 14 c5 80 b8 > > > > > 65 80 48 b8 b7 6d db > > > > > kernel: [ 222.002092] RSP > > > > > > > > > > > > > Is that the whole oops message? There should have been a few > > > > interesting > > > > lines preceding the above. > > > > > > I've posted it above. > > > > That's peculiar. > > > > Normally an oops on x86_64 looks like: > > > > Unable to handle kernel NULL pointer dereference at 0038 > > RIP: [] iput+0x18/0x80 > > PGD 3a607067 PUD 27b20067 PMD 0 > > Oops: [1] SMP > > CPU 0 > > Modules linked in: psmouse battery ac thermal fan button > > ... > > > > but you seem to have lost the first few lines. > > It looks like some of these messages have different priority. These lines have > been in different log file... > > kernel: [ 222.002000] Unable to handle kernel NULL pointer dereference at > RIP: > kernel: [ 222.002004] [page_to_pfn+0/64] page_to_pfn+0x0/0x40 > kernel: [ 222.002010] PGD 253115067 PUD 0 > kernel: [ 222.002011] Oops: [1] PREEMPT SMP > kernel: [ 222.002013] CPU 0 Ah, that makes things clearer, thanks. Your page_to_pfn() is: Code; Before first symbol <_RIP>: Code; Before first symbol 0: 48 8b 07 mov(%rdi),%rax Code; 000
Re: [discuss] [patch] mtrr: fix issues with large addresses
On Tuesday 06 February 2007 10:31, Jan Beulich wrote: > >>> Andi Kleen <[EMAIL PROTECTED]> 06.02.07 08:53 >>> > >On Monday 05 February 2007 23:50, Siddha, Suresh B wrote: > >> On Mon, Feb 05, 2007 at 06:19:59PM +0100, Andreas Herrmann wrote: > >> > o added check to restrict base address to 36 bit on i386 > >> > >> Why is this? It can go upto implemented physical bits, right? > > > >In theory it can, but Linux doesn't support it. > > I don't think I remember a restriction here, at least not below 44 bits > (that's where pfn-s would need to become 64-bit wide). The i386 mm code only supports 4 entries in the PGD, so more than 36bit cannot be mapped right now. Also even 64MB barely works (many boxes don't boot), you would likely need at least the 4:4 patch to go >64GB. Also we know there are tons of possible deadlocks in various subsystems when the lowmem:highmem ratio gets so out of hand. Ok it could be probably all fixed with some work (at least the mm part, the deadlocks would be more tricky), but would seem fairly pointless to me because all machines with >36bits support are 64bit capable. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote: > On Mon, 5 Feb 2007, David Woodhouse wrote: > > > > The netfilter example is totally irrelevant here, since 'select' is > > neither necessary nor sufficient for that. Russell and I have both > > pointed that out to you already. > > No, the example IS relevant. > > Why? > > Because you don't seem to be getting the whole "be nice" part. If you'd come down from your high horse for a moment you might realise that I _agree_ with the 'be nice' part, as long as you don't pessimise things for those who _do_ know what they're doing. The thing you want for netfilter is a _GOOD IDEA_. I agree. I've even implemented something _very_ similar, for JFFS2 compression options. If you want to play about with individual compressors you have to enable the 'Advanced options' first; otherwise you get the sane defaults. Unless you really want to get your hands dirty, you don't have to know which compressors we use by default. It's a bad example because it's not relevant to the 'select' question, and you're trying to use it as a straw man; assigning to me a belief I just don't have. > You continually argue as if being nice isn't an issue, and shouldn't be > even an option. Perhaps I haven't spoken carefully enough. I mean to argue that being nice is good -- but that we shouldn't do so in a way which _costs_ those who use the system most. > And maybe you can do it without select for netfilter, but you sure as HELL > cannot do it for things like SCSI and the USB/ATA question. No, you really aren't paying attention. You CAN DO IT WITHOUT SELECT. My point is not that we shouldn't be helpful. My point is that 'select' is the _wrong_ way to be 'helpful', because that's a PITA for other people. My point is that if we _want_ someone less experienced to be able to see 'SCSI' light up automatically when they enable USB_STORAGE, then we can do that IN THE TOOLS, as was demonstrated quite capably a decade ago by the Nemesis folks. But you're obviously not actually interested in reading what people say, so I fully expect you to again pick one sentence out of the above and go off at a tangent with a straw man again. So forget it. At least some guidance on when to use depends vs. select _has_ come out of the thread, which can be written up in Documentation/ and referred to later. That should at least improve the _completely_ arbitrary use of 'select' we currently see, such as the patch which started this thread. And I'll go fix the kconfig tools to have an option for treating all 'select' of user-visible options as dependencies, but the benefit of the people who are the _normal_ users of Kconfig stuff. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
On Mon, Feb 05, 2007 at 04:01:23PM +0200, Pekka Enberg wrote: > Hi Joerg, > > On 2/5/07, Joerg Roedel <[EMAIL PROTECTED]> wrote: > >Hmm, this seems to be the same issue as in [1] and [2]. A page that is > >assumed to belong to the slab but is not longer marked as a slab page. > >Could this be a bug in the memory management? > > The BUG_ON triggers whenever you feed an invalid pointer to kfree() or > kmem_cache_free() so I am guessing the caller is simply broken. Note > that kernels prior to 2.6.18 would quietly corrupt the slab unless > CONFIG_SLAB_DEBUG was enabled which might explain why this hasn't been > noticed before. Ok. I was not aware of that. Thanks for clarification. Joerg -- Joerg Roedel Operating System Research Center AMD Saxony LLC & Co. KG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.20] Regression in dmfe driver
Thomas Bächler <[EMAIL PROTECTED]> writes: > Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe: > support basic carrier detection) breaks networking on my Davicom DM9009. > ethtool always reports there is no link. tcpdump shows incoming packets, > but TX is disabled. Reverting the above patch fixes the problem. disable link detection in your network config then (eg: MII_NOT_SUPPORTED=yes in ifcfg-XXX depending on the distro). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [discuss] [patch] mtrr: fix issues with large addresses
>> I don't think I remember a restriction here, at least not below 44 bits >> (that's where pfn-s would need to become 64-bit wide). > >The i386 mm code only supports 4 entries in the PGD, so more than 36bit cannot >be mapped right now. That has nothing to do with the number of physical address bits. >Also even 64MB barely works (many boxes don't boot), you would likely >need at least the 4:4 patch to go >64GB. Also we know there are tons >of possible deadlocks in various subsystems when the lowmem:highmem ratio >gets so out of hand. > >Ok it could be probably all fixed with some work (at least the mm part, >the deadlocks would be more tricky), but would seem fairly >pointless to me because all machines with >36bits support are 64bit capable. That's a different story, and certainly a limiting factor. But this shouldn't e.g. disallow (hypothetical?) systems that have a very sparse memory map extending beyond 64G. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH] To list all active probes in the system
Hi folks
I have developed a patch, that lists all active probes in the
system. I have done this through /proc interface. Currently list is
available under /proc/kprobes/list. Any suggestions for better place and
name??
My patch scans through kprobe_table[],lists out all the probes, in an
order it finds them. It also takes care of aggregate handlers. Type of
the probe is recognised by the kind of pre_handler it has. I have
assigned letter for each probe, like "k" for kprobes, "j" for jprobes,
"r" for kretprobes. Along with type of the probe,it also lists the
address of the instruction,its symbolic name(function name + offset) and
the module name.
Output of /proc/kprobes/list looks like this
==
[EMAIL PROTECTED] a]# cat /proc/kprobes/list
c00c0720 r .sys_write+0x0
c00c0720 k .sys_write+0x0
c004c550 k .do_fork+0x0
c004c550 k .do_fork+0x0
c004c550 j .do_fork+0x0
c00bfed4 r .vfs_read+0x0
c00bddb4 r .sys_open+0x0
c00c0694 r .sys_read+0x0
c00c0694 k .sys_read+0x0
c004c554 k .do_fork+0x4
d00781b0 k .autofs4_dentry_release+0x0 autofs4
c00275d0 k kretprobe_trampoline+0x0
c00bfd18 k .vfs_write+0x0
Please let me know your comments on this.
Signed-off-by: Srinivasa DS <[EMAIL PROTECTED]>
fs/proc/root.c |4 ++
include/linux/kprobes.h |7 +++
kernel/kprobes.c| 87
3 files changed, 98 insertions(+)
Index: linux-2.6.20/kernel/kprobes.c
===
--- linux-2.6.20.orig/kernel/kprobes.c
+++ linux-2.6.20/kernel/kprobes.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -815,6 +816,92 @@ static int __init init_kprobes(void)
return err;
}
+static void __kprobes report_probe(struct seq_file *pi, struct kprobe *p,
+ const char *sym, int offset,char *modname)
+{
+ char *kprobe_type;
+
+ if (p->pre_handler == pre_handler_kretprobe)
+ kprobe_type = "r";
+ else if (p->pre_handler == setjmp_pre_handler)
+ kprobe_type = "j";
+ else
+ kprobe_type = "k";
+ if (sym)
+ seq_printf(pi, "%p %s %s+0x%x %s\n", p->addr, kprobe_type,
+ sym, offset, (modname ? modname : " "));
+ else
+ seq_printf(pi, "%p %s %p\n", p->addr, kprobe_type, p->addr);
+}
+
+void __kprobes *kprobe_seq_start(struct seq_file *f, loff_t *pos)
+{
+ return (*pos < KPROBE_TABLE_SIZE) ? pos : NULL;
+}
+
+void __kprobes *kprobe_seq_next(struct seq_file *f, void *v, loff_t *pos)
+{
+ (*pos)++;
+ if (*pos >= KPROBE_TABLE_SIZE)
+ return NULL;
+ return pos;
+}
+
+void __kprobes kprobe_seq_stop(struct seq_file *f, void *v)
+{
+ /* Nothing to do */
+}
+
+int __kprobes show_kprobe_addr(struct seq_file *pi, void *v)
+{
+ struct hlist_head *head;
+ struct hlist_node *node;
+ struct kprobe *p, *kp;
+ unsigned int i = *(loff_t *) v;
+ unsigned long size, offset = 0;
+ char *modname, namebuf[128];
+ const char *sym = NULL;
+
+ head = &kprobe_table[i];
+ preempt_disable();
+ hlist_for_each_entry_rcu(p, node, head, hlist) {
+ sym = kallsyms_lookup((unsigned long)p->addr, &size,
+ &offset, &modname, namebuf);
+ if (p->pre_handler == aggr_pre_handler) {
+ list_for_each_entry_rcu(kp, &p->list, list)
+report_probe(pi, kp, sym, offset, modname);
+ } else
+ report_probe(pi, p, sym, offset, modname);
+ }
+ preempt_enable();
+ return 0;
+}
+
+struct seq_operations kprobes_seq_ops = {
+ .start = kprobe_seq_start,
+ .next = kprobe_seq_next,
+ .stop = kprobe_seq_stop,
+ .show = show_kprobe_addr
+};
+
+static int __kprobes kprobes_open(struct inode *inode, struct file *filp)
+{
+ return seq_open(filp, &kprobes_seq_ops);
+}
+
+static struct file_operations proc_kprobes_operations = {
+ .open = kprobes_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= seq_release,
+};
+
+void __kprobes proc_kprobe_init(void)
+{
+ proc_mkdir("kprobes", NULL);
+ create_seq_entry("kprobes/list", 0, &proc_kprobes_operations);
+}
+
__initcall(init_kprobes);
EXPORT_SYMBOL_GPL(register_kprobe);
Index: linux-2.6.20/include/linux/kprobes.h
===
--- linux-2.6.20.orig/include/linux/kprobes.h
+++ linux-2.6.20/include/linux/kprobes.h
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_KPROBES
#include
@@ -167,6 +168,8 @@ extern void show_registers(struct pt_reg
extern kprobe_opcode_t *get_insn_slot(void);
extern void free_insn_slot(kprobe_opcode_t *slot, int dirty);
extern void kprobes_inc_nmissed_count(struct kprobe *p);
+extern void create_seq_entry(char *name, mode_t mode,
+ const struct file_operations *f);
/* Get the kprobe at this addr (if any) - called with preemption disabled */
struct kprobe *get_kprobe(void *addr);
@@ -203,6 +206,7 @@ struc
Re: [RFC] [PATCH] To list all active probes in the system
On Tue, Feb 06, 2007 at 03:25:35PM +0530, Srinivasa Ds wrote: > Hi folks > > I have developed a patch, that lists all active probes in the > system. I have done this through /proc interface. Currently list is > available under /proc/kprobes/list. Any suggestions for better place and > name?? /debug/kprobes/list? :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] To list all active probes in the system
On Tue, 06 Feb 2007 15:25:35 +0530 Srinivasa Ds <[EMAIL PROTECTED]> wrote: > I have developed a patch, that lists all active probes in the > system. userspace added the probes, so userspace should know where they all are? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] To list all active probes in the system
Andrew Morton wrote: > On Tue, 06 Feb 2007 15:25:35 +0530 Srinivasa Ds <[EMAIL PROTECTED]> wrote: > >> I have developed a patch, that lists all active probes in the >> system. > > userspace added the probes, so userspace should know where they all are? Irrespective of the number of users/modules that use kprobes, this is one place where you can get all the info. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] To list all active probes in the system
Christoph Hellwig wrote: > On Tue, Feb 06, 2007 at 03:25:35PM +0530, Srinivasa Ds wrote: >> Hi folks >> >> I have developed a patch, that lists all active probes in the >> system. I have done this through /proc interface. Currently list is >> available under /proc/kprobes/list. Any suggestions for better place and >> name?? > > /debug/kprobes/list? :) > Good Idea, I will update my patch to use debugfs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 -- Loads of section mismatches
On Mon, Feb 05, 2007 at 11:48:57AM +0100, Andi Kleen wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/x86_64-mm-move-startup_32-in-texthead-section.patch > > > > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/x86_64-mm-break-init-in-two-parts-to-avoid-modpost-warnings.patch > > The two part init / head.S patch was considered too intrusive late > in the game. > Near all of the other section patches should have made it in though. > Yes all others have gone in. I found one more which is present in rc-mm2, but can't see it in rc6-mm3. http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm2/broken-out/i386-modpost-apic-related-warning-fixes.patch Andrew seems to have dropped it. Not sure why. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3, try #2] Blackfin: serial driver for Blackfin architecture against Linux kernel 2.6.20
On 2/6/07, Russell King <[EMAIL PROTECTED]> wrote:
I think you have a bit of work to do on this driver; it seems to be
missing all termios handling apart from setting the baud rate.
Yes, only baud rate setting is enabled. We'll implement others in future.
Moreover, it's re-using the 8250 driver port range despite claiming
to have a proper allocation.
Thanks to point this out, although 8250 driver and bfin serial driver
will never be enabled at the same time.
Is there a port map to show which ports are used? Or how do I know
which port is available?
(I don't maintain serial anymore but I do reserve the right to
occasionally review serial code.)
On Tue, Feb 06, 2007 at 11:20:11AM +0800, Wu, Bryan wrote:
> +/* We've been assigned a range on the "Low-density serial ports" major */
> +#define SERIAL_BFIN_MAJORTTY_MAJOR
> +#define MINOR_START 64
If you've been assigned a range in the low density serial ports major,
why aren't you using it instead of taking the 8250 drivers range (thereby
preventing PCMCIA cards from ever being used) ?
> +#if defined(CONFIG_BAUD_9600)
> +#define CONSOLE_BAUD_RATE 9600
> +#elif defined(CONFIG_BAUD_19200)
> +#define CONSOLE_BAUD_RATE 19200
> +#elif defined(CONFIG_BAUD_38400)
> +#define CONSOLE_BAUD_RATE 38400
> +#elif defined(CONFIG_BAUD_57600)
> +#define CONSOLE_BAUD_RATE 57600
> +#elif defined(CONFIG_BAUD_115200)
> +#define CONSOLE_BAUD_RATE 115200
> +#endif
What's wrong with passing console=ttyblackfin0,115200 to the kernel or
via some default command line?
We are not used to pass parameter like that. Put it in Kconfig option
is more friendly to our customer.
> +/*
> + * interrupts are disabled on entry
> + */
> +static void bfin_serial_stop_tx(struct uart_port *port)
> +{
> + struct bfin_serial_port *uart = (struct bfin_serial_port *)port;
> +
> +#ifdef CONFIG_SERIAL_BFIN_DMA
> +disable_dma(uart->tx_dma_channel);
It's far better to stop transmission as soon as possible to prevent
overruns at the remote end. I doubt disabling DMA achieves that.
UART peripheral on blackfin has two work mode, one is PIO, the other is DMA.
The driver enables two mode. If overruns at the remote end is critical
for someone, PIO is a better choice.
> +#else
> + unsigned short ier;
> +
> + ier = UART_GET_IER(uart);
> + ier &= ~ETBEI;
> + UART_PUT_IER(uart, ier);
> +#endif
> +}
...
> +static void bfin_serial_rx_chars(struct bfin_serial_port *uart)
> +{
> + struct tty_struct *tty = uart->port.info?uart->port.info->tty:0;
> + unsigned int status, ch, flg;
> +#if defined(CONFIG_BF531) || defined(CONFIG_BF532) || defined(CONFIG_BF533)
> + static int in_break = 0;
> +#endif
> +
> + status = UART_GET_LSR(uart);
> + ch = UART_GET_CHAR(uart);
> + uart->port.icount.rx++;
> +
> +#if defined(CONFIG_BF531) || defined(CONFIG_BF532) || defined(CONFIG_BF533)
> + if (in_break) {
> + if (ch != 0) {
> + in_break = 0;
> + ch = UART_GET_CHAR(uart);
> + }
> + return;
> + }
> +#endif
> +
> + if (status & BI) {
> +#if defined(CONFIG_BF531) || defined(CONFIG_BF532) || defined(CONFIG_BF533)
> + in_break = 1;
> +#endif
> + uart->port.icount.brk++;
> + if (uart_handle_break(&uart->port))
> + goto ignore_char;
> + flg = TTY_BREAK;
> + } else if (status & PE) {
> + flg = TTY_PARITY;
> + uart->port.icount.parity++;
> + } else if (status & OE) {
> + flg = TTY_OVERRUN;
> + uart->port.icount.overrun++;
> + } else if (status & FE) {
> + flg = TTY_FRAME;
> + uart->port.icount.frame++;
> + } else
> + flg = TTY_NORMAL;
Why do many serial drivers when they're first written utterly ignore
termios modes in their reception path by not using port.read_status_mask?
It's broken as stands.
> +
> + if (uart_handle_sysrq_char(&uart->port, ch))
> + goto ignore_char;
> + if (tty)
> + uart_insert_char(&uart->port, status, 2, ch, flg);
> +
> +ignore_char:
> + if (tty)
> + tty_flip_buffer_push(tty);
> +}
...
> +static irqreturn_t bfin_serial_int(int irq, void *dev_id)
> +{
> + struct bfin_serial_port *uart = dev_id;
> + unsigned short status;
> +
> + spin_lock(&uart->port.lock);
> + status = UART_GET_IIR(uart);
> + do {
> + if ((status & IIR_STATUS) == IIR_TX_READY)
> + bfin_serial_tx_chars(uart);
> + if ((status & IIR_STATUS) == IIR_RX_READY)
> + bfin_serial_rx_chars(uart);
> + status = UART_GET_IIR(uart);
> + } while (status &(IIR_TX_READY | IIR_RX_READY));
Space between '&' and '(' please.
> + spin_unlock(&uart->port.lock);
> + return IRQ_HANDLED;
> +}
...
> +static void bfin_serial_dma_rx_chars(struct bfin_serial_port * uar
Re: [patch 3/3] mm: make read_cache_page synchronous
On Tue, 6 Feb 2007 09:02:33 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote: > Ensure pages are uptodate after returning from read_cache_page, which allows > us to cut out most of the filesystem-internal PageUptodate_NoLock calls. Normally it's good to rename functions when we change their behaviour, but I guess any missed (or out-of-tree) filesystems will just end up doing a pointless wait_on_page_locked() and will continue to work OK, yes? > I didn't have a great look down the call chains, but this appears to fixes 7 > possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in > ecryptfs, > 1 in jffs2, and a possible cleared data overwritten with readpage in > block2mtd. > All depending on whether the filler is async and/or can return with a > !uptodate > page. > > Also, a memory leak in sys_swapon(). Separate 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: [patch 2/3] fs: buffer don't PageUptodate without page locked
On Tue, Feb 06, 2007 at 12:21:40AM -0800, Andrew Morton wrote:
> On Tue, 6 Feb 2007 09:02:23 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]>
> wrote:
>
> > __block_write_full_page is calling SetPageUptodate without the page locked.
> > This is unusual, but not incorrect, as PG_writeback is still set.
> >
> > However with the previous patch, this is now a problem: so don't bother
> > setting the page uptodate in this case (it is weird that the write path
> > does such a thing anyway). Instead just leave it to the read side to bring
> > the page uptodate when it notices that all buffers are uptodate.
> >
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> >
> > Index: linux-2.6/fs/buffer.c
> > ===
> > --- linux-2.6.orig/fs/buffer.c
> > +++ linux-2.6/fs/buffer.c
> > @@ -1679,6 +1679,7 @@ static int __block_write_full_page(struc
> > */
> > BUG_ON(PageWriteback(page));
> > set_page_writeback(page);
> > + unlock_page(page);
> >
> > do {
> > struct buffer_head *next = bh->b_this_page;
> > @@ -1688,7 +1689,6 @@ static int __block_write_full_page(struc
> > }
> > bh = next;
> > } while (bh != head);
> > - unlock_page(page);
> >
> > err = 0;
> > done:
>
> Why this change? Without looking at it too hard, it seems that if
> submit_bh() completes synchronously, this thread can end up playing with
> the buffers on a non-locked, non-PageWriteback page. Someone else could
> whip the buffers away and oops?
Hmm, it definitely shouldn't be there, it leaked in from another patch
to bring partiy with the error handling...
Here is an updated patch.
--
__block_write_full_page is calling SetPageUptodate without the page locked.
This is unusual, but not incorrect, as PG_writeback is still set.
However with the previous patch, this is now a problem: so don't bother
setting the page uptodate in this case (it is weird that the write path
does such a thing anyway). Instead just leave it to the read side to bring
the page uptodate when it notices that all buffers are uptodate.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/buffer.c
===
--- linux-2.6.orig/fs/buffer.c
+++ linux-2.6/fs/buffer.c
@@ -1698,17 +1698,8 @@ done:
* clean. Someone wrote them back by hand with
* ll_rw_block/submit_bh. A rare case.
*/
- int uptodate = 1;
- do {
- if (!buffer_uptodate(bh)) {
- uptodate = 0;
- break;
- }
- bh = bh->b_this_page;
- } while (bh != head);
- if (uptodate)
- SetPageUptodate(page);
end_page_writeback(page);
+
/*
* The page and buffer_heads can be released at any time from
* here on.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1][RFC] mm: prepare_write positive return value
Almost all read/write operation handles data with chunks(segments or pages)
and result has integral behaviour for folowing scenario:
for_each_chunk() {
res = op();
if(IS_ERROR(res))
return progress ? progress : res;
progress += res;
}
prepare_write may has integral behaviour in case of blksize < pgsize,
for example we successfully allocated/read some blocks, but not all of them,
and than some error happend. Currently we eliminate this progress by doing
vmtrunate() after prepare_has failed.
It is good to have ability to signal about this progress. Interprete positive
prepare_write() ret code as bytes num that fs ready to handle at this moment.
I've ask SAW, he think it is sane. This size always less than PAGE_CACHE_SIZE
so it less than AOP_TRUNCATED_PAGE too.
BTH: This approach was used in OpenVZ 2.6.9 kernel in order to make FS with
delayed allocation more correct, and its works well.
I think not everybody will happy about this, but let's discuss all advantages
and disadvantages of this change.
Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]>
-
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 62632f5..b4f6eac 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -239,7 +239,11 @@ static int do_lo_send_aops(struct loop_device *lo, struct
bio_vec *bvec,
page_cache_release(page);
continue;
}
- goto unlock;
+ if (ret > 0 && ret < PAGE_CACHE_SIZE)
+ /* prepare_write demands limit size of bytes. */
+ size = min(size, (unsigned)ret);
+ else
+ goto unlock;
}
transfer_result = lo_do_transfer(lo, WRITE, page, offset,
bvec->bv_page, bv_offs, size, IV);
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 1e5d2ba..b5eebe8 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -454,6 +454,17 @@ static int ecryptfs_write_inode_size_to_header(struct file
*lower_file,
}
lower_a_ops = lower_inode->i_mapping->a_ops;
rc = lower_a_ops->prepare_write(lower_file, header_page, 0, 8);
+ if (unlikely(rc > 0 && rc < PAGE_CACHE_SIZE)) {
+ /*
+* prepare_write can handle less bytes whan we need. This is not likely
+* to happend realy because usualy we need only one block. In order to
+* preserve prepare/commit balanced invoke commit end fail.
+*/
+ int ret;
+ ret = lower_a_ops->commit_write(lower_file, header_page, 0, rc);
+ rc = ret ? ret : -ENOSPC;
+ goto unlock;
+ }
file_size = (u64)i_size_read(inode);
ecryptfs_printk(KERN_DEBUG, "Writing size: [0x%.16x]\n", file_size);
file_size = cpu_to_be64(file_size);
@@ -462,6 +473,7 @@ static int ecryptfs_write_inode_size_to_header(struct file
*lower_file,
kunmap_atomic(header_virt, KM_USER0);
flush_dcache_page(header_page);
rc = lower_a_ops->commit_write(lower_file, header_page, 0, 8);
+unlock:
if (rc < 0)
ecryptfs_printk(KERN_ERR, "Error commiting header page "
"write\n");
diff --git a/fs/namei.c b/fs/namei.c
index b305589..723db81 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2704,6 +2704,16 @@ retry:
page_cache_release(page);
goto retry;
}
+ if (unlikely(err > 0 && err < PAGE_CACHE_SIZE)) {
+ /*
+* prepare_write can handle less bytes whan we need. This is not likely
+* to happend realy because usualy we need only one block. In order to
+* preserve prepare/commit balanced invoke commit end fail.
+*/
+ int ret;
+ ret = mapping->a_ops->commit_write(NULL, page, 0, err);
+ err = ret ? ret : -ENOSPC;
+ }
if (err)
goto fail_map;
kaddr = kmap_atomic(page, KM_USER0);
diff --git a/fs/splice.c b/fs/splice.c
index 2fca6eb..d2b92bf 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -652,6 +652,17 @@ find_page:
if (unlikely(ret)) {
loff_t isize = i_size_read(mapping->host);
+ if (ret > 0 && ret < PAGE_CACHE_SIZE) {
+ /*
+* prepare_write demands limit size of bytes. In order to
+* preserve prepare/commit balanced invoke commit end fail.
+* Initial i_size saved, so vmtruncate safely restore it later.
+*/
+ int ret2;
+ ret2 = mapping->a_ops->commit_write(file, page, offset,
+ offset + ret);
+ ret = ret2 ? ret2 : -ENOSPC;
+ }
if (ret != AOP_TRUNCATED_PAGE)
unlock_page(page)
[PATCH 1/1][RFC] mm: prepare_write positive return value
This patch solve ext3/4 retry loop issue
Issue description:
What we can do if block_prepare_write fail inside ext3_prepare_write ?
a) Stop transaction and do retry if possible, but what happend if
reboot comes after journal_force_commit, but before we exhaust
all retry attempts and generic_file_buffered_write call trancate?
We may get allocated blocks outside i_size. Witch is bad.
b) Commit newly allocated blocks. This approach was used after Andrey's patch.
But if reboot comes, or error happend, user will be surprised that i_size
increased but blocks are zero filed. This is internal write operation state
becames visiable to user. Witch is also bad.
c) Just return as match bytes as we can deal with rigth now back to
caller, and let's caller handles it and than call commit. In this scenario
we never stop journal in the midle of some internal fs operation.
If reboot comes before commit trunsaction was't closed so it will
be droped while journal replay.
Only (c) tend to garantie attomic data operation.
Also fix some issues introduced by
retries-in-ext3_prepare_write-violate-ordering-requirements:
i_size may increase after error happend.
possible data corruption caused commiting non uptodate bh.
Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]>
-
diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
index dba6dd2..4c5e9f7 100644
--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -1154,6 +1154,18 @@ static int do_journal_get_write_access(handle_t *handle,
* transaction must include the content of the newly allocated blocks.
* This content is expected to be set to zeroes by block_prepare_write().
* 2006/10/14 SAW
+ * What we can do if some blocks was allocated?
+ * a) Stop transaction and do retry if possible, but what happend if
+ *reboot comes after journal_force_commit, but before we exhaust
+ *all retry attempts and caller call trancate?
+ *We may get allocated blocks outside i_size. Witch is bad.
+ * b) Commit newly allocated blocks. And if reboot comes, user will be
+ *surprised that i_size increased but blocks are zero filed. Witch is
+ *also bad.
+ * c) Just return as match bytes as we can deal with rigth now back to
+ *caller, and if reboot comes trunsaction was't closed so it will
+ *be droped while journal replay.
+ * Only (c) tend to garantie attomic data operation.
*/
static int ext3_prepare_failure(struct file *file, struct page *page,
unsigned from, unsigned to)
@@ -1186,7 +1198,7 @@ skip:
block_start = to;
break;
}
- if (!buffer_mapped(bh))
+ if (!buffer_mapped(bh) || !buffer_uptodate(bh))
/* prepare_write failed on this bh */
break;
if (ext3_should_journal_data(mapping->host)) {
@@ -1204,8 +1216,8 @@ skip:
if (block_start <= from)
goto skip;
- /* commit allocated and zeroed buffers */
- return mapping->a_ops->commit_write(file, page, from, block_start);
+ /* return number of bytes till last mapped && uptodate block */
+ return block_start - from;
}
static int ext3_prepare_write(struct file *file, struct page *page,
@@ -1239,7 +1251,8 @@ retry:
failure:
ret2 = ext3_prepare_failure(file, page, from, to);
- if (ret2 < 0)
+ if (ret2)
+ /* ready to partial write, or fatal error */
return ret2;
if (ret == -ENOSPC && ext3_should_retry_alloc(inode->i_sb, &retries))
goto retry;
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 806eee1..da39f80 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1153,6 +1153,18 @@ static int do_journal_get_write_access(handle_t *handle,
* transaction must include the content of the newly allocated blocks.
* This content is expected to be set to zeroes by block_prepare_write().
* 2006/10/14 SAW
+ * What we can do if some blocks was allocated?
+ * a) Stop transaction and do retry if possible, but what happend if
+ *reboot comes after journal_force_commit, but before we exhaust
+ *all retry attempts and caller call trancate?
+ *We may get allocated blocks outside i_size. Witch is bad.
+ * b) Commit newly allocated blocks. And if reboot comes, user will be
+ *surprised that i_size increased but blocks are zero filed. Witch is
+ *also bad.
+ * c) Just return as match bytes as we can deal with rigth now back to
+ *caller, and if reboot comes trunsaction was't closed so it will
+ *be droped while journal replay.
+ * Only (c) tend to garantie attomic data operation.
*/
static int ext4_prepare_failure(struct file *file, struct page *page,
unsigned from, unsigned to)
@@ -1185,7 +1197,7 @@ skip:
block_start = to;
break;
}
- if (!buffer_mapped(bh)
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Mon, 2007-02-05 at 19:20 -0800, Andreas Gruenbacher wrote: > On Monday 05 February 2007 11:02, Christoph Hellwig wrote: > > On Mon, Feb 05, 2007 at 10:58:26AM -0800, Trond Myklebust wrote: > > > On Mon, 2007-02-05 at 18:44 +, Christoph Hellwig wrote: > > > > Just FYI: Al was very opposed to the idea of passing the vfsmount to > > > > the vfs_ helpers, so you should discuss this with him. > > > > > > > > Looking at the actual patches I see you're lazy in a lot of places. > > > > Please make sure that when you introduce a vfsmount argument somewhere > > > > that it is _always_ passed and not just when it's conveniant. Yes, > > > > that's more work, but then again if you're not consistant anyone > > > > half-serious will laught at a security model using this infrasturcture. > > > > > > nfsd in particular tends to be a bit lazy about passing around vfsmount > > > info. Forcing it to do so should not be hard since the vfsmount is > > > already cached in the "struct export" (which can be found using the > > > filehandle). It will take a bit of re-engineering in order to pass that > > > information around inside the nfsd code, though. > > > > I actually have a patch to fix that. It's part of a bigger series > > that's not quite ready, but I hope to finish all of it this month. > > It's actually not hard to "fix", and nfsd would look a little less weird. But > what would this add, what do pathnames mean in the context of nfsd, and would > nfsd actually become less weird? > > On the wire, nfs transmits file handles, not filenames. The file handle > usually contains the inode numbers of the file and the containing directory. > > The code in fs/exportfs/expfs.c:find_exported_dentry() shows that fh_verify() > should return a dentry that may be connected or not, depending on the export > options and whether it's a file or directory. Together with the vfsmount from > the svc_export, we could compute a pathname. > > But there is no way to tell different hardlinks to the same inode in the same > directory from each other (both the file and directory inode are the same), > and depending on the export options, we may or may not be able to distinguish > different hardlinks across directories. Who cares? There is no way to export a partial directory, and in any case the subtree_check crap is borken beyond repair (see cross-directory renames which lead to actual changes to the filehandle - broken, broken, broken). > If the nohide or crossmnt export options are used, we might run into similar > aliasing issues with mounts (I'm not sure about this). Wrong. Those create new export points since you are crossing into a different filesystem. > So we could compute pathnames, but they wouldn't be very meaningful. Instead > of going that way, it seems more reasonable to not do pathname based access > control for the kernel kernel nfsd at all. Passing NULL as the vfsmounts does > that. With a properly configured nfsd, the areas that remote users could > access would still be well confined. Huh? Even if you don't pass in a vfsmount, you _still_ need to pass in a super_block. Inodes are only unique per filesystem. In fact, on an ideal NFS export, there is no ambiguity between the two (see above comment about subtree_check) since the entire filesystem will be exported. > The focus with this whole pathname based security stuff really is to be able > to better confine local processes. The kernel nfsd is a kernel thread, and as > such, confining it from a security point of view cannot really work, anyway. > > > > Note also that it might be nice to enforce the vfsmount argument by > > > replacing the existing dentry parameters with a struct path instead of > > > adding an extra reference to the vfsmount to existing functions. > > > > That definitly sounds like a good idea, independent of whether we want > > to pass the vfsmount in more places or not. > > Note that you can still pass a NULL vfsmount in a struct path. ...but we will have Dick Cheney track you down and shoot you if you do. The point is that you only have to check _one_ argument (the initialisation of the struct path) instead of having a check for every function argument in the vfs. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] mm: make read_cache_page synchronous
Andrew Morton wrote: On Tue, 6 Feb 2007 09:02:33 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote: Ensure pages are uptodate after returning from read_cache_page, which allows us to cut out most of the filesystem-internal PageUptodate_NoLock calls. Normally it's good to rename functions when we change their behaviour, but I guess any missed (or out-of-tree) filesystems will just end up doing a pointless wait_on_page_locked() and will continue to work OK, yes? Yeah. I didn't have a great look down the call chains, but this appears to fixes 7 possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in block2mtd. All depending on whether the filler is async and/or can return with a !uptodate page. Also, a memory leak in sys_swapon(). Separate patch? Well its fixed by virtue of read_cache_page now correctly dropping the page refcount if it finds the page !uptodate, rather than any special logic I added. I can do another patch though. No problem, I'll be resending the series after this round of feedback. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Writing performance problem with SAS1068
Hello, I've stumbled onto a strange performance problem on a new server: reading from disks is fast (70-80MB/s), but writing is extremely slow (13-15MB/s). I've measured it like this: dd if=/dev/zero of=/dev/sdd bs=4096 count=65536 conv=fdatasync 65536+0 records in 65536+0 records out 268435456 bytes (268 MB) copied, 17.7004 seconds, 15.2 MB/s *but*: if I rebuild the kernel and change CONFIG_FUSION_MAX_SGE from 40 (Fedora's default) to 128 (maximum value), it suddenly gets much faster: 31MB/s! Looks very much like an interrupt problem to me. Maybe increasing the scatter gather mitigates the problem of missing completion notifications. Evidence: Exhibit A: custom kernel config for 2.6.18-1.2257.fc5.bernie http://www.codewiz.org/helium_logs/config Exhibit B: dmesg output from said kernel http://www.codewiz.org/helium_logs/dmesg Exhibit C: misc proc files, and all that http://www.codewiz.org/helium_logs/ Exhibit D: motherboard and chipset specification http://www.supermicro.com/products/motherboard/Xeon3000/3010/PDSME+.cfm Circumstantial evidence: - Seems to affect just the LSI SAS1068 PCI-X controller. The on-board AHCI controller writes very fast (>60MB/s) - I've seen a very similar writing bottleneck with a Promise TX4 SATA controller (not PCI-X) on a server with a similar motherboard (Supermicro with Mukilteo 3000). - Passing mpt_msi_enable=1 doesn't change anything - FreeBSD 6.2 is even slower: writes at 7MB/s - OpenSolaris is much, much slower... less than 1MB/s. - Windows Vista (rc something) writes at 90MB/s. Too fast to believe, maybe dd from Cygwin is misbehaving. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] mm: make read_cache_page synchronous
On Tue, Feb 06, 2007 at 12:28:39AM -0800, Andrew Morton wrote: > > > > Also, a memory leak in sys_swapon(). > > Separate patch? Gack, I'm an idiot, there is no memory leak :P - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] mm: fix PageUptodate memorder
Andrew Morton wrote:
On Tue, 6 Feb 2007 09:02:11 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
+static inline void __SetPageUptodate(struct page *page)
+{
+#ifdef CONFIG_S390
if (!test_and_set_bit(PG_uptodate, &page->flags))
page_test_and_clear_dirty(page);
-}
#else
-#define SetPageUptodate(page) set_bit(PG_uptodate, &(page)->flags)
+ /*
+* Memory barrier must be issued before setting the PG_uptodate bit,
+* so all previous writes that served to bring the page uptodate are
+* visible before PageUptodate becomes true.
+*
+* S390 is guaranteed to have a barrier in the test_and_set operation
+* (see Documentation/atomic_ops.txt).
+*
+* XXX: does this memory barrier need to be anything special to
+* handle things like DMA writes into the page?
+*/
+ smp_wmb();
+ set_bit(PG_uptodate, &(page)->flags);
#endif
+}
+
+static inline void SetPageUptodate(struct page *page)
+{
+ WARN_ON(!PageLocked(page));
+ __SetPageUptodate(page);
+}
+
+static inline void SetNewPageUptodate(struct page *page)
+{
+ __SetPageUptodate(page);
+}
I was panicing for a minute when I saw that __SetPageUptodate() in there.
Conventionally the __SetPageFoo namespace is for nonatomic updates to
page->flags. Can we call this something different?
Duh, of course, sorry.
What a fugly patchset :(
Fugly problem. One could fix it by always locking the page, but I was
worried about Hugh flaming me if I tried that ;)
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
On Mon, Feb 05, 2007 at 10:17:44PM -0500, Theodore Tso wrote: > > sysrq+u is helpful. It is like \( sysrq+s && make sure no further writes > > go to disk \). > > I agree it is useful, but if we're going to do it we really should do > it right. We should have real revoke() functionality on file > descriptors, which revokes all of the mmap()'s (any attempt to write > into a previously read/write mmap will cause a SEGV) as well as > changing f_mode, and then use that to implement emergency read-only > remount. Revoke is only part of it. What we really need is proper forced unmount support. That means revoking any kind of userspace access, blocking new access and making sure the ondisk image is coherent. This would definitly be a useful feature, but it's a lot of work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Mon, Feb 05, 2007 at 07:20:35PM -0800, Andreas Gruenbacher wrote: > It's actually not hard to "fix", and nfsd would look a little less weird. But > what would this add, what do pathnames mean in the context of nfsd, and would > nfsd actually become less weird? It's not actually a pathname we care about, but a vfsmount + dentry combo. That one means as much in nfsd as elsewhere. We want nfsd to obey r/o or noatime mount flags if /export/foo is exported with them but /foo not. Even better would be to change nfsd so it creates it's own non-visible vfsmount for the filesystems it exports.. > But there is no way to tell different hardlinks to the same inode in the same > directory from each other (both the file and directory inode are the same), > and depending on the export options, we may or may not be able to distinguish > different hardlinks across directories. This doesn't matter. hardlinks are per definition on the same vfsmount. > If the nohide or crossmnt export options are used, we might run into similar > aliasing issues with mounts (I'm not sure about this). no, we won't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Tue, Feb 06, 2007 at 12:51:52AM -0800, Trond Myklebust wrote: > Who cares? There is no way to export a partial directory, and in any > case the subtree_check crap is borken beyond repair (see cross-directory > renames which lead to actual changes to the filehandle - broken, broken, > broken). It's getting a little oftopic for this thread, but is there a chance we could just kill that crap after a resonable deprecation period? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Mon, Feb 05, 2007 at 06:13:26PM -0800, Andreas Gruenbacher wrote: > On Monday 05 February 2007 10:44, Christoph Hellwig wrote: > > Looking at the actual patches I see you're lazy in a lot of places. > > Please make sure that when you introduce a vfsmount argument somewhere > > that it is _always_ passed and not just when it's conveniant. Yes, that's > > more work, but then again if you're not consistant anyone half-serious > > will laught at a security model using this infrasturcture. > > It may appear like laziness, but it's not. Let's look at where we're passing > NULL at the moment: You know, I've tracked a lot of this down previously when I submitted patches to add vfsmount arguments to the vfs_ helpers, just to get tought by Al that this is a bad idea :) > fs/hpfs/namei.c > > In hpfs_unlink, hpfs truncates one of its own inodes through > notify_change(). You definitely don't want any lsms to interfere here, > pathname based or not; hpfs should probably truncate its inode itself > instead. But given that hpfs goes via the vfs, we at least pass NULL > to indicate that this file really has no meaningful paths to it > anymore. (In addition, we don't really have a vfsmount at this > point anymore, and neither would it make sense to pass it there.) > > To play more nicely with other lsms, hpfs could mark the inode as > private before attempting the truncate. The right fix would be to not go through the vfs. Or even better to remove the utter hack. See my previous patch on this subject and the discussion started on it. > fs/reiserfs/xattr.c > > The directories an files that reiserfs uses internally to store xattrs > are hanging off ".reiserfs_priv/xattrs" in the filesystem. This part > of the namespace is not accessible or visible from user space though > except through the xattr syscalls. > > Reiserfs should probably just mark all its xattr inodes as private in > order > to play nicely with other lsms. As far as pathname based lsms are > concerned, > pathnames to those fs-internal objects are meaningless though, and so we > pass NULL here. Well, the 100% correct fix would be to rip out the braindead reiserfs xattr code :) Of course that's not an option, but reiserfs would be much better of stop using vfs_rmdir. It really doesn't need most of the checks in there and should just call into reiserfs_rmdir instead of doing this useless trip into vfs land. > fs/sysfs/file.c > fs/nfsd/vfs.c and fs/nfsd/nfs4recover.c > > For nfsd, the concept of pathnames is a bit peculiar. I'll try to > respond to > that separately. the actually nfsd filehandle code is conceptually trivially fixable, although with quite a bit of code churn. As mention I'll soon submit a patch for it. nfs4recover.c is broken beyond repair and should just be deleted from the tree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Tuesday February 6, [EMAIL PROTECTED] wrote: > On Mon, Feb 05, 2007 at 07:20:35PM -0800, Andreas Gruenbacher wrote: > > It's actually not hard to "fix", and nfsd would look a little less weird. > > But > > what would this add, what do pathnames mean in the context of nfsd, and > > would > > nfsd actually become less weird? > > It's not actually a pathname we care about, but a vfsmount + dentry > combo. That one means as much in nfsd as elsewhere. We want nfsd > to obey r/o or noatime mount flags if /export/foo is exported with them > but /foo not. Even better would be to change nfsd so it creates it's > own non-visible vfsmount for the filesystems it exports.. What would be the benefit of having private non-visible vfsmounts? Sounds like a recipe for confusion? It is possible that mountd might start doing bind-mounts to create the 'pseudo filesystem' thing for NFSv4, but they would be very visible (under /var/lib/nfs/v4root or something). So having it's own vfsmount might make sense, but I don't get 'non-visible'. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Tuesday February 6, [EMAIL PROTECTED] wrote: > On Tue, Feb 06, 2007 at 12:51:52AM -0800, Trond Myklebust wrote: > > Who cares? There is no way to export a partial directory, and in any > > case the subtree_check crap is borken beyond repair (see cross-directory > > renames which lead to actual changes to the filehandle - broken, broken, > > broken). > > It's getting a little oftopic for this thread, but is there a chance we > could just kill that crap after a resonable deprecation period? Probably. A couple of years? nfs-utils 1.1.0 is due to stop subtree_check from being the default. After that is released, the next kernel can start printing warnings that it might stop working in a couple of years. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Tue, Feb 06, 2007 at 09:26:14PM +1100, Neil Brown wrote: > What would be the benefit of having private non-visible vfsmounts? > Sounds like a recipe for confusion? > > It is possible that mountd might start doing bind-mounts to create the > 'pseudo filesystem' thing for NFSv4, but they would be very visible > (under /var/lib/nfs/v4root or something). So having it's own vfsmount > might make sense, but I don't get 'non-visible'. It would allow creating an exported tree without interferance with the local visible tree. Note that the local visible tree isn't global anymore either, and this allows to adjust what's exported through nfsd throug a specific interface instead of needing to get into nfsd namespace through some way. Think of listing the actually exported devices in /etc/exports instead of the indirection through fstab aswell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] wavelan: Use ARRAY_SIZE macro when appropriate
On Mon, Feb 05, 2007 at 11:17:09PM +0300, Alexey Dobriyan wrote:
> On Mon, Feb 05, 2007 at 07:00:44PM +0200, Ahmed S. Darwish wrote:
> > A trivial patch to use ARRAY_SIZE macro.
>
> You're supposed to remove it ans use ARRAY_SIZE where old macro is used.
>
> > --- a/drivers/net/wireless/wavelan.p.h
> > +++ b/drivers/net/wireless/wavelan.p.h
> > @@ -450,7 +450,7 @@ static const char *version= "wavelan.c :
> > v24 (SMP + wireless extensions) 11/12/
> > #defineWATCHDOG_JIFFIES(512*HZ/100)
> >
> > /* Macro to get the number of elements in an array */
> > -#defineNELS(a) (sizeof(a) / sizeof(a[0]))
> > +#defineNELS(a) ARRAY_SIZE(a)
Ooh, how dumb the original patch is :). Thanks, here's the modified patch.
A patch to use ARRAY_SIZE macro when appropriate.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/wavelan.c b/drivers/net/wireless/wavelan.c
index 24221e4..2aa3c76 100644
--- a/drivers/net/wireless/wavelan.c
+++ b/drivers/net/wireless/wavelan.c
@@ -28,7 +28,7 @@
*/
static u8 wv_irq_to_psa(int irq)
{
- if (irq < 0 || irq >= NELS(irqvals))
+ if (irq < 0 || irq >= ARRAY_SIZE(irqvals))
return 0;
return irqvals[irq];
@@ -42,7 +42,7 @@ static int __init wv_psa_to_irq(u8 irqval)
{
int irq;
- for (irq = 0; irq < NELS(irqvals); irq++)
+ for (irq = 0; irq < ARRAY_SIZE(irqvals); irq++)
if (irqvals[irq] == irqval)
return irq;
@@ -1695,7 +1695,7 @@ static int wv_frequency_list(unsigned long ioaddr,
/* I/O port of the card */
/* Look in the table if the frequency is allowed */
if (table[9 - (freq / 16)] & (1 << (freq % 16))) {
/* Compute approximate channel number */
- while ((c < NELS(channel_bands)) &&
+ while ((c < ARRAY_SIZE(channel_bands)) &&
(((channel_bands[c] >> 1) - 24) < freq))
c++;
list[i].i = c; /* Set the list index */
@@ -4269,7 +4269,7 @@ struct net_device * __init wavelan_probe(int unit)
printk(KERN_DEBUG "%s: <-wavelan_probe()\n", dev->name);
#endif
} else { /* Scan all possible addresses of the WaveLAN hardware. */
- for (i = 0; i < NELS(iobase); i++) {
+ for (i = 0; i < ARRAY_SIZE(iobase); i++) {
dev->irq = def_irq;
if (wavelan_config(dev, iobase[i]) == 0) {
#ifdef DEBUG_CALLBACK_TRACE
@@ -4280,7 +4280,7 @@ struct net_device * __init wavelan_probe(int unit)
break;
}
}
- if (i == NELS(iobase))
+ if (i == ARRAY_SIZE(iobase))
r = -ENODEV;
}
if (r)
@@ -4327,14 +4327,14 @@ int __init init_module(void)
#endif
/* Copy the basic set of address to be probed. */
- for (i = 0; i < NELS(iobase); i++)
+ for (i = 0; i < ARRAY_SIZE(iobase); i++)
io[i] = iobase[i];
}
/* Loop on all possible base addresses. */
i = -1;
- while ((io[++i] != 0) && (i < NELS(io))) {
+ while ((io[++i] != 0) && (i < ARRAY_SIZE(io))) {
struct net_device *dev = alloc_etherdev(sizeof(net_local));
if (!dev)
break;
diff --git a/drivers/net/wireless/wavelan.p.h b/drivers/net/wireless/wavelan.p.h
index 72b646c..fe24281 100644
--- a/drivers/net/wireless/wavelan.p.h
+++ b/drivers/net/wireless/wavelan.p.h
@@ -449,9 +449,6 @@ static const char *version= "wavelan.c : v24 (SMP
+ wireless extensions) 11/12/
/* Watchdog temporisation */
#defineWATCHDOG_JIFFIES(512*HZ/100)
-/* Macro to get the number of elements in an array */
-#defineNELS(a) (sizeof(a) / sizeof(a[0]))
-
/* PRIVATE IOCTL */
#define SIOCSIPQTHRSIOCIWFIRSTPRIV /* Set quality threshold */
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
On Mon, Feb 05, 2007 at 12:31:26PM -0800, Auke Kok wrote:
> Alexey Dobriyan wrote:
> >On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
> >>A patch to use ARRAY_SIZE macro already defined in kernel.h.
> >
> >Remove it and use ARRAY_SIZE instead.
> >
> >>--- a/drivers/net/ixgb/ixgb_param.c
> >>+++ b/drivers/net/ixgb/ixgb_param.c
> >>@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option
> >>*opt)
> >>return -1;
> >> }
> >>
> >>-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
> >>+#define LIST_LEN(l) ARRAY_SIZE(l)
>
> yes, well spotted. Please change line 338 in this file to read:
>
> .arg = { .l = { .nr = ARRAY_SIZE(fc_list),
>
> instead, so you can remove the LIST_LEN macro completely.
Thanks, Here's the new patch.
Use ARRAY_SIZE macro when appropriate.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..c38ce73 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,8 +245,6 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
-
/**
* ixgb_check_options - Range Checking for Command Line Parameters
* @adapter: board private structure
@@ -335,7 +333,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
.name = "Flow Control",
.err = "reading default settings from EEPROM",
.def = ixgb_fc_tx_pause,
- .arg = { .l = { .nr = LIST_LEN(fc_list),
+ .arg = { .l = { .nr = ARRAY_SIZE(fc_list),
.p = fc_list }}
};
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [discuss] [patch] mtrr: fix issues with large addresses
On Tuesday 06 February 2007 10:53, Jan Beulich wrote: > >> I don't think I remember a restriction here, at least not below 44 bits > >> (that's where pfn-s would need to become 64-bit wide). > > > >The i386 mm code only supports 4 entries in the PGD, so more than 36bit > >cannot > >be mapped right now. > > That has nothing to do with the number of physical address bits. You couldn't use the memory in any ways. Anyways I give up -- the check is probably not needed, unless Andreas comes up with a good reason. > > >Also even 64MB barely works (many boxes don't boot), you would likely > >need at least the 4:4 patch to go >64GB. Also we know there are tons > >of possible deadlocks in various subsystems when the lowmem:highmem ratio > >gets so out of hand. > > > >Ok it could be probably all fixed with some work (at least the mm part, > >the deadlocks would be more tricky), but would seem fairly > >pointless to me because all machines with >36bits support are 64bit capable. > > That's a different story, and certainly a limiting factor. But this shouldn't > e.g. disallow (hypothetical?) systems that have a very sparse memory map > extending beyond 64G. They would need a discontig kernel to boot most likely, otherwise mem_map would fill up their memory. And I was told Windows doesn't like that, so it's unlikely there will ever be such x86 machines. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm][AIO] AIO completion signal notification fixes and cleanups
On 02/06, S?bastien Dugu? wrote:
>
> @@ -970,8 +969,14 @@ static long aio_setup_sigevent(struct ai
> rcu_read_lock();
> target = sigevent_find_task(&event);
>
> - if (unlikely(!target))
> + if (unlikely(!target)) {
> + /*
> + * Revert notify to SIGEV_NONE so that really_put_req()
> + * knows that no ref has been taken on a task.
> + */
> + notify->notify = SIGEV_NONE;
> goto out_unlock;
> + }
Very minor nit, feel free to ignore.
Isn't it better to move "notify->* = event.*;" down, when we know that
target != NULL. Imho, a bit easier to follow. This way we don't need to
reset notify->notify = SIGEV_NONE.
aio_setup_sigevent() relies on the fact that ->notify = SIGEV_NONE on
entry anyway.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On 2/6/07, Grant Grundler <[EMAIL PROTECTED]> wrote: On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote: > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[EMAIL PROTECTED]> wrote: > > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > > ... > > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ > > > Latency: 0, Cache Line Size 0c > > > > BIST is running > > > > > > BIST is required to complete in 2 seconds. Either with success or failure. > > > I expect BIOS to have complained before launching grub/lilo. > > > > Gregkh, > > I just realized linux-pci bus scan should ignore devices (print a warning) > > which have BIST set. Want a patch for this? > > > > Slight risk some previously "working" device which violates the > > spec might get ignored...but I hope there aren't too many of those. > > Should we wait two seconds before declaring the device dead? > To see whether it will come back? Hrm...my thought was BIOS should already be doing that...but I just realised 2 seconds have elapsed if Manu can collect "lspci" output showing "BIST is running". I think the fact that BIST is not "running" in the 2.6.20-rc7 lspci output is just coincidental. The config space for that device is full of similar garbage in both cases regardless how long it took. Maybe BIOS is clobbering BIST when writing latency timer or cacheline size register and BIOS is not being careful to clear or disable the other bytes in that same 32-bit word? PCI is by nature a 32-bit wide config space and "byte enables" are used to mask off bytes we want to ignore. If the chipset or BIOS config access routines aren't careful, they could accidentally modify other values in the same 32-bit word when only one byte was intended to be changed. The code in pci_set_cacheline_size() uses byte enables but is only called by pci_set_mwi(). 82 different .c files (124 instances) access PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls. But I really only care about the calls what would apply get invoked for 1822:4e35. My guess is this one always gets invoked: ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat); since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]". (http://pci-ids.ucw.cz/iii/?i=1822) pci_enable_bridges() -> pci_set_master() -> pcibios_set_master(). Manu, can you add code to pci_enable_bridges() to dump information about which bridges are getting enabled _before_ pci_set_master() is called? I'm interested in a hex dump of the first 8 32-bit words of PCI config space for each device. attaching a dump of the regs (on 2.6.17.7) as well as the diff regards, manu [17179569.184000] Linux version 2.6.17.7 ([EMAIL PROTECTED]) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #4 SMP PREEMPT Tue Feb 6 14:58:19 GST 2007 [17179569.184000] BIOS-provided physical RAM map: [17179569.184000] BIOS-e820: - 0009fc00 (usable) [17179569.184000] BIOS-e820: 0009fc00 - 000a (reserved) [17179569.184000] BIOS-e820: 000e8000 - 0010 (reserved) [17179569.184000] BIOS-e820: 0010 - 1ff3 (usable) [17179569.184000] BIOS-e820: 1ff3 - 1ff4 (ACPI data) [17179569.184000] BIOS-e820: 1ff4 - 1fff (ACPI NVS) [17179569.184000] BIOS-e820: 1fff - 2000 (reserved) [17179569.184000] BIOS-e820: ffb8 - 0001 (reserved) [17179569.184000] 511MB LOWMEM available. [17179569.184000] found SMP MP-table at 000ff780 [17179569.184000] On node 0 totalpages: 130864 [17179569.184000] DMA zone: 4096 pages, LIFO batch:0 [17179569.184000] Normal zone: 126768 pages, LIFO batch:31 [17179569.184000] DMI 2.3 present. [17179569.184000] ACPI: RSDP (v002 ACPIAM) @ 0x000f9e30 [17179569.184000] ACPI: XSDT (v001 A M I OEMXSDT 0x01000428 MSFT 0x0097) @ 0x1ff30100 [17179569.184000] ACPI: FADT (v003 A M I OEMFACP 0x01000428 MSFT 0x0097) @ 0x1ff30290 [17179569.184000] ACPI: MADT (v001 A M I OEMAPIC 0x01000428 MSFT 0x0097) @ 0x1ff30390 [17179569.184000] ACPI: OEMB (v001 A M I OEMBIOS 0x01000428 MSFT 0x0097) @ 0x1ff40040 [17179569.184000] ACPI: DSDT (v001 P4C81 P4C81100 0x0100 INTL 0x02002026) @ 0x [17179569.184000] ACPI: PM-Timer IO Port: 0x808 [17179569.184000] ACPI: Local APIC address 0xfee0 [17179569.184000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [17179569.184000] Processor #0 15:2 APIC version 20 [17179569.184000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [17179569.184000] Processor #1 15:2 APIC version 20 [17179569.184000] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [17179569.184000] IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 [17179569.1
Re: hwsusp defunct
Rafael J. Wysocki napsal(a): Hi, On Sunday, 4 February 2007 14:12, Jiri Slaby wrote: Hi. When I'm trying to suspend to mem one machine, it wakes immediatly back with nothing notable in dmesg: [--snip--] Will PM_DEBUG or ACPI_DEBUG help somehow? Or later kernel? Later kernel might help, some important fixes have gone in since 2.6.19, PCI quirks-related etc. Please try 2.6.20-rc7 and if that doesn't help, try the latest -mm. 2.6.20 from init 2 is no go either, -mm (-rc6-mm3) with minimal config [1] suspends, no key was able to resume it back, only power button, but monitor doesn't wake (actually I've this problem on another machine when X is not running) -- how to debug both of this? Do not suspend consoles? PM_TRACE (this won't help since it completely resumes, I guess)? This is blindly written dmesg after resume. See it whole at [2]: Suspending device 0.0 ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (7) is beyon d end of object [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.GTM_] (Node dfe64fcc), AE_AML_PACKAGE_LIMIT ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.CHN0._ GTM] (Node dfe649f0), AE_AML_PACKAGE_LIMIT ... hda: selected mode 0x45 ACPI Error (dsopcode-0481): Attempt to CreateField of length zero [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.RATA] (Node dfe64ec8), AE_AML_OPERAND_VALUE ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.CHN0.D RV1._GTF] (Node dfe64964), AE_AML_OPERAND_VALUE do_drive_get_GTF: Run _GTF error: status = 0x3006 $ ls -l /sys/block/hda/device lrwxrwxrwx 1 root root 0 úno 6 12:14 /sys/block/hda/device -> ../../devices/pci:00/:00:1f.1/ide0/0.0 $ ls -l /sys/block/hda/device/driver lrwxrwxrwx 1 root root 0 úno 6 12:15 /sys/block/hda/device/driver -> ../../../../../bus/ide/drivers/ide-disk $ ls -l /sys/block/hda/device/driver/0.0 lrwxrwxrwx 1 root root 0 úno 6 12:16 /sys/block/hda/device/driver/0.0 -> ../../../../devices/pci:00/:00:1f.1/ide0/0.0 # lspci -vvvxxs :00:1f.1 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 5 Region 0: I/O ports at 01f0 [size=8] Region 1: I/O ports at 03f4 [size=1] Region 2: I/O ports at 0170 [size=8] Region 3: I/O ports at 0374 [size=1] Region 4: I/O ports at fc00 [size=16] Region 5: Memory at 3010 (32-bit, non-prefetchable) [size=1K] 00: 86 80 db 24 07 00 80 02 02 8a 01 01 00 00 00 00 10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 20: 01 fc 00 00 00 00 10 30 00 00 00 00 43 10 a6 80 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 Do you want acpidump? Should I test 2.6.20 with minimal config? [1] http://www.fi.muni.cz/~xslaby/sklad/config-mm [2] http://www.fi.muni.cz/~xpapiez/test/dmesg-mm.txt regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.20][PATCH] fix mempolicy error check on a system with memory-less-node
current mempolicy just checks whether a node is online or not.
If there is memory-less-node, mempolicy's target node can be
invalid.
This patch adds a check whether a node has memory or not.
This is an back-trace in which a program uses MPOL_MBIND just includes
memory-less-node.
== backtrace from crash (linux-2.6.20) ==
#0 [BSP:e00121f412d8] schedule at a0010061ccc0
#1 [BSP:e00121f41280] rwsem_down_failed_common at a00100290490
#2 [BSP:e00121f41260] rwsem_down_read_failed at a00100620d30
#3 [BSP:e00121f41240] down_read at a001000b01a0
#4 [BSP:e00121f411e8] ia64_do_page_fault at a00100625710
#5 [BSP:e00121f411e8] ia64_leave_kernel at a001c660
EFRAME: e00121f47100
B0: a0010013cc40 CR_IIP: a0010012aa30
CR_IPSR: 101008022018 CR_IFS: 8205
AR_PFS: 0309 AR_RSC: 0003
AR_UNAT: AR_RNAT:
AR_CCV: AR_FPSR: 0009804c8a70033f
LOADRS: AR_BSPSTORE:
B6: a0010003f040 B7: a001ccd0
PR: 0055a9a5 R1: a00100d5a5b0
R2: e0010c50df7c R3: 0030
R8: R9: e0011dc52930
R10: e0011dc52928 R11: e0010c50df80
R12: e00121f472c0 R13: e00121f4
R14: 0002 R15: 3f00
R16: 1040 R17: e00121f4
R18: a00100b5a9d0 R19: e00121f40018
R20: e00121f40c84 R21:
R22: e00121f47330 R23: e00121f47334
R24: e00121f40b88 R25: e00121f47340
R26: e00121f47334 R27:
R28: R29: e00121f47338
R30: 7fff R31: a00100b5b5e0
F6: 1003eccd55056199632ec F7: 1003e9e3779b97f4a7c16
F8: 1003e0a0010001422 F9: 1003e0fa0
F10: 1003e3b9aca00F11: 1003e431bde82d7b634db
#6 [BSP:e00121f411c0] slab_node at a0010012aa30
#7 [BSP:e00121f41190] alternate_node_alloc at a0010013cc40
#8 [BSP:e00121f41160] kmem_cache_alloc at a0010013dc40
#9 [BSP:e00121f41100] desc_prologue at a0010003ee00
#10 [BSP:e00121f410c0] unw_decode_r2 at a0010003f0c0
#11 [BSP:e00121f41068] find_save_locs at a0010003fbf0
#12 [BSP:e00121f41038] unw_init_frame_info at a00100040900
#13 [BSP:e00121f41010] unw_init_running at a001ccf0
==
This panic(hang) was found by a numa test-set on a system with 3 nodes, where
node(2) was memory-less-node.
This means an access to NULL,here.
==
unsigned slab_node(struct mempolicy *policy)
{
case MPOL_BIND:
/*
* Follow bind policy behavior and start allocation at the
* first node.
*/
return zone_to_nid(policy->v.zonelist->zones[0]);
}
==
length of this zonelist was 0.
It seems fixing a NULL access here is also O.K.
This patch is just an idea.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Index: linux-2.6.20/mm/mempolicy.c
===
--- linux-2.6.20.orig/mm/mempolicy.c2007-02-06 20:02:31.0 +0900
+++ linux-2.6.20/mm/mempolicy.c 2007-02-06 20:09:47.0 +0900
@@ -116,6 +116,8 @@
static int mpol_check_policy(int mode, nodemask_t *nodes)
{
int empty = nodes_empty(*nodes);
+ int nd;
+ nodemask_t node_with_memory;
switch (mode) {
case MPOL_DEFAULT:
@@ -130,7 +132,12 @@
return -EINVAL;
break;
}
- return nodes_subset(*nodes, node_online_map) ? 0 : -EINVAL;
+ nodes_clear(node_with_memory);
+ for_each_online_node(nd) {
+ if (node_present_pages(nd))
+ node_set(nd, node_with_memory);
+ }
+ return nodes_subset(*nodes, node_with_memory) ? 0 : -EINVAL;
}
/* Generate a custom zonelist for the BIND policy. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: hwsusp defunct
Jiri Slaby napsal(a): monitor doesn't wake (actually I've this problem on another machine when Ah, oh. Monitor over DVI on 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 AGP 8x] (rev a1) (prog-if 00 [VGA]) Subsystem: ASUSTeK Computer Inc. Unknown device 807b Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 248 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 11 Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at e800 (32-bit, prefetchable) [size=128M] [virtual] Expansion ROM at fe9e [disabled] [size=128K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 3.0 Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=32 ArqSz=2 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8 00: de 10 81 02 07 00 b0 02 a1 00 00 03 00 f8 00 00 10: 00 00 00 fd 08 00 00 e8 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 7b 80 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 05 01 40: 43 10 7b 80 02 00 30 00 1b 0e 00 1f 02 43 00 1f 50: 01 00 00 00 01 00 00 00 ce d6 23 00 0f 00 00 00 60: 01 44 02 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][0/5] floppy.c: first round of cleanup patches - the simple stuff
On Tue, 6 Feb 2007 00:28:31 +0100 Jesper Juhl <[EMAIL PROTECTED]> wrote: > Greetings people, > > Here is, as promised, the first round of cleanup patches for floppy.c > (more will follow later). > > I opted to start with the simple stuff first, both to get it out of the way > and also to get something done resonably fast, so don't expect anything > earth shattering in this first series. > > There are 5 patches in this series. They are based on 2.6.20 and are > incremental. > > These are the patches (they'll be posted to the same recipients as this > initial mail) : > > [PATCH][1/5] floppy.c: Initial (partial) CodingStyle cleanup > [PATCH][2/5] floppy.c: Remove pointless register keywords > [PATCH][3/5] floppy.c: Remove dead/commented out code > [PATCH][4/5] floppy.c: Add explicit/better printk() levels > [PATCH][5/5] floppy.c: Fix device_create_file() warning Acked-by: Alan Cox <[EMAIL PROTECTED]> for the set of 5 patches. Its a beginning and removing the dead wood so you can see what is actually there is a good a beginning as any other. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SUN3/3X Lance trivial fix
Cyrill V. Gorcunov napsal(a):
This patch adds checking for allocated DVMA
memory and granted IRQ line.
Signed-off-by: Cyrill V. Gorcunov <[EMAIL PROTECTED]>
---
drivers/net/sun3lance.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sun3lance.c b/drivers/net/sun3lance.c
index c62e85d..e4c2c88 100644
--- a/drivers/net/sun3lance.c
+++ b/drivers/net/sun3lance.c
@@ -336,13 +336,20 @@ static int __init lance_probe( struct net_device *dev)
/* XXX - leak? */
MEM = dvma_malloc_align(sizeof(struct lance_memory), 0x1);
+ if (MEM == NULL) {
+ printk(KERN_WARNING "SUN3 Lance couldn't allocate DVMA
memory\n");
+ return 0;
+ }
lp->iobase = (volatile unsigned short *)ioaddr;
dev->base_addr = (unsigned long)ioaddr; /* informational only */
But now, if it fails (and you return 0=OK state) these are not assigned and
probably used later.
REGA(CSR0) = CSR0_STOP;
- request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3 Lance", dev);
+ if (request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3 Lance",
dev) < 0) {
+ printk(KERN_WARNING "SUN3 Lance unable to allocate IRQ\n");
+ return 0;
+ }
dev->irq = (unsigned short)LANCE_IRQ;
Not even irq is grabbed.
Is this intended?
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm][AIO] AIO completion signal notification fixes and cleanups
On Tue, 6 Feb 2007 14:05:39 +0300 Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> On 02/06, S?bastien Dugu? wrote:
> >
> > @@ -970,8 +969,14 @@ static long aio_setup_sigevent(struct ai
> > rcu_read_lock();
> > target = sigevent_find_task(&event);
> >
> > - if (unlikely(!target))
> > + if (unlikely(!target)) {
> > + /*
> > +* Revert notify to SIGEV_NONE so that really_put_req()
> > +* knows that no ref has been taken on a task.
> > +*/
> > + notify->notify = SIGEV_NONE;
> > goto out_unlock;
> > + }
>
> Very minor nit, feel free to ignore.
>
> Isn't it better to move "notify->* = event.*;" down, when we know that
> target != NULL. Imho, a bit easier to follow. This way we don't need to
> reset notify->notify = SIGEV_NONE.
>
> aio_setup_sigevent() relies on the fact that ->notify = SIGEV_NONE on
> entry anyway.
Yep, right, it will make things cleaner.
Thanks,
Sébastien.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SUN3/3X Lance trivial fix
Jiri Slaby napsal(a):
Cyrill V. Gorcunov napsal(a):
This patch adds checking for allocated DVMA
memory and granted IRQ line.
Signed-off-by: Cyrill V. Gorcunov <[EMAIL PROTECTED]>
---
drivers/net/sun3lance.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sun3lance.c b/drivers/net/sun3lance.c
index c62e85d..e4c2c88 100644
--- a/drivers/net/sun3lance.c
+++ b/drivers/net/sun3lance.c
@@ -336,13 +336,20 @@ static int __init lance_probe( struct net_device
*dev)
/* XXX - leak? */
MEM = dvma_malloc_align(sizeof(struct lance_memory), 0x1);
+if (MEM == NULL) {
+printk(KERN_WARNING "SUN3 Lance couldn't allocate DVMA
memory\n");
+return 0;
+}
lp->iobase = (volatile unsigned short *)ioaddr;
dev->base_addr = (unsigned long)ioaddr; /* informational only */
But now, if it fails (and you return 0=OK state) these are not assigned
Ok, 0 is not OK state, I see it now.
and probably used later.
REGA(CSR0) = CSR0_STOP;
-request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3
Lance", dev);
+if (request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3
Lance", dev) < 0) {
+printk(KERN_WARNING "SUN3 Lance unable to allocate IRQ\n");
But in that case, you want to dvma_free() here?
+return 0;
+}
dev->irq = (unsigned short)LANCE_IRQ;
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SUN3/3X Lance trivial fix
Jiri Slaby napsal(a):
Jiri Slaby napsal(a):
Cyrill V. Gorcunov napsal(a):
This patch adds checking for allocated DVMA
memory and granted IRQ line.
Signed-off-by: Cyrill V. Gorcunov <[EMAIL PROTECTED]>
---
drivers/net/sun3lance.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sun3lance.c b/drivers/net/sun3lance.c
index c62e85d..e4c2c88 100644
--- a/drivers/net/sun3lance.c
+++ b/drivers/net/sun3lance.c
@@ -336,13 +336,20 @@ static int __init lance_probe( struct
net_device *dev)
/* XXX - leak? */
MEM = dvma_malloc_align(sizeof(struct lance_memory), 0x1);
+if (MEM == NULL) {
+printk(KERN_WARNING "SUN3 Lance couldn't allocate DVMA
memory\n");
And also iounmap() here...
+return 0;
+}
lp->iobase = (volatile unsigned short *)ioaddr;
dev->base_addr = (unsigned long)ioaddr; /* informational only */
But now, if it fails (and you return 0=OK state) these are not assigned
Ok, 0 is not OK state, I see it now.
and probably used later.
REGA(CSR0) = CSR0_STOP;
-request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3
Lance", dev);
+if (request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3
Lance", dev) < 0) {
+printk(KERN_WARNING "SUN3 Lance unable to allocate IRQ\n");
But in that case, you want to dvma_free() here?
And here.
+return 0;
+}
dev->irq = (unsigned short)LANCE_IRQ;
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On 2/6/07, Manu Abraham <[EMAIL PROTECTED]> wrote: On 2/6/07, Grant Grundler <[EMAIL PROTECTED]> wrote: > On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote: > > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > > > ... > > > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > > > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ > > > > Latency: 0, Cache Line Size 0c > > > > > BIST is running > > > > > > > > BIST is required to complete in 2 seconds. Either with success or failure. > > > > I expect BIOS to have complained before launching grub/lilo. > > > > > > Gregkh, > > > I just realized linux-pci bus scan should ignore devices (print a warning) > > > which have BIST set. Want a patch for this? > > > > > > Slight risk some previously "working" device which violates the > > > spec might get ignored...but I hope there aren't too many of those. > > > > Should we wait two seconds before declaring the device dead? > > To see whether it will come back? > > Hrm...my thought was BIOS should already be doing that...but I just > realised 2 seconds have elapsed if Manu can collect "lspci" output showing > "BIST is running". I think the fact that BIST is not "running" in the > 2.6.20-rc7 lspci output is just coincidental. The config space for that > device is full of similar garbage in both cases regardless how long > it took. > > Maybe BIOS is clobbering BIST when writing latency timer or cacheline size > register and BIOS is not being careful to clear or disable the other > bytes in that same 32-bit word? > > PCI is by nature a 32-bit wide config space and "byte enables" > are used to mask off bytes we want to ignore. If the chipset > or BIOS config access routines aren't careful, they could accidentally > modify other values in the same 32-bit word when only one byte was > intended to be changed. > > The code in pci_set_cacheline_size() uses byte enables but is only > called by pci_set_mwi(). 82 different .c files (124 instances) access > PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls. > But I really only care about the calls what would apply get invoked > for 1822:4e35. My guess is this one always gets invoked: > ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat); > > since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]". > (http://pci-ids.ucw.cz/iii/?i=1822) > pci_enable_bridges() -> pci_set_master() -> pcibios_set_master(). > > Manu, can you add code to pci_enable_bridges() to dump information about > which bridges are getting enabled _before_ pci_set_master() is called? > > I'm interested in a hex dump of the first 8 32-bit words of > PCI config space for each device. > attaching a dump of the regs (on 2.6.17.7) as well as the diff The device now works, used the demodulator driver alongwith the bridge driver. inlined the log regards, manu [17181623.04] gpif status: 6000 irqcfg: [17181623.04] irq: 18, latency: 64 [17181623.04] memory: 0xefeff000, mmio: 0xe18f4000 [17181623.04] found a UNKNOWN PCI UNKNOWN device on (02:0a.0), [17181623.04] Mantis Rev 1 [1822:0031], irq: 18, latency: 64 [17181623.04] memory: 0xefeff000, mmio: 0xe18f4000 [17181623.04] mantis_i2c_write: Address=[0x50] [ 08 ] [17181623.04] mantis_i2c_read: Address=[0x50] [ 00 00 00 00 00 00 ] [17181623.044000] MAC Address=[00:00:00:00:00:00] [17181623.044000] mantis_alloc_buffers (0): DMA=0x186b cpu=0xd86b size=65536 [17181623.044000] mantis_alloc_buffers (0): RISC=0x1c3af000 cpu=0xdc3af000 size=1000 [17181623.044000] DVB: registering new adapter (Mantis dvb adapter). [17181623.564000] mantis_frontend_init (0): Probing for STB0899 (DVB-S/DSS/DVB-S2) [17181623.564000] stb0899_write_regs [0xf1b6]: 02 [17181623.564000] mantis_i2c_write: Address=[0x68] [ f1 b6 02 ] [17181623.564000] stb0899_write_regs [0xf1c2]: 00 [17181623.564000] mantis_i2c_write: Address=[0x68] [ f1 c2 00 ] [17181623.568000] stb0899_write_regs [0xf1c3]: 00 [17181623.568000] mantis_i2c_write: Address=[0x68] [ f1 c3 00 ] [17181623.568000] mantis_i2c_write: Address=[0x68] [ f0 00 ] [17181623.568000] mantis_i2c_read: Address=[0x68] [ 82 ] [17181623.568000] stb0899_read_reg: Reg=[0xf000], data=82 [17181623.568000] stb0899_get_dev_id: Device ID=[8], Release=[2] [17181623.568000] mantis_i2c_write: Address=[0x68] [ f3 fc 00 04 00 00 ] [17181623.572000] mantis_i2c_write: Address=[0x68] [ f3 34 ] [17181623.572000] mantis_i2c_read: Address=[0x68] [ 31 44 4d 44 ] [17181623.572000] mantis_i2c_write: Address=[0x68] [ f3 34 ] [17181623.572000] mantis_i2c_read: Address=[0x68] [ 31 44 4d 44 ] [17181623.576000] stb0899_read_s2reg Device=[0xf3fc],
Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V9: mmc_sysfs.diff
Anderson Briglia wrote: > Bug fixed. Is there anything else to improve? > > Great. All known issues should be fixed now. I'm currently reorganising my -mm branch, so things might go missing from there for a while. But it will be back eventually. Btw, any progress on testing this with SD? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm][AIO] AIO completion signal notification small cleanup
Andrew, one more cleanup to aio_setup_sigevent() to make it more readable.
Sébastien.
From: Sébastien Dugué <[EMAIL PROTECTED]>
AIO completion signal notification small cleanup
This patch cleans up aio_setup_sigevent() to make it more readable.
aio.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc6-mm3/fs/aio.c
===
--- linux-2.6.20-rc6-mm3.orig/fs/aio.c 2007-02-06 09:33:55.0 +0100
+++ linux-2.6.20-rc6-mm3/fs/aio.c 2007-02-06 12:43:52.0 +0100
@@ -962,21 +962,11 @@ static long aio_setup_sigevent(struct ai
event.sigev_notify != SIGEV_THREAD_ID)
return -EINVAL;
- notify->notify = event.sigev_notify;
- notify->signo = event.sigev_signo;
- notify->value = event.sigev_value;
-
rcu_read_lock();
target = sigevent_find_task(&event);
- if (unlikely(!target)) {
- /*
-* Revert notify to SIGEV_NONE so that really_put_req()
-* knows that no ref has been taken on a task.
-*/
- notify->notify = SIGEV_NONE;
+ if (unlikely(!target))
goto out_unlock;
- }
/*
* At this point, we know that notify is either SIGEV_SIGNAL or
@@ -988,6 +978,9 @@ static long aio_setup_sigevent(struct ai
notify->target = target;
rcu_read_unlock();
+ notify->notify = event.sigev_notify;
+ notify->signo = event.sigev_signo;
+ notify->value = event.sigev_value;
notify->sigq = __sigqueue_alloc(current, GFP_KERNEL, 0);
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
dang ! rebooted it into 2.6.17.7 no errors, during a bootup, BIST isn't running anymore running M$ did change the status from dead to alive ??? shocked !! Interesting! does windows driver fixes the broken firmware/flash on this card? attached lspci output in the very same setup as earlier, no difference in anything, except that it was rebooted into windows. the PCI config dump would help ? I guess you would never reproduce this issue again unless you can restore the broken firmware/flash on this card. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On 2/6/07, Luming Yu <[EMAIL PROTECTED]> wrote: > dang ! > > rebooted it into 2.6.17.7 > > no errors, during a bootup, BIST isn't running anymore > running M$ did change the status from dead to alive ??? shocked !! Interesting! does windows driver fixes the broken firmware/flash on this card? No firmware/flash on the card. > > attached lspci output in the very same setup as earlier, no difference > in anything, except that it was rebooted into windows. > > the PCI config dump would help ? > I guess you would never reproduce this issue again unless you can restore the broken firmware/flash on this card. :-) none on the card, a flash or a firmware .. it has a 24c02 EEPROM for vendor information, that's all regards, manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
> hmm stolen time could even be useful without virtualization; to a large > degree, if cpufreq reduces the speed of your cpu you have "stolen > cycles" that way... I wonder if this concept can be used for that as > well... If you mean it for the real time clock: Doesn't make sense then because Linux time isn't measured in cycles If you mean it for the scheduler: it only uses estimates for relative fairness. As long as everybody is sloeed down in the same way the relative fairness doesn't change. For time accounting: the regular timer interrupt is fairly imprecise anyawys because it samples at a low frequency. While it would be possible to improve this it would be quite costly by slowing down interrupts and syscalls. I'm not sure it makes that much difference here either. I don't see the point, frankly. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/11] Add a CPU KHZ calibration function to paravirt-ops
On Mon, Feb 05, 2007 at 07:53:23PM -0800, Zachary Amsden wrote: > Provide a paravirtualized way to get the CPU clock frequency; this allows much > of the code in tsc.c to be shared between all paravirt implementations. Is this really needed? What worries me somewhat of your patches is that you seem to be quick at adding new hooks. But I would like to keep paravirtops as minimal as possible with new hooks only added when there is a very good justification. I don't see it here. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/11] Panic delay fix
On Mon, Feb 05, 2007 at 07:53:30PM -0800, Zachary Amsden wrote: > Failure to use real-time delay here causes the keyboard to become demonically > possessed in the event of a kernel crash, with wildly blinking lights and > unpredictable behavior. This has resulted in several injuries. There must be a reason why it wasn't default before. Has this reason changed? -Andi > > Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]> > > diff -r 10fac6d484e2 drivers/input/serio/i8042.c > --- a/drivers/input/serio/i8042.c Tue Jan 30 16:44:54 2007 -0800 > +++ b/drivers/input/serio/i8042.c Tue Jan 30 16:45:00 2007 -0800 > @@ -9,6 +9,7 @@ > * under the terms of the GNU General Public License version 2 as published > by > * the Free Software Foundation. > */ > +#define USE_REAL_TIME_DELAY > > #include > #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/11] Vmi timer no idle hz fixes.patch
> -#ifdef CONFIG_S390
> -#ifdef CONFIG_MATHEMU
> - {
> - .ctl_name = KERN_IEEE_EMULATION_WARNINGS,
> - .procname = "ieee_emulation_warnings",
> - .data = &sysctl_ieee_emulation_warnings,
> - .maxlen = sizeof(int),
> - .mode = 0644,
> - .proc_handler = &proc_dointvec,
> - },
I think there needs to be a way to have this syctl only
when it's really implemented for the paravirt ops.
I suppose you should move it to dynamic registration on demand.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/11] Fix PIT override bug for paravirt
On Mon, Feb 05, 2007 at 07:53:02PM -0800, Zachary Amsden wrote: > The time initialization changed for i386 when some code moved into time_init. > This made it no longer possible to override the PIT / HPET, which broke > paravirt guests. Looks still fragile. Can this be done cleaner? In particularly some comments would be good, but clearer code logic would be preferred. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/11] Sched clock paravirt op
> .write_msr = native_write_msr, > .read_tsc = native_read_tsc, > .read_pmc = native_read_pmc, > + .get_scheduled_cycles = native_read_tsc, > + .get_cpu_khz = native_calculate_cpu_khz, > .load_tr_desc = native_load_tr_desc, Description missing? Please write at least two paragraphs or more on each new hook you want to add. My feeling is that rdtsc should work fine here. If not please explain. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: One-shot high-resolution POSIX timer periodically late
* John <[EMAIL PROTECTED]> wrote: > > 2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5 > > too? > > Ingo, Thomas, > > I cannot reproduce in 2.6.20-rc6-rt6, but it is not strictly an > apples-to-apples comparison because I get a tsc clocksource in > 2.6.20-rc6-rt6, and an acpi_pm clocksource in 2.6.18.6-rt7. that suggests that the TSC was not deemed reliable by the newer kernel - which almost always means it's not realiable. I think the problems you were seeing are consistent with TSC being non-monotonic - so the fix is to not use the TSC - and the newer kernel does this automatically. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
On Tue, 2007-02-06 at 13:25 +0100, Andi Kleen wrote: > > hmm stolen time could even be useful without virtualization; to a large > > degree, if cpufreq reduces the speed of your cpu you have "stolen > > cycles" that way... I wonder if this concept can be used for that as > > well... > > I don't see the point, frankly. I mean for showing the sysadmin that his system has spare capacity left. right now top shows 50% in use (at say 600Mhz) while the 2.8Ghz processor obviously isn't even nearly half loaded. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
> First of all, if sending attached patches, *MAKE SURE* they're text/plain. Sorry, next time I'll do. > The standard way to do this is to have a command line argument named > BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz). There is no reason to do > this differently from every other bootloader. I was more thinking as a command line like the shell command line, I can probably modify that. It is only to guess the root filesystem, I do not know if BOOT_IMAGE= usually contains the fully qualified path. Gujin just adds this string from the "name" field of the GZIP file, so it can be manually adjusted. > Why build the real-mode code as part of the kernel binary? If you have > to reference kernel symbols, you can do that with the -R option to ld. > Bundling it into the kernel binary just to then extract it later is > silly at best. Gujin do not reference any kernel symbol; the complete file is loaded at once at a variable memory address. Then Gujin moves the real-mode section at a valid address and execute it, then it moves the code and data protected mode at a valid address and execute it. In this mode Gujin just act as an ELF program loader. The variable memory address is good when you are running DOS/HIMEM for instance to debug hardware/BIOS - it does not crash random address before requesting BIOS services like all other bootloaders. >> + @echo " /boot/linux-$(KERNELRELEASE).kgz - create a boot kernel >> for the Gujin bootloader" > This doesn't exactly fit very well the standard pattern. Something like > make gujin TARGET=... would be more like it. For me, the make parameter is the file you want to get - up to "make" to sort out how to generate it. > Given how many of your files are highly Gujin-specific, and have generic > names, please put them in a subdirectory (e.g. arch/i386/boot/gujin/). I do agree that there is a functionality I am not sure of the interface, that is the automatic root detection. Nearly everybody put the kernel in its own distribution filesystem (Fedora kernel in Fedora root filesystem, Debian kernel in Debian root filesystem...) or only has a single distribution. The bootloader is loading this kernel file - so it knows exactly which disk/partition to propose as root to the kernel. So under the compilation switch "ROOT_EXTENSIVE_SEARCH", there is the exposed Gujin interface to help the real-mode function of the ELF file decide what to do. I do disagree that the BIOS interface like "union drive_info" of realmode.h is Gujin stuff, it is just that I a lot prefer a C interface with a clean structure than "#define OFFSET_OF_THIS_BYTE, #define MASK_OF_THIS_BIT" everywhere, I prefer programing in C than programing in CPP. Ok, most of the fields are not used - even by Gujin - it is just how the BIOS documentation describes them. >-hpa Thanks for your comments. Sorry I could not answer immediately but I had to sleep a bit. I try to reply to the other messages together. Etienne. ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SUN3/3X Lance trivial fix
On Tue, Feb 06, 2007 at 12:47:36PM +0100, Jiri Slaby wrote:
| Jiri Slaby napsal(a):
| >Jiri Slaby napsal(a):
| >>Cyrill V. Gorcunov napsal(a):
| >>>This patch adds checking for allocated DVMA
| >>>memory and granted IRQ line.
| >>>
| >>>Signed-off-by: Cyrill V. Gorcunov <[EMAIL PROTECTED]>
| >>>
| >>>---
| >>>
| >>> drivers/net/sun3lance.c |9 -
| >>> 1 files changed, 8 insertions(+), 1 deletions(-)
| >>>
| >>>diff --git a/drivers/net/sun3lance.c b/drivers/net/sun3lance.c
| >>>index c62e85d..e4c2c88 100644
| >>>--- a/drivers/net/sun3lance.c
| >>>+++ b/drivers/net/sun3lance.c
| >>>@@ -336,13 +336,20 @@ static int __init lance_probe( struct
| >>>net_device *dev)
| >>>
| >>> /* XXX - leak? */
| >>> MEM = dvma_malloc_align(sizeof(struct lance_memory), 0x1);
| >>>+if (MEM == NULL) {
| >>>+printk(KERN_WARNING "SUN3 Lance couldn't allocate DVMA
| >>>memory\n");
|
| And also iounmap() here...
|
| >>>+return 0;
| >>>+}
| >>>
| >>> lp->iobase = (volatile unsigned short *)ioaddr;
| >>> dev->base_addr = (unsigned long)ioaddr; /* informational only */
| >>
| >>But now, if it fails (and you return 0=OK state) these are not assigned
| >
| >Ok, 0 is not OK state, I see it now.
| >
| >>and probably used later.
| >>
| >>>
| >>> REGA(CSR0) = CSR0_STOP;
| >>>
| >>>-request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3
| >>>Lance", dev);
| >>>+if (request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3
| >>>Lance", dev) < 0) {
| >>>+printk(KERN_WARNING "SUN3 Lance unable to allocate IRQ\n");
| >
| >But in that case, you want to dvma_free() here?
|
| And here.
|
| >>>+return 0;
| >>>+}
| >>> dev->irq = (unsigned short)LANCE_IRQ;
|
| regards,
| --
| http://www.fi.muni.cz/~xslaby/Jiri Slaby
| faculty of informatics, masaryk university, brno, cz
| e-mail: jirislaby gmail com, gpg pubkey fingerprint:
| B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Thanks a lot,
I'll fix it to get iounmap() used. I don't know is there any reason
to use dvma_free() - it's just a 'return' function. May be for further?
I think you are right - we should use dvma_free() anyway...
Cyrill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On 2/6/07, Manu Abraham <[EMAIL PROTECTED]> wrote: On 2/6/07, Luming Yu <[EMAIL PROTECTED]> wrote: > > dang ! > > > > rebooted it into 2.6.17.7 > > > > no errors, during a bootup, BIST isn't running anymore > > running M$ did change the status from dead to alive ??? shocked !! > > Interesting! does windows driver fixes the broken firmware/flash on this card? No firmware/flash on the card. > > > > > attached lspci output in the very same setup as earlier, no difference > > in anything, except that it was rebooted into windows. > > > > the PCI config dump would help ? > > > > I guess you would never reproduce this issue again unless you can > restore the broken firmware/flash on this card. :-) > none on the card, a flash or a firmware .. it has a 24c02 EEPROM for vendor information, that's all You can see the same from this picture regards, manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 PCI Cannot allocate resource region 2
On 2/6/07, Manu Abraham <[EMAIL PROTECTED]> wrote: On 2/6/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > On 2/6/07, Luming Yu <[EMAIL PROTECTED]> wrote: > > > dang ! > > > > > > rebooted it into 2.6.17.7 > > > > > > no errors, during a bootup, BIST isn't running anymore > > > running M$ did change the status from dead to alive ??? shocked !! > > > > Interesting! does windows driver fixes the broken firmware/flash on this card? > > > No firmware/flash on the card. > > > > > > > > > > attached lspci output in the very same setup as earlier, no difference > > > in anything, except that it was rebooted into windows. > > > > > > the PCI config dump would help ? > > > > > > > I guess you would never reproduce this issue again unless you can > > restore the broken firmware/flash on this card. :-) > > > > none on the card, a flash or a firmware .. it has a 24c02 EEPROM for > vendor information, that's all > You can see the same from this picture http://abraham.manu.googlepages.com/p3130016.jpg regards, manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
> Building real mode code with kernel binary (vmlinux) has got another > disadvantage that it breaks using vmlinux for kdump purposes. One compiles > the kernel binary to execute from a different address but real mode code/data > will continue to be at virtual/physical addr 0 and kexec can not load it > as that physical memory is not available at all. Kdump skips the real mode > code execution. But that is exactly what you want and need for kdump, isn't it? The ELF file did not change, the program header has the last index at address 0 that you do not want to load because you do not want to execute the real-mode code. Load the rest and provide the 4 Kbytes parameter page - it should work. > I don't know much about Gujin, but advantage here seems to be that it has > capability to load elf files and that's why the attempt to turn kernel binary > into a compressed elf image. Why don't we then simply add an ELF header to > bzImage and Gujin and any ELF loader including Gujin, should be able to load > it? (As Eric had done in one of the implementations in the past?) Why to >create the new infrastructure? Because I think when a program evolves it has to get simpler to generate, run and maintain/debug - while doing more stuff. The number of assembler lines has to reduce because they are difficult to maintain. Removing a ELF header to modify the binary and stick another ELF header is not exactly what I think simpler - a bit like linking at a fix address and then modifying the whole set. HPA wrote: > Well, Gujin wants additional code too. > Putting an ELF header on bzImage broke some bootloaders (GRUB, I believe), > so that's not going to happen again. See the relocatable bzImage thread... I also refuses to load a big file at a fixed address before asking the BIOS for information, I only crash once the memory when I am pretty sure everything seems alright, interruption disabled, just before jumping to the kernel entry point. Cannot do that with bzImage. Cannot easily debug without this feature. > Thanks > Vivek Thanks for you comment. Etienne. ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with unix sockets: SOCK_DGRAM ignores MSG_TRUNC
On Monday 05 February 2007 01:52, David Miller wrote: > > Thus I used recv() with flags MSG_TRUNC|MSG_PEEK in order to detect > > message truncation due to insufficient buffer size. > > What part of "Only valid for packet sockets" from the manual page > escapes you? :-)) > It's a feature which only was meant to be valid for AF_PACKET sockets. Thanks for pointing that out. I thought, "packet sockets" means "datagram-oriented socket". Obviously it means PF_PACKET instead. It's hard to learn programming IPC by only reading man pages :-) > What UDP is doing is different, it's returning the full packet length > when the packet is larger then the given buffer size, but it does this > irregardless of whether you set MSG_TRUNC in the recvmsg() passed-in > flags. UDP itself sets the MSG_TRUNC flag when it detects this > situation. Please correct me gently if I am wrong: According to the kernel source code, this behaviour was introduced with patch-2.6.8: http://www.kernel.org/diff/diffview.cgi?file=/pub/linux/kernel/v2.6/patch-2.6.8.gz;z=4325 linux/net/ipv4/udp.c + err = copied; +if (flags & MSG_TRUNC) + err = skb->len - sizeof(struct udphdr); I think local sockets (PF_UNIX) implement a different semantics: According to unix_dgram_recvmsg() in linux/net/unix/af_unix.c, in case of truncation the buffer size is returned and not the full packet length. In my opinion this implementation of local sockets (PF_UNIX) is not following the wording of the man page man 2 recv: "These calls return the number of bytes received". Am I getting something wrong here? Why not improve consistency and make unix_dgram_recvmsg() return the full packet length? So it would behave as UDP does. What do you think about adding the following code to linux/net/unix/af_unix.c: err = size; +if (flags & MSG_TRUNC) +err = skb->len; Cheers Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
H. Peter Anvin, Vivek Goyal wrote: >> Either way, though, putting Gujin-specific code in the main kernel >> output is a pretty dull thud. > > Agreed. May I ask if you are refering to the Gujin structures under the ROOT_EXTENSIVE_SEARCH compilation switch, or the C structures describing the BIOS which could even be used in the kernel? Eric W. Biederman wrote: > From what little I skimmed part of what Gujin wanted to do was sane > at first glance. Just boot a gziped vmlinux like the other > architectures. The problem was the 16bit code. So without ROOT_EXTENSIVE_SEARCH defined. It is so usefull when you have loads of distributions... But yes, maybe that part should be in another file, maybe not a complete directory for a single file. There is also a special problem with ia32, the number of processor involved and their partial compatibilities, that Gujin try to help with. > So there may be some good ideas buried in there somewhere, but it > likely to take some doing, and patches that I have to save before > I read them are a real pain! Last time I used this web interface it did not encode text files... > Eric Thanks, Etienne. ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] backlight control for Frontpath ProGear HX1050+
From: Marcin Juszkiewicz <[EMAIL PROTECTED]>
Add control of LCD backlight for Frontpath ProGear HX1050+.
Patch is based on http://downloads.sf.net/progear/progear-lcd-0.2.tar.gz
driver by M Schacht.
Signed-Off-By: Marcin Juszkiewicz <[EMAIL PROTECTED]>
---
Patch follow kernel version 2.6.20
Kconfig |8 +++
Makefile |1
progear_bl.c | 157 +++
3 files changed, 166 insertions(+)
Index: linux-2.6.20/drivers/video/backlight/Kconfig
===
--- linux-2.6.20.orig/drivers/video/backlight/Kconfig 2007-02-04
19:44:54.0 +0100
+++ linux-2.6.20/drivers/video/backlight/Kconfig2007-02-05
16:13:13.0 +0100
@@ -66,3 +66,11 @@
If you have a HP Jornada 680, say y to enable the
backlight driver.
+config BACKLIGHT_PROGEAR
+ tristate "Frontpath ProGear Backlight Driver"
+ depends on BACKLIGHT_DEVICE && PCI
+ default y
+ help
+ If you have a Frontpath ProGear say Y to enable the
+ backlight driver.
+
Index: linux-2.6.20/drivers/video/backlight/progear_bl.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.20/drivers/video/backlight/progear_bl.c 2007-02-05
16:29:14.0 +0100
@@ -0,0 +1,157 @@
+/*
+ * Backlight Driver for Frontpath ProGear HX1050+
+ *
+ * Copyright (c) 2006 Marcin Juszkiewicz
+ *
+ * Based on Progear LCD driver by M Schacht
+ *
+ *
+ * Based on Sharp's Corgi Backlight Driver
+ * Based on Backlight Driver for HP Jornada 680
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PMU_LPCR 0xB0
+#define SB_MPS10x61
+#define HW_LEVEL_MAX 0x77
+#define HW_LEVEL_MIN 0x4f
+
+static int progearbl_intensity;
+static struct backlight_properties progearbl_data;
+static struct backlight_device *progear_backlight_device;
+
+static struct pci_dev *pmu_dev = NULL;
+static struct pci_dev *sb_dev = NULL;
+
+static int progearbl_send_intensity(struct backlight_device *bd)
+{
+ int intensity = bd->props->brightness;
+
+ if (bd->props->power != FB_BLANK_UNBLANK)
+ intensity = 0;
+ if (bd->props->fb_blank != FB_BLANK_UNBLANK)
+ intensity = 0;
+
+ pci_write_config_byte(pmu_dev, PMU_LPCR, intensity + HW_LEVEL_MIN);
+
+ progearbl_intensity = intensity;
+
+ return 0;
+}
+
+static int progearbl_get_intensity(struct backlight_device *bd)
+{
+ return progearbl_intensity;
+}
+
+static int progearbl_set_intensity(struct backlight_device *bd)
+{
+ progearbl_send_intensity(progear_backlight_device);
+
+ return 0;
+}
+
+static struct backlight_properties progearbl_data = {
+ .owner = THIS_MODULE,
+ .get_brightness = progearbl_get_intensity,
+ .update_status = progearbl_set_intensity,
+};
+
+static int progearbl_probe(struct platform_device *pdev)
+{
+ u8 temp;
+
+ pmu_dev = pci_get_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M7101, 0);
+ if (!pmu_dev) {
+ printk("ALI M7101 PMU not found.\n");
+ return -ENODEV;
+ }
+
+ sb_dev = pci_get_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M1533, 0);
+ if (!sb_dev) {
+ printk("ALI 1533 SB not found.\n");
+ pci_dev_put(pmu_dev);
+ return -ENODEV;
+ }
+
+ /* Set SB_MPS1 to enable brightness control. */
+ pci_read_config_byte(sb_dev, SB_MPS1, &temp);
+ pci_write_config_byte(sb_dev, SB_MPS1, temp | 0x20);
+
+ progear_backlight_device = backlight_device_register("progear-bl",
+ &pdev->dev, NULL, &progearbl_data);
+ if (IS_ERR(progear_backlight_device))
+ return PTR_ERR(progear_backlight_device);
+
+ progearbl_data.power = FB_BLANK_UNBLANK;
+ progearbl_data.brightness = HW_LEVEL_MAX - HW_LEVEL_MIN;
+ progearbl_data.max_brightness = HW_LEVEL_MAX - HW_LEVEL_MIN;
+ progearbl_send_intensity(progear_backlight_device);
+
+ return 0;
+}
+
+static int progearbl_remove(struct platform_device *dev)
+{
+ backlight_device_unregister(progear_backlight_device);
+
+ return 0;
+}
+
+static struct platform_driver progearbl_driver = {
+ .probe = progearbl_probe,
+ .remove = progearbl_remove,
+ .driver = {
+ .name = "progear-bl",
+ },
+};
+
+static struct platform_device *progearbl_device;
+
+static int __init progearbl_init(void)
+{
+ int ret = platform_driver_register(&progearbl_driver);
+ if (!ret) {
+ pro
Re: [PATCH] move remove_dquot_ref to dqout.c
On Mon 05-02-07 19:05:27, Christoph Hellwig wrote:
> Remove_dquot_ref can move to dqout.c instead of beeing in inode.c
> under #ifdef CONFIG_QUOTA. Also clean the resulting code up
Yes, this was because at the time the code was written, inode_lock was not
exported
from inode.c.
> a tiny little bit by testing sb->dq_op earlier - it's constant
> over a filesystems lifetime.
Looks fine.
> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
>
> Index: linux-2.6/fs/dquot.c
> ===
> --- linux-2.6.orig/fs/dquot.c 2007-02-05 18:49:41.0 +0100
> +++ linux-2.6/fs/dquot.c 2007-02-05 18:53:49.0 +0100
> @@ -79,6 +79,7 @@
> #include
> #include
> #include
> +#include /* for inode_lock, oddly enough.. */
>
> #include
>
> @@ -756,15 +757,30 @@
> }
> }
>
> +static void remove_dquot_ref(struct super_block *sb, int type,
> + struct list_head *tofree_head)
> +{
> + struct inode *inode;
> +
> + spin_lock(&inode_lock);
> + list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
> + if (!IS_NOQUOTA(inode))
> + remove_inode_dquot_ref(inode, type, tofree_head);
> + }
> + spin_unlock(&inode_lock);
> +}
> +
> /* Gather all references from inodes and drop them */
> static void drop_dquot_ref(struct super_block *sb, int type)
> {
> LIST_HEAD(tofree_head);
>
> - down_write(&sb_dqopt(sb)->dqptr_sem);
> - remove_dquot_ref(sb, type, &tofree_head);
> - up_write(&sb_dqopt(sb)->dqptr_sem);
> - put_dquot_list(&tofree_head);
> + if (sb->dq_op) {
> + down_write(&sb_dqopt(sb)->dqptr_sem);
> + remove_dquot_ref(sb, type, &tofree_head);
> + up_write(&sb_dqopt(sb)->dqptr_sem);
> + put_dquot_list(&tofree_head);
> + }
> }
>
> static inline void dquot_incr_inodes(struct dquot *dquot, unsigned long
> number)
> Index: linux-2.6/fs/inode.c
> ===
> --- linux-2.6.orig/fs/inode.c 2007-02-05 18:49:41.0 +0100
> +++ linux-2.6/fs/inode.c 2007-02-05 18:49:56.0 +0100
> @@ -1252,33 +1252,6 @@
>
> EXPORT_SYMBOL(inode_needs_sync);
>
> -/*
> - * Quota functions that want to walk the inode lists..
> - */
> -#ifdef CONFIG_QUOTA
> -
> -void remove_dquot_ref(struct super_block *sb, int type,
> - struct list_head *tofree_head)
> -{
> - struct inode *inode;
> -
> - if (!sb->dq_op)
> - return; /* nothing to do */
> - spin_lock(&inode_lock); /* This lock is for inodes code */
> -
> - /*
> - * We don't have to lock against quota code - test IS_QUOTAINIT is
> - * just for speedup...
> - */
> - list_for_each_entry(inode, &sb->s_inodes, i_sb_list)
> - if (!IS_NOQUOTA(inode))
> - remove_inode_dquot_ref(inode, type, tofree_head);
> -
> - spin_unlock(&inode_lock);
> -}
> -
> -#endif
> -
> int inode_wait(void *word)
> {
> schedule();
> Index: linux-2.6/include/linux/fs.h
> ===
> --- linux-2.6.orig/include/linux/fs.h 2007-02-05 18:51:48.0 +0100
> +++ linux-2.6/include/linux/fs.h 2007-02-05 18:51:52.0 +0100
> @@ -1681,7 +1681,6 @@
> extern int __remove_suid(struct dentry *, int);
> extern int should_remove_suid(struct dentry *);
> extern int remove_suid(struct dentry *);
> -extern void remove_dquot_ref(struct super_block *, int, struct list_head *);
>
> extern void __insert_inode_hash(struct inode *, unsigned long hashval);
> extern void remove_inode_hash(struct inode *);
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel: shut up the IRQ mismatch messages (Re: wbsd: IRQ handler type mismatch)
On Mon, 05 Feb 2007 21:16:59 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> I'm seeing this on bootup on my laptop with recent kernels (currently
> 2.6.20-rc6-mm3):
The problem is various drivers legally validly and sensibly try to claim
IRQs but the kernel insists on vomiting forth a giant irrelevant
debugging spew when the types clash.
Edit kernel/irq/manage.c go down to mismatch: in setup_irq() and ifdef
out the if clause that checks for mismatches. It'll then just do the
right thing and work sanely.
For the current -mm kernel this will do the trick (and moves it into
shared irq debugging as in debug mode the info spew is useful). I've had
a variant of this in my private tree for some time as I got fed up on the
mess on boxes where old legacy IRQs get reused.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
--- linux.vanilla-2.6.20-rc6-mm3/kernel/irq/manage.c2007-01-31
14:20:43.0 +
+++ linux-2.6.20-rc6-mm3/kernel/irq/manage.c2007-02-06 11:01:00.796928504
+
@@ -372,12 +372,14 @@
return 0;
mismatch:
+#ifdef CONFIG_DEBUG_SHIRQ
if (!(new->flags & IRQF_PROBE_SHARED)) {
printk(KERN_ERR "IRQ handler type mismatch for IRQ %d\n", irq);
if (old_name)
printk(KERN_ERR "current handler: %s\n", old_name);
dump_stack();
}
+#endif
spin_unlock_irqrestore(&desc->lock, flags);
return -EBUSY;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix NULL-pointer dereference in ia64_machine_kexec()
[I got no response after my corrected patch, so I try it again.
I request it to appear in -mm tree. Patch is against 2.6.20-rc6-mm3.]
This patch fixes a NULL-pointer dereference in ia64_machine_kexec().
The variable ia64_kimage is set in machine_kexec_prepare() which is
called from sys_kexec_load(). If kdump wasn't configured before,
ia64_kimage is NULL. machine_kdump_on_init() passes ia64_kimage() to
machine_kexec() which assumes a valid value.
The patch also adds a few sanity checks for the image to simplify
debugging of similar problems in future.
Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
---
arch/ia64/kernel/crash.c |5 +
arch/ia64/kernel/machine_kexec.c |2 ++
2 files changed, 7 insertions(+)
Index: b/arch/ia64/kernel/crash.c
===
--- a/arch/ia64/kernel/crash.c
+++ b/arch/ia64/kernel/crash.c
@@ -116,6 +116,11 @@ machine_crash_shutdown(struct pt_regs *p
static void
machine_kdump_on_init(void)
{
+ if (!ia64_kimage) {
+ printk(KERN_NOTICE "machine_kdump_on_init(): "
+ "kdump not configured\n");
+ return;
+ }
local_irq_disable();
kexec_disable_iosapic();
machine_kexec(ia64_kimage);
Index: b/arch/ia64/kernel/machine_kexec.c
===
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -93,6 +93,7 @@ static void ia64_machine_kexec(struct un
unsigned long vector;
int ii;
+ BUG_ON(!image);
if (image->type == KEXEC_TYPE_CRASH) {
crash_save_this_cpu();
current->thread.ksp = (__u64)info->sw - 16;
@@ -131,6 +132,7 @@ static void ia64_machine_kexec(struct un
void machine_kexec(struct kimage *image)
{
+ BUG_ON(!image);
unw_init_running(ia64_machine_kexec, image);
for(;;);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: v2.6.20-rt1, yum/rpm
On Mon, 2007-02-05 at 07:56 +0100, Ingo Molnar wrote:
> i have released the v2.6.20-rt1 kernel, which can be downloaded from the
> usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> more info about the -rt patchset can be found in the RT wiki:
>
> http://rt.wiki.kernel.org
>
> This is a fixes-only release. Since the -rt tree has been closely
> tracking Linus' upstream kernel since -rc1, no new issues are expected -
> please re-report if anything is still unfixed.
patch below has 2 tweaks
1) the new RCU feature wakes up once per second, make sure this is using
the new round_jiffies() infrastructure
2) the slab background reap code is waking up once per 2 seconds per
cpu. The patch makes this more dynamic; if no work was done (no activity
on the cpu happened) then this is made to be 4 seconds
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Index: linux-2.6.20-rt2/kernel/rcupreempt.c
===
--- linux-2.6.20-rt2.orig/kernel/rcupreempt.c
+++ linux-2.6.20-rt2/kernel/rcupreempt.c
@@ -465,7 +465,7 @@ static int rcu_booster(void *arg)
* adjust, or eliminate in case of OOM.
*/
- schedule_timeout_interruptible(HZ);
+ schedule_timeout_interruptible(round_jiffies_relative(HZ));
/* Print stats if enough time has passed. */
Index: linux-2.6.20-rt2/kernel/rcutorture.c
===
--- linux-2.6.20-rt2.orig/kernel/rcutorture.c
+++ linux-2.6.20-rt2/kernel/rcutorture.c
@@ -288,7 +288,7 @@ static int rcu_torture_preempt(void *arg
cond_resched();
if (rcu_torture_completed() == completedstart)
rcu_torture_preempt_errors++;
- schedule_timeout_interruptible(HZ);
+ schedule_timeout_interruptible(round_jiffies_relative(HZ));
} while (!kthread_should_stop());
return 0;
}
@@ -660,7 +660,7 @@ rcu_torture_reader(void *arg)
if (p == NULL) {
/* Wait for rcu_torture_writer to get underway */
cur_ops->readunlock(idx);
- schedule_timeout_interruptible(HZ);
+
schedule_timeout_interruptible(round_jiffies_relative(HZ));
continue;
}
if (p->rtort_mbtest == 0)
Index: linux-2.6.20-rt2/mm/slab.c
===
--- linux-2.6.20-rt2.orig/mm/slab.c
+++ linux-2.6.20-rt2/mm/slab.c
@@ -1062,7 +1062,7 @@ static int transfer_objects(struct array
#ifndef CONFIG_NUMA
#define drain_alien_cache(cachep, alien) do { } while (0)
-#define reap_alien(cachep, l3, this_cpu) do { } while (0)
+#define reap_alien(cachep, l3, this_cpu) 0
static inline struct array_cache **alloc_alien_cache(int node, int limit)
{
@@ -1160,7 +1160,7 @@ static void __drain_alien_cache(struct k
/*
* Called from cache_reap() to regularly drain alien caches round robin.
*/
-static void
+static int
reap_alien(struct kmem_cache *cachep, struct kmem_list3 *l3, int *this_cpu)
{
int node = per_cpu(reap_node, *this_cpu);
@@ -1171,8 +1171,10 @@ reap_alien(struct kmem_cache *cachep, st
if (ac && ac->avail && spin_trylock_irq(&ac->lock)) {
__drain_alien_cache(cachep, ac, node, this_cpu);
spin_unlock_irq(&ac->lock);
+ return 1;
}
}
+ return 0;
}
static void drain_alien_cache(struct kmem_cache *cachep,
@@ -2473,7 +2475,7 @@ static void check_spinlock_acquired_node
#define check_spinlock_acquired_node(x, y) do { } while(0)
#endif
-static void drain_array(struct kmem_cache *cachep, struct kmem_list3 *l3,
+static int drain_array(struct kmem_cache *cachep, struct kmem_list3 *l3,
struct array_cache *ac,
int force, int node);
@@ -4114,15 +4116,16 @@ static int enable_cpucache(struct kmem_c
* Drain an array if it contains any elements taking the l3 lock only if
* necessary. Note that the l3 listlock also protects the array_cache
* if drain_array() is used on the shared array.
+ * returns non-zero if some work is done
*/
-void drain_array(struct kmem_cache *cachep, struct kmem_list3 *l3,
+int drain_array(struct kmem_cache *cachep, struct kmem_list3 *l3,
struct array_cache *ac, int force, int node)
{
int this_cpu = smp_processor_id();
int tofree;
if (!ac || !ac->avail)
- return;
+ return 0;
if (ac->touched && !force) {
ac->touched = 0;
} else {
@@ -4138,6 +4141,7 @@ void drain_array(struct kmem_cache *cach
}
slab_spin_unlock_irq(&l3->list_lock, this_cpu);
}
+ return 1;
}
/**
@@ -4157,6 +4161,7 @@ static void cac
Re: v2.6.20-rt1, yum/rpm
On 2/5/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: i have released the v2.6.20-rt1 kernel, which can be downloaded from the This is about 2.6.20-rt2, no issues here. PID TTY STAT TIME COMMAND 1 ?Ss 0:00 init [5] 2 ?S 0:00 [migration/0] 3 ?S 0:00 [posix_cpu_timer] 4 ?S 0:00 [softirq-high/0] 5 ?S 0:00 [softirq-timer/0] 6 ?S 0:00 [softirq-net-tx/] 7 ?S 0:00 [softirq-net-rx/] 8 ?S 0:00 [softirq-block/0] 9 ?S 0:00 [softirq-tasklet] 10 ?S 0:00 [softirq-sched/0] 11 ?S 0:00 [softirq-hrtimer] 12 ?S 0:00 [softirq-rcu/0] 13 ?S< 0:00 [desched/0] 14 ?S 0:00 [migration/1] 15 ?S 0:00 [posix_cpu_timer] 16 ?S 0:00 [softirq-high/1] 17 ?S 0:00 [softirq-timer/1] 18 ?S 0:00 [softirq-net-tx/] 19 ?S 0:00 [softirq-net-rx/] 20 ?S 0:00 [softirq-block/1] 21 ?S 0:00 [softirq-tasklet] 22 ?S 0:00 [softirq-sched/1] 23 ?S 0:00 [softirq-hrtimer] 24 ?S 0:00 [softirq-rcu/1] 25 ?S< 0:00 [desched/1] 26 ?S< 0:00 [events/0] 27 ?S< 0:00 [events/1] 28 ?S< 0:00 [khelper] 29 ?S 0:00 [RCU Prio Booste] 30 ?S< 0:00 [kthread] 63 ?S< 0:00 [kblockd/0] 64 ?S< 0:00 [kblockd/1] 65 ?S< 0:00 [kacpid] 66 ?S< 0:00 [IRQ-9] 157 ?S< 0:00 [cqueue/0] 158 ?S< 0:00 [cqueue/1] 159 ?S< 0:00 [ksuspend_usbd] 162 ?S< 0:00 [khubd] 164 ?S< 0:00 [kseriod] 189 ?S 0:00 [pdflush] 190 ?S 0:00 [pdflush] 191 ?S< 0:00 [kswapd0] 192 ?S< 0:00 [flush_filesd/0] 193 ?S< 0:00 [flush_filesd/1] 194 ?S< 0:00 [aio/0] 195 ?S< 0:00 [aio/1] 285 ?S< 0:00 [IRQ-8] 317 ?S< 0:00 [IRQ-14] 332 ?S< 0:00 [IRQ-12] 333 ?S< 0:00 [IRQ-1] 339 ?S< 0:00 [kpsmoused] 343 ?S 0:00 [kirqd] 351 ?S< 0:00 [IRQ-20] 352 ?S< 0:00 [IRQ-19] 353 ?S< 0:00 [IRQ-18] 354 ?S< 0:00 [IRQ-16] 376 ?S< 0:00 [ata/0] 377 ?S< 0:00 [ata/1] 378 ?S< 0:00 [ata_aux] 382 ?S< 0:00 [scsi_eh_0] 383 ?S< 0:00 [scsi_eh_1] 384 ?S< 0:00 [kjournald] 412 ?S< 0:00 [kauditd] 449 ?Shttp://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 9/9] mm: fix pagecache write deadlocks
On Tue, 2007-02-06 at 03:09 +0100, Nick Piggin wrote: > On Sun, Feb 04, 2007 at 05:40:35PM +, Anton Altaparmakov wrote: > > On Sun, 4 Feb 2007, Andrew Morton wrote: > > > truncate's OK: we're holding i_mutex. > > > > How about excluding readpage() (in addition to truncate if Nick is right > > and some cases of truncate do not hold i_mutex) with an extra page flag as > > I proposed for truncate exclusion? Then it would not matter that > > prepare_write might have allocated blocks and might expose stale data. > > It would go to sleep and wait on the bit to be cleared instead of trying > > to bring the page uptodate. It can then lock the page and either find it > > uptodate (because commit_write did it) or not and then bring it uptodate. > > > > Then we could safely fault in the page, copy from it into a temporary > > page, then lock the destination page again and copy into it. > > > > This is getting more involved as a patch again... )-: But at least it > > does not affect the common case except for having to check the new page > > flag in every readpage() and truncate() call. But at least the checks > > could be with an "if (unlikely(newpageflag()))" so should not be too bad. > > > > Have I missed anything this time? > > Yes. If you have a flag to exclude readpage(), then you must also > exclude filemap_nopage, in which case it is still deadlocky. Ouch, you are of course right. )-: Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove sb->s_files and file_list_lock usage in dquot.c
Iterate over sb->s_inodes instead of sb->s_files in add_dquot_ref.
This reduces list search and lock hold time aswell as getting rid of
one of the few uses of file_list_lock which Ingo identified as a
scalability problem.
Previously we called dq_op->initialize for every inode handing of
a writeable file that wasn't initialized before. Now we're calling
it for every inode that has a non-zero i_writecount, aka a writeable
file descriptor refering to it.
Thanks a lot to Jan Kara for running this patch through his quota
test harness.
Note: this is ontop of '[PATCH] move remove_dquot_ref to dqout.c'
which I sent out yesterday.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/fs/dquot.c
===
--- linux-2.6.orig/fs/dquot.c 2007-02-05 18:54:36.0 +0100
+++ linux-2.6/fs/dquot.c2007-02-05 18:59:48.0 +0100
@@ -689,23 +689,27 @@
/* This routine is guarded by dqonoff_mutex mutex */
static void add_dquot_ref(struct super_block *sb, int type)
{
- struct list_head *p;
+ struct inode *inode;
restart:
- file_list_lock();
- list_for_each(p, &sb->s_files) {
- struct file *filp = list_entry(p, struct file, f_u.fu_list);
- struct inode *inode = filp->f_path.dentry->d_inode;
- if (filp->f_mode & FMODE_WRITE && dqinit_needed(inode, type)) {
- struct dentry *dentry = dget(filp->f_path.dentry);
- file_list_unlock();
- sb->dq_op->initialize(inode, type);
- dput(dentry);
- /* As we may have blocked we had better restart... */
- goto restart;
- }
+ spin_lock(&inode_lock);
+ list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
+ if (!atomic_read(&inode->i_writecount))
+ continue;
+ if (!dqinit_needed(inode, type))
+ continue;
+ if (inode->i_state & (I_FREEING|I_WILL_FREE))
+ continue;
+
+ __iget(inode);
+ spin_unlock(&inode_lock);
+
+ sb->dq_op->initialize(inode, type);
+ iput(inode);
+ /* As we may have blocked we had better restart... */
+ goto restart;
}
- file_list_unlock();
+ spin_unlock(&inode_lock);
}
/* Return 0 if dqput() won't block (note that 1 doesn't necessarily mean
blocking) */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, Ingo Oeser wrote: > On Monday, 5. February 2007, Linus Torvalds wrote: > > So thank God for the few selects we have, and we should add a whole lot > > more! > > But "select" is not fine grained enough. > > I would like to have "require", "recommend", "suggest" for feature A. > > require X > does not work without X, but X is way down the tree > e.g. ext3 and block device or how select currently is intended > > recommend X > it is usable but uncomfortable without X, enabled per default > e.g. firewalling recommends connection tracking support > or NAT recommends all NAT helpers > > suggest X > many people use A together with X, > so you might be interested in enabling it, but I disabled it > per default unless you said "featuritis mode" before. > e.g. highmem and SMP or a network driver and NAPI. > > That is what the Debian/Ubuntu package management does and maybe other too. > And this also gives us new keywords to replace select with, > so migration is doable :-) > > This would also make "EMBEDDED" superflous, because it would just mean > "disable anything not required". > > And this would enable an individual tree for the users current configuration > problem instead of a global one. I think "package manager" is the best possible way to think about this problem. I can't tell you how often I've wished the kernel config process behaved like apt and just prompted me with a list of things it would need to enable to allow me to use the option and ask me if I still want to do it. The reverse when I try and remove something important would be good too just ask me if I really want to remove all those as well. A functional equivelant of deborphan would be cool too. Just run it and have it tell me what is enabled that no devices depend on. The config system is nasty even for power users. There is a fun part of the netfilter code where I find myself having to enable all from one menu, go to the next menu down enable everything and then go back to the first menu. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
