Re: 2.6.19-rc6-mm2
On Tue, 5 Dec 2006, Neil Brown wrote: > As Andrew correctly pointed out, this bit error is not a RAM problem. It > is actually the low bit of a counter a spinlock that was decremented > just before the WARN_ON. So it simply indicates that the inode had > already been freed, which I think we knew already. Unfortunately I still > have no idea why that inode had been freed but was still referenced by a > dentry How repeatable as this bug? How did you narrow it down to > that patch? Did you use git-bisect or something else? When this happened, I just looked at the broken-out patches in -mm, which ones touch the md subsystem, found your patch, reverse-applied it, and this stopped happening. It seemed to be 100% reproducible - happened on every boot of FC6 system, so it was probably triggered by some raid/lvm command executed from init scripts after boot, but I didn't examine it further. As soon as I get to the machine where this happens, I will try to narrow it down to the exact userspace command that triggers it and will let you know (probably this evening). -- Jiri Kosina - 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: PMTMR running too fast
On Mon, 2006-12-04 at 12:14 -0800, john stultz wrote: > On Mon, 2006-12-04 at 19:40 +, Ian Campbell wrote: > > On Mon, 2006-12-04 at 11:19 -0800, john stultz wrote: > > > On Sun, 2006-12-03 at 13:50 +, Ian Campbell wrote: > > > > In older kernels arch/i386/kernel/timers/timer_pm.c:verify_pmtmr_rate > > > > contained a check for sensible PMTMR rate and disabled that clocksource > > > > if it was found to be out of spec[0]. This check seems to have been lost > > > > in the transition to drivers/clocksource/acpi_pm.c, the removal is in > > > > 61743fe445213b87fb55a389c8d073785323ca3e "Time: i386 Conversion - part > > > > 4: Remove Old timer_opts Code"[1] and the check is not present in the > > > > replacement 5d0cf410e94b1f1ff852c3f210d22cc6c5a27ffa "Time: i386 > > > > Clocksource Drivers"[2]. > > > > > > Fedora has a bug covering this: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211902 > > > > > > Is there a specific reason the check was removed (I couldn't see on in > > > > the archives) or was it simply overlooked? Without it I need to pass > > > > clocksource=tsc to have 2.6.18 work correctly on an older K6 system with > > > > an Aladdin chipset (will dig out the precise details if required). Would > > > > a patch to reintroduce the check be acceptable or would some sort of > > > > blacklist based solution be more acceptable? > > > > > > If I recall correctly, it was pulled because there was some question as > > > to if it was actually needed (x86_64 didn't need it) and it slows down > > > the boot time (although not by much). > > > > > > I'm fine just re-adding it. Although if the number of affected systems > > > are small we could just blacklist it (Ian, mind sending dmidecode > > > output?). > > I don't have a dev box to test on at the moment, but here's a quick hack > attempt at re-adding the code. Does the following work for you? I get: PM-Timer running at invalid rate: 200% of normal - aborting. ... Time: pit clocksource has been installed. Without the clocksource parameter. Should tsc be preferred to pit though? /sys/devices/system/clocksource/clocksource0/available_clocksource now shows "jiffies tsc pit" and current_clocksource is "pit". Thanks, Ian. -- Ian Campbell love, n.: When it's growing, you don't mind watering it with a few tears. signature.asc Description: This is a digitally signed message part
Re: [PATCH] mm: D-cache aliasing issue in cow_user_page
In light of James Bottomsley's commit[1] declaring that kmap() and friends now have to take care of coherency issues, is the patch "mm: D-cache aliasing issue in cow_user_page"[2] correct, or could it potentially cause a slowdown by calling flush_dcache_page() a second time (i.e. once in an architecture-specific kmap() implementation, and once in cow_user_page())? Matt [1] http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a6ca1b99ed434f3fb41bbed647ed36c0420501e5 [2] http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c4ec7b0de4bc18ccb4380de638550984d9a65c25 - 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] CPEI gets warning at kernel/irq/migration.c:27/move_masked_irq()
Hi,
While running my MCA test (hardware error injection) on 2.6.19,
I got some warning like following:
> BUG: warning at kernel/irq/migration.c:27/move_masked_irq()
>
> Call Trace:
> [] show_stack+0x40/0xa0
> sp=e0006b2578d0 bsp=e0006b2510b0
> [] dump_stack+0x30/0x60
> sp=e0006b257aa0 bsp=e0006b251098
> [] move_masked_irq+0xb0/0x240
> sp=e0006b257aa0 bsp=e0006b251070
> [] move_native_irq+0xe0/0x180
> sp=e0006b257aa0 bsp=e0006b251040
> [] iosapic_end_level_irq+0x30/0xe0
> sp=e0006b257aa0 bsp=e0006b251020
> [] __do_IRQ+0x170/0x400
> sp=e0006b257aa0 bsp=e0006b250fd8
> [] ia64_handle_irq+0x1b0/0x260
> sp=e0006b257aa0 bsp=e0006b250fa8
> [] ia64_leave_kernel+0x0/0x280
> sp=e0006b257aa0 bsp=e0006b250fa8
> [] _spin_unlock_irqrestore+0x30/0x60
> sp=e0006b257c70 bsp=e0006b250f90
It comes from:
[kernel/irq/migration.c]
26 if (CHECK_IRQ_PER_CPU(desc->status)) {
27 WARN_ON(1);
28 return;
29 }
By putting some printk in kernel, I found that irqbalance is trying to
move CPEI which is handled as PER_CPU irq. That's why.
CPEI(Corrected Platform Error Interrupt) is ia64 specific irq, is
allowed to pin to particular processor which selected by the platform, and
even it is PER_CPU but it has set_affinity handler (=iosapic_set_affinity)
as same as other IO-SAPIC-level interrupts. (I don't know why, but
I guess that there would be typical situation where the handler for
migration is needed, such as hotplug - the processor going to be
offline/hot-removed.)
To shut up this warning, there are 2 way at least:
a) fix CPEI stuff
b) prohibit setting affinity to PER_CPU irq
I'm not sure what stuff of CPEI need to be fixed, but I think that
returning error to attempting move PER_CPU irq is useful for all
applications since it will never work.
Following small patch takes b) style.
It works, the warning disappeared and irqbalance still runs well.
Thanks,
H.Seto
Signed-off-by: Hidetoshi Seto <[EMAIL PROTECTED]>
---
kernel/irq/proc.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.19/kernel/irq/proc.c
===
--- linux-2.6.19.orig/kernel/irq/proc.c
+++ linux-2.6.19/kernel/irq/proc.c
@@ -54,7 +54,8 @@ static int irq_affinity_write_proc(struc
unsigned int irq = (int)(long)data, full_count = count, err;
cpumask_t new_value, tmp;
- if (!irq_desc[irq].chip->set_affinity || no_irq_affinity)
+ if (!irq_desc[irq].chip->set_affinity || no_irq_affinity ||
+ CHECK_IRQ_PER_CPU(irq_desc[irq].status))
return -EIO;
err = cpumask_parse_user(buffer, count, new_value);
-
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: la la la la ... swappiness
Nick Piggin wrote: Aucoin wrote: Ummm, shm_open, ftruncate, mmap ? Is it a trick question ? The process responsible for initially setting up the shared area doesn't stay resident. The issue is that the shm pages should show up in the active and inactive lists. But they aren't, and you seem to have about 1542524K unacconted for. Weird. Can you try getting the output of /proc/vmstat as well? Haven't followed along on this thread, but couldn't help notice the ftruncate there and some similarity to a problem I once experienced myself. Is ext3 involved? If so, maybe: http://mail.nl.linux.org/linux-mm/2002-11/msg00110.html is still or again being annoying? Rene. - 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/3] New firewire stack
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Tue, 05 Dec 2006 16:42:42 +1100 > - It's horribly broken in at least two area : > > DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!! > > and > > Where do you handle endianness ? (no need to shout for > that one). > > (Or in general, do not use bitfields period ) Yes, this is a show stopper, the endianness and word-size/endian testing should have been done before submission. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
On Mon, Dec 04 2006, Andrew Morton wrote: > > > > > libata_resume_fix.patch > > > > I thought this was resolved long ago? Are there still open reports that > > this solves, where upstream doesn't work? > > Heck, I don't know. I'm not aware of any, and resume works for me. Did that patch ever get verified as fixing something for anybody? I think it can be safely dropped. -- Jens Axboe - 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: la la la la ... swappiness
Aucoin wrote: From: Linus Torvalds [mailto:[EMAIL PROTECTED] I actually suspect you should be _fairly_ close to such a situation We run with min_free_kbytes set around 4k to answer your earlier question. Louis, exactly how do you allocate that big 1.6GB shared area? Ummm, shm_open, ftruncate, mmap ? Is it a trick question ? The process responsible for initially setting up the shared area doesn't stay resident. The issue is that the shm pages should show up in the active and inactive lists. But they aren't, and you seem to have about 1542524K unacconted for. Weird. Can you try getting the output of /proc/vmstat as well? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Status of buffered write path (deadlock fixes)
Hi, I'd like to try to state where we are WRT the buffered write patches, and ask for comments. Sorry for the wide cc list, but this is an important issue which hasn't had enough review. Well the next -mm will include everything we've done so far. I won't repost patches unless someone would like to comment on a specific one. I think the core generic_file_buffered_write is fairly robust, after fixing the efault and zerolength iov problems picked up in testing (thanks, very helpful!). So now I *believe* we have an approach that solves the deadlock and doesn't expose transient or stale data, transient zeroes, or anything like that. Error handling is getting close, but there may be cases that nobody has picked up, and I've noticed a couple which I'll explain below. I think we do the right thing WRT pagecache error handling: a !uptodate page remains !uptodate, an uptodate page can handle the write being done in several parts. Comments in the patches attempt to explain how this works. I think it is pretty straightforward. But WRT block allocation in the case of errors, it needs more review. Block allocation: - prepare_write can allocate blocks - prepare_write doesn't need to initialize the pagecache on top of these blocks where it is within the range specified in prepare_write (because the copy_from_user will initialise it correctly) - In the case of a !uptodate page, unless the page is brought uptodate (ie the copy_from_user completely succeeds) and marked dirty, then a read that sneaks in after we unlock the page (to retry the write) will try to bring it uptodate by pulling in the uninitialised blocks. Problem 1: I think that allocating blocks outside i_size is OK WRT uninitialised data, because we update i_size only after a successful copy. However, I don't think we trim these blocks off (eg. perhaps the "prepare_write may have instantiated a few blocks" path should be the normal error path for both the copy_from_user and the commit_write error cases as well?) We allocate blocks within holes, but these don't need to be trimmed: it is enough to just zero out any new buffers. It might be nicer if we had some kind of way to punch a hole, but it is a rare corner case. Problem 2: nobh error handling[*]. We have just a single buffer that is used for each block in the prepare_write path, so the "zero new buffers" trick doesn't work. I think one solution to this could be to allocate all buffers for the page like normal, and then strip them off when commit_write succeeds? This would allow the zero_new_buffers path to work properly. [*] Actually I think there is a problem with the mainline nobh error handling in that a whole page of blocks will get zeroed on failure, even valid data that isn't being touched by the write. Finally, filesystems. Only OGAWA Hirofumi and Mark Fasheh have given much feedback so far. I've tried to grok ext2/3 and think they'll work OK, and have at least *looked* at all the rest. However in the worst case, there might be many subtle and different problems :( Filesystem developers need to review this, please. I don't want to cc every filesystem dev list, but if anybody thinks it would be helpful to forward this then please do. Well, that's about where its at. Block allocation problems 1 and 2 shouldn't be too hard to fix, but I would like confirmation / suggestions. Thanks, Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.19-rt1, yum/rpm
Am Dienstag, 5. Dezember 2006 01:19 schrieb Karsten Wiese: > Am Donnerstag, 30. November 2006 09:33 schrieb Ingo Molnar: > > i have released the 2.6.19-rt1 tree, which can be downloaded from the > > Hi Ingo, > > here comes a freerunning trace explaining the weirdness I see here. > I tried max_latency tracing first, didn't see anything usefull, > went on with tracing freerunning with a user_trace_stop() at the spot, > where snd-usb-usx2y diagnoses hickup. Seams to hickup when irq happens while uhci_hcd is busy doing some kind of timer triggered housekeeping. Will look into uhci code deeper ;-) Karsten - 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/
in HP nx8220 S3 resume does not work in stock kernels 2.6.15-2.6.19. Ide light stays on.
Hi,
in HP nx8220 S3 resume does not work in stock kernels 2.6.15-2.6.19.
Ide light stays on.
The attached patch for ide.c for 2.6.18.2 fixes this for me, but the
patch does not apply anymore in 2.6.19.
http://bugzilla.kernel.org/show_bug.cgi?id=2039
http://bugzilla.kernel.org/show_bug.cgi?id=5604
-honkkis
--- linux-2.6.18.2-orig/drivers/ide/ide.c 2006-11-04 03:33:58.0
+0200
+++ linux-2.6.18.2/drivers/ide/ide.c2006-11-11 00:44:44.0 +0200
@@ -1207,6 +1207,237 @@
EXPORT_SYMBOL(system_bus_clock);
+#if 1
+#include
+#define DBG(x...) printk(x)
+static int ide_acpi_find_device(struct device *dev, acpi_handle *handle)
+{
+ int i, tmp;
+ acpi_integer addr;
+
+ if (sscanf(dev->bus_id, "%u.%u", , ) != 2)
+ return -ENODEV;
+
+ addr = i;
+ *handle = acpi_get_child(DEVICE_ACPI_HANDLE(dev->parent), addr);
+ if (!*handle)
+ return -ENODEV;
+ return 0;
+}
+
+/* This assumes the ide controller is a PCI device */
+static int ide_acpi_find_channel(struct device *dev, acpi_handle *handle)
+{
+ int num;
+ int channel;
+ acpi_integer addr;
+
+ num = sscanf(dev->bus_id, "ide%x", );
+
+ if (num != 1 || !dev->parent)
+ return -ENODEV;
+ addr = channel;
+ *handle = acpi_get_child(DEVICE_ACPI_HANDLE(dev->parent), addr);
+ if (!*handle)
+ return -ENODEV;
+ return 0;
+}
+
+static struct acpi_bus_type ide_acpi_bus = {
+ .bus = _bus_type,
+ .find_device = ide_acpi_find_device,
+ .find_bridge = ide_acpi_find_channel,
+};
+
+static int __init ide_acpi_init(void)
+{
+ return register_acpi_bus_type(_acpi_bus);
+}
+
+#define MAX_DEVICES 10
+#define GTM_LEN (sizeof(u32) * 5)
+static struct acpi_ide_stat {
+ acpi_handle handle; /* channel device"s handle */
+ u32 gtm[GTM_LEN/sizeof(u32)]; /* info from _GTM */
+ struct hd_driveid id_buff[2];
+ int channel_handled;
+} device_state[MAX_DEVICES];
+
+static struct acpi_ide_stat *ide_get_acpi_state(acpi_handle handle)
+{
+ int i;
+ for (i = 0; i < MAX_DEVICES; i ++)
+ if (device_state[i].handle == handle)
+ break;
+ if (i < MAX_DEVICES)
+ return _state[i];
+ for (i = 0; i < MAX_DEVICES; i ++)
+ if (device_state[i].handle == NULL)
+ break;
+ if (i >= MAX_DEVICES)
+ return NULL;
+
+ memset(_state[i], 0, sizeof(struct acpi_ide_stat));
+ return _state[i];
+}
+
+int acpi_ide_suspend(struct device *dev)
+{
+ acpi_handle handle, parent_handle;
+ struct acpi_ide_stat *stat;
+ acpi_status status;
+ struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
+ union acpi_object *package;
+ ide_drive_t *drive = dev->driver_data;
+ int drive_id = 0;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+ if (!handle) {
+ DBG("IDE device ACPI handler is NULL\n");
+ return -ENODEV;
+ }
+ if (ACPI_FAILURE(acpi_get_parent(handle, _handle))) {
+ printk(KERN_ERR "ACPI get parent handler error\n");
+ return -ENODEV;
+ }
+ stat = ide_get_acpi_state(parent_handle);
+ if (stat == NULL)
+ return -ENODEV;
+ if (stat->channel_handled) {
+ drive_id = 1;
+ goto id;
+ }
+
+ status = acpi_evaluate_object(parent_handle, "_GTM", NULL, );
+ if (ACPI_FAILURE(status)) {
+ printk(KERN_ERR "Error evaluating _GTM\n");
+ return -ENODEV;
+ }
+ package = (union acpi_object *) buffer.pointer;
+ if (package->buffer.length != GTM_LEN) {
+ printk(KERN_ERR "Buffer length returned by _GTM is wrong\n");
+ kfree(buffer.pointer);
+ return -ENODEV;
+ }
+ memcpy(stat->gtm, package->buffer.pointer, GTM_LEN);
+ stat->handle = parent_handle;
+ stat->channel_handled = 1;
+ kfree(buffer.pointer);
+id:
+ taskfile_lib_get_identify(drive, >id_buff[drive_id]);
+ DBG("GTM info %x,%x,%x,%x,%x\n", stat->gtm[0],
+ stat->gtm[1], stat->gtm[2],
+ stat->gtm[3], stat->gtm[4]);
+ return 0;
+}
+
+static int acpi_ide_stm(struct acpi_ide_stat *stat)
+{
+ struct acpi_object_list input;
+ union acpi_object params[3];
+ acpi_status status;
+
+ input.count = 3;
+ input.pointer = params;
+ params[0].type = ACPI_TYPE_BUFFER;
+ params[0].buffer.length = sizeof(stat->gtm);
+ params[0].buffer.pointer = (char*)stat->gtm;
+
+ params[1].type = ACPI_TYPE_BUFFER;
+ params[1].buffer.length = sizeof(stat->id_buff[0]);
+ params[1].buffer.pointer = (char *)>id_buff[0];
+
+ params[2].type = ACPI_TYPE_BUFFER;
+ params[2].buffer.length = sizeof(stat->id_buff[1]);
+
RE: la la la la ... swappiness
> From: Linus Torvalds [mailto:[EMAIL PROTECTED] > I actually suspect you should be _fairly_ close to such a situation We run with min_free_kbytes set around 4k to answer your earlier question. > Louis, exactly how do you allocate that big 1.6GB shared area? Ummm, shm_open, ftruncate, mmap ? Is it a trick question ? The process responsible for initially setting up the shared area doesn't stay resident. - 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: mmc: pxamci compilation fix
Sascha Hauer wrote: > Hi Pierre and all, > > since commit fcaf71fd51f9cfc504455d3e19ec242e4b2073ed > struct mmc_host does not have a dev field. Retrieve the device with > mmc_dev() instead. > > Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]> > Bad Greg ;) Applied, thanks. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Add device probing, sysfs interface and char device code.
This patch add code to probe devices and integrate with the device model,
adds minimal sysfs structure and implements a char device for user space
control.
---
drivers/fw/Makefile |3
drivers/fw/fw-device-cdev.c | 580 +
drivers/fw/fw-device-cdev.h | 141 ++
drivers/fw/fw-device.c | 611 +++
drivers/fw/fw-device.h | 156 +++
drivers/fw/fw-topology.c|4
6 files changed, 1490 insertions(+), 5 deletions(-)
diff --git a/drivers/fw/Makefile b/drivers/fw/Makefile
index 1b2a3ad..fb6003e 100644
--- a/drivers/fw/Makefile
+++ b/drivers/fw/Makefile
@@ -2,6 +2,7 @@ #
# Makefile for the Linux IEEE 1394 implementation
#
-fw-core-objs := fw-card.o fw-topology.o fw-transaction.o fw-iso.o
+fw-core-objs := fw-card.o fw-topology.o fw-transaction.o fw-iso.o \
+ fw-device.o fw-device-cdev.o
obj-$(CONFIG_FW_CORE) += fw-core.o
diff --git a/drivers/fw/fw-device-cdev.c b/drivers/fw/fw-device-cdev.c
new file mode 100644
index 000..d3f14bd
--- /dev/null
+++ b/drivers/fw/fw-device-cdev.c
@@ -0,0 +1,580 @@
+/* -*- c-basic-offset: 8 -*-
+ *
+ * fw-device-cdev.c - Char device for device raw access
+ *
+ * Copyright © 2005 Kristian Høgsberg <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "fw-transaction.h"
+#include "fw-topology.h"
+#include "fw-device.h"
+#include "fw-device-cdev.h"
+
+/*
+ * todo
+ *
+ * - bus resets sends a new packet with new generation and node id
+ *
+ */
+
+/* This struct is embedded just before the actual data, so event.data
+ * becomes the data to copy to user space. Also, since
+ * dequeue_event() just kfree()'s the event, the event has to be the
+ * first field in the struct. */
+
+struct event {
+ size_t immediate_size;
+ size_t indirect_size;
+ struct list_head link;
+ void *indirect;
+ u32 immediate[0];
+};
+
+struct response {
+ struct fw_transaction transaction;
+ struct client *client;
+ struct event event;
+ struct fw_cdev_event_response response;
+};
+
+struct iso_interrupt {
+ struct event event;
+ struct fw_cdev_event_iso_interrupt interrupt;
+};
+
+struct client {
+ struct fw_device *device;
+ spinlock_t lock;
+ struct list_head handler_list;
+ struct list_head request_list;
+ u32 request_serial;
+ struct list_head event_list;
+ struct semaphore event_list_sem;
+ wait_queue_head_t wait;
+ unsigned long vm_start;
+ struct fw_iso_context *iso_context;
+};
+
+static int fw_device_op_open(struct inode *inode, struct file *file)
+{
+ struct fw_device *device;
+ struct client *client;
+
+ device = container_of(inode->i_cdev, struct fw_device, cdev);
+
+ client = kzalloc(sizeof *client, GFP_KERNEL);
+ if (client == NULL)
+ return -ENOMEM;
+
+ client->device = fw_device_get(device);
+ INIT_LIST_HEAD(>event_list);
+ sema_init(>event_list_sem, 0);
+ INIT_LIST_HEAD(>handler_list);
+ INIT_LIST_HEAD(>request_list);
+ spin_lock_init(>lock);
+ init_waitqueue_head(>wait);
+
+ file->private_data = client;
+
+ return 0;
+}
+
+static void queue_event(struct client *client, struct event *event)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+
+ list_add_tail(>link, >event_list);
+
+ up(>event_list_sem);
+ wake_up_interruptible(>wait);
+
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+static int dequeue_event(struct client *client, char *buffer, size_t count)
+{
+ unsigned long flags;
+ struct event *event;
+ int retval;
+
+ if (down_interruptible(>event_list_sem) < 0)
+ return -EINTR;
+
+ spin_lock_irqsave(>lock, flags);
+
+ event = container_of(client->event_list.next, struct event, link);
+ list_del(>link);
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ retval = min(event->immediate_size, count);
+ if (buffer && copy_to_user(buffer, event->immediate, retval))
+
[PATCH 0/2] fw-core resend
Oops, looks like the fw-core patch was to big for the list. I've split it into two parts: fw-core which is the transaction logic and bus reset handling and fw-device which is device probing and sysfs integration. cheers, Kristian - 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/3] New firewire stack
Benjamin Herrenschmidt wrote: On Tue, 2006-12-05 at 00:22 -0500, Kristian Høgsberg wrote: Hi, I'm announcing an alternative firewire stack that I've been working on the last few weeks. I'm aiming to implement feature parity with the current firewire stack, but not necessarily interface compatibility. For now, I have the low-level OHCI driver done, the mid-level transaction logic done, and the SBP-2 (storage) driver is basically done. What's missing is a streaming interface (in progress) to allow reception and transmission of isochronous data and a userspace interface for controlling devices (much like raw1394 or libusb for usb). I'm working out of this git repository: A very very very quick look at the code shows that: - It looks nice / clear Great, good to hear. - It's horribly broken in at least two area : DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!! and Where do you handle endianness ? (no need to shout for that one). Well, the code isn't big-endian safe yet, but the only place where I expect to have to fix this is in fw-ohci.c. I need to figure out how I want to set up the OHCI controller to this - it has a couple of bits to control this. All data outside the low-level driver is cpu-endian, with the exception of payload data. IEEE1394 doesn't specify an endianness for the payload data, even though most protocols use big-endian.Some protocols have a mix of byte-arrays and be32 words (eg SBP-2) so it's up to the protocol to byteswap its data as appropriate. (Or in general, do not use bitfields period ) bitfields format is not guaranteed, and is not endian consistent. Ok... I was planning to make big-endian versions of the structs so that the endian issue would be solved. But if the bit layout is not consistent, I guess bitfields are useless for wire formats. I didn't know that though, I thought the C standard specified that the compiler should allocate bits out of a word using the lower bits first. Is the problem that it allocates them out of a 64-bit word on 64-bit platforms? cheers, Kristian - 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] add an iterator index in struct pagevec
Andrew Morton wrote on Monday, December 04, 2006 9:45 PM > On Mon, 4 Dec 2006 21:21:31 -0800 > "Chen, Kenneth W" <[EMAIL PROTECTED]> wrote: > > > pagevec is never expected to be more than PAGEVEC_SIZE, I think a > > unsigned char is enough to count them. This patch makes nr, cold > > to be unsigned char > > Is that on the right side of the speed/space tradeoff? I haven't measured speed. Size wise, making them char shrinks vmlinux text size by 112 bytes on x86_64 (using default config option). > I must say I'm a bit skeptical about the need for this. But I haven't > looked closely at the blockdev-specific dio code yet. It was suggested to declare another struct that embeds pagevec to perform iteration. But I prefer to have pagevec having the capability, it is more compact this way. It would be nice if you can review blockdev-specific dio code. I would appreciate it very much. - Ken - 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.18-rc7-git1: AHCI not seeing devices on ICH8 mobo (DG965RY)
On Sun, 2006-09-17 16:49:29, Tejun Heo wrote: > Can you please try the attached patch? I'm seeing the same problem reported by Robin Johnson: that is, the first two SATA disks are seen by the Linux kernel but the third is not. The third drive is seen by the BIOS. I attempted to apply the patch posted by Tejun Heo on 2006-09-17 but it won't apply against a 2.6.19 kernel. The patch-2.6.19-git6 diff doesn't contain the needed changes. Is there a patch compatible with the current source tree? The reason I ask is that I installed a Intel DP964LT mainboard in my worksation today (to resolve a SATA silent data corruption problem with a ASUS nVidia nForce 4 mainboard). Should I try to adapt the patch from September for the 2.6.19 kernel source or is there an easier option? I've already spent nearly a week debugging the silent data corruption problem that caused me to switch mainboards and CPUs and I'm eager to get back to my real job of solving my customer's problems rather than mine :-) -- Kurtis D. Rader, Linux level 3 support email: [EMAIL PROTECTED] IBM Integrated Technology Services DID: +1 503-578-3714 15300 SW Koll Pkwy, MS RHE2-O2 service: 800-IBM-SERV Beaverton, OR 97006-6063http://www.ibm.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Import fw-sbp2 driver.
Kristian Høgsberg wrote:
Pull in the fw-sbp2 driver for firewire storage devices.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
---
drivers/fw/fw-ohci.c |2
drivers/fw/fw-sbp2.c | 1083 ++
2 files changed, 1084 insertions(+), 1 deletions(-)
diff --git a/drivers/fw/fw-ohci.c b/drivers/fw/fw-ohci.c
index 78e0324..444e8f0 100644
--- a/drivers/fw/fw-ohci.c
+++ b/drivers/fw/fw-ohci.c
@@ -594,7 +594,7 @@ static void bus_reset_tasklet(unsigned l
self_id_count, ohci->self_id_buffer);
}
-static irqreturn_t irq_handler(int irq, void *data, struct pt_regs *unused)
+static irqreturn_t irq_handler(int irq, void *data)
{
struct fw_ohci *ohci = data;
u32 event, iso_event;
diff --git a/drivers/fw/fw-sbp2.c b/drivers/fw/fw-sbp2.c
new file mode 100644
index 000..e0e7590
--- /dev/null
+++ b/drivers/fw/fw-sbp2.c
@@ -0,0 +1,1083 @@
+/* -*- c-basic-offset: 8 -*-
+ * fw-sbp2.c -- SBP2 driver (SCSI over IEEE1394)
+ *
+ * Copyright © 2005 Kristian Høgsberg <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "fw-transaction.h"
+#include "fw-topology.h"
+#include "fw-device.h"
+
+/* I don't know why the SCSI stack doesn't define something like this... */
+typedef void (*scsi_done_fn_t) (struct scsi_cmnd *);
submit a patch?
+static const char sbp2_driver_name[] = "sbp2";
+
+struct sbp2_device {
+ struct fw_address_handler address_handler;
+ struct list_head orb_list;
+ u64 management_agent_address;
+ u64 command_block_agent_address;
+ u32 workarounds;
+ int login_id;
+
+ /* We cache these addresses and only update them once we've
+* logged in or reconnected to the sbp2 device. That way, any
+* IO to the device will automatically fail and get retried if
+* it happens in a window where the device is not ready to
+* handle it (e.g. after a bus reset but before we reconnect). */
+ int node_id;
+ int address_high;
+ int generation;
+
+ struct work_struct work;
+ struct Scsi_Host *scsi_host;
+};
+
+#define SBP2_MAX_SG_ELEMENT_LENGTH 0xf000
+#define SBP2_MAX_SECTORS 255 /* Max sectors supported */
+#define SBP2_MAX_CMDS 8 /* This should be safe */
+
+#define SBP2_ORB_NULL 0x8000
+
+#define SBP2_DIRECTION_TO_MEDIA0x0
+#define SBP2_DIRECTION_FROM_MEDIA 0x1
+
+/* Unit directory keys */
+#define SBP2_COMMAND_SET_SPECIFIER 0x38
+#define SBP2_COMMAND_SET 0x39
+#define SBP2_COMMAND_SET_REVISION 0x3b
+#define SBP2_FIRMWARE_REVISION 0x3c
+
+/* Flags for detected oddities and brokeness */
+#define SBP2_WORKAROUND_128K_MAX_TRANS 0x1
+#define SBP2_WORKAROUND_INQUIRY_36 0x2
+#define SBP2_WORKAROUND_MODE_SENSE_8 0x4
+#define SBP2_WORKAROUND_FIX_CAPACITY 0x8
+#define SBP2_WORKAROUND_OVERRIDE 0x100
+
+/* Management orb opcodes */
+#define SBP2_LOGIN_REQUEST 0x0
+#define SBP2_QUERY_LOGINS_REQUEST 0x1
+#define SBP2_RECONNECT_REQUEST 0x3
+#define SBP2_SET_PASSWORD_REQUEST 0x4
+#define SBP2_LOGOUT_REQUEST0x7
+#define SBP2_ABORT_TASK_REQUEST0xb
+#define SBP2_ABORT_TASK_SET0xc
+#define SBP2_LOGICAL_UNIT_RESET0xe
+#define SBP2_TARGET_RESET_REQUEST 0xf
+
+/* Offsets for command block agent registers */
+#define SBP2_AGENT_STATE 0x00
+#define SBP2_AGENT_RESET 0x04
+#define SBP2_ORB_POINTER 0x08
+#define SBP2_DOORBELL 0x10
+#define SBP2_UNSOLICITED_STATUS_ENABLE 0x14
+
+/* Status write response codes */
+#define SBP2_STATUS_REQUEST_COMPLETE 0x0
+#define SBP2_STATUS_TRANSPORT_FAILURE 0x1
+#define SBP2_STATUS_ILLEGAL_REQUEST0x2
+#define SBP2_STATUS_VENDOR_DEPENDENT 0x3
consider enum{} rather than #define
+struct sbp2_status {
+ unsigned int orb_high:16;
unsigned short? probably generates better code than a bitfield:16
+ unsigned int sbp_status:8;
unsigned char?
+
Re: [PATCH 2/3] Import fw-ohci driver.
> > +struct descriptor {
> > + u32 req_count:16;
> > +
> > + u32 wait:2;
> > + u32 branch:2;
> > + u32 irq:2;
> > + u32 yy:1;
> > + u32 ping:1;
> > +
> > + u32 key:3;
> > + u32 status:1;
> > + u32 command:4;
> > +
> > + u32 data_address;
> > + u32 branch_address;
> > +
> > + u32 res_count:16;
> > + u32 transfer_status:16;
> > +} __attribute__ ((aligned(16)));
>
> you probably want __le32 annotations for sparse, right?
More than that... he wants no bitfields ! Right now, this code is broken
on some endians (I suspect big, dunno on what Kristian tested).
>
> And for the last two fields, I bet that using the normal 'u16' type
> (__le16?) would generate much better code than a bitfield:16 ever would.
Bah, it's endian broken anyway due to bitfield (ab)use.
> enum {
> constant1 = 1234,
> constant2 = 5678,
> };
>
> for constants. These actually have some type information attached by
> the compiler, and they show up as symbols in the debugger since they are
> not stripped out by the C pre-processor.
Note that while this is true for small constants, beware of the fact
that this is highly unrecommended for anything that doesn't fit in a
signed int. gcc has some dodgy extensions allowing non-int enums but you
don't want to go near them. Read a recent discussion with Linus & Viro
(a few days ago iirc) on lkml about it.
Since some of his constants have values up to 0x8000, I'm not 100%
confident enum is the way to go, but if you are careful with sign, it
could still be.
> > +static void ar_context_run(struct ar_context *ctx)
> > +{
> > + reg_write(ctx->ohci, ctx->command_ptr, ctx->descriptor_bus | 1);
> > + reg_write(ctx->ohci, ctx->control_set, CONTEXT_RUN);
>
> PCI posting?
In that specific case (kicking the context), it doesn't matter much.
It's not a bug per-se not to do it, though you might get better
performances by making sure it's kicked right away.
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/
Re: [PATCH] Add Broadcom PHY support
> I believe that this fiber enabling can be done by defining config_init in the
> phy_driver struct.
>
> struct phy_driver {
>
> /* Called to initialize the PHY,
>* including after a reset */
> int (*config_init)(struct phy_device *phydev);
>
> };
Well... I don't know for sure... thing is, enabling the fiber mode is a
rather platform specific thing. So it's the MAC driver that knows wether
it wants it on a PHY and should call into the driver.
It's difficult to abstract all possible PHY config options tho... some
MACs might want to enable low power, some don't because they have issues
with it, that sort of thing, though.
Not sure what the best solution is at this point... Maybe an ascii
string to pass the PHY driver is the most flexible, though a bit yucky,
or we try to have a list of all the possible configuration options in
phy.h and people just add new ones that they need as they add support
for them...
Sounds grossly like an in-kernel ioctl tho...
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/
Oops in pata_pdc2027x
Hi all,
I get an oops during initialisation of the pata_pdc2027x module on a
POWER 285 machine. This is on a very recent Linus kernel tree
(ff51a98799931256b555446b2f5675db08de6229) with Paulus' powerpc tree
(that has now been merged). The oops looks like this:
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...pata_pdc2027x 0001:cc:01.0: PLL input
clock 32721 kHz
ata1: PATA max UDMA/133 cmd 0xD800801457C0 ctl 0xD80080145FDA bmdma
0xD80080145000 irq 324
ata2: PATA max UDMA/133 cmd 0xD800801455C0 ctl 0xD80080145DDA bmdma
0xD80080145008 irq 324
scsi1 : pata_pdc2027x
ata1.00: ATAPI, max UDMA/66
Unable to handle kernel paging request for data at address 0xc001007e8d80
Faulting instruction address: 0xd007b660
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: pata_pdc2027x dm_mirror dm_snapshot ipr libata
NIP: D007B660 LR: D007B628 CTR:
REGS: c000f4e3b5a0 TRAP: 0300 Not tainted (2.6.19comb)
MSR: 80009032 CR: 2480 XER: 2009
DAR: C001007E8D80, DSISR: 4001
TASK = c7001040[3393] 'scsi_eh_1' THREAD: c000f4e38000 CPU: 2
GPR00: 0001 C000F4E3B820 D00A95C0 CFA946E8
GPR04: C000F4E3B960 0003 C000F4E3B890
GPR08: 0001 C07E8D80 D80080145110 C0033A34
GPR12: C056FF80 C04751C8
GPR16: 41C0 C0473B90 0035D800
GPR20: 0213AF30 C053AF30 C000F4E3BB10 0001
GPR24: 0002 C000F4E3B960 CFA946E8
GPR28: 0003 4000 D00A7980
NIP [D007B660] .ata_exec_internal+0x8c/0xf8 [libata]
LR [D007B628] .ata_exec_internal+0x54/0xf8 [libata]
Call Trace:
[C000F4E3B820] [D00A7980] .ipr_store_update_fw+0x100/0x6f0 [ipr]
(unreliable)
[C000F4E3B8F0] [D007C15C] .ata_set_mode+0x4dc/0x6d0 [libata]
[C000F4E3B9D0] [D00860E0] .ata_do_eh+0x1538/0x1930 [libata]
[C000F4E3BC20] [D0083774] .ata_bmdma_drive_eh+0x1f8/0x2e8 [libata]
[C000F4E3BCD0] [D00C17B4] .pdc2027x_error_handler+0x28/0x40
[pata_pdc2027x]
[C000F4E3BD50] [D0086DC0] .ata_scsi_error+0x32c/0x660 [libata]
[C000F4E3BE00] [C0312F7C] .scsi_error_handler+0xc8/0x80c
[C000F4E3BEE0] [C006A0F4] .kthread+0x124/0x174
[C000F4E3BF90] [C0024D68] .kernel_thread+0x4c/0x68
Instruction dump:
57ac053e e93e8020 7f63db78 7f44d378 780007c6 7f25cb78 7f86e378 38e10070
7fbd0214 3901 7ba0f860 78001f24 <7d69002a> 7ba0a302 7bbd4602 3920
done.
(The reference to ipr_store_update_fw is certainly not real)
The config, lspci and full boot dmesg output are available at
http://ozlabs.org/~sfr/{config,lspci,dmesg}
This machine has a only cdrom drive attached to the pdc controller.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpimsSAJWOgN.pgp
Description: PGP signature
Re: data corruption with nvidia chipsets and IDE/SATA drives
On Sat, 2006-12-02 17:17:37, Kurtis D. Rader wrote: > I'm also experiencing silent data corruption on writes to SATA disks > connected to a Nvidia controller (nForce 4 chipset). The problem is > 100% reproducible. Details of my configuration (mainboard model, lspci, > etc.) are near the bottom of this message. What follows is a summation > of my findings. Various suggestions (e.g., booting with "acpi=off") have either not helped or have resulted in a system which won't boot. Today I replaced the ASUS A8N (nVidia nForce 4 chipset) mainboard and AMD Athlon 64 CPU with a Intel DP965LT (Intel 965 chipset) and E6600 Duo Core 2 CPU. The SATA disks and cables are unchanged. The case, power supply, and video card are also unchanged. Not one of the previous tests now results in corruption. If anyone (e.g., a nVidia employee) wants to pursue this and can provide a meaningful action plan I'll be happy to install the problem components in another case and attempt to gather additional diagnostic data. -- Kurtis D. Rader, Linux level 3 support email: [EMAIL PROTECTED] IBM Integrated Technology Services DID: +1 503-578-3714 15300 SW Koll Pkwy, MS RHE2-O2 service: 800-IBM-SERV Beaverton, OR 97006-6063http://www.ibm.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Import fw-ohci driver.
Kristian Høgsberg wrote:
Add the OHCI driver to the stack and build system.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
---
drivers/fw/fw-ohci.c | 1334 ++
drivers/fw/fw-ohci.h | 152 ++
2 files changed, 1486 insertions(+), 0 deletions(-)
diff --git a/drivers/fw/fw-ohci.c b/drivers/fw/fw-ohci.c
new file mode 100644
index 000..78e0324
--- /dev/null
+++ b/drivers/fw/fw-ohci.c
@@ -0,0 +1,1334 @@
+/* -*- c-basic-offset: 8 -*-
+ *
+ * fw-ohci.c - Driver for OHCI 1394 boards
+ * Copyright (C) 2003 Kristian Høgsberg <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fw-transaction.h"
+#include "fw-ohci.h"
+
+struct descriptor {
+ u32 req_count:16;
+
+ u32 wait:2;
+ u32 branch:2;
+ u32 irq:2;
+ u32 yy:1;
+ u32 ping:1;
+
+ u32 key:3;
+ u32 status:1;
+ u32 command:4;
+
+ u32 data_address;
+ u32 branch_address;
+
+ u32 res_count:16;
+ u32 transfer_status:16;
+} __attribute__ ((aligned(16)));
you probably want __le32 annotations for sparse, right?
+#define DESCRIPTOR_OUTPUT_MORE 0
+#define DESCRIPTOR_OUTPUT_LAST 1
+#define DESCRIPTOR_INPUT_MORE 2
+#define DESCRIPTOR_INPUT_LAST 3
+#define DESCRIPTOR_NO_IRQ 0
+#define DESCRIPTOR_IRQ_ERROR 1
+#define DESCRIPTOR_IRQ_ALWAYS 3
+#define DESCRIPTOR_KEY_IMMEDIATE 2
+#define DESCRIPTOR_BRANCH_ALWAYS 3
+
+struct ar_context {
+ struct fw_ohci *ohci;
+ struct descriptor descriptor;
+ u32 buffer[512];
+ dma_addr_t descriptor_bus;
+ dma_addr_t buffer_bus;
+
+ u32 command_ptr;
+ u32 control_set;
+ u32 control_clear;
+
+ struct tasklet_struct tasklet;
+};
+
+struct at_context {
+ struct fw_ohci *ohci;
+ dma_addr_t descriptor_bus;
+ dma_addr_t buffer_bus;
+
+ struct list_head list;
+
+ struct {
+ struct descriptor more;
+ u32 header[4];
+ struct descriptor last;
+ } descriptor;
+
+ u32 command_ptr;
+ u32 control_set;
+ u32 control_clear;
+
+ struct tasklet_struct tasklet;
+};
+
+struct it_header {
+ u32 sy:4;
+ u32 tcode:4;
+ u32 channel:6;
+ u32 tag:2;
+ u32 speed:3;
+ u32 reserved0:13;
+ u32 reserved1:16;
+ u32 data_length:16;
+};
ditto.
And for the last two fields, I bet that using the normal 'u16' type
(__le16?) would generate much better code than a bitfield:16 ever would.
+struct iso_context {
+ struct fw_iso_context base;
+ struct tasklet_struct tasklet;
+ u32 control_set;
+ u32 control_clear;
+ u32 command_ptr;
+ u32 context_match;
+
+ struct descriptor *buffer;
+ dma_addr_t buffer_bus;
+ struct descriptor *head_descriptor;
+ struct descriptor *tail_descriptor;
+ struct descriptor *tail_descriptor_last;
+ struct descriptor *prev_descriptor;
+};
+
+#define CONFIG_ROM_SIZE 1024
+
+struct fw_ohci {
+ struct fw_card card;
+
+ struct pci_dev *dev;
struct device* instead? grep for to_pci_dev() to see how to get pci-dev
from device.
+ char *registers;
should be 'void __iomem *'
See Documentation/sparse.txt for more info on checking your code with
sparse.
+ dma_addr_t self_id_bus;
+ u32 *self_id_cpu;
+ struct tasklet_struct bus_reset_tasklet;
+ int generation;
+ int request_generation;
+
+ spinlock_t lock;
+ u32 self_id_buffer[512];
+
+ /* Config rom buffers */
+ u32 *config_rom;
+ dma_addr_t config_rom_bus;
+ u32 *next_config_rom;
+ dma_addr_t next_config_rom_bus;
+
+ struct ar_context ar_request_ctx;
+ struct ar_context ar_response_ctx;
+ struct at_context at_request_ctx;
+ struct at_context at_response_ctx;
+
+ u32 it_context_mask;
+ struct iso_context *it_context_list;
+ u32 ir_context_mask;
+ struct iso_context *ir_context_list;
+};
+
+extern inline struct fw_ohci
Re: [PATCH] Add Broadcom PHY support
> On Fri, 2006-09-15 at 16:15 -0400, Amy Fong wrote:
> > [PATCH] Add Broadcom PHY support
> >
> > This patch adds a driver to support the bcm5421s and bcm5461s PHY
> >
> > Kernel version: linux-2.6.18-rc6
> >
> > Signed-off-by: Amy Fong
>
> Some 5421's need special initialisation (see drivers/net/sungem_phy.c),
> might be worth having them there too. I was also wondering... for
> spidernet, we need to enable the fiber mode on the PHY. Does phylib has
> an API for that ?
>
> I'd like to look into moving sungem and spidernet over to phylib.
>
> Ben.
I believe that this fiber enabling can be done by defining config_init in the
phy_driver struct.
struct phy_driver {
/* Called to initialize the PHY,
* including after a reset */
int (*config_init)(struct phy_device *phydev);
};
ie.
static struct phy_driver bcm5421s_driver = {
.config_init = bcm5421s_phy_config,
};
int bcm5421s_phy_config(struct phy_device *phydev)
{
...
/* enable fiber mode here... */
...
}
Amy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Andrew Morton wrote: On Tue, 5 Dec 2006 16:14:03 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: radix-tree-rcu-lockless-readside.patch There's no reason to merge this yet. We want to use it in some powerpc arch code. Currently we use a per-cpu array of spinlocks, and this patch would let us get rid of that array. ok, let's merge it then. Well that wasn't as hard as I thought ;) No arguments from me! -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Import fw-ohci driver.
On Tue, 05 Dec 2006 00:22:45 -0500, "Kristian Høgsberg" <[EMAIL PROTECTED]> wrote: Your wonderful crossed-o might be ok here (or it would've been if only your mailer worked -- notice that the name is right in the "On" tag line above): > Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]> > --- But it's very much NOT OK here: > + * fw-ohci.c - Driver for OHCI 1394 boards > + * Copyright (C) 2003 Kristian Høgsberg <[EMAIL PROTECTED]> And you know why? Because the C code in kernel has no character set. Even if the holy penguin declares "we use UTF-8 now", it's still not ok, because people routinely send patches in e-mail. So, please don't do that. I do not put "Copyright (c) 2006 Петр Зайцев" in my patches out of courtesy to you. You might not even have fonts for that. Now I expect the same from you. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Paul Mackerras wrote: Andrew Morton writes: radix-tree-rcu-lockless-readside.patch There's no reason to merge this yet. We want to use it in some powerpc arch code. Currently we use a per-cpu array of spinlocks, and this patch would let us get rid of that array. I'd like to get another patch in here before going upstream if possible. It is not a correctness fix, but it is a bit of a rework. I also wouldn't mind getting the readahead path, if not the full pagecache readside, out from under tree_lock in -mm kernels to exercise the radix-tree concurrency a bit more. It's just been painfully slow, recently because of these more important buffered write vs deadlock and pagefault vs invalidate problems that I've been working on. I don't feel I can load up -mm with too much unrelated stuff that messes with mm/pagecache internals. I guess the per-cpu spinlocks are pretty reasonable for scalability, and you are mainly looking to eliminate the lock/unlock cost in your interrupt path? Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] add an iterator index in struct pagevec
On Mon, 4 Dec 2006 21:21:31 -0800
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
> pagevec is never expected to be more than PAGEVEC_SIZE, I think a
> unsigned char is enough to count them. This patch makes nr, cold
> to be unsigned char
Is that on the right side of the speed/space tradeoff?
> and also adds an iterator index. With that,
> the size can be even bumped up by 1 to 15.
>
> Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
>
>
> diff -Nurp linux-2.6.19/include/linux/pagevec.h
> linux-2.6.19.ken/include/linux/pagevec.h
> --- linux-2.6.19/include/linux/pagevec.h 2006-11-29 13:57:37.0
> -0800
> +++ linux-2.6.19.ken/include/linux/pagevec.h 2006-12-04 19:18:21.0
> -0800
> @@ -8,15 +8,16 @@
> #ifndef _LINUX_PAGEVEC_H
> #define _LINUX_PAGEVEC_H
>
> -/* 14 pointers + two long's align the pagevec structure to a power of two */
> -#define PAGEVEC_SIZE 14
> +/* 15 pointers + 3 char's align the pagevec structure to a power of two */
> +#define PAGEVEC_SIZE 15
>
> struct page;
> struct address_space;
>
> struct pagevec {
> - unsigned long nr;
> - unsigned long cold;
> + unsigned char nr;
> + unsigned char cold;
> + unsigned char idx;
> struct page *pages[PAGEVEC_SIZE];
> };
>
I'd have thought that pagevec_init() would want to be involved in this, no?
I must say I'm a bit skeptical about the need for this. But I haven't
looked closely at the blockdev-specific dio code yet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
On Tue, 5 Dec 2006 16:14:03 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: > > radix-tree-rcu-lockless-readside.patch > > > > There's no reason to merge this yet. > > We want to use it in some powerpc arch code. Currently we use a > per-cpu array of spinlocks, and this patch would let us get rid of > that array. ok, let's merge it then. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
On Mon, 04 Dec 2006 23:56:42 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > via-pata-controller-xfer-fixes.patch > > via-pata-controller-xfer-fixes-fix.patch > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the > reporter as fixing things, so these two shouldn't be needed. OK thanks, I dropped it. > > > libata_resume_fix.patch > > I thought this was resolved long ago? Are there still open reports that > this solves, where upstream doesn't work? Heck, I don't know. > > > ahci-ati-sb600-sata-support-for-various-modes.patch > > With the PCI quirk, I thought ATI was finally sorted? Was it? I don't know that either. I'll drop these too. - 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/3] New firewire stack
On Tue, 2006-12-05 at 00:22 -0500, Kristian Høgsberg wrote: > Hi, > > I'm announcing an alternative firewire stack that I've been working on > the last few weeks. I'm aiming to implement feature parity with the > current firewire stack, but not necessarily interface compatibility. > For now, I have the low-level OHCI driver done, the mid-level > transaction logic done, and the SBP-2 (storage) driver is basically > done. What's missing is a streaming interface (in progress) to allow > reception and transmission of isochronous data and a userspace > interface for controlling devices (much like raw1394 or libusb for > usb). I'm working out of this git repository: A very very very quick look at the code shows that: - It looks nice / clear - It's horribly broken in at least two area : DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!! and Where do you handle endianness ? (no need to shout for that one). (Or in general, do not use bitfields period ) bitfields format is not guaranteed, and is not endian consistent. 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/
Re: -mm merge plans for 2.6.20
Andrew Morton writes: > ppc-m48t35-add-missing-bracket.patch > powerpc-replace-kmallocmemset-with-kzalloc.patch These are already in Linus' tree. > Am holding onto these until the powerpc git tree gets un-messied up. It should be fine now. Linus has pulled it, so there are currently no changes in powerpc.git relative to Linus' tree. > radix-tree-rcu-lockless-readside.patch > > There's no reason to merge this yet. We want to use it in some powerpc arch code. Currently we use a per-cpu array of spinlocks, and this patch would let us get rid of that array. Paul. - 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 04/13] Connection Manager
> So will each new NIC implement some parts of TCP stack in theirs drivers? I hope not. The driver we merged (amso1100) did it completely in FW, with a separate MAC and IP interface for the RDMA connections. I think we better understand the Chelsio driver pretty well and think it over carefully before we merge it. Thanks for pointing this stuff out. - R. - 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 2/3] Import fw-ohci driver.
Add the OHCI driver to the stack and build system.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
---
drivers/fw/fw-ohci.c | 1334 ++
drivers/fw/fw-ohci.h | 152 ++
2 files changed, 1486 insertions(+), 0 deletions(-)
diff --git a/drivers/fw/fw-ohci.c b/drivers/fw/fw-ohci.c
new file mode 100644
index 000..78e0324
--- /dev/null
+++ b/drivers/fw/fw-ohci.c
@@ -0,0 +1,1334 @@
+/* -*- c-basic-offset: 8 -*-
+ *
+ * fw-ohci.c - Driver for OHCI 1394 boards
+ * Copyright (C) 2003 Kristian Høgsberg <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fw-transaction.h"
+#include "fw-ohci.h"
+
+struct descriptor {
+ u32 req_count:16;
+
+ u32 wait:2;
+ u32 branch:2;
+ u32 irq:2;
+ u32 yy:1;
+ u32 ping:1;
+
+ u32 key:3;
+ u32 status:1;
+ u32 command:4;
+
+ u32 data_address;
+ u32 branch_address;
+
+ u32 res_count:16;
+ u32 transfer_status:16;
+} __attribute__ ((aligned(16)));
+
+#define DESCRIPTOR_OUTPUT_MORE 0
+#define DESCRIPTOR_OUTPUT_LAST 1
+#define DESCRIPTOR_INPUT_MORE 2
+#define DESCRIPTOR_INPUT_LAST 3
+#define DESCRIPTOR_NO_IRQ 0
+#define DESCRIPTOR_IRQ_ERROR 1
+#define DESCRIPTOR_IRQ_ALWAYS 3
+#define DESCRIPTOR_KEY_IMMEDIATE 2
+#define DESCRIPTOR_BRANCH_ALWAYS 3
+
+struct ar_context {
+ struct fw_ohci *ohci;
+ struct descriptor descriptor;
+ u32 buffer[512];
+ dma_addr_t descriptor_bus;
+ dma_addr_t buffer_bus;
+
+ u32 command_ptr;
+ u32 control_set;
+ u32 control_clear;
+
+ struct tasklet_struct tasklet;
+};
+
+struct at_context {
+ struct fw_ohci *ohci;
+ dma_addr_t descriptor_bus;
+ dma_addr_t buffer_bus;
+
+ struct list_head list;
+
+ struct {
+ struct descriptor more;
+ u32 header[4];
+ struct descriptor last;
+ } descriptor;
+
+ u32 command_ptr;
+ u32 control_set;
+ u32 control_clear;
+
+ struct tasklet_struct tasklet;
+};
+
+struct it_header {
+ u32 sy:4;
+ u32 tcode:4;
+ u32 channel:6;
+ u32 tag:2;
+ u32 speed:3;
+ u32 reserved0:13;
+ u32 reserved1:16;
+ u32 data_length:16;
+};
+
+struct iso_context {
+ struct fw_iso_context base;
+ struct tasklet_struct tasklet;
+ u32 control_set;
+ u32 control_clear;
+ u32 command_ptr;
+ u32 context_match;
+
+ struct descriptor *buffer;
+ dma_addr_t buffer_bus;
+ struct descriptor *head_descriptor;
+ struct descriptor *tail_descriptor;
+ struct descriptor *tail_descriptor_last;
+ struct descriptor *prev_descriptor;
+};
+
+#define CONFIG_ROM_SIZE 1024
+
+struct fw_ohci {
+ struct fw_card card;
+
+ struct pci_dev *dev;
+ char *registers;
+ dma_addr_t self_id_bus;
+ u32 *self_id_cpu;
+ struct tasklet_struct bus_reset_tasklet;
+ int generation;
+ int request_generation;
+
+ spinlock_t lock;
+ u32 self_id_buffer[512];
+
+ /* Config rom buffers */
+ u32 *config_rom;
+ dma_addr_t config_rom_bus;
+ u32 *next_config_rom;
+ dma_addr_t next_config_rom_bus;
+
+ struct ar_context ar_request_ctx;
+ struct ar_context ar_response_ctx;
+ struct at_context at_request_ctx;
+ struct at_context at_response_ctx;
+
+ u32 it_context_mask;
+ struct iso_context *it_context_list;
+ u32 ir_context_mask;
+ struct iso_context *ir_context_list;
+};
+
+extern inline struct fw_ohci *fw_ohci(struct fw_card *card)
+{
+ return container_of(card, struct fw_ohci, card);
+}
+
+#define CONTEXT_CYCLE_MATCH_ENABLE 0x8000
+
+#define CONTEXT_RUN0x8000
+#define CONTEXT_WAKE 0x1000
+#define CONTEXT_DEAD 0x0800
+#define CONTEXT_ACTIVE 0x0400
+
+#define OHCI1394_MAX_AT_REQ_RETRIES0x2
+#define OHCI1394_MAX_AT_RESP_RETRIES 0x2
+#define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8
+
+#define FW_OHCI_MAJOR 240
[PATCH 3/3] Import fw-sbp2 driver.
Pull in the fw-sbp2 driver for firewire storage devices.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
---
drivers/fw/fw-ohci.c |2
drivers/fw/fw-sbp2.c | 1083 ++
2 files changed, 1084 insertions(+), 1 deletions(-)
diff --git a/drivers/fw/fw-ohci.c b/drivers/fw/fw-ohci.c
index 78e0324..444e8f0 100644
--- a/drivers/fw/fw-ohci.c
+++ b/drivers/fw/fw-ohci.c
@@ -594,7 +594,7 @@ static void bus_reset_tasklet(unsigned l
self_id_count, ohci->self_id_buffer);
}
-static irqreturn_t irq_handler(int irq, void *data, struct pt_regs *unused)
+static irqreturn_t irq_handler(int irq, void *data)
{
struct fw_ohci *ohci = data;
u32 event, iso_event;
diff --git a/drivers/fw/fw-sbp2.c b/drivers/fw/fw-sbp2.c
new file mode 100644
index 000..e0e7590
--- /dev/null
+++ b/drivers/fw/fw-sbp2.c
@@ -0,0 +1,1083 @@
+/* -*- c-basic-offset: 8 -*-
+ * fw-sbp2.c -- SBP2 driver (SCSI over IEEE1394)
+ *
+ * Copyright © 2005 Kristian Høgsberg <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "fw-transaction.h"
+#include "fw-topology.h"
+#include "fw-device.h"
+
+/* I don't know why the SCSI stack doesn't define something like this... */
+typedef void (*scsi_done_fn_t) (struct scsi_cmnd *);
+
+static const char sbp2_driver_name[] = "sbp2";
+
+struct sbp2_device {
+ struct fw_address_handler address_handler;
+ struct list_head orb_list;
+ u64 management_agent_address;
+ u64 command_block_agent_address;
+ u32 workarounds;
+ int login_id;
+
+ /* We cache these addresses and only update them once we've
+* logged in or reconnected to the sbp2 device. That way, any
+* IO to the device will automatically fail and get retried if
+* it happens in a window where the device is not ready to
+* handle it (e.g. after a bus reset but before we reconnect). */
+ int node_id;
+ int address_high;
+ int generation;
+
+ struct work_struct work;
+ struct Scsi_Host *scsi_host;
+};
+
+#define SBP2_MAX_SG_ELEMENT_LENGTH 0xf000
+#define SBP2_MAX_SECTORS 255 /* Max sectors supported */
+#define SBP2_MAX_CMDS 8 /* This should be safe */
+
+#define SBP2_ORB_NULL 0x8000
+
+#define SBP2_DIRECTION_TO_MEDIA0x0
+#define SBP2_DIRECTION_FROM_MEDIA 0x1
+
+/* Unit directory keys */
+#define SBP2_COMMAND_SET_SPECIFIER 0x38
+#define SBP2_COMMAND_SET 0x39
+#define SBP2_COMMAND_SET_REVISION 0x3b
+#define SBP2_FIRMWARE_REVISION 0x3c
+
+/* Flags for detected oddities and brokeness */
+#define SBP2_WORKAROUND_128K_MAX_TRANS 0x1
+#define SBP2_WORKAROUND_INQUIRY_36 0x2
+#define SBP2_WORKAROUND_MODE_SENSE_8 0x4
+#define SBP2_WORKAROUND_FIX_CAPACITY 0x8
+#define SBP2_WORKAROUND_OVERRIDE 0x100
+
+/* Management orb opcodes */
+#define SBP2_LOGIN_REQUEST 0x0
+#define SBP2_QUERY_LOGINS_REQUEST 0x1
+#define SBP2_RECONNECT_REQUEST 0x3
+#define SBP2_SET_PASSWORD_REQUEST 0x4
+#define SBP2_LOGOUT_REQUEST0x7
+#define SBP2_ABORT_TASK_REQUEST0xb
+#define SBP2_ABORT_TASK_SET0xc
+#define SBP2_LOGICAL_UNIT_RESET0xe
+#define SBP2_TARGET_RESET_REQUEST 0xf
+
+/* Offsets for command block agent registers */
+#define SBP2_AGENT_STATE 0x00
+#define SBP2_AGENT_RESET 0x04
+#define SBP2_ORB_POINTER 0x08
+#define SBP2_DOORBELL 0x10
+#define SBP2_UNSOLICITED_STATUS_ENABLE 0x14
+
+/* Status write response codes */
+#define SBP2_STATUS_REQUEST_COMPLETE 0x0
+#define SBP2_STATUS_TRANSPORT_FAILURE 0x1
+#define SBP2_STATUS_ILLEGAL_REQUEST0x2
+#define SBP2_STATUS_VENDOR_DEPENDENT 0x3
+
+struct sbp2_status {
+ unsigned int orb_high:16;
+ unsigned int sbp_status:8;
+ unsigned int len:3;
+ unsigned int dead:1;
+ unsigned int response:2;
+ unsigned int source:2;
+ u32 orb_low;
+ u8 data[24];
+};
+
+struct sbp2_orb {
+
[PATCH 0/3] New firewire stack
Hi, I'm announcing an alternative firewire stack that I've been working on the last few weeks. I'm aiming to implement feature parity with the current firewire stack, but not necessarily interface compatibility. For now, I have the low-level OHCI driver done, the mid-level transaction logic done, and the SBP-2 (storage) driver is basically done. What's missing is a streaming interface (in progress) to allow reception and transmission of isochronous data and a userspace interface for controlling devices (much like raw1394 or libusb for usb). I'm working out of this git repository: http://gitweb.freedesktop.org/?p=users/krh/juju.git but I'll be sending 3 patches for review after this mail: first the core subsystem, then the OHCI driver and finally the SBP-2 (SCSI over firewire) driver. For people who want to test this out, the easiest approach right now is to clone the git repo and run make. This requires the kernel-devel RPM on Fedora Core; I'm sure other distros have a similar package. Now, I didn't set out to rewrite the entire firewire stack. At first I just wanted to fix the OHCI driver. However any rewrite that addresses the problems in the driver will shift the code around enough to invalidate the quirks and workarounds there. And frankly, I don't trust most of the workarounds to begin with. So I decided to write the OHCI driver from scratch. The rest of the stack has problems too, there's too many kernel threads bouncing around, the nodemgr code is racy and doesn't really consider issues such as hotplug during device probing. And there is 5 different interfaces for doing isochronous streaming. The new stack is more compact and I'd like to think it's easier to follow the code. Here are the sizes for the three patches that follow: [juju:linux-2.6]$ wc -l patches-juju/*.patch 3983 patches-juju/fw-core.patch 1510 patches-juju/fw-ohci.patch 1114 patches-juju/fw-sbp2.patch 6607 total Compared to [EMAIL PROTECTED] ieee1394]$ wc -l *.[ch] ... 30431 total The new stack can co-exists with the old stack, since it's sitting in drivers/fw. So users can pick which stack they want at compile time, or maybe compile both and switch at run-time using a modprobe blacklist file. This allows a transition phase from the old stack to the new one where interfaces will be awailable. At this point I'm not proposing the stack for inclusion into mainline yet, as I'm still developing the streaming interface and the userspace control interface. This is just a heads up for now, to announce the effort and where I'd like to go with this. It is basically useful with the storage devices I have available here, though, and ready for testing for that specific use case. Once the remaining features land, I'd like to see this in mainstream linux and I'm interested in hearing how people feel about this. cheers, Kristian - 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] add an iterator index in struct pagevec
pagevec is never expected to be more than PAGEVEC_SIZE, I think a
unsigned char is enough to count them. This patch makes nr, cold
to be unsigned char and also adds an iterator index. With that,
the size can be even bumped up by 1 to 15.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff -Nurp linux-2.6.19/include/linux/pagevec.h
linux-2.6.19.ken/include/linux/pagevec.h
--- linux-2.6.19/include/linux/pagevec.h2006-11-29 13:57:37.0
-0800
+++ linux-2.6.19.ken/include/linux/pagevec.h2006-12-04 19:18:21.0
-0800
@@ -8,15 +8,16 @@
#ifndef _LINUX_PAGEVEC_H
#define _LINUX_PAGEVEC_H
-/* 14 pointers + two long's align the pagevec structure to a power of two */
-#define PAGEVEC_SIZE 14
+/* 15 pointers + 3 char's align the pagevec structure to a power of two */
+#define PAGEVEC_SIZE 15
struct page;
struct address_space;
struct pagevec {
- unsigned long nr;
- unsigned long cold;
+ unsigned char nr;
+ unsigned char cold;
+ unsigned char idx;
struct page *pages[PAGEVEC_SIZE];
};
-
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 04/13] Connection Manager
On Mon, Dec 04, 2006 at 09:13:59PM -0800, Roland Dreier ([EMAIL PROTECTED]) wrote: > > It is for iwarp/rdma from description. > > Yes, iWARP on top of 10G ethernet. > > > If it is 10ge, then why does it parse incomping packet headers and > > implements initial tcp state machine? > > To establish connections to run RDMA over, I guess. iWARP is RDMA > over TCP. So will each new NIC implement some parts of TCP stack in theirs drivers? > - R. -- 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 v2 04/13] Connection Manager
On Mon, Dec 04, 2006 at 10:20:51AM -0600, Steve Wise ([EMAIL PROTECTED]) wrote: > > > This and a lot of other changes in this driver definitely says you > > > implement your own stack of protocols on top of infiniband hardware. > > > > ...but I do know this driver is for 10-gig ethernet HW. > > > > There is no SW TCP stack in this driver. The HW supports RDMA over > TCP/IP/10GbE in HW and this is required for zero-copy RDMA over Ethernet > (aka iWARP). The device is a 10 GbE device, not Infiniband. The > Ethernet driver, upon which the rdma driver depends, acts both like a > traditional Ethernet NIC for the Linux stack as well as a TCP offload > device for the RDMA driver allowing establishment of RDMA connections. > The Connection Manager (patch 04/13) sends/receives messages from the > Ethernet driver that sets up HW TCP connections for doing RDMA. While > this is indeed implementing TCP offload, it is _not_ integrating it with > the sockets layer nor the linux stack and offloading sockets > connections. Its only supporting offload connections for the RDMA > driver to do iWARP. The Ammasso device is another example of this > (drivers/infiniband/hw/amso1100). Deep iSCSI adapters are another > example of this. So what will happen when application will create a socket, bind it to that NIC, and then try to establish a TCP connection? How NIC will decide that received packets are from socket but not for internal TCP state machine handled by that device? As a side note, does all iwarp devices _require_ to have very limited TCP engine implemented it in its hardware, or it is possible to work with external SW stack? > Steve. -- 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 v2 04/13] Connection Manager
> It is for iwarp/rdma from description. Yes, iWARP on top of 10G ethernet. > If it is 10ge, then why does it parse incomping packet headers and > implements initial tcp state machine? To establish connections to run RDMA over, I guess. iWARP is RDMA over TCP. - R. - 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 04/13] Connection Manager
On Mon, Dec 04, 2006 at 07:45:52AM -0800, Roland Dreier ([EMAIL PROTECTED]) wrote: > > This and a lot of other changes in this driver definitely says you > > implement your own stack of protocols on top of infiniband hardware. > > ...but I do know this driver is for 10-gig ethernet HW. It is for iwarp/rdma from description. If it is 10ge, then why does it parse incomping packet headers and implements initial tcp state machine? > - R. -- 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/
[PATCH] Re: 2.6.19 git compile error - "current_is_keventd" [drivers/net/phy/libphy.ko] undefined
[EMAIL PROTECTED] wrote: to: linux-kernel@vger.kernel.org cc: [EMAIL PROTECTED] 2006/12/04/18:00 CST Building modules, stage 2. Kernel: arch/x86_64/boot/bzImage is ready (#2) MODPOST 1256 modules WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 xboom Here's a patch with the easy fix, but I'm not certain it's a permanent fix. Frank This patch fixes a compile error when CONFIG_PHYLIB is a module. Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]> --- kernel/workqueue.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.19-fs1/kernel/workqueue.c === --- linux-2.6.19-fs1.orig/kernel/workqueue.c 2006-12-04 22:21:06.0 -0600 +++ linux-2.6.19-fs1/kernel/workqueue.c 2006-12-04 22:59:55.0 -0600 @@ -608,6 +608,7 @@ return ret; } +EXPORT_SYMBOL_GPL(current_is_keventd); #ifdef CONFIG_HOTPLUG_CPU /* Take the work from this (downed) CPU. */ - 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 up compiler warnings in megaraid driver
Martin Bligh wrote: Fix up compiler warnings in megaraid driver Signed-off-by: Martin J. Bligh <[EMAIL PROTECTED]> diff -aurpN -X /home/mbligh/.diff.exclude linux-2.6.19/drivers/scsi/megaraid.c 2.6.19-megaraid/drivers/scsi/megaraid.c --- linux-2.6.19/drivers/scsi/megaraid.c2006-12-04 17:52:00.0 -0800 +++ 2.6.19-megaraid/drivers/scsi/megaraid.c 2006-12-04 18:24:03.0 -0800 @@ -73,10 +73,14 @@ static unsigned short int max_mbox_busy_ module_param(max_mbox_busy_wait, ushort, 0); MODULE_PARM_DESC(max_mbox_busy_wait, "Maximum wait for mailbox in microseconds if busy (default=MBOX_BUSY_WAIT=10)"); -#define RDINDOOR(adapter) readl((adapter)->base + 0x20) -#define RDOUTDOOR(adapter) readl((adapter)->base + 0x2C) -#define WRINDOOR(adapter,value)writel(value, (adapter)->base + 0x20) -#define WROUTDOOR(adapter,value) writel(value, (adapter)->base + 0x2C) +#define RDINDOOR(adapter) readl((volatile void __iomem *) \ + (adapter)->base + 0x20) +#define RDOUTDOOR(adapter) readl((volatile void __iomem *) \ + (adapter)->base + 0x2C) +#define WRINDOOR(adapter,value)writel(value, (volatile void __iomem *)\ + (adapter)->base + 0x20) +#define WROUTDOOR(adapter,value) writel(value, (volatile void __iomem *)\ + (adapter)->base + 0x2C) /* * Global variables I posted a better fix just yesterday... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -mm merge plans for 2.6.20
Andrew Morton wrote: via-pata-controller-xfer-fixes.patch via-pata-controller-xfer-fixes-fix.patch Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the reporter as fixing things, so these two shouldn't be needed. libata_resume_fix.patch I thought this was resolved long ago? Are there still open reports that this solves, where upstream doesn't work? ahci-ati-sb600-sata-support-for-various-modes.patch With the PCI quirk, I thought ATI was finally sorted? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] optimize o_direct on block device - v2
This patch implements block device specific .direct_IO method instead
of going through generic direct_io_worker for block device.
direct_io_worker is fairly complex because it needs to handle O_DIRECT
on file system, where it needs to perform block allocation, hole detection,
extents file on write, and tons of other corner cases. The end result is
that it takes tons of CPU time to submit an I/O.
For block device, the block allocation is much simpler and a tight triple
loop can be written to iterate each iovec and each page within the iovec
in order to construct/prepare bio structure and then subsequently submit
it to the block layer. This significantly speeds up O_D on block device.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
---
Changes since v1->v2:
* add BUILD_BUG_ON to ensure bio_count fit inside iocb->private
* add comment that bio_alloc won't fail with GFP_KERNEL
* fix back out path if get_uer_pages fail
* fix back out path if iov segment doesn't align properly
fs/bio.c|2
fs/block_dev.c | 173
fs/read_write.c |2
include/linux/bio.h |1
4 files changed, 150 insertions(+), 28 deletions(-)
--- ./fs/block_dev.c.orig 2006-11-29 13:57:37.0 -0800
+++ ./fs/block_dev.c2006-12-04 18:38:53.0 -0800
@@ -129,43 +129,164 @@ blkdev_get_block(struct inode *inode, se
return 0;
}
-static int
-blkdev_get_blocks(struct inode *inode, sector_t iblock,
- struct buffer_head *bh, int create)
+int blk_end_aio(struct bio *bio, unsigned int bytes_done, int error)
{
- sector_t end_block = max_block(I_BDEV(inode));
- unsigned long max_blocks = bh->b_size >> inode->i_blkbits;
+ struct kiocb* iocb = bio->bi_private;
+ atomic_t* bio_count = (atomic_t*) >private;
+ long res;
+
+ if ((bio->bi_rw & 1) == READ)
+ bio_check_pages_dirty(bio);
+ else {
+ bio_release_pages(bio);
+ bio_put(bio);
+ }
- if ((iblock + max_blocks) > end_block) {
- max_blocks = end_block - iblock;
- if ((long)max_blocks <= 0) {
- if (create)
- return -EIO;/* write fully beyond EOF */
- /*
-* It is a read which is fully beyond EOF. We return
-* a !buffer_mapped buffer
-*/
- max_blocks = 0;
- }
+ if (error)
+ iocb->ki_left = -EIO;
+
+ if (atomic_dec_and_test(bio_count)) {
+ res = (iocb->ki_left < 0) ? iocb->ki_left : iocb->ki_nbytes;
+ aio_complete(iocb, res, 0);
}
- bh->b_bdev = I_BDEV(inode);
- bh->b_blocknr = iblock;
- bh->b_size = max_blocks << inode->i_blkbits;
- if (max_blocks)
- set_buffer_mapped(bh);
return 0;
}
+#define VEC_SIZE 16
+struct pvec {
+ unsigned short nr;
+ unsigned short idx;
+ struct page *page[VEC_SIZE];
+};
+
+
+struct page *blk_get_page(unsigned long addr, size_t count, int rw,
+ struct pvec *pvec)
+{
+ int ret, nr_pages;
+ if (pvec->idx == pvec->nr) {
+ nr_pages = (addr + count + PAGE_SIZE - 1) / PAGE_SIZE -
+ addr / PAGE_SIZE;
+ nr_pages = min(nr_pages, VEC_SIZE);
+ down_read(>mm->mmap_sem);
+ ret = get_user_pages(current, current->mm, addr, nr_pages,
+rw==READ, 0, pvec->page, NULL);
+ up_read(>mm->mmap_sem);
+ if (ret < 0)
+ return ERR_PTR(ret);
+ pvec->nr = ret;
+ pvec->idx = 0;
+ }
+ return pvec->page[pvec->idx++];
+}
+
static ssize_t
blkdev_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
- loff_t offset, unsigned long nr_segs)
+loff_t pos, unsigned long nr_segs)
{
- struct file *file = iocb->ki_filp;
- struct inode *inode = file->f_mapping->host;
+ struct inode *inode = iocb->ki_filp->f_mapping->host;
+ unsigned blkbits = blksize_bits(bdev_hardsect_size(I_BDEV(inode)));
+ unsigned blocksize_mask = (1<< blkbits) - 1;
+ unsigned long seg, nvec, cur_off, cur_len;
+
+ unsigned long addr;
+ size_t count, nbytes = iocb->ki_nbytes;
+ loff_t size;
+ struct bio * bio;
+ atomic_t *bio_count = (atomic_t *) >private;
+ struct page *page;
+ struct pvec pvec = {.nr = 0, .idx = 0, };
+
+ BUILD_BUG_ON(sizeof(atomic_t) > sizeof(iocb->private));
+
+ size = i_size_read(inode);
+ if (pos + nbytes > size)
+ nbytes = size - pos;
+
+ seg = 0;
+ addr = (unsigned long) iov[0].iov_base;
+ count = iov[0].iov_len;
+ atomic_set(bio_count, 1);
+
+
RE: la la la la ... swappiness
On Mon, 4 Dec 2006, Aucoin wrote: > > If I'm going to go through all the trouble to change the kernel and maybe > create a new proc file how much code would I have to touch to create a proc > file to set something like, let's say, effective memory and have all the vm > calculations use effective memory as the basis for swap and cache > calculations? Considering your /proc/meminfo under load: MemTotal: 2075152 kB MemFree:169848 kB Buffers: 4360 kB Cached: 334824 kB SwapCached: 0 kB Active: 178692 kB Inactive: 271452 kB HighTotal: 1179392 kB HighFree: 3040 kB LowTotal: 895760 kB LowFree:499876 kB SwapTotal: 524276 kB SwapFree: 524276 kB Dirty: 0 kB Writeback: 0 kB Mapped: 116720 kB Slab:27956 kB .. I actually suspect you should be _fairly_ close to such a situation already. In particular, the Active and Inactive lists really are fairly small, and don't contain the big SHM area, they seem to be just the cache and some (a fairly small amount of) anonymous pages. The above actually confuses me mightily. I _really_ expected the SHM pages to show up on the active/inactive lists if it was actually SHM, and they don't seem to. What am I missing? Louis, exactly how do you allocate that big 1.6GB shared area? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19: OOPS in cat /proc/fs/nfs/exports
On Monday December 4, [EMAIL PROTECTED] wrote:
> This is 100% reproducible. It hangs exportfs on shutdown.
>
> Dec 4 19:50:13 glotze kernel: BUG: unable to handle kernel NULL pointer
> dereference at virtual address 0040
> Dec 4 19:50:13 glotze kernel: printing eip:
> Dec 4 19:50:13 glotze kernel: c017254a
> Dec 4 19:50:13 glotze kernel: *pde =
> Dec 4 19:50:13 glotze kernel: Oops: [#1]
> Dec 4 19:50:13 glotze kernel: PREEMPT
> Dec 4 19:50:13 glotze kernel: Modules linked in: nfsd exportfs i915 stv0299
> budget_ci budget_core dvb_core saa7146 ttpci_eeprom 8250 serial_core nfs
> lockd sunrpc tuner tvaudio bttv video_buf ir_common compat_ioctl32
> i2c_algo_bit btcx_risc tveeprom i2c_core videodev v4l1_compat v4l2_common
> ipv6 nvram snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd
> soundcore snd_page_alloc ide_cd cdrom e100 mii af_packet
> Dec 4 19:50:13 glotze kernel: CPU:0
> Dec 4 19:50:13 glotze kernel: EIP:0060:[seq_escape+29/201]Not
> tainted VLI
> Dec 4 19:50:13 glotze kernel: EFLAGS: 00010286 (2.6.19 #2)
> Dec 4 19:50:13 glotze kernel: EIP is at seq_escape+0x1d/0xc9
> Dec 4 19:50:13 glotze kernel: eax: c761 ebx: c7370e00 ecx: 1000
> edx: c761005c
> Dec 4 19:50:13 glotze kernel: esi: 0040 edi: d0590384 ebp: cd2115f4
> esp: c9543ef4
> Dec 4 19:50:13 glotze kernel: ds: 007b es: 007b ss: 0068
> Dec 4 19:50:13 glotze kernel: Process cat (pid: 1379, ti=c9542000
> task=c73ea030 task.ti=c9542000)
> Dec 4 19:50:13 glotze kernel: Stack: c7370e00 c017219d 0004 c7370e00
> 0810 cd2115f4 d05878e7 c7370e00
> Dec 4 19:50:13 glotze kernel:d059037e d0590343 d059036f fffe
> fffe 0004 0301 d05969d0
> Dec 4 19:50:13 glotze kernel:c7370e00 cd2115c0 0029 c01727c3
> 0400 0804c848 cb9cb740 c7370e20
> Dec 4 19:50:13 glotze kernel: Call Trace:
> Dec 4 19:50:13 glotze kernel: [seq_printf+46/82] seq_printf+0x2e/0x52
> Dec 4 19:50:13 glotze kernel: [pg0+270379239/1069880320]
> svc_export_show+0x1dd/0x2b1 [nfsd]
That shouldn't happen (of course).
There is a place where a failed kstrdup could lead to this, but that
is rather unlikely and wouldn't be as reproducible as this seems to
be.
If you boot up and then immediately shutdown does this error trigger,
it does it have to be up for a while?
Just before shutting down, can you
cat /proc/fs/nfsd/exports
and see if that works? If so, can you show me the contents.
If not, can I see your /etc/exports ??
Thanks,
NeilBrown
This patch fixes a problem that is very unlikely to be yours.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcauth_unix.c |4
1 file changed, 4 insertions(+)
diff .prev/net/sunrpc/svcauth_unix.c ./net/sunrpc/svcauth_unix.c
--- .prev/net/sunrpc/svcauth_unix.c 2006-12-05 15:20:26.0 +1100
+++ ./net/sunrpc/svcauth_unix.c 2006-12-05 15:20:48.0 +1100
@@ -53,6 +53,10 @@ struct auth_domain *unix_domain_find(cha
return NULL;
kref_init(>h.ref);
new->h.name = kstrdup(name, GFP_KERNEL);
+ if (new->h.name == NULL) {
+ kree(new);
+ return NULL;
+ }
new->h.flavour = _unix;
new->addr_changes = 0;
rv = auth_domain_lookup(name, >h);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-mm2
On Tuesday December 5, [EMAIL PROTECTED] wrote: > > I notice it says: > | > v > > 090: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > Single bit error detected. Probably bad RAM. > > Run memtest86+ or a similar memory test tool. > > Have you tried running memtest86 ?? As Andrew correctly pointed out, this bit error is not a RAM problem. It is actually the low bit of a counter a spinlock that was decremented just before the WARN_ON. So it simply indicates that the inode had already been freed, which I think we knew already. Unfortunately I still have no idea why that inode had been freed but was still referenced by a dentry How repeatable as this bug? How did you narrow it down to that patch? Did you use git-bisect or something else? Thanks, NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: la la la la ... swappiness
> From: Nick Piggin [mailto:[EMAIL PROTECTED] > I'd be interested to know how OOM and page reclaim behaves after these > patches > (or with a newer kernel). We didn't get far today. The various suggestions everyone has for solving this problem spurred several new discussions inside the office and raised more questions. At the heart of the problem Andrew is right, heavy handed tactics to force limits on page cache don't solve anything and may just squeeze the problem to new areas. Modifying tar is really a band aid and not a solution, there is still a fundamental problem with memory management in this setup. Nick suggested the possibility of a patching the kernel or upgrading to a new kernel. Linus made the suggestion of dialing the value of min_free_kbytes down to match something more in line with what might be expected in a system with 400MB memory as a way to possibly make VM or at least a portion of VM simulate a restricted amount of memory. And, I have seen a couple suggestions about creating a new proc vm file to do things like tweak max_buffer_heads dynamically. So here's a silly (crazy) question (or two). If I'm going to go through all the trouble to change the kernel and maybe create a new proc file how much code would I have to touch to create a proc file to set something like, let's say, effective memory and have all the vm calculations use effective memory as the basis for swap and cache calculations? And can I stop at the vm engine or does the sprawl farther out? To the untrained mind it seems like this might be the best of both worlds. It sounds like it would allow an embedded system like ours to set aside a chunk of ram for a special purpose and designate a sandbox for the OS. I am, of course, making the *bold* assumption here that a majority of the vm algorithms are based off something remotely similar to a value which represents physical memory. Thoughts? Stones? - 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/
Is there way to reserve more MMIO resource for PCIE-hotplug-capable slot?
Hi, Sometimes we could hotplug a PCIE device, which require more MMIO resource than that reserved by BIOS. My question is: is there a way for kernel to reserved more MMIO resource for a PCIE-hotplug-capable slot? I searched the kernel-parameters.txt, but didn't find any related information. Thanks, Forrest - 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] Centralise definitions of sector_t and blkcnt_t
On Mon, 4 Dec 2006, Matthew Wilcox wrote: > > CONFIG_LBD and CONFIG_LSF are spread into asm/types.h for no particularly > good reason. Centralising the definition in linux/types.h means that arch > maintainers don't need to bother adding it, as well as fixing the problem > with x86-64 users being asked to make a decision that has absolutely no > effect. The H8/300 porters seem particularly confused since I'm not aware > of any microcontrollers that need to support 2TB filesystems. Applied, since this is a good cleanup regardless. I'd still be open to switching things around further, and allow even 64-bit architectures to say that they only want 32-bit sector_t's and page indexes (ie remove the "depends on !64BIT" and make the "unsigned long" case actually be "u32" instead, so that it literally switches between 32-bit or 64-bit values _regardless_ or architecture). I don't know how big a deal it is, but I could imagine that we could actually save memory in a smaller "struct page", for example, on 64bit architectures by just using a 4-byte index. For now, the !64BIT makes sense simply because a 64-bit architecture probably doesn't care, and might as well just use 64 bits anyway (ie you tend to have tons of memory there anyway). And I suspect it doesn't actually even help on 64-bits due to structure alignment etc issues, but am too lazy to go check. Just thought I'd mention the possibility, in other words. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 git compile error - "current_is_keventd" [drivers/net/phy/libphy.ko] undefined
On Mon, 4 Dec 2006, Horst H. von Brand wrote: > [EMAIL PROTECTED] wrote: > > 2006/12/04/18:00 CST > > > > Building modules, stage 2. > > Kernel: arch/x86_64/boot/bzImage is ready (#2) > > MODPOST 1256 modules > > WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined! > > make[1]: *** [__modpost] Error 1 > > make: *** [modules] Error 2 > > Also i686, sparc64. At drivers/net/phy/phy.c:590 is the lone reference to > current_is_keventd in that directory. Still present as of ff51a9... Yeah, I'm waiting for this whole mess to be either explained or reverted. There are apparently bigegr issues with it than just the butt-ugly "current_is_keventd()" crud. Linus - 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/
About watch dog timer limit of CPU (Xscale ->IXP425) How can I set more long time ?
Hello all , My embeded board hardware configuration is like this : # cat /proc/cpuinfo Processor : XScale-IXP425/IXC1100 rev 1 (v5b) BogoMIPS: 266.24 Features: swp half thumb fastmult edsp Hardware: Intel IXDP425 Development Platform Revision: Serial : Through reading datasheet of ixp4xx ,I know it has own watchdog functions , please see attchment :15 Timer I find a driver by goole , see attachment . Watchdog timer counter is 32 bit register , its max value is 2<<32 -1 #define TIMER_FREQ 6600 /* 66 MHZ timer */ #define TIMER_KEY 0x482e #define TIMER_MARGIN 60 /* (secs) Default is 1 minute */ //I want to modify it ,I find its max value is 65 static int ixp425_margin = TIMER_MARGIN; /* in seconds */ static int ixp425wdt_users; //static int pre_margin; //IXP425 CPU 's watch dog timer is 32 bit , //so I define it to be unsigned int --bob static unsigned int pre_margin; pre_margin = TIMER_FREQ * TIMER_MARGIN *IXP425_OSWT = pre_margin; if I need one minutes , *IXP425_OSWT = 6600 * 60 = 39600 ,not overflow if I need two minutes , *IXP425_OSWT = 6600 * 120 = 79200 ( which has been > 2<<32-1 , overflow So I compute the max time I can set : T_max = 2<<32-1 / 6600= 65 seconds ¡£ My question: if need more seconds ( for example , 5 minutes ) ,what should I do ? I have a method based on datasheet (ixp4xx) ,but I don't know if it will successed when system crash How can I do to break the limit of hardware ? Thanks ahead ! -- Best Regards bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc5-mm1 progression
Andrew Morton wrote: On Fri, 24 Nov 2006 17:36:27 +0100 "Benoit Boissinot" <[EMAIL PROTECTED]> wrote: On 11/24/06, Larry Finger <[EMAIL PROTECTED]> wrote: Is there the equivalent of 'git bisect' for the -mmX kernels? http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt Please take the time to do that. Yours is an interesting report - I'm not aware of anything in there which was expected to cause a change of this mature. There are at least two patches in 2.6.19-rc5-mm2 that make my system much more responsive for interactive jobs. The one that has the majority of the effect is: radix-tree-rcu-lockless-readside.patch I have not been able to isolate the second patch, which has the lesser effect. All I can say is that it occurred before the above patch in patches/series. This patch was tested against 2.6.19 and fixed most of the problem on that version. Larry Finger - 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: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 05 Dec 2006 03:36:09 +0100
Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> i know i said i suspected this was another bug, but i have revised my
> suspecisions, and i do believe its in relation to x86 chroot on x86_64
> install, as it has happened with more stuff now, inside the chroot, and
> only inside the chroot, while the same apps dont do it outside chroot.
>
> 2.6.19 release is affected too
Please don't top-post.
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> >
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on x86_64.
> > >
> > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > dmesg:
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> >
> > Try
> >
> > echo 0 > /proc/sys/kernel/compat-log
> >
> > I don't _think_ we did anything to change the logging in there. Which
> > kernel
> > version were you using previously (the one which didn't do this)?
Possibly some ioctl got removed. I don't know why it would only occur
within a chrooted environment.
Possibly one could work out what's going on by reverse-engineering x86_64
ioctl command 0x82187201, but unfortunately I don't have time to do that.
Also unfortunately there appears to be an assumption that unless I
personally can immediately and straightforwardly identify a bug-owner, I
personally own the bug. The best I can suggest is that you raise a report
at bugzilla.kernel.org so this issue gets ignored in a more organised
fashion.
Sorry.
-
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 2/2] x86_64: earlyprintk usb debug device support.
-Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Monday, December 04, 2006 4:45 PM To: Eric W. Biederman Cc: Lu, Yinghai; USB development list; Stefan Reinauer; Peter Stuge; linuxbios@linuxbios.org; linux-kernel@vger.kernel.org; Andi Kleen Subject: Re: [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. On Mon, Dec 04, 2006 at 02:26:52PM -0700, Eric W. Biederman wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > Anyway next time I touch this the project will be how to integrate > this into the kernel cleanly. This round was to figure out how > to get some working code. Please check the adapted version for LinuxBIOS with your kernel patch. Hope your next version could have more good shape ... YH usbdebug_direct.h Description: usbdebug_direct.h usbdebug_direct.c Description: usbdebug_direct.c
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 03:36 +0100, Kasper Sandberg wrote:
> i know i said i suspected this was another bug, but i have revised my
> suspecisions, and i do believe its in relation to x86 chroot on x86_64
> install, as it has happened with more stuff now, inside the chroot, and
> only inside the chroot, while the same apps dont do it outside chroot.
and by that (so that theres no confusion), i mean that with the x86_64
binaries of the same application dont crash it, but the x86 binaries in
the chroot does :)
>
> 2.6.19 release is affected too
>
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> >
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on x86_64.
> > >
> > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > dmesg:
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> >
> > Try
> >
> > echo 0 > /proc/sys/kernel/compat-log
> >
> > I don't _think_ we did anything to change the logging in there. Which
> > kernel
> > version were you using previously (the one which didn't do this)?
> >
> > -
> > 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/
> >
>
> -
> 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/
>
-
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: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
2.6.19 release is affected too
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <[EMAIL PROTECTED]> wrote:
>
> > it appears some sort of bug has gotten into .19, in regards to x86
> > emulation on x86_64.
> >
> > i have only tested with >=rc5, thw folling, as an example, appears in
> > dmesg:
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
>
> Try
>
> echo 0 > /proc/sys/kernel/compat-log
>
> I don't _think_ we did anything to change the logging in there. Which kernel
> version were you using previously (the one which didn't do this)?
>
> -
> 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/
>
-
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 patch] USB_RTL8150 must select MII
On Monday 04 December 2006 3:13 pm, Randy Dunlap wrote: > On Mon, 4 Dec 2006 21:02:06 +0100 Adrian Bunk wrote: > > > USB_RTL8150 must select MII to avoid link errors. > > > > Stolen from a patch by Randy Dunlap. > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > Thanks, Adrian. > > David B. may prefer a patch similar to the one that was > merged for USB_NET_MCS7830, which does: > > select USB_USBNET_MII No, rtl8150 doesn't use the usbnet framework. - 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.19-rc6] fix hotplug for legacy platform drivers
On Thursday 30 November 2006 11:04 pm, Greg KH wrote: > On Wed, Nov 29, 2006 at 05:27:31PM -0800, David Brownell wrote: > > On Wednesday 29 November 2006 3:02 pm, Greg KH wrote: > > > > > > > > Here's my fix. ... > > > > ... I audited all the drivers using the relevant APIs, and I can't > > > > see many (if any!) folk hitting problems from this. > > > > > > But this still can cause the problem that your 'modalias' file in sysfs > > > contains exactly the same name as the module itself, right? > > > > Not a problem if folk stick to the original design. Hotplug will at > > most "modprobe $MODALIAS" (iff the device needs a driver) before doing > > a udevsend ... and only coldplug uses "modprobe $(cat modalias)". > > I'm not saying that the design does not have problems, but having a No design is problem free, but I was just saying that any problems in that context are because of someone needlessly fighting that design. Like "of course you get into accidents when you drive on the wrong side of the road", or "of course zeroing /dev/kmem as root crashes". > modalias with no real alias does not make much sense to me. > > > I could update the patch so that attribute turns into a null string, > > but that would have a **negative effect** since it would break coldplug > > for all the platform init code which doesn't use platform_add_devices() > > or maybe platform_device_register(). > > Ok, I'm being thick here, but why do we need a modalias with the same > name as the module? We don't, today. But that's the direct consequence of the change Kay has promoted ... that is, the pushback on the $SUBJECT patch, trying to cast the issue as related to how drivers are identified, not than how they act. It's either create such pointless aliases for quite a few drivers *OR* break what is currently _working_ hotplug on many busses ... nontrivial regression, requiring a lot of work to resolve that would mean deployment delays on the (usual/optimistic) order of 12 months or so for tool updates. Or, more directly and simply, merge the $SUBJECT patch; no regression, no deployment delays in userspace tools, etc. In reality, "modalias" is the misnomer ... it's the kind of implementation detail that's bad to put into an interfaces. The role of that information is "driver identifier". Which for many busses is the module name. For some expansion busses, like PCI and USB, the identifier supports some bus-specific wildcard match rules. Those busses were architected around such driver match rules. And modprobe was modified to understand those wildcard rules; and kbuild was modified to generate module aliases that hotplug could feed to "modprobe". Fancy busses, fancy infrastructure; it took a long time to get to the point where /sbin/hotplug can be as simple as "modprobe $MODALIAS" (if needed!) plus "udevsend". Busses like that are the exception though. Most don't have any kind of dynamic identification/enumeration infrastructure, or multi-vendor driver match algorithm ... those have both design and implementation costs, which are not always justifiable. (Once you know the chip/board, you know every device on it; so there's no point in adding any support for auto-enumeration. There are also power management issues, since devices' interface clocks likely default to "off". Linux must explicitly enable those clocks, defeating the purpose of auto-enumeration...) So the best that most busses can have is a Linux-specific driver ID; although if you were judging by PC expansion busses, you might think otherwise. To Linux, "platform_bus" covers many dozens of different hardware implementations. On one SOC series, I can easily count a dozen such busses ... sometimes just within one chip. And in the context of platform_device and platform_driver, the driver ID has always been the driver name ... which in all but a few cases is also the module name. There's been a trivial workaround for those few cases: MODULE_ALIAS(driver_name). > > > That's not good, it should be an alias, not the "real name". > > > > Well, adding unjustified complexity _after the fact_ isn't good either, > > and that's what I see going on here. > > > > How many years has KMOD been around? It's worked just fine without that > > sort of bizarre (and un-needed) rule. > > What rule? The new rule that's being promoted, with effect of breaking hotplug and coldplug for platform drivers. (And SPI drivers, and any other bus that doesn't want to create needless complexity by requiring updates to module-init-tools and kbuild.) And some cases of KMOD. That is, the new rule that requires the driver identifier never to be the same as its module name ... and (a different rule?) requiring that the driver identifer always be an alias, since (courtesy of the other rule) the identifier couldn't be the module name. The one requiring that $MODALIAS become an actual alias, instead of a driver ID. (You can tell those are new rules by the fact that applying
[PATCH] Fix up compiler warnings in megaraid driver
Fix up compiler warnings in megaraid driver
Signed-off-by: Martin J. Bligh <[EMAIL PROTECTED]>
diff -aurpN -X /home/mbligh/.diff.exclude linux-2.6.19/drivers/scsi/megaraid.c
2.6.19-megaraid/drivers/scsi/megaraid.c
--- linux-2.6.19/drivers/scsi/megaraid.c2006-12-04 17:52:00.0
-0800
+++ 2.6.19-megaraid/drivers/scsi/megaraid.c 2006-12-04 18:24:03.0
-0800
@@ -73,10 +73,14 @@ static unsigned short int max_mbox_busy_
module_param(max_mbox_busy_wait, ushort, 0);
MODULE_PARM_DESC(max_mbox_busy_wait, "Maximum wait for mailbox in microseconds
if busy (default=MBOX_BUSY_WAIT=10)");
-#define RDINDOOR(adapter) readl((adapter)->base + 0x20)
-#define RDOUTDOOR(adapter) readl((adapter)->base + 0x2C)
-#define WRINDOOR(adapter,value)writel(value, (adapter)->base +
0x20)
-#define WROUTDOOR(adapter,value) writel(value, (adapter)->base + 0x2C)
+#define RDINDOOR(adapter) readl((volatile void __iomem *) \
+ (adapter)->base + 0x20)
+#define RDOUTDOOR(adapter) readl((volatile void __iomem *) \
+ (adapter)->base + 0x2C)
+#define WRINDOOR(adapter,value)writel(value, (volatile void
__iomem *)\
+ (adapter)->base + 0x20)
+#define WROUTDOOR(adapter,value) writel(value, (volatile void __iomem *)\
+ (adapter)->base + 0x2C)
/*
* Global variables
@@ -3566,7 +3570,7 @@ megadev_ioctl(struct inode *inode, struc
/*
* The user passthru structure
*/
- upthru = (mega_passthru __user *)MBOX(uioc)->xferaddr;
+ upthru = (mega_passthru __user *)(unsigned
long)MBOX(uioc)->xferaddr;
/*
* Copy in the user passthru here.
@@ -3618,7 +3622,7 @@ megadev_ioctl(struct inode *inode, struc
/*
* Get the user data
*/
- if( copy_from_user(data, (char __user
*)uxferaddr,
+ if( copy_from_user(data, (char __user
*)(unsigned long) uxferaddr,
pthru->dataxferlen) ) {
rval = (-EFAULT);
goto freemem_and_return;
@@ -3644,7 +3648,7 @@ megadev_ioctl(struct inode *inode, struc
* Is data going up-stream
*/
if( pthru->dataxferlen && (uioc.flags & UIOC_RD) ) {
- if( copy_to_user((char __user *)uxferaddr, data,
+ if( copy_to_user((char __user *)(unsigned long)
uxferaddr, data,
pthru->dataxferlen) ) {
rval = (-EFAULT);
}
@@ -3697,7 +3701,7 @@ freemem_and_return:
/*
* Get the user data
*/
- if( copy_from_user(data, (char __user
*)uxferaddr,
+ if( copy_from_user(data, (char __user
*)(unsigned long) uxferaddr,
uioc.xferlen) ) {
pci_free_consistent(pdev,
@@ -3737,7 +3741,7 @@ freemem_and_return:
* Is data going up-stream
*/
if( uioc.xferlen && (uioc.flags & UIOC_RD) ) {
- if( copy_to_user((char __user *)uxferaddr, data,
+ if( copy_to_user((char __user *)(unsigned long)
uxferaddr, data,
uioc.xferlen) ) {
rval = (-EFAULT);
Re: [rfc] possible page manipulation simplifications?
On Mon, Dec 04, 2006 at 03:55:52PM +0100, Nick Piggin wrote:
> Hi Mel,
>
> I think you're right about the leakage, thanks for catching it.
Yeah, it caused oom storm here.
The pagevec simplification looks nice.
I've ported it to -mm, hope it is useful.
I'm prepared to test your revised patch :)
Fengguang Wu
---
--- linux-2.6.19-rc6-mm2.orig/mm/filemap.c
+++ linux-2.6.19-rc6-mm2/mm/filemap.c
@@ -708,26 +708,18 @@ EXPORT_SYMBOL(find_lock_page);
struct page *find_or_create_page(struct address_space *mapping,
unsigned long index, gfp_t gfp_mask)
{
- struct page *page, *cached_page = NULL;
+ struct page *page;
int err;
repeat:
page = find_lock_page(mapping, index);
if (!page) {
- if (!cached_page) {
- cached_page = alloc_page(gfp_mask);
- if (!cached_page)
- return NULL;
- }
- err = add_to_page_cache_lru(cached_page, mapping,
- index, gfp_mask);
- if (!err) {
- page = cached_page;
- cached_page = NULL;
- } else if (err == -EEXIST)
+ page = alloc_page(gfp_mask);
+ if (!page)
+ return NULL;
+ err = add_to_page_cache_lru(page, mapping, index, gfp_mask);
+ if (err == -EEXIST)
goto repeat;
}
- if (cached_page)
- page_cache_release(cached_page);
return page;
}
EXPORT_SYMBOL(find_or_create_page);
@@ -922,11 +914,9 @@ void do_generic_mapping_read(struct addr
unsigned long next_index;
unsigned long prev_index;
loff_t isize;
- struct page *cached_page;
int error;
struct file_ra_state ra = *_ra;
- cached_page = NULL;
index = *ppos >> PAGE_CACHE_SHIFT;
next_index = index;
prev_index = ra.prev_page;
@@ -1107,14 +1097,12 @@ no_cached_page:
* Ok, it wasn't cached, so we need to create a new
* page..
*/
- if (!cached_page) {
- cached_page = page_cache_alloc_cold(mapping);
- if (!cached_page) {
- desc->error = -ENOMEM;
- goto out;
- }
+ page = page_cache_alloc_cold(mapping);
+ if (!page) {
+ desc->error = -ENOMEM;
+ goto out;
}
- error = add_to_page_cache_lru(cached_page, mapping,
+ error = add_to_page_cache_lru(page, mapping,
index, GFP_KERNEL);
if (error) {
if (error == -EEXIST)
@@ -1122,8 +1110,6 @@ no_cached_page:
desc->error = error;
goto out;
}
- page = cached_page;
- cached_page = NULL;
goto readpage;
}
@@ -1133,8 +1119,6 @@ out:
_ra->prev_page = prev_index;
*ppos = ((loff_t) index << PAGE_CACHE_SHIFT) + offset;
- if (cached_page)
- page_cache_release(cached_page);
if (filp)
file_accessed(filp);
}
@@ -1826,35 +1810,28 @@ static inline struct page *__read_cache_
int (*filler)(void *,struct page*),
void *data)
{
- struct page *page, *cached_page = NULL;
+ struct page *page;
int err;
repeat:
page = find_get_page(mapping, index);
if (!page) {
- if (!cached_page) {
- cached_page = page_cache_alloc_cold(mapping);
- if (!cached_page)
- return ERR_PTR(-ENOMEM);
- }
- err = add_to_page_cache_lru(cached_page, mapping,
- index, GFP_KERNEL);
+ page = page_cache_alloc_cold(mapping);
+ if (!page)
+ return ERR_PTR(-ENOMEM);
+ err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
if (err == -EEXIST)
goto repeat;
if (err < 0) {
/* Presumably ENOMEM for radix tree node */
- page_cache_release(cached_page);
+ page_cache_release(page);
return ERR_PTR(err);
}
- page = cached_page;
- cached_page = NULL;
err = filler(data, page);
if (err < 0) {
page_cache_release(page);
page = ERR_PTR(err);
}
}
- if (cached_page)
-
Re: Why SCSI module needed for PCI-IDE ATA only disks ?
Jeff Garzik wrote: Bernard Pidoux wrote: I am asking why need to compile the following modules while I do not have any SCSI device ? libata uses SCSI to provide a lot of infrastructure that it would otherwise have to recreate. Also, using SCSI meant that it automatically worked in existing installers. Jeff This confusion could easily be remedied by explaining the requirement in the Help output for libata drivers/section. Also, making a dependency in the menu (since there is one) or automatically selecting the required scsi items when you select a libata driver would seem logical. As it is, nothing is said of scsi requirements in menuconfig. Trying to boot a machine without compiling the scsi drivers (something you're allowed to do) results in a system that boots and initializes the ata busses but can't communicate to any of the drives on them, (useless). Then maybe later down the road, moving those scsi drivers shared by scsi and libata to the generic block layer would seem logical. That is, when ide is gone from the kernel and all the kernel speaks is scsi, there would be no need to differentiate scsi from the generic block layer devices, and no need to compile "scsi" drivers to have libata driver support, eliminating any possible further confusion. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-mm2
On Wednesday November 29, [EMAIL PROTECTED] wrote: > On Tue, 28 Nov 2006, Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/ > > md-change-lifetime-rules-for-md-devices.patch gives me the following early > during boot (first WARNING() inside __mutex_lock_slowpath(), then BUG at > __mutex_lock_slowpath(), just after that slab corruption). > > When I revert md-change-lifetime-rules-for-md-devices.patch, everything > seems to go fine (this machine does use neither LVM nor RAID, but the > kernel has DM compiled in). > > Config is at http://www.jikos.cz/jikos/junk/.config_md > > WARNING at kernel/mutex.c:132 __mutex_lock_common() > [] dump_trace+0x68/0x1b5 > [] show_trace_log_lvl+0x18/0x2c > [] show_trace+0xf/0x11 > [] dump_stack+0x12/0x14 > [] __mutex_lock_slowpath+0xa1/0x213 > [] create_dir+0x24/0x1ba > [] sysfs_create_dir+0x45/0x5f > [] kobject_add+0xce/0x185 > [] kobject_register+0x19/0x30 > [] md_probe+0x11a/0x124 Very odd. md_probe is registering a kobject presenting md specific stuff and that creates a directory called 'md' inside the block device. e.g. /sys/block/md0/md The inode for /sys/block/md0 appear to be non-existent at this point, which as you are seeing poisoned memory where the inode should be. This shouldn't happen and I cannot reproduce it. I notice it says: | v > 090: 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > Single bit error detected. Probably bad RAM. > Run memtest86+ or a similar memory test tool. Have you tried running memtest86 ?? NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 git compile error - "current_is_keventd" [drivers/net/phy/libphy.ko] undefined
[EMAIL PROTECTED] wrote: > 2006/12/04/18:00 CST > > Building modules, stage 2. > Kernel: arch/x86_64/boot/bzImage is ready (#2) > MODPOST 1256 modules > WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 Also i686, sparc64. At drivers/net/phy/phy.c:590 is the lone reference to current_is_keventd in that directory. Still present as of ff51a9... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git6 header error
On Mon, 4 Dec 2006 17:03:24 -0800 Randy Dunlap wrote: > linux-2.6.19-git6/usr/include/linux/netfilter.h requires linux/rcupdate.h, > which does not exist in exported headers > make[3]: *** > [/var/linsrc/linux-2.6.19-git6/usr/include/linux/.check.netfilter.h] Error 1 > make[2]: *** [linux] Error 2 > make[1]: *** [headers_check] Error 2 > make: *** [vmlinux] Error 2 Oops, Al has already fixed this one. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs NET=n build error
On Monday December 4, [EMAIL PROTECTED] wrote:
>
> Ingo, Neil:
>
> Al has summarized that csum_partial() is arch-specific.
> However, drivers/md/md.c uses it.
Yep.
>
> Does that mean that RAID volumes are not portable across
> (some) architectures?
Yep. version-0.90 superblocks are already not portable between archs
of different endianness. There can also be issues between arch with
different implementations of csum_partial, though the use of csum_fold
in
if (csum_fold(calc_sb_csum(sb)) != csum_fold(sb->sb_csum)) {
printk(KERN_WARNING "md: invalid superblock checksum on %s\n",
b);
(in super_90_load in md.c) tries to alleviate this.
>
> Should md.c use a specific, known, fixed (as in static,
> arch-independent) version of csum_partial()?
For version-1 superblocks it uses arch-independent byte-order and
arch-independent checksums but
>
> Will changing now possibly make some existing volumes
> non-portable?
.. it really is too late for 0.90 superblocks. Certainly changing it
would back things for people who want to revert to an earlier kernel.
The use of csum_fold has been in place since late 2004 so you would
need to go quite a long way back to hit problems... and if you go that
far back you could hit problems with mdadm too (as mdadm calculated
the checksum the same on all architectures...).
So maybe we could get rid of csum_partial and use a replacement and
still have most things work tested patched would be considered :-)
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
Hi, your plan looks good to me. some comments. On Mon, 4 Dec 2006 23:45:32 + (GMT) Mel Gorman <[EMAIL PROTECTED]> wrote: > 1. Use lumpy-reclaim to intelligently reclaim contigous pages. The same > logic can be used to reclaim within a PFN range > 2. Merge anti-frag to help high-order allocations, hugetlbpage > allocations and freeing up SPARSEMEM sections of memory For freeing up SPARSEMEM sections of memory ? It looks that you assumes MAX_ORDER_NR_PAGES equals to PAGES_PER_SECTION. plz don't assume that when you talk about generic arch code. > 3. Anti-frag includes support for page flags that affected a MAX_ORDER block > of pages. These flags can be used to mark a section of memory that should > not be allocated from. This is of interest to both hugetlb page allocatoin > and memory hot-remove. Use the flags to mark a MAX_ORDER_NR_PAGES that > is currently being freed up and shouldn't be allocated. > 4. Use anti-frag fallback logic to bias unmovable allocations to the lower > PFNs. I think this can be one of the most diffcult things ;) > 5. Add arch support where possible for offlining sections of memory that > can be powered down. I had a patch for ACPI-memory-hot-unplug, which ties memory sections to memory chunk on ACPI. > 6. Add arch support where possible to power down a DIMM when the memory > sections that make it up have been offlined. This is an extenstion of > step 5 only. > 7. Add a zone that only allows __GFP_MOVABLE allocations so that > sections can 100% be reclaimed and powered-down > 8. Allow nodes to only have a zone for __GFP_MOVABLE allocations so that > whole nodes can be offlined. > I (numa-node-hotplug) needs 7 and 8 basically. And Other people may not. IMHO: For DIMM unplug, I suspect that we'll finally divide memory to core-memory and hot-pluggable by pgdat even on SMP. If we use pgdat for that purpose, almost all necessary infrastructure(statistics ,etc..) is ready. But if we find better way, it's good. -Kame - 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.19-git6 header error
linux-2.6.19-git6/usr/include/linux/netfilter.h requires linux/rcupdate.h, which does not exist in exported headers make[3]: *** [/var/linsrc/linux-2.6.19-git6/usr/include/linux/.check.netfilter.h] Error 1 make[2]: *** [linux] Error 2 make[1]: *** [headers_check] Error 2 make: *** [vmlinux] Error 2 --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Relative atime (was Re: What's in ocfs2.git)
On Mon, Dec 04, 2006 at 04:36:20PM -0800, Valerie Henson wrote:
> On Mon, Dec 04, 2006 at 04:10:07PM -0800, Mark Fasheh wrote:
> > Hi Steve,
> >
> > On Mon, Dec 04, 2006 at 10:54:53AM +, Steven Whitehouse wrote:
> > > > In the future, I'd like to see a "relative atime" mode, which functions
> > > > in the manner described by Valerie Henson at:
> > > >
> > > > http://lkml.org/lkml/2006/8/25/380
> > > >
> > > I'd like to second that. [adding Val Henson to the "to"] What (if
> > > anything) remains to be done before the relative atime patch is ready to
> > > go upstream? I'm happy to help out here if required,
> > Last time I looked at them, things seemed to be in pretty good shape - it
> > wasn't a very large patch series.
And the userland part.
-VAL
Add the "relatime" (relative atime) option support to mount. Relative
atime only updates the atime if the previous atime is older than the
mtime or ctime. Like noatime, but useful for applications like mutt
that need to know when a file has been read since it was last
modified.
Signed-off-by: Valerie Henson <[EMAIL PROTECTED]>
---
mount/mount.8 |7 +++
mount/mount.c |6 ++
mount/mount_constants.h |4
3 files changed, 17 insertions(+)
--- util-linux-2.13-pre7.orig/mount/mount.8
+++ util-linux-2.13-pre7/mount/mount.8
@@ -586,6 +586,13 @@ access on the news spool to speed up new
.B nodiratime
Do not update directory inode access times on this filesystem.
.TP
+.B relatime
+Update inode access times relative to modify or change time. Access
+time is only updated if the previous access time was earlier than the
+current modify or change time. (Similar to noatime, but doesn't break
+mutt or other applications that need to know if a file has been read
+since the last time it was modified.)
+.TP
.B noauto
Can only be mounted explicitly (i.e., the
.B \-a
--- util-linux-2.13-pre7.orig/mount/mount.c
+++ util-linux-2.13-pre7/mount/mount.c
@@ -164,6 +164,12 @@ static const struct opt_map opt_map[] =
{ "diratime",0, 1, MS_NODIRATIME }, /* Update dir access times */
{ "nodiratime", 0, 0, MS_NODIRATIME },/* Do not update dir access times */
#endif
+#ifdef MS_RELATIME
+ { "relatime", 0, 0, MS_RELATIME }, /* Update access times relative to
+ mtime/ctime */
+ { "norelatime", 0, 1, MS_RELATIME }, /* Update access time without regard
+ to mtime/ctime */
+#endif
{ NULL, 0, 0, 0 }
};
--- util-linux-2.13-pre7.orig/mount/mount_constants.h
+++ util-linux-2.13-pre7/mount/mount_constants.h
@@ -57,6 +57,10 @@ if we have a stack or plain mount - moun
#ifndef MS_VERBOSE
#define MS_VERBOSE 0x8000 /* 32768 */
#endif
+#ifndef MS_RELATIME
+#define MS_RELATIME 0x20 /* 20: Update access times relative
+ to mtime/ctime */
+#endif
/*
* Magic mount flag number. Had to be or-ed to the flag values.
*/
-
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 2/2] x86_64: earlyprintk usb debug device support.
On Mon, Dec 04, 2006 at 02:26:52PM -0700, Eric W. Biederman wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > > On Mon, Dec 04, 2006 at 12:18:30PM -0800, Lu, Yinghai wrote: > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> > >> >arch/x86_64/kernel/early_printk.c | 574 > >> + > >> > drivers/usb/host/ehci.h |8 + > >> > include/asm-x86_64/fixmap.h |1 > >> > >> Can you separate usbdebug handle out from early_printk? > > > > Yeah, at least tear it out of x86-64, so those of us stuck on different > > platforms can use this :) > > > > Other than that minor issue, this looks great. I don't have a x86-64 > > box set up here at the moment, so I can't test it, but it looks > > acceptable at first glance. > > Makes sense. I'm curious now what architecture do you have? i386 My main development box these days is a mac mini due to it's great form factor and ability to suspend to ram easily. Unfortunately they don't come with a working 64bit processor just yet. > Anyway next time I touch this the project will be how to integrate > this into the kernel cleanly. This round was to figure out how > to get some working code. > > If someone beats me to the punch on generalizing this code I won't > mind. > > The first pass was a success. And the performance is reasonable > assuming you don't plug the end you are watching into a usb1 only > port. > > Given that I didn't really know anything about usb a week ago I think > I did pretty well :) Yes, you certainly did, no complaint from me at all about that :) thanks, greg k-h - 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/
Relative atime (was Re: What's in ocfs2.git)
On Mon, Dec 04, 2006 at 04:10:07PM -0800, Mark Fasheh wrote:
> Hi Steve,
>
> On Mon, Dec 04, 2006 at 10:54:53AM +, Steven Whitehouse wrote:
> > > In the future, I'd like to see a "relative atime" mode, which functions
> > > in the manner described by Valerie Henson at:
> > >
> > > http://lkml.org/lkml/2006/8/25/380
> > >
> > I'd like to second that. [adding Val Henson to the "to"] What (if
> > anything) remains to be done before the relative atime patch is ready to
> > go upstream? I'm happy to help out here if required,
> Last time I looked at them, things seemed to be in pretty good shape - it
> wasn't a very large patch series.
Yep, the relative atime patch is tiny and pretty much done - just
needs some soak time in -mm and a little more review (cc'd Viro and
fsdevel). Kernel patch against 2.6.18-rc4 appended, patch to mount
following. (Note that my web server suffered a RAID failure and my
patches page is unavailable till the restore finishes.)
-VAL
Add "relatime" (relative atime) support. Relative atime only updates
the atime if the previous atime is older than the mtime or ctime.
Like noatime, but useful for applications like mutt that need to know
when a file has been read since it was last modified.
Signed-off-by: Valerie Henson <[EMAIL PROTECTED]>
---
fs/inode.c| 11 ++-
fs/namespace.c|5 -
include/linux/fs.h|1 +
include/linux/mount.h |1 +
4 files changed, 16 insertions(+), 2 deletions(-)
--- linux-2.6.18-rc4-relatime.orig/fs/inode.c
+++ linux-2.6.18-rc4-relatime/fs/inode.c
@@ -1200,7 +1200,16 @@ void touch_atime(struct vfsmount *mnt, s
return;
now = current_fs_time(inode->i_sb);
- if (!timespec_equal(>i_atime, )) {
+ if (timespec_equal(>i_atime, ))
+ return;
+ /*
+* With relative atime, only update atime if the previous
+* atime is earlier than either the ctime or mtime.
+*/
+ if (!mnt ||
+ !(mnt->mnt_flags & MNT_RELATIME) ||
+ (timespec_compare(>i_atime, >i_mtime) < 0) ||
+ (timespec_compare(>i_atime, >i_ctime) < 0)) {
inode->i_atime = now;
mark_inode_dirty_sync(inode);
}
--- linux-2.6.18-rc4-relatime.orig/fs/namespace.c
+++ linux-2.6.18-rc4-relatime/fs/namespace.c
@@ -376,6 +376,7 @@ static int show_vfsmnt(struct seq_file *
{ MNT_NOEXEC, ",noexec" },
{ MNT_NOATIME, ",noatime" },
{ MNT_NODIRATIME, ",nodiratime" },
+ { MNT_RELATIME, ",relatime" },
{ 0, NULL }
};
struct proc_fs_info *fs_infop;
@@ -1413,9 +1414,11 @@ long do_mount(char *dev_name, char *dir_
mnt_flags |= MNT_NOATIME;
if (flags & MS_NODIRATIME)
mnt_flags |= MNT_NODIRATIME;
+ if (flags & MS_RELATIME)
+ mnt_flags |= MNT_RELATIME;
flags &= ~(MS_NOSUID | MS_NOEXEC | MS_NODEV | MS_ACTIVE |
- MS_NOATIME | MS_NODIRATIME);
+ MS_NOATIME | MS_NODIRATIME | MS_RELATIME);
/* ... and get the mountpoint */
retval = path_lookup(dir_name, LOOKUP_FOLLOW, );
--- linux-2.6.18-rc4-relatime.orig/include/linux/fs.h
+++ linux-2.6.18-rc4-relatime/include/linux/fs.h
@@ -119,6 +119,7 @@ extern int dir_notify_enable;
#define MS_PRIVATE (1<<18) /* change to private */
#define MS_SLAVE (1<<19) /* change to slave */
#define MS_SHARED (1<<20) /* change to shared */
+#define MS_RELATIME(1<<21) /* Update atime relative to mtime/ctime. */
#define MS_ACTIVE (1<<30)
#define MS_NOUSER (1<<31)
--- linux-2.6.18-rc4-relatime.orig/include/linux/mount.h
+++ linux-2.6.18-rc4-relatime/include/linux/mount.h
@@ -27,6 +27,7 @@ struct namespace;
#define MNT_NOEXEC 0x04
#define MNT_NOATIME0x08
#define MNT_NODIRATIME 0x10
+#define MNT_RELATIME 0x20
#define MNT_SHRINKABLE 0x100
-
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: reiserfs NET=n build error
On Tue, 28 Nov 2006 11:47:57 -0800 Randy Dunlap wrote: > On Sun, 19 Nov 2006 17:32:11 -0500 Jeff Mahoney wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Al Viro wrote: > > > On Sun, Nov 19, 2006 at 11:04:33AM -0800, Randy Dunlap wrote: > > >> Andi Kleen wrote: > > > I would copy a relatively simple C implementation, like > > > arch/h8300/lib/checksum.c > > As long as the h8300 version has the same output as the x86 version. > > >>> The trouble is that the different architecture have different output > > >>> for csum_partial. So you already got a bug when someone wants to move > > >>> file systems. > > >>> > > >>> -Andi > > >> That argues for having only one version of it (in a lib.; my preference) > > >> -or- Every module having its own local copy/version of it. :( > > > > > > Wrong. csum_partial() result is defined modulo 0x and it's basically > > > "whatever's convenient as intermediate for this architecture". > > > > > > reiserfs use of it is just plain broken. net/* is fine, since all > > > final uses are via csum_fold() or equivalents. > > > > > > Note that reiserfs use is broken in another way: it takes fixed-endian > > > value > > > and feeds it to cpu_to_le32(). IOW, even if everything had literally the > > > same csum_partial(), the value it shits on disk would be endian-dependent. > > > > Oh great. Even better. :( > > Even more: MD/raid (=m) is broken in this way also. > It uses csum_partial(), which isn't present (CONFIG_NET=n). > > Kernel: arch/x86_64/boot/bzImage is ready (#9) > Building modules, stage 2. > MODPOST 101 modules > WARNING: "csum_partial" [drivers/md/md-mod.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > CONFIG_MD=y > CONFIG_BLK_DEV_MD=m > CONFIG_MD_LINEAR=m > # CONFIG_MD_RAID0 is not set > CONFIG_MD_RAID1=m > # CONFIG_MD_RAID10 is not set > # CONFIG_MD_RAID456 is not set > CONFIG_MD_MULTIPATH=m > # CONFIG_MD_FAULTY is not set > CONFIG_BLK_DEV_DM=y > CONFIG_DM_DEBUG=y > CONFIG_DM_CRYPT=m > CONFIG_DM_SNAPSHOT=y > CONFIG_DM_MIRROR=y > CONFIG_DM_ZERO=m > CONFIG_DM_MULTIPATH=y > CONFIG_DM_MULTIPATH_EMC=m > > --- > ~Randy > full broken config for MD: > http://oss.oracle.com/~rdunlap/configs/config-md-csum Ingo, Neil: Al has summarized that csum_partial() is arch-specific. However, drivers/md/md.c uses it. Does that mean that RAID volumes are not portable across (some) architectures? Should md.c use a specific, known, fixed (as in static, arch-independent) version of csum_partial()? Will changing now possibly make some existing volumes non-portable? Thanks, --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mounting NFS root FS
Trond Myklebust wrote: On Mon, 2006-12-04 at 22:05 +0200, Janne Karhunen wrote: On Monday 04 December 2006 20:21, Trond Myklebust wrote: 2) NFS provides persistent storage. To me this sounds like a chicken and an egg problem. It both depends and provides this at the same time :/. But hey, if it's supposed to work then OK. ??? Locking depends on persistent storage, but persistent storage never depended on locking. Except for the fact that to be able to mount anything RW you generally _want_ to have locks. And can't have locks without the mount. Not that it wouldn't work, it's just that I would not do it [for obvious reasons]. You just need to be careful to set it up correctly in the initrd: either make sure that you mount the root partition as 'nolock' or else make sure that you mount /var/lib/nfs, and start rpc.statd before you start init and any other applications that might need locking. The nfsmount which is in the klibc distribution supports running an ad hoc portmap daemon, which allows locking to be done by forwarding information to the "real" portmap for when the real rpc.statd is run. -hpa - 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] rfkill - Add support for input key to control wireless radio
On Sun, 3 Dec 2006 23:28:11 +0100 Ivo van Doorn wrote:
> rfkill with the fixes as suggested by Arjan.
> - instead of a semaphore a mutex is now being used.
> - open_count changing is now locked by the mutex.
>
> ---
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index ba0e88c..6986d59 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -79,4 +79,19 @@ config HP_SDC_RTC
> Say Y here if you want to support the built-in real time clock
> of the HP SDC controller.
>
> +config RFKILL
> + tristate "RF button support"
depends on SYSFS
> + help
> + If you say yes here, the rfkill driver will be build
s/build/built/
> + which allowed network devices to register their hardware
s/allowed/allows/
> + RF button which controls the radio state. This driver
> + will then create an input device for it.
> +
> + When the input device is not used, the rfkill driver
> + will make sure that when the RF button is pressed the radio
> + is enabled or disabled accordingly. When the input device
> + has been opened by the user this radio control will be left
> + to the user, and rfkill will only send the RF button status
> + change to userspace.
> +
> endif
> diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
> new file mode 100644
> index 000..4777d73
> --- /dev/null
> +++ b/drivers/input/misc/rfkill.c
> @@ -0,0 +1,887 @@
[snip]
> +/*
> + * Function called by the key driver to report the new status
> + * of the key.
> + */
> +void rfkill_report_event(struct rfkill *rfkill, int new_status)
> +{
> + mutex_lock(>mutex);
> +
> + if (rfkill_check_key(rfkill->key, new_status))
> + schedule_work(>toggle_work);
> +
> + mutex_unlock(>mutex);
> +}
> +EXPORT_SYMBOL_GPL(rfkill_report_event);
Please use kernel-doc notation for non-static functions.
See Documentation/kernel-doc-nano-HOWTO.txt for more info.
> +/*
> + * Function called by the key driver when the rfkill structure
> + * needs to be registered.
> + */
kernel-doc please.
> +int rfkill_register_key(struct rfkill *rfkill, int init_status)
> +{
> + struct rfkill_type *type = >type[rfkill->key_type];
> + struct rfkill_key *key;
> + int status;
> +
> + if (!rfkill)
> + return -EINVAL;
> +
> + if (rfkill->key_type >= KEY_TYPE_MAX)
> + return -EINVAL;
> +
> + /*
> + * Increase module use count to prevent this
> + * module to be unloaded while there are still
> + * registered keys.
> + */
> + if (!try_module_get(THIS_MODULE))
> + return -EBUSY;
> +
> + mutex_lock(>mutex);
> +
> + /*
> + * Initialize key, and if required the type.
> + */
> + status = rfkill_add_type_key(type);
> + if (status)
> + goto exit;
> +
> + key = rfkill_key_init(rfkill, init_status);
> + if (!key) {
> + status = -ENOMEM;
> + goto exit_type;
> + }
> +
> + /*
> + * Add key to our list.
> + */
> + list_add(>entry, >key_list);
> +
> + /*
> + * Check if we need polling, and if we do
> + * increase the poll required counter and check
> + * if we weren't polling yet.
> + */
> + if (rfkill->poll && !master->poll_required++)
> + schedule_delayed_work(>poll_work, RFKILL_POLL_DELAY);
> +
> + mutex_unlock(>mutex);
> +
> + return 0;
> +
> +exit_type:
> + rfkill_del_type_key(type);
> +
> +exit:
> + mutex_unlock(>mutex);
> + module_put(THIS_MODULE);
> +
> + return status;
> +}
> +EXPORT_SYMBOL_GPL(rfkill_register_key);
> +
> +/*
> + * Function called by the key driver when the rfkill structure
> + * needs to be deregistered.
> + */
kernel-doc
> +int rfkill_deregister_key(struct rfkill *rfkill)
> +{
> + struct rfkill_type *type;
> +
> + if (!rfkill || !rfkill->key)
> + return -EINVAL;
> +
> + mutex_lock(>mutex);
> +
> + /*
> + * Cancel delayed work if this is the last key
> + * that requires polling. It is not bad if
> + * if the workqueue is still running,
> + * the workqueue won't rearm itself since the
> + * poll_required variable has been set.
> + * and we have protected the list with a semaphore.
> + */
> + if (rfkill->poll && !--master->poll_required)
> + cancel_delayed_work(>poll_work);
> +
> + /*
> + * Delete the rfkill structure to the list.
> + */
> + list_del(>key->entry);
> +
> + /*
> + * Deinitialize key.
> + */
> + type = rfkill->key->type;
> + rfkill_key_deinit(rfkill->key);
> + rfkill_del_type_key(type);
> +
> + mutex_unlock(>mutex);
> +
> + /*
> + * rfkill entry has been removed,
> + * decrease module use count.
> + */
> + module_put(THIS_MODULE);
> +
> + return 0;
> +}
>
Re: v2.6.19-rt1, yum/rpm
Am Donnerstag, 30. November 2006 09:33 schrieb Ingo Molnar:
> i have released the 2.6.19-rt1 tree, which can be downloaded from the
Hi Ingo,
here comes a freerunning trace explaining the weirdness I see here.
I tried max_latency tracing first, didn't see anything usefull,
went on with tracing freerunning with a user_trace_stop() at the spot,
where snd-usb-usx2y diagnoses hickup.
I tweaked latency_trace.c to make freerunning work. Will post later.
To get an overview of whats happening, search in this e-mail for
i_usX2Y_usbpcm_urb_complete
. Its the interrupt callback.
Those were the rt priorities with IRQ 17 driving the usb soundcard:
$ ps -ALc|grep FF
2 2 FF 90 ?00:00:00 posix_cpu_timer
3 3 FF 41 ?00:00:00 softirq-high/0
4 4 FF 41 ?00:00:00 softirq-timer/0
5 5 FF 41 ?00:00:00 softirq-net-tx/
6 6 FF 41 ?00:00:00 softirq-net-rx/
7 7 FF 41 ?00:00:00 softirq-block/0
8 8 FF 41 ?00:00:06 softirq-tasklet
9 9 FF 41 ?00:00:00 softirq-hrtimer
1010 FF 41 ?00:00:00 softirq-rcu/0
1111 FF 139 ?00:00:00 watchdog/0
1313 FF 41 ?00:00:00 events/0
5050 FF 89 ?00:00:00 IRQ 9
242 242 FF 88 ?00:00:00 IRQ 8
273 273 FF 87 ?00:00:00 IRQ 14
275 275 FF 86 ?00:00:00 IRQ 15
295 295 FF 85 ?00:00:00 IRQ 12
296 296 FF 84 ?00:00:00 IRQ 1
308 308 FF 120 ?00:00:30 IRQ 17
735 735 FF 110 ?00:00:00 IRQ 19
1329 1329 FF 81 ?00:00:00 IRQ 6
1338 1338 FF 80 ?00:00:00 IRQ 7
1684 1684 FF 110 ?00:00:06 IRQ 18
2198 2198 FF 78 ?00:00:00 IRQ 4
2667 2672 FF 49 pts/000:00:00 ardour.bin
2700 2700 FF 90 ?00:00:00 artsd
$ cat /proc/interrupts
CPU0
0:1477957 IO-APIC[N/ 0]-edge timer
1: 7560 IO-APIC[...M./ 0]-edge i8042
4: 12 IO-APIC[...M./ 3]-edge serial
7: 0 IO-APIC[..PM./ 0]-edge parport0
8: 1 IO-APIC[./ 0]-edge rtc
9: 0 IO-APIC[./ 0]-fasteoi acpi
12: 62839 IO-APIC[...M./ 0]-edge i8042
14: 22303 IO-APIC[...M./ 0]-edge ide0
15: 10169 IO-APIC[...M./ 0]-edge ide1
17: 967826 IO-APIC[./ 0]-fasteoi uhci_hcd:usb1,
uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, ehci_hcd:usb5
18: 247356 IO-APIC[./ 1]-fasteoi eth0, nvidia
19:979 IO-APIC[./ 0]-fasteoi VIA8237
NMI: 0
LOC:834
ERR: 0
MIS: 0
Edited Trace, first part showing normal operation,
second part showing things getting weired:
preemption latency trace v1.1.5 on 2.6.19-rt1.dbg
latency: 491583660 us, #131071/131071, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1)
-
| task: IRQ 17-308 (uid:0 nice:-5 policy:1 rt_prio:80)
-
=> started at: snd_usX2Y_pcm_trigger+0x30/0xf4
=> ended at: __schedule+0x680/0x70e
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
qjackctl-2668 0D...0us < (0)
qjackctl-2668 00us > sys_gettimeofday (b7212324 007b)
qjackctl-2668 0D...2us < (0)
qjackctl-2668 02us > sys_write (0010 b721338a 007b)
qjackctl-2668 04us : try_to_wake_up (c011b4ab 0 0)
qjackctl-2668 0D..15us : __activate_task (172 1)
qjackctl-2668 0D...6us < (1)
qjackctl-2668 06us+> sys_read (000f b721338a 007b)
qjackctl-2668 0D...9us < (1)
qjackctl-2668 0 10us+> sys_poll (0823dea8 0002 007b)
qjackctl-2668 0...1 12us : __schedule (c032a995 0 0)
qjackctl-2668 0D..2 13us : deactivate_task (172 2)
ardour.b-2675 0D..2 14us+: __schedule (172 172)
ardour.b-2675 0D... 17us < (1)
ardour.b-2675 0 18us > sys_gettimeofday (b01fe324 007b)
ardour.b-2675 0D... 20us!< (0)
ardour.b-2675 0D.h. 178us+: do_IRQ (b6281a8a 0 0)
ardour.b-2675 0D.h1 185us : hrtimer_interrupt (d2f6b90d72 eccc1f4c)
ardour.b-2675 0D.h1 185us : try_to_wake_up (c011b58b 0 0)
ardour.b-2675 0D.h2 186us : effective_prio (-5 -5)
ardour.b-2675 0D.h2 187us!: __activate_task (-5 1)
ardour.b-2675 0D.h. 576us : do_IRQ (b61ead92 18 0)
ardour.b-2675 0D.h1 576us : try_to_wake_up (c011b58b 0 0)
ardour.b-2675 0D.h2 577us!:
2.6.19 git compile error - "current_is_keventd" [drivers/net/phy/libphy.ko] undefined
to: linux-kernel@vger.kernel.org cc: [EMAIL PROTECTED] 2006/12/04/18:00 CST Building modules, stage 2. Kernel: arch/x86_64/boot/bzImage is ready (#2) MODPOST 1256 modules WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 xboom - 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: why can't I remove a kernel module (or: what uses a given module)?
On Mon, Dec 04, 2006 at 11:10:01AM +0100, Tobias Oed wrote: > Tomasz Chmielewski wrote: > > > Yes, something's using that drive, be it a program, a module (unlikely), > > or something that is compiled directly in the kernel (for example, > > md/raid1). > > Since you mention md, dm comes to mind. I have seen a couple of drives that > were previously attached to fake raid controllers becoming unavailable when > moved to a normal controller. I haven't found the one size workaround for > the problem yet. dmraid -r -E Yes, I was hit by this in a different context. A command is described on 'man dmraid' but figuring out what was the issue took me a long while. Michal - 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: What's in ocfs2.git
Hi Steve, On Mon, Dec 04, 2006 at 10:54:53AM +, Steven Whitehouse wrote: > > In the future, I'd like to see a "relative atime" mode, which functions > > in the manner described by Valerie Henson at: > > > > http://lkml.org/lkml/2006/8/25/380 > > > I'd like to second that. [adding Val Henson to the "to"] What (if > anything) remains to be done before the relative atime patch is ready to > go upstream? I'm happy to help out here if required, Last time I looked at them, things seemed to be in pretty good shape - it wasn't a very large patch series. The thing is (I'm going from memory here), gfs2 and ocfs2 are likely to just make use of the option parsing (and setting of the MNT_RELATIME flag), and ignore the changes to touch_atime() since we we handle our own atime updates. Overall I think it's a matter of pushing the patches to the kernel and to mount(8). For ocfs2/gfs2 we implement a small amount of the logic in our "lock and update atime" functions. --Mark -- Mark Fasheh Senior Software Developer, Oracle [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/
[git patches] ocfs2 and configfs updates
Hi Linus, This patch set comprises the bulk of my 2.6.20 features which need to be pushed upstream. My description of the changes is below: * Various ocfs2 cleanups, including a patchset by me intended to clean up some of the internal ocfs2 journal api. Mostly this revolves around removing the ocfs2_journal_handle wrapper around handle_t. The immediate benefits are better readability and a slightly smaller memory footprint for open journal transactions. * Configfs gets some small cleanups and some mutex annotations. * Atime updates - thanks to Tiger Yang <[EMAIL PROTECTED]>, ocfs2 now writes to the inode atime field. This doesn't require any disk changes, and is completely backwards compatible with older ocfs2 versions. An inodes Atime is only updated if it hasn't changed within a certain quantum. The user can define their own value at mount time, with 0 indicating that atime should always be updated. This is very similar to the scheme implemented by gfs2. * Sys_splice - ocfs2 now has splice read and write support. Thanks again to Tiger for the bulk of this functionality. Mostly we make use of the generic_splice_read() and generic_file_splice_write_nolock() functions provided already in fs/splice.c. - There is one patch in the ocfs2 splice() series external to fs/ocfs2 - a simple export of should_remove_suid(). This is done for code reuse purposes. That particular patch can be seen at: http://ftp.kernel.org/pub/linux/kernel/people/mfasheh/ocfs2/ocfs2_git_patches/ocfs2-upstream-linus-20061201/0025-Export-should_remove_suid.txt I'll also attach it to this mail for review purposes. * Not included in this set of patches are the following updates, which I think need a few more days before they're ready (I'll push them early next week if they make the cut): - A lock migration fix within the ocfs2 dlm. - Some patches to make ocfs2 network timeout values user-adjustable. - A "local mount" patch which will give ocfs2 the ability to act as a local file system (no cluster configuration needed, no dlm locking, etc). Please pull from 'upstream-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus to receive the following updates: fs/configfs/dir.c|9 - fs/ocfs2/alloc.c | 90 +--- fs/ocfs2/alloc.h |2 fs/ocfs2/aops.c | 22 +-- fs/ocfs2/aops.h |2 fs/ocfs2/dir.c | 33 ++-- fs/ocfs2/dir.h |2 fs/ocfs2/dlm/dlmdomain.c |3 fs/ocfs2/dlmglue.c | 60 ++-- fs/ocfs2/dlmglue.h |9 - fs/ocfs2/export.c|2 fs/ocfs2/file.c | 343 --- fs/ocfs2/file.h | 11 + fs/ocfs2/inode.c | 33 +--- fs/ocfs2/inode.h |9 - fs/ocfs2/ioctl.c | 10 - fs/ocfs2/journal.c | 271 - fs/ocfs2/journal.h | 78 +- fs/ocfs2/localalloc.c| 126 +++-- fs/ocfs2/localalloc.h|3 fs/ocfs2/mmap.c | 11 + fs/ocfs2/namei.c | 296 +--- fs/ocfs2/namei.h |2 fs/ocfs2/ocfs2.h |4 fs/ocfs2/suballoc.c | 174 ++- fs/ocfs2/suballoc.h | 16 -- fs/ocfs2/super.c | 32 ++-- fs/ocfs2/symlink.c |4 mm/filemap.c |1 29 files changed, 760 insertions(+), 898 deletions(-) Adrian Bunk: [2.6 patch] make ocfs2_create_new_lock() static configfs: make configfs_dirent_exists() static Mark Fasheh: ocfs2: fix format warnings in dlm_alloc_pagevec() ocfs2: remove unused ocfs2_journal_handle field ocfs2: have ocfs2_extend_trans() take handle_t ocfs2: remove ocfs2_journal_handle flags field ocfs2: don't pass handle to ocfs2_meta_lock() in localalloc.c ocfs2: don't pass handle to ocfs2_meta_lock() in __ocfs2_flush_truncate_log() ocfs2: don't pass handle to ocfs2_meta_lock() in ocfs2_mknod() ocfs2: don't pass handle to ocfs2_meta_lock() in ocfs2_link() ocfs2: don't pass handle to ocfs2_meta_lock() in orphan dir code ocfs2: don't pass handle to ocfs2_meta_lock in ocfs2_unlink() ocfs2: don't pass handle to ocfs2_meta_lock in ocfs2_symlink() ocfs2: don't pass handle to ocfs2_meta_lock in ocfs2_rename() ocfs2: don't use handle for locking in allocation functions ocfs2: Don't allocate handle early in ocfs2_rename() ocfs2: remove unused ocfs2_handle_add_inode() ocfs2: remove unused ocfs2_handle_add_lock() ocfs2: make ocfs2_alloc_handle() static ocfs2: remove unused handle argument from ocfs2_meta_lock_full() ocfs2: pass ocfs2_super * into ocfs2_commit_trans() ocfs2: remove ocfs2_journal_handle journal field ocfs2: remove handle argument to ocfs2_start_trans() ocfs2: Remove struct
Re: [PATCH 0/4] lock stat for 2.6.19-rt1
On Mon, Dec 04, 2006 at 09:08:56AM -0800, Bill Huey wrote: > On Mon, Dec 04, 2006 at 01:21:29PM +0100, bert hubert wrote: > > How tightly is your work bound to -rt? Iow, any chance of separating the > > two? Or should we even want to? > > There's other uses for it as well. Think about RCU algorithms that need > to spin-try to make sure the update of an element or the validation of > it's data is safe to do. If an object was created to detect those spins > it'll track what is effectively contention as well as it is represented > in that algorithm. I've seen an RCU radix tree implementation do something > like that. That was a horrible paragraph plus I'm bored at the moment. What I meant is that lockless algorithms occasionally have a spin-try associated with it as well that might possibly validate the data that's updated against the entire data structure for some kind of consistency cohernecy or possibly on an individual element. That retry or spin can be considered a contention as well and it can be made aware to this lock-stat patch just by connecting the actually occurance of retry logic against a backing object. I need to be more conscious about proofreading what I write before sending it off. Was this clear ? bill - 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] Add __GFP_MOVABLE for callers to flag allocations that may be migrated
On (04/12/06 14:34), Andrew Morton didst pronounce: On Mon, 4 Dec 2006 20:34:29 + (GMT) Mel Gorman <[EMAIL PROTECTED]> wrote: > > IOW: big-picture where-do-we-go-from-here stuff. > > > > Start with lumpy reclaim, I had lumpy-reclaim in my todo-queue but it seems to have gone away. I think I need a lumpy-reclaim resend, please. I believe the patches conflicted with the latest -mm and it was going through another rebase and retest cycle. > then I'd like to merge page clustering piece by > piece, ideally with one of the people with e1000 problems testing to see > does it make a difference. > > Assuming they are shown to help, where we'd go from there would be stuff > like; > > 1. Keep non-movable and reapable allocations at the lower PFNs as much as > possible. This is so DIMMS for higher PFNs can be removed (doesn't > exist) "as much as possible" won't suffice, I suspect. If there's any chance at all that a non-moveable page can land in a hot-unpluggable region then there will be failure scenarios. Easy-to-hit ones, I suspect. There are five situations of interest I can think of 1. Satisfying high-order allocations such as those required for e1000 2. Being able to grow the hugepage pool when the system has been running for any length of time 3. Offlining a SPARSEMEM section of memory 4. Offlining a DIMM 5. Offlining a Node anti-frag + lumpy-reclaim definitly help situation 2 in the test situations I've used. I cannot trigger situation 1 on demand but if situation 2 works at all, I imagine situation 1 does as well. Situation 3 used to be helped by anti-frag, particularly if a MAX_ORDER_NR_PAGES == NUMBER_OF_PAGES_IN_A_SECTION. I was at one point able to offline memory on an x86 although the stability left a lot to be desired. Zones are overkill here. For Situation 4, a zone may be needed because MAX_ORDER_NR_PAGES would have to be set to too high for anti-frag to be effective. However, zones would have to be tuned at boot-time and that would be an annoying restriction. If DIMMs are being offlined for power reasons, it would be sufficient to be best-effort. Situation 5 requires that a hotpluggable node only allows __GFP_MOVABLE allocations in the zonelists. This would probably involving having one zone that only allowed __GFP_MOVABLE. What is particularly important here is that using a zone would solve situation 3, 4 or 5 a reliable fashion but it does not help situations 1 and 2 at all. anti-frag+lumpy-reclaim greatly improve the situation for situations 1-3. By keeping non-movable allocations at lower PFNs, situation 4 will sometimes work but not always. In other words, to properly address all situations, we may need anti-frag and zones, not one or the other. > 2. Use page migration to compact memory rather than depending solely on > reclaim (doesn't exist) Yup. > 3. Introduce a mechanism for marking a group of pages as being offlined so > that they are not reallocated (code that does something like this > exists) yup. > 4. Resurrect the hotplug-remove code (exists, but probably very stale) I don't even remember what that looks like. I don't fully recall either. When I last got it working though 10 months or so ago, it wasn't in the best of shape. What I recall is that it worked by marking a memory section as going offline. All pages within that section were marked as under "page-capture" and once freed, never allocated again. It would then reap caches and reclaiming pages until the section could be marked fully offline. > 5. Allow allocations for hugepages outside of the pool as long as the > process remains with it's locked_vm limits (patches were posted to > libhugetlbfs last Friday. will post to linux-mm tomorrow). hm. I'm not saying that we need to do memory hot-unplug immediately. But the overlaps between this and anti-frag and lumpiness are sufficient that I do think that we need to work out how we'll implement hot-unplug, so we don't screw ourselves up later on. Ok, how about this is a rough roadmap. It is mainly concerned with how to place pages. 1. Use lumpy-reclaim to intelligently reclaim contigous pages. The same logic can be used to reclaim within a PFN range 2. Merge anti-frag to help high-order allocations, hugetlbpage allocations and freeing up SPARSEMEM sections of memory 3. Anti-frag includes support for page flags that affected a MAX_ORDER block of pages. These flags can be used to mark a section of memory that should not be allocated from. This is of interest to both hugetlb page allocatoin and memory hot-remove. Use the flags to mark a MAX_ORDER_NR_PAGES that is currently being freed up and shouldn't be allocated. 4. Use anti-frag fallback logic to bias unmovable allocations to the lower PFNs. 5. Add arch support where possible for offlining sections of memory that can be powered down. 6. Add arch support where possible to power down a DIMM when the memory sections that
Re: Why SCSI module needed for PCI-IDE ATA only disks ?
Bernard Pidoux wrote: I am asking why need to compile the following modules while I do not have any SCSI device ? libata uses SCSI to provide a lot of infrastructure that it would otherwise have to recreate. Also, using SCSI meant that it automatically worked in existing installers. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
scst support for kernels above 2.6.15
I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18 and above. Is scst and target support for FC-AL going to remain supported and/or merged at some point? If so, what is planned for scst support for later kernels? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] libata: Simulate REPORT LUNS for ATAPI devices
The Quantum GoVault SATAPI removable disk device returns ATA_ERR in
response to a REPORT LUNS packet. If this happens to an ATAPI device
that is attached to a SAS controller (this is the case with sas_ata),
the device does not load because SCSI won't touch a "SCSI device"
that won't report its LUNs. Since most ATAPI devices don't support
multiple LUNs anyway, we might as well fake a response like we do for
ATA devices.
Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]>
---
drivers/ata/libata-scsi.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 47ea111..5ecf260 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2833,8 +2833,13 @@ static inline int __ata_scsi_queuecmd(st
rc = ata_scsi_translate(dev, cmd, done, xlat_func);
else
ata_scsi_simulate(dev, cmd, done);
- } else
- rc = ata_scsi_translate(dev, cmd, done, atapi_xlat);
+ } else {
+ /* Simulate REPORT LUNS for ATAPI devices */
+ if (cmd->cmnd[0] == REPORT_LUNS)
+ ata_scsi_simulate(dev, cmd, done);
+ else
+ rc = ata_scsi_translate(dev, cmd, done, atapi_xlat);
+ }
return rc;
}
-
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] rfkill - Add support for input key to control wireless radio
Hi, > > This patch is a resend of a patch I has been send to the linux kernel > > and netdev list earlier. The most recent version of a few weeks back > > didn't compile since I missed 1 line in my patch that changed > > include/linux/input.h. > > > > This patch will offer the handling of radiokeys on a laptop. > > Such keys often control the wireless devices on the radio > > like the wifi, bluetooth and irda. > > > > The rfkill works as follows, when the user presses the hardware key > > to control the wireless (wifi, bluetooth or irda) radio a signal will > > go to rfkill. This happens by the hardware driver sending a signal > > to rfkill, or rfkill polling for the button status. > > The key signal will then be processed by rfkill, each key will have > > its own input device, if this input device has not been openened > > by the user, rfkill will keep the signal and either turn the radio > > on or off based on the key status. > > If the input device has been opened, rfkill will send the signal to > > userspace and do nothing further. The user is in charge of controlling > > the radio. > > > > This driver (if accepted and applied) will be usefull for the rt2x00 drivers > > (rt2400pci, rt2500pci, rt2500usb, rt61pci and rt73usb) in the wireless-dev > > tree and the MSI laptop driver from Lennart Poettering in the main > > linux kernel tree. > > > > Before this patch can be applied to any tree, I first wish to hear > > if the patch is acceptable. Since the previous time it was send I have made > > several fixes based on the feedback like adding the sysfs entries for > > reading the status. > > > > Hi Ivo, > > I apologize for not responding to your post earlier, it was a busy week. No problem, it didn't compile anyway. And this time I have CC'ed all people that have previously shown interest in rfkill, so they are now updated about rfkill as well. ;) > I am still not sure that tight coupling of input device with rfkill > structure is such a good idea. Quite often the button is separated > from the device itself and radio control is done via BIOS SMM (see > wistron driver) or there is no special button at all and users might > want to assign one of their standard keyboard buttons to be an RF > switch. Making sure rfkill supports keys that are not handled by the driver is a bit hard. Just as drivers that can only check if the button is toggled and not what the current state is. The problem is that it is hard to make a clean split between the 2 different button controls. Not all drivers allow the radio to be enabled while the button status are indicating the radio should be off. The buttons that are already integrated into the keyboard, by example by using a Fn key combo don't control the device directly. So the driver cannot offer anything to the rfkill driver. Such buttons should be mapped in userspace without the help of rfkill, since the kernel cannot detect if that key belonged to a radio control key or not. > I think it would be better if there was an rfkill class listing all > controlled devices (preferrably grouped by their type - WiFi, BT, > IRDA, etc) and if every group would provide an attribute allowing to > control state of the whole group (do we realistically need to kill > just one interface? Wouldn't ifconfig be suitable for that?). The There have been mixed feelings on the netdev list about what should exactly happen when the button is pressed. The possible options are: 1 - rfkill will kill all interfaces 2 - rfkill will kill all interfaces of the same type (wifi, bt, irda) 3 - rfkill will kill the interface it belongs to Personally I would favour the second option, but used the third after hearing objections to the second method. So since there are also fans of the third option I think there should be a decision made about what the correct option is, so rfkill can follow that method. > attribute should be a tri-state on/off/auto, "auto" meaning the driver > itself manages radio state. This would avoid another tacky IMHO point > that in your implementation mere opening of an input device takes over > RF driver. Explicit control allow applications "snoop" RF state > without disturbing it. Currently userspace can always check the state of the button whenever they like by checking the sysfs entry. > If there are concerns that drivers will have to re-implement most of > the button handling you are still free to create a simple > implementation of polled RF button (I don't think that interrupt > driver RF buttons would share alot of code) so that users would only > need to implement a polling function. Isn't the current interface to the driver not clean enough? It only asks for the (optional) poll method, and the enable/disable method. I believe this should not add too much code into the drivers, especially when all methods are optional. Ivo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: Intel 82559 NIC corrupted EEPROM
On 12/1/06, John <[EMAIL PROTECTED]> wrote: > can you try adding mdelay(100); in e100_eeprom_load before the for loop, > and then change the multiple udelay(4) to mdelay(1) in e100_eeprom_read I applied the attached patch. Loading the driver now takes around one minute :-) ouch, but yep, thats what happens when you use "super extra delay" I ran 'source load_unload' 25 times in a loop. The first 12 times were successful. The last 13 times failed. (cf. attached archive) I noticed something very strange. The number of words obviously in error (0x) returned by the EEPROM on 00:09.0 is not constant. That is very strange, I would think that maybe you have something else on the bus with the e100 that may be hogging bus cycles you have failing hardware (maybe a bad eeprom, or possibly a bad mac chip) $ grep -c 0x insmod* insmod_300.txt:0 insmod_301.txt:0 insmod_302.txt:0 insmod_303.txt:0 insmod_304.txt:0 insmod_305.txt:0 insmod_306.txt:0 insmod_307.txt:0 insmod_308.txt:0 insmod_309.txt:0 insmod_310.txt:0 insmod_311.txt:0 insmod_312.txt:1 insmod_313.txt:5 insmod_314.txt:24 insmod_315.txt:45 insmod_316.txt:243 insmod_317.txt:256 insmod_318.txt:256 insmod_319.txt:256 insmod_320.txt:256 insmod_321.txt:256 insmod_322.txt:256 insmod_323.txt:253 insmod_324.txt:240 this is even stranger, does it cycle back down (sine wave) to zero again? The delays did seem to work, at least sometimes. This indicates that something needs that extra delay to successfully read the eeprom. I might try changing all the udelay(4) to udelay(40) (x10 increase) and see if that gives you a happy medium of "most times driver loads without error" John, this problem seems to be very specific to your hardware. I know that you have put in a lot of time debugging this, but I'm not sure what we can do from here. If this were a generic code problem more people would be reporting the issue. What would you like to do? At this stage I would like e100 to work better than it is, but I'm not sure what to do next. Thanks for your patience on this issue, Jesse - 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] make sata_promise PATA ports work
Alan wrote: On Mon, 4 Dec 2006 12:47:37 -0700 Erik Andersen <[EMAIL PROTECTED]> wrote: This patch vs 2.6.19, based on the not-actually-working-for-me code lurking in libata-dev.git#promise-sata-pata, makes the PATA ports on my promise sata card actually work. Since the plan as Nice, this is pretty much what is needed to polish up the other split PATA/SATA cases. Disagree. Internal libata is set up so that you can have different ata_port::flags and ata_port::ops for each port, which is what enables proper hardware sharing between SATA and PATA. Two things need to happen: 1) probe_ent needs to permit a driver to supply multiple flags/ops pairs, not just one for the whole driver, and pass that through to the proper data structures during ata_port init. 2) a VERY FEW details like ->irq_clear() are really ata_host level hooks, but they live in ata_port_operations because there is no ata_host_operations. Fix these. Once those issues are fixed, PATA+SATA can be easily support on the combinations of hardware that have been desperately wanting it: sata_promise, sata_sis, sata_via (sata_uli too?) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] UML - Size register files correctly
We were using the wrong symbol to size register files.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
Index: linux-2.6.18-mm/arch/um/include/sysdep-i386/ptrace.h
===
--- linux-2.6.18-mm.orig/arch/um/include/sysdep-i386/ptrace.h 2006-11-27
18:55:15.0 -0500
+++ linux-2.6.18-mm/arch/um/include/sysdep-i386/ptrace.h2006-11-29
04:39:05.0 -0500
@@ -75,7 +75,7 @@ union uml_pt_regs {
#endif
#ifdef UML_CONFIG_MODE_SKAS
struct skas_regs {
- unsigned long regs[HOST_FRAME_SIZE];
+ unsigned long regs[MAX_REG_NR];
unsigned long fp[HOST_FP_SIZE];
unsigned long xfp[HOST_XFP_SIZE];
struct faultinfo faultinfo;
Index: linux-2.6.18-mm/arch/um/include/sysdep-x86_64/ptrace.h
===
--- linux-2.6.18-mm.orig/arch/um/include/sysdep-x86_64/ptrace.h 2006-11-27
18:55:15.0 -0500
+++ linux-2.6.18-mm/arch/um/include/sysdep-x86_64/ptrace.h 2006-11-29
04:38:13.0 -0500
@@ -108,7 +108,7 @@ union uml_pt_regs {
* file size, while i386 uses FRAME_SIZE. Therefore, we need
* to use UM_FRAME_SIZE here instead of HOST_FRAME_SIZE.
*/
- unsigned long regs[UM_FRAME_SIZE];
+ unsigned long regs[MAX_REG_NR];
unsigned long fp[HOST_FP_SIZE];
struct faultinfo faultinfo;
long syscall;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] UML - include stddef.h correctly
We were not including stddef.h in files that used offsetof. One file was also including linux/stddef.h for no perciptible reason. Signed-off-by: Jeff Dike <[EMAIL PROTECTED]> Index: linux-2.6.18-mm/arch/um/sys-i386/ldt.c === --- linux-2.6.18-mm.orig/arch/um/sys-i386/ldt.c 2006-12-04 14:25:45.0 -0500 +++ linux-2.6.18-mm/arch/um/sys-i386/ldt.c 2006-12-04 14:26:12.0 -0500 @@ -3,7 +3,6 @@ * Licensed under the GPL */ -#include "linux/stddef.h" #include "linux/sched.h" #include "linux/slab.h" #include "linux/types.h" Index: linux-2.6.18-mm/arch/um/sys-i386/ptrace_user.c === --- linux-2.6.18-mm.orig/arch/um/sys-i386/ptrace_user.c 2006-12-04 14:25:45.0 -0500 +++ linux-2.6.18-mm/arch/um/sys-i386/ptrace_user.c 2006-12-04 14:26:12.0 -0500 @@ -4,9 +4,9 @@ */ #include +#include #include #include -#include #include "ptrace_user.h" /* Grr, asm/user.h includes asm/ptrace.h, so has to follow ptrace_user.h */ #include Index: linux-2.6.18-mm/arch/um/sys-i386/user-offsets.c === --- linux-2.6.18-mm.orig/arch/um/sys-i386/user-offsets.c2006-12-04 14:25:45.0 -0500 +++ linux-2.6.18-mm/arch/um/sys-i386/user-offsets.c 2006-12-04 14:26:12.0 -0500 @@ -2,7 +2,7 @@ #include #include #include -#include +#include #include #define DEFINE(sym, val) \ - 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 patch] USB_RTL8150 must select MII
On Mon, 4 Dec 2006 21:02:06 +0100 Adrian Bunk wrote: > USB_RTL8150 must select MII to avoid link errors. > > Stolen from a patch by Randy Dunlap. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Thanks, Adrian. David B. may prefer a patch similar to the one that was merged for USB_NET_MCS7830, which does: select USB_USBNET_MII although I don't see why... > --- > > This patch was already sent on: > - 4 Nov 2006 > > --- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig > +++ linux-2619-rc3-pv/drivers/usb/net/Kconfig > @@ -84,6 +84,7 @@ config USB_PEGASUS > config USB_RTL8150 > tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)" > depends on EXPERIMENTAL > + select MII > help > Say Y here if you have RTL8150 based usb-ethernet adapter. > Send me <[EMAIL PROTECTED]> any comments you may have. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] UML - Include asm/page.h in order to get PAGE_SHIFT
Include the proper header to get a definition of PAGE_SHIFT. Signed-off-by: Jeff Dike <[EMAIL PROTECTED]> Index: linux-2.6.17/arch/um/include/sysdep-i386/stub.h === --- linux-2.6.17.orig/arch/um/include/sysdep-i386/stub.h2006-06-17 21:49:35.0 -0400 +++ linux-2.6.17/arch/um/include/sysdep-i386/stub.h 2006-11-13 16:41:37.0 -0500 @@ -9,6 +9,7 @@ #include #include #include +#include #include "stub-data.h" #include "kern_constants.h" #include "uml-config.h" - 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 4/4] UML - Use get_random_bytes after random pool is seeded
When the UML network driver generates random MACs for its devices, it was possible for a number of UMLs to get the same MACs because the ethernet initialization was done before the random pool was properly seeded. This patch moves the initialization later so that it gets better randomness. Signed-off-by: Jeff Dike <[EMAIL PROTECTED]> Index: linux-2.6.18-mm/arch/um/drivers/daemon_kern.c === --- linux-2.6.18-mm.orig/arch/um/drivers/daemon_kern.c 2006-11-24 14:29:57.0 -0500 +++ linux-2.6.18-mm/arch/um/drivers/daemon_kern.c 2006-12-04 12:08:52.0 -0500 @@ -98,4 +98,4 @@ static int register_daemon(void) return 0; } -__initcall(register_daemon); +late_initcall(register_daemon); Index: linux-2.6.18-mm/arch/um/drivers/mcast_kern.c === --- linux-2.6.18-mm.orig/arch/um/drivers/mcast_kern.c 2006-11-24 14:29:57.0 -0500 +++ linux-2.6.18-mm/arch/um/drivers/mcast_kern.c2006-12-04 12:08:52.0 -0500 @@ -127,4 +127,4 @@ static int register_mcast(void) return 0; } -__initcall(register_mcast); +late_initcall(register_mcast); Index: linux-2.6.18-mm/arch/um/drivers/pcap_kern.c === --- linux-2.6.18-mm.orig/arch/um/drivers/pcap_kern.c2006-11-24 14:29:57.0 -0500 +++ linux-2.6.18-mm/arch/um/drivers/pcap_kern.c 2006-12-04 12:08:52.0 -0500 @@ -109,4 +109,4 @@ static int register_pcap(void) return 0; } -__initcall(register_pcap); +late_initcall(register_pcap); Index: linux-2.6.18-mm/arch/um/drivers/slip_kern.c === --- linux-2.6.18-mm.orig/arch/um/drivers/slip_kern.c2006-11-27 18:55:16.0 -0500 +++ linux-2.6.18-mm/arch/um/drivers/slip_kern.c 2006-12-04 12:08:52.0 -0500 @@ -95,4 +95,4 @@ static int register_slip(void) return 0; } -__initcall(register_slip); +late_initcall(register_slip); Index: linux-2.6.18-mm/arch/um/drivers/slirp_kern.c === --- linux-2.6.18-mm.orig/arch/um/drivers/slirp_kern.c 2006-11-27 18:55:16.0 -0500 +++ linux-2.6.18-mm/arch/um/drivers/slirp_kern.c2006-12-04 12:08:52.0 -0500 @@ -119,4 +119,4 @@ static int register_slirp(void) return 0; } -__initcall(register_slirp); +late_initcall(register_slirp); Index: linux-2.6.18-mm/arch/um/os-Linux/drivers/ethertap_kern.c === --- linux-2.6.18-mm.orig/arch/um/os-Linux/drivers/ethertap_kern.c 2006-11-27 18:55:16.0 -0500 +++ linux-2.6.18-mm/arch/um/os-Linux/drivers/ethertap_kern.c2006-12-04 12:08:52.0 -0500 @@ -105,4 +105,4 @@ static int register_ethertap(void) return 0; } -__initcall(register_ethertap); +late_initcall(register_ethertap); Index: linux-2.6.18-mm/arch/um/os-Linux/drivers/tuntap_kern.c === --- linux-2.6.18-mm.orig/arch/um/os-Linux/drivers/tuntap_kern.c 2006-11-27 18:55:16.0 -0500 +++ linux-2.6.18-mm/arch/um/os-Linux/drivers/tuntap_kern.c 2006-12-04 12:08:52.0 -0500 @@ -90,4 +90,4 @@ static int register_tuntap(void) return 0; } -__initcall(register_tuntap); +late_initcall(register_tuntap); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-mm2: uli526x only works after reload
On Fri, Dec 01, 2006 at 02:08:28AM +0100, Rafael J. Wysocki wrote: > On Thursday, 30 November 2006 22:32, Rafael J. Wysocki wrote: > > [Trimmed the Cc list a bit.] > > > > On Thursday, 30 November 2006 22:12, Andrew Morton wrote: > > > On Thu, 30 Nov 2006 21:21:27 +0100 > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > > > On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote: > > > > > On Thursday, 30 November 2006 00:26, Andrew Morton wrote: > > > > > > On Thu, 30 Nov 2006 00:08:21 +0100 > > > > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote: > > > > > > > > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote: > > > > > > > > > On Wed, 29 Nov 2006 21:08:00 +0100 > > > > > > > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki > > > > > > > > > > wrote: > > > > > > > > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote: > > > > > > > > > > > > > > > > > > > > > > > > Temporarily at > > > > > > > > > > > > > > > > > > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/ > > > > > > > > > > > > > > > > > > > > > > > > Will appear eventually at > > > > > > > > > > > > > > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/ > > > > > > > > > > > > > > > > > > > > > > A minor issue: on one of my (x86-64) test boxes the > > > > > > > > > > > uli526x driver doesn't > > > > > > > > > > > work when it's first loaded. I have to rmmod and > > > > > > > > > > > modprobe it to make it work. > > > > > > > > > > > > > > > > > > That isn't a minor issue. > > > > > > > > > > > > > > > > > > > > It worked just fine on -mm1, so something must have > > > > > > > > > > > happened to it recently. > > > > > > > > > > > > > > > > > > > > Sorry, I was wrong. The driver doesn't work at all, even > > > > > > > > > > after reload. > > > > > > > > > > > > > > > > > > > > > > > > > > > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2. > > > > > > > > > But you're > > > > > > > > > not using that (corrent?) > > > > > > > > > > > > > > > > > > git-netdev-all changes drivers/net/tulip/de2104x.c, but > > > > > > > > > you're not using > > > > > > > > > that either. > > > > > > > > > > > > > > > > > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're > > > > > > > > > not using that. > > > > > > > > > > > > > > > > > > Beats me, sorry. Perhaps it's due to changes in networking > > > > > > > > > core. It's > > > > > > > > > presumably a showstopper for statically-linked-uli526x users. > > > > > > > > > If you could > > > > > > > > > bisect it, please? I'd start with git-netdev-all, then > > > > > > > > > tulip-*. > > > > > > > > > > > > > > > > OK, but it'll take some time. > > > > > > > > > > > > > > OK, done. > > > > > > > > > > > > > > It's one of these (the first one alone doesn't compile): > > > > > > > > > > > > > > git-netdev-all.patch > > > > > > > git-netdev-all-fixup.patch > > > > > > > libphy-dont-do-that.patch > > > > > > > > Hm, all of these patches are the same as in -mm1 which hasn't caused any > > > > problems to appear on this box. > > > > > > > > So, it seems there's another change between -mm1 and -mm2 that causes > > > > this > > > > to happen. > > > > > > > > > > It would be nice to eliminate libphy-dont-do-that.patch if poss - that was > > > a rogue akpm patch aimed at some incomprehensible gobbledigook in the > > > netdev tree (and to fix the current_is_keventd-not-exported-to-modules > > > bug). > > > > Unfortunately the kernel doesn't compile without it ... > > > > Well, I think I'll try to find the patch that contains the change which has > > triggered this. > > It looks like the winner is: > > gregkh-driver-driver-core-fixes-sysfs_create_link-retval-checks-in-core.c.patch > > Without this patch there are no problems, with this patch applied the problems > (with uli526x, when it's the second interface and the first one is not used) > occur, almost 100% of the time. Ok, I've now removed this from my tree. thanks, greg k-h - 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: libata: Simulate REPORT LUNS for ATAPI devices when not supported
Darrick J. Wong wrote: The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. If we see this command fail, we should simulate a response that indicates the presence of LUN 0. Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]> I think the answer to this issue lies in the behavior of the majority of ATAPI devices when responding to REPORT LUNS. Regardless of SAS or SATA or whatever bus the device is using. ISTR that REPORT LUNS can make ATAPI devices croak, so it might be wise and more safe to simply simulate REPORT LUNS by default for all ATAPI devices. Then readdress the issue if someone has a burning need to support the rare multi-LUN ATAPI devices. I have one, but I'm not highly motivated to dig it out. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 32/36] driver core: Introduce device_move(): move a device to a new parent.
On Mon, Dec 04, 2006 at 10:15:03PM +0100, Marcel Holtmann wrote: > Hi Greg, > > > > > Provide a function device_move() to move a device to a new parent > > > > device. Add > > > > auxilliary functions kobject_move() and sysfs_move_dir(). > > > > kobject_move() generates a new uevent of type KOBJ_MOVE, containing the > > > > previous path (DEVPATH_OLD) in addition to the usual values. For this, > > > > a new > > > > interface kobject_uevent_env() is created that allows to add further > > > > environmental data to the uevent at the kobject layer. > > > > > > has this one been tested? I don't get it working. I always get an EINVAL > > > when trying to move the TTY device of a Bluetooth RFCOMM link around. > > > > I relied on Cornelia to test this. I think some s390 patches depend on > > this change, right? > > my pre-condition is that the TTY device has no parent and then we move > it to a Bluetooth ACL link as child. This however is not working or the > TTY change to use device instead of class_device has broken something. Hm, I don't think the class_device stuff has broken anything, but if you think so, please let me know. > > > And shouldn't device_move(dev, NULL) re-attach it to the virtual device > > > tree instead of failing? > > > > Yes, that would be good to have. > > Cornelia, please fix this, because otherwise we can't detach a device > from its parent. Storing the current virtual parent looks racy to me. You can always restore the previous "virtual" parent from the information given to you in the device itself. That is what the code does when it first registers the device. And yes, I too think it should be fixed. thanks, greg k-h - 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/
libata: Simulate REPORT LUNS for ATAPI devices when not supported
The Quantum GoVault SATAPI removable disk device returns ATA_ERR in
response to a REPORT LUNS packet. If this happens to an ATAPI device
that is attached to a SAS controller (this is the case with sas_ata),
the device does not load because SCSI won't touch a "SCSI device"
that won't report its LUNs. If we see this command fail, we should
simulate a response that indicates the presence of LUN 0.
Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 36
drivers/ata/libata-scsi.c |4 ++--
include/linux/libata.h|2 ++
3 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 915a55a..a3d6217 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4455,6 +4455,35 @@ void ata_qc_complete(struct ata_queued_c
{
struct ata_port *ap = qc->ap;
+ /*
+* If this is an ATAPI device that fails a REPORT LUN issued by SCSI,
+* assume that LUN 0 exists and fake the return buffer as appropriate.
+* ATA devices have REPORT LUN simulated for them.
+*/
+ if (is_atapi_taskfile(>tf) &&
+ qc->scsicmd &&
+ qc->cdb[0] == REPORT_LUNS &&
+ qc->err_mask) {
+ unsigned int buflen;
+ struct scsi_cmnd *cmd = qc->scsicmd;
+ u8 *buf = NULL;
+
+ buflen = ata_scsi_rbuf_get(cmd, );
+ memset(buf, 0, buflen);
+ buf[3] = 8;
+ ata_scsi_rbuf_put(cmd, buf);
+
+ qc->err_mask = 0;
+
+ /* read result TF if requested */
+ if (qc->flags & ATA_QCFLAG_RESULT_TF)
+ ap->ops->tf_read(ap, >result_tf);
+ qc->result_tf.command &= ~ATA_ERR;
+ qc->flags &= ~ATA_QCFLAG_RESULT_TF;
+
+ goto finish_qc;
+ }
+
/* XXX: New EH and old EH use different mechanisms to
* synchronize EH with regular execution path.
*
@@ -4486,8 +4515,6 @@ void ata_qc_complete(struct ata_queued_c
/* read result TF if requested */
if (qc->flags & ATA_QCFLAG_RESULT_TF)
ap->ops->tf_read(ap, >result_tf);
-
- __ata_qc_complete(qc);
} else {
if (qc->flags & ATA_QCFLAG_EH_SCHEDULED)
return;
@@ -4495,9 +4522,10 @@ void ata_qc_complete(struct ata_queued_c
/* read result TF if failed or requested */
if (qc->err_mask || qc->flags & ATA_QCFLAG_RESULT_TF)
ap->ops->tf_read(ap, >result_tf);
-
- __ata_qc_complete(qc);
}
+
+finish_qc:
+ __ata_qc_complete(qc);
}
/**
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 47ea111..da013a7 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1639,7 +1639,7 @@ defer:
* Length of response buffer.
*/
-static unsigned int ata_scsi_rbuf_get(struct scsi_cmnd *cmd, u8 **buf_out)
+unsigned int ata_scsi_rbuf_get(struct scsi_cmnd *cmd, u8 **buf_out)
{
u8 *buf;
unsigned int buflen;
@@ -1670,7 +1670,7 @@ static unsigned int ata_scsi_rbuf_get(st
* spin_lock_irqsave(host lock)
*/
-static inline void ata_scsi_rbuf_put(struct scsi_cmnd *cmd, u8 *buf)
+void ata_scsi_rbuf_put(struct scsi_cmnd *cmd, u8 *buf)
{
if (cmd->use_sg) {
struct scatterlist *sg;
diff --git a/include/linux/libata.h b/include/linux/libata.h
index abd2deb..b37b21f 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -723,6 +723,8 @@ extern int ata_scsi_detect(struct scsi_h
extern int ata_scsi_ioctl(struct scsi_device *dev, int cmd, void __user *arg);
extern int ata_scsi_queuecmd(struct scsi_cmnd *cmd, void (*done)(struct
scsi_cmnd *));
extern int ata_scsi_release(struct Scsi_Host *host);
+unsigned int ata_scsi_rbuf_get(struct scsi_cmnd *cmd, u8 **buf_out);
+void ata_scsi_rbuf_put(struct scsi_cmnd *cmd, u8 *buf);
extern void ata_sas_port_destroy(struct ata_port *);
extern struct ata_port *ata_sas_port_alloc(struct ata_host *,
struct ata_port_info *, struct
Scsi_Host *);
-
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: /sys/bus/pci/drivers//new_id
On Wed, Nov 29, 2006 at 09:18:04PM +, Russell King wrote: > Unfortunately, the .../new_id feature does not work with the 8250_pci > driver. > > The reason for this comes down to the way .../new_id is implemented. > When PCI tries to match a driver to a device, it checks the modules > static device ID tables _before_ checking the dynamic new_id tables. > > When a driver is capable of matching by ID, and falls back to matching > by class (as 8250_pci does), this makes it absolutely impossible to > specify a board by ID, and as such the correct driver_data value to > use with it. > > Let's say you have a serial board with vendor 0x1234 and device 0x5678. > It's class is set to PCI_CLASS_COMMUNICATION_SERIAL. > > On boot, this card is matched to the 8250_pci driver, which tries to > probe it because it matched using the class entry. The driver finds > that it is unable to automatically detect the correct settings to use, > so it returns -ENODEV. > > You know that the information the driver needs is to match this card > using a device_data value of '7'. So you echo 1234 5678 0 0 0 0 7 > into new_id. > > The kernel attempts to re-bind 8250_pci to this device. However, > because it scans the PCI driver tables, it _again_ matches the class > entry which has the wrong device_data. It fails. > > End of story. You can't support the card without rebuilding the > kernel (or writing a specific PCI probe module to support it.) > > So, can we make new_id override the driver-internal PCI ID tables? > IOW, like this: Yes, you are right, I'll add this to my queue. thanks, greg k-h - 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] fully support linker generated .eh_frame_hdr section
On Mon, 04 Dec 2006 16:23:27 + Jan Beulich wrote: > Now that binutils' ld is able to properly populate .eh_frame_hdr in the > Linux kernel case, here's a patch to add some functionality to the Dwarf2 > unwinder to actually be able to make use of this (applies on firstfloor > tree with the previously sent patch to add debug output, but not on plain > 2.6.19). Requires what version of binutils / ld? Thanks, --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
