Re: [PATCH][MMC] Fix wrong EXT_CSD_REV handling
On Fri, 14 Dec 2007 11:01:03 +0900 Kyungmin Park [EMAIL PROTECTED] wrote: Yes, reserved word should or must be zero, then it should check if (ext_csd_struct = 2) instead of = 2. In the Spec. 4.2, it can have three value 0, 1, or 2. There's no other restriction. As I said, the spec doesn't say must, and I've seen cards with bogus data in there so I'm afraid we can't rely on the fields being zero. The version field is the only decent way of determining what to expect in the rest of the structure. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch 1/3] block: non-atomic queue_flags prep
On Tue, Dec 18, 2007 at 08:44:40AM +0100, Jens Axboe wrote: On Sat, Dec 15 2007, Nick Piggin wrote: Hi, This is just an idea I had, which might make request processing a little bit cheaper depending on queue behaviour. For example if it is getting plugged unplugged frequently (as I think is the case for some database workloads), then we might save one or two atomic operations per request. Anyway, I'm not completely sure if I have ensured all queue_flags users are safe (I think md may need a bit of help). But overall it seems quite doable. Looks ok to me, I'll throw it into the testing mix. Thanks Nick! OK... actually if you are expecting it to be widely tested, can you change the BUG_ONs in queue_flag_set / queue_flag_clear into WARN_ON? That way it's less likely to take down people's systems... Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] readahead: clean up and simplify the code for filemap page fault readahead
On Sun, Dec 16, 2007 at 07:59:30PM +0800, Fengguang Wu wrote:
@@ -1321,78 +1401,69 @@ int filemap_fault(struct vm_area_struct
struct address_space *mapping = file-f_mapping;
struct file_ra_state *ra = file-f_ra;
struct inode *inode = mapping-host;
+ pgoff_t offset = vmf-pgoff;
struct page *page;
unsigned long size;
- int did_readaround = 0;
int ret = 0;
size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) PAGE_CACHE_SHIFT;
if (vmf-pgoff = size)
return VM_FAULT_SIGBUS;
- /* If we don't want any read-ahead, don't bother */
- if (VM_RandomReadHint(vma))
- goto no_cached_page;
-
/*
- * Do we have something in the page cache already?
+ * Do we have something in the page cache already that
+ * is unlocked and already up-to-date?
*/
-retry_find:
- page = find_lock_page(mapping, vmf-pgoff);
- /*
- * For sequential accesses, we use the generic readahead logic.
- */
- if (VM_SequentialReadHint(vma)) {
- if (!page) {
- page_cache_sync_readahead(mapping, ra, file,
-vmf-pgoff, 1);
- page = find_lock_page(mapping, vmf-pgoff);
- if (!page)
- goto no_cached_page;
- }
- if (PageReadahead(page)) {
- page_cache_async_readahead(mapping, ra, file, page,
-vmf-pgoff, 1);
- }
- }
+ read_lock_irq(mapping-tree_lock);
+ page = radix_tree_lookup(mapping-page_tree, offset);
+ if (likely(page)) {
+ int got_lock, uptodate;
+ page_cache_get(page);
+
+ got_lock = !TestSetPageLocked(page);
+ uptodate = PageUptodate(page);
+ read_unlock_irq(mapping-tree_lock);
If we could avoid open coding tree_lock here (and expanding its coverage
to PageUptodate), that would be nice. I don't think it gains us too much.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/s390/: Spelling fixes
On Monday 17 December 2007 20:40, Joe Perches wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- drivers/s390/block/dasd_3990_erp.c |2 +- drivers/s390/block/dasd_eckd.c |2 +- drivers/s390/char/sclp_rw.c|2 +- drivers/s390/char/tape_3590.c |2 +- drivers/s390/cio/airq.c|2 +- drivers/s390/scsi/zfcp_erp.c |2 +- drivers/s390/scsi/zfcp_qdio.c |2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/s390/block/dasd_3990_erp.c b/drivers/s390/block/dasd_3990_erp.c index 5b7385e..c02f960 100644 --- a/drivers/s390/block/dasd_3990_erp.c +++ b/drivers/s390/block/dasd_3990_erp.c @@ -2620,7 +2620,7 @@ dasd_3990_erp_handle_match_erp(struct dasd_ccw_req *erp_head, * DASD_3990_ERP_ACTION * * DESCRIPTION - * controll routine for 3990 erp actions. + * control routine for 3990 erp actions. * Has to be called with the queue lock (namely the s390_irq_lock) acquired. * * PARAMETER diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c index 44adf84..6038d91 100644 --- a/drivers/s390/block/dasd_eckd.c +++ b/drivers/s390/block/dasd_eckd.c @@ -1542,7 +1542,7 @@ dasd_eckd_performance(struct dasd_device *device, void __user *argp) prssdp = (struct dasd_psf_prssd_data *) cqr-data; memset(prssdp, 0, sizeof (struct dasd_psf_prssd_data)); prssdp-order = PSF_ORDER_PRSSD; - prssdp-suborder = 0x01;/* Perfomance Statistics */ + prssdp-suborder = 0x01;/* Performance Statistics */ prssdp-varies[1] = 0x01; /* Perf Statistics for the Subsystem */ ccw = cqr-cpaddr; diff --git a/drivers/s390/char/sclp_rw.c b/drivers/s390/char/sclp_rw.c index d6b06ab..ad7195d 100644 --- a/drivers/s390/char/sclp_rw.c +++ b/drivers/s390/char/sclp_rw.c @@ -76,7 +76,7 @@ sclp_make_buffer(void *page, unsigned short columns, unsigned short htab) } /* - * Return a pointer to the orignal page that has been used to create + * Return a pointer to the original page that has been used to create * the buffer. */ void * diff --git a/drivers/s390/char/tape_3590.c b/drivers/s390/char/tape_3590.c index da25f8e..8246ef3 100644 --- a/drivers/s390/char/tape_3590.c +++ b/drivers/s390/char/tape_3590.c @@ -1495,7 +1495,7 @@ tape_3590_unit_check(struct tape_device *device, struct tape_request *request, device-cdev-dev.bus_id); return tape_3590_erp_basic(device, request, irb, -EPERM); case 0x8013: - PRINT_WARN((%s): Another host has priviliged access to the + PRINT_WARN((%s): Another host has privileged access to the tape device\n, device-cdev-dev.bus_id); PRINT_WARN((%s): To solve the problem unload the current cartridge!\n, device-cdev-dev.bus_id); diff --git a/drivers/s390/cio/airq.c b/drivers/s390/cio/airq.c index 5287631..5eada73 100644 --- a/drivers/s390/cio/airq.c +++ b/drivers/s390/cio/airq.c @@ -23,7 +23,7 @@ static adapter_int_handler_t adapter_handler; * register for adapter interrupts * * With HiperSockets the zSeries architecture provides for - * means of adapter interrups, pseudo I/O interrupts that are + * means of adapter interrupts, pseudo I/O interrupts that are * not tied to an I/O subchannel, but to an adapter. However, * it doesn't disclose the info how to enable/disable them, but * to recognize them only. Perhaps we should consider them diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c index 07fa824..8925b3a 100644 --- a/drivers/s390/scsi/zfcp_erp.c +++ b/drivers/s390/scsi/zfcp_erp.c @@ -1285,7 +1285,7 @@ zfcp_erp_strategy_do_action(struct zfcp_erp_action *erp_action) * note: no lock in subsequent strategy routines * (this allows these routine to call schedule, e.g. * kmalloc with such flags or qdio_initialize friends) - * Note: in case of timeout, the seperate strategies will fail + * Note: in case of timeout, the separate strategies will fail * anyhow. No need for a special action. Even worse, a nameserver * failure would not wake up waiting ports without the call. */ diff --git a/drivers/s390/scsi/zfcp_qdio.c b/drivers/s390/scsi/zfcp_qdio.c index 51d92b1..22fdc17 100644 --- a/drivers/s390/scsi/zfcp_qdio.c +++ b/drivers/s390/scsi/zfcp_qdio.c @@ -529,7 +529,7 @@ zfcp_qdio_sbals_wipe(struct zfcp_fsf_req *fsf_req) /** - * zfcp_qdio_sbale_fill - set address and lenght in current SBALE + * zfcp_qdio_sbale_fill - set address and length in current SBALE * on request_queue */ static void ACK for the zfcp bits. Cheers Swen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read
Re: [RFC PATCH 06/12] PAT 64b: Add ioremap_wc support
Siddha, Suresh B [EMAIL PROTECTED] writes: Yes. We are looking for comments for our proposal to track the reserved/non-reserved regions some what different. This is the critical issue which had been holding off PAT for years now... The mattr infrastructure appears to do a decent job of handling the reserved page mapping case. It essentially reinvents struct vm_area_struct, and so I expect we can do things a little more easily if we use the existing vm_area_struct with it's vm_page_prot member for our checks, all rooted at a dummy reserved page inode. That way we don't need to do anything special on unmap. For normal pages we always have them in the kernel mapping and we use them there. change_page_attr also comes in from the AGP drivers and changes the caching attributes on a few of those. So when mapping a normal page we need to require it to be write-back or whatever change_page_attr has set it to. I expect 2 bits of page-flags with the proper default can handle that. change_page_attr needs to check non kernel mappings of a page and either fix them or fail. If we perform the checks I have described for normal pages in /dev/mem (in remap_pfn_pages?) that should be our most difficult case handled. Eric snip from the other mails Change x86_64 identity map to only map non-reserved memory. This helps to handle UC/WC mapping of reserved region in a much simple manner (we don't have to do cpa any more, as such not keep track of the actual reference counts. We still track all the usages to keep the mappings consistent. We just avoid the headache of splitting mattr regions for managing ref counts for every individual usage of the reserved area). Well we do want to early map the ``isa'' region. For now, we don't track RAM pages using memattr infrastructure. This is because, memattr infrastructure is not enough. i.e., while the page is getting tracked using memattr infrastructure, potentially the page can get freed(a bug that we need to catch, to avoid attribute aliasing). For example, a driver does ioremap_uc and an application mapped the same page using /dev/mem. When the driver does iounamp and free the page, /dev/mem mapping is still live and we run into aliasing issue. /dev/mem is particular weird because it doesn't own the page, and thus will always be the second user if we are talking about pages in ram. Can we use the existing page struct to keep track of the attribute and usage? Yes but not the way you describe below. /dev/mem mappings then can increment the page ref count and not allow to free the page while the /dev/mem mappings are active. And allow /dev/mem to map only those pages which are marked reserved (which the driver does before doing iomap). Part of the usefulness of /dev/mem is that it can do silly things like map pages someone else in the kernel is using. /dev/mem by it's very nature does not own ram pages so we need to handle that differently. Or when a WB mapping through /dev/mem is active, don't allow any driver to map the page as UC.. Can we do this tracking for RAM pages through struct page. Or there any issues we should keep in mind.. I think some bits in page-flags should do the trick. The semantics of change_page_attr are interesting in this case. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4 -mm] kexec based hibernation -v7 : kexec jump
On Tue, 2007-12-11 at 02:27 -0700, Eric W. Biederman wrote:
Huang, Ying [EMAIL PROTECTED] writes:
On Mon, 2007-12-10 at 19:25 -0700, Eric W. Biederman wrote:
Huang, Ying [EMAIL PROTECTED] writes:
[...]
/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now.
*/
-NORET_TYPE void machine_kexec(struct kimage *image)
+int machine_kexec_vcall(struct kimage *image, unsigned long *ret,
+ unsigned int argc, va_list args)
{
Why do we need var arg support?
Can't we do that with a shim we load from user space?
If all parameters are provided in user space, the usage model may be as
follow:
- sys_kexec_load() /* with executable/data/parameters(A) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with
parameters(A)*/
- /* jump back */
- sys_kexec_load() /* with executable/data/parameters(B) loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,) /* execute physical mode code with
parameters(B)*/
- /* jump back */
That is, the kexec image should be re-loaded if the parameters are
different, and there can be no state reserved in kexec image. This is OK
for original kexec implementation, because there is no jumping back.
But, for kexec with jumping back, another usage model may be useful too.
- sys_kexec_load() /* with executable/data loaded */
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(A)) /* execute physical
mode
code with parameters(A)*/
- sys_reboot(,,LINUX_REBOOT_CMD_KEXEC,parameters(B)) /* execute physical
mode
code with parameters(B)*/
This way the kexec image need not to be re-loaded, and the state of
kexec image can be reserved across several invoking.
Interesting. We wind up preserving the code in between invocations.
I don't know about your particular issue, but I can see that clearly
we need a way to read values back from our target image.
And if we can read everything back one way to proceed is to read
everything out modify it and then write it back.
Amending a kexec image that is already stored may also make sense.
I'm not convinced that the var arg parameters make sense, but you
added them because of a real need.
The kexec function is split into two separate calls so that we can
unmount the filesystem the kexec image comes from before actually
doing the kexec.
My real issue is that I need a kind of kernel to kernel communication
method. The var args is just a convenient way to pass an array of
unsigned longs between two kernels. The reason is as follow:
The kexec based hibernating process is as follow:
h1. put devices in quiescent state
h2. save devices/CPU state
h3. jump to kexeced kernel (kernel B)
*h4. normal kernel boot of kernel B
*h5. save devices/CPU state
*h6. jump back to original kernel (kernel A)
h7. restore devices/CPU state
h8. put devices in quiescent state
h9. put devices in low power state
h10. execute necessary ACPI method (prepare to sleep)
h11. save devices/CPU state
h12. jump to kernel B
*h13. execute necessary ACPI method (wake up)
*h14. restore devices/CPU state
*h15. put devices in normal power state
*h16. write memory image of kernel A into disk
*h17. put system into ACPI S4 state
The kexec based resuming process is as follow:
*r1. boot the resuming kernel (kernel C)
*r2. restore the memory image of kernel A
*r3. put devices in quiescent state
*r4. execute necessary ACPI method (prepare to resume)
*r5. jump to kernel A
r6. execute necessary ACPI method (wake up)
r7. restore devices/CPU state
Where, line begin with * is executed in kernel B and kernel C, others
are executed in kernel A.
The kernel A need to distinguish the difference between h7 and r6, while
the kernel B/C need to distinguish between *h13 and normal jump back.
The different kernel action need to be taken depends on the action of
peer kernel. Now, this is solved by kernel-kernel communication, a
command word is passed to peer kernel to inform the action required.
I remember you have said before that you think it is better to use only
user space to user space communication between kernel A and kernel B.
This is OK for normal kexec. But if the kexec jump is used for multiple
functions with early kernel action involved (normal kexec jump, kexec
jump to hibernate, kexec jump to resume), it is necessary to use kernel
to kernel communication.
The var args in the patch is just an array of unsigned longs, it can be
expresses as follow too.
int kexec_call(struct kimage *image, unsigned long *ret, unsigned int
argc, unsigned long argv[]);
The var args version is as follow.
int kexec_call(struct kimage *image, unsigned long *ret, unsigned int
argc, ...);
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Update ip command line processing
Recently the documentation in Documentation/nfsroot.txt was
update to note that in fact ip=off and ip=::off as the
latter is ignored and the default (on) is used.
This was certainly a step in the direction of reducing confusion.
But it seems to me that the code ought to be fixed up so that
ip=::off actually turns off ip autoconfiguration.
This patch also notes more specifically that ip=on (aka ip=::on)
is the default.
Cc: Amos Waterland [EMAIL PROTECTED]
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Index: net-2.6.25/net/ipv4/ipconfig.c
===
--- net-2.6.25.orig/net/ipv4/ipconfig.c 2007-12-18 17:45:07.0 +0900
+++ net-2.6.25/net/ipv4/ipconfig.c 2007-12-18 17:45:52.0 +0900
@@ -1414,9 +1414,16 @@ late_initcall(ip_auto_config);
*/
static int __init ic_proto_name(char *name)
{
+ if (!name) {
+ return 1;
+ }
if (!strcmp(name, on) || !strcmp(name, any)) {
return 1;
}
+ if (!strcmp(name, off) || !strcmp(name, none)) {
+ ic_enable = 0;
+ return 1;
+ }
#ifdef CONFIG_IP_PNP_DHCP
else if (!strcmp(name, dhcp)) {
ic_proto_enabled = ~IC_RARP;
@@ -1451,12 +1458,6 @@ static int __init ip_auto_config_setup(c
ic_set_manually = 1;
- ic_enable = (*addrs
- (strcmp(addrs, off) != 0)
- (strcmp(addrs, none) != 0));
- if (!ic_enable)
- return 1;
-
if (ic_proto_name(addrs))
return 1;
Index: net-2.6.25/Documentation/nfsroot.txt
===
--- net-2.6.25.orig/Documentation/nfsroot.txt 2007-12-18 17:46:47.0
+0900
+++ net-2.6.25/Documentation/nfsroot.txt2007-12-18 17:48:51.0
+0900
@@ -97,10 +97,6 @@ ip=client-ip:server-ip:gw-ip:netm
autoconfiguration will take place. The most common way to use this
is ip=dhcp.
- Note that ip=off is not the same thing as ip=::off, because in
- the latter autoconfiguration will take place if any of DHCP, BOOTP or RARP
- are compiled in the kernel.
-
client-ip IP address of the client.
Default: Determined using autoconfiguration.
@@ -150,6 +146,7 @@ ip=client-ip:server-ip:gw-ip:netm
off or none: don't use autoconfiguration
on or any: use any protocol available in the kernel
+ (default)
dhcp:use DHCP
bootp: use BOOTP
rarp:use RARP
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: Atmel Serial Console interrupt handler splitup
On Mon, 17 Dec 2007 23:49:32 + Russell King - ARM Linux [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 09:56:30PM +0100, Remy Bohmer wrote: +#define lread(port) __raw_readl(port) +#define lwrite(v, port) __raw_writel(v, port) Why is this necessary, and what does 'l' stand for? There is a huge list of macros below these definitions. By doing it this way, the macros still fit on 80 characters wide, while without them, I had split up the macros over several lines, which does not make it more readable. That's all. 'l' refers at the last letter of __raw_readl, and writel. Nothing special. So why not keep to the Linux convention? How about at_readl() and at_writel() ? Something like this perhaps? #define at_readl(port, off) __raw_readl((port)-membase + (off)) #define at_writel(v, port, off) __raw_writel(v, (port)-membase + (off)) #define UART_PUT_CR(port, v)at_writel(v, port, ATMEL_US_CR) #define UART_PUT_MR(port, v)at_writel(v, port, ATMEL_US_MR) #define UART_PUT_IER(port, v) at_writel(v, port, ATMEL_US_IER) #define UART_PUT_IDR(port, v) at_writel(v, port, ATMEL_US_IDR) #define UART_PUT_CHAR(port, v) at_writel(v, port, ATMEL_US_THR) #define UART_PUT_BRGR(port, v) at_writel(v, port, ATMEL_US_BRGR) #define UART_PUT_RTOR(port, v) at_writel(v, port, ATMEL_US_RTOR) That said, I wonder if it may actually be nicer to just use at_writel()/at_readl() throughout the driver...but that's for a later cleanup. + while (!(UART_GET_CSR(port) ATMEL_US_TXEMPTY)) + barrier(); Should probably use cpu_relax(), but it's probably out of scope for a codingstyle cleanup patch (and I don't think it matters on AVR32 or ARM.) Agree. Even though it doesn't matter at the moment, I rather like to think a bit about the future. If the kernel has a simple and cheap mechanism there's no reason to avoid using it. I can do it in a separate patch. /* - * First, save IMR and then disable interrupts + * First, save IMR and then disable interrupts */ imr = UART_GET_IMR(port); /* get interrupt mask */ UART_PUT_IDR(port, ATMEL_US_RXRDY | ATMEL_US_TXRDY); @@ -790,30 +828,32 @@ static void atmel_console_write(struct c uart_console_write(port, s, count, atmel_console_putchar); /* - * Finally, wait for transmitter to become empty - * and restore IMR + * Finally, wait for transmitter to become empty + * and restore IMR */ Looks like you're replacing TABs with spaces. Why? I think someone's mailer might be messing with the patches. The above removed and added lines appear to be identical. Yes, the difference was wiped out after a few times back and forth. It was visible (or...not actually visible, but you know how to detect these things) in the first couple of e-mails. Haavard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl
Well the other alternative looks like having a second file per par bar. Say resource0_wc to support the write-combining mode, possibly The intention was to support memory not in bars, but give a generic IOMMU mapped memory interface for user space e.g. for the X server. But that needs a way to return the bus address for the mmap mapping and ioctl was the best I came up with for that. Given it was never finished. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 1/4] pci: Add pci_enable_device_{io,mem} intefaces
On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote:
+EXPORT_SYMBOL(pci_enable_device_io);
+EXPORT_SYMBOL(pci_enable_device_mem);
EXPORT_SYMBOL(pci_enable_device);
Wouldn't it be better to export only the pci_enable_device_flags()
and make these three just static inline wrappers in pci.h?
EXPORT_SYMBOL(pcim_enable_device);
Looks like many SATA drivers would benefit from pcim_* equivalents
of pci_enable_device_{io,mem}, as they could happily work with just
a single MMIO BAR... Alan?
Ivan.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 1/4] pci: Add pci_enable_device_{io,mem} intefaces
On Tue, 2007-12-18 at 12:37 +0300, Ivan Kokshaysky wrote:
On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote:
+EXPORT_SYMBOL(pci_enable_device_io);
+EXPORT_SYMBOL(pci_enable_device_mem);
EXPORT_SYMBOL(pci_enable_device);
Wouldn't it be better to export only the pci_enable_device_flags()
and make these three just static inline wrappers in pci.h?
Been thinking about it yeah. I don't want drivers to start using
the _flags version directly tho, which is why I preferred going that
way but if people prefer the inline version, I'll do that.
EXPORT_SYMBOL(pcim_enable_device);
Looks like many SATA drivers would benefit from pcim_* equivalents
of pci_enable_device_{io,mem}, as they could happily work with just
a single MMIO BAR... Alan?
I have no experience with the pcim stuff, I would appreciate if somebody
took care of that part.
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] atmel_serial: Clean up the code
From: Remy Bohmer [EMAIL PROTECTED]
This patch cleans up the atmel_serial driver to conform the coding rules.
It contains no functional change.
[EMAIL PROTECTED]: additional cleanups]
Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
Changes since v1:
Use at_{read,write}l instead of l{write,read}
More whitespace cleanup
Re-break stuff in atmel_enable_ms()
Kill inlines
Fix comment indentation
Re-indent if() condition in handle_status
Re-indent request_irq() call
Kill useless comments
Revert TODO: CR change
Move comment inside if() body
Kill redundant parens and re-indent
Please note that I'm not trying to steal the show here -- I just want
to get the fundamental stuff out of the way so that I can do
additional fixes on top of everything without having to resolve lots
of conflicts when the next version of this patch comes along.
Haavard
drivers/serial/atmel_serial.c | 328 -
1 files changed, 190 insertions(+), 138 deletions(-)
diff --git a/drivers/serial/atmel_serial.c b/drivers/serial/atmel_serial.c
index 111da57..7af8af8 100644
--- a/drivers/serial/atmel_serial.c
+++ b/drivers/serial/atmel_serial.c
@@ -74,38 +74,42 @@
#define ATMEL_ISR_PASS_LIMIT 256
-#define UART_PUT_CR(port,v)__raw_writel(v, (port)-membase + ATMEL_US_CR)
-#define UART_GET_MR(port) __raw_readl((port)-membase + ATMEL_US_MR)
-#define UART_PUT_MR(port,v)__raw_writel(v, (port)-membase + ATMEL_US_MR)
-#define UART_PUT_IER(port,v) __raw_writel(v, (port)-membase + ATMEL_US_IER)
-#define UART_PUT_IDR(port,v) __raw_writel(v, (port)-membase + ATMEL_US_IDR)
-#define UART_GET_IMR(port) __raw_readl((port)-membase + ATMEL_US_IMR)
-#define UART_GET_CSR(port) __raw_readl((port)-membase + ATMEL_US_CSR)
-#define UART_GET_CHAR(port)__raw_readl((port)-membase + ATMEL_US_RHR)
-#define UART_PUT_CHAR(port,v) __raw_writel(v, (port)-membase + ATMEL_US_THR)
-#define UART_GET_BRGR(port)__raw_readl((port)-membase + ATMEL_US_BRGR)
-#define UART_PUT_BRGR(port,v) __raw_writel(v, (port)-membase + ATMEL_US_BRGR)
-#define UART_PUT_RTOR(port,v) __raw_writel(v, (port)-membase + ATMEL_US_RTOR)
-
-// #define UART_GET_CR(port) __raw_readl((port)-membase + ATMEL_US_CR)
// is write-only
+#define at_readl(port, off)__raw_readl((port)-membase + (off))
+#define at_writel(v, port, off)__raw_writel(v, (port)-membase + (off))
+
+#define UART_PUT_CR(port, v) at_writel(v, port, ATMEL_US_CR)
+#define UART_PUT_MR(port, v) at_writel(v, port, ATMEL_US_MR)
+#define UART_PUT_IER(port, v) at_writel(v, port, ATMEL_US_IER)
+#define UART_PUT_IDR(port, v) at_writel(v, port, ATMEL_US_IDR)
+#define UART_PUT_CHAR(port, v) at_writel(v, port, ATMEL_US_THR)
+#define UART_PUT_BRGR(port, v) at_writel(v, port, ATMEL_US_BRGR)
+#define UART_PUT_RTOR(port, v) at_writel(v, port, ATMEL_US_RTOR)
+
+#define UART_GET_MR(port) at_readl(port, ATMEL_US_MR)
+#define UART_GET_IMR(port) at_readl(port, ATMEL_US_IMR)
+#define UART_GET_CSR(port) at_readl(port, ATMEL_US_CSR)
+#define UART_GET_CHAR(port)at_readl(port, ATMEL_US_RHR)
+#define UART_GET_BRGR(port)at_readl(port, ATMEL_US_BRGR)
+
+/* is write-only */
+/* #define UART_GET_CR(port) at_readl(port, ATMEL_US_CR) */
/* PDC registers */
-#define UART_PUT_PTCR(port,v) __raw_writel(v, (port)-membase +
ATMEL_PDC_PTCR)
-#define UART_GET_PTSR(port)__raw_readl((port)-membase + ATMEL_PDC_PTSR)
-
-#define UART_PUT_RPR(port,v) __raw_writel(v, (port)-membase + ATMEL_PDC_RPR)
-#define UART_GET_RPR(port) __raw_readl((port)-membase + ATMEL_PDC_RPR)
-#define UART_PUT_RCR(port,v) __raw_writel(v, (port)-membase + ATMEL_PDC_RCR)
-#define UART_PUT_RNPR(port,v) __raw_writel(v, (port)-membase +
ATMEL_PDC_RNPR)
-#define UART_PUT_RNCR(port,v) __raw_writel(v, (port)-membase +
ATMEL_PDC_RNCR)
-
-#define UART_PUT_TPR(port,v) __raw_writel(v, (port)-membase + ATMEL_PDC_TPR)
-#define UART_PUT_TCR(port,v) __raw_writel(v, (port)-membase + ATMEL_PDC_TCR)
-//#define UART_PUT_TNPR(port,v)__raw_writel(v, (port)-membase +
ATMEL_PDC_TNPR)
-//#define UART_PUT_TNCR(port,v)__raw_writel(v, (port)-membase +
ATMEL_PDC_TNCR)
-
-static int (*atmel_open_hook)(struct uart_port *);
-static void (*atmel_close_hook)(struct uart_port *);
+#define UART_PUT_PTCR(port, v) at_writel(v, port, ATMEL_PDC_PTCR)
+#define UART_PUT_RPR(port, v) at_writel(v, port, ATMEL_PDC_RPR)
+#define UART_PUT_RCR(port, v) at_writel(v, port, ATMEL_PDC_RCR)
+#define UART_PUT_RNPR(port, v) at_writel(v, port, ATMEL_PDC_RNPR)
+#define UART_PUT_RNCR(port, v) at_writel(v, port, ATMEL_PDC_RNCR)
+#define UART_PUT_TPR(port, v) at_writel(v, port, ATMEL_PDC_TPR)
+#define UART_PUT_TCR(port, v) at_writel(v, port, ATMEL_PDC_TCR)
+/*#define UART_PUT_TNPR(port, v) at_writel(v, port, ATMEL_PDC_TNPR) */
+/*#define UART_PUT_TNCR(port,
Re: [RFC/PATCH 4/4] [POWERPC] pci: Disable IO/Mem on a device when resources can't be allocated
On Tue, Dec 18, 2007 at 10:01:15AM +1100, Benjamin Herrenschmidt wrote: @@ -1040,7 +1040,10 @@ static inline void __devinit alloc_resou r-flags |= IORESOURCE_UNSET; r-end -= r-start; r-start = 0; Perhaps we should use IORESOURCE_UNSET universally... It's a lot better than clearing r-start which is in fact architecture dependent thing and in the end just destroys information for no purpose. Ivan. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch/s390/: Spelling fixes
Hi Joe, I've added all three spelling fix patches to the git390. The patch for drivers lost one hunk because there is another patch in the git390 tree that removes the comment you are trying to fix. Your patches will be included in the big merge frenzy after 2.6.24 has been released. Thanks. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top kernel oopses/warnings this week
On Mon, 2007-12-17 at 21:31 -0500, Theodore Tso wrote: On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote: which also gets bonus points for being totally unreadable, and thus 100% in the spirit of uuid's. Heh. UUID's don't have to be readable; just universally unique. Code on the other hand should be readable. :-) If you want something more readable, you could print the MAC address and boot time. Of course some crazy people seem to think leaking the MAC address will somehow be a privacy violation. And printing a random UUID is a lot simpler Printing a random UUID is necessary, for now anyway, because you cannot assume every machine is going to have a MAC address, even if it is deemed appropriate to print this on oops. The Network is the Computer! Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] [POWERPC] Add fixed-phy support for fs_enet
Hi Jeff, ACK, pass this through paulus? Yes, that's fine for me. Thanks, Jochen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Memory Read Error
I am newbie for Linux Kernel.How can I read the memory area like the range between to .Directly i read that area it shows some error like this unable to handle kernel paging request at virtual address . So,I don't know, how to solve this error .Please anyone help me Thanks in Advance -Sasi- -- View this message in context: http://www.nabble.com/Memory-Read-Error-tp14390531p14390531.html Sent from the linux-kernel mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] atmel_serial: Clean up the code
Hello Haavard, Please note that I'm not trying to steal the show here -- I just want That did not even come to my mind at all... I am happy with everything that helps making this driver better. What shall we do first from here, splitup of the interrupt handler? Or DMA patch? Kind Regards, Remy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: zfcp
James we are planning a major rewrite of the zfcp driver, meaning that a lot of patches will hit the mailing-list in the near future. Since I can't support this additional work-load along with my other responsibilities we are shifting the maintainership to Christof Schmitt as the maintainer and Martin Peschke as the co-maintainer. Please support the two in providing us a new and more stable zfcp environment. Thanks Swen --- MAINTAINERS |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Index: scsi-misc/MAINTAINERS === --- scsi-misc.orig/MAINTAINERS +++ scsi-misc/MAINTAINERS @@ -3246,8 +3246,10 @@ W: http://www.ibm.com/developerworks/lin S: Supported S390 ZFCP DRIVER -P: Swen Schillig -M: [EMAIL PROTECTED] +P: Christof Schmitt +M: [EMAIL PROTECTED] +P: Martin Peschke +M: [EMAIL PROTECTED] M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.ibm.com/developerworks/linux/linux390/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pcmcia: Add support P2CCLK bit enabler for TI PC1520
There is a device that doesn't work when P2CCLK's bit of TI PC1520 was disable.
This patch supports P2CCLK bit enabler for TI PC1520.
Signed-off-by: Nobuhiro Iwamatsu [EMAIL PROTECTED]
---
drivers/pcmcia/Kconfig |5 +
drivers/pcmcia/ti113x.h |8
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 519b4ff..3d80888 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -134,6 +134,11 @@ config YENTA_ENE_TUNE
bool Auto-tune EnE bridges for CB cards if EMBEDDED
depends on YENTA_TI CARDBUS
+config YENTA_TI_P2CCLK
+ default n
+ bool Clock generated by internal oscillator if EMBEDDED
+ depends on YENTA_TI CARDBUS
+
config YENTA_TOSHIBA
default y
bool Special initialization for Toshiba ToPIC bridges if EMBEDDED
diff --git a/drivers/pcmcia/ti113x.h b/drivers/pcmcia/ti113x.h
index d29657b..ea749e8 100644
--- a/drivers/pcmcia/ti113x.h
+++ b/drivers/pcmcia/ti113x.h
@@ -59,6 +59,7 @@
#define TI122X_SCR_SER_STEP 0xc000
#define TI122X_SCR_INTRTIE0x2000
#define TIXX21_SCR_TIEALL 0x1000
+#define TI122X_SCR_P2CCLK 0x0800
#define TI122X_SCR_CBRSVD 0x0040
#define TI122X_SCR_MRBURSTDN 0x8000
#define TI122X_SCR_MRBURSTUP 0x4000
@@ -822,6 +823,13 @@ static int ti12xx_override(struct yenta_socket *socket)
printk(KERN_INFO Yenta: Enabling burst memory read
transactions\n);
val |= TI122X_SCR_MRBURSTUP;
}
+
+#ifdef CONFIG_YENTA_TI_P2CCLK
+ if ( !(val TI122X_SCR_P2CCLK)) {
+ printk(KERN_INFO Yenta: Clock generated by internal
oscillator\n);
+ val |= TI122X_SCR_P2CCLK;
+ }
+#endif
if (val_orig != val)
config_writel(socket, TI113X_SYSTEM_CONTROL, val);
--
1.5.3.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: Atmel Serial Console interrupt handler splitup
On Tue, 18 Dec 2007 12:08:05 +0200 Andrew Victor [EMAIL PROTECTED] wrote: #define at_readl(port, off) __raw_readl((port)-membase + (off)) #define at_writel(v, port, off) __raw_writel(v, (port)-membase + (off)) #define UART_PUT_CR(port, v)at_writel(v, port, ATMEL_US_CR) #define UART_PUT_MR(port, v)at_writel(v, port, ATMEL_US_MR) I'd like to point out this relatively recent change to CodingStyle. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dff4982f5cd4e30e2a140a3bca95d8814115bf5b So I don't see a reason for complicating the code by adding additional macro's just to fit it in 80 column's. Hmm...yes, I think that change to the CodingStyle makes sense. But I guess the question is whether the old code significantly increases readability and whether the new code hides information. I don't think so, but I don't feel all that strongly about it. I'd actually prefer if we used at_writel() and at_readl() throughout the code and killed those UART_PUT/UART_GET macros. Haavard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
The dmesg snippet with the patched kernel. This does not contain my patch. Linux version 2.6.24-rc5-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #2 SMP Thu Dec 13 15:38:25 IST 2007 Command line: root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3 vga=0x31a resume=/dev/sda2 splash=verbose showopts 1 BIOS-provided physical RAM map: BIOS-e820: - 0009cc00 (usable) BIOS-e820: 0009cc00 - 000a (reserved) BIOS-e820: 000cc000 - 0010 (reserved) BIOS-e820: 0010 - 7fff (usable) BIOS-e820: 7fff - 8000 (reserved) BIOS-e820: 8000 - cff0 (usable) BIOS-e820: cff0 - cff0a000 (ACPI data) BIOS-e820: cff0a000 - cff8 (ACPI NVS) BIOS-e820: cff8 - d000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) BIOS-e820: 0001 - 00023000 (usable) Entering add_active_range(0, 0, 156) 0 entries of 3200 used Entering add_active_range(0, 256, 524272) 1 entries of 3200 used Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used end_pfn_map = 2293760 DMI present. ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD ) ACPI: RSDT CFF064D5, 004C (r1 DELL PE_SC3604 DELL0) ACPI: FACP CFF09906, 0074 (r1 DELL PE_SC3604 DELLF4240) ACPI: DSDT CFF06521, 33E5 (r1 DELL PE_SC3604 MSFT 10E) ACPI: FACS CFF0AFC0, 0040 ACPI: TCPA CFF0997A, 0032 (r1 Phoeni x604 TL 0) ACPI: SLIC CFF099AC, 0176 (r1 DELL PE_SC3604 PTL 1) ACPI: SPCR CFF09B22, 0050 (r1 DELL PE_SC3604 PTL 1) ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1) ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW 604 AMD 1) ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604 LTP0) ACPI: HPET CFF09F42, 0038 (r1 PTLTD HPETTBL 604 LTP1) ACPI: APIC CFF09F7A, 005E (r1 PTLTD APIC604 LTP0) ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) SRAT: PXM 0 - APIC 0 - Node 0 SRAT: PXM 0 - APIC 1 - Node 0 SRAT: Node 0 PXM 0 0-a Entering add_active_range(0, 0, 156) 0 entries of 3200 used SRAT: Node 0 PXM 0 0-d000 Entering add_active_range(0, 0, 156) 1 entries of 3200 used Entering add_active_range(0, 256, 524272) 1 entries of 3200 used Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used SRAT: Node 0 PXM 0 0-23000 Entering add_active_range(0, 0, 156) 3 entries of 3200 used Entering add_active_range(0, 256, 524272) 3 entries of 3200 used Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used NUMA: Using 63 for the hash shift. Bootmem setup node 0 -00023000 Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 2293760 Movable zone start PFN for each node early_node_map[4] active PFN ranges 0:0 - 156 0: 256 - 524272 0: 524288 - 851712 0: 1048576 - 2293760 On node 0 totalpages: 2096780 DMA zone: 96 pages used for memmap DMA zone: 2540 pages reserved DMA zone: 1360 pages, LIFO batch:0 DMA32 zone: 24480 pages used for memmap DMA32 zone: 823120 pages, LIFO batch:31 Normal zone: 29184 pages used for memmap Normal zone: 1216000 pages, LIFO batch:31 Movable zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x8008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat ACPI: HPET id: 0x10de8201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information swsusp: Registered nosave memory region: 0009c000 - 0009d000 swsusp: Registered nosave memory region: 0009d000 - 000a swsusp: Registered nosave memory region: 000a - 000cc000 swsusp: Registered nosave memory region: 000cc000 - 0010 swsusp: Registered nosave memory region: 7fff - 8000 swsusp: Registered nosave memory region: cff0 - cff0a000 swsusp: Registered nosave memory region:
Re: [PATCH v2] atmel_serial: Clean up the code
On Tue, 18 Dec 2007 11:14:42 +0100 Remy Bohmer [EMAIL PROTECTED] wrote: Hello Haavard, Please note that I'm not trying to steal the show here -- I just want That did not even come to my mind at all... I am happy with everything that helps making this driver better. Good :) What shall we do first from here, splitup of the interrupt handler? Or DMA patch? I currently have the patches applied in the order you sent them, with my stuff wedged in between (thanks to git-rebase --interactive.) So I think it makes sense to do the interrupt handler splitup first, even though I personally care more about the DMA patch. Haavard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: unify extable_{32|64}.c
Introduce fixup_exception() on X86_64 and use it in kprobes to
eliminate an #ifdef.
Only X86_64 needs search_extable() due to a stepping bug.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
arch/x86/kernel/kprobes.c | 12 +
arch/x86/mm/Makefile_32 |2 +-
arch/x86/mm/Makefile_64 |2 +-
arch/x86/mm/extable.c | 62 +
arch/x86/mm/extable_32.c | 35 -
arch/x86/mm/extable_64.c | 34
6 files changed, 65 insertions(+), 82 deletions(-)
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 1a0d96d..045a45e 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -902,19 +902,9 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs,
int trapnr)
* In case the user-specified fault handler returned
* zero, try to fix up.
*/
-#ifdef CONFIG_X86_64
- {
- const struct exception_table_entry *fixup;
- fixup = search_exception_tables(regs-ip);
- if (fixup) {
- regs-ip = fixup-fixup;
- return 1;
- }
- }
-#else
if (fixup_exception(regs))
return 1;
-#endif
+
/*
* fixup routine could not handle it,
* Let do_page_fault() fix it.
diff --git a/arch/x86/mm/Makefile_32 b/arch/x86/mm/Makefile_32
index a01aca7..6a5e981 100644
--- a/arch/x86/mm/Makefile_32
+++ b/arch/x86/mm/Makefile_32
@@ -2,7 +2,7 @@
# Makefile for the linux i386-specific parts of the memory manager.
#
-obj-y := init_32.o pgtable_32.o fault_32.o ioremap_32.o extable_32.o
pageattr_32.o mmap.o
+obj-y := init_32.o pgtable_32.o fault_32.o ioremap_32.o extable.o
pageattr_32.o mmap.o
obj-$(CONFIG_NUMA) += discontig_32.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
diff --git a/arch/x86/mm/Makefile_64 b/arch/x86/mm/Makefile_64
index b5a7448..09c997f 100644
--- a/arch/x86/mm/Makefile_64
+++ b/arch/x86/mm/Makefile_64
@@ -2,7 +2,7 @@
# Makefile for the linux x86_64-specific parts of the memory manager.
#
-obj-y := init_64.o fault_64.o ioremap_64.o extable_64.o pageattr_64.o mmap.o
+obj-y := init_64.o fault_64.o ioremap_64.o extable.o pageattr_64.o mmap.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_NUMA) += numa_64.o
obj-$(CONFIG_K8_NUMA) += k8topology_64.o
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
new file mode 100644
index 000..7e8db53
--- /dev/null
+++ b/arch/x86/mm/extable.c
@@ -0,0 +1,62 @@
+#include linux/module.h
+#include linux/spinlock.h
+#include asm/uaccess.h
+
+
+int fixup_exception(struct pt_regs *regs)
+{
+ const struct exception_table_entry *fixup;
+
+#ifdef CONFIG_PNPBIOS
+ if (unlikely(SEGMENT_IS_PNP_CODE(regs-cs))) {
+ extern u32 pnp_bios_fault_eip, pnp_bios_fault_esp;
+ extern u32 pnp_bios_is_utter_crap;
+ pnp_bios_is_utter_crap = 1;
+ printk(KERN_CRIT PNPBIOS fault.. attempting recovery.\n);
+ __asm__ volatile(
+ movl %0, %%esp\n\t
+ jmp *%1\n\t
+ : : g (pnp_bios_fault_esp), g (pnp_bios_fault_eip));
+ panic(do_trap: can't hit this);
+ }
+#endif
+
+ fixup = search_exception_tables(regs-ip);
+ if (fixup) {
+ regs-ip = fixup-fixup;
+ return 1;
+ }
+
+ return 0;
+}
+
+#ifdef CONFIG_X86_64
+/*
+ * Need to defined our own search_extable on X86_64 to work around
+ * a B stepping K8 bug.
+ */
+const struct exception_table_entry *
+search_extable(const struct exception_table_entry *first,
+ const struct exception_table_entry *last,
+ unsigned long value)
+{
+ /* B stepping K8 bug */
+ if ((value 32) == 0)
+ value |= 0xUL 32;
+
+ while (first = last) {
+ const struct exception_table_entry *mid;
+ long diff;
+
+ mid = (last - first) / 2 + first;
+ diff = mid-insn - value;
+ if (diff == 0)
+ return mid;
+ else if (diff 0)
+ first = mid+1;
+ else
+ last = mid-1;
+ }
+ return NULL;
+}
+#endif
diff --git a/arch/x86/mm/extable_32.c b/arch/x86/mm/extable_32.c
deleted file mode 100644
index 4168546..000
--- a/arch/x86/mm/extable_32.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * linux/arch/i386/mm/extable.c
- */
-
-#include linux/module.h
-#include linux/spinlock.h
-#include asm/uaccess.h
-
-int fixup_exception(struct pt_regs *regs)
-{
- const struct exception_table_entry *fixup;
-
-#ifdef CONFIG_PNPBIOS
- if (unlikely(SEGMENT_IS_PNP_CODE(regs-cs)))
- {
-
Re: No dma_sync_* during pci_probe? (Sparc, post 2.6.22 regression)
[As pointed out elsewhere in the thread, this is indeed about sparc64,
not sparc per se.]
David Miller wrote:
From: Stefan Richter [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 00:53:03 +0100
The fault happens due to dma_sync_single_for_device() which
drivers/firewire/fw-ohci.c calls in ar_context_add_page() when still
being in its pci_probe method. I suspect that --- at least on Sparc and
after 2.6.22 --- it is not possible anymore to use dma_sync_* before the
pci_device's or device's probe was finished.
Would that be a bug in the Sparc platform code? Or a bug in driver core
code or in PCI code? Or am I expected to refrain from dma_sync_* calls
until after the probe returned?
The problem is likely what device struct you are passing to
dma_sync_single_for_device(), it has to be a real pci_dev or similar
that has it's dev_archdata properly initialized.
I bet dev_archdata in whatever struct device is being passed in has
a NULL iommu pointer or something like that.
Oh yeah, I see what you're doing, that won't work, please pass in
the correct device struct pointer. Please pass in the pci_dev-dev
not this ohci-card.device thing.
No, the dev argument is alright. We use it a few lines above in the
same function in a call to dma_map_single(). The dev argument is IMO
correctly obtained here:
static int
pci_probe(struct pci_dev *dev, const struct pci_device_id *ent)
{
...
fw_card_initialize(ohci-card, ohci_driver, dev-dev);
...
}
void
fw_card_initialize(struct fw_card *card, const struct fw_card_driver
*driver, struct device *device)
{
...
card-device = device;
...
}
So, ohci-card.device is in fact pci_dev-dev.
Also note:
- The very same code did not oops at this point in 2.6.22. It only
started doing so in 2.6.23.
- There has been no other report of this kind for any other
architecture yet. I would expect e.g. the PPC64 folks to report
bugs in our dma mappings eventually.
-
Two footnotes:
- Although the 2.6.22 firewire subsystem does not oops during the
pci_probe like it does in 2.6.23 and 2.6.24, it does lock up sometime
later during actual use. However this is not surprising, as I found and
fixed some portential DMA mapping issues in the fw-sbp2 highlevel driver
sometime after 2.6.22. But due to the pci_probe problem, the firewire
subsystem doesn't get as far on sparc64 on 2.6.23 and 2.6.24.
- One thing which we do slightly wrong in ar_context_add_page() is that we
1.) dma-map the buffer,
2.) continue to write into the buffer from the CPU,
3.) then sync it for the device.
I let the reporter try a patch which inserted a
dma_sync_single_for_cpu() right after the dma_map_single() in order to
be clearly entitled to access the buffer by the CPU, but that didn't fix it.
--
Stefan Richter
-=-=-=== ==-- =--=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: dynamically update the root-domain span/online maps
* Gregory Haskins [EMAIL PROTECTED] wrote: http://marc.info/?l=linux-mm-commitsm=119793598429477w=2 I have confirmed that it builds and boots clean, and it passes checkpatch. However, my test machine seems to be having problems with suspend-to-ram that are unrelated to this patch that prevent me from verifying the fix entirely. If Gautham or Andrew could confirm that it resolves their suspend-to-ram issue, I would be most appreciative. i'm reluctant to apply it without test results, unless we have a very clear picture of what happened on Andrew's box and how this updated patch resolves that problem. (or once Andrew tests your patch and deems it OK.) Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: unify extable_{32|64}.c
* Harvey Harrison [EMAIL PROTECTED] wrote: Introduce fixup_exception() on X86_64 and use it in kprobes to eliminate an #ifdef. Only X86_64 needs search_extable() due to a stepping bug. thanks, applied. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: dynamically update the root-domain span/online maps
* Gregory Haskins [EMAIL PROTECTED] wrote: Hi Steven, I posted a suspend-to-ram fix to sched-devel earlier today: http://lkml.org/lkml/2007/12/17/445 This fix should also be applied to -rt as I introduced the same regression there. Here is a version of the fix for 23-rt13. I can submit a version for 24-rc5-rt1 at your request. well since i reverted the original patch, there's no regression. The question is, do we know whether this new patch works fine wrt. s2ram? Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: Use helper in fault_64.c
Use the fixup_exception() helper in fault_64.c
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
This is only appropriate if CONFIG_PNP_BIOS cannot be set on
X86_64, which looks to be the case, but needs confirmation.
arch/x86/mm/fault_64.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/fault_64.c b/arch/x86/mm/fault_64.c
index 121c7bd..3a94941 100644
--- a/arch/x86/mm/fault_64.c
+++ b/arch/x86/mm/fault_64.c
@@ -298,7 +298,6 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs
*regs,
struct mm_struct *mm;
struct vm_area_struct * vma;
unsigned long address;
- const struct exception_table_entry *fixup;
int write, fault;
unsigned long flags;
siginfo_t info;
@@ -508,9 +507,7 @@ bad_area_nosemaphore:
no_context:
/* Are we prepared to handle this kernel fault? */
- fixup = search_exception_tables(regs-ip);
- if (fixup) {
- regs-ip = fixup-fixup;
+ if (fixup_exception(regs)) {
return;
}
--
1.5.4.rc0.1143.g1a8a
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: swapping in 2.6.24-rc5-git3
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote: I think yes. 0 swappiness doesn't mean no swapping at all. From the code in shrink_active_list() it seems that it just decreases likeliness of removing pages of mmaped files (i.e., also executables loaded in memory). So, I tried to add some prints. I have mapped ratio about 78 while scp-ing the file. Distress suddenly raises from 0 to 100. At this poing, all the processes are swapped out. I guess it happens if scp is faster than the local disk which happens if I scp-ing over GE from desktop (with fast disk - and reading) to laptop (slow disk - and writing). This is my settings. /proc/sys/vm/* block_dump:0 dirty_background_ratio:10 dirty_expire_centisecs:2999 dirty_ratio:40 dirty_writeback_centisecs:499 drop_caches:0 laptop_mode:0 legacy_va_layout:0 lowmem_reserve_ratio:256256 32 max_map_count:65536 min_free_kbytes:4006 nr_pdflush_threads:2 oom_kill_allocating_task:0 overcommit_memory:0 overcommit_ratio:50 page-cluster:3 panic_on_oom:0 percpu_pagelist_fraction:0 stat_interval:1 swappiness:0 vfs_cache_pressure:100 -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] initrd: Fix virtual/physical mix-up in overwrite test
On Sun, 16 Dec 2007 11:51:00 +0100 (CET) Geert Uytterhoeven [EMAIL PROTECTED] wrote: On recent kernels, I get the following error when using an initrd: | initrd overwritten (0x00b78000 0x07668000) - disabling it. My Amiga 4000 has 12 MiB of RAM at physical address 0x0740 (virtual 0x). The initrd is located at the end of RAM: 0x00b78000 - 0x00c0 (virtual). The overwrite test compares the (virtual) initrd location to the (physical) first available memory location, which fails. This patch converts initrd_start to a page frame number, so it can be safely compared with min_low_pfn. Before the introduction of discontiguous memory support on m68k (12d810c1b8c2b913d48e629e2b5c01d105029839), min_low_pfn was just left untouched by the m68k-specific code (zero, I guess), and everything worked fine. breaks x86. init/main.c: In function 'start_kernel': init/main.c:601: error: implicit declaration of function 'virt_to_pfn' init/main.c:603: warning: format '%08lx' expects type 'long unsigned int', but argument 2 has type 'int' -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/4] DST: Distributed storage.
Hi David. On Tue, Dec 18, 2007 at 12:00:04PM +1100, David Chinner ([EMAIL PROTECTED]) wrote: On Mon, Dec 17, 2007 at 06:03:38PM +0300, Evgeniy Polyakov wrote: DST passed all FS tests in LTP with XFS (modulo MAX_LOCK_DEPTH too low bug: [ 8398.605691] BUG: MAX_LOCK_DEPTH too low! [ 8398.609641] turning off the locking correctness validator. Evgeniy, can you please start reporting these XFS problems you are coming across to the XFS list ([EMAIL PROTECTED])? They may be real issues that we need to address and we should not be hearing about them for the first time in the release notes for a block device project It is not XFS as is, but lock validator warning. I just found it working with XFS - it can be anything else: VFS, block layer, DST itself (there is number of locks too), so I did not fill the bug against filesystem, but pointed that some problem, probalby harmless, exists in tested environment. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Use helper in fault_64.c
* Harvey Harrison [EMAIL PROTECTED] wrote: Use the fixup_exception() helper in fault_64.c thanks, applied. This is only appropriate if CONFIG_PNP_BIOS cannot be set on X86_64, which looks to be the case, but needs confirmation. yeah, that seems to be the case: in drivers/pnp/pnpbios/Kconfig: config PNPBIOS ... depends on ISA X86 EXPERIMENTAL in arch/x86/Kconfig: if X86_32 config ISA it seems the PNPBIOS has not infested the 64-bit world, so we wont ever see this with a 64-bit kernel: extern u32 pnp_bios_is_utter_crap; pnp_bios_is_utter_crap = 1; printk(KERN_CRIT PNPBIOS fault.. attempting recovery.\n); Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Use helper in fault_64.c
On Tue, 2007-12-18 at 12:19 +0100, Ingo Molnar wrote: * Harvey Harrison [EMAIL PROTECTED] wrote: Use the fixup_exception() helper in fault_64.c thanks, applied. This is only appropriate if CONFIG_PNP_BIOS cannot be set on X86_64, which looks to be the case, but needs confirmation. yeah, that seems to be the case: in drivers/pnp/pnpbios/Kconfig: config PNPBIOS ... depends on ISA X86 EXPERIMENTAL in arch/x86/Kconfig: if X86_32 config ISA That's how I read it, just wanted a second opinion. Harvey -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Important regression with XFS update for 2.6.24-rc6
Hello, As a follow-up to http://marc.info/?l=linux-kernelm=119796120524618w=2 (LKML seems down right now so I am not linking to it), I have detected an important problem with these two patches: after applying them by hand (downloaded them raw from SGI's gitweb) on top of 2.6.24-rc5-git5 (they have not yet been pulled into mainline by Linux as of this morning) for testing purposes, I noticed upon reboot that ls -l on directories with many files and subdirectories (around 5000 entries) takes several hundreds of MB in RAM and then dies with memory exhausted error. I also noticed that ldconfig takes a lot of time to complete, and firefox seems also to eat much more memory than usual. Reverting the two patches (going back to vanilla rc5-git5) makes these problems go away. I am not able to test right now if only one of the patches is bogus or if both of them are concerned. As the symptoms are easy to reproduce, I guess this is some kind of brown paper bag bug and will be easy for XFS experts to spot. Best, -- Damien Wyart -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: dynamically update the root-domain span/online maps
On Tue, 18 Dec 2007 11:48:00 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: * Gregory Haskins [EMAIL PROTECTED] wrote: http://marc.info/?l=linux-mm-commitsm=119793598429477w=2 I have confirmed that it builds and boots clean, and it passes checkpatch. However, my test machine seems to be having problems with suspend-to-ram that are unrelated to this patch that prevent me from verifying the fix entirely. If Gautham or Andrew could confirm that it resolves their suspend-to-ram issue, I would be most appreciative. i'm reluctant to apply it without test results, unless we have a very clear picture of what happened on Andrew's box and how this updated patch resolves that problem. (or once Andrew tests your patch and deems it OK.) wades through a pile of new compile errors tests it Seems OK now - resume-from-RAM actually resumes. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] x86: add kprobe-booster to X86_64
* Harvey Harrison [EMAIL PROTECTED] wrote: Sorry I missed an ifdef in this patch in the following hunk: could you resend your kprobes cleanups against current x86.git? They have been conceptually acked by Masami. This cuts out the unification part of your queue which is bad luck but the effort has been duplicated already so there's not much we can do about it i guess. Your other 17 cleanup and unification patches are still queued up in x86.git and passed a lot of testing, so they will likely go into v2.6.25. Nice work! Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: dynamically update the root-domain span/online maps
Ingo Molnar wrote: well since i reverted the original patch, there's no regression. The question is, do we know whether this new patch works fine wrt. s2ram? Hi Ingo, I included the same patches into 2.6.23.9-rt13 and someone reported s2r failed for them. I've included Greg's updates into a pre release of -rt14 and sent that to the reporter. I'm waiting on a response before releasing -rt14. Although I did just get a response from Andrew Morton saying that the updated patch fixed his box. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] x86: add kprobe-booster to X86_64
On Tue, 2007-12-18 at 12:29 +0100, Ingo Molnar wrote:
* Harvey Harrison [EMAIL PROTECTED] wrote:
Sorry I missed an ifdef in this patch in the following hunk:
could you resend your kprobes cleanups against current x86.git? They
have been conceptually acked by Masami. This cuts out the unification
part of your queue which is bad luck but the effort has been duplicated
already so there's not much we can do about it i guess.
Your other 17 cleanup and unification patches are still queued up in
x86.git and passed a lot of testing, so they will likely go into
v2.6.25. Nice work!
Ingo
Ingo,
I'd suggest just tossing my kprobes cleanups. I just sent you a rollup
of anything I saw that was left in mine that was still worthwhile
after Masami's, included below for reference. It didn't amount to much
left so I rolled it all together:
Subject: [PATCH] x86: kprobes leftover cleanups
Eliminate __always_inline, all of these static functions are
only called once. Minor whitespace cleanup. Eliminate one
supefluous return at end of void function. Reverse sense of
#ifndef to be #ifdef to show the case only affects X86_32.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
arch/x86/kernel/kprobes.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 9aadd4d..1a0d96d 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -159,7 +159,7 @@ struct kretprobe_blackpoint kretprobe_blacklist[] = {
const int kretprobe_blacklist_size = ARRAY_SIZE(kretprobe_blacklist);
/* Insert a jump instruction at address 'from', which jumps to address 'to'.*/
-static __always_inline void set_jmp_op(void *from, void *to)
+static void set_jmp_op(void *from, void *to)
{
struct __arch_jmp_op {
char op;
@@ -174,7 +174,7 @@ static __always_inline void set_jmp_op(void *from, void *to)
* Returns non-zero if opcode is boostable.
* RIP relative instructions are adjusted at copying time in 64 bits mode
*/
-static __always_inline int can_boost(kprobe_opcode_t *opcodes)
+static int can_boost(kprobe_opcode_t *opcodes)
{
kprobe_opcode_t opcode;
kprobe_opcode_t *orig_opcodes = opcodes;
@@ -392,13 +392,13 @@ static void __kprobes set_current_kprobe(struct kprobe
*p, struct pt_regs *regs,
kcb-kprobe_saved_flags = ~IF_MASK;
}
-static __always_inline void clear_btf(void)
+static void clear_btf(void)
{
if (test_thread_flag(TIF_DEBUGCTLMSR))
wrmsr(MSR_IA32_DEBUGCTLMSR, 0, 0);
}
-static __always_inline void restore_btf(void)
+static void restore_btf(void)
{
if (test_thread_flag(TIF_DEBUGCTLMSR))
wrmsr(MSR_IA32_DEBUGCTLMSR, current-thread.debugctlmsr, 0);
@@ -409,7 +409,7 @@ static void __kprobes prepare_singlestep(struct kprobe *p,
struct pt_regs *regs)
clear_btf();
regs-flags |= TF_MASK;
regs-flags = ~IF_MASK;
- /*single step inline if the instruction is an int3*/
+ /* single step inline if the instruction is an int3 */
if (p-opcode == BREAKPOINT_INSTRUCTION)
regs-ip = (unsigned long)p-addr;
else
@@ -767,7 +767,7 @@ static void __kprobes resume_execution(struct kprobe *p,
case 0xe8: /* call relative - Fix return addr */
*tos = orig_ip + (*tos - copy_ip);
break;
-#ifndef CONFIG_X86_64
+#ifdef CONFIG_X86_32
case 0x9a: /* call absolute -- same as call absolute, indirect */
*tos = orig_ip + (*tos - copy_ip);
goto no_change;
@@ -813,8 +813,6 @@ static void __kprobes resume_execution(struct kprobe *p,
no_change:
restore_btf();
-
- return;
}
/*
--
1.5.4.rc0.1143.g1a8a
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/21] [PATCH] unify common parts of processor.h
* Glauber de Oliveira Costa [EMAIL PROTECTED] wrote: This patch moves the pieces of processor_32.h and processor_64 that are equal to processor.h. Only what's exactly the same is moved around, the rest not being touched. argh, it doesnt even build cleanly: In file included from include/linux/elf.h:6, from include/linux/module.h:14, from include/linux/crypto.h:21, from arch/x86/kernel/asm-offsets_32.c:7, from arch/x86/kernel/asm-offsets.c:2: include/asm/elf.h:286: warning: 'struct mm_struct' declared inside parameter list include/asm/elf.h:286: warning: its scope is only this definition or declaration, which is probably not what you want due to zapping this bit of include/asm-x86/processor_32.h: -/* Forward declaration, a strange C thing */ -struct task_struct; -struct mm_struct; Ingo # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc5 # Tue Dec 18 12:27:00 2007 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_SUPPORTS_OPROFILE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set # CONFIG_TASK_XACCT is not set CONFIG_USER_NS=y CONFIG_PID_NS=y # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=20 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=m # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED=noop # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y # CONFIG_X86_PC is not set # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set CONFIG_X86_GENERICARCH=y # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set CONFIG_X86_CYCLONE_TIMER=y # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set #
Re: [PATCH 0/9] mmap read-around and readahead
On Sun, Dec 16, 2007 at 03:35:58PM -0800, Linus Torvalds wrote: On Sun, 16 Dec 2007, Fengguang Wu wrote: Here are the mmap read-around related patches initiated by Linus. They are for linux-2.6.24-rc4-mm1. The one major new feature - auto detection and early readahead for mmap sequential reads - runs as expected on my desktop :-) Just out of interest - did you check to see if it makes any difference to any IO patterns (or even timings)? No timings for now... but I wrote a debug patch(attached) and watched it running for about a week. Here are some interesting numbers: % grep .so, /var/log/kern.log|grep init0|wc 4085 60806 583895 % grep .so, /var/log/kern.log|grep around|wc 14438 215265 2107308 % grep .so, /var/log/kern.log|grep around|grep '= 32' | wc 3133 46757 462446 % grep .so, /var/log/kern.log|grep interleaved|wc 997 14866 148921 % grep .so, /var/log/kern.log|grep interleaved|grep '= 0'|wc 5448089 79661 % grep .so, /var/log/kern.log|grep interleaved|grep '= 32'|wc 1792683 28233 % grep .so, /var/log/kern.log|grep sequential|wc 3499 52275 541319 % grep .so, /var/log/kern.log|grep sequential|grep '= 0' | wc 915 13598 131953 % grep .so, /var/log/kern.log|grep sequential|grep '= 32' | wc 1327 19880 212896 That says, there are 4085 page faults on start-of-lib-file, 14438 mmap read-around, 22% full ra size 3499 mmap async readahead, 38% full ra size, or 51% if removing pure cache hits 997 mmap sync readahead,18% full ra size, or 40% if removing pure cache hits That's good numbers: I/O sizes get larger, and possibly less I/O waits :-) Sure it's rather coarse estimation, but there are some sequential mmap accesses. E.g. [11736.998347] readahead-init0(process: sh/23926, file: sda1/w3m, offset=0:-1, ra=0+4-3) = 4 [11737.014985] readahead-around(process: w3m/23926, file: sda1/w3m, offset=0:0, ra=290+32-0) = 17 [11737.019488] readahead-around(process: w3m/23926, file: sda1/w3m, offset=0:0, ra=118+32-0) = 32 [11737.024921] readahead-interleaved(process: w3m/23926, file: sda1/w3m, offset=0:2, ra=4+6-6) = 6 [11737.025726] readahead-sequential(process: w3m/23926, file: sda1/w3m, offset=0:3, ra=10+12-12) = 12 [11737.025794] readahead-around(process: w3m/23926, file: sda1/w3m, offset=0:4, ra=90+32-0) = 28 --- sequential begin --- [11737.037893] readahead-init(process: w3m/23926, file: sda1/w3m, offset=0:149, ra=150+64-32) = 64 [11737.043928] readahead-sequential(process: w3m/23926, file: sda1/w3m, offset=0:181, ra=214+32-32) = 32 [11737.044086] readahead-sequential(process: w3m/23926, file: sda1/w3m, offset=0:213, ra=246+32-32) = 32 [11737.045633] readahead-sequential(process: w3m/23926, file: sda1/w3m, offset=0:245, ra=278+32-32) = 12 [11737.047321] readahead-sequential(process: w3m/23926, file: sda1/w3m, offset=0:277, ra=310+32-32) = 0 --- sequential end --- [11737.048296] readahead-around(process: w3m/23926, file: sda1/w3m, offset=0:119, ra=48+32-0) = 32 [11737.066908] readahead-around(process: w3m/23926, file: sda1/w3m, offset=0:63, ra=73+32-0) = 10 [11737.136880] readahead-around(process: w3m/23926, file: sda1/w3m, offset=0:116, ra=30+32-0) = 18 [11737.166005] readahead-around(process: w3m/23926, file: sda1/w3m, offset=0:37, ra=6+32-0) = 8 But also there is one minor problem. [16416.600720] readahead-init0(process: zsh/30490, file: sda1/bc, offset=0:-1, ra=0+4-3) = 4 [16416.607967] readahead-around(process: bc/30490, file: sda1/bc, offset=0:0, ra=1+32-0) = 14 The 4-page readahead-init0() hurts performance. It occurs before every initial mmap reads. A longer example: wfg ~% dmesg|grep mplayer [ 1221.454230] readahead-init0(process: mutt/7131, file: md0/mplayer-devel, offset=0:-1, ra=0+4-3) = 4 [ 1378.667305] readahead-init0(process: strace/7352, file: sda1/mplayer, offset=0:-1, ra=0+4-3) = 4 [ 1378.692389] readahead-around(process: mplayer/7352, file: sda1/mplayer, offset=0:0, ra=2212+32-0) = 17 [ 1378.703656] readahead-around(process: mplayer/7352, file: sda1/mplayer, offset=0:0, ra=2061+32-0) = 32 [ 1378.715537] readahead-around(process: mplayer/7352, file: sda1/mplayer, offset=0:2077, ra=0+32-0) = 28 [ 1378.716261] readahead-around(process: mplayer/7352, file: sda1/mplayer, offset=0:10, ra=44+32-0) = 32 [ 1378.727570] readahead-init0(process: mplayer/7352, file: sda1/libdirectfb-0.9.so.25.0.0, offset=0:-1, ra=0+4-3) = 4 [ 1378.740579] readahead-around(process: mplayer/7352, file: sda1/libdirectfb-0.9.so.25.0.0, offset=0:0, ra=79+32-0) = 17 [ 1378.744826] readahead-around(process: mplayer/7352, file: sda1/libdirectfb-0.9.so.25.0.0, offset=0:1, ra=0+32-0) = 28 [ 1378.749882] readahead-init0(process: mplayer/7352, file: sda1/libXv.so.1.0.0, offset=0:-1, ra=0+4-3) = 4 [ 1378.754546] readahead-around(process: mplayer/7352, file: sda1/libXv.so.1.0.0, offset=0:0, ra=0+32-0) = 1 [ 1378.758057] readahead-init0(process: mplayer/7352, file:
Re: [PATCH 2/9] readahead: clean up and simplify the code for filemap page fault readahead
On Tue, Dec 18, 2007 at 09:19:07AM +0100, Nick Piggin wrote:
On Sun, Dec 16, 2007 at 07:59:30PM +0800, Fengguang Wu wrote:
+ read_lock_irq(mapping-tree_lock);
+ page = radix_tree_lookup(mapping-page_tree, offset);
+ if (likely(page)) {
+ int got_lock, uptodate;
+ page_cache_get(page);
+
+ got_lock = !TestSetPageLocked(page);
+ uptodate = PageUptodate(page);
+ read_unlock_irq(mapping-tree_lock);
If we could avoid open coding tree_lock here (and expanding its coverage
to PageUptodate), that would be nice. I don't think it gains us too much.
To use find_get_page()? That would be nice to me, too.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: Atmel Serial Console interrupt handler splitup
Hello Haavard, I don't think so, but I don't feel all that strongly about it. I'd actually prefer if we used at_writel() and at_readl() throughout the code and killed those UART_PUT/UART_GET macros. I completely agree. Kind Regards, Remy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: unify module_{32|64}.h
This adds one case to the MODULE_PROC_FAMILY block testing
for X86_64. There are no new things defined on X86_64 than
there were before.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
include/asm-x86/module.h| 83 +-
include/asm-x86/module_32.h | 75 --
include/asm-x86/module_64.h | 10 -
3 files changed, 81 insertions(+), 87 deletions(-)
diff --git a/include/asm-x86/module.h b/include/asm-x86/module.h
index 2b2f18d..994837c 100644
--- a/include/asm-x86/module.h
+++ b/include/asm-x86/module.h
@@ -1,5 +1,84 @@
+#ifndef _ASM_MODULE_H
+#define _ASM_MODULE_H
+
+/* x86_32/64 are simple */
+struct mod_arch_specific
+{
+};
+
#ifdef CONFIG_X86_32
-# include module_32.h
+# define Elf_Shdr Elf32_Shdr
+# define Elf_Sym Elf32_Sym
+# define Elf_Ehdr Elf32_Ehdr
#else
-# include module_64.h
+# define Elf_Shdr Elf64_Shdr
+# define Elf_Sym Elf64_Sym
+# define Elf_Ehdr Elf64_Ehdr
#endif
+
+#ifdef CONFIG_X86_64
+/* X86_64 does not define MODULE_PROC_FAMILY */
+#elif defined CONFIG_M386
+#define MODULE_PROC_FAMILY 386
+#elif defined CONFIG_M486
+#define MODULE_PROC_FAMILY 486
+#elif defined CONFIG_M586
+#define MODULE_PROC_FAMILY 586
+#elif defined CONFIG_M586TSC
+#define MODULE_PROC_FAMILY 586TSC
+#elif defined CONFIG_M586MMX
+#define MODULE_PROC_FAMILY 586MMX
+#elif defined CONFIG_MCORE2
+#define MODULE_PROC_FAMILY CORE2
+#elif defined CONFIG_M686
+#define MODULE_PROC_FAMILY 686
+#elif defined CONFIG_MPENTIUMII
+#define MODULE_PROC_FAMILY PENTIUMII
+#elif defined CONFIG_MPENTIUMIII
+#define MODULE_PROC_FAMILY PENTIUMIII
+#elif defined CONFIG_MPENTIUMM
+#define MODULE_PROC_FAMILY PENTIUMM
+#elif defined CONFIG_MPENTIUM4
+#define MODULE_PROC_FAMILY PENTIUM4
+#elif defined CONFIG_MK6
+#define MODULE_PROC_FAMILY K6
+#elif defined CONFIG_MK7
+#define MODULE_PROC_FAMILY K7
+#elif defined CONFIG_MK8
+#define MODULE_PROC_FAMILY K8
+#elif defined CONFIG_X86_ELAN
+#define MODULE_PROC_FAMILY ELAN
+#elif defined CONFIG_MCRUSOE
+#define MODULE_PROC_FAMILY CRUSOE
+#elif defined CONFIG_MEFFICEON
+#define MODULE_PROC_FAMILY EFFICEON
+#elif defined CONFIG_MWINCHIPC6
+#define MODULE_PROC_FAMILY WINCHIPC6
+#elif defined CONFIG_MWINCHIP2
+#define MODULE_PROC_FAMILY WINCHIP2
+#elif defined CONFIG_MWINCHIP3D
+#define MODULE_PROC_FAMILY WINCHIP3D
+#elif defined CONFIG_MCYRIXIII
+#define MODULE_PROC_FAMILY CYRIXIII
+#elif defined CONFIG_MVIAC3_2
+#define MODULE_PROC_FAMILY VIAC3-2
+#elif defined CONFIG_MVIAC7
+#define MODULE_PROC_FAMILY VIAC7
+#elif defined CONFIG_MGEODEGX1
+#define MODULE_PROC_FAMILY GEODEGX1
+#elif defined CONFIG_MGEODE_LX
+#define MODULE_PROC_FAMILY GEODE
+#else
+#error unknown processor family
+#endif
+
+#ifdef CONFIG_X86_32
+# ifdef CONFIG_4KSTACKS
+# define MODULE_STACKSIZE 4KSTACKS
+# else
+# define MODULE_STACKSIZE
+# endif
+# define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_STACKSIZE
+#endif
+
+#endif /* _ASM_MODULE_H */
diff --git a/include/asm-x86/module_32.h b/include/asm-x86/module_32.h
deleted file mode 100644
index 7e5fda6..000
--- a/include/asm-x86/module_32.h
+++ /dev/null
@@ -1,75 +0,0 @@
-#ifndef _ASM_I386_MODULE_H
-#define _ASM_I386_MODULE_H
-
-/* x86 is simple */
-struct mod_arch_specific
-{
-};
-
-#define Elf_Shdr Elf32_Shdr
-#define Elf_Sym Elf32_Sym
-#define Elf_Ehdr Elf32_Ehdr
-
-#ifdef CONFIG_M386
-#define MODULE_PROC_FAMILY 386
-#elif defined CONFIG_M486
-#define MODULE_PROC_FAMILY 486
-#elif defined CONFIG_M586
-#define MODULE_PROC_FAMILY 586
-#elif defined CONFIG_M586TSC
-#define MODULE_PROC_FAMILY 586TSC
-#elif defined CONFIG_M586MMX
-#define MODULE_PROC_FAMILY 586MMX
-#elif defined CONFIG_MCORE2
-#define MODULE_PROC_FAMILY CORE2
-#elif defined CONFIG_M686
-#define MODULE_PROC_FAMILY 686
-#elif defined CONFIG_MPENTIUMII
-#define MODULE_PROC_FAMILY PENTIUMII
-#elif defined CONFIG_MPENTIUMIII
-#define MODULE_PROC_FAMILY PENTIUMIII
-#elif defined CONFIG_MPENTIUMM
-#define MODULE_PROC_FAMILY PENTIUMM
-#elif defined CONFIG_MPENTIUM4
-#define MODULE_PROC_FAMILY PENTIUM4
-#elif defined CONFIG_MK6
-#define MODULE_PROC_FAMILY K6
-#elif defined CONFIG_MK7
-#define MODULE_PROC_FAMILY K7
-#elif defined CONFIG_MK8
-#define MODULE_PROC_FAMILY K8
-#elif defined CONFIG_X86_ELAN
-#define MODULE_PROC_FAMILY ELAN
-#elif defined CONFIG_MCRUSOE
-#define MODULE_PROC_FAMILY CRUSOE
-#elif defined CONFIG_MEFFICEON
-#define MODULE_PROC_FAMILY EFFICEON
-#elif defined CONFIG_MWINCHIPC6
-#define MODULE_PROC_FAMILY WINCHIPC6
-#elif defined CONFIG_MWINCHIP2
-#define MODULE_PROC_FAMILY WINCHIP2
-#elif defined CONFIG_MWINCHIP3D
-#define MODULE_PROC_FAMILY WINCHIP3D
-#elif defined CONFIG_MCYRIXIII
-#define MODULE_PROC_FAMILY CYRIXIII
-#elif defined CONFIG_MVIAC3_2
-#define MODULE_PROC_FAMILY VIAC3-2
-#elif defined CONFIG_MVIAC7
-#define MODULE_PROC_FAMILY VIAC7
-#elif defined CONFIG_MGEODEGX1
-#define MODULE_PROC_FAMILY GEODEGX1
-#elif defined CONFIG_MGEODE_LX
-#define
Re: [PATCH 3/21] [PATCH] move desc_empty to where they belong
Rusty Russell wrote:
On Tuesday 18 December 2007 09:52:26 Glauber de Oliveira Costa wrote:
+static inline int desc_empty(const void *ptr)
+{
+ const u32 *desc = ptr;
+ return !(desc[0] | desc[1]);
+}
Erk. This really needs to be a union, not a void *. I guess we can clean it
later.
Rusty.
My last series, that unified desc_struct, made it possible to do that.
However, the intent of this, is just move it to a common place.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix crash with FLAT_MEMORY and ARCH_PFN_OFFSET != 0
When using FLAT_MEMORY and ARCH_PFN_OFFSET is not 0, the kernel crashes in memmap_init_zone(). This bug got introduced by commit c713216deebd95d2b0ab38fef8bb2361c0180c2d Signed-off-by: Thomas Bogendoerfer [EMAIL PROTECTED] --- mm/page_alloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b5a58d4..496f7f3 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3427,7 +3427,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat) mem_map = NODE_DATA(0)-node_mem_map; #ifdef CONFIG_ARCH_POPULATES_NODE_MAP if (page_to_pfn(mem_map) != pgdat-node_start_pfn) - mem_map -= pgdat-node_start_pfn; + mem_map -= (pgdat-node_start_pfn - ARCH_PFN_OFFSET); #endif /* CONFIG_ARCH_POPULATES_NODE_MAP */ } #endif -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/21] [PATCH] unify common parts of processor.h
Ingo Molnar wrote: * Glauber de Oliveira Costa [EMAIL PROTECTED] wrote: This patch moves the pieces of processor_32.h and processor_64 that are equal to processor.h. Only what's exactly the same is moved around, the rest not being touched. argh, it doesnt even build cleanly: In file included from include/linux/elf.h:6, from include/linux/module.h:14, from include/linux/crypto.h:21, from arch/x86/kernel/asm-offsets_32.c:7, from arch/x86/kernel/asm-offsets.c:2: include/asm/elf.h:286: warning: 'struct mm_struct' declared inside parameter list include/asm/elf.h:286: warning: its scope is only this definition or declaration, which is probably not what you want due to zapping this bit of include/asm-x86/processor_32.h: -/* Forward declaration, a strange C thing */ -struct task_struct; -struct mm_struct; Ingo I'll test it with your config, and repost. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] x86: unify module_{32|64}.h
From 5be3fc6a0e28d82a05487a8fb1a86532fb0ad4e8 Mon Sep 17 00:00:00 2001
From: Harvey Harrison [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 03:58:10 -0800
Subject: [PATCH] x86: unify module_{32|64}.h
This adds one case to the MODULE_PROC_FAMILY block testing
for X86_64. There are no new things defined on X86_64 than
there were before.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Ingo, let a single checkpatch warning go by in the first one,
fixed in this version.
include/asm-x86/module.h| 81 +-
include/asm-x86/module_32.h | 75 ---
include/asm-x86/module_64.h | 10 -
3 files changed, 79 insertions(+), 87 deletions(-)
diff --git a/include/asm-x86/module.h b/include/asm-x86/module.h
index 2b2f18d..bfedb24 100644
--- a/include/asm-x86/module.h
+++ b/include/asm-x86/module.h
@@ -1,5 +1,82 @@
+#ifndef _ASM_MODULE_H
+#define _ASM_MODULE_H
+
+/* x86_32/64 are simple */
+struct mod_arch_specific {};
+
#ifdef CONFIG_X86_32
-# include module_32.h
+# define Elf_Shdr Elf32_Shdr
+# define Elf_Sym Elf32_Sym
+# define Elf_Ehdr Elf32_Ehdr
#else
-# include module_64.h
+# define Elf_Shdr Elf64_Shdr
+# define Elf_Sym Elf64_Sym
+# define Elf_Ehdr Elf64_Ehdr
#endif
+
+#ifdef CONFIG_X86_64
+/* X86_64 does not define MODULE_PROC_FAMILY */
+#elif defined CONFIG_M386
+#define MODULE_PROC_FAMILY 386
+#elif defined CONFIG_M486
+#define MODULE_PROC_FAMILY 486
+#elif defined CONFIG_M586
+#define MODULE_PROC_FAMILY 586
+#elif defined CONFIG_M586TSC
+#define MODULE_PROC_FAMILY 586TSC
+#elif defined CONFIG_M586MMX
+#define MODULE_PROC_FAMILY 586MMX
+#elif defined CONFIG_MCORE2
+#define MODULE_PROC_FAMILY CORE2
+#elif defined CONFIG_M686
+#define MODULE_PROC_FAMILY 686
+#elif defined CONFIG_MPENTIUMII
+#define MODULE_PROC_FAMILY PENTIUMII
+#elif defined CONFIG_MPENTIUMIII
+#define MODULE_PROC_FAMILY PENTIUMIII
+#elif defined CONFIG_MPENTIUMM
+#define MODULE_PROC_FAMILY PENTIUMM
+#elif defined CONFIG_MPENTIUM4
+#define MODULE_PROC_FAMILY PENTIUM4
+#elif defined CONFIG_MK6
+#define MODULE_PROC_FAMILY K6
+#elif defined CONFIG_MK7
+#define MODULE_PROC_FAMILY K7
+#elif defined CONFIG_MK8
+#define MODULE_PROC_FAMILY K8
+#elif defined CONFIG_X86_ELAN
+#define MODULE_PROC_FAMILY ELAN
+#elif defined CONFIG_MCRUSOE
+#define MODULE_PROC_FAMILY CRUSOE
+#elif defined CONFIG_MEFFICEON
+#define MODULE_PROC_FAMILY EFFICEON
+#elif defined CONFIG_MWINCHIPC6
+#define MODULE_PROC_FAMILY WINCHIPC6
+#elif defined CONFIG_MWINCHIP2
+#define MODULE_PROC_FAMILY WINCHIP2
+#elif defined CONFIG_MWINCHIP3D
+#define MODULE_PROC_FAMILY WINCHIP3D
+#elif defined CONFIG_MCYRIXIII
+#define MODULE_PROC_FAMILY CYRIXIII
+#elif defined CONFIG_MVIAC3_2
+#define MODULE_PROC_FAMILY VIAC3-2
+#elif defined CONFIG_MVIAC7
+#define MODULE_PROC_FAMILY VIAC7
+#elif defined CONFIG_MGEODEGX1
+#define MODULE_PROC_FAMILY GEODEGX1
+#elif defined CONFIG_MGEODE_LX
+#define MODULE_PROC_FAMILY GEODE
+#else
+#error unknown processor family
+#endif
+
+#ifdef CONFIG_X86_32
+# ifdef CONFIG_4KSTACKS
+# define MODULE_STACKSIZE 4KSTACKS
+# else
+# define MODULE_STACKSIZE
+# endif
+# define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_STACKSIZE
+#endif
+
+#endif /* _ASM_MODULE_H */
diff --git a/include/asm-x86/module_32.h b/include/asm-x86/module_32.h
deleted file mode 100644
index 7e5fda6..000
--- a/include/asm-x86/module_32.h
+++ /dev/null
@@ -1,75 +0,0 @@
-#ifndef _ASM_I386_MODULE_H
-#define _ASM_I386_MODULE_H
-
-/* x86 is simple */
-struct mod_arch_specific
-{
-};
-
-#define Elf_Shdr Elf32_Shdr
-#define Elf_Sym Elf32_Sym
-#define Elf_Ehdr Elf32_Ehdr
-
-#ifdef CONFIG_M386
-#define MODULE_PROC_FAMILY 386
-#elif defined CONFIG_M486
-#define MODULE_PROC_FAMILY 486
-#elif defined CONFIG_M586
-#define MODULE_PROC_FAMILY 586
-#elif defined CONFIG_M586TSC
-#define MODULE_PROC_FAMILY 586TSC
-#elif defined CONFIG_M586MMX
-#define MODULE_PROC_FAMILY 586MMX
-#elif defined CONFIG_MCORE2
-#define MODULE_PROC_FAMILY CORE2
-#elif defined CONFIG_M686
-#define MODULE_PROC_FAMILY 686
-#elif defined CONFIG_MPENTIUMII
-#define MODULE_PROC_FAMILY PENTIUMII
-#elif defined CONFIG_MPENTIUMIII
-#define MODULE_PROC_FAMILY PENTIUMIII
-#elif defined CONFIG_MPENTIUMM
-#define MODULE_PROC_FAMILY PENTIUMM
-#elif defined CONFIG_MPENTIUM4
-#define MODULE_PROC_FAMILY PENTIUM4
-#elif defined CONFIG_MK6
-#define MODULE_PROC_FAMILY K6
-#elif defined CONFIG_MK7
-#define MODULE_PROC_FAMILY K7
-#elif defined CONFIG_MK8
-#define MODULE_PROC_FAMILY K8
-#elif defined CONFIG_X86_ELAN
-#define MODULE_PROC_FAMILY ELAN
-#elif defined CONFIG_MCRUSOE
-#define MODULE_PROC_FAMILY CRUSOE
-#elif defined CONFIG_MEFFICEON
-#define MODULE_PROC_FAMILY EFFICEON
-#elif defined CONFIG_MWINCHIPC6
-#define MODULE_PROC_FAMILY WINCHIPC6
-#elif defined CONFIG_MWINCHIP2
-#define MODULE_PROC_FAMILY WINCHIP2
-#elif defined CONFIG_MWINCHIP3D
-#define MODULE_PROC_FAMILY WINCHIP3D
-#elif defined CONFIG_MCYRIXIII
RE: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
ata1.00: XXX DMA address 202275000 is above 32bit Tejun-I find the allocation always above 32bit with the following tests - 1) kernel-2.6.24-rc5 + the 32 bit limiting patch that you provided in a previous posting. 2) vanilla-2.6.24-rc5. But I don't find the DMA allocation above 32bit in the kernel logs when I apply my patch on the vanilla-2.6.24-rc5 kernel. -Shyam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] mmap read-around and readahead
On Tue, Dec 18, 2007 at 07:46:09PM +0800, Fengguang Wu wrote:
No timings for now... but I wrote a debug patch(attached) and watched
it running for about a week. Here are some interesting numbers:
Here are the (forgotten) readahead-debug.patch:
---
include/linux/fs.h | 43 ++
mm/Kconfig | 19 +++
mm/filemap.c |1
mm/readahead.c | 54 ++-
4 files changed, 116 insertions(+), 1 deletion(-)
--- linux-2.6.24-rc4-mm1.orig/include/linux/fs.h
+++ linux-2.6.24-rc4-mm1/include/linux/fs.h
@@ -760,11 +760,54 @@ struct file_ra_state {
unsigned int async_size;/* do asynchronous readahead when
there are only # of pages ahead */
+ unsigned int flags;
unsigned int ra_pages; /* Maximum readahead window */
int mmap_miss; /* Cache miss stat for mmap accesses */
loff_t prev_pos;/* Cache last read() position */
};
+#define RA_CLASS_SHIFT 4
+#define RA_CLASS_MASK ((1 RA_CLASS_SHIFT) - 1)
+/*
+ * Detailed classification of read-ahead behaviors.
+ */
+enum ra_class {
+ RA_CLASS_INIT0,
+ RA_CLASS_INIT,
+ RA_CLASS_SEQUENTIAL,
+ RA_CLASS_INTERLEAVED,
+ RA_CLASS_CONTEXT,
+ RA_CLASS_AROUND,
+ RA_CLASS_COUNT
+};
+
+static inline enum ra_class ra_class_new(struct file_ra_state *ra)
+{
+ return ra-flags RA_CLASS_MASK;
+}
+
+static inline enum ra_class ra_class_old(struct file_ra_state *ra)
+{
+ return (ra-flags RA_CLASS_SHIFT) RA_CLASS_MASK;
+}
+
+/*
+ * Which method is issuing this read-ahead?
+ */
+static inline void ra_set_class(struct file_ra_state *ra, enum ra_class
ra_class)
+{
+ unsigned long flags_mask;
+ unsigned long flags;
+ unsigned long old_ra_class;
+
+ flags_mask = ~(RA_CLASS_MASK | (RA_CLASS_MASK RA_CLASS_SHIFT));
+ flags = ra-flags flags_mask;
+
+ old_ra_class = ra_class_new(ra) RA_CLASS_SHIFT;
+
+ ra-flags = flags | old_ra_class | ra_class;
+}
+
/*
* Check if @index falls in the readahead windows.
*/
--- linux-2.6.24-rc4-mm1.orig/mm/Kconfig
+++ linux-2.6.24-rc4-mm1/mm/Kconfig
@@ -194,3 +194,22 @@ config NR_QUICK
config VIRT_TO_BUS
def_bool y
depends on !ARCH_NO_VIRT_TO_BUS
+
+config DEBUG_READAHEAD
+ bool Readahead debug and accounting
+ default y
+ select DEBUG_FS
+ help
+ This option injects extra code to dump detailed debug traces and do
+ readahead events accounting.
+
+ To actually get the data:
+
+ mkdir /debug
+ mount -t debug none /debug
+
+ After that you can do the following:
+
+ echo /debug/readahead/events # reset the counters
+ cat /debug/readahead/events# check the counters
+
--- linux-2.6.24-rc4-mm1.orig/mm/readahead.c
+++ linux-2.6.24-rc4-mm1/mm/readahead.c
@@ -16,6 +16,29 @@
#include linux/task_io_accounting_ops.h
#include linux/pagevec.h
#include linux/pagemap.h
+#include linux/debugfs.h
+
+static const char * const ra_class_name[] = {
+ [RA_CLASS_INIT0]= init0,
+ [RA_CLASS_INIT] = init,
+ [RA_CLASS_SEQUENTIAL] = sequential,
+ [RA_CLASS_INTERLEAVED] = interleaved,
+ [RA_CLASS_CONTEXT] = context,
+ [RA_CLASS_AROUND] = around,
+};
+
+#ifdef CONFIG_DEBUG_READAHEAD
+static u32 readahead_debug_level = 1;
+# define debug_option(o) (o)
+#else
+# define debug_option(o) (0)
+# define readahead_debug_level(0)
+#endif /* CONFIG_DEBUG_READAHEAD */
+
+#define dprintk(args...) \
+ do { if (readahead_debug_level = 2) printk(KERN_DEBUG args); } while(0)
+#define ddprintk(args...) \
+ do { if (readahead_debug_level = 3) printk(KERN_DEBUG args); } while(0)
void default_unplug_io_fn(struct backing_dev_info *bdi, struct page *page)
{
@@ -220,6 +243,13 @@ unsigned long max_sane_readahead(unsigne
static int __init readahead_init(void)
{
+#ifdef CONFIG_DEBUG_READAHEAD
+ struct dentry *root;
+
+ root = debugfs_create_dir(readahead, NULL);
+
+ debugfs_create_u32(debug_level, 0644, root, readahead_debug_level);
+#endif
return bdi_init(default_backing_dev_info);
}
subsys_initcall(readahead_init);
@@ -235,6 +265,15 @@ unsigned long ra_submit(struct file_ra_s
actual = __do_page_cache_readahead(mapping, filp,
ra-start, ra-size, ra-async_size);
+ dprintk(readahead-%s(process: %s/%d, file: %s/%s,
+ offset=%ld:%ld, ra=%ld+%d-%d) = %d\n,
+ ra_class_name[ra_class_new(ra)],
+ current-comm, current-pid,
+ mapping-host-i_sb-s_id,
+ filp-f_path.dentry-d_iname,
+ (long)(filp-f_pos PAGE_CACHE_SHIFT),
+
Re: [PATCH] sound/: Spelling fixes
At Mon, 17 Dec 2007 11:40:38 -0800, Joe Perches wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- sound/drivers/serial-u16550.c|6 ++-- sound/isa/es18xx.c |2 +- sound/pci/au88x0/au88x0_core.c |2 +- sound/pci/cs46xx/cs46xx_lib.c|2 +- sound/pci/hda/hda_codec.h|2 +- sound/pci/rme9652/hdsp.c |2 +- sound/pci/rme9652/hdspm.c|4 +- sound/pci/rme9652/rme9652.c |4 +- sound/pci/trident/trident_main.c | 44 +++--- 9 files changed, 34 insertions(+), 34 deletions(-) Applied to ALSA tree now. Thanks. Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/sound/: Spelling fixes
At Mon, 17 Dec 2007 11:40:39 -0800, Joe Perches wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- include/sound/ad1848.h |2 +- include/sound/cs4231-regs.h |2 +- include/sound/soc-dapm.h|2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Applied to ALSA tree. Thanks. Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Important regression with XFS update for 2.6.24-rc6
On Tue, Dec 18, 2007 at 12:28:04PM +0100, Damien Wyart wrote: Hello, As a follow-up to http://marc.info/?l=linux-kernelm=119796120524618w=2 (LKML seems down right now so I am not linking to it), I have detected an important problem with these two patches: after applying them by hand (downloaded them raw from SGI's gitweb) on top of 2.6.24-rc5-git5 (they have not yet been pulled into mainline by Linux as of this morning) for testing purposes, I noticed upon reboot that ls -l on directories with many files and subdirectories (around 5000 entries) takes several hundreds of MB in RAM and then dies with memory exhausted error. Ok. I haven't noticed anything wrong with directories up to about 250,000 files in the last few days. The ls -l I just did on a directory with 15000 entries (btree format) used about 5MB of RAM. extent format directories appear to work fine as well (tested 500 entries). Can you: a) isolate the problem to one patch or the other. My guess would be the directory mod, but. b) show your working ;) - what platform (i386, x86_64, etc) - what debug options - commands and output that shows the problem - strace of ls -l going bad - xfs_info from filesystem in question I also noticed that ldconfig takes a lot of time to complete, and firefox seems also to eat much more memory than usual. Reverting the two patches (going back to vanilla rc5-git5) makes these problems go away. I am not able to test right now if only one of the patches is bogus or if both of them are concerned. Well, there goes a). As the symptoms are easy to reproduce, I guess this is some kind of brown paper bag bug and will be easy for XFS experts to spot. Well, not reproducable on my test boxes. It may well be a brown paper bag job, but it's not obvious. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix crash with FLAT_MEMORY and ARCH_PFN_OFFSET != 0
On Tue, 18 Dec 2007 13:03:00 +0100 (CET) Thomas Bogendoerfer [EMAIL PROTECTED] wrote: When using FLAT_MEMORY and ARCH_PFN_OFFSET is not 0, the kernel crashes in memmap_init_zone(). This bug got introduced by commit c713216deebd95d2b0ab38fef8bb2361c0180c2d Signed-off-by: Thomas Bogendoerfer [EMAIL PROTECTED] --- mm/page_alloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b5a58d4..496f7f3 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3427,7 +3427,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat) mem_map = NODE_DATA(0)-node_mem_map; #ifdef CONFIG_ARCH_POPULATES_NODE_MAP if (page_to_pfn(mem_map) != pgdat-node_start_pfn) - mem_map -= pgdat-node_start_pfn; + mem_map -= (pgdat-node_start_pfn - ARCH_PFN_OFFSET); #endif /* CONFIG_ARCH_POPULATES_NODE_MAP */ } #endif hm. It's rather non-trivial to verify that this will compile OK on all architectures. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Avoid overflows in kernel/time.c (version 3)
On Dec 17 2007 15:33, H. Peter Anvin wrote: Could this live in scripts/ too? (And use CodingStyle?) Why should it live in scripts/ rather than where it is used? scripts/ is used either for global scripts or scripts which are used manually. Other scripts are not centralized there. CodingStyle is applicable to C code, not to scripts as far as I can tell. Checkpatch adheres to it. And indent, which is applicable to almost all languages, is a strong point in CodingStyle. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix crash with FLAT_MEMORY and ARCH_PFN_OFFSET != 0
On Tue, Dec 18, 2007 at 04:24:04AM -0800, Andrew Morton wrote: On Tue, 18 Dec 2007 13:03:00 +0100 (CET) Thomas Bogendoerfer [EMAIL PROTECTED] wrote: --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3427,7 +3427,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat) mem_map = NODE_DATA(0)-node_mem_map; #ifdef CONFIG_ARCH_POPULATES_NODE_MAP if (page_to_pfn(mem_map) != pgdat-node_start_pfn) - mem_map -= pgdat-node_start_pfn; + mem_map -= (pgdat-node_start_pfn - ARCH_PFN_OFFSET); #endif /* CONFIG_ARCH_POPULATES_NODE_MAP */ } #endif hm. It's rather non-trivial to verify that this will compile OK on all architectures. I grepped through include/asm-* and found: #if defined(CONFIG_FLATMEM) #ifndef ARCH_PFN_OFFSET #define ARCH_PFN_OFFSET (0UL) #endif in include/asm-generic/memory_model.h. So I'm still confident, that this works on all architectures. It's tested on MIPS. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: About mounting the sysfs
On Dec 18 2007 15:10, wit wrote:
1. What is the d_alloc_root used for? Actually, the question should
be: why we have to call d_alloc_root.
I think the root already has its dentry,
It does not.
why we have to allocate another while we mounting a file
system?
2. Why we call d_alloc_root to allocate a dentry for the mount point
while the usual mount point of sysfs is defined by the user (something
like /sysfs but not /).
/sys is a dentry that belongs to the / vfsmount, but we need a
/ that belongs to the whatever you are going to mount vfsmount.
See below:
root = d_alloc_root(inode);
if (!root) {
pr_debug(%s: could not get root dentry!\n,__FUNCTION__);
iput(inode);
return -ENOMEM;
}
root-d_fsdata = sysfs_root;
sb-s_root = root;
does this means settting the sysfs' mount point to / but not /sysfs.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/21] [PATCH] change bitwise operations to get a void parameter.
On Dec 18, 2007 3:18 AM, Rusty Russell [EMAIL PROTECTED] wrote: On Tuesday 18 December 2007 09:52:36 Glauber de Oliveira Costa wrote: This patch changes the bitwise operations in bitops.h to get a void pointers as a parameter. Before this patch, a lot of warnings can be seen. They're gone after it. No, this is a backwards step! These warnings are important for non-arch-specific code: I fought hard to get them made into unsigned longs. But I'm happy for this to be applied as is, then I'll grab the git tree, revert it and fix the warnings... Even before my processor.h patches, there are a lot of warnings caused by this. If Ingo does not mind getting more warnings, I can drop this patch entirely, and you (or someone else) can fix them later on. -- Glauber de Oliveira Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: dynamically update the root-domain span/online maps
* Andrew Morton [EMAIL PROTECTED] wrote: i'm reluctant to apply it without test results, unless we have a very clear picture of what happened on Andrew's box and how this updated patch resolves that problem. (or once Andrew tests your patch and deems it OK.) wades through a pile of new compile errors hm, due to any of these patches? tests it Seems OK now - resume-from-RAM actually resumes. cool, thanks! I've added it to sched-devel.git and have updated it. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch/x86/: Spelling fixes
* Joe Perches [EMAIL PROTECTED] wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- arch/x86/kernel/apic_32.c|2 +- arch/x86/kernel/mpparse_32.c |2 +- arch/x86/kernel/vm86_32.c|2 +- arch/x86/mm/srat_64.c|2 +- thanks, applied. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ATA bus error with external hd on esata
Greg Freemyer schrieb: On Dec 17, 2007 5:53 AM, Andrew Morton [EMAIL PROTECTED] wrote: On Sat, 15 Dec 2007 21:10:47 +0100 Zsolt Barat [EMAIL PROTECTED] wrote: Zsolt Barat schrieb: hi list, Let's cc the IDE development list. i just bought a MyBook called external HD with a fixed enclosure, from WD. Connected to the SATA port i constantly get ATA bus error messages in the kernel log. Is this a known issue? As an FYI: I've had a lot of problems with the big prepackaged drives in the last 6 months even from Windows, so I would not be too quick to blame Linux. ie. I bought several 500GB / 1000GB Buffalo Drives last month with plans to use them from Windows via USB. I attempted to do a lot of heavy file copying to/from them. I was getting a bunch of Delayed Write Failures, I finally gave up. The 500GB drives had a single hard drive internally, so I opened the case, removed the drive and connected them via standalone external carriers I had around. In that mode the drives worked fine (from Windows). I've used both standalone eSata external carriers and standalone USB external carriers with these same physical drives with no issues. My conclusion is that the electronics in the prepackaged external units is just not up to the job if your doing heavy i/o. thanks for your answer. the error messages are vanished for now. i switched on/of the power supply for the hd-box sometimes and then it suddenly worked normaly. it even negotiates with 3 Gbps and UDMA/133. Dec 18 13:05:50 proto1 ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 18 13:05:50 proto1 ata2.00: ATA-6: WD My Book ES, 012, max UDMA/133 maybe it is the cable, i have to investigate it. it also claimes to have an automatic power on/off function, whatever this should mean. best regards zsolt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ATA bus error with external hd on esata
Jean-Louis Dupond schrieb: Greg Freemyer schreef: On Dec 17, 2007 5:53 AM, Andrew Morton [EMAIL PROTECTED] wrote: On Sat, 15 Dec 2007 21:10:47 +0100 Zsolt Barat [EMAIL PROTECTED] wrote: Zsolt Barat schrieb: hi list, Let's cc the IDE development list. i just bought a MyBook called external HD with a fixed enclosure, from WD. Connected to the SATA port i constantly get ATA bus error messages in the kernel log. Is this a known issue? As an FYI: I've had a lot of problems with the big prepackaged drives in the last 6 months even from Windows, so I would not be too quick to blame Linux. ie. I bought several 500GB / 1000GB Buffalo Drives last month with plans to use them from Windows via USB. I attempted to do a lot of heavy file copying to/from them. I was getting a bunch of Delayed Write Failures, I finally gave up. The 500GB drives had a single hard drive internally, so I opened the case, removed the drive and connected them via standalone external carriers I had around. In that mode the drives worked fine (from Windows). I've used both standalone eSata external carriers and standalone USB external carriers with these same physical drives with no issues. My conclusion is that the electronics in the prepackaged external units is just not up to the job if your doing heavy i/o. Greg Could u check the temps of the disk ? I had that error in windows also with to hot disks ! If temp is 50°C I would start to worry :) hi, thanks for your answer. i can't check the temps via software tools, but i doubt it's the temperature, since it seems to have a fan inbuilt into the case. best regards zsolt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] atmel_serial: Clean up the code
On Tue, 18 Dec 2007 21:22:01 +0800
steve birtles [EMAIL PROTECTED] wrote:
Is there any change can we clean this up?
/*
* We wrap our port structure around the generic uart_port.
@@ -142,8 +146,8 @@ static void atmel_set_mctrl(struct uart_port
*port, u_int mctrl)
#ifdef CONFIG_ARCH_AT91RM9200
if (cpu_is_at91rm9200()) {
/*
- * AT91RM9200 Errata #39: RTS0 is not internally connected to
PA21.
- * We need to drive the pin manually.
+ * AT91RM9200 Errata #39: RTS0 is not internally connected
+ * to PA21. We need to drive the pin manually.
*/
if (port-mapbase == AT91RM9200_BASE_US0) {
if (mctrl TIOCM_RTS)
@@ -228,7 +232,8 @@ static void atmel_stop_rx(struct uart_port *port)
*/
I'm not sure what you mean. It just breaks the comment to fit within 80
columns...
and potentially add those flags for dealing with the CTS RTS ,
that may not be used on every board, because this clean up sit's in
my minor changes for the YL9200, specifically to re-jig the USARTS
lines so that we can separate RXD TXD , from a forced requirment to
use control lines when using 232
Could you just post your changes so that we can see where it fits in?
Haavard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/21] [PATCH] finish processor.h integration
* Ingo Molnar [EMAIL PROTECTED] wrote: What's left in processor_32.h and processor_64.h cannot be cleanly integrated. However, it's just a couple of definitions. They are moved to processor.h around ifdefs, and the original files are deleted. Note that there's much less headers included in the final version. and this patch breaks the build on the attached config, with: CC arch/x86/mm/boot_ioremap_32.o In file included from include/asm/fixmap_32.h:28, from include/asm/fixmap.h:2, from include/asm/pgtable_32.h:16, from include/asm/pgtable.h:2, from arch/x86/mm/boot_ioremap_32.c:21: include/asm/acpi.h:159: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'acpi_fake_nodes' make[1]: *** [arch/x86/mm/boot_ioremap_32.o] Error 1 make: *** [arch/x86/mm/boot_ioremap_32.o] Error 2 really, please do _much_ more careful unification. We unified two full architectures in .24-rc1 and there was _not a single regression_ due to that unification. Not a single build failure, not a single boot or runtime failure. here the problem is apparently caused by your patch, a careless 'unification' of include file sections. 32-bit had this: -#include asm/vm86.h -#include asm/math_emu.h -#include asm/segment.h -#include asm/page.h -#include asm/types.h -#include asm/sigcontext.h -#include asm/cpufeature.h -#include asm/msr.h -#include asm/system.h -#include linux/threads.h -#include linux/init.h -#include asm/desc_defs.h 64-bit had this: -#include asm/segment.h -#include asm/page.h -#include asm/types.h -#include asm/sigcontext.h -#include asm/cpufeature.h -#include linux/threads.h -#include asm/msr.h -#include asm/current.h -#include asm/system.h -#include linux/personality.h -#include asm/desc_defs.h and the 'unified' processor.h has: +#include asm/desc_defs.h +#include asm/msr.h #include asm/page.h #include asm/percpu.h #include asm/system.h #include asm/percpu.h #include linux/cpumask.h #include linux/cache.h +#include linux/personality.h Those are visible, _crutial_ differences totally unmentioned in the patch. yes, our include file dependencies are a jungle, the differences between 32-bit and 64-bit are arbitrary in 80% of the cases, but still there's no reason why this couldnt be done correctly. The patch below is a quick bandaid that adds the missing bits. Ingo -- Subject: x86: fix include file mess From: Ingo Molnar [EMAIL PROTECTED] fix include file mess. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] --- include/asm-x86/processor.h | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) Index: linux-x86.q/include/asm-x86/processor.h === --- linux-x86.q.orig/include/asm-x86/processor.h +++ linux-x86.q/include/asm-x86/processor.h @@ -6,15 +6,27 @@ struct task_struct; struct mm_struct; +#ifdef CONFIG_X86_32 +# include asm/math_emu.h +# include asm/vm86.h +#endif + +#include asm/cpufeature.h +#include asm/current.h #include asm/desc_defs.h #include asm/msr.h #include asm/page.h #include asm/percpu.h +#include asm/segment.h +#include asm/sigcontext.h #include asm/system.h -#include asm/percpu.h -#include linux/cpumask.h +#include asm/types.h + #include linux/cache.h +#include linux/cpumask.h +#include linux/init.h #include linux/personality.h +#include linux/threads.h /* * Default implementation of macro that returns current -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/21] [PATCH] finish processor.h integration
* Ingo Molnar [EMAIL PROTECTED] wrote: yes, our include file dependencies are a jungle, the differences between 32-bit and 64-bit are arbitrary in 80% of the cases, but still there's no reason why this couldnt be done correctly. The patch below is a quick bandaid that adds the missing bits. the bandaid didnt work - so i removed the 21/21 patch for the time being. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
On Mon, Dec 17, 2007 at 08:48:03PM -0800, Joe Perches wrote: diff --git a/MAINTAINERS b/MAINTAINERS index 9507b42..690f172 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3758,13 +3758,6 @@ W: http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/ T: git kernel.org:/pub/scm/linux/kernel/git/bunk/trivial.git S: Maintained -TMS380 TOKEN-RING NETWORK DRIVER -P: Adam Fritzler -M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -W: http://www.auk.cx/tms380tr/ -S: Maintained That's pretty unfriendly. Presumably the linux-tr list is still active and would still help people with that driver. So how about: TMS380 TOKEN-RING NETWORK DRIVER -P: Adam Fritzler -M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] ?W:? -S: Maintained +S: Orphan (Dunno what to do about W:) -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/21] [PATCH] finish processor.h integration
Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: What's left in processor_32.h and processor_64.h cannot be cleanly integrated. However, it's just a couple of definitions. They are moved to processor.h around ifdefs, and the original files are deleted. Note that there's much less headers included in the final version. and this patch breaks the build on the attached config, with: CC arch/x86/mm/boot_ioremap_32.o In file included from include/asm/fixmap_32.h:28, from include/asm/fixmap.h:2, from include/asm/pgtable_32.h:16, from include/asm/pgtable.h:2, from arch/x86/mm/boot_ioremap_32.c:21: include/asm/acpi.h:159: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'acpi_fake_nodes' make[1]: *** [arch/x86/mm/boot_ioremap_32.o] Error 1 make: *** [arch/x86/mm/boot_ioremap_32.o] Error 2 really, please do _much_ more careful unification. We unified two full architectures in .24-rc1 and there was _not a single regression_ due to that unification. Not a single build failure, not a single boot or runtime failure. IIRC, 24-rc1 was a different story. Most, if not all patches, had no binary diff, etc. This is not the case here. here the problem is apparently caused by your patch, a careless 'unification' of include file sections. 32-bit had this: Point is this patches do unification, but they are not just that, as you can see. I am attempting to cleanup headers that appears not to be used, I am effectivelly adding a new feature to x86_64, and so on. I am testing everything, all I sent works in my configs, and your testing, and point out the configs that breaks is really much appreciated. -#include asm/vm86.h -#include asm/math_emu.h -#include asm/segment.h -#include asm/page.h -#include asm/types.h -#include asm/sigcontext.h -#include asm/cpufeature.h -#include asm/msr.h -#include asm/system.h -#include linux/threads.h -#include linux/init.h -#include asm/desc_defs.h 64-bit had this: -#include asm/segment.h -#include asm/page.h -#include asm/types.h -#include asm/sigcontext.h -#include asm/cpufeature.h -#include linux/threads.h -#include asm/msr.h -#include asm/current.h -#include asm/system.h -#include linux/personality.h -#include asm/desc_defs.h and the 'unified' processor.h has: +#include asm/desc_defs.h +#include asm/msr.h #include asm/page.h #include asm/percpu.h #include asm/system.h #include asm/percpu.h #include linux/cpumask.h #include linux/cache.h +#include linux/personality.h Those are visible, _crutial_ differences totally unmentioned in the patch. yes, our include file dependencies are a jungle, the differences between 32-bit and 64-bit are arbitrary in 80% of the cases, but still there's no reason why this couldnt be done correctly. The patch below is a quick bandaid that adds the missing bits. And that's because I'm trying to drop headers that are not used anymore. Again, getting test for other people but me, helps making sure it's correct. I am working on updating the series now, and will send an updated version. Ingo -- Subject: x86: fix include file mess From: Ingo Molnar [EMAIL PROTECTED] fix include file mess. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] --- include/asm-x86/processor.h | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) Index: linux-x86.q/include/asm-x86/processor.h === --- linux-x86.q.orig/include/asm-x86/processor.h +++ linux-x86.q/include/asm-x86/processor.h @@ -6,15 +6,27 @@ struct task_struct; struct mm_struct; +#ifdef CONFIG_X86_32 +# include asm/math_emu.h +# include asm/vm86.h +#endif + +#include asm/cpufeature.h +#include asm/current.h #include asm/desc_defs.h #include asm/msr.h #include asm/page.h #include asm/percpu.h +#include asm/segment.h +#include asm/sigcontext.h #include asm/system.h -#include asm/percpu.h -#include linux/cpumask.h +#include asm/types.h + #include linux/cache.h +#include linux/cpumask.h +#include linux/init.h #include linux/personality.h +#include linux/threads.h /* * Default implementation of macro that returns current -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl
Andi Kleen [EMAIL PROTECTED] writes: Well the other alternative looks like having a second file per par bar. Say resource0_wc to support the write-combining mode, possibly The intention was to support memory not in bars, but give a generic IOMMU mapped memory interface for user space e.g. for the X server. But that needs a way to return the bus address for the mmap mapping and ioctl was the best I came up with for that. Given it was never finished. Ok that part wasn't obvious. The only thing we mmap in sysfs today are the bars. Taking normal memory and iommu mapping it to a device and then having a user space accessible version is a bit different. We need a special interface to allocate it and map it through the iommu to user space. This needs to be a driver or a support subsystem like DRM. Once we have gone that far then we can map those address to user space. I expect from the sysfs perspective those per device regions should look a lot like bars showing contiguous chunks of memory RAM from the devices perspective. At which point having two files instead of just one can solve the problem without an ioctl. For contiguous to device memory we also have some permission issues so I'm not yet certain that it make sense to expose it through sysfs. Regardless that seems to be solving a completely new aspect of the problem, and we can solve that problem separately. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/21] [PATCH] finish processor.h integration
Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: yes, our include file dependencies are a jungle, the differences between 32-bit and 64-bit are arbitrary in 80% of the cases, but still there's no reason why this couldnt be done correctly. The patch below is a quick bandaid that adds the missing bits. the bandaid didnt work - so i removed the 21/21 patch for the time being. I will also have updates for other patches, If you want, you can drop the series entirely, and wait for the new one to come -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] atmel_serial: Clean up the code
On Dec 18, 2007, at 6:33 PM, Haavard Skinnemoen wrote:
On Tue, 18 Dec 2007 11:14:42 +0100
Remy Bohmer [EMAIL PROTECTED] wrote:
Hello Haavard,
Please note that I'm not trying to steal the show here -- I just
want
That did not even come to my mind at all...
I am happy with everything that helps making this driver better.
Good :)
What shall we do first from here, splitup of the interrupt
handler? Or
DMA patch?
Is there any change can we clean this up?
/*
* We wrap our port structure around the generic uart_port.
@@ -142,8 +146,8 @@ static void atmel_set_mctrl(struct uart_port
*port, u_int mctrl)
#ifdef CONFIG_ARCH_AT91RM9200
if (cpu_is_at91rm9200()) {
/*
-* AT91RM9200 Errata #39: RTS0 is not internally connected to
PA21.
-* We need to drive the pin manually.
+* AT91RM9200 Errata #39: RTS0 is not internally connected
+* to PA21. We need to drive the pin manually.
*/
if (port-mapbase == AT91RM9200_BASE_US0) {
if (mctrl TIOCM_RTS)
@@ -228,7 +232,8 @@ static void atmel_stop_rx(struct uart_port *port)
*/
and potentially add those flags for dealing with the CTS RTS ,
that may not be used on every board, because this clean up sit's in
my minor changes for the YL9200, specifically to re-jig the USARTS
lines so that we can separate RXD TXD , from a forced requirment to
use control lines when using 232
Steve
I currently have the patches applied in the order you sent them,
with my
stuff wedged in between (thanks to git-rebase --interactive.) So I
think it makes sense to do the interrupt handler splitup first, even
though I personally care more about the DMA patch.
Haavard
---
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-
arm-kernel
FAQ:http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] x86: add kprobe-booster to X86_64
Hi Harvey,
Thank you for cleaning this up.
Harvey Harrison wrote:
Subject: [PATCH] x86: kprobes leftover cleanups
Eliminate __always_inline, all of these static functions are
only called once. Minor whitespace cleanup. Eliminate one
supefluous return at end of void function. Reverse sense of
#ifndef to be #ifdef to show the case only affects X86_32.
Unfortunately, to prevent kprobe recursive call, all functions which
is called from kprobes must be inlined or have __kprobes.
If __always_inline macro still work, I prefer to use it. If not,
it must have a __kprobe attribute like as below.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
arch/x86/kernel/kprobes.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 9aadd4d..1a0d96d 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -159,7 +159,7 @@ struct kretprobe_blackpoint kretprobe_blacklist[] = {
const int kretprobe_blacklist_size = ARRAY_SIZE(kretprobe_blacklist);
/* Insert a jump instruction at address 'from', which jumps to address
'to'.*/
-static __always_inline void set_jmp_op(void *from, void *to)
+static void set_jmp_op(void *from, void *to)
+static void __kprobes set_jmp_op(void *from, void *to)
{
struct __arch_jmp_op {
char op;
@@ -174,7 +174,7 @@ static __always_inline void set_jmp_op(void *from, void
*to)
* Returns non-zero if opcode is boostable.
* RIP relative instructions are adjusted at copying time in 64 bits mode
*/
-static __always_inline int can_boost(kprobe_opcode_t *opcodes)
+static int can_boost(kprobe_opcode_t *opcodes)
+static int __kprobes can_boost(kprobe_opcode_t *opcodes)
{
kprobe_opcode_t opcode;
kprobe_opcode_t *orig_opcodes = opcodes;
@@ -392,13 +392,13 @@ static void __kprobes set_current_kprobe(struct kprobe
*p, struct pt_regs *regs,
kcb-kprobe_saved_flags = ~IF_MASK;
}
-static __always_inline void clear_btf(void)
+static void clear_btf(void)
+static void __kprobes clear_btf(void)
{
if (test_thread_flag(TIF_DEBUGCTLMSR))
wrmsr(MSR_IA32_DEBUGCTLMSR, 0, 0);
}
-static __always_inline void restore_btf(void)
+static void restore_btf(void)
+static void __kprobes restore_btf(void)
{
if (test_thread_flag(TIF_DEBUGCTLMSR))
wrmsr(MSR_IA32_DEBUGCTLMSR, current-thread.debugctlmsr, 0);
@@ -409,7 +409,7 @@ static void __kprobes prepare_singlestep(struct kprobe
*p, struct pt_regs *regs)
clear_btf();
regs-flags |= TF_MASK;
regs-flags = ~IF_MASK;
- /*single step inline if the instruction is an int3*/
+ /* single step inline if the instruction is an int3 */
if (p-opcode == BREAKPOINT_INSTRUCTION)
regs-ip = (unsigned long)p-addr;
else
@@ -767,7 +767,7 @@ static void __kprobes resume_execution(struct kprobe *p,
case 0xe8: /* call relative - Fix return addr */
*tos = orig_ip + (*tos - copy_ip);
break;
-#ifndef CONFIG_X86_64
+#ifdef CONFIG_X86_32
case 0x9a: /* call absolute -- same as call absolute, indirect */
*tos = orig_ip + (*tos - copy_ip);
goto no_change;
@@ -813,8 +813,6 @@ static void __kprobes resume_execution(struct kprobe *p,
no_change:
restore_btf();
-
- return;
}
/*
Thanks again!
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drivers/scsi/: Spelling fixes
ACK ips line change.
Sincerely -- Mark Salyzyn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Perches
Sent: Monday, December 17, 2007 2:40 PM
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton; AACRAID; Andrew Vasquez; Brian King;
IpsLinux; Hannes Reinecke; James E.J. Bottomley; James Smart;
Mike Christie; Neela Syam Kolli; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: [PATCH] drivers/scsi/: Spelling fixes
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
. . .
drivers/scsi/ips.c|2 +-
. . .
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 5c5a9b2..901e14b 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -1313,7 +1313,7 @@ ips_intr_copperhead(ips_ha_t * ha)
cstatus.value = (*ha-func.statupd) (ha);
if (cstatus.fields.command_id (IPS_MAX_CMDS - 1)) {
- /* Spurious Interupt ? */
+ /* Spurious Interrupt ? */
continue;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmi: Let drivers walk the DMI table
Hi all,
This patch is for review and comments, not merge. As the first user for
this new functionality is a hardware monitoring driver [1], this patch
will be better merged via the hwmon tree. If anyone has objections with
regards to this patch, please let me know.
[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2007-December/022164.html
* * * * *
Let drivers walk the DMI table for their own needs. Some drivers need
data stored in OEM-specific DMI records for proper operation.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/firmware/dmi_scan.c | 61 +--
include/linux/dmi.h |3 ++
2 files changed, 50 insertions(+), 14 deletions(-)
--- linux-2.6.24-rc5.orig/drivers/firmware/dmi_scan.c 2007-12-12
12:36:34.0 +0100
+++ linux-2.6.24-rc5/drivers/firmware/dmi_scan.c2007-12-18
14:27:28.0 +0100
@@ -36,18 +36,12 @@ static char * __init dmi_string(const st
* We have to be cautious here. We have seen BIOSes with DMI pointers
* pointing to completely the wrong place for example
*/
-static int __init dmi_table(u32 base, int len, int num,
- void (*decode)(const struct dmi_header *))
+static void dmi_table(u8 *buf, int len, int num,
+ void (*decode)(const struct dmi_header *))
{
- u8 *buf, *data;
+ u8 *data = buf;
int i = 0;
- buf = dmi_ioremap(base, len);
- if (buf == NULL)
- return -1;
-
- data = buf;
-
/*
* Stop when we see all the items the table claimed to have
* OR we run off the end of the table (also happens)
@@ -68,7 +62,23 @@ static int __init dmi_table(u32 base, in
data += 2;
i++;
}
- dmi_iounmap(buf, len);
+}
+
+static u32 dmi_base;
+static u16 dmi_len;
+static u16 dmi_num;
+
+static int __init dmi_walk_early(void (*decode)(const struct dmi_header *))
+{
+ u8 *buf;
+
+ buf = dmi_ioremap(dmi_base, dmi_len);
+ if (buf == NULL)
+ return -1;
+
+ dmi_table(buf, dmi_len, dmi_num, decode);
+
+ dmi_iounmap(buf, dmi_len);
return 0;
}
@@ -273,9 +283,9 @@ static int __init dmi_present(const char
memcpy_fromio(buf, p, 15);
if ((memcmp(buf, _DMI_, 5) == 0) dmi_checksum(buf)) {
- u16 num = (buf[13] 8) | buf[12];
- u16 len = (buf[7] 8) | buf[6];
- u32 base = (buf[11] 24) | (buf[10] 16) |
+ dmi_num = (buf[13] 8) | buf[12];
+ dmi_len = (buf[7] 8) | buf[6];
+ dmi_base = (buf[11] 24) | (buf[10] 16) |
(buf[9] 8) | buf[8];
/*
@@ -287,7 +297,7 @@ static int __init dmi_present(const char
buf[14] 4, buf[14] 0xF);
else
printk(KERN_INFO DMI present.\n);
- if (dmi_table(base,len, num, dmi_decode) == 0)
+ if (dmi_walk_early(dmi_decode) == 0)
return 0;
}
return 1;
@@ -470,3 +480,26 @@ int dmi_get_year(int field)
return year;
}
+/**
+ * dmi_walk - Walk the DMI table and get called back for every record
+ * @decode: Callback function
+ *
+ * Returns -1 when the DMI table can't be reached, 0 on success.
+ */
+int dmi_walk(void (*decode)(const struct dmi_header *))
+{
+ u8 *buf;
+
+ if (!dmi_available)
+ return -1;
+
+ buf = ioremap(dmi_base, dmi_len);
+ if (buf == NULL)
+ return -1;
+
+ dmi_table(buf, dmi_len, dmi_num, decode);
+
+ iounmap(buf);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dmi_walk);
--- linux-2.6.24-rc5.orig/include/linux/dmi.h 2007-12-12 12:36:34.0
+0100
+++ linux-2.6.24-rc5/include/linux/dmi.h2007-12-18 14:27:28.0
+0100
@@ -78,6 +78,7 @@ extern const struct dmi_device * dmi_fin
extern void dmi_scan_machine(void);
extern int dmi_get_year(int field);
extern int dmi_name_in_vendors(const char *str);
+extern int dmi_walk(void (*decode)(const struct dmi_header *));
#else
@@ -87,6 +88,8 @@ static inline const struct dmi_device *
const struct dmi_device *from) { return NULL; }
static inline int dmi_get_year(int year) { return 0; }
static inline int dmi_name_in_vendors(const char *s) { return 0; }
+static inline int dmi_walk(void (*decode)(const struct dmi_header *))
+ { return -1; }
#endif
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: xfs mknod regression
On Mon, Dec 17, 2007 at 08:48:40PM -0800, Bret Towe wrote: I hit a bug in 2.6.24-rc looks to be in 2.6.23 also so not sure how long it's been there with an xfs filesystem pbuilder has an issue using device files it makes for chroot the mknod command looks to work fine the file is created however when attempting to use one of the created files you see something like the below ghoststar dev # echo hi null bash: null: No such device or address ghoststar dev # ls -l null crw-rw-rw- 1 root root 1, 3 2007-12-17 20:34 null ghoststar dev # ls -l /dev/null crw-rw-rw- 1 root root 1, 3 2007-10-05 17:29 /dev/null ghoststar dev # echo hi /dev/null ghoststar dev # Ok. Works on 2.6.22. doesn't work on latest xfsdev. I'll look into it. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix crash with FLAT_MEMORY and ARCH_PFN_OFFSET != 0
On (18/12/07 13:03), Thomas Bogendoerfer didst pronounce: When using FLAT_MEMORY and ARCH_PFN_OFFSET is not 0, the kernel crashes in memmap_init_zone(). This bug got introduced by commit c713216deebd95d2b0ab38fef8bb2361c0180c2d That commit is over a year old and it initially distressed me that it would take this long to show up on a boot test. However, you said this was to fix MIPS in a follow-on mail and I never made it use arch-independent zone-sizing which is where CONFIG_ARCH_POPULATES_NODE_MAP comes from. Support for arch-independent zone-sizing was added for MIPS on Nov 3rd 2007 by commit cce335ae47e231398269fb05fa48e0e9cbf289e0 (relevant cc added) which is a much more reasonable timeframe for catching this sort of problem. I believe the real bug might be in there. Can you post a full dmesg log with loglevel=8 so I can see what the layout looks like? My aim is to find out why the start of your mem_map is not at the start of node 0's mem_map which is what I generally expected with the FLATMEM model. Thanks. Signed-off-by: Thomas Bogendoerfer [EMAIL PROTECTED] --- mm/page_alloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b5a58d4..496f7f3 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3427,7 +3427,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat) mem_map = NODE_DATA(0)-node_mem_map; #ifdef CONFIG_ARCH_POPULATES_NODE_MAP if (page_to_pfn(mem_map) != pgdat-node_start_pfn) - mem_map -= pgdat-node_start_pfn; + mem_map -= (pgdat-node_start_pfn - ARCH_PFN_OFFSET); #endif /* CONFIG_ARCH_POPULATES_NODE_MAP */ } #endif -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] PCI: use dev_printk in x86 quirk messages
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Convert quirk printks to dev_printk(). thanks, applied the x86 bits. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] x86: add kprobe-booster to X86_64
* Harvey Harrison [EMAIL PROTECTED] wrote: On Tue, 2007-12-18 at 12:29 +0100, Ingo Molnar wrote: * Harvey Harrison [EMAIL PROTECTED] wrote: Sorry I missed an ifdef in this patch in the following hunk: could you resend your kprobes cleanups against current x86.git? They have been conceptually acked by Masami. This cuts out the unification part of your queue which is bad luck but the effort has been duplicated already so there's not much we can do about it i guess. Your other 17 cleanup and unification patches are still queued up in x86.git and passed a lot of testing, so they will likely go into v2.6.25. Nice work! Ingo Ingo, I'd suggest just tossing my kprobes cleanups. I just sent you a rollup of anything I saw that was left in mine that was still worthwhile after Masami's, included below for reference. It didn't amount to much left so I rolled it all together: Subject: [PATCH] x86: kprobes leftover cleanups Eliminate __always_inline, all of these static functions are only called once. Minor whitespace cleanup. Eliminate one supefluous return at end of void function. Reverse sense of #ifndef to be #ifdef to show the case only affects X86_32. thanks, i've applied them. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/21] [PATCH] unify common parts of processor.h
* Glauber de Oliveira Costa [EMAIL PROTECTED] wrote: due to zapping this bit of include/asm-x86/processor_32.h: -/* Forward declaration, a strange C thing */ -struct task_struct; -struct mm_struct; Ingo I'll test it with your config, and repost. i've pushed out a new iteration of x86.git, which includes 20 out of your 21 patches, so please repost relative to that tree. i have fixed the above problem by adding those 3 lines. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] x86: unify module_{32|64}.h
* Harvey Harrison [EMAIL PROTECTED] wrote:
From 5be3fc6a0e28d82a05487a8fb1a86532fb0ad4e8 Mon Sep 17 00:00:00 2001
From: Harvey Harrison [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 03:58:10 -0800
Subject: [PATCH] x86: unify module_{32|64}.h
This adds one case to the MODULE_PROC_FAMILY block testing
for X86_64. There are no new things defined on X86_64 than
there were before.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Ingo, let a single checkpatch warning go by in the first one,
fixed in this version.
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc5-mm1 -- INFO: possible circular locking dependency detected -- pm-suspend/5800 is trying to acquire lock
I have only seen this happen once, and cannot reproduce it. I'll keep
trying, though.
Dec 16 22:10:48 syntropy kernel: [ 231.718023]
===
Dec 16 22:10:48 syntropy kernel: [ 231.718025] [ INFO: possible
circular locking dependency detected ]
Dec 16 22:10:48 syntropy kernel: [ 231.718028] 2.6.24-rc5-mm1 #7
Dec 16 22:10:48 syntropy kernel: [ 231.718029]
---
Dec 16 22:10:48 syntropy kernel: [ 231.718032] pm-suspend/5800 is
trying to acquire lock:
Dec 16 22:10:48 syntropy kernel: [ 231.718034]
((priv-init_alive_start)-work){--..}, at:
[__cancel_work_timer+0x8a/0x17f] __cancel_work_timer+0x8a/0x17f
Dec 16 22:10:48 syntropy kernel: [ 231.718045]
Dec 16 22:10:48 syntropy kernel: [ 231.718046] but task is already
holding lock:
Dec 16 22:10:48 syntropy kernel: [ 231.718047] (priv-mutex){--..},
at: [f8a587e7] iwl3945_pci_suspend+0x1d/0x65 [iwl3945]
Dec 16 22:10:48 syntropy kernel: [ 231.718065]
Dec 16 22:10:48 syntropy kernel: [ 231.718066] which lock already
depends on the new lock.
Dec 16 22:10:48 syntropy kernel: [ 231.718067]
Dec 16 22:10:48 syntropy kernel: [ 231.718068]
Dec 16 22:10:48 syntropy kernel: [ 231.718069] the existing
dependency chain (in reverse order) is:
Dec 16 22:10:48 syntropy kernel: [ 231.718071]
Dec 16 22:10:48 syntropy kernel: [ 231.718072] - #1 (priv-mutex){--..}:
Dec 16 22:10:48 syntropy kernel: [ 231.718075]
[__lock_acquire+0xa17/0xbf4] __lock_acquire+0xa17/0xbf4
Dec 16 22:10:48 syntropy kernel: [ 231.718083]
[mac80211:lock_acquire+0x76/0x1d8] lock_acquire+0x76/0x9d
Dec 16 22:10:48 syntropy kernel: [ 231.718088]
[pcmcia:mutex_lock_nested+0xf7/0xd7d] mutex_lock_nested+0xf7/0x294
Dec 16 22:10:48 syntropy kernel: [ 231.718096][f8a56ff7]
iwl3945_bg_init_alive_start+0x2d/0x1d7 [iwl3945]
Dec 16 22:10:48 syntropy kernel: [ 231.718109]
[run_workqueue+0xbb/0x18b] run_workqueue+0xbb/0x18b
Dec 16 22:10:48 syntropy kernel: [ 231.718115]
[worker_thread+0xbe/0xcd] worker_thread+0xbe/0xcd
Dec 16 22:10:48 syntropy kernel: [ 231.718121]
[kthread+0x3b/0x61] kthread+0x3b/0x61
Dec 16 22:10:48 syntropy kernel: [ 231.718126]
[kernel_thread_helper+0x7/0x10] kernel_thread_helper+0x7/0x10
Dec 16 22:10:48 syntropy kernel: [ 231.718133][] 0x
Dec 16 22:10:48 syntropy kernel: [ 231.718145]
Dec 16 22:10:48 syntropy kernel: [ 231.718146] - #0
((priv-init_alive_start)-work){--..}:
Dec 16 22:10:48 syntropy kernel: [ 231.718149]
[__lock_acquire+0x93e/0xbf4] __lock_acquire+0x93e/0xbf4
Dec 16 22:10:48 syntropy kernel: [ 231.718155]
[mac80211:lock_acquire+0x76/0x1d8] lock_acquire+0x76/0x9d
Dec 16 22:10:48 syntropy kernel: [ 231.718161]
[__cancel_work_timer+0xb3/0x17f] __cancel_work_timer+0xb3/0x17f
Dec 16 22:10:48 syntropy kernel: [ 231.718167]
[iwl3945:cancel_delayed_work_sync+0xb/0x0d]
cancel_delayed_work_sync+0xb/0xd
Dec 16 22:10:48 syntropy kernel: [ 231.718173][f8a542cb]
__iwl3945_down+0x51/0x310 [iwl3945]
Dec 16 22:10:48 syntropy kernel: [ 231.718184][f8a587f7]
iwl3945_pci_suspend+0x2d/0x65 [iwl3945]
Dec 16 22:10:48 syntropy kernel: [ 231.718196]
[pci_device_suspend+0x1b/0x4b] pci_device_suspend+0x1b/0x4b
Dec 16 22:10:48 syntropy kernel: [ 231.718203]
[device_suspend+0x17e/0x259] device_suspend+0x17e/0x259
Dec 16 22:10:48 syntropy kernel: [ 231.718210]
[suspend_devices_and_enter+0x3d/0x138]
suspend_devices_and_enter+0x3d/0x138
Dec 16 22:10:48 syntropy kernel: [ 231.718217]
[enter_state+0x121/0x17d] enter_state+0x121/0x17d
Dec 16 22:10:48 syntropy kernel: [ 231.718222]
[state_store+0x96/0xac] state_store+0x96/0xac
Dec 16 22:10:48 syntropy kernel: [ 231.718228]
[kobj_attr_store+0x1a/0x22] kobj_attr_store+0x1a/0x22
Dec 16 22:10:48 syntropy kernel: [ 231.718234]
[sysfs_write_file+0xb8/0xe3] sysfs_write_file+0xb8/0xe3
Dec 16 22:10:48 syntropy kernel: [ 231.718242]
[vfs_write+0xa4/0x120] vfs_write+0xa4/0x120
Dec 16 22:10:48 syntropy kernel: [ 231.718248]
[sys_write+0x3b/0x60] sys_write+0x3b/0x60
Dec 16 22:10:48 syntropy kernel: [ 231.718254]
[sysenter_past_esp+0x6b/0xc1] sysenter_past_esp+0x6b/0xc1
Dec 16 22:10:48 syntropy kernel: [ 231.718259][] 0x
Dec 16 22:10:48 syntropy kernel: [ 231.718269]
Dec 16 22:10:48 syntropy kernel: [ 231.718269] other info that might
help us debug this:
Dec 16 22:10:48 syntropy kernel: [ 231.718271]
Dec 16 22:10:48 syntropy kernel: [ 231.718272] 4 locks held by pm-suspend/5800:
Dec 16 22:10:48 syntropy kernel: [ 231.718274] #0:
(buffer-mutex){--..}, at: [sysfs_write_file+0x25/0xe3]
sysfs_write_file+0x25/0xe3
Dec 16 22:10:48 syntropy kernel: [ 231.718280] #1:
(pm_mutex){--..}, at: [enter_state+0x166/0x17d]
enter_state+0x166/0x17d
Dec 16 22:10:48 syntropy kernel: [ 231.718286] #2: (dpm_mtx){--..},
at: [device_suspend+0x2b/0x259] device_suspend+0x2b/0x259
Dec 16 22:10:48 syntropy kernel: [ 231.718291] #3:
(priv-mutex){--..}, at: [f8a587e7]
Do not reset xfsquota flags on quotaless ro mount
Hi,
In https://bugzilla.novell.com/show_bug.cgi?id=345338 it is claimed that
resetting the quota flags in the mounting sequence rw,ro,rw is a bug, but I
would say this is not the case, as quota is metadata, and the log is replayed
in ro mode even for other filesystems. Yet, it is still not nice, and I have
been trying with this patch, which does not do the right thing yet. (It does a
recovery when mounting for the 3rd time, which probably just says that I did
not know too much of xfs internals to cook up a nicely working patch.)
Opinions?
===
In the following action sequence, quota is unnecessarily recalculated
at the 3rd mount invocation:
mount -o usrquota,grpquota /dev/mapper/myxfs /mnt
umount /mnt
mount -o ro /dev/mapper/myxfs /mnt
umount /mnt
mount -o usrquota,grpquota /dev/mapper/myxfs /mnt
This patch skips clearing the quota flags on read-only mounts.
---
fs/xfs/xfs_qmops.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6/fs/xfs/xfs_qmops.c
===
--- linux-2.6.orig/fs/xfs/xfs_qmops.c
+++ linux-2.6/fs/xfs/xfs_qmops.c
@@ -134,7 +134,14 @@ static struct xfs_qmops xfs_qmcore_stub
int
xfs_qmops_get(struct xfs_mount *mp, struct xfs_mount_args *args)
{
- if (args-flags (XFSMNT_UQUOTA | XFSMNT_PQUOTA | XFSMNT_GQUOTA)) {
+ bool c;
+
+ c = args-flags (XFSMNT_UQUOTA | XFSMNT_GQUOTA | XFSMNT_PQUOTA);
+#ifdef CONFIG_XFS_QUOTA
+ c |= mp-m_flags XFS_MOUNT_RDONLY;
+#endif
+
+ if (c) {
#ifdef CONFIG_XFS_QUOTA
mp-m_qm_ops = xfs_qmcore_xfs;
#else
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 -- INFO: possible circular locking dependency detected -- pm-suspend/5800 is trying to acquire lock
On Tue, 2007-12-18 at 09:03 -0500, Miles Lane wrote: I have only seen this happen once, and cannot reproduce it. I'll keep trying, though. Dec 16 22:10:48 syntropy kernel: [ 231.718023] === Do you have a version that isn't line-wrapped before I try to unwrap it? Thanks, johannes signature.asc Description: This is a digitally signed message part
Re: Important regression with XFS update for 2.6.24-rc6
* David Chinner [EMAIL PROTECTED] [071218 13:24]: Ok. I haven't noticed anything wrong with directories up to about 250,000 files in the last few days. The ls -l I just did on a directory with 15000 entries (btree format) used about 5MB of RAM. extent format directories appear to work fine as well (tested 500 entries). Ok, nice to know the problem is not so frequent. Can you: a) isolate the problem to one patch or the other. My guess would be the directory mod, but. Yes, it is indeed the directory patch. But even if I still sometimes get huge memory usage with ls (using the patched kernel), this is quite rare, and the problem is now mainly getting entries in the listing repeated, and the ls process taking longer than without the patch. But this is mainly after booting. I guess the cache plays a role and even using drop_caches, I can't reproduce the problem. Only on fresh reboot do I get it systematically, but much less often the memory problem. And as said earlier, after fresh boot on rc5-git5 without the directory patch, the ls -l goes normal (no repeated entries). b) show your working ;) Sorry, I forgot this part in my initial report. - what platform (i386, x86_64, etc) i386. - what debug options Nothing special, the kernel has 4K stacks, and xfs partitions are mounted with noatime,nodiratime. - commands and output that shows the problem It is mainly ls -l in a quite crowded directory. - strace of ls -l going bad - xfs_info from filesystem in question I have put the files at http://damien.wyart.free.fr/xfs/ strace_xfs_problem.1.gz and strace_xfs_problem.2.gz have been created with the problematic kernel, and are quite bigger than strace_xfs_problem.normal.gz, which has been created with the vanilla rc5-git5. There is also xfs_info. I can provide further details if needed (maybe kernel config, but nothing special on the xfs side), but I confirm the behavior is different with and without the directory patch (041388b54ed95cd169546bd83bacd08ee32bd7ea on oss.sgi), and doesn't look normal with the patch. -- Damien Wyart -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] atmel_serial: Split the interrupt handler
From: Remy Bohmer [EMAIL PROTECTED]
This patch splits up the interrupt handler of the serial port
into a interrupt top-half and a tasklet.
The goal is to get the interrupt top-half as short as possible to
minimize latencies on interrupts. But the old code also does some
calls in the interrupt handler that are not allowed on preempt-RT
in IRQF_NODELAY context. This handler is executed in this context
because of the interrupt sharing with the timer interrupt.
The timer interrupt on Preempt-RT runs in IRQF_NODELAY context.
The tasklet takes care of handling control status changes, pushing
incoming characters to the tty layer, handling break and other errors.
The Transmit path was IRQF_NODELAY safe by itself, and is not adapted.
The read path for DMA(PDC) is also not adapted, because that code
does not run in IRQF_NODELAY context due to irq-sharing. The DBGU
which is shared with the timer-irq does not work with DMA, so
therefor this is no problem.
Reading the complete receive queue is still done in the top-half
because we never want to miss any incoming character.
This patch demands the following patches to be installed first:
* atmel_serial_cleanup.patch
[EMAIL PROTECTED]: misc cleanups and simplifications]
Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
Changes since v1:
Whitespace cleanups
Allocate rx ring data separately
Move more of the rx processing into tasklet
Consolidate rx and status tasklets into one
Use circ_buf instead of atmel_uart_ring
Eliminate RX ring locking
In this version of the patch, we try to only do things that are
absolutely necessary in the interrupt handler, storing away the
status register along with the received character and letting the
tasklet handle break, sysrq, error flags, etc.
Since we don't need to store the tty flags and overrun bit, the size
of each entry in the RX ring is reduced from 16 bytes to 4 bytes.
I've also used the first SMP barrier pair in my life; hope it's
correct. I don't think we need full barriers because we don't deal
with I/O, but we need SMP barriers to get correct ordering across CPUs
and to prevent the compiler from reading things in the wrong order.
This patch should apply on top of the cleanup patch I sent earlier
today. Or at least I think so...I'll send the full series once
everyone are happy.
drivers/serial/atmel_serial.c | 208 -
1 files changed, 162 insertions(+), 46 deletions(-)
diff --git a/drivers/serial/atmel_serial.c b/drivers/serial/atmel_serial.c
index bd41529..a733db5 100644
--- a/drivers/serial/atmel_serial.c
+++ b/drivers/serial/atmel_serial.c
@@ -111,6 +111,13 @@
static int (*atmel_open_hook) (struct uart_port *);
static void (*atmel_close_hook) (struct uart_port *);
+struct atmel_uart_char {
+ u16 status;
+ u16 ch;
+};
+
+#define ATMEL_SERIAL_RINGSIZE 1024
+
/*
* We wrap our port structure around the generic uart_port.
*/
@@ -119,6 +126,12 @@ struct atmel_uart_port {
struct clk *clk; /* uart clock */
unsigned short suspended; /* is port suspended? */
int break_active; /* break being received */
+
+ struct tasklet_struct tasklet;
+ unsigned intirq_pending;
+ unsigned intirq_status;
+
+ struct circ_buf rx_ring;
};
static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
@@ -248,22 +261,42 @@ static void atmel_break_ctl(struct uart_port *port, int
break_state)
}
/*
+ * Stores the incoming character in the ring buffer
+ */
+static void
+atmel_buffer_rx_char(struct uart_port *port, unsigned int status,
+unsigned int ch)
+{
+ struct atmel_uart_port *atmel_port = (struct atmel_uart_port *)port;
+ struct circ_buf *ring = atmel_port-rx_ring;
+ struct atmel_uart_char *c;
+
+ if (!CIRC_SPACE(ring-head, ring-tail, ATMEL_SERIAL_RINGSIZE))
+ /* Buffer overflow, ignore char */
+ return;
+
+ c = ((struct atmel_uart_char *)ring-buf)[ring-head];
+ c-status = status;
+ c-ch = ch;
+
+ /* Make sure the character is stored before we update head. */
+ smp_wmb();
+
+ ring-head = (ring-head + 1) (ATMEL_SERIAL_RINGSIZE - 1);
+}
+
+/*
* Characters received (called from interrupt handler)
*/
static void atmel_rx_chars(struct uart_port *port)
{
struct atmel_uart_port *atmel_port = (struct atmel_uart_port *)port;
- struct tty_struct *tty = port-info-tty;
- unsigned int status, ch, flg;
+ unsigned int status, ch;
status = UART_GET_CSR(port);
while (status ATMEL_US_RXRDY) {
ch = UART_GET_CHAR(port);
- port-icount.rx++;
-
- flg = TTY_NORMAL;
-
/*
* note that the error
[git pull] scheduler fixes
Linus, please pull the latest scheduler git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
Thanks,
Ingo
--
Dmitry Adamushko (1):
sched: fix crash on ia64, introduce task_current()
Eric Dumazet (1):
sched: sysctl, proc_dointvec_minmax() expects int values for
Ingo Molnar (2):
sched: touch softlockup watchdog after idling
sched: do not hurt SCHED_BATCH on wakeup
Livio Soares (1):
sched: mark rwsem functions as __sched for wchan/profiling
kernel/rwsem.c |5 +++--
kernel/sched.c | 18 --
kernel/sched_fair.c |3 +--
kernel/sysctl.c |8
lib/rwsem.c |2 +-
5 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/kernel/rwsem.c b/kernel/rwsem.c
index 1ec620c..cae050b 100644
--- a/kernel/rwsem.c
+++ b/kernel/rwsem.c
@@ -6,6 +6,7 @@
#include linux/types.h
#include linux/kernel.h
+#include linux/sched.h
#include linux/module.h
#include linux/rwsem.h
@@ -15,7 +16,7 @@
/*
* lock for reading
*/
-void down_read(struct rw_semaphore *sem)
+void __sched down_read(struct rw_semaphore *sem)
{
might_sleep();
rwsem_acquire_read(sem-dep_map, 0, 0, _RET_IP_);
@@ -42,7 +43,7 @@ EXPORT_SYMBOL(down_read_trylock);
/*
* lock for writing
*/
-void down_write(struct rw_semaphore *sem)
+void __sched down_write(struct rw_semaphore *sem)
{
might_sleep();
rwsem_acquire(sem-dep_map, 0, 0, _RET_IP_);
diff --git a/kernel/sched.c b/kernel/sched.c
index c6e551d..3df84ea 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -508,10 +508,15 @@ EXPORT_SYMBOL_GPL(cpu_clock);
# define finish_arch_switch(prev) do { } while (0)
#endif
+static inline int task_current(struct rq *rq, struct task_struct *p)
+{
+ return rq-curr == p;
+}
+
#ifndef __ARCH_WANT_UNLOCKED_CTXSW
static inline int task_running(struct rq *rq, struct task_struct *p)
{
- return rq-curr == p;
+ return task_current(rq, p);
}
static inline void prepare_lock_switch(struct rq *rq, struct task_struct *next)
@@ -540,7 +545,7 @@ static inline int task_running(struct rq *rq, struct
task_struct *p)
#ifdef CONFIG_SMP
return p-oncpu;
#else
- return rq-curr == p;
+ return task_current(rq, p);
#endif
}
@@ -663,6 +668,7 @@ void sched_clock_idle_wakeup_event(u64 delta_ns)
struct rq *rq = cpu_rq(smp_processor_id());
u64 now = sched_clock();
+ touch_softlockup_watchdog();
rq-idle_clock += delta_ns;
/*
* Override the previous timestamp and ignore all
@@ -3334,7 +3340,7 @@ unsigned long long task_sched_runtime(struct task_struct
*p)
rq = task_rq_lock(p, flags);
ns = p-se.sum_exec_runtime;
- if (rq-curr == p) {
+ if (task_current(rq, p)) {
update_rq_clock(rq);
delta_exec = rq-clock - p-se.exec_start;
if ((s64)delta_exec 0)
@@ -4021,7 +4027,7 @@ void rt_mutex_setprio(struct task_struct *p, int prio)
oldprio = p-prio;
on_rq = p-se.on_rq;
- running = task_running(rq, p);
+ running = task_current(rq, p);
if (on_rq) {
dequeue_task(rq, p, 0);
if (running)
@@ -4332,7 +4338,7 @@ recheck:
}
update_rq_clock(rq);
on_rq = p-se.on_rq;
- running = task_running(rq, p);
+ running = task_current(rq, p);
if (on_rq) {
deactivate_task(rq, p, 0);
if (running)
@@ -7101,7 +7107,7 @@ void sched_move_task(struct task_struct *tsk)
update_rq_clock(rq);
- running = task_running(rq, tsk);
+ running = task_current(rq, tsk);
on_rq = tsk-se.on_rq;
if (on_rq) {
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index c33f0ce..da7c061 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -511,8 +511,7 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity
*se, int initial)
if (!initial) {
/* sleeps upto a single latency don't count. */
- if (sched_feat(NEW_FAIR_SLEEPERS) entity_is_task(se)
- task_of(se)-policy != SCHED_BATCH)
+ if (sched_feat(NEW_FAIR_SLEEPERS) entity_is_task(se))
vruntime -= sysctl_sched_latency;
/* ensure we never gain time by being placed backwards. */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 1135de7..c68f68d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -225,10 +225,10 @@ static struct ctl_table root_table[] = {
};
#ifdef CONFIG_SCHED_DEBUG
-static unsigned long min_sched_granularity_ns = 10;/* 100
usecs */
-static unsigned long max_sched_granularity_ns = NSEC_PER_SEC; /* 1 second */
-static unsigned long min_wakeup_granularity_ns;/* 0
usecs */
-static unsigned long max_wakeup_granularity_ns = NSEC_PER_SEC; /* 1
Re: Do not reset xfsquota flags on quotaless ro mount
On Tue, Dec 18, 2007 at 03:04:03PM +0100, Jan Engelhardt wrote: Hi, In https://bugzilla.novell.com/show_bug.cgi?id=345338 it is claimed that resetting the quota flags in the mounting sequence rw,ro,rw is a bug, but I You mounted without quotas in the middle step, thereby invalidating them. would say this is not the case, as quota is metadata, and the log is replayed in ro mode even for other filesystems. Yet, it is still not nice, and I have been trying with this patch, which does not do the right thing yet. (It does a recovery when mounting for the 3rd time, which probably just says that I did not know too much of xfs internals to cook up a nicely working patch.) Opinions? Log recovery occurs on read only mounts. Log recovery on filesystems without quota enabled ignores quota changes in the log (as quotas are not enabled and hence we can't assume that there's dquots still on disk). Hence a mount read only without quota enabled will leave quota inconsistent on disk. i.e mount -o usrquota,grpquota /dev/mapper/myxfs /mnt umount /mnt mount -o ro /dev/mapper/myxfs /mnt Quota is now potentially inconsistent, and hence: umount /mnt mount -o usrquota,grpquota /dev/mapper/myxfs /mnt This mount *must* recalculate it. So, behaviour is as expected given the above command sequence. You should use this as the middle step: mount -o ro,usrquota,grpquota /dev/mapper/myxfs /mnt So that log replay replays all the journalled quota changes so that the quota remains consistent with the rest of the filesystem. Then you wont see a recalc when you remount rw. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c
Hi Eric, On Tue, 18 Dec 2007 09:54:42 +0800, eric miao wrote: Well, I guess it would be a smooth path if we rename the drivers/i2c/chips/pca9539.c since that's old style I2C driver, which means the driver name is not so useful external so the impact is actually minimum. That's fine with me, just send me a patch. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Do not reset xfsquota flags on quotaless ro mount
On Dec 19 2007 01:38, David Chinner wrote: In https://bugzilla.novell.com/show_bug.cgi?id=345338 it is claimed that resetting the quota flags in the mounting sequence rw,ro,rw is a bug, but I would say this is not the case, You mounted without quotas in the middle step, thereby invalidating them. That's clear to me, but according to the commenter, the filesystem is in read-only mode (that is, if no recovery was necessary for the ro mount), hence they should not be invalidated as they cannot change anyway. Or can they? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 -- INFO: possible circular locking dependency detected -- pm-suspend/5800 is trying to acquire lock
Sorry. GMail doesn't support sending unwrapped text, as far as I can tell. I will send the log segment to you as an attachment. Also, when I sent my .config inline to Andrew recently, it tripped his spam filter. I'll attach it as well. Thanks. This is a bug in iwlwifi. The problem is actually another case where my workqueue debugging with lockdep is triggering a warning :)) Here's the thing: iwl3945_cancel_deferred_work does cancel_delayed_work_sync(priv-init_alive_start); (which is the ((priv-init_alive_start)-work) lock) but it is called from within a locked section of mutex_lock(priv-mutex); (locked from iwl3945_pci_suspend) On the other hand, the task that runs from the init_alive_start workqueue is iwl3945_bg_init_alive_start() which will lock the same mutex. So the deadlock condition is that you can be in cancel_delayed_work_sync() above while the mutex is locked, and be waiting for iwl_3945_bg_init_alive_start() which tries to lock the mutex. johannes signature.asc Description: This is a digitally signed message part
Re: ip neigh show not showing arp cache entries?
Herbert Xu wrote: Chris Friesen [EMAIL PROTECTED] wrote: However, if I specifically try to print out one of the missing entries, it shows up: [EMAIL PROTECTED]:/root /tmp/ip neigh show 192.168.24.81 192.168.24.81 dev bond2 lladdr 00:01:af:14:e9:8a REACHABLE What about ip -4 neigh show Looks like that did it. Why does specifying the family make a difference? [EMAIL PROTECTED]:/root ip neigh show 10.41.18.1 dev eth6 lladdr 00:00:5e:00:01:01 STALE 172.24.137.0 dev bond0 lladdr 00:c0:8b:08:e4:88 REACHABLE 172.24.0.9 dev bond0 lladdr 00:07:e9:41:4b:b4 REACHABLE 10.41.18.101 dev eth6 lladdr 00:0e:0c:5e:95:bd REACHABLE 172.24.0.11 dev bond0 lladdr 00:03:cc:51:06:5e STALE 172.24.132.1 dev bond0 lladdr 00:01:af:14:e9:88 REACHABLE 172.24.0.15 dev bond0 lladdr 00:0e:0c:85:fd:d2 STALE 172.24.0.3 dev bond0 lladdr 00:01:af:14:c8:cc REACHABLE 172.24.0.5 dev bond0 lladdr 00:01:af:15:e0:6a STALE [EMAIL PROTECTED]:/root ip -4 neigh show 192.168.24.81 dev bond2 lladdr 00:01:af:14:e9:8a REACHABLE 172.24.132.2 dev bond0 FAILED 172.24.136.0 dev bond0 lladdr 00:c0:8b:07:b3:7e REACHABLE 10.41.18.1 dev eth6 lladdr 00:00:5e:00:01:01 STALE 172.24.137.0 dev bond0 lladdr 00:c0:8b:08:e4:88 REACHABLE 172.24.0.9 dev bond0 lladdr 00:07:e9:41:4b:b4 REACHABLE 10.41.18.101 dev eth6 lladdr 00:0e:0c:5e:95:bd REACHABLE 172.24.0.11 dev bond0 lladdr 00:03:cc:51:06:5e STALE 172.24.132.1 dev bond0 lladdr 00:01:af:14:e9:88 REACHABLE 172.24.0.15 dev bond0 lladdr 00:0e:0c:85:fd:d2 STALE 172.24.0.3 dev bond0 lladdr 00:01:af:14:c8:cc REACHABLE 172.24.0.5 dev bond0 lladdr 00:01:af:15:e0:6a STALE Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] msi: set 'En' bit of MSI Mapping Capability
According to the HyperTransport spec, 'En' indicate if the MSI Mapping is
active.
Set the 'En' bit when setup pci and add the quirk for some nvidia devices.
The patch base on kernel 2.6.24-rc5
Signed-off-by: Andy Currid [EMAIL PROTECTED]
Signed-off-by: Peer Chen [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
linux-2.6.24-rc5-vanilla/drivers/pci/probe.c
linux-2.6.24-rc5/drivers/pci/probe.c
--- linux-2.6.24-rc5-vanilla/drivers/pci/probe.c2007-12-18
14:35:46.0 -0500
+++ linux-2.6.24-rc5/drivers/pci/probe.c2007-12-18 16:28:29.0
-0500
@@ -721,6 +721,9 @@ static int pci_setup_device(struct pci_d
/* Unknown power state */
dev-current_state = PCI_UNKNOWN;
+
+ /* Enable HT MSI mapping */
+ ht_enable_msi_mapping(dev);
/* Early fixups, before probing the BARs */
pci_fixup_device(pci_fixup_early, dev);
diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
linux-2.6.24-rc5-vanilla/drivers/pci/quirks.c
linux-2.6.24-rc5/drivers/pci/quirks.c
--- linux-2.6.24-rc5-vanilla/drivers/pci/quirks.c 2007-12-18
14:35:46.0 -0500
+++ linux-2.6.24-rc5/drivers/pci/quirks.c 2007-12-18 16:28:41.0
-0500
@@ -1705,6 +1705,45 @@ static void __devinit quirk_nvidia_ck804
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
quirk_nvidia_ck804_msi_ht_cap);
+static void __devinit quirk_msi_ht_cap_disable(struct pci_dev *dev) {
+ struct pci_dev *host_bridge;
+ int pos, ttl = 48;
+
+ /* HT MSI mapping should be disabled on devices that are below
+* a non-Hypertransport host bridge. Locate the host bridge...
+*/
+
+ if ((host_bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0,0))) == NULL) {
+ printk(KERN_WARNING
+PCI: quirk_msi_ht_cap_disable didn't locate host
bridge\n);
+ return;
+ }
+
+ if ((pos = pci_find_ht_capability(host_bridge, HT_CAPTYPE_SLAVE)) != 0)
{
+ /* Host bridge is to HT */
+ return;
+ }
+
+ /* Host bridge is not to HT, disable HT MSI mapping on this device */
+
+ pos = pci_find_ht_capability(dev, HT_CAPTYPE_MSI_MAPPING);
+ while (pos ttl--) {
+ u8 flags;
+
+ if (pci_read_config_byte(dev, pos + HT_MSI_FLAGS, flags) == 0)
{
+ printk(KERN_INFO PCI: Quirk disabling HT MSI mapping
on %s\n,
+ pci_name(dev));
+
+ pci_write_config_byte(dev, pos + HT_MSI_FLAGS,
+ flags ~HT_MSI_FLAGS_ENABLE);
+ }
+ pos = pci_find_next_ht_capability(dev, pos,
+ HT_CAPTYPE_MSI_MAPPING);
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
+
quirk_msi_ht_cap_disable);
+
static void __devinit quirk_msi_intx_disable_bug(struct pci_dev *dev)
{
dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
linux-2.6.24-rc5-vanilla/include/asm-generic/pci.h
linux-2.6.24-rc5/include/asm-generic/pci.h
--- linux-2.6.24-rc5-vanilla/include/asm-generic/pci.h 2007-12-18
14:35:52.0 -0500
+++ linux-2.6.24-rc5/include/asm-generic/pci.h 2007-12-18 16:29:12.0
-0500
@@ -45,6 +45,10 @@ pcibios_select_root(struct pci_dev *pdev
#define pcibios_scan_all_fns(a, b) 0
+#ifndef HAVE_ARCH_HT_ENABLE_MSI_MAPPING
+#define ht_enable_msi_mapping(a) 0
+#endif /* HAVE_ARCH_HT_ENABLE_MSI_MAPPING */
+
#ifndef HAVE_ARCH_PCI_GET_LEGACY_IDE_IRQ
static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
{
diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
linux-2.6.24-rc5-vanilla/include/asm-x86/pci.h
linux-2.6.24-rc5/include/asm-x86/pci.h
--- linux-2.6.24-rc5-vanilla/include/asm-x86/pci.h 2007-12-18
14:35:51.0 -0500
+++ linux-2.6.24-rc5/include/asm-x86/pci.h 2007-12-18 16:28:58.0
-0500
@@ -75,6 +75,27 @@ static inline void pci_dma_burst_advice(
}
#endif
+#ifdef CONFIG_PCI
+#define HAVE_ARCH_HT_ENABLE_MSI_MAPPING
+static inline void ht_enable_msi_mapping(struct pci_dev *dev)
+{
+ int pos, ttl = 48;
+
+ pos = pci_find_ht_capability(dev, HT_CAPTYPE_MSI_MAPPING);
+ while (pos ttl--) {
+ u8 flags;
+
+ if (pci_read_config_byte(dev, pos + HT_MSI_FLAGS, flags) == 0)
{
+ printk(KERN_INFO PCI: Enabling HT MSI Mapping on %s\n,
+ dev-dev.bus_id);
+
+ pci_write_config_byte(dev, pos + HT_MSI_FLAGS,
+ flags | HT_MSI_FLAGS_ENABLE);
+ }
+ pos = pci_find_next_ht_capability(dev, pos,
Re: About mounting the sysfs
2007/12/18, Jan Engelhardt [EMAIL PROTECTED]:
On Dec 18 2007 15:10, wit wrote:
1. What is the d_alloc_root used for? Actually, the question should
be: why we have to call d_alloc_root.
I think the root already has its dentry,
It does not.
There's no dentry for the /? I mean the rootfs.
why we have to allocate another while we mounting a file
system?
2. Why we call d_alloc_root to allocate a dentry for the mount point
while the usual mount point of sysfs is defined by the user (something
like /sysfs but not /).
/sys is a dentry that belongs to the / vfsmount, but we need a
/ that belongs to the whatever you are going to mount vfsmount.
Why we need such a vfsmount (for the /, not the rootfs)? And where
we store the mount point info (path) when mount_root, s_root and the
mnt_mountpoint are all points to the / which is allocated by
d_alloc_root? Or do we have to store such info? Why?
See below:
root = d_alloc_root(inode);
if (!root) {
pr_debug(%s: could not get root dentry!\n,__FUNCTION__);
iput(inode);
return -ENOMEM;
}
root-d_fsdata = sysfs_root;
sb-s_root = root;
does this means settting the sysfs' mount point to / but not /sysfs.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] [POWERPC] Add fixed-phy support for fs_enet
On Mon, 17 Dec 2007 18:20:14 -0500 Jeff Garzik wrote: Jochen Friedrich wrote: This patch adds support to use the fixed-link property of an ethernet node to fs_enet for the CONFIG_PPC_CPM_NEW_BINDING case. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] Acked-by: Vitaly Bordug [EMAIL PROTECTED] Jochen, will you resend the patch with all acks to paulus? I'll do that if not. -- Sincerely, Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: remove Adam Fritzler, update his email address in other sources
On Mon, 17 Dec 2007 20:28:00 -0800 Andrew Morton [EMAIL PROTECTED] wrote: btw, I cheerfully skipped all your spelling-fixes patches. Some will have stuck via subsystem maintainers but I have a secret no spelling fixes unless they're end-user-visible policy. That means I'll take spelling fixes only if they're in printks or in Documentation/*. This is a little defense mechanism to avoid getting buried in micropatches. for something more productive.. add an aspell/ispell hook to checkpatch.pl ;-) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc5-mm1 - IPv6 throws section mismatches.
On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/ git-net.patch (I'm guessing one of Daniel's commits, but not sure which one) causes some complaints: LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux.o(.init.text+0x2263f): Section mismatch: reference to .exit.text:tcpv6_exit (between 'inet6_init' and 'ac6_proc_init') WARNING: vmlinux.o(.init.text+0x22644): Section mismatch: reference to .exit.text:udplitev6_exit (between 'inet6_init' and 'ac6_proc_init') WARNING: vmlinux.o(.init.text+0x22649): Section mismatch: reference to .exit.text:udpv6_exit (between 'inet6_init' and 'ac6_proc_init') WARNING: vmlinux.o(.init.text+0x22658): Section mismatch: reference to .exit.text:addrconf_cleanup (between 'inet6_init' and 'ac6_proc_init') WARNING: vmlinux.o(.init.text+0x226bc): Section mismatch: reference to .exit.text:rawv6_exit (between 'inet6_init' and 'ac6_proc_init') Looks like the problem is that tcpv6_exit and friends are called from net/ipv6/af_inet6.c:inet6_init() - which is declared as: static int __init inet6_init(void) I can see how calling an __exit from an __init would be Bad Juju... pgp060vJhETGy.pgp Description: PGP signature
Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior...
(Adding Dave Howells, his name is on iget-stop-isofs-from-using-read_inode.patch) On Tue, 18 Dec 2007 10:37:32 +0800, Dave Young said: I don't mind it failing the mount, but the oops seems excessive. I suspect that *somewhere* in that stack trace, we're wanting something like a if (!foo_ptr) return -EIO; but I admit not being competent enough to decide where that should be. Hi, Could you please try the below patch: Signed-off-by: Dave Young [EMAIL PROTECTED] --- fs/isofs/inode.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) With that patch applied, I took the ISO image (which I ended up reading on another machine and copying over the net to get a complete usable image), and dd'ed just the first 150M into another file, and tried to loopback mount it. And I got: # mount -o ro,loop /path/to/cd.partial.image /mnt/loop mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so And my dmesg says: [ 33.622073] ISO 9660 Extensions: Microsoft Joliet Level 3 [ 33.622125] attempt to access beyond end of device [ 33.622129] loop0: rw=0, want=1284500, limit=30 [ 33.622133] ISOFS: unable to read i-node block Here is where we would oops before - now it errors out more reasonably: [ 33.622140] ISOFS: changing to secondary root [ 33.622148] attempt to access beyond end of device [ 33.622151] loop0: rw=0, want=1284508, limit=30 [ 33.622155] ISOFS: unable to read i-node block [ 33.622159] isofs_fill_super: get root inode failed So that fixes *this* bug. I looked in the -rc5-mm1 broken-out/, saw the vast multitudes of 'iget-stop-foofs-from-using' patches, and decided that somebody else will probably have to audit them for sanity. In the iget-* series, there's some 184 'return ERR_PTR(-EFOO);' for some FOO, and 3 other uses: % grep ERR_PTR iget* | grep -v return iget-stop-isofs-from-using-read_inode.patch:+ inode = ERR_PTR(ret); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:+parent = ERR_PTR(-ENOMEM); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:-parent = ERR_PTR(-EACCES); iget-stop-jfs-from-using-iget-and-read_inode-try.patch:-parent = ERR_PTR(-ENOMEM); isofs is the only place we don't return a constant 'ERR_PTR(-EFOO)', but cast somebody else's return value. I wish I understood what that tells us. ;) pgppwUchT0vXx.pgp Description: PGP signature
Re: 2.6.24-rc5-mm1 - IPv6 throws section mismatches.
[EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/ git-net.patch (I'm guessing one of Daniel's commits, but not sure which one) causes some complaints: LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux.o(.init.text+0x2263f): Section mismatch: reference to .exit.text:tcpv6_exit (between 'inet6_init' and 'ac6_proc_init') WARNING: vmlinux.o(.init.text+0x22644): Section mismatch: reference to .exit.text:udplitev6_exit (between 'inet6_init' and 'ac6_proc_init') WARNING: vmlinux.o(.init.text+0x22649): Section mismatch: reference to .exit.text:udpv6_exit (between 'inet6_init' and 'ac6_proc_init') WARNING: vmlinux.o(.init.text+0x22658): Section mismatch: reference to .exit.text:addrconf_cleanup (between 'inet6_init' and 'ac6_proc_init') WARNING: vmlinux.o(.init.text+0x226bc): Section mismatch: reference to .exit.text:rawv6_exit (between 'inet6_init' and 'ac6_proc_init') Looks like the problem is that tcpv6_exit and friends are called from net/ipv6/af_inet6.c:inet6_init() - which is declared as: static int __init inet6_init(void) I can see how calling an __exit from an __init would be Bad Juju... Yep, thanks Valdis for pointing that. I sent a patch several days ago which fix that to DaveM and he applied it to the latest net-2.6.25 -- Sauf indication contraire ci-dessus: Compagnie IBM France Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 Courbevoie RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 542.737.118 ? SIREN/SIRET : 552 118 465 02430 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpuinfo_cur_freq always max
Johannes Weiner wrote: Hi, Stephen Clark [EMAIL PROTECTED] writes: Which governor are you using? ondemand? Not sure - but the only thing that is changed is the kernel - if I go back to 2.6.23.1 it works correctly. Have a look at /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Hannes PS: Steve, please keep the list in CC. userspace -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Important regression with XFS update for 2.6.24-rc6
On Tue, Dec 18, 2007 at 03:30:31PM +0100, Damien Wyart wrote: * David Chinner [EMAIL PROTECTED] [071218 13:24]: Ok. I haven't noticed anything wrong with directories up to about 250,000 files in the last few days. The ls -l I just did on a directory with 15000 entries (btree format) used about 5MB of RAM. extent format directories appear to work fine as well (tested 500 entries). Ok, nice to know the problem is not so frequent. . I have put the files at http://damien.wyart.free.fr/xfs/ strace_xfs_problem.1.gz and strace_xfs_problem.2.gz have been created with the problematic kernel, and are quite bigger than strace_xfs_problem.normal.gz, which has been created with the vanilla rc5-git5. There is also xfs_info. Looks like several getdents() through the directory the getdents() call starts outputting the first files again. It gets to a certain point and always goes back to the beginning. However, it appears to get to the end eventually (without ever getting past the bad offset). I'll ook into this more in the morning as it's not obvious what is wrong in my sleep-deprived state Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:05:31 +0300 Al Boldi [EMAIL PROTECTED] wrote: Indan Zupancic wrote: On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: I think you can better spend your time on read-only bind mounts. That would be too coarse. Actually, who needs to create device nodes? Just prohibit everyone from creating them, except installer and udev personality. This means removing CAP_MKNOD on a global scale. (OTOH, both don't need CAP_SYS_ADMIN. Maybe udev needs CAP_SYS_MODULE...) Now, stopping people from faking hotplug events is totally another story. Is that currently possible? signature.asc Description: PGP signature
