* Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Jon Smirl @ 2006-05-05 20:35 UTC (permalink / raw)
To: Greg KH; +Cc: Ian Romanick, Dave Airlie, Arjan van de Ven, linux-kernel
In-Reply-To: <20060505202603.GB6413@kroah.com>
On 5/5/06, Greg KH <greg@kroah.com> wrote:
> On Fri, May 05, 2006 at 04:14:00PM -0400, Jon Smirl wrote:
> > I would like to see other design alternatives considered on this
> > issue. The 'enable' attribute has a clear problem in that you can't
> > tell which user space program is trying to control the device.
> > Multiple programs accessing the video hardware with poor coordination
> > is already the source of many problems.
>
> Who cares who "enabled" the device. Remember, the majority of PCI
> devices in the system are not video ones. Lots of other types of
> devices want this ability to enable PCI devices from userspace. I've
> been talking with some people about how to properly write PCI drivers in
> userspace, and this attribute is a needed part of it.
User space program enables the device.
Next I load a device driver
next I rmmod the device driver and it disables the device
user space program trys to use the device
No coordination and user space program faults
Don't say this can't happen, it is a current source of conflict
between X and fbdev.
Should we just remove the ability to disable hardware?
How would that interact with hotplug?
> And if X gets enabling the device wrong, again, who cares, it's not a
> kernel issue. :)
>
> thanks,
>
> greg k-h
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [RFC][PATCH] tracking dirty pages in shared mappings
From: Peter Zijlstra @ 2006-05-05 20:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, Rohit Seth, Andrew Morton, clameter, mbligh, hugh,
riel, andrea, piggin, arjan, apw, mel, marcelo, anton, paulmck,
linux-mm
People expressed the need to track dirty pages in shared mappings.
Linus outlined the general idea of doing that through making clean
writable pages write-protected and taking the write fault.
This patch does exactly that, it makes pages in a shared writable
mapping write-protected. On write-fault the pages are marked dirty and
made writable. When the pages get synced with their backing store, the
write-protection is re-instated.
It survives a simple test and shows the dirty pages in /proc/vmstat.
Comments?
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
include/linux/mm.h | 5 +++-
include/linux/rmap.h | 6 +++++
mm/filemap.c | 3 +-
mm/fremap.c | 9 +++++--
mm/memory.c | 16 +++++++++++++
mm/page-writeback.c | 2 +
mm/rmap.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++
mm/shmem.c | 2 -
8 files changed, 98 insertions(+), 6 deletions(-)
Index: linux-2.6/include/linux/mm.h
===================================================================
--- linux-2.6.orig/include/linux/mm.h 2006-05-04 21:34:06.000000000 +0200
+++ linux-2.6/include/linux/mm.h 2006-05-05 19:07:58.000000000 +0200
@@ -183,6 +183,9 @@ extern unsigned int kobjsize(const void
#define VM_SequentialReadHint(v) ((v)->vm_flags & VM_SEQ_READ)
#define VM_RandomReadHint(v) ((v)->vm_flags & VM_RAND_READ)
+#define VM_SharedWritable(v) (((v)->vm_flags & (VM_SHARED | VM_MAYSHARE)) && \
+ ((v)->vm_flags & VM_WRITE))
+
/*
* mapping from the currently active vm_flags protection bits (the
* low four bits) to a page protection mask..
@@ -721,7 +724,7 @@ static inline void unmap_shared_mapping_
extern int vmtruncate(struct inode * inode, loff_t offset);
extern int vmtruncate_range(struct inode * inode, loff_t offset, loff_t end);
-extern int install_page(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, struct page *page, pgprot_t prot);
+extern int install_page(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, struct page *page, pgprot_t prot, int wrprotect);
extern int install_file_pte(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, unsigned long pgoff, pgprot_t prot);
#ifdef CONFIG_MMU
Index: linux-2.6/mm/filemap.c
===================================================================
--- linux-2.6.orig/mm/filemap.c 2006-05-04 21:34:06.000000000 +0200
+++ linux-2.6/mm/filemap.c 2006-05-05 19:10:37.000000000 +0200
@@ -1627,7 +1627,8 @@ repeat:
return -ENOMEM;
if (page) {
- err = install_page(mm, vma, addr, page, prot);
+ err = install_page(mm, vma, addr, page, prot,
+ VM_SharedWritable(vma));
if (err) {
page_cache_release(page);
return err;
Index: linux-2.6/mm/fremap.c
===================================================================
--- linux-2.6.orig/mm/fremap.c 2006-05-04 21:34:06.000000000 +0200
+++ linux-2.6/mm/fremap.c 2006-05-04 22:33:49.000000000 +0200
@@ -49,7 +49,8 @@ static int zap_pte(struct mm_struct *mm,
* previously existing mapping.
*/
int install_page(struct mm_struct *mm, struct vm_area_struct *vma,
- unsigned long addr, struct page *page, pgprot_t prot)
+ unsigned long addr, struct page *page, pgprot_t prot,
+ int wrprotect)
{
struct inode *inode;
pgoff_t size;
@@ -79,9 +80,11 @@ int install_page(struct mm_struct *mm, s
inc_mm_counter(mm, file_rss);
flush_icache_page(vma, page);
- set_pte_at(mm, addr, pte, mk_pte(page, prot));
+ pte_val = mk_pte(page, prot);
+ if (wrprotect)
+ pte_val = pte_wrprotect(pte_val);
+ set_pte_at(mm, addr, pte, pte_val);
page_add_file_rmap(page);
- pte_val = *pte;
update_mmu_cache(vma, addr, pte_val);
err = 0;
unlock:
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c 2006-05-04 21:34:06.000000000 +0200
+++ linux-2.6/mm/memory.c 2006-05-05 19:37:14.000000000 +0200
@@ -1495,6 +1495,18 @@ static int do_wp_page(struct mm_struct *
}
}
+ if (VM_SharedWritable(vma)) {
+ flush_cache_page(vma, address, pte_pfn(orig_pte));
+ entry = pte_mkyoung(orig_pte);
+ entry = pte_mkwrite(pte_mkdirty(entry));
+ ptep_set_access_flags(vma, address, page_table, entry, 1);
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+ ret |= VM_FAULT_WRITE;
+ set_page_dirty(old_page);
+ goto unlock;
+ }
+
/*
* Ok, we need to copy. Oh, well..
*/
@@ -2150,6 +2162,8 @@ retry:
entry = mk_pte(new_page, vma->vm_page_prot);
if (write_access)
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
+ else if (VM_SharedWritable(vma))
+ entry = pte_wrprotect(entry);
set_pte_at(mm, address, page_table, entry);
if (anon) {
inc_mm_counter(mm, anon_rss);
@@ -2159,6 +2173,8 @@ retry:
} else {
inc_mm_counter(mm, file_rss);
page_add_file_rmap(new_page);
+ if (write_access)
+ set_page_dirty(new_page);
}
} else {
/* One of our sibling threads was faster, back out. */
Index: linux-2.6/mm/shmem.c
===================================================================
--- linux-2.6.orig/mm/shmem.c 2006-05-04 21:34:06.000000000 +0200
+++ linux-2.6/mm/shmem.c 2006-05-04 22:12:54.000000000 +0200
@@ -1270,7 +1270,7 @@ static int shmem_populate(struct vm_area
/* Page may still be null, but only if nonblock was set. */
if (page) {
mark_page_accessed(page);
- err = install_page(mm, vma, addr, page, prot);
+ err = install_page(mm, vma, addr, page, prot, 0);
if (err) {
page_cache_release(page);
return err;
Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c 2006-05-04 16:30:46.000000000 +0200
+++ linux-2.6/mm/page-writeback.c 2006-05-05 13:40:08.000000000 +0200
@@ -725,6 +725,7 @@ int test_clear_page_dirty(struct page *p
page_index(page),
PAGECACHE_TAG_DIRTY);
write_unlock_irqrestore(&mapping->tree_lock, flags);
+ page_wrprotect(page);
if (mapping_cap_account_dirty(mapping))
dec_page_state(nr_dirty);
return 1;
@@ -756,6 +757,7 @@ int clear_page_dirty_for_io(struct page
if (mapping) {
if (TestClearPageDirty(page)) {
+ page_wrprotect(page);
if (mapping_cap_account_dirty(mapping))
dec_page_state(nr_dirty);
return 1;
Index: linux-2.6/mm/rmap.c
===================================================================
--- linux-2.6.orig/mm/rmap.c 2006-05-04 19:27:42.000000000 +0200
+++ linux-2.6/mm/rmap.c 2006-05-05 22:00:34.000000000 +0200
@@ -478,6 +478,67 @@ int page_referenced(struct page *page, i
return referenced;
}
+static int page_wrprotect_one(struct page *page, struct vm_area_struct *vma)
+{
+ struct mm_struct *mm = vma->vm_mm;
+ unsigned long address;
+ pte_t *pte, entry;
+ spinlock_t *ptl;
+
+ address = vma_address(page, vma);
+ if (address == -EFAULT)
+ goto out;
+
+ pte = page_check_address(page, mm, address, &ptl);
+ if (!pte)
+ goto out;
+
+ if (!pte_write(*pte))
+ goto unlock;
+
+ entry = pte_wrprotect(*pte);
+ ptep_establish(vma, address, pte, entry);
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+
+unlock:
+ pte_unmap_unlock(pte, ptl);
+out:
+ return 0;
+}
+
+static int page_wrprotect_file(struct page *page)
+{
+ struct address_space *mapping = page->mapping;
+ pgoff_t pgoff = page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT);
+ struct vm_area_struct *vma;
+ struct prio_tree_iter iter;
+
+ BUG_ON(PageAnon(page));
+
+ spin_lock(&mapping->i_mmap_lock);
+
+ vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
+ if (VM_SharedWritable(vma))
+ page_wrprotect_one(page, vma);
+ }
+
+ spin_unlock(&mapping->i_mmap_lock);
+ return 0;
+}
+
+int page_wrprotect(struct page *page)
+{
+ BUG_ON(!PageLocked(page));
+
+ if (page_mapped(page) && page->mapping) {
+ if (!PageAnon(page))
+ page_wrprotect_file(page);
+ }
+
+ return 0;
+}
+
/**
* page_set_anon_rmap - setup new anonymous rmap
* @page: the page to add the mapping to
Index: linux-2.6/include/linux/rmap.h
===================================================================
--- linux-2.6.orig/include/linux/rmap.h 2006-05-05 14:02:45.000000000 +0200
+++ linux-2.6/include/linux/rmap.h 2006-05-05 14:03:04.000000000 +0200
@@ -105,6 +105,12 @@ pte_t *page_check_address(struct page *,
*/
unsigned long page_address_in_vma(struct page *, struct vm_area_struct *);
+/*
+ * Used to writeprotect clean pages, in order to count nr_dirty for shared
+ * mappings
+ */
+int page_wrprotect(struct page *);
+
#else /* !CONFIG_MMU */
#define anon_vma_init() do {} while (0)
--
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
* Re: [PATCH] binary patch.
From: Daniel Barkalow @ 2006-05-05 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vac9wxom0.fsf@assigned-by-dhcp.cox.net>
On Fri, 5 May 2006, Junio C Hamano wrote:
> But "binaryness" affects only certain operations that extract
> the data (e.g. diff and grep) and not others (e.g. fetch).
> Also, it makes sense to being able to retroactively mark a blob,
> which was not marked as such originally, is a binary. So I do
> not think it should be recorded in the object header.
Why do you think it makes sense to retroactively mark a blob with things
like binariness or MIME type? To the extent that the information is not
possible to extract from the blob contents, it seems to me to be a
permanent aspect of the blob. And I could see having blobs with the same
content but different type information (that one is a ZIP archive, while
this one is a OpenDocument file), and tools may care how they were
specified, and the user would want to be able to track how they had
historically been marked, if the system allows them to be marked at all.
Of course, there's still the issue of how this info is generated for a new
blob; I think it should live in the index for tracked files and come from
a .gitignore-style file for new files. (For that matter, there could be a
.gitmetadata file, which would handle "ignore" as well as binary and
whatever other info you want to produce about your not-previously-tracked
files.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] device core: remove redundant call to device_initialize.
From: Paolo 'Blaisorblade' Giarrusso @ 2006-05-05 15:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: Greg Kroah-Hartman, linux-kernel
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
platform_device_add calls device_register which calls then again
device_initialize, redundantly.
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
drivers/base/platform.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 83f5c59..b0d9bd4 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -317,7 +317,6 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device * pdev)
{
- device_initialize(&pdev->dev);
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
^ permalink raw reply related
* [PATCH] blk_start_queue must be called with irq disabled - add warning
From: Paolo 'Blaisorblade' Giarrusso @ 2006-05-05 15:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jens Axboe, linux-kernel
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
The queue lock can be taken from interrupts so it must always be taken with irq
disabling primitives. Some primitives already verify this.
blk_start_queue() is called under this lock, so interrupts must be disabled.
Also document this requirement clearly in blk_init_queue(), where the queue
spinlock is set.
Cc: Jens Axboe <axboe@suse.de>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
block/ll_rw_blk.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index e5041a0..11872d1 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -1663,6 +1663,8 @@ static void blk_unplug_timeout(unsigned
**/
void blk_start_queue(request_queue_t *q)
{
+ WARN_ON(!irqs_disabled());
+
clear_bit(QUEUE_FLAG_STOPPED, &q->queue_flags);
/*
@@ -1865,7 +1867,8 @@ EXPORT_SYMBOL(blk_alloc_queue_node);
* get dealt with eventually.
*
* The queue spin lock must be held while manipulating the requests on the
- * request queue.
+ * request queue; this lock will be taken also from interrupt context, so irq
+ * disabling is needed for it.
*
* Function returns a pointer to the initialized request queue, or NULL if
* it didn't succeed.
^ permalink raw reply related
* Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers
From: Stephen Hemminger @ 2006-05-05 20:30 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20060505191127.GA16076@thunk.org>
On Fri, 5 May 2006 15:11:27 -0400
Theodore Tso <tytso@mit.edu> wrote:
> On Fri, May 05, 2006 at 12:24:26PM -0500, Matt Mackall wrote:
> > I haven't seen such an analysis, scholarly or otherwise and my bias
> > here is to lean towards the paranoid.
> >
> > Assuming a machine with no TSC and an otherwise quiescent ethernet
> > (hackers burning the midnight oil), I think most of the
> > hard-to-analyze bits above get pretty transparent.
>
> As always, whether or not the packet arrival times could be guessable
> and/or controlled by an attacker really depends on your threat model.
> For someone who has an ethernet monitor attached directly to the
> segment right next to your computer, it's very likely that they would
> be successful in guessing the inputs into the entropy pool. However,
> an attacker with physical access to your machine could probably do all
> sorts of other things, such as install a keyboard sniffer, etc.
>
> For a remote attacker, life gets much more difficult. Each switch,
> router, and bridge effectively has a queue into which packets must
> flow through, and that is _not_ known to a remote attacker. This is
> especially true today, when most people don't even use repeaters, but
> rather switches/bridges, which effectly make each ethernet connection
> to each host its own separate collision domain (indeed that term
> doesn't even apply for modern high-speed ethernets).
>
> I've always thought the right answer is that whether or not network
> packet arrival times should be used as entropy input should be
> configurable, since depending on the environment, it might or might
> not be safe, and for some hosts (particularly diskless servers), the
> network might be the only source of entropy available to them.
>
> - Ted
An added problem is that many of the high speed interfaces have
interrupt mitigation. The chip will hold off the interrupt for a short
time to try and aggregate multiple packets. This has the effect
of synchronizing the interrupt, and reduces the entropy, especially
under load. NAPI also eliminates much of the entropy in network drivers.
So the quality of the entropy also depends on the chipset. Most of
the older, dumber hardware probably has better entropy but worse performance.
^ permalink raw reply
* Re: Remove silly messages from input layer.
From: Nuri Jawad @ 2006-05-05 20:30 UTC (permalink / raw)
To: Martin Bligh
Cc: Dave Jones, Martin Mares, Pavel Machek, dtor_core, Linux Kernel
In-Reply-To: <445BB050.4040309@mbligh.org>
On Fri, 5 May 2006, Martin Bligh wrote:
> Sorry, but these comparisons to Windows are just childish.
No, in this case they're not. Clear text error messages, compared to
obscure numerical error codes or no reports at all, are a very useful
attribute of free operating systems that I do not want to miss because
somebody is trying to please clueless Joe User.
> Linux is not obliged to spit out meaningless, unhelpful error messages,
I already explained in a previous reply why this message IS undisputably
useful for me, and others have done the same. Why are we discussing if you
don't read what we write but have obviously already made up your mind?
> The current error message is wrong
No it's not, the keyboard is in fact reporting too many pressed keys.
> But throwing 'Windows' around is not useful
It is useful to show you what kind of environment many users do not want
to have. Hiding information is not user-friendly for the experienced user,
only for the novice.
Regards, Nuri
^ permalink raw reply
* [U-Boot-Users] [PATCH 3/11] Add Rockbox FAT filesystem driver with write support
From: Keith J Outwater @ 2006-05-05 20:29 UTC (permalink / raw)
To: u-boot
The attached patch adds a port of the FAT filesystem driver from the
Rockbox (www.rockbox.org) project. The port is still a little rough
around the edges (support for 'cd' needs work), but I have been using
basic read/write functions for some time without problems.
Thanks to Daniel Stenberg for suggesting the use of the rockbox code.
Signed-off-by: Keith Outwater <outwater4@comcast.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kjo-p3of11-add-rockbox-fat-driver.patch.bz2
Type: application/octet-stream
Size: 27697 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060505/e8f2186f/attachment.obj
^ permalink raw reply
* Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Greg KH @ 2006-05-05 20:26 UTC (permalink / raw)
To: Jon Smirl; +Cc: Ian Romanick, Dave Airlie, Arjan van de Ven, linux-kernel
In-Reply-To: <9e4733910605051314jb681476y4b2863918dfae1f8@mail.gmail.com>
On Fri, May 05, 2006 at 04:14:00PM -0400, Jon Smirl wrote:
> I would like to see other design alternatives considered on this
> issue. The 'enable' attribute has a clear problem in that you can't
> tell which user space program is trying to control the device.
> Multiple programs accessing the video hardware with poor coordination
> is already the source of many problems.
Who cares who "enabled" the device. Remember, the majority of PCI
devices in the system are not video ones. Lots of other types of
devices want this ability to enable PCI devices from userspace. I've
been talking with some people about how to properly write PCI drivers in
userspace, and this attribute is a needed part of it.
And if X gets enabling the device wrong, again, who cares, it's not a
kernel issue. :)
thanks,
greg k-h
^ permalink raw reply
* Re: Touchscreen on Innovator OMAP1510
From: David Brownell @ 2006-05-05 20:25 UTC (permalink / raw)
To: linux-omap-open-source; +Cc: Prakash Narayanan M
In-Reply-To: <9343BE359FA4224CA72A94D8CC362C9C0936A8@edpc500.cedt.iisc.ernet.in>
On Friday 05 May 2006 5:07 am, Prakash Narayanan M wrote:
> Innovator has ADS7846E as touchscreen controller. How to enable the
> driver for ads7846 instead of tsc2101?
Did you try this with the current kernel tree? There was a bogus
dependency in Kconfig which should resolve that even if you're using
the "old" touchscreen driver.
You could switch do the "new" drivers/input/touchscreen/ads7846.c driver
with a simple bitbang SPI module. If you're interested, I'll post you one
off-list that you'd need to modify for Innovator.
- Dave
^ permalink raw reply
* Re: Calculating virtual address from physical address
From: Matt Porter @ 2006-05-05 20:24 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Chris Dumoulin, linuxppc-embedded
In-Reply-To: <445BA736.30208@246tNt.com>
On Fri, May 05, 2006 at 09:27:50PM +0200, Sylvain Munaut wrote:
> Chris Dumoulin wrote:
> > I'm using a Virtex II Pro-based board with a PPC405. The board is
> > hanging somewhere very early in the kernel boot process. I believe it
> > may be dying at the point where the MMU is enabled. In order to
> > determine the exact point at which my board hangs, I'm blinking two LEDs
> > in the assembly code found in arch/ppc/kernel/head_4xx.S, . Currently I
> > am only able to successfully access the LEDs before the MMU is turned
> > on, but I can't be sure that I'm calculating the virtual address
> > properly when I try to access the LED after the MMU is turned on.
>
> Typical when trying to bring up board ...
>
> Once the MMU is turned on, you leds register are most likely ... nowhere
> ... i.e.
> if you don't create a mapping your self there is just no virtual address
> that will
> access your leds physical address.
>
> What I did on some ppc work was tu use a quick BAT mapping to map some leds.
> It's pretty easy to setup. Be aware though that this mapping will get
> wiped out when
> the kernel sets up the BAT for itself.
There are no BATs on 4xx. However, the same conceptual thing can be
done by wiring a fixed TLB entry to cover those LEDs temporarily
during bringup debug. The temporary TLB entry will be wiped out by
normal tlb misses after things are running whenever the fixed entry
is clobbered by the round robin replacement.
-Matt
^ permalink raw reply
* Re: Compact Flash Issue on OSK 5912
From: David Brownell @ 2006-05-05 20:22 UTC (permalink / raw)
To: linux-omap-open-source
In-Reply-To: <31bab3780605050815v5906b07ap994bcb3204a8b49d@mail.gmail.com>
On Friday 05 May 2006 8:15 am, Bharat Kumar Reddy wrote:
>
> Has anyone faced these problems before and are there any patch fixes for this ?
Post any stack backtraces you get. I saw similar rudeness on 2.6.17-current
but ISTR that 2.6.14-omap didn't have problems there. It's not clear what
the problems are; my symptoms pointed more at IDE layer confusions with respect
to IRQ handling.
^ permalink raw reply
* [PATCH] ppc32 8xx: Fix r3 thrashing due to 8MB TLB page instantiation (!CONFIG_8xx_CPU6)
From: Marcelo Tosatti @ 2006-05-05 20:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: David Jander, linux-ppc-embedded
(please ignore last patch, its incomplete)
Instantiation of 8MB pages on the TLB cache for the kernel static
mapping thrashes r3 register on !CONFIG_8xx_CPU6 configurations.
Signed-off-by: Marcelo Tosatti <marcelo@kvack.org>
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index ec53c7d..09b3adc 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -355,9 +355,7 @@ #endif
. = 0x1200
DataStoreTLBMiss:
-#ifdef CONFIG_8xx_CPU6
stw r3, 8(r0)
-#endif
DO_8xx_CPU6(0x3f80, r3)
mtspr SPRN_M_TW, r10 /* Save a couple of working registers */
mfcr r10
@@ -417,9 +415,7 @@ #endif
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is an instruction TLB error on the MPC8xx. This could be due
@@ -500,9 +496,7 @@ LoadLargeDTLB:
lwz r11, 4(r0)
lwz r12, 16(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is the data TLB error on the MPC8xx. This could be due to
^ permalink raw reply related
* [PATCH] IPC_SET_PERM cleanup
From: Linda Knippers @ 2006-05-05 20:19 UTC (permalink / raw)
To: Linux Audit Discussion
The following patch addresses most of the issues with the IPC_SET_PERM
records as described in:
https://www.redhat.com/archives/linux-audit/2006-May/msg00010.html
To summarize, I made the following changes:
1. Changed sys_msgctl() and semctl_down() so that an IPC_SET_PERM
record is emitted in the failure case as well as the success case.
This matches the behavior in sys_shmctl(). I could simplify the
code in sys_msgctl() and semctl_down() slightly but it would mean
that in some error cases we could get an IPC_SET_PERM record
without an IPC record and that seemed odd.
2. No change to the IPC record type, given no feedback on the backward
compatibility question.
3. Removed the qbytes field from the IPC record. It wasn't being
set and when audit_ipc_obj() is called from ipcperms(), the
information isn't available. If we want the information in the IPC
record, more extensive changes will be necessary. Since it only
applies to message queues and it isn't really permission related, it
doesn't seem worth it.
4. Removed the obj field from the IPC_SET_PERM record. This means that
the kern_ipc_perm argument is no longer needed.
5. Replaced the spaces in the IPC_SET_PERM field names with underscores.
I tested this with the lspp.22 kernel on an x86_64 box. Please let me
know if you see any issues.
-- ljk
include/linux/audit.h | 2 +-
ipc/msg.c | 9 +++++----
ipc/sem.c | 8 +++++---
ipc/shm.c | 2 +-
kernel/auditsc.c | 22 +++++-----------------
5 files changed, 17 insertions(+), 26 deletions(-)
--- linux-2.6.16.x86_64.orig/kernel/auditsc.c 2006-05-05 14:29:42.000000000 -0400
+++ linux-2.6.16.x86_64/kernel/auditsc.c 2006-05-05 14:48:44.000000000 -0400
@@ -665,8 +665,8 @@ static void audit_log_exit(struct audit_
case AUDIT_IPC: {
struct audit_aux_data_ipcctl *axi = (void *)aux;
audit_log_format(ab,
- " qbytes=%lx iuid=%u igid=%u mode=%x",
- axi->qbytes, axi->uid, axi->gid, axi->mode);
+ "iuid=%u igid=%u mode=%x",
+ axi->uid, axi->gid, axi->mode);
if (axi->osid != 0) {
char *ctx = NULL;
u32 len;
@@ -684,21 +684,10 @@ static void audit_log_exit(struct audit_
case AUDIT_IPC_SET_PERM: {
struct audit_aux_data_ipcctl *axi = (void *)aux;
audit_log_format(ab,
- " new qbytes=%lx new iuid=%u new igid=%u new mode=%x",
+ "new_qbytes=%lx new_iuid=%u new_igid=%u new_mode=%x",
axi->qbytes, axi->uid, axi->gid, axi->mode);
- if (axi->osid != 0) {
- char *ctx = NULL;
- u32 len;
- if (selinux_ctxid_to_string(
- axi->osid, &ctx, &len)) {
- audit_log_format(ab, " osid=%u",
- axi->osid);
- call_panic = 1;
- } else
- audit_log_format(ab, " obj=%s", ctx);
- kfree(ctx);
- }
break; }
+
case AUDIT_EXECVE: {
struct audit_aux_data_execve *axi = (void *)aux;
int i;
@@ -1232,7 +1221,7 @@ int audit_ipc_obj(struct kern_ipc_perm *
*
* Returns 0 for success or NULL context or < 0 on error.
*/
-int audit_ipc_set_perm(unsigned long qbytes, uid_t uid, gid_t gid, mode_t mode, struct kern_ipc_perm *ipcp)
+int audit_ipc_set_perm(unsigned long qbytes, uid_t uid, gid_t gid, mode_t mode)
{
struct audit_aux_data_ipcctl *ax;
struct audit_context *context = current->audit_context;
@@ -1248,7 +1237,6 @@ int audit_ipc_set_perm(unsigned long qby
ax->uid = uid;
ax->gid = gid;
ax->mode = mode;
- selinux_get_ipc_sid(ipcp, &ax->osid);
ax->d.type = AUDIT_IPC_SET_PERM;
ax->d.next = context->aux;
--- linux-2.6.16.x86_64.orig/ipc/msg.c 2006-05-05 14:30:15.000000000 -0400
+++ linux-2.6.16.x86_64/ipc/msg.c 2006-05-05 14:50:32.000000000 -0400
@@ -454,6 +454,11 @@ asmlinkage long sys_msgctl (int msqid, i
err = audit_ipc_obj(ipcp);
if (err)
goto out_unlock_up;
+ if (cmd==IPC_SET) {
+ err = audit_ipc_set_perm(setbuf.qbytes, setbuf.uid, setbuf.gid, setbuf.mode);
+ if (err)
+ goto out_unlock_up;
+ }
err = -EPERM;
if (current->euid != ipcp->cuid &&
@@ -468,10 +473,6 @@ asmlinkage long sys_msgctl (int msqid, i
switch (cmd) {
case IPC_SET:
{
- err = audit_ipc_set_perm(setbuf.qbytes, setbuf.uid, setbuf.gid, setbuf.mode, ipcp);
- if (err)
- goto out_unlock_up;
-
err = -EPERM;
if (setbuf.qbytes > msg_ctlmnb && !capable(CAP_SYS_RESOURCE))
goto out_unlock_up;
--- linux-2.6.16.x86_64.orig/ipc/shm.c 2006-05-05 15:08:23.000000000 -0400
+++ linux-2.6.16.x86_64/ipc/shm.c 2006-05-05 14:51:53.000000000 -0400
@@ -643,7 +643,7 @@ asmlinkage long sys_shmctl (int shmid, i
err = audit_ipc_obj(&(shp->shm_perm));
if (err)
goto out_unlock_up;
- err = audit_ipc_set_perm(0, setbuf.uid, setbuf.gid, setbuf.mode, &(shp->shm_perm));
+ err = audit_ipc_set_perm(0, setbuf.uid, setbuf.gid, setbuf.mode);
if (err)
goto out_unlock_up;
err=-EPERM;
--- linux-2.6.16.x86_64.orig/ipc/sem.c 2006-05-05 14:30:02.000000000 -0400
+++ linux-2.6.16.x86_64/ipc/sem.c 2006-05-05 14:50:58.000000000 -0400
@@ -828,6 +828,11 @@ static int semctl_down(int semid, int se
if (err)
goto out_unlock;
+ if (cmd == IPC_SET) {
+ err = audit_ipc_set_perm(0, setbuf.uid, setbuf.gid, setbuf.mode);
+ if (err)
+ goto out_unlock;
+ }
if (current->euid != ipcp->cuid &&
current->euid != ipcp->uid && !capable(CAP_SYS_ADMIN)) {
err=-EPERM;
@@ -844,9 +849,6 @@ static int semctl_down(int semid, int se
err = 0;
break;
case IPC_SET:
- err = audit_ipc_set_perm(0, setbuf.uid, setbuf.gid, setbuf.mode, ipcp);
- if (err)
- goto out_unlock;
ipcp->uid = setbuf.uid;
ipcp->gid = setbuf.gid;
ipcp->mode = (ipcp->mode & ~S_IRWXUGO)
--- linux-2.6.16.x86_64.orig/include/linux/audit.h 2006-05-05 15:09:42.000000000 -0400
+++ linux-2.6.16.x86_64/include/linux/audit.h 2006-05-05 14:49:35.000000000 -0400
@@ -324,7 +324,7 @@ extern void auditsc_get_stamp(struct aud
extern int audit_set_loginuid(struct task_struct *task, uid_t loginuid);
extern uid_t audit_get_loginuid(struct audit_context *ctx);
extern int audit_ipc_obj(struct kern_ipc_perm *ipcp);
-extern int audit_ipc_set_perm(unsigned long qbytes, uid_t uid, gid_t gid, mode_t mode, struct kern_ipc_perm *ipcp);
+extern int audit_ipc_set_perm(unsigned long qbytes, uid_t uid, gid_t gid, mode_t mode);
extern int audit_bprm(struct linux_binprm *bprm);
extern int audit_socketcall(int nargs, unsigned long *args);
extern int audit_sockaddr(int len, void *addr);
^ permalink raw reply
* [lm-sensors] Unknown EEPROM type (8)?????? AND CPU temperature
From: Rudolf Marek @ 2006-05-05 20:15 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <AFD391091A1B1F4C810F27127FD3BA05A0DC53@ntsvr06.pontassieve.local>
Hello Alessio
> Redhat ES 4 kernel 2.6.9-34.Elsmp,
> Mother board ASUS p5gd2 (bios 1006) with P4 at 3.4Ghz.
> Sensors: sensors version 2.8.7 with libsensors version 2.8.7
Too old version, you have 83627EHF imho. Please try new version
2.9.1/2 should be OK
> i2c /dev entries driver
> CPU0: Temperature above threshold
> CPU1: Temperature above threshold
> CPU1: Running in modulated clock mode
> CPU0: Running in modulated clock mode
> CPU1: Temperature above threshold
> CPU0: Temperature above threshold
> CPU0: Running in modulated clock mode
> CPU1: Running in modulated clock mode
This is done idependetely from hardware and it means
that both CPUs overheat, please check the heatsinks
and/or check the thermal conducting grease between
heatsink and processor. Check fans too.
> 1) Sensor/chipset not recognised.
Old version
> 2) Messages about cpu temperature
See above ;)
Regards
Rudolf
^ permalink raw reply
* [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Larry Finger @ 2006-05-05 20:14 UTC (permalink / raw)
To: netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz, Harald Welte,
Jouni Malinen, Christoph Hellwig
Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on
those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis,
Jouni Malinen, and Harald Welte. The important points of my proposal are as follows:
* The database will be maintained as a text file to be processed by a userland daemon that will
transform this database into the data structure needed by the ieee80211 code. In addition to the
regulatory data, this file will also contain the information needed for the daemon to set the size
of its data arrays dynamically.
* A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo
structure into the kernel. Information passed to the daemon will be the country code in ASCII and
whether the interface is to be used indoors or outdoors.
* Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit
anyone with moderate skills from hacking the channel/power settings, but such hacking will require
some effort.
* Each channel in the resulting kernel data structure will have appropriate flags set indicating if
it is to be used indoors, outdoors, or both. In addition, if the channel should be used only for
passive scanning, a suitable flag will be set. In the 2.4 GHz band, a flag will indicate if it
should be used for 802.11b, otherwise both b and g mode will be assumed. In the 5.0 GHz bands, a
flag will be set if the channel is to conform with 802.11h or 802.11a standards.
The database consists of two sections. The first relates the Country Codes to a wireless group. The
second section describes the channel parameters for the groups. Shown below is a fragment showing
the Country Code - Group info for a few countries and the definitions for a few of the groups.
Please send me any comments, etc.
Larry
===================================================================
# text file for IEEE80211 Regulatory/Geographical information
#
# Version of 04 May 2006
#
# Information for dynamic array sizing
#
Number of Countries: 100
Number of Groups: 15
#
# Countries listed first
#
# group Country Code Description
#
1 AT Austria (Standard EU)
1 DE Germany (Standard EU)
2 FRI France Indoor (Not Guyana or La Reunion)
3 FRO France Outdoor (Not Guyana or La Reunion)
4 FR1 French Departments of Guyana and La Reunion Indoor
5 FR2 French Departments of Guyana and La Reunion Outdoor
.
.
.
9 US United States (FCC)
#
#
# Groups follow countries
#
Group 0 - Unspecified Country
#
# Band Ch. Range Ch. Spacing Power Flags
#
# Band - b, bg, a, or h
# Ch. Range - Minimum and Maximum Channels for this range
# Ch. Spacing - Number of channels between adjacent entries
# Power in mW EIRP
# Flag Codes
# B - Both Indoor and Outdoor
# I - Indoor Only
# O - Outdoor Only
# P - Passive Scan Only
#
bg 1 - 11 1 100 B
#
Group 1 - General European Union (EU)
#
bg 1 - 13 1 100 B
h 36 - 40 4 200 I
h 52 - 64 4 200 IP
h 100 - 140 4 1000 BP
#
Group 2 - France Indoor (Not Guyana or La Reunion)
#
bg 1 - 13 1 100 I
h 36 - 48 4 200 I
h 52 - 64 4 200 IP
h 100 - 140 4 1000 IP
#
Group 3 - France Outdoor (Not Guyana or La Reunion)
#
bg 1 - 8 1 100 O
bg 9 - 13 1 10 O
h 100 - 140 4 1000 OP
.
.
.
.
#
Group 9 - US (FCC)
#
bg 1 - 11 1 100 B
a 36 - 40 4 200 I
a 52 - 64 4 200 B
a 149 - 161 4 1000 B
#
^ permalink raw reply
* Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Jon Smirl @ 2006-05-05 20:14 UTC (permalink / raw)
To: Ian Romanick, Greg KH, Dave Airlie, Arjan van de Ven; +Cc: linux-kernel
In-Reply-To: <445BA584.40309@us.ibm.com>
On 5/5/06, Ian Romanick <idr@us.ibm.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Peter Jones wrote:
> > On Thu, 2006-05-04 at 17:38 -0400, Jon Smirl wrote:
> >
> >># cd /sys/bus/pci/devices/0000:01:00.0
> >># echo 1 >rom
> >># hexdump -C rom
> >>
> >>As far as I know this works on every platform, not just the PC one.
> >
> > Yep, you're right, this works. So we don't necessarily need it for the
> > vbetool case. X still could use it though, instead of their scary
> > poke-at-memory way.
>
> Dave Airlie recently changed X to use sysfs for reading ROMs. I'm also
> working on some changes to eliminate nearly all of the PCI bus poking
> that X does. Search for "PCI rework" or "libpciaccess" in the xorg list
> archives.
What's the story with PCI VGA routing?
DaveA I were chatting about an alternative to 'enable' attribute. You
would make a VGA driver that isn't bound to any PCI IDs. After the
kernel boots a user space program uses sysfs/vga/new_id to load it
with PCI IDs for all PCI class = VGA hardware. Anything that doesn't
have a driver loaded will then get bound to this VGA driver. In
conjunction with the driver udev would make a device node appear.
Opening the new device node would enable the device and control
ownership. If you want to load a device specific driver later, set
sysfs/vga/unbind=1, load the new device specific driver, set
sysfs/vga/bind=1.
This scheme all works within existing kernel mechanisms and does not
require adding an 'enable' attribute. It also addresses the problem of
who owns the state in the hardware; the state is owned by whoever has
the device node open. If another app wants to mess with the hardware
it won't be able to open the device node.
I would like to see other design alternatives considered on this
issue. The 'enable' attribute has a clear problem in that you can't
tell which user space program is trying to control the device.
Multiple programs accessing the video hardware with poor coordination
is already the source of many problems.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* prurient marbles
From: Paula Morrison @ 2006-05-05 13:11 UTC (permalink / raw)
To: nfs
[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #1.2: Type: text/html, Size: 412 bytes --]
[-- Attachment #2: intrinsic.gif --]
[-- Type: image/gif, Size: 40768 bytes --]
^ permalink raw reply
* Re: [PATCH] binary patch.
From: Nicolas Pitre @ 2006-05-05 20:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac9wxom0.fsf@assigned-by-dhcp.cox.net>
On Fri, 5 May 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Fri, 5 May 2006, Junio C Hamano wrote:
> >
> >> The delta is going to be deflated and hopefully gets a bit
> >> smaller, so if we really care that level of detail, it might be
> >> worth to do (deflate_size*3/2) or something like that here, use
> >> delta with or without deflate whichever is smaller, and mark the
> >> uncompressed delta with a different tag ("uncompressed delta"?).
> >> And for symmetry, to deal with uncompressible data, we may want
> >> to have "uncompressed literal" as well.
> >
> > Nah... Please just forget that. ;-)
>
> I was serious about the above actually.
And I think this is overkill.
First, if a deflated delta is to be _larger_ than its inflated version
this is because the delta data is really really short, most probably
shorter than a single base85 line. Same for literal data.
So I truely think the pretty special and rare case where not deflating
might be smaller is simply not worth the added complexity.
> BTW, this "binary patch" opens a different can of worms.
>
> Currently, the diff uses a heuristic borrowed from GNU diff
> (I did not look at the code when I did it, but it is described
> in its documentation) to decide if a file is binary (look at the
> first few bytes and find NUL). I am sure people will want to
> have a way to say "that heuristic fails but this _is_ a binary
> file and please treat it as such".
>
> There are two, both valid, I think, ways to do it.
>
> - give an option to "diff" that says "treat this path as binary
> for this invocation of the program".
>
> - give an attribute to blob object that says "this blob is
> binary and should be treated as such".
>
> The latter is probably the right way to go in the longer term.
I'm not sure I agree.
> A blob being binary or not is a property of the content and does
> not depend on where it sits in the history, so unlike "recording
> renames as a hint in commit objects", the attribute is at the
> blob level, not at the commit nor the tree that points at the
> blob.
Well, sort of.
> But "binaryness" affects only certain operations that extract
> the data (e.g. diff and grep) and not others (e.g. fetch).
> Also, it makes sense to being able to retroactively mark a blob,
> which was not marked as such originally, is a binary. So I do
> not think it should be recorded in the object header.
Agreed.
> Which suggests that we may perhaps want to have notes that can
> be attached to existing objects to augment them without changing
> the contents of the data, and have tools notice these notes when
> they are available. Another example is to associate correct
> MIME types to blobs so, gitweb _blob_ links can do sensible
> things to them.
I think blobs are the wrong level to attach such notes. If you go that
path you'll have to add as many entries for the number of blobs many
revisions of the same file might have.
Instead I think it should be attached to files. After all being a
binary or not is a file attribute regardless of its revision. And
implementation wise I'd do it as a .gitbin file listing all names of
files that should be considered as binaries, with path globing and all,
just like .gitignore currently lists files that should be ignored.
And the advantage is that those .gitbin files can be distributed and
revision-controlled just like the .gitignore files.
And in addition to those files you could have a section in the repo
config file listing default name patterns for files that are considered
binaries. Or even a section, if present, that lists patterns for files
that are _not_ binaries since that list might certainly be shorter.
There could be a corresponding .gittext as well.
And in the absence of any of those then the default automatic euristic
applies.
Nicolas
^ permalink raw reply
* Re: Remove silly messages from input layer.
From: Martin Bligh @ 2006-05-05 20:06 UTC (permalink / raw)
To: Nuri Jawad
Cc: Dave Jones, Martin Mares, Pavel Machek, dtor_core, Linux Kernel
In-Reply-To: <Pine.LNX.4.64.0605052131580.28721@pc>
>> Go buy a new laptop because someone else has a utopian view on how
>> hardware should be?
>
> You mean deciding not to silently ignore errors is having a utopian
> view? Are we talking about Linux or kernel32.dll?
>
>> When a user can't do *anything* about it, it's useless, and serves
>> as nothing but a cause for concern. "Oh no, is my laptop dying?".
>
> Laptops come with Windows XP pre-installed for those users, what was
> your problem again?
Sorry, but these comparisons to Windows are just childish.
Linux is not obliged to spit out meaningless, unhelpful error messages,
and be as user-hostile as possible. It's not a good trait. The current
error message is wrong ... if we can come up with something useful to
print, then great. But throwing 'Windows' around is not useful, and
neither are crappy, incorrect errors.
M.
^ permalink raw reply
* Re: megaraid_mbox: garbage in file
From: James Bottomley @ 2006-05-05 20:05 UTC (permalink / raw)
To: Vasily Averin
Cc: linux-scsi, Neela.Kolli, Atul Mukker, Seokmann.Ju, sreenib, devel,
Linux Kernel Mailing List
In-Reply-To: <445B96B9.20100@sw.ru>
On Fri, 2006-05-05 at 22:17 +0400, Vasily Averin wrote:
> megaraid mailbox: status:0x0 cmd:0xa7 id:0x25 sec:0x1a
> lba:0x33f624ac addr:0xffffffff ld:128 sg:4
> scsi cmnd: 0x28 0x00 0x33 0xf6 0x24 0xac 0x00 0x00 0x1a 0x00
> mbox request_buffer eafde340 use_sg 4
> mbox sg0: page 077a0474 off 0 addr 1fd575000 len 4096 virt ff15a000
> first 03020100 page->flags 40020101
> mbox sg1: page 077b5738 off 0 addr 1fdede000 len 4096 virt ff141000
> first 03020100 page->flags 40020101
> mbox sg2: page 077ad500 off 0 addr 1fdb40000 len 4096 virt ff056000
> first 03020100 page->flags 40020101
> mbox sg3: page 030d46e8 off 1024 addr 5e6a400 len 1024 virt 07e6a400
> first 03020100 page->flags 20001004
The odd thing about this is that the highmem addresses shouldn't have a
virtual mapping (since nothing should have called kmap on them).
But the other tickles a suspicion about the card. I know various LSI
chips that don't have a true 64 bit mode, but instead have programmable
windowed mappings in their descriptors (i.e. all SG list elements have
to be in the same xGB region of physical memory), and since the last
descriptor is more than 4GB away from the other three, whether this
might be the problem here. Unfortunately, only LSI can tell us this ...
James
^ permalink raw reply
* [Qemu-devel] qemu/hw usb-hub.c
From: Fabrice Bellard @ 2006-05-05 20:05 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Fabrice Bellard <bellard@savannah.gnu.org> 06/05/05 20:05:35
Modified files:
hw : usb-hub.c
Log message:
patch in bLength for hub descriptor (Lonnie Mendez)
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb-hub.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
^ permalink raw reply
* git pull on ia64 linux tree
From: Luck, Tony @ 2006-05-05 20:04 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <200504222203.j3MM3fV17003@unix-os.sc.intel.com>
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below.
Thanks!
-Tony
arch/ia64/lib/memcpy_mck.S | 9 ++++++---
include/asm-ia64/bitops.h | 1 -
2 files changed, 6 insertions(+), 4 deletions(-)
Chen, Kenneth W:
[IA64] strcpy returns NULL pointer and not destination pointer
Jon Mason:
[IA64] remove asm-ia64/bitops.h self-inclusion
diff-tree 913ed41eb5c948d2f8b5deffd29c2638eceef3d7 (from 3e6e155646706f1ef9f791a4402d145f112a3f8d)
Author: Jon Mason <jdmason@us.ibm.com>
Date: Wed May 3 17:26:58 2006 -0500
[IA64] remove asm-ia64/bitops.h self-inclusion
asm-ia64/bitops.h includes itself. The #ifndef _ASM_IA64_BITOPS_H
prevents this from being an issue, but it should still be removed.
Signed-off-by: Jon Mason <jdmason@us.ibm.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
diff --git a/include/asm-ia64/bitops.h b/include/asm-ia64/bitops.h
index 90921e1..6cc517e 100644
--- a/include/asm-ia64/bitops.h
+++ b/include/asm-ia64/bitops.h
@@ -11,7 +11,6 @@ #define _ASM_IA64_BITOPS_H
#include <linux/compiler.h>
#include <linux/types.h>
-#include <asm/bitops.h>
#include <asm/intrinsics.h>
/**
diff-tree 3e6e155646706f1ef9f791a4402d145f112a3f8d (from d98550e334715b2d9e45f8f0f4e1608720108640)
Author: Chen, Kenneth W <kenneth.w.chen@intel.com>
Date: Wed May 3 11:53:43 2006 -0700
[IA64] strcpy returns NULL pointer and not destination pointer
Bob Picco noted that 6edfba1b33c701108717f4e036320fc39abe1912
dropped the -ffreestanding compiler flag from the top level
Makefile, which allows the compiler to substitute memcpy() in
places where strcpy() is used with a known size source string.
But the ia64 memcpy() returns 0 for success, and "bytes copied"
for failure.
Fix to return the address of the destination string (like
stdlibc version, and other architectures). There are no
places where ia64 specific code makes use of the non-standard
return value.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
diff --git a/arch/ia64/lib/memcpy_mck.S b/arch/ia64/lib/memcpy_mck.S
index 46c9331..9e534d5 100644
--- a/arch/ia64/lib/memcpy_mck.S
+++ b/arch/ia64/lib/memcpy_mck.S
@@ -6,7 +6,9 @@
* in1: source address
* in2: number of bytes to copy
* Output:
- * 0 if success, or number of byte NOT copied if error occurred.
+ * for memcpy: return dest
+ * for copy_user: return 0 if success,
+ * or number of byte NOT copied if error occurred.
*
* Copyright (C) 2002 Intel Corp.
* Copyright (C) 2002 Ken Chen <kenneth.w.chen@intel.com>
@@ -73,6 +75,7 @@ GLOBAL_ENTRY(memcpy)
and r28=0x7,in0
and r29=0x7,in1
mov f6ð
+ mov retval=in0
br.cond.sptk .common_code
;;
END(memcpy)
@@ -84,7 +87,7 @@ GLOBAL_ENTRY(__copy_user)
mov f6ñ
mov saved_in0=in0 // save dest pointer
mov saved_in1=in1 // save src pointer
- mov saved_in2=in2 // save len
+ mov retval=r0 // initialize return value
;;
.common_code:
cmp.gt p15,p0=8,in2 // check for small size
@@ -92,7 +95,7 @@ GLOBAL_ENTRY(__copy_user)
cmp.ne p14,p0=0,r29 // check src alignment
add src0=0,in1
sub r30=8,r28 // for .align_dest
- mov retval=r0 // initialize return value
+ mov saved_in2=in2 // save len
;;
add dst0=0,in0
add dst1=1,in0 // dest odd index
^ permalink raw reply related
* [Qemu-devel] qemu/hw acpi.c
From: Fabrice Bellard @ 2006-05-05 20:03 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Fabrice Bellard <bellard@savannah.gnu.org> 06/05/05 20:03:46
Modified files:
hw : acpi.c
Log message:
typo
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/acpi.c.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
^ permalink raw reply
* [PATCH 2/3] bcm43xx-d80211: fix whitespace
From: Stefano Brivio @ 2006-05-05 19:59 UTC (permalink / raw)
To: John W. Linville; +Cc: bcm43xx-dev, netdev
In-Reply-To: <20060505215542.25d310dd@localhost>
Fix whitespace.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:43:44.981535888 +0200
@@ -128,13 +128,13 @@
static struct pci_device_id bcm43xx_pci_tbl[] = {
/* Broadcom 4303 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4307 802.11b */
+ /* Broadcom 4307 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4318 802.11b/g */
+ /* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4306 802.11a */
+ /* Broadcom 4306 802.11a */
// { PCI_VENDOR_ID_BROADCOM, 0x4321, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4309 802.11a/b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4324, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
--
Ciao
Stefano
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.