* Re: READ SCSI cmd seems to fail on SATA optical devices...
From: Tejun Heo @ 2006-11-15 16:04 UTC (permalink / raw)
To: Mathieu Fluhr
Cc: Arjan van de Ven, Phillip Susi, jgarzik, linux-ide, linux-kernel
In-Reply-To: <1163603958.3029.3.camel@de-c-l-110.nero-de.internal>
Mathieu Fluhr wrote:
> On Wed, 2006-11-15 at 02:24 +0900, Tejun Heo wrote:
>>> ... and the problem is not in accessing the device itself (this is
>>> working like a charm) but understanding why a SCSI READ(10) cmd
>>> sometimes fails as a ATA-padded READ(10) cmd - as discribed in the
>> Annex
>>> A of the MMC-5 spec - ALWAYS works.
>>> -> I would suspect somehow a synchronisation problem somehow in the
>>> translation of SCSI to ATA command...
>> Can you try the attached patch and see if anything changes?
>>
>
> The patch _seems_ to solve my problem. I am just really astonished when
> I read the diff file :D. Can I expect that it will be merged to the
> official kernel sources ?
It seems that some devices choke when the bytes after CDB contain
garbage. I seem to recall that I read somewhere ATAPI device require
left command bytes cleared to zero but I can't find it anywhere now.
Maybe I'm just imagining. Anyways, yeah, I'll push it to upstream.
--
tejun
^ permalink raw reply
* Re: git tag: don't complain of empty messages
From: Johannes Schindelin @ 2006-11-15 16:02 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <ejfc1t$6am$1@sea.gmane.org>
Hi,
On Wed, 15 Nov 2006, Han-Wen Nienhuys wrote:
> GIT refuses to set annotated tags without a comment. I think this is a silly
> restriction when the message is explicitly set to the empty string.
I think that this behaviour is on purpose: The tag will be identified
(like all objects in git) by its contents. The rationale: the filename
does not matter, since the tag _object_ is not identified by it. So, in
case you lose your .git/refs/tags/ directory, you can still reconstruct
the tags with "git-fsck-objects --full".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 05/19] NFS: Use local caching
From: David Howells @ 2006-11-15 16:00 UTC (permalink / raw)
To: Trond Myklebust
Cc: David Howells, torvalds, akpm, sds, selinux, linux-kernel, aviro,
steved
In-Reply-To: <1163603377.5691.113.camel@lade.trondhjem.org>
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> Why is fscache being given a vote on whether or not the NFS page can be
> removed from the mapping? If the file has changed on the server, so that
> we have to invalidate the mapping, then I don't care about the fact that
> fscache is busy: the page has to go.
This is releasepage() not invalidatepage(). It is conditional.
At this point you can't get rid of the page if FS-Cache is still using it
because FS-Cache will call the netfs callback on the page when it has finished.
You also can't cancel the I/O because it may involve a BIO which itself can't
be cancelled.
You may not be able to sleep to wait for FS-Cache to finish because gfp might
not include __GFP_WAIT.
The whole point is to find out whether a page is releasable and recycle it if
it is, not to force it to be released; for that, invalidatepage() exists.
In my opinion, it is better to tell the VM that this page is not currently
available, and let it get on with trying to find one that is rather than
holding up the page allocator until the page becomes available.
> You are missing the NFSv4 change attribute. The latter is supposed to
> override mtime/ctime/size concerns in NFSv4.
Is that stored in the inode? I don't recall offhand. It's easy enough to add
if it is.
> > @@ -84,6 +84,7 @@ void nfs_clear_inode(struct inode *inode
> ...
> What about nfs4_clear_inode?
It calls nfs_clear_inode()...
> > + nfs_fscache_zap_fh_cookie(inode);
>
> The cache will be zapped upon the next revalidation anyway. and the
> whole point of nfs_zap_caches is to allow fast invalidation in contexts
> where we cannot sleep. nfs_fscache_zap_fh_cookie calls
> fscache_relinquish_cookie(), which sleeps, grabs rw_semaphores, etc.
Okay... It sounds like I should be able to drop that call there.
Perhaps you should add a comment to that function to note this...
> > @@ -376,6 +383,7 @@ void nfs_setattr_update_inode(struct ino
> > if ((attr->ia_valid & ATTR_SIZE) != 0) {
> > nfs_inc_stats(inode, NFSIOS_SETATTRTRUNC);
> > inode->i_size = attr->ia_size;
> > + nfs_fscache_set_size(inode);
>
> Why? Isn't this supposed to be a read-only inode?
I suppose. This is a holdover from when I supported R/W inodes too.
> > @@ -942,11 +954,13 @@ static int nfs_update_inode(struct inode
> > ...
> > + nfs_fscache_set_size(inode);
>
> Doesn't nfs_fscache_set_size try to grab rw_semaphores? This function is
> _always_ called with the inode->i_lock spinlock held.
Hmmm... I wonder if I need to do this in nfs_update_inode() at all. Won't the
pages and the cache object attached to an inode be discarded anyway if the file
attributes returned by the server change?
When can an inode be left with its data attached when modified on the server?
Is this an NFSv4 thing?
> > static void nfs_readpage_release(struct nfs_page *req)
> > {
> > + struct inode *d_inode = req->wb_context->dentry->d_inode;
> > +
> > + if (PageUptodate(req->wb_page))
> > + nfs_readpage_to_fscache(d_inode, req->wb_page, 0);
> > +
>
> Will usually be called from an rpciod context. Should therefore not be
> grabbing semaphores, doing memory allocation etc.
Is it possible to make an NFS kernel thread that can have completed nfs_page
structs queued for writing to the cache?
> > +
> > + nfs_writepage_to_fscache(inode, page);
> > +
>
> Why are we doing this, if the cache is turned off whenever the file is
> open for writes?
Good point again; for the moment, this can be discarded - though we could do it
for NFS4 under some circumstances, I believe.
David
^ permalink raw reply
* [2.6.16/18 patch] security/seclvl.c: fix time wrap (CVE-2005-4352)
From: Adrian Bunk @ 2006-11-15 16:01 UTC (permalink / raw)
To: Chris Wright, Michael Halcrow; +Cc: linux-kernel, stable
initlvl=2 in seclvl gives the guarantee
"Cannot decrement the system time".
But it was possible to set the time to the maximum unixtime value
(19 Jan 2038) resulting in a wrap to the minimum value.
This patch fixes this by disallowing setting the time to any date
after 2031 with initlvl=2.
This patch does not apply to kernel 2.6.19 since the seclvl module was
already removed in this kernel.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16.32/security/seclvl.c.old 2006-11-15 13:58:05.000000000 +0100
+++ linux-2.6.16.32/security/seclvl.c 2006-11-15 16:41:51.000000000 +0100
@@ -381,6 +381,8 @@ static int seclvl_settime(struct timespe
current->group_leader->pid);
return -EPERM;
} /* if attempt to decrement time */
+ if (tv->tv_sec > 1924988400) /* disallow dates after 2030) */
+ return -EPERM; /* CVE-2005-4352 */
} /* if seclvl > 1 */
return 0;
}
^ permalink raw reply
* Re: How mdadm can support > 2T
From: Chris Allen @ 2006-11-15 16:00 UTC (permalink / raw)
To: 俞先印; +Cc: linux-raid
In-Reply-To: <200611151236376090234@dahuatech.com>
俞先印 wrote:
> Ilinux-raid want to create raid0 use mdadm 2.5.6, kernel 2.6.18-iop3 on the intel iop80331(32bit). use 5 disks, and every hard disk is 500G. But it can't beyond > 2T. How can support >2T on the 32bit cpu ?
>
> command and log :
> #mdadm -C /dev/md0 -l0 -n5 /dev/sd[c,d,e,f,g]
> # mdadm --detail /dev/md0
>
>
I have many arrays which are 12TB or greater - so I don't think this is
your problem.
It looks like mdadm is only using 60GB from each disk.
What output do you get from these commands:
fdisk -l /dev/sdc
mdadm --examine /dev/sdc
?
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 05/19] NFS: Use local caching
From: David Howells @ 2006-11-15 16:00 UTC (permalink / raw)
To: Trond Myklebust
Cc: David Howells, torvalds, akpm, sds, selinux, linux-kernel, aviro,
steved
In-Reply-To: <1163603377.5691.113.camel@lade.trondhjem.org>
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> Why is fscache being given a vote on whether or not the NFS page can be
> removed from the mapping? If the file has changed on the server, so that
> we have to invalidate the mapping, then I don't care about the fact that
> fscache is busy: the page has to go.
This is releasepage() not invalidatepage(). It is conditional.
At this point you can't get rid of the page if FS-Cache is still using it
because FS-Cache will call the netfs callback on the page when it has finished.
You also can't cancel the I/O because it may involve a BIO which itself can't
be cancelled.
You may not be able to sleep to wait for FS-Cache to finish because gfp might
not include __GFP_WAIT.
The whole point is to find out whether a page is releasable and recycle it if
it is, not to force it to be released; for that, invalidatepage() exists.
In my opinion, it is better to tell the VM that this page is not currently
available, and let it get on with trying to find one that is rather than
holding up the page allocator until the page becomes available.
> You are missing the NFSv4 change attribute. The latter is supposed to
> override mtime/ctime/size concerns in NFSv4.
Is that stored in the inode? I don't recall offhand. It's easy enough to add
if it is.
> > @@ -84,6 +84,7 @@ void nfs_clear_inode(struct inode *inode
> ...
> What about nfs4_clear_inode?
It calls nfs_clear_inode()...
> > + nfs_fscache_zap_fh_cookie(inode);
>
> The cache will be zapped upon the next revalidation anyway. and the
> whole point of nfs_zap_caches is to allow fast invalidation in contexts
> where we cannot sleep. nfs_fscache_zap_fh_cookie calls
> fscache_relinquish_cookie(), which sleeps, grabs rw_semaphores, etc.
Okay... It sounds like I should be able to drop that call there.
Perhaps you should add a comment to that function to note this...
> > @@ -376,6 +383,7 @@ void nfs_setattr_update_inode(struct ino
> > if ((attr->ia_valid & ATTR_SIZE) != 0) {
> > nfs_inc_stats(inode, NFSIOS_SETATTRTRUNC);
> > inode->i_size = attr->ia_size;
> > + nfs_fscache_set_size(inode);
>
> Why? Isn't this supposed to be a read-only inode?
I suppose. This is a holdover from when I supported R/W inodes too.
> > @@ -942,11 +954,13 @@ static int nfs_update_inode(struct inode
> > ...
> > + nfs_fscache_set_size(inode);
>
> Doesn't nfs_fscache_set_size try to grab rw_semaphores? This function is
> _always_ called with the inode->i_lock spinlock held.
Hmmm... I wonder if I need to do this in nfs_update_inode() at all. Won't the
pages and the cache object attached to an inode be discarded anyway if the file
attributes returned by the server change?
When can an inode be left with its data attached when modified on the server?
Is this an NFSv4 thing?
> > static void nfs_readpage_release(struct nfs_page *req)
> > {
> > + struct inode *d_inode = req->wb_context->dentry->d_inode;
> > +
> > + if (PageUptodate(req->wb_page))
> > + nfs_readpage_to_fscache(d_inode, req->wb_page, 0);
> > +
>
> Will usually be called from an rpciod context. Should therefore not be
> grabbing semaphores, doing memory allocation etc.
Is it possible to make an NFS kernel thread that can have completed nfs_page
structs queued for writing to the cache?
> > +
> > + nfs_writepage_to_fscache(inode, page);
> > +
>
> Why are we doing this, if the cache is turned off whenever the file is
> open for writes?
Good point again; for the moment, this can be discarded - though we could do it
for NFS4 under some circumstances, I believe.
David
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [linux-lvm] No label detected
From: Alasdair G Kergon @ 2006-11-15 15:58 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <168918.46162.qm@web51015.mail.yahoo.com>
Wipe the partition tables if you aren't using partitions.
(Back them up first of course.)
Alasdair
--
agk@redhat.com
^ permalink raw reply
* pagefault in generic_file_buffered_write() causing deadlock
From: Badari Pulavarty @ 2006-11-15 15:57 UTC (permalink / raw)
To: akpm, linux-mm; +Cc: ext4, lkml
Hi Andrew & MM experts,
We are looking at a customer situation (on 2.6.16-based distro) - where
system becomes almost useless while running some java & stress tests.
Root cause seems to be taking a pagefault in generic_file_buffered_write
() after calling prepare_write. I am wondering
1) Why & How this can happen - since we made sure to fault the user
buffer before prepare write.
2) If this is already fixed in current mainline (I can't see how).
Ideas on what I can do to fix it ?
Thanks,
Badari
Here is the analysis & stacks:
===============================
Java thread doing mmap() holding for mmap_sem and waiting for
transaction to be unlocked:
java D 000000000fed3ff4 7104 2447 2391 2448 2446
(NOTLB)
Call Trace:
[C00000002AC8F410] [C000000001315AC0] 0xc000000001315ac0 (unreliable)
[C00000002AC8F5E0] [C00000000000F0B4] .__switch_to+0x12c/0x150
[C00000002AC8F670] [C00000000039980C] .schedule+0xcec/0xe4c
[C00000002AC8F780] [C00000000017BC24] .start_this_handle+0x3b4/0x4ac
[C00000002AC8F8A0] [C00000000017BE08] .journal_start+0xec/0x140
[C00000002AC8F940] [C000000000171374] .ext3_journal_start_sb+0x58/0x78
[C00000002AC8F9C0] [C00000000016AB90] .ext3_dirty_inode+0x38/0xb0
[C00000002AC8FA50] [C0000000000F6820] .__mark_inode_dirty+0x60/0x1d4
[C00000002AC8FAF0] [C0000000000E9F60] .touch_atime+0xc8/0xe0
[C00000002AC8FB80] [C000000000093834] .generic_file_mmap+0x54/0x80
[C00000002AC8FC00] [C0000000000AC450] .do_mmap_pgoff+0x558/0x870
[C00000002AC8FD10] [C00000000000A9C0] .sys_mmap+0xdc/0x160
[C00000002AC8FDC0] [C000000000014258] .compat_sys_mmap2+0x14/0x28
[C00000002AC8FE30] [C00000000000871C] syscall_exit+0x0/0x40
kjournald locked the transaction and waiting for journal stop
(t_updates to go to zero):
kjournald D 0000000000000000 8704 2167 1 2203 2028
(L-TLB)
Call Trace:
[C00000003514F980] [C0000000005257D8] amd74xx_pci_tbl+0x8/0x200 (unreliable)
[C00000003514FB50] [C00000000000F0B4] .__switch_to+0x12c/0x150
[C00000003514FBE0] [C00000000039980C] .schedule+0xcec/0xe4c
[C00000003514FCF0] [C00000000017DA58] .journal_commit_transaction+0x190/0x1448
[C00000003514FE50] [C000000000182F44] .kjournald+0xf0/0x27c
[C00000003514FF90] [C000000000025630] .kernel_thread+0x4c/0x68
Another java thread, did journal_start() in prepare_write() and
took a pagefault while copying. Now this is waiting for mmap_sem
to finish the fault :(
java D 000000000ffd76f0 6384 2452 2391 2453 2451
(NOTLB)
Call Trace:
[C00000002ABBEE50] [C00000002ABBEEE0] 0xc00000002abbeee0 (unreliable)
[C00000002ABBF020] [C00000000000F0B4] .__switch_to+0x12c/0x150
[C00000002ABBF0B0] [C00000000039980C] .schedule+0xcec/0xe4c
[C00000002ABBF1C0] [C00000000039B688] .rwsem_down_read_failed
+0x284/0x2d0
[C00000002ABBF290] [C00000000039D58C] .do_page_fault+0x2e4/0x75c
[C00000002ABBF460] [C000000000004860] .handle_page_fault+0x20/0x54
--- Exception: 301 at .__copy_tofrom_user+0x11c/0x580
LR = .generic_file_buffered_write+0x39c/0x7c8
[C00000002ABBF750] [C000000000095A94]
.generic_file_buffered_write+0x2c0/0x7c8 (
unreliable)
[C00000002ABBF8F0] [C0000000000962EC]
.__generic_file_aio_write_nolock+0x350/0x3
e0
[C00000002ABBFA20] [C000000000096908] .generic_file_aio_write+0x78/0x104
[C00000002ABBFAE0] [C0000000001649F0] .ext3_file_write+0x2c/0xd4
[C00000002ABBFB70] [C0000000000C5168] .do_sync_write+0xd4/0x130
[C00000002ABBFCF0] [C0000000000C5ED4] .vfs_write+0x128/0x20c
[C00000002ABBFD90] [C0000000000C664C] .sys_write+0x4c/0x8c
[C00000002ABBFE30] [C00000000000871C] syscall_exit+0x0/0x40
^ permalink raw reply
* pagefault in generic_file_buffered_write() causing deadlock
From: Badari Pulavarty @ 2006-11-15 15:57 UTC (permalink / raw)
To: akpm, linux-mm; +Cc: ext4, lkml
Hi Andrew & MM experts,
We are looking at a customer situation (on 2.6.16-based distro) - where
system becomes almost useless while running some java & stress tests.
Root cause seems to be taking a pagefault in generic_file_buffered_write
() after calling prepare_write. I am wondering
1) Why & How this can happen - since we made sure to fault the user
buffer before prepare write.
2) If this is already fixed in current mainline (I can't see how).
Ideas on what I can do to fix it ?
Thanks,
Badari
Here is the analysis & stacks:
===============================
Java thread doing mmap() holding for mmap_sem and waiting for
transaction to be unlocked:
java D 000000000fed3ff4 7104 2447 2391 2448 2446
(NOTLB)
Call Trace:
[C00000002AC8F410] [C000000001315AC0] 0xc000000001315ac0 (unreliable)
[C00000002AC8F5E0] [C00000000000F0B4] .__switch_to+0x12c/0x150
[C00000002AC8F670] [C00000000039980C] .schedule+0xcec/0xe4c
[C00000002AC8F780] [C00000000017BC24] .start_this_handle+0x3b4/0x4ac
[C00000002AC8F8A0] [C00000000017BE08] .journal_start+0xec/0x140
[C00000002AC8F940] [C000000000171374] .ext3_journal_start_sb+0x58/0x78
[C00000002AC8F9C0] [C00000000016AB90] .ext3_dirty_inode+0x38/0xb0
[C00000002AC8FA50] [C0000000000F6820] .__mark_inode_dirty+0x60/0x1d4
[C00000002AC8FAF0] [C0000000000E9F60] .touch_atime+0xc8/0xe0
[C00000002AC8FB80] [C000000000093834] .generic_file_mmap+0x54/0x80
[C00000002AC8FC00] [C0000000000AC450] .do_mmap_pgoff+0x558/0x870
[C00000002AC8FD10] [C00000000000A9C0] .sys_mmap+0xdc/0x160
[C00000002AC8FDC0] [C000000000014258] .compat_sys_mmap2+0x14/0x28
[C00000002AC8FE30] [C00000000000871C] syscall_exit+0x0/0x40
kjournald locked the transaction and waiting for journal stop
(t_updates to go to zero):
kjournald D 0000000000000000 8704 2167 1 2203 2028
(L-TLB)
Call Trace:
[C00000003514F980] [C0000000005257D8] amd74xx_pci_tbl+0x8/0x200 (unreliable)
[C00000003514FB50] [C00000000000F0B4] .__switch_to+0x12c/0x150
[C00000003514FBE0] [C00000000039980C] .schedule+0xcec/0xe4c
[C00000003514FCF0] [C00000000017DA58] .journal_commit_transaction+0x190/0x1448
[C00000003514FE50] [C000000000182F44] .kjournald+0xf0/0x27c
[C00000003514FF90] [C000000000025630] .kernel_thread+0x4c/0x68
Another java thread, did journal_start() in prepare_write() and
took a pagefault while copying. Now this is waiting for mmap_sem
to finish the fault :(
java D 000000000ffd76f0 6384 2452 2391 2453 2451
(NOTLB)
Call Trace:
[C00000002ABBEE50] [C00000002ABBEEE0] 0xc00000002abbeee0 (unreliable)
[C00000002ABBF020] [C00000000000F0B4] .__switch_to+0x12c/0x150
[C00000002ABBF0B0] [C00000000039980C] .schedule+0xcec/0xe4c
[C00000002ABBF1C0] [C00000000039B688] .rwsem_down_read_failed
+0x284/0x2d0
[C00000002ABBF290] [C00000000039D58C] .do_page_fault+0x2e4/0x75c
[C00000002ABBF460] [C000000000004860] .handle_page_fault+0x20/0x54
--- Exception: 301 at .__copy_tofrom_user+0x11c/0x580
LR = .generic_file_buffered_write+0x39c/0x7c8
[C00000002ABBF750] [C000000000095A94]
.generic_file_buffered_write+0x2c0/0x7c8 (
unreliable)
[C00000002ABBF8F0] [C0000000000962EC]
.__generic_file_aio_write_nolock+0x350/0x3
e0
[C00000002ABBFA20] [C000000000096908] .generic_file_aio_write+0x78/0x104
[C00000002ABBFAE0] [C0000000001649F0] .ext3_file_write+0x2c/0xd4
[C00000002ABBFB70] [C0000000000C5168] .do_sync_write+0xd4/0x130
[C00000002ABBFCF0] [C0000000000C5ED4] .vfs_write+0x128/0x20c
[C00000002ABBFD90] [C0000000000C664C] .sys_write+0x4c/0x8c
[C00000002ABBFE30] [C00000000000871C] syscall_exit+0x0/0x40
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] Oprofile-for-Cell prereqs: New routines for managing PMU interrupts
From: Kevin Corry @ 2006-11-15 15:56 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, oprofile-list, linux-kernel
Add routines for managing the Cell PMU interrupts.
The following routines are added to arch/powerpc/platforms/cell/pmu.c:
cbe_clear_pm_interrupts()
cbe_enable_pm_interrupts()
cbe_disable_pm_interrupts()
cbe_query_pm_interrupts()
cbe_pm_irq()
cbe_init_pm_irq()
This also adds a routine in arch/powerpc/platforms/cell/interrupt.c and
some macros in cbe_regs.h to manipulate the IIC_IR register:
iic_set_interrupt_routing()
Signed-off-by: Kevin Corry <kevcorry@us.ibm.com>
Signed-off-by: Carl Love <carll@us.ibm.com>
Index: linux-2.6.18-arnd6/arch/powerpc/platforms/cell/pmu.c
===================================================================
--- linux-2.6.18-arnd6.orig/arch/powerpc/platforms/cell/pmu.c
+++ linux-2.6.18-arnd6/arch/powerpc/platforms/cell/pmu.c
@@ -22,9 +22,11 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include <linux/interrupt.h>
#include <linux/types.h>
#include <asm/io.h>
#include <asm/machdep.h>
+#include <asm/pmc.h>
#include <asm/reg.h>
#include <asm/spu.h>
@@ -338,3 +340,71 @@ void cbe_read_trace_buffer(u32 cpu, u64
}
EXPORT_SYMBOL_GPL(cbe_read_trace_buffer);
+/*
+ * Enabling/disabling interrupts for the entire performance monitoring unit.
+ */
+
+u32 cbe_query_pm_interrupts(u32 cpu)
+{
+ return cbe_read_pm(cpu, pm_status);
+}
+EXPORT_SYMBOL_GPL(cbe_query_pm_interrupts);
+
+u32 cbe_clear_pm_interrupts(u32 cpu)
+{
+ /* Reading pm_status clears the interrupt bits. */
+ return cbe_query_pm_interrupts(cpu);
+}
+EXPORT_SYMBOL_GPL(cbe_clear_pm_interrupts);
+
+void cbe_enable_pm_interrupts(u32 cpu, u32 thread, u32 mask)
+{
+ /* Set which node and thread will handle the next interrupt. */
+ iic_set_interrupt_routing(cpu, thread, 0);
+
+ /* Enable the interrupt bits in the pm_status register. */
+ if (mask)
+ cbe_write_pm(cpu, pm_status, mask);
+}
+EXPORT_SYMBOL_GPL(cbe_enable_pm_interrupts);
+
+void cbe_disable_pm_interrupts(u32 cpu)
+{
+ cbe_clear_pm_interrupts(cpu);
+ cbe_write_pm(cpu, pm_status, 0);
+}
+EXPORT_SYMBOL_GPL(cbe_disable_pm_interrupts);
+
+static irqreturn_t cbe_pm_irq(int irq, void *dev_id, struct pt_regs *regs)
+{
+ perf_irq(regs);
+ return IRQ_HANDLED;
+}
+
+int __init cbe_init_pm_irq(void)
+{
+ unsigned int irq;
+ int rc, node;
+
+ for_each_node(node) {
+ irq = irq_create_mapping(NULL, IIC_IRQ_IOEX_PMI |
+ (node << IIC_IRQ_NODE_SHIFT));
+ if (irq == NO_IRQ) {
+ printk("ERROR: Unable to allocate irq for node %d\n",
+ node);
+ return -EINVAL;
+ }
+
+ rc = request_irq(irq, cbe_pm_irq,
+ IRQF_DISABLED, "cbe-pmu-0", NULL);
+ if (rc) {
+ printk("ERROR: Request for irq on node %d failed\n",
+ node);
+ return rc;
+ }
+ }
+
+ return 0;
+}
+arch_initcall(cbe_init_pm_irq);
+
Index: linux-2.6.18-arnd6/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linux-2.6.18-arnd6.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linux-2.6.18-arnd6/arch/powerpc/platforms/cell/interrupt.c
@@ -397,3 +397,19 @@ void __init iic_init_IRQ(void)
/* Enable on current CPU */
iic_setup_cpu();
}
+
+void iic_set_interrupt_routing(int cpu, int thread, int priority)
+{
+ struct cbe_iic_regs __iomem *iic_regs = cbe_get_cpu_iic_regs(cpu);
+ u64 iic_ir = 0;
+ int node = cpu >> 1;
+
+ /* Set which node and thread will handle the next interrupt */
+ iic_ir |= CBE_IIC_IR_PRIO(priority) |
+ CBE_IIC_IR_DEST_NODE(node);
+ if (thread == 0)
+ iic_ir |= CBE_IIC_IR_DEST_UNIT(CBE_IIC_IR_PT_0);
+ else
+ iic_ir |= CBE_IIC_IR_DEST_UNIT(CBE_IIC_IR_PT_1);
+ out_be64(&iic_regs->iic_ir, iic_ir);
+}
Index: linux-2.6.18-arnd6/arch/powerpc/platforms/cell/interrupt.h
===================================================================
--- linux-2.6.18-arnd6.orig/arch/powerpc/platforms/cell/interrupt.h
+++ linux-2.6.18-arnd6/arch/powerpc/platforms/cell/interrupt.h
@@ -83,5 +83,7 @@ extern u8 iic_get_target_id(int cpu);
extern void spider_init_IRQ(void);
+extern void iic_set_interrupt_routing(int cpu, int thread, int priority);
+
#endif
#endif /* ASM_CELL_PIC_H */
Index: linux-2.6.18-arnd6/include/asm-powerpc/cell-pmu.h
===================================================================
--- linux-2.6.18-arnd6.orig/include/asm-powerpc/cell-pmu.h
+++ linux-2.6.18-arnd6/include/asm-powerpc/cell-pmu.h
@@ -87,4 +87,9 @@ extern void cbe_disable_pm(u32 cpu);
extern void cbe_read_trace_buffer(u32 cpu, u64 *buf);
+extern void cbe_enable_pm_interrupts(u32 cpu, u32 thread, u32 mask);
+extern void cbe_disable_pm_interrupts(u32 cpu);
+extern u32 cbe_query_pm_interrupts(u32 cpu);
+extern u32 cbe_clear_pm_interrupts(u32 cpu);
+
#endif /* __ASM_CELL_PMU_H__ */
Index: linux-2.6.18-arnd6/arch/powerpc/platforms/cell/cbe_regs.h
===================================================================
--- linux-2.6.18-arnd6.orig/arch/powerpc/platforms/cell/cbe_regs.h
+++ linux-2.6.18-arnd6/arch/powerpc/platforms/cell/cbe_regs.h
@@ -185,6 +185,14 @@ struct cbe_iic_regs {
struct cbe_iic_thread_regs thread[2]; /* 0x0400 */
u64 iic_ir; /* 0x0440 */
+#define CBE_IIC_IR_PRIO(x) (((x) & 0xf) << 12)
+#define CBE_IIC_IR_DEST_NODE(x) (((x) & 0xf) << 4)
+#define CBE_IIC_IR_DEST_UNIT(x) ((x) & 0xf)
+#define CBE_IIC_IR_IOC_0 0x0
+#define CBE_IIC_IR_IOC_1S 0xb
+#define CBE_IIC_IR_PT_0 0xe
+#define CBE_IIC_IR_PT_1 0xf
+
u64 iic_is; /* 0x0448 */
#define CBE_IIC_IS_PMI 0x2
^ permalink raw reply
* Re: Boot failure with ext2 and initrds
From: Hugh Dickins @ 2006-11-15 15:56 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, Mel Gorman, linux-kernel
In-Reply-To: <455B330F.7050102@mbligh.org>
On Wed, 15 Nov 2006, Martin J. Bligh wrote:
> Hugh Dickins wrote:
> >
> > i386 and ppc64 still doing builds, but after an hour on x86_64,
> > an ld got stuck in a loop under ext2_try_to_allocate_with_rsv,
> > alternating between ext2_rsv_window_add and rsv_window_remove.
>
> Ugh. What test are you doing? kernel compile in a tight loop forever?
That kind of thing, yes: my usual test, two repeated make -j20s of
a smallish kernel in 512MB RAM + 1or2GB swap, one in a tmpfs and
one in an ext2 backed by a looped tmpfs file. (When things go
badly wrong, little harm befalls the hard disk.)
Hugh
^ permalink raw reply
* Re: [PATCH] ALSA: hda-intel - Disable MSI support by default
From: Linus Torvalds @ 2006-11-15 15:53 UTC (permalink / raw)
To: Roland Dreier; +Cc: Jeff Garzik, David Miller, linux-kernel, tiwai
In-Reply-To: <ada8xidz5zn.fsf@cisco.com>
On Tue, 14 Nov 2006, Roland Dreier wrote:
>
> Huh? The device can't generate any legacy interrupts once MSI is
> enabled. As the PCI spec says:
PLEASE.
The spec is just so much toilet paper. The ONLY thing that matters is what
real hardware does. So please please please PLEASE don't start quoting
specs as a way to "prove your point". It is totally meaningless.
The fact is, we _know_ there are broken devices out there. Not just wrt
MSI - pretty much every single sentence of the PCI spec is probably broken
by _some_ device or subsystem. For example, I would expect that the DMA
ordering rule is likely broken by the big SGI boxes, because they do
memory coherency traffic separately from the IO traffic.
This should be the #1 rule for every kernel programmer: read the
documentation, but don't actually assume it's complete, or that it is
always true.
One of the big reasons user-level programming is so much simpler than
kernel programming is that you can basically "think" about your
algorithms. You seldom have cases where you literally just need to test
out whether all hardware really works that way.
The bottom line: MSI looks great on paper. I think we might make it a rule
that we can enable it by default on bridges we trust (which would seem to
be mainly just Intel). But even then, I think it makes sense for
per-driver rules, because
- some drivers may care more than others (sound, for example, certainly
doesn't really care at all), apart from irq routing issues, and right
now those are _worse_ with MSI due to bugs.
- we definitely have the potential for per-driver bugs (eg the "disable
INTx explicitly" kind of situation), so even if MSI works on a system
level, I think we all know that it doesn't always work on a device
level, and the safe thing tends to be to keep it disabled unless you
have some really overriding concern to use it.
End result: I think that at least for 2.6.19, and at least for the HDA
sound driver, keeping it disabled by default is the right choice. We
should probably _also_ make "pci_msi_supported()" just return an error
(probably by just clearing "pci_msi_enable") for any non-intel host bridge
for now.
I don't dispute AT ALL that we should try to enable things more in the
future. I'm just saying that we're better off being careful, and realizing
that documentation and "official rules" seldom match reality.
(People seem to trust documentation, because for _most_ devices, the
documentation is correct. But if it's wrong for 1% of all devices, you
should still realize that IT IS WRONG. You can't quote "the standard" to
prove a point - a single exception is enough to show that a standard is
incomplete)
Linus
^ permalink raw reply
* Xen support for i386/core and i386/core2?
From: Markus Armbruster @ 2006-11-15 15:55 UTC (permalink / raw)
To: xen-devel
Xen's oprofile code is derived from Linux. Linux's version knows
core, Xen's doesn't.
Linux code (arch/i386/oprofile/nmi_int.c):
static int __init ppro_init(char ** cpu_type)
{
__u8 cpu_model = boot_cpu_data.x86_model;
if (cpu_model == 14)
*cpu_type = "i386/core";
else if (cpu_model == 15)
*cpu_type = "i386/core_2";
else if (cpu_model > 0xd)
return 0;
else if (cpu_model == 9) {
*cpu_type = "i386/p6_mobile";
} else if (cpu_model > 5) {
*cpu_type = "i386/piii";
} else if (cpu_model > 2) {
*cpu_type = "i386/pii";
} else {
*cpu_type = "i386/ppro";
}
model = &op_ppro_spec;
return 1;
}
Current Xen code:
static int __init ppro_init(char *cpu_type)
{
__u8 cpu_model = current_cpu_data.x86_model;
if (cpu_model > 0xd) {
printk("xenoprof: Initialization failed. "
"Intel processor model %d for P6 class family is not "
"supported\n", cpu_model);
return 0;
}
if (cpu_model == 9) {
strncpy (cpu_type, "i386/p6_mobile", XENOPROF_CPU_TYPE_SIZE - 1);
} else if (cpu_model > 5) {
strncpy (cpu_type, "i386/piii", XENOPROF_CPU_TYPE_SIZE - 1);
} else if (cpu_model > 2) {
strncpy (cpu_type, "i386/pii", XENOPROF_CPU_TYPE_SIZE - 1);
} else {
strncpy (cpu_type, "i386/ppro", XENOPROF_CPU_TYPE_SIZE - 1);
}
model = &op_ppro_spec;
return 1;
}
Andrew Theurer posted a patch back in October[*], which makes the Xen
code match the Linux code. What happened to it?
[*] http://lists.xensource.com/archives/html/xen-devel/2006-10/msg00032.html
^ permalink raw reply
* 2.6 Kernel not mounting JFFS2 partition.
From: Glen Johnson @ 2006-11-15 15:55 UTC (permalink / raw)
To: linux-mtd
Dear linux-mtd,
I have a target system which works fine using MTD and JFFS2 with
the uClinux 2.4.22 kernel. I am attempting to bring up the uClinux
2.6.17 kernel now and am having some problems with mounting the JFFS2
partition. I have tried both recommended procedures for mounting a
JFFS2 partition.
First attempt, I created a JFFS2 image on the target platform,
erased the partition, and then copied the image to the partition.
All seemed well until "mount -t jffs2 /dev/mtdblock2 /mnt" and I
received +3500 lines of error messages.
Second attempt, I created a JFFS2 image on a separate computer,
tftp-ed the image to the target, erased the JFFS2 partition and copied
in the jffs2 image to the partition. What resulted was the same +3500
lines of error messages.
By the way toward the bottom of the list of errors it says "You cannot
use older JFFS2 file systems with newer kernels", so I tried down
loading Red Hats cvs server and used the latest and greatest version
of mkfs.jffs2. Still gave me the same error messages as before.
Can anyone give any recommendations on what I am doing wrong? I know
I'm close to getting it working but I can't seem to find the right
flag to set or whatever it is. Any and all help is greatly appreciated.
Directly below is an abbreviated listing of the errors and just after
this I supplied a boot log to provide context to the target system.
ERROR MESSAGE:
- ----------------------
mount -t jffs2 /dev/mtdblock2 /mnt
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000:
0x9b9a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004:
0x2a04 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008:
0x1ca7 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c:
0x2a03 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010:
0x1c2a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014:
0x0022 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018:
0x0415 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c:
0x08a2 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020:
0x1d04 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024:
0x2b10 instead
Further such events for this erase block will not be printed
Empty flash at 0x00005014 ends at 0x00005018
Empty flash at 0x00009008 ends at 0x0000900c
Empty flash at 0x00009028 ends at 0x0000902c
- --------8<------------------------8<--------
In the interest of time and space I removed the other
3500 lines like the ones above and below this.
- --------8<------------------------8<--------
Empty flash at 0x001e6384 ends at 0x001e6388
Empty flash at 0x001e6590 ends at 0x001e6594
Empty flash at 0x001efd80 ends at 0x001efdf0
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0000:
0x246f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0004:
0x4a8a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0008:
0x202a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f000c:
0xb0aa instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0010:
0x6422 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0014:
0x0004 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0018:
0xd1ea instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f001c:
0x4280 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0020:
0x0008 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0024:
0x2541 instead
Further such events for this erase block will not be printed
Empty flash at 0x001f2820 ends at 0x001f2824
Empty flash at 0x001f2864 ends at 0x001f2868
Empty flash at 0x001f2878 ends at 0x001f287c
Empty flash at 0x001f2884 ends at 0x001f2888
Empty flash at 0x001f2a90 ends at 0x001f2a94
Empty flash at 0x001f3000 ends at 0x001f3010
Empty flash at 0x001f3024 ends at 0x001f3028
Empty flash at 0x001f3060 ends at 0x001f3064
Empty flash at 0x001f3f7c ends at 0x001f3fe0
Empty flash at 0x001f3fe4 ends at 0x001f4000
Empty flash at 0x001f8528 ends at 0x001f852c
Old JFFS2 bitmask found at 0x001f91ec
You cannot use older JFFS2 filesystems with newer kernels
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
empty_blocks 0, bad_blocks 0, c->nr_blocks 32
mount: Mounting /dev/mtdblock2 on /mnt failed: Input/output error
BOOT LOG:
---------------
U-Boot 1.1.2 (Jul 11 2005 - 11:28:55)
CPU: MOTOROLA MCF5272 (Mask:1)
Board: Valcom VIP8XX
DRAM: 16 MB
FLASH: 4 MB
In: serial
Out: serial
Err: serial
Enter password to stop autoboot: 2 1 0
TFTP from server 192.168.11.111; our IP address is 192.168.11.112
Filename 'vcisc-1.03.pkg'.
Load address: 0x200000
Loading:
*#################################################################
#################################################################
###################################################
done
Bytes transferred = 921780 (e10b4 hex)
Automatic boot of image at addr 0x00200000 ...
## Booting image at 00200000 ...
Image Name:
Image Type: M68K Linux Kernel Image (gzip compressed)
Data Size: 921716 Bytes = 900.1 kB
Load Address: 00020000
Entry Point: 00020000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
Linux version 2.6.17-uc1 (glen at ekul
<http://lists.infradead.org/mailman/listinfo/linux-mtd>) (gcc version
4.1.1) #7 Thu Nov 9
14:17:03 EST 2006
uClinux/COLDFIRE(m5272)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
<http://lists.infradead.org/mailman/listinfo/linux-mtd>
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists
Kernel command line: rootfstype=romfs
PID hash table entries: 64 (order: 6, 256 bytes)
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory available: 6036k/8192k RAM, (1011k kernel code, 148k data)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
io scheduler noop registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver version 1.00
ttyS0 at 0x10000100 (irq = 73) is a builtin ColdFire UART
ttyS1 at 0x10000140 (irq = 74) is a builtin ColdFire UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
FEC ENET Version 0.2
fec: PHY @ 0x0, ID 0x001378e2 -- LXT971
eth0: ethernet 00:00:00:00:00:00
SnapGear flash probe(0xffc00000,4194304,1): 400000 at ffc00000
Flash: Found 1 x16 devices at 0x0 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 3 MTD partitions on "Flash":
0x00000000-0x00080000 : "Das U-Boot"
0x00080000-0x00200000 : "Kernel"
0x00200000-0x00400000 : "JFFS2"
SnapGear ram probe(0x141fac,798720,4): c3000 at 141fac
Creating 1 MTD partitions on "RAM":
0x00000000-0x000c3000 : "Romfs"
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 48k freed (0x127000 - 0x132000)
init: Failed to open /etc/inittab.#
Thanks,
Glen Johnson
^ permalink raw reply
* Re: [PATCH 19/19] CacheFiles: Permit daemon to probe inuseness of a cache file
From: Christoph Hellwig @ 2006-11-15 15:52 UTC (permalink / raw)
To: David Howells
Cc: torvalds, akpm, sds, trond.myklebust, selinux, linux-kernel,
aviro, steved
In-Reply-To: <20061114200702.12943.39624.stgit@warthog.cambridge.redhat.com>
On Tue, Nov 14, 2006 at 08:07:02PM +0000, David Howells wrote:
> Permit the daemon to probe to see whether a cache file is in use by a netfs or
> not.
>
> Signed-Off-By: David Howells <dhowells@redhat.com>
> ---
>
> fs/cachefiles/cf-daemon.c | 73 +++++++++++++++++++
> fs/cachefiles/cf-namei.c | 170 +++++++++++++++++++++++++++++++++++++++++++++
> fs/cachefiles/internal.h | 3 +
> 3 files changed, 246 insertions(+), 0 deletions(-)
>
> diff --git a/fs/cachefiles/cf-daemon.c b/fs/cachefiles/cf-daemon.c
> index ae82685..ee07865 100644
> --- a/fs/cachefiles/cf-daemon.c
> +++ b/fs/cachefiles/cf-daemon.c
> @@ -38,6 +38,7 @@ static int cachefiles_daemon_cull(struct
> static int cachefiles_daemon_debug(struct cachefiles_cache *cache, char *args);
> static int cachefiles_daemon_dir(struct cachefiles_cache *cache, char *args);
> static int cachefiles_daemon_tag(struct cachefiles_cache *cache, char *args);
> +static int cachefiles_daemon_inuse(struct cachefiles_cache *cache, char *args);
>
> static unsigned long cachefiles_open;
>
> @@ -66,6 +67,7 @@ static const struct cachefiles_daemon_cm
> { "frun", cachefiles_daemon_frun },
> { "fcull", cachefiles_daemon_fcull },
> { "fstop", cachefiles_daemon_fstop },
> + { "inuse", cachefiles_daemon_inuse },
> { "tag", cachefiles_daemon_tag },
> { "", NULL }
> };
> @@ -602,3 +604,74 @@ inval:
> kerror("debug command requires mask");
> return -EINVAL;
> }
> +
> +/*
> + * find out whether an object is in use or not
> + * - command: "inuse <dirfd> <name>"
> + */
> +static int cachefiles_daemon_inuse(struct cachefiles_cache *cache, char *args)
> +{
> + struct dentry *dir;
> + struct file *dirfile;
> + uid_t fsuid;
> + gid_t fsgid;
> + u32 fscreatesid;
> + int dirfd, fput_needed, ret;
> +
> + _enter(",%s", args);
> +
> + dirfd = simple_strtoul(args, &args, 0);
> +
> + if (!isspace(*args))
> + goto inval;
> +
> + while (isspace(*args))
> + args++;
> +
> + if (!*args)
> + goto inval;
> +
> + if (strchr(args, '/'))
> + goto inval;
> +
> + if (!test_bit(CACHEFILES_READY, &cache->flags)) {
> + kerror("inuse applied to unready cache");
> + return -EIO;
> + }
> +
> + if (test_bit(CACHEFILES_DEAD, &cache->flags)) {
> + kerror("inuse applied to dead cache");
> + return -EIO;
> + }
> +
> + /* extract the directory dentry from the fd */
> + dirfile = fget_light(dirfd, &fput_needed);
Once again a very strong NACK for anything that gets a fd argument as
text from userspace. Also a very strong NACK for use of fget/fget_light
from non-core code and exports for either of them.
^ permalink raw reply
* [Buildroot] C++ cross compiler
From: MikeW @ 2006-11-15 15:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <24139.82.171.61.116.1163604033.squirrel@webmail.aerende.com>
<nina.holly@...> writes:
>
> Hi Mike,
> The build completes without an error, just no
> arm-linux-g++ compiler gets built. So I'm not sure
> if the patch would fix the problem.
>
> Nina
>
Must be something more fundamental wrong - you'll have to try (e.g.)
capturing the build output and then checking through it with an editor
to try to find why it skips c++/g++ creation.
Had a problem with libstdc++ which I fixed as described.
I have had success using buildroot-20061031, with
binutils-2-16.91.0.7 and gcc-3.4.3
I also moved the download directory away from the default, so that
I could do dirclean without losing all the tar.gz files.
MikeW
^ permalink raw reply
* RE: [Xenomai-help] pthread_setname_np
From: Daniel Schnell @ 2006-11-15 15:49 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
In-Reply-To: <455B29BE.3060805@domain.hid>
Gilles Chanteperdrix wrote:
> You are being dishonest: the function expects a pthread_t argument,
> the only way to get a valid pthread_t value is to create a thread or
> to call pthread_self().
No only a dumb newbie user of the Posix API with a background of
VxWorks.
If I want to create a task in VxWorks with e.g. int taskSpawn() I get
explecitly back a task id, comparable to a pthread_t for POSIX API.
Because it is a simple int (which is in fact not really true, because it
is a pointer in the task control block casted into an int), I know as a
dumb user that I cannot use it somehow before.
With pthreads I did the following:
pthread_t thread;
pthread_attr_t attr;
pthread_attr_init (&attr);
pthread_attr_setname_np(&attr, "newname"); (-->
pthread_set_name_np(thread, "newname");)
pthread_create (&thread, &attr, func, arg);
This did not compile, because only valid in kernel space, so I replaced
pthread_attr_setname_np() with pthread_set_name_np() and let it run. Of
course checking return values could have helped here.
I expected that pthread_t is a normal structure and would only be
modified with pthread_set_name_np() aka the attribute structure with
pthread_attr_setxxx(). I am simply not used to an API that doesn't
provide the possibility to spawn a thread already with the correct name
and rather forces the user to change the name after the thread is
already running ...
A collegue of mine stumbled over the exact same thing. A bit more
"redundancy" in the documentation would probably have opened our eyes,
although it seems according to Google that I am the first mentioning
this problem.
>> Btw. Is there a reason why the call to pthread_attr_setname_np() is
>> limited to kernel space ?
>
> It is impossible to implement pthread_attr_setname_np in user-space.
> I think I will remove this call, having different APIs in
> kernel-space and user-space only adds confusion.
Just out of curiosity: what are the exact reasons ? I mean: couldn't you
principially pass any information to the Xenomai subsystem at the time
of a pthread_create() ??
Best regards,
Daniel Schnell.
^ permalink raw reply
* Re: [PATCH 2/16] add hypervisor support for SPU
From: Arnd Bergmann @ 2006-11-15 15:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200611150928.kAF9SkJN021123@toshiba.co.jp>
On Wednesday 15 November 2006 10:28, Ishizaki Kou wrote:
> +static int __init find_spu_unit_number(struct device_node *spe)
> +{
> +=A0=A0=A0=A0=A0=A0=A0const unsigned int *reg;
> +=A0=A0=A0=A0=A0=A0=A0reg =3D get_property(spe, "reg", NULL);
> +=A0=A0=A0=A0=A0=A0=A0return reg ? *reg : 0;
> +}
> +
The unit number shold not be in the 'reg' property any more. With
the device tree layout we want to migrate to for better OFW compatibility,
'reg' should contain the addresses of local store, problem state and priv2
mappings, in that order.
Having the function is fine, but your interface needs to be a different
property.
> @@ -805,7 +816,11 @@
> =A0=A0=A0=A0=A0=A0=A0=A0if (ret)
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto out_unmap;
> =A0=A0=A0=A0=A0=A0=A0=A0spin_lock_init(&spu->register_lock);
> -=A0=A0=A0=A0=A0=A0=A0spu_mfc_sdr_set(spu, mfspr(SPRN_SDR1));
> +#ifdef CONFIG_SPU_NEED_SHADOW_INT_MASK
> +=A0=A0=A0=A0=A0=A0=A0spin_lock_init(&spu->int_mask_lock);
> +#endif
> +=A0=A0=A0=A0=A0=A0=A0if (!(firmware_has_feature(FW_FEATURE_LPAR)))
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0spu_mfc_sdr_set(spu, mfspr(=
SPRN_SDR1));
> =A0=A0=A0=A0=A0=A0=A0=A0spu_mfc_sr1_set(spu, 0x33);
> ...
> =A0=A0=A0=A0=A0=A0=A0=A0u32 node;
> +=A0=A0=A0=A0=A0=A0=A0u32 unit_number;
> =A0=A0=A0=A0=A0=A0=A0=A0u64 flags;
> =A0=A0=A0=A0=A0=A0=A0=A0u64 dar;
> =A0=A0=A0=A0=A0=A0=A0=A0u64 dsisr;
> +#ifdef=A0CONFIG_SPU_NEED_SHADOW_INT_MASK
> +=A0=A0=A0=A0=A0=A0=A0spinlock_t int_mask_lock;
> +=A0=A0=A0=A0=A0=A0=A0u64 shadow_int_mask_RW[3];
> +#endif
> =A0=A0=A0=A0=A0=A0=A0=A0size_t ls_size;
> =A0=A0=A0=A0=A0=A0=A0=A0unsigned int slb_replace;
> =A0=A0=A0=A0=A0=A0=A0=A0struct mm_struct *mm;
Not sure what others think about this, but I'd prefer not to have the
#ifdef here at all. This part is not a fast path, so we can spend the
few extra bytes and cycles on keeping it in the kernel always.
The place where it is used should still have a run-time check for whether
it's running on BEAT.
Arnd <><
^ permalink raw reply
* Re: [LARTC] bypassing qdisc for some traffic
From: Daniel Musketa @ 2006-11-15 15:43 UTC (permalink / raw)
To: lartc
In-Reply-To: <BAY103-DAV7E1AA9503C1DE9109CEB3B2EA0@phx.gbl>
> Problem: I don't want to limit traffic from eth1 to
> eth2. Is there a clean way to bypass the qdisc for
> certain kind of traffic (all traffic from eth1)?
You can create a 100mbit root class 1: rate 100mbit default 11, containing two
subclasses: 1:10 rate 2mbit and 1:11 rate 98mbit ceil 100mbit. Use iptables
to mark all traffic coming from eth0 to go to 1:10 ...
Daniel
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [PATCH] avoid compiler warnings
From: Mikael Pettersson @ 2006-11-15 15:42 UTC (permalink / raw)
To: Jan Beulich; +Cc: linux-acpi, linux-kernel
In-Reply-To: <455B36D2.76E4.0078.0@novell.com>
Jan Beulich writes:
> Pointers should not be casted to u32 as this results in compiler warnings
> on 64-bit platforms.
>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>
> --- linux-2.6.19-rc5/drivers/acpi/executer/exmutex.c 2006-09-20 05:42:06.000000000 +0200
> +++ 2.6.19-rc5-acpi-warnings/drivers/acpi/executer/exmutex.c 2006-11-06 09:10:16.000000000 +0100
> @@ -266,10 +266,10 @@ acpi_ex_release_mutex(union acpi_operand
> walk_state->thread->thread_id)
> && (obj_desc->mutex.os_mutex != ACPI_GLOBAL_LOCK)) {
> ACPI_ERROR((AE_INFO,
> - "Thread %X cannot release Mutex [%4.4s] acquired by thread %X",
> - (u32) walk_state->thread->thread_id,
> + "Thread %lX cannot release Mutex [%4.4s] acquired by thread %lX",
> + (unsigned long) walk_state->thread->thread_id,
> acpi_ut_get_node_name(obj_desc->mutex.node),
> - (u32) obj_desc->mutex.owner_thread->thread_id));
> + (unsigned long) obj_desc->mutex.owner_thread->thread_id));
> return_ACPI_STATUS(AE_AML_NOT_OWNER);
> }
>
> --- linux-2.6.19-rc5/drivers/acpi/utilities/utmutex.c 2006-09-20 05:42:06.000000000 +0200
> +++ 2.6.19-rc5-acpi-warnings/drivers/acpi/utilities/utmutex.c 2006-11-06 09:10:16.000000000 +0100
> @@ -258,8 +258,8 @@ acpi_status acpi_ut_acquire_mutex(acpi_m
> acpi_gbl_mutex_info[mutex_id].thread_id = this_thread_id;
> } else {
> ACPI_EXCEPTION((AE_INFO, status,
> - "Thread %X could not acquire Mutex [%X]",
> - (u32) this_thread_id, mutex_id));
> + "Thread %lX could not acquire Mutex [%X]",
> + (unsigned long) this_thread_id, mutex_id));
> }
>
> return (status);
NAK. Use "%p" for formatting pointers. No casts needed.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 15:41 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611150917.23756.andyparkins@gmail.com>
On Wed, 15 Nov 2006, Andy Parkins wrote:
> On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
>
> > OK..... let's pretend this is my follow-up to your "If I were redoing
>
> Personally, I agree with almost everything in this email. Except the
> implementation of point 3.
>
> > 3) remote branch handling should become more straight forward.
>
> I was completely confused by this origin/master/clone stuff when I started
> with git. In hindsight, now I understand git a bit more, this is what I
> would have liked:
>
> * Don't use the name "origin" twice. In fact, don't use it at all. In a
> distributed system there is no such thing as a true origin.
I agree, sort of. Not because"origin" is ambigous as a name. But
rather because there is a magic translation from "master" to "origin",
and I think this is wrong to do that.
As mentioned elsewhere (and let's start using "get" instead of "pull" as
suggested by Johannes), a "get" should probably always create a branch
group even if it contains only one branch. This way the remote branch
called "master" will still be called "master" locally, under the branch
group used to represent the remote repository. And if a local name is
not provided then let's just call it "default". This way, amongst the
remote references, there would be a "default/master" that would be used
when nothing else is provided by the user. So...
git get repo.com/time_machine.git
would create a local branch named "remotes/default/master" if the remote
repo has only a master branch.
Then, a simple:
git merge
could be the same as
git merge default
which would be equivalent to
git merge default/master
Afterwards, because the "default" remote already exists, then:
git get
would be the same as
git get default
to get changes for all branches in the "default" remote branches, of
which "master" might be the only one in the simple case.
But again I think it is important that the URL to use must be a per
branch attribute i.e. attached to "default/master" and not just
"default". This way someone could add all branches of interest into the
"default" group even if they're from different repositories, and a
simple get without any argument would get them all.
^ permalink raw reply
* Re: interesting way to break ext3 using loop devices
From: Theodore Tso @ 2006-11-15 15:40 UTC (permalink / raw)
To: Andi Kleen; +Cc: ext2-devel, linux-fsdevel
In-Reply-To: <200611151536.21066.ak@suse.de>
On Wed, Nov 15, 2006 at 03:36:20PM +0100, Andi Kleen wrote:
> Of course this was clearly an operator error and
> copying a file system into itself is clearly a sick thing
> to do, but still it shouldn't cause symptoms like this. Perhaps
> it points to a deeper issue.
Agreed; I'm guessing it's a bug in the loop device at first glance.
- Ted
^ permalink raw reply
* Can not run iptables
From: Vladimir Iskoz @ 2006-11-15 15:39 UTC (permalink / raw)
To: Netfilter (E-mail)
Hi all,
I'm really new to uClinux and Netfilter and trying to run it.
My target is ARM
Kernel: linux-2.6.14
GNU 3.4.5
Cross compiler - Buildroot.
Buildroot produces the file system that is loaded to flash while kernel image is loaded to RAM using TFTP.
I'm trying to add the Netfilter to the kernel using menuconfig.
It seems to be OK and I received zImage for loading on target.
After loading the image I'm trying to run some iptables command but receive that
iptables: applets not found (or file not found)
It seems that I'm running it from wrong place, I don't know.
I see that Ip tables package is configured (may be partially) according to some prints during initialization.
What can I check (do) to clear the situation?
Thank you very much for your help and time
Vladi
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************
^ permalink raw reply
* Re: openSUSE lists migrated
From: Mads Martin Joergensen @ 2006-11-15 15:35 UTC (permalink / raw)
To: mlmmj
In-Reply-To: <20061115132552.GC26298@suse.de>
* Henne Vogelsang <hvogel@opensuse.org> [Nov 15. 2006 14:26]:
> ~14000 unique subscribers resulting in ~110k msg/month[2]
>
> Everything mlm related did go very smooth. Thanks for this great piece
> of software :)
You're most welcome, glad you like it!
> Henne
>
> [1] hacked together by Mr. Jørgensen and others 8)
> [2] if i can trust mmj's mrtg setup ;)
That wasn't mine actually, that was Dr. Mahmoods. You might need to
change it to Postfix?
Chris?
--
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?"
-- A. P. J.
^ permalink raw reply
* git tag: don't complain of empty messages
From: Han-Wen Nienhuys @ 2006-11-15 15:34 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
Hello,
GIT refuses to set annotated tags without a comment. I think this is a
silly restriction when the message is explicitly set to the empty string.
The attached patch should fix this; Unfortunately, I've been unable to
test it. Running the script with sh -x stops at
++exec /home/hanwen/usr/pkg/git/bin/git-sh-setup
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
[-- Attachment #2: tagpatch --]
[-- Type: text/plain, Size: 1165 bytes --]
commit 446cfbd9edcfaf5fe76f597823e0e3314d091489
Author: Han-Wen Nienhuys <hanwen@lilypond.org>
Date: Wed Nov 15 16:27:27 2006 +0100
always set tag if -m is given, even if empty
diff --git a/git-tag.sh b/git-tag.sh
index ac269e3..f2533a3 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -5,6 +5,7 @@ USAGE='-l [<pattern>] | [-a | -s | -u <k
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+message_given=
annotate=
signed=
force=
@@ -37,6 +38,7 @@ do
annotate=1
shift
message="$1"
+ message_given=1
;;
-u)
annotate=1
@@ -83,7 +85,7 @@ tagger=$(git-var GIT_COMMITTER_IDENT) ||
trap 'rm -f "$GIT_DIR"/TAG_TMP* "$GIT_DIR"/TAG_FINALMSG "$GIT_DIR"/TAG_EDITMSG' 0
if [ "$annotate" ]; then
- if [ -z "$message" ]; then
+ if [ -z "$message_given" ]; then
( echo "#"
echo "# Write a tag message"
echo "#" ) > "$GIT_DIR"/TAG_EDITMSG
@@ -95,7 +97,7 @@ if [ "$annotate" ]; then
grep -v '^#' <"$GIT_DIR"/TAG_EDITMSG |
git-stripspace >"$GIT_DIR"/TAG_FINALMSG
- [ -s "$GIT_DIR"/TAG_FINALMSG ] || {
+ [ -s "$GIT_DIR"/TAG_FINALMSG -o -n "$message_given" ] || {
echo >&2 "No tag message?"
exit 1
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.