Re: [ANNOUNCE] System Inactivity Monitor v1.0
On Thu, 2007-01-18 at 20:29 +0100, Alessandro Di Marco wrote: > Hi all, > > this is a new 2.6.20 module implementing a user inactivity trigger. Basically > it acts as an event sniffer, issuing an ACPI event when no user activity is > detected for more than a certain amount of time. This event can be > successively > grabbed and managed by an user-level daemon such as acpid, blanking the > screen, > dimming the lcd-panel light à la mac, etc... Hi, why did you chose an ACPI event? I'd expect a uevent (which dbus captures etc) to be a more logical choice.. Greetings, Arjan van de Ven - 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] pci_bus conversion to struct device
On Thu, Jan 18, 2007 at 09:14:06AM +0100, Martin Mares wrote: > Hello! > > > I recommend we just delete the pci_bus class. I don't think it serves > > any useful purpose. The bridge can be inferred frmo the sysfs hierarchy > > (not to mention lspci will tell you). The cpuaffinity file should be > > moved from the bus to the device -- it really doesn't make any sense to > > talk about which cpu a bus is affine to, only a device. > > It doesn't seem to serve any useful purpose other than the affinity now, > but I still think that it conceptually belongs there, because it makes > sense to have per-bus attributes. For example, in the future we could > show data width and signalling speed. Other per bus attributes might be address routing, VGA routing enabled, Fast-back-to-back enabled. PCI-X bridges and PCI-e bridges might also advertise data related to MMRBC and similar onboard buffer mgt behaviors. ISTR, IBM PCI-X bridge works better with 512 "block" (data xfer size) than larger sizes becuase it internally allocates buffer space in 512B chunks. It would be useful to know along with downstream device MMRBC. Not sure this all has to come from /sys though. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unable to mmap /dev/kmem
Hugh Dickins wrote: On Thu, 18 Jan 2007, Nadia Derbey wrote: Trying to mmap /dev/kmem with an offset I take from /boot/System.map, I get an EIO error on a 2.6.20-rc4. This is something that used to work on older kernels. Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering whether pfn is correctly computed there: shouldn't we have something like pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) + __pa(vma->vm_pgoff << PAGE_SHIFT); instead of pfn = PFN_DOWN(virt_to_phys((void *)PAGE_OFFSET)) + vma->vm_pgoff; Or may be should I substract PAGE_OFFSET from the value I get from System.map before mmapping /dev/kmem? Sigh, you're right, 2.6.19 messed that up completely. No, you never had to subtract PAGE_OFFSET from that address in the past, and you shouldn't have to do so now. Please revert the offending patch below, and then maybe Franck can come up with a patch which preserves the original behaviour on architectures which used to work (e.g. i386), while fixing it for those architectures (which are they?) that did not. Ok, I'll do that, thanks! Regards, Nadia - 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: [take33 10/10] kevent: Kevent based AIO (aio_sendfile()/aio_sendfile_path()).
On Wed, Jan 17, 2007 at 05:39:51PM +0300, Evgeniy Polyakov wrote: > On Wed, Jan 17, 2007 at 07:21:42PM +0530, Suparna Bhattacharya ([EMAIL > PROTECTED]) wrote: > > > > Since you are implementing new APIs here, have you considered doing an > > aio_sendfilev to be able to send a header with the data ? > > It is doable, but why people do not like corking? > With Linux less than microsecond syscall overhead it is better and more > flexible solution, doesn't it? That is what I used to think as well. However ... The problem as I understand it now is not about bunching data together, but of ensuring some sort of atomicity between the header and the data, when there can be multiple outstanding aio requests on the same socket - i.e ensuring strict ordering without other data coming in between, when data to be sent is not already in cache, and in the meantime another sendfile or aio write requests comes in for the same socket. Without having to lock the socket when reading data from disk. There are alternate ways to address this, aio_sendfilev is one of the options I have heard people requesting. Regards Suparna > > I'm not saying - 'no, there will not be any *v variants', just getting > more info. > > > Regards > > Suparna > > -- > Evgeniy Polyakov -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc5 2/4] pvrusb2: Use ARRAY_SIZE macro
On Tue, 16 Jan 2007, Ahmed S. Darwish wrote: > On Tue, Jan 16, 2007 at 10:16:33AM -0800, Randy Dunlap wrote: > > On Tue, 16 Jan 2007 03:36:16 -0500 (EST) Robert P. J. Day wrote: > > > > > On Tue, 16 Jan 2007, Ahmed S. Darwish wrote: > > > > > > > Use ARRAY_SIZE macro in pvrusb2-hdw.c file > > > > > > > > Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]> > > > > > > ... snip ... > > > > > > i'm not sure it's worth submitting multiple patches to convert code > > > expressions to the ARRAY_SIZE() macro since i was going to wait for > > > the next kernel release, and do that in one fell swoop with a single > > > patch. > > > > > > but if people higher up the food chain think it's a better idea to do > > > it a little at a time, that's fine. > > > > I'm not strictly on the food chain, but these 4 patches to > > pvrusb2 should have been sent as one patch IMO. > > Here's the same patch in one file as suggested. > > A patch to use ARRAY_SIZE macro when appropriate. > > Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]> > --- Ahmed: I've pulled your patch into my driver source and will propagate it up appropriately as part of the next batch of pvrusb2 changes to come out of the v4l-dvb repository. -Mike -- | Mike Isely | PGP fingerprint Spammers Die!! | | 03 54 43 4D 75 E5 CC 92 | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8 | | - 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: problems with latest smbfs changes on 2.4.34 and security backports
Hi Dann !
On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
> On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> > @@ -505,8 +510,13 @@
> > mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
> > mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
> >
> > - mnt->flags = (oldmnt->file_mode >> 9);
> > + mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
> > + SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
> > } else {
> > + mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > + S_IROTH | S_IXOTH | S_IFREG;
> > + mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > + S_IROTH | S_IXOTH | S_IFDIR;
> > if (parse_options(mnt, raw_data))
> > goto out_bad_option;
> > }
> >
> >
> > See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
> > expected thing like this but I wonder if the initial intent was
> > exactly this.
>
> Wow - sorry about that, that's certainly a cut & paste error. But the
> end result appears to match current 2.6, which was the intent.
OK.
> > Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
> > what I say is stupid, but it's just a guess.
>
> I really don't know the correct answer to that, I was merely copying
> the 2.6 flags.
Don't waste your time on this one, it did not work.
> [Still working on getting a 2.4 smbfs test system up...]
Thanks !
Best regards,
Willy
-
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: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
Tomasz Chmielewski wrote: Al Borchers wrote: Thomas Chmielewski wrote: These all unpleasant tasks could be avoided if it was possible to have a "fallback" device. For example, consider this hypothetical command line: root=/dev/sdb1,/dev/sda1 Here is a patch to do this, though it sounds like you might have other solutions. This patch is for 2.6.18.1--thanks to Ed Falk for updating my original 2.6.11 patch. If people are interested I can update and test this on the current kernel. It was tested on 2.6.11. Yes, I'd be interested in a patch against a 2.6.19. It is way simpler to do it this way than to do it with initramfs (although not as flexible). I will look do it, but I will be out next week so it may take a while. -- Al I tried your patch against 2.6.19, with some minor changes (as it wouldn't apply), but it didn't work for me (perhaps I just screwed something). - 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 16/20] XEN-paravirt: Add the Xen virtual console driver.
Pavel Machek wrote: > You have drivers/xen... so maybe arch/i386/xen is easier to type? > arch/i386/paravirt/xen would make some sense, too, but it looks too > deep to me. I think the exact placement of these files needs a bit of work. I don't much care about xen/ vs paravirt/xen vs paravirt-xen/, but placement of headers needs a bit more thought. lhype, er, lguest and vmi are in kernel/, but I think it would be nice to put them near Xen. J - 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 17/20] XEN-paravirt: Add Xen grant table support
Pavel Machek wrote: > What is going on? Diffstat does not seem to match the diff. Sorry, forgot to update the diffstat for this one: drivers/xen/Makefile |1 drivers/xen/core/Makefile |1 drivers/xen/core/grant_table.c | 445 include/xen/grant_table.h | 107 + 4 files changed, 554 insertions(+) J - 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 CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
On Fri, 19 Jan 2007 12:19:10 +0900 (JST), Atsushi Nemoto <[EMAIL PROTECTED]>
wrote:
> OK, here is a revised patch which uses pci= option instead of config
> parameters.
Sorry, this patch would cause build failure if setup-bus.c was not
built into kernel. Revised again.
Subject: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size
might result in allocation failure for the reserving itself on some
platforms (for example typical 32bit MIPS). Make it (and
CARDBUS_IO_SIZE too) customizable by "pci=" option for such platforms.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |6 ++
drivers/pci/pci.c | 16
drivers/pci/setup-bus.c | 27 ++-
include/linux/pci.h |3 +++
4 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 25d2985..ace7a9a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1259,6 +1259,12 @@ and is between 256 and 4096 characters.
This sorting is done to get a device
order compatible with older (<= 2.4) kernels.
nobfsortDon't sort PCI devices into breadth-first order.
+ cbiosize=nn[KMG]A fixed amount of bus space is
+ reserved for CardBus bridges.
+ The default value is 256 bytes.
+ cbmemsize=nn[KMG] A fixed amount of bus space is
+ reserved for CardBus bridges.
+ The default value is 64 megabytes.
pcmv= [HW,PCMCIA] BadgePAD 4
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 206c834..dc7f40e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1159,6 +1159,16 @@ static int __devinit pci_init(void)
return 0;
}
+/*
+ * FIXME: IO should be max 256 bytes. However, since we may
+ * have a P2P bridge below a cardbus bridge, we need 4K.
+ */
+#define DEFAULT_CARDBUS_IO_SIZE(256)
+#define DEFAULT_CARDBUS_MEM_SIZE (64*1024*1024)
+/* pci=cbmemsize=nnM,cbiosize=nn can override this */
+unsigned long pci_cardbus_io_size = DEFAULT_CARDBUS_IO_SIZE;
+unsigned long pci_cardbus_mem_size = DEFAULT_CARDBUS_MEM_SIZE;
+
static int __devinit pci_setup(char *str)
{
while (str) {
@@ -1168,6 +1178,12 @@ static int __devinit pci_setup(char *str
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
+ } else if (!strncmp(str, "cbiosize=", 9)) {
+ pci_cardbus_io_size =
+ memparse(str + 9, &str);
+ } else if (!strncmp(str, "cbmemsize=", 10)) {
+ pci_cardbus_mem_size =
+ memparse(str + 10, &str);
} else {
printk(KERN_ERR "PCI: Unknown option `%s'\n",
str);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 89f3036..3554f39 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -36,13 +36,6 @@ #endif
#define ROUND_UP(x, a) (((x) + (a) - 1) & ~((a) - 1))
-/*
- * FIXME: IO should be max 256 bytes. However, since we may
- * have a P2P bridge below a cardbus bridge, we need 4K.
- */
-#define CARDBUS_IO_SIZE(256)
-#define CARDBUS_MEM_SIZE (64*1024*1024)
-
static void __devinit
pbus_assign_resources_sorted(struct pci_bus *bus)
{
@@ -415,12 +408,12 @@ pci_bus_size_cardbus(struct pci_bus *bus
* Reserve some resources for CardBus. We reserve
* a fixed amount of bus space for CardBus bridges.
*/
- b_res[0].start = CARDBUS_IO_SIZE;
- b_res[0].end = b_res[0].start + CARDBUS_IO_SIZE - 1;
+ b_res[0].start = pci_cardbus_io_size;
+ b_res[0].end = b_res[0].start + pci_cardbus_io_size - 1;
b_res[0].flags |= IORESOURCE_IO;
- b_res[1].start = CARDBUS_IO_SIZE;
- b_res[1].end = b_res[1].start + CARDBUS_IO_SIZE - 1;
+ b_res[1].start = pci_cardbus_io_size;
+ b_res[1].end = b_res[1].start + pci_cardbus_io_size - 1;
b_res[1].flags |= IORESOURCE_IO;
/*
@@ -440,16 +433,16 @@ pci_bus_size_cardbus(struct pci_bus *bus
* twice the size.
*/
if (ctrl & PCI_CB_BRIDGE_CTL_PREFETCH_MEM0) {
- b_res[2].start = CARDBUS_MEM_SIZE;
- b_res[2].end = b_res[2].start + CARDBUS_MEM_SIZE - 1;
+ b_res[2].start = pci_cardbus_mem_size;
+ b_res[2].end = b
Re: PATCH: Update disable_IO_APIC to use 8-bit destination field (X86_64)
On Thu, Jan 18, 2007 at 02:13:39PM -0500, Benjamin Romer wrote: [..] > > > > > > OK, here's the updated patch that uses the new definition and fixes up > > > the other places that use it. I built and tested this on the ES7000/ONE > > > and it works well. :) > > > > Cool. > > > > I hate to pick nits by why the double underscore on dest? > > > > It was defined that way in the updated structure definition you sent in > a previous mail, so I figured you wanted it that way. Here's another > revision with the double underscores removed. :) > > -- Ben > This patch looks good to me. You might want to provide some description too for changelog. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 mounted as ext2 but journal still in effect.
Thank you all for all your input. The tune2fs option was eventually used and we run into other problems. I think Andries was right in that the initrd was interfering, that's where we run into issues after the tune2fs. I was trying to avoid the tune2fs as it involves booting into a live CD and brings the system down to where I can't access it over the network (it is a 4 hour drive). At the end we had to replace the drive and recreate all file systems. If it ever happens again I will pay closer attention to the initrd commands to see if the rootfstype=ext2 was overridden with what's there. Thanks, Alberto On Thu, 2007-01-18 at 23:05 +0100, Andries Brouwer wrote: > >> You were right, even after making the changes, it seems to be > >> telling lies: > >> > >> # mount > >> /dev/hda2 on / type ext2 (rw,usrquota) > > Roughly speaking: > /etc/mtab shows you what you said to mount. > /proc/mounts shows what the current kernel state is. > These may differ greatly. > > For all filesystems mounted by you using mount(8), a line is added > to /etc/mtab, where the contents of that line is related to the > given mount command, but not to what the kernel did. > > For the root filesystem, mount(8) writes an initial line in /etc/mtab > taken from /etc/fstab. Again the information is from you, not from the kernel. > > >> # dmesg | grep 'Kernel command' > >> Kernel command line: ro root=/dev/hda2 rootfstype=ext2 > > ... > >> /dev/root / ext3 rw 0 0 > > It would be a bad bug if the kernel mounted its root filesystem > with a type different from the type given in "rootfstype=". > But I see you use an initrd, and there can be all kinds of commands there. -- Alberto AlonsoGlobal Gate Systems LLC. (512) 351-7233http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups - 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: [Cbe-oss-dev] [PATCH] Cell SPU task notification
On Wed, Jan 17, 2007 at 09:56:12AM -0600, Maynard Johnson wrote: > I haven't seen that the scheduler patch series got applied yet. This > Cell spu task notification patch is a pre-req for OProfile development > to support profiling SPUs. When the scheduler patch gets applied to a > kernel version that fits our needs for our OProfile development, I don't > see any problem in using the sched_flags field instead of notify_active. I'll hopefull commit these patches this weekend, I'm at a conference currently so not really able to do a lot of work. If you need to make more progress until than just apply the hunk that introduces sched_flags before doing your patch. > Yes, the yield() and the memory barriers were leftovers from an earlier > ill-conceived attempt at solving this problem. They should have been > removed. They're gone now. Ok. > I hesitated doing this since it would entail changing spu_switch_notify > from being static to non-static. I'd like to get Arnd's opinion on this > question before going ahead and making such a change. There is no difference in impact between marking a function non-static and adding a trivial wrapper around it, only that the latter creates more bloat. So I don't think there's a good argument against 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/
Re: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
On Thu, 18 Jan 2007 13:53:26 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Patch looks technically ok to me, so feel free to add my Acked-by: line.
> >
> > The grief I have with this sort of patch is that this kind of detailed
> > technical knowledge should not be required by a mortal configuring the
> > Linux kernel.
> >
>
> Yes, it does rater suck. A boot option/module parameter would be better.
OK, here is a revised patch which uses pci= option instead of config
parameters.
Subject: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size
might result in allocation failure for the reserving itself on some
platforms (for example typical 32bit MIPS). Make it (and
CARDBUS_IO_SIZE too) customizable by "pci=" option for such platforms.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |6 ++
drivers/pci/pci.c |6 ++
drivers/pci/setup-bus.c | 27 +++
include/linux/pci.h |3 +++
4 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 25d2985..ace7a9a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1259,6 +1259,12 @@ and is between 256 and 4096 characters.
This sorting is done to get a device
order compatible with older (<= 2.4) kernels.
nobfsortDon't sort PCI devices into breadth-first order.
+ cbiosize=nn[KMG]A fixed amount of bus space is
+ reserved for CardBus bridges.
+ The default value is 256 bytes.
+ cbmemsize=nn[KMG] A fixed amount of bus space is
+ reserved for CardBus bridges.
+ The default value is 64 megabytes.
pcmv= [HW,PCMCIA] BadgePAD 4
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 206c834..639069a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1168,6 +1168,12 @@ static int __devinit pci_setup(char *str
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
+ } else if (!strncmp(str, "cbiosize=", 9)) {
+ pci_cardbus_io_size =
+ memparse(str + 9, &str);
+ } else if (!strncmp(str, "cbmemsize=", 10)) {
+ pci_cardbus_mem_size =
+ memparse(str + 10, &str);
} else {
printk(KERN_ERR "PCI: Unknown option `%s'\n",
str);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 89f3036..1dfc288 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -40,8 +40,11 @@ #define ROUND_UP(x, a) (((x) + (a) - 1)
* FIXME: IO should be max 256 bytes. However, since we may
* have a P2P bridge below a cardbus bridge, we need 4K.
*/
-#define CARDBUS_IO_SIZE(256)
-#define CARDBUS_MEM_SIZE (64*1024*1024)
+#define DEFAULT_CARDBUS_IO_SIZE(256)
+#define DEFAULT_CARDBUS_MEM_SIZE (64*1024*1024)
+/* pci=cbmemsize=nnM,cbiosize=nn can override this */
+unsigned long pci_cardbus_io_size = DEFAULT_CARDBUS_IO_SIZE;
+unsigned long pci_cardbus_mem_size = DEFAULT_CARDBUS_MEM_SIZE;
static void __devinit
pbus_assign_resources_sorted(struct pci_bus *bus)
@@ -415,12 +418,12 @@ pci_bus_size_cardbus(struct pci_bus *bus
* Reserve some resources for CardBus. We reserve
* a fixed amount of bus space for CardBus bridges.
*/
- b_res[0].start = CARDBUS_IO_SIZE;
- b_res[0].end = b_res[0].start + CARDBUS_IO_SIZE - 1;
+ b_res[0].start = pci_cardbus_io_size;
+ b_res[0].end = b_res[0].start + pci_cardbus_io_size - 1;
b_res[0].flags |= IORESOURCE_IO;
- b_res[1].start = CARDBUS_IO_SIZE;
- b_res[1].end = b_res[1].start + CARDBUS_IO_SIZE - 1;
+ b_res[1].start = pci_cardbus_io_size;
+ b_res[1].end = b_res[1].start + pci_cardbus_io_size - 1;
b_res[1].flags |= IORESOURCE_IO;
/*
@@ -440,16 +443,16 @@ pci_bus_size_cardbus(struct pci_bus *bus
* twice the size.
*/
if (ctrl & PCI_CB_BRIDGE_CTL_PREFETCH_MEM0) {
- b_res[2].start = CARDBUS_MEM_SIZE;
- b_res[2].end = b_res[2].start + CARDBUS_MEM_SIZE - 1;
+ b_res[2].start = pci_cardbus_mem_size;
+ b_res[2].end = b_res[2].start + pci_cardbus_mem_size - 1;
b_res[2].flags |= IORESOURCE_MEM | IORES
[RFC, PATCH] workqueue: rework threads/hotplug management
(to apply this patch,
handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
should be dropped, it is not needed any longer).
With this patch workqueue_mutex is used only to protect workqueues list,
all workqueue operations can run in parallel with cpuhotplug callback path.
take_over_work(), migrate_sequence, CPU_LOCK_ACQUIRE/RELEASE go away.
CPU_DEAD just sets cwq->should_stop and returns. After that cwq->thread runs
unbound until it flushes cwq->worklist, then exits. So this patch slightly
increases the probability that work_struct will be processed by the "wrong"
CPU, but we can't avoid this with CONFIG_HOTPLUG_CPU anyway.
CPU_UP_PREPARE creates the new cwq->thread if it's not NULL, CPU_ONLINE binds
it to the new cpu.
This all greatly simplifies the workqueues/cpu-hotplug interaction and imho
makes the code better. Shrinks both the source and compiled code (430 bytes).
In particular, we can take workqueue_mutex in work->func() or create/destroy
workqueues from the cpuhotplug callback path.
The ugly part of this patch is that it adds "static int embryonic_cpu", it's
used by __create_workqueue() when it runs between CPU_UP_PREPARE/CPU_ONLINE.
cpu_populated_map was introduced to optimize for_each_possible_cpu(), it is
not strictly needed, and it is more a documentation in fact.
Further possible changes:
- don't use kthread_create(), we don't use kthread_stop()
- don't do kthread_bind() when create_workqueue_thread()
is called by CPU_UP_PREPARE, this is noop because of the
wake_up_process() below.
- make cpu_populated_map per workqueue_struct, this allows
us to remove some "is_single_threaded(wq)" checks, and we
can clear the bit when cwq->thread exits.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- WQ/kernel/workqueue.c~1_rework 2007-01-19 05:01:53.0 +0300
+++ WQ/kernel/workqueue.c 2007-01-19 05:04:13.0 +0300
@@ -43,10 +43,11 @@ struct cpu_workqueue_struct {
struct list_head worklist;
wait_queue_head_t more_work;
+ struct work_struct *current_work;
struct workqueue_struct *wq;
struct task_struct *thread;
- struct work_struct *current_work;
+ int should_stop;
int run_depth; /* Detect run_workqueue() recursion depth */
} cacheline_aligned;
@@ -64,11 +65,10 @@ struct workqueue_struct {
/* All the per-cpu workqueues on the system, for hotplug cpu to add/remove
threads to each one as cpus come/go. */
-static long migrate_sequence __read_mostly;
static DEFINE_MUTEX(workqueue_mutex);
static LIST_HEAD(workqueues);
-static int singlethread_cpu;
+static int singlethread_cpu __read_mostly;
/* If it's single threaded, it isn't in the list of workqueues. */
static inline int is_single_threaded(struct workqueue_struct *wq)
@@ -343,10 +343,28 @@ static void run_workqueue(struct cpu_wor
spin_unlock_irqrestore(&cwq->lock, flags);
}
+/*
+ * NOTE: the caller must not touch *cwq if this func returns true
+ */
+static inline int cwq_should_stop(struct cpu_workqueue_struct *cwq)
+{
+ int should_stop = cwq->should_stop;
+
+ if (unlikely(should_stop)) {
+ spin_lock_irq(&cwq->lock);
+ should_stop = cwq->should_stop && list_empty(&cwq->worklist);
+ if (should_stop)
+ cwq->thread = NULL;
+ spin_unlock_irq(&cwq->lock);
+ }
+
+ return should_stop;
+}
+
static int worker_thread(void *__cwq)
{
struct cpu_workqueue_struct *cwq = __cwq;
- DECLARE_WAITQUEUE(wait, current);
+ DEFINE_WAIT(wait);
struct k_sigaction sa;
sigset_t blocked;
@@ -372,23 +390,21 @@ static int worker_thread(void *__cwq)
siginitset(&sa.sa.sa_mask, sigmask(SIGCHLD));
do_sigaction(SIGCHLD, &sa, (struct k_sigaction *)0);
- set_current_state(TASK_INTERRUPTIBLE);
- while (!kthread_should_stop()) {
- if (cwq->wq->freezeable)
- try_to_freeze();
-
- add_wait_queue(&cwq->more_work, &wait);
- if (list_empty(&cwq->worklist))
- schedule();
- else
- __set_current_state(TASK_RUNNING);
- remove_wait_queue(&cwq->more_work, &wait);
-
- if (!list_empty(&cwq->worklist))
- run_workqueue(cwq);
- set_current_state(TASK_INTERRUPTIBLE);
- }
- __set_current_state(TASK_RUNNING);
+ for (;;) {
+ if (cwq->wq->freezeable)
+ try_to_freeze();
+
+ prepare_to_wait(&cwq->more_work, &wait, TASK_INTERRUPTIBLE);
+ if (!cwq->should_stop && list_empty(&cwq->worklist))
+ schedule();
+ finish_wait(&cwq->more_work, &wait);
+
+ if (cwq_should_stop(cwq))
+ break;
+
+
Re: [RFC: 2.6 patch] remove the broken OAKNET driver
Adrian Bunk wrote: The OAKNET driver: - has been marked as BROKEN for more than two years and - is still marked as BROKEN. Drivers that had been marked as BROKEN for such a long time seem to be unlikely to be revived in the forseeable future. But if anyone wants to ever revive this driver, the code is still present in the older kernel releases. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/10] cxgb3 - main header files
Divy Le Ray wrote: Jeff Garzik wrote: Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> This patch implements the main header files of the Chelsio T3 network driver. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> Once you think it's ready, email me a URL to a single patch that adds the driver to the latest linux-2.6.git kernel. Include in the email a description of the driver and signed-off-by line, which will get directly included in the git changelog. Adding new drivers is a bit special, because we want to merge it as a single changeset, but that would create a patch too large to review on the common kernel mailing lists. Jeff, You can grab the monolithic patch at this URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 applied to netdev-2.6.git#upstream I'm really counting on Chelsio to actively maintain this driver, unlike the abandonware you guys first submitted. 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: [2.6 patch] make hdlc_setup() static again
Adrian Bunk wrote: hdlc_setup was exported, but this export was never used. If a driver using it actually shows up it can still be exported again. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Krzysztof Halasa <[EMAIL PROTECTED]> applied - 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 4/4] atl1: Ancillary C files for Attansic L1 driver
Jay Cliburn wrote:
+static u32 atl1_get_tx_csum(struct net_device *netdev)
+{
+ return (netdev->features & NETIF_F_HW_CSUM) != 0;
+}
+
+static int atl1_set_tx_csum(struct net_device *netdev, u32 data)
+{
+ if (data)
+ netdev->features |= NETIF_F_HW_CSUM;
+ else
+ netdev->features &= ~NETIF_F_HW_CSUM;
+
+ return 0;
+}
+
+static int atl1_set_tso(struct net_device *netdev, u32 data)
+{
+ if (data)
+ netdev->features |= NETIF_F_TSO;
+ else
+ netdev->features &= ~NETIF_F_TSO;
+ return 0;
+}
There should be generic functions covering this.
+static u32 ether_crc_le(int length, unsigned char *data)
+{
+ u32 crc = ~0; /* Initial value. */
+ while (--length >= 0) {
+ unsigned char current_octet = *data++;
+ int bit;
+ for (bit = 8; --bit >= 0; current_octet >>= 1) {
+ if ((crc ^ current_octet) & 1) {
+ crc >>= 1;
+ crc ^= 0xedb88320;
+ } else
+ crc >>= 1;
+ }
+ }
+ return ~crc;
+}
this duplicates a library function
+/**
+ * Reset the transmit and receive units; mask and clear all interrupts.
+ * hw - Struct containing variables accessed by shared code
+ * return : ATL1_SUCCESS or idle status (if error)
+ **/
+s32 atl1_reset_hw(struct atl1_hw * hw)
+{
+ u32 icr;
+ u16 pci_cfg_cmd_word;
+ int i;
+
+ /* Workaround for PCI problem when BIOS sets MMRBC incorrectly. */
+ atl1_read_pci_cfg(hw, PCI_REG_COMMAND, &pci_cfg_cmd_word);
+ if ((pci_cfg_cmd_word &
+(CMD_IO_SPACE | CMD_MEMORY_SPACE | CMD_BUS_MASTER))
+ != (CMD_IO_SPACE | CMD_MEMORY_SPACE | CMD_BUS_MASTER)) {
+ pci_cfg_cmd_word |=
+ (CMD_IO_SPACE | CMD_MEMORY_SPACE | CMD_BUS_MASTER);
+ atl1_write_pci_cfg(hw, PCI_REG_COMMAND, &pci_cfg_cmd_word);
+ }
This duplicates bits set by pci_enable_device() and pci_set_master()
+ /**
+ * Clear Interrupt mask to stop board from generating
+ * interrupts & Clear any pending interrupt events
+ **/
+ /**
+* atl1_write32(hw, REG_IMR, 0);
+* atl1_write32(hw, REG_ISR, 0x);
+**/
+
+ /**
+* Issue Soft Reset to the MAC. This will reset the chip's
+* transmit, receive, DMA. It will not effect
+* the current PCI configuration. The global reset bit is self-
+* clearing, and should clear within a microsecond.
+**/
+ /*atl1_write32(hw, REG_MASTER_CTRL, MASTER_CTRL_SOFT_RST);*/
+ atl1_write32(hw, REG_MASTER_CTRL, MASTER_CTRL_SOFT_RST);
+ wmb();
PCI posting (need to read a register before delaying to guarantee flush;
probably makes wmb superfluous)
+ atl1_write16(hw, REG_GPHY_ENABLE, 1);
+
+ msec_delay(1); /* delay about 1ms */
ditto
+ /* Wait at least 10ms for All module to be Idle */
+ for (i = 0; i < 10; i++) {
+ icr = atl1_read32(hw, REG_IDLE_STATUS);
+ if (!icr)
+ break;
+ msec_delay(1); /* delay 1 ms */
+ cpu_relax();/* FIXME: is this still the right way to do
this? */
+ }
+
+ if (icr)
+ return icr;
+
+ return ATL1_SUCCESS;
+}
+
+static inline bool atl1_eth_address_valid(u8 * p_addr)
+{
+ /* Invalid PermanentAddress ? */
+ if (((p_addr[0] == 0) &&
+(p_addr[1] == 0) &&
+(p_addr[2] == 0) &&
+(p_addr[3] == 0) && (p_addr[4] == 0) && (p_addr[5] == 0)
+ ) || (p_addr[0] & 1))
+ /* Multicast address or Broadcast Address */
+ return false;
+
+ return true;
look at is_valid_ether_addr() lib function
+ if (atl1_get_permanent_address(hw)) {
+ hw->perm_mac_addr[0] = 0x00;
+ hw->perm_mac_addr[1] = 0x13;
+ hw->perm_mac_addr[2] = 0x74;
+ hw->perm_mac_addr[3] = 0x00;
+ hw->perm_mac_addr[4] = 0x5c;
+ hw->perm_mac_addr[5] = 0x38;
+ }
standard technique is to use random bytes, not a fixed address like
this, when MAC address is otherwise unavailable. consider what happens
when two MACs are present.
+ for (i = 0; i < NODE_ADDRESS_SIZE; i++)
+ hw->mac_addr[i] = hw->perm_mac_addr[i];
+ return ATL1_SUCCESS;
+}
+
+/**
+ * Hashes an address to determine its location in the multicast table
+ * hw - Struct containing variables accessed by shared code
+ * mc_addr - the multicast address to hash
+ *
+ * atl1_hash_mc_addr
+ * purpose
+ * set hash value for a multicast address
+ * hash calcu processing :
+ * 1. calcu 32bit CRC for multicast address
+ * 2. reverse crc with MSB to LSB
+ **/
+u32 atl1_hash_mc_addr(struct atl1_hw *
Re: [BUG] 2.6.20-rc4-mm1: Panic in e1000_write_vfta_82543()
Sukadev Bhattiprolu wrote: I get following panic on 2.6.20-rc4-mm1 on a 2-cpu AMD Opteron system. Same basic config file seems to work with 2.6.20-rc2-mm1 on this same system. Have not tried -rc3-mm1 yet. Attached are config file and "lspci -vv" output. Let me know if you need more info. Suka --- [ 168.925840] Freeing unused kernel memory: 320k freed * INIT: version 2.86 booting * Starting basic networking... [ ok ] * Starting kernel event manager... [ ok ] * Loading hardware drivers... [ ok ] * Starting PCMCIA services... * PCMCIA not present * Loading manual drivers... [ ok ] [ 171.575122] Unable to handle kernel paging request at c20100ec55fc RIP: [ 171.584632] [] e1000_write_vfta_82543+0x58/0xd0 [ 171.614833] PGD 114e067 PUD 0 [ 171.633943] Oops: [1] PREEMPT SMP [ 171.654614] last sysfs file: /devices/pci:00/:00:06.0/:01:06.0/host0/target0:0:0/0:0:0:0/rev [ 171.698158] CPU 1 [ 171.698161] Modules linked in: [ 171.698164] Pid: 2173, comm: ifconfig Not tainted 2.6.20-rc4-mm1 #1 * Checking root[ 171.698166] RIP: 0010:[] [] e1000_write_vfta_82543+0x58/0xd0 file system...[ 171.698171] RSP: 0018:81007dfc5cf8 EFLAGS: 00010286 [ 171.698174] RAX: c20100ec55fc RBX: 81003e4c8948 RCX: /dev/shm/root: clean, 662056/2443200 files, 3121107/4883752 bloc[ 171.698176] RDX: RSI: RDI: 81003e4c8948 ks [ ok ] [ 171.698178] RBP: R08: 0010 R09: [ 171.698181] R10: 0002 R11: 804a9800 R12: c2ec [ 171.698183] R13: fffc R14: R15: 81003e4c8000 * Setting up LVM Volume Groups...[ 171.698186] FS: 2ab17ce3f6d0() GS:81007f0b0bc0() knlGS: [ 171.698188] CS: 0010 DS: ES: CR0: 8005003b [ 171.698191] CR2: c20100ec55fc CR3: 7d828000 CR4: 06e0 [ 171.698194] Process ifconfig (pid: 2173, threadinfo 81007dfc4000, task 81007dd957e0) [ 171.698196] Stack: 8000 81003e4c8680 c2ec 81003e4c8000 [ 171.698202] 7fff2dfba960 804c103d 81003e4c8680 [ 171.698205] 81003e4c8680 804c3195 [ 171.698208] Call Trace: [ 171.698216] [] e1000_vlan_rx_register+0x1dd/0x210 [ 171.698219] [] e1000_up+0x35/0x4b0 [ 171.698222] [] e1000_open+0x74/0x100 [ 171.698227] [] dev_open+0x3e/0xa0 [ 171.698230] [] dev_change_flags+0x6f/0x160 [ 171.698234] [] devinet_ioctl+0x2d4/0x6e0 [ 171.698238] [] __up_read+0x21/0xb0 [ 171.698243] [] sock_ioctl+0x1fc/0x230 [ 171.698247] [] do_ioctl+0x2f/0xa0 [ 171.698249] [] vfs_ioctl+0x2bb/0x2f0 [ 171.698252] [] sys_ioctl+0x49/0x80 [ 171.698256] [] error_exit+0x0/0x84 [ 171.698259] [] system_call+0x7e/0x83 [ 171.698261] [ 171.698262] [ 171.698262] Code: 44 8b 20 e8 30 7e 00 00 83 bb 94 01 00 00 03 75 3c 83 e5 01 [ 171.698268] RIP [] e1000_write_vfta_82543+0x58/0xd0 [ 171.698273] RSP [ 171.698274] CR2: c20100ec55fc [ 171.698276] <6>EXT3 FS on sda1, internal journal Hi, I believe this is one of the bugs that is fixed in the patch that I sent monday. Please try again with the patch applied to your tree and re-test. Thanks. I didn't see Andrew merge the patch yet. see: http://lkml.org/lkml/2007/1/16/226 I can mail the patch if you can't find it. Just ping me privately. Cheers, Auke - 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: Questions on PCI express AER support in HBA driver
On Thu, 2007-01-18 at 12:46 -0800, Allexio Ju wrote:
> > What are the expected changes on SCSI LLD driver in regards to PCIE
> > AER supporting? I understood that the driver need to call following
> > APIs during probing to enable AER support for the device,
> > ---
> > if (pci_find_aer_capability(dev)) {
> >pci_enable_pcie_error_reporting(dev);
> > }
This is just to enable the error reporting of the device. One of the important
parts of AER is error recovery.
When an AER error happens, device will send an error message to root port. Then,
root port will notify kernel by interrupt. Kernel will print out error message,
and do error recovery to recover the related devices. Such recovery need device
drivers to provide a couple of callbacks. Documentation/pci-error-recovery.txt
has the detailed callback definitions and the recovery steps.
> > ---
> > What else does SCSI LLD driver need to changed?
Usually, 3 callbacks are enough while error_detected is must.
int (*error_detected)(struct pci_dev *dev, enum pci_channel_state);
int (*slot_reset)(struct pci_dev *dev);
void (*resume)(struct pci_dev *dev);
You could refer to the patches of e1000 drivers written by Linas, or just read
the source codes of the 3 callbacks of e1000 drivers in the latest kernel.
Yanmin
-
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] 2.6.20-rc4-mm1: Panic in e1000_write_vfta_82543()
Auke Kok [EMAIL PROTECTED] wrote: | Sukadev Bhattiprolu wrote: | >I get following panic on 2.6.20-rc4-mm1 on a 2-cpu AMD Opteron system. | > | >Same basic config file seems to work with 2.6.20-rc2-mm1 on this same | >system. Have not tried -rc3-mm1 yet. | > | >Attached are config file and "lspci -vv" output. Let me know if you need | >more info. | > | >Suka | > | >--- | > | >[ 168.925840] Freeing unused kernel memory: 320k freed | > * INIT: version 2.86 booting | > * Starting basic networking... [ | > ok ] | > * Starting kernel event manager... [ | > ok ] | > * Loading hardware drivers... [ | > ok ] | > * Starting PCMCIA services... * PCMCIA not present | > * Loading manual drivers... [ | > ok ] | >[ 171.575122] Unable to handle kernel paging request at c20100ec55fc | >RIP: | >[ 171.584632] [] e1000_write_vfta_82543+0x58/0xd0 ... | >[ 171.698208] Call Trace: | >[ 171.698216] [] e1000_vlan_rx_register+0x1dd/0x210 | >[ 171.698219] [] e1000_up+0x35/0x4b0 | >[ 171.698222] [] e1000_open+0x74/0x100 | >[ 171.698227] [] dev_open+0x3e/0xa0 | >[ 171.698230] [] dev_change_flags+0x6f/0x160 | >[ 171.698234] [] devinet_ioctl+0x2d4/0x6e0 | >[ 171.698238] [] __up_read+0x21/0xb0 | >[ 171.698243] [] sock_ioctl+0x1fc/0x230 | >[ 171.698247] [] do_ioctl+0x2f/0xa0 | >[ 171.698249] [] vfs_ioctl+0x2bb/0x2f0 | >[ 171.698252] [] sys_ioctl+0x49/0x80 | >[ 171.698256] [] error_exit+0x0/0x84 | >[ 171.698259] [] system_call+0x7e/0x83 | >[ 171.698261] | >[ 171.698262] | >[ 171.698262] Code: 44 8b 20 e8 30 7e 00 00 83 bb 94 01 00 00 03 75 3c 83 | >e5 01 | >[ 171.698268] RIP [] e1000_write_vfta_82543+0x58/0xd0 | >[ 171.698273] RSP | >[ 171.698274] CR2: c20100ec55fc | >[ 171.698276] <6>EXT3 FS on sda1, internal journal | | Hi, | | I believe this is one of the bugs that is fixed in the patch that I sent | monday. Please | try again with the patch applied to your tree and re-test. Thanks. I didn't | see Andrew | merge the patch yet. | | see: http://lkml.org/lkml/2007/1/16/226 | | I can mail the patch if you can't find it. Just ping me privately. Yep. Seems to fix the crash. Thanks ! Suka | | Cheers, | | Auke - 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/
Do SIG_DFL handlers have SA_RESTART?
Do the default signal handlers for Linux behave as if they were installed with SA_RESTART, or not? (I tried querying 'em with sigaction but the defaults all have sa_flags 0.) I remember years ago hitting a bug where ctrl-z followed by fg would cause pipelined processes to drop data, and would like to avoid that without having to wrap every darn syscall and check for -EINTR. I _think_ that I just have to feed SA_RESTART to the signals I register handlers for myself, but I'd like to confirm that. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery - 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/
mmc: correct semantics of the mmc_host_remove
Greetings. It appears to me that under certain circumstances mmc layer will issue requests to the host after mmc_host_remove returns. This happens, for example, in tifm_sd driver because mmc_host may be removed mid-transfer, as the socket shall be freed for possible reuse by different media type. Currently, the only solution is to sleep a little somewhere after mmc_remove_host but before mmc_free_host. I think the correct way to handle the situation is to ensure that mmc_host is never accessed by the mmc layer after mmc_remove_host returns. I think a easy way to handle this is to modify __mmc_claim_host to fail if the mmc_host is marked for removal (this implies that its return value should be checked on use, which is not currently the case everywhere). This way, mmc_host_remove can claim host, mark it as "dead" and then return safely knowing that nobody will send any more requests to the host. Some questions: 1. Will this suffice for the task? 2. Are there any reasons not to do this? 3. Is it possible to replace the fancy locking loop in the __mmc_claim_host with mutex based locking (mutex does the same thing, isn't it)? Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc5: known regressions with patches (v2)
On Thu, 2007-01-18 at 20:59 +0100, Adrian Bunk wrote: > Subject: CONFIG_JFFS2_FS_DEBUG=2 compile error > References : http://lkml.org/lkml/2007/1/12/161 > Submitter : Russell King <[EMAIL PROTECTED]> > Caused-By : Al Viro <[EMAIL PROTECTED]> > commit 914e26379decf1fd984b22e51fd2e4209b7a7f1b > Handled-By : David Woodhouse <[EMAIL PROTECTED]> > Status : patch available Linus, please pull from git://git.infradead.org/mtd-2.6.git This fixes the above bug along with a few others. It does also contain a small amount of new code which has been waiting for a while (including the driver for the CAFÉ NAND controller which we use on OLPC.). My apologies for missing the merge window and first asking you to pull this a few hours after 2.6.20-rc1 was cut; I'd been waiting for the bitrev stuff to land, and had waited too long. Adrian Bunk (3): [MTD] SSFDC must depend on BLOCK [MTD] [NAND] rtc_from4.c: use lib/bitrev.c [MTD] make drivers/mtd/cmdlinepart.c:mtdpart_setup() static Adrian Hunter (2): [MTD] OneNAND: Implement read-while-load [MTD] OneNAND: Handle DDP chip boundary during read-while-load Akinobu Mita (1): [JFFS2] Use rb_first() and rb_last() cleanup Alan Cox (1): [MTD] MAPS: esb2rom: use hotplug safe interfaces Alexey Dobriyan (1): [MTD] JEDEC probe: fix comment typo (devic) Amit Choudhary (1): [JFFS2] Fix error-path leak in summary scan Andrew Morton (1): [MTD] Tidy bitrev usage in rtc_from4.c Andrew Victor (2): [MTD] NAND: AT91 NAND driver [MTD] NAND: Support for 16-bit bus-width on AT91. Artem Bityutskiy (10): [MTD] core: trivial comments fix [MTD] NAND: nandsim: support subpage write [MTD] increase MAX_MTD_DEVICES [MTD] add get_mtd_device_nm() function [MTD] add get and put methods [MTD] return error code from get_mtd_device() [MTD] nandsim: bugfix in page addressing [JFFS2] add cond_resched() when garbage collecting deletion dirent [JFFS2] Reschedule in loops [MTD] OneNAND: release CPU in cycles Burman Yan (1): [MTD] replace kmalloc+memset with kzalloc Dave Olsen (1): [MTD] [MAPS] Support for BIOS flash chips on the nvidia ck804 southbridge David Anders (1): [MTD] NOR: leave Intel chips in read-array mode on suspend David Woodhouse (29): [MTD NAND] Initial import of CAFÉ NAND driver. [MTD NAND] OLPC CAFÉ driver update Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 [MTD] NAND: Combined oob buffer so it's contiguous with data [MTD] NAND: Correct setting of chip->oob_poi OOB buffer Merge git://git.infradead.org/~dwmw2/cafe-2.6 [MTD] NAND: Add hardware ECC correction support to CAFÉ NAND driver [MTD] NAND: CAFÉ NAND driver cleanup, fix ECC on reading empty flash [MTD] NAND: Disable ECC checking on CAFÉ since it's broken for now [MTD] NAND: Café ECC -- remove spurious BUG_ON() in err_pos() [MTD] NAND: Reset Café controller before initialising. [MTD] CAFÉ NAND: Add 'slowtiming' parameter, default usedma and checkecc on [MTD] NAND: Add ECC debugging for CAFÉ [MTD] NAND: Remove empty block ECC workaround [MTD] NAND: Fix timing calculation in CAFÉ debugging message [MTD] NAND: Use register #defines throughout CAFÉ driver, not numbers [MTD] NAND: Add register debugging spew option to CAFÉ driver [MTD] NAND: Fix ECC settings in CAFÉ controller driver. Merge git://git.infradead.org/~dwmw2/cafe-2.6 Merge git://git.infradead.org/~kmpark/onenand-mtd-2.6 [MTD] [NAND] Update CAFÉ driver interrupt handler prototype [MTD] Use EXPORT_SYMBOL_GPL() for exported symbols. [MTD] Remove trailing whitespace Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 [MTD] Fix SSFDC build for variable blocksize. [MTD] Fix ssfdc blksize typo Merge branch 'master' of git://git.infradead.org/~kmpark/onenand-mtd-2.6 [JFFS2] debug.h: include for current->pid Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 Haavard Skinnemoen (1): [MTD] bugfix: DataFlash is not bit writable Jeff Garzik (1): [JFFS2] kill warning RE debug-only variables Josh Boyer (1): [MTD] add MTD_BLKDEVS Kconfig option Kyungmin Park (9): MTD: OneNAND: interrupt based wait support [MTD] OneNAND: lock support [MTD] OneNAND: Single bit error detection [MTD] OneNAND: fix oob handling in recent oob patch [JFFS2] use the ref_offset macro [MTD] OneNAND: fix onenand_wait bug [MTD] OneNAND: add subpage write support [MTD] OneNAND: fix onenand_wait bug in read ecc error [MTD] OneNAND: return ecc error code only when 2-bit ecc occurs Lew Glendenning (1): [MTD] MAPS: Support for BIOS flash chips on Intel ESB2 southbridge Mariusz Kozlowski (1): [MTD] [NAND] Compile fix in rfc_from4.c Qi
[BUG] 2.6.20-rc4-mm1: Panic in e1000_write_vfta_82543()
I get following panic on 2.6.20-rc4-mm1 on a 2-cpu AMD Opteron system. Same basic config file seems to work with 2.6.20-rc2-mm1 on this same system. Have not tried -rc3-mm1 yet. Attached are config file and "lspci -vv" output. Let me know if you need more info. Suka --- [ 168.925840] Freeing unused kernel memory: 320k freed * INIT: version 2.86 booting * Starting basic networking... [ ok ] * Starting kernel event manager... [ ok ] * Loading hardware drivers... [ ok ] * Starting PCMCIA services... * PCMCIA not present * Loading manual drivers... [ ok ] [ 171.575122] Unable to handle kernel paging request at c20100ec55fc RIP: [ 171.584632] [] e1000_write_vfta_82543+0x58/0xd0 [ 171.614833] PGD 114e067 PUD 0 [ 171.633943] Oops: [1] PREEMPT SMP [ 171.654614] last sysfs file: /devices/pci:00/:00:06.0/:01:06.0/host0/target0:0:0/0:0:0:0/rev [ 171.698158] CPU 1 [ 171.698161] Modules linked in: [ 171.698164] Pid: 2173, comm: ifconfig Not tainted 2.6.20-rc4-mm1 #1 * Checking root[ 171.698166] RIP: 0010:[] [] e1000_write_vfta_82543+0x58/0xd0 file system...[ 171.698171] RSP: 0018:81007dfc5cf8 EFLAGS: 00010286 [ 171.698174] RAX: c20100ec55fc RBX: 81003e4c8948 RCX: /dev/shm/root: clean, 662056/2443200 files, 3121107/4883752 bloc[ 171.698176] RDX: RSI: RDI: 81003e4c8948 ks [ ok ] [ 171.698178] RBP: R08: 0010 R09: [ 171.698181] R10: 0002 R11: 804a9800 R12: c2ec [ 171.698183] R13: fffc R14: R15: 81003e4c8000 * Setting up LVM Volume Groups...[ 171.698186] FS: 2ab17ce3f6d0() GS:81007f0b0bc0() knlGS: [ 171.698188] CS: 0010 DS: ES: CR0: 8005003b [ 171.698191] CR2: c20100ec55fc CR3: 7d828000 CR4: 06e0 [ 171.698194] Process ifconfig (pid: 2173, threadinfo 81007dfc4000, task 81007dd957e0) [ 171.698196] Stack: 8000 81003e4c8680 c2ec 81003e4c8000 [ 171.698202] 7fff2dfba960 804c103d 81003e4c8680 [ 171.698205] 81003e4c8680 804c3195 [ 171.698208] Call Trace: [ 171.698216] [] e1000_vlan_rx_register+0x1dd/0x210 [ 171.698219] [] e1000_up+0x35/0x4b0 [ 171.698222] [] e1000_open+0x74/0x100 [ 171.698227] [] dev_open+0x3e/0xa0 [ 171.698230] [] dev_change_flags+0x6f/0x160 [ 171.698234] [] devinet_ioctl+0x2d4/0x6e0 [ 171.698238] [] __up_read+0x21/0xb0 [ 171.698243] [] sock_ioctl+0x1fc/0x230 [ 171.698247] [] do_ioctl+0x2f/0xa0 [ 171.698249] [] vfs_ioctl+0x2bb/0x2f0 [ 171.698252] [] sys_ioctl+0x49/0x80 [ 171.698256] [] error_exit+0x0/0x84 [ 171.698259] [] system_call+0x7e/0x83 [ 171.698261] [ 171.698262] [ 171.698262] Code: 44 8b 20 e8 30 7e 00 00 83 bb 94 01 00 00 03 75 3c 83 e5 01 [ 171.698268] RIP [] e1000_write_vfta_82543+0x58/0xd0 [ 171.698273] RSP [ 171.698274] CR2: c20100ec55fc [ 171.698276] <6>EXT3 FS on sda1, internal journal # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc4-mm1 # Thu Jan 18 15:00:14 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y # CONFIG_SWAP_PREFETCH is not set CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_USER_NS=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CPUSETS=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y
[PATCH] sata_mv HighPoint 2310 support (88SX7042)
Hi,
With the following patch, my HighPoint 2310 with a Marvell 88SX7042 on
it seems to work OK.
The controller only has 4 ports, with MV_FLAG_DUAL_HC it seems to init 8
ports and fails miserably at probe time. There are no other devices mapped
to that chip, maybe it was just incorrectly specified in the first place?
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/ata/sata_mv.c
===
--- linux-2.6.orig/drivers/ata/sata_mv.c
+++ linux-2.6/drivers/ata/sata_mv.c
@@ -523,8 +523,7 @@ static const struct ata_port_info mv_por
},
{ /* chip_7042 */
.sht= &mv_sht,
- .flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
- MV_FLAG_DUAL_HC),
+ .flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS),
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = 0x7f, /* udma0-6 */
.port_ops = &mv_iie_ops,
@@ -545,6 +544,8 @@ static const struct pci_device_id mv_pci
{ PCI_VDEVICE(ADAPTEC2, 0x0241), chip_604x },
+ { PCI_VDEVICE(TTI, 0x2310), chip_7042 },
+
{ } /* terminate list */
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: problems with latest smbfs changes on 2.4.34 and security backports
On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> @@ -505,8 +510,13 @@
> mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
> mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
>
> - mnt->flags = (oldmnt->file_mode >> 9);
> + mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
> + SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
> } else {
> + mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> + S_IROTH | S_IXOTH | S_IFREG;
> + mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> + S_IROTH | S_IXOTH | S_IFDIR;
> if (parse_options(mnt, raw_data))
> goto out_bad_option;
> }
>
>
> See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
> expected thing like this but I wonder if the initial intent was
> exactly this.
Wow - sorry about that, that's certainly a cut & paste error. But the
end result appears to match current 2.6, which was the intent.
> Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
> what I say is stupid, but it's just a guess.
I really don't know the correct answer to that, I was merely copying
the 2.6 flags.
[Still working on getting a 2.4 smbfs test system up...]
--
dann frazier
-
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: SATA exceptions with 2.6.20-rc5
On 2007.01.18 18:09:50 -0600, Robert Hancock wrote: > I heard from Larry Walton who was apparently seeing this problem as > well. He tried my recent "sata_nv: cleanup ADMA error handling v2" patch > and originally thought it fixed the problem, but it turned out to only > make it happen less often. > > I wouldn't expect that patch to have an effect on this problem. If it > seems to reduce the frequency that would tend to be further evidence of > some kind of timing-related issue where the code change just happens > to make a difference. > > I'll see if I can come up with a debug patch for people having this > problem to try, which prints out when a flush command is issued and what > interrupts happen when a flush is pending. > > There is one important difference between ADMA and non-ADMA mode for > non-DMA commands like flushes, which didn't come to mind before: ADMA > mode uses MMIO registers on the controller whereas non-ADMA mode uses > legacy IO registers. Posted write flushing is a concern with MMIO > registers but not with PIO, the libata core is supposed to handle this > but maybe it doesn't in some case(s). In fact, just looking at > libata-sff.c there's this comment on the ata_exec_command_mmio function: > > * FIXME: missing write posting for 400nS delay enforcement > > That seems a bit suspicious.. That would imply that disabling adma via a module parameter should make the issue go away, right? I'll try to have a test run with adma disabled over night then. Thanks, Björn - 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] binfmt_elf: core dump masking support
On Fri 2007-01-19 09:40:39, Kawai, Hidehiro wrote: > Hi Pavel, > > >>>Well, you can have it as set of 0-1 "limits"... > >> > >>I have come up with a similar idea of regarding the ulimit > >>value as a bitmask, and I think it may work. > >>But it will be confusable for users to add the new concept of > >>0-1 limitation into the traditional resouce limitation feature. > >>Additionaly, this approach needs a modification of each shell > >>command. > >>What do you think about these demerits? > > > >>The /proc// approach doesn't have these demerits, and it > >>has an advantage that users can change the bitmask of any process > >>at anytime. > > > > Well... not sure if it is advantage. > > For example, consider the following case: > a process forks many children and system administrator wants to > allow only one of these processes to dump shared memory. > > This is accomplished as follows: > > $ echo 1 > /proc/self/coremask > $ ./some_program > (fork children) > $ echo 0 > /proc//coremask > > With the /proc// interface, we don't need to modify the > user program. In contrast, with the ulimit or setrlimit interface, > the administrator can't do it without modifying the user program > to call setrlimit. This will not be preferred. Yep, otoh process coremask setting can change while it is running, that is not expected. Hmm, it can also change while it is dumping core, are you sure it is not racy? (run echo 1 > coremask, echo 0 > coremask in a loop while dumping core. Do you have enough locking to make it work as expected?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rdmsr_on_cpu, wrmsr_on_cpu
Andi Kleen wrote: On Friday 19 January 2007 10:40, H. Peter Anvin wrote: It would, but rather than having the paravirtualization interfaces duplicate out of control, we could/should implement the less generic features in terms of the more generic, above the pvz layer. I can't see any Hypervisors ever allowing those weird MSRs, so for paravirtualization it is probably better to just disable then. Don't assume they're going to be "weird." Intel, in particular, is notorious in forgetting what they have already documented as architectural. -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: [PATCH] binfmt_elf: core dump masking support
Hi Pavel, >>>Well, you can have it as set of 0-1 "limits"... >> >>I have come up with a similar idea of regarding the ulimit >>value as a bitmask, and I think it may work. >>But it will be confusable for users to add the new concept of >>0-1 limitation into the traditional resouce limitation feature. >>Additionaly, this approach needs a modification of each shell >>command. >>What do you think about these demerits? > >>The /proc// approach doesn't have these demerits, and it >>has an advantage that users can change the bitmask of any process >>at anytime. > > Well... not sure if it is advantage. For example, consider the following case: a process forks many children and system administrator wants to allow only one of these processes to dump shared memory. This is accomplished as follows: $ echo 1 > /proc/self/coremask $ ./some_program (fork children) $ echo 0 > /proc//coremask With the /proc// interface, we don't need to modify the user program. In contrast, with the ulimit or setrlimit interface, the administrator can't do it without modifying the user program to call setrlimit. This will not be preferred. > Semantics of ulimit inheritance > are well given, for example. How is this going to be inherited? The coremask setting is inherited in mm_init(), which is called once as an extention of do_fork(), do_execve() or compat_do_execve(). Inheritance is done by copying the bitmask from current->mm->coremask. However, if current->mm is NULL, the inherited bitmask is set to 0 (default value). Best regards, -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory - 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] rdmsr_on_cpu, wrmsr_on_cpu
On Friday 19 January 2007 10:40, H. Peter Anvin wrote: > It would, but rather than having the paravirtualization interfaces > duplicate out of control, we could/should implement the less generic > features in terms of the more generic, above the pvz layer. I can't see any Hypervisors ever allowing those weird MSRs, so for paravirtualization it is probably better to just disable then. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to flush the disk write cache from userspace
Ricardo Correia wrote: On Tuesday 16 January 2007 00:38, you wrote: As always with these things, the devil is in the details. It requires the device to support a ->prepare_flush() queue hook, and not all devices do that. It will work for IDE/SATA/SCSI, though. In some devices you don't want/need to do a real disk flush, it depends on the write cache settings, battery backing, etc. Is there any chance that someone could implement this (I don't have the skills, unfortunately)? Maybe add a new ioctl() to block devices, so that it doesn't break any existing code? I think we really should have support for doing cache flushes automatically on fsync, etc. User space code should not have to worry about this problem, it's pretty silly that for example MySQL has to advise people to use hdparm -W 0 to disable the write cache on their IDE drives in order to get proper data integrity guarantees - and disabling the cache on IDE without command queueing really slaughters the performance, unnecessarily in this case. There may be some cases where the controller provides a battery-backed cache and thus we don't want to actually force the controller to flush everything out to the drive on fsync, so we may need to be able to disable this, but these controllers may ignore flushes anyway. I know IBM ServeRAID appears to fail requests for write cache info and so the kernel assumes drive cache: write through and doesn't do any flushes. I believe it's a very useful (and relatively simple) feature that increases data integrity and reliability for applications that need this functionality. I think it must be considered that most people have disk write caches enabled and are using IDE, SATA or SCSI disks. I also think there's no point in disabling disks' write caches, since it slows writes and decreases disks' lifetime, and because there's a better solution. Yes, ideally doing all writes to the drive with write cache enabled and then flushing them out afterwards would be much more efficient (at least when no command queueing is involved) since the drive can choose what order to complete the writes in. Personally, I'm not really interested in specific filesystem behaviour, since my application uses block devices directly (it's a filesystem itself). Although I think all filesystems should guarantee data integrity in the face of fsync() or metadata modifications, even if it costs a little performance. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/15] atiixp/jmicron/triflex: fix PIO fallback
[PATCH] atiixp/jmicron/triflex: fix PIO fallback
* atiixp: if DMA can't be used atiixp_config_drive_for_dma() should return 0,
atiixp_dma_check() will tune the correct PIO mode anyway
* jmicron: if DMA can't be used config_chipset_for_dma() should return 0,
micron_config_drive_for_dma() will tune the correct PIO mode anyway
config_jmicron_chipset_for_pio(drive, !speed) doesn't program
device transfer mode for speed != 0 (only wastes some CPU cycles
on ide_get_best_pio_mode() call) so remove it
* triflex: if DMA can't be used triflex_config_drive_for_dma() should return 0,
triflex_config_drive_xfer_rate() will tune correct PIO mode anyway
Above changes also fix (theoretical) issue when ->speedproc fails to set
device transfer mode (i.e. when ide_config_drive_speed() fails to program it)
but one of DMA transfer modes is already enabled on the device by the BIOS.
In such scenario ide_dma_enable() will incorrectly return true statement
and ->ide_dma_check will try to enable DMA on the device.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/atiixp.c |7 ++-
drivers/ide/pci/jmicron.c |4 +++-
drivers/ide/pci/triflex.c |8 +++-
3 files changed, 8 insertions(+), 11 deletions(-)
Index: b/drivers/ide/pci/atiixp.c
===
--- a/drivers/ide/pci/atiixp.c
+++ b/drivers/ide/pci/atiixp.c
@@ -235,11 +235,8 @@ static int atiixp_config_drive_for_dma(i
{
u8 speed = ide_dma_speed(drive, atiixp_ratemask(drive));
- /* If no DMA speed was available then disable DMA and use PIO. */
- if (!speed) {
- u8 tspeed = ide_get_best_pio_mode(drive, 255, 5, NULL);
- speed = atiixp_dma_2_pio(XFER_PIO_0 + tspeed) + XFER_PIO_0;
- }
+ if (!speed)
+ return 0;
(void) atiixp_speedproc(drive, speed);
return ide_dma_enable(drive);
Index: b/drivers/ide/pci/jmicron.c
===
--- a/drivers/ide/pci/jmicron.c
+++ b/drivers/ide/pci/jmicron.c
@@ -147,7 +147,9 @@ static int config_chipset_for_dma (ide_d
{
u8 speed= ide_dma_speed(drive, jmicron_ratemask(drive));
- config_jmicron_chipset_for_pio(drive, !speed);
+ if (!speed)
+ return 0;
+
jmicron_tune_chipset(drive, speed);
return ide_dma_enable(drive);
}
Index: b/drivers/ide/pci/triflex.c
===
--- a/drivers/ide/pci/triflex.c
+++ b/drivers/ide/pci/triflex.c
@@ -104,11 +104,9 @@ static int triflex_config_drive_for_dma(
{
int speed = ide_dma_speed(drive, 0); /* No ultra speeds */
- if (!speed) {
- u8 pspeed = ide_get_best_pio_mode(drive, 255, 4, NULL);
- speed = XFER_PIO_0 + pspeed;
- }
-
+ if (!speed)
+ return 0;
+
(void) triflex_tune_chipset(drive, speed);
return ide_dma_enable(drive);
}
-
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 8/15] ide: disable DMA in ->ide_dma_check for "no IORDY" case
[PATCH] ide: disable DMA in ->ide_dma_check for "no IORDY" case
If DMA is unsupported ->ide_dma_check should disable DMA.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/aec62xx.c |8 +++-
drivers/ide/pci/atiixp.c |5 ++---
drivers/ide/pci/cmd64x.c |8 +++-
drivers/ide/pci/cs5535.c |5 ++---
drivers/ide/pci/hpt34x.c |8 +++-
drivers/ide/pci/hpt366.c |8 +++-
drivers/ide/pci/pdc202xx_new.c |8 +++-
drivers/ide/pci/pdc202xx_old.c |8 +++-
drivers/ide/pci/piix.c |5 ++---
drivers/ide/pci/serverworks.c |9 +++--
drivers/ide/pci/siimage.c |8 +++-
drivers/ide/pci/sis5513.c |8 +++-
drivers/ide/pci/slc90e66.c |5 ++---
drivers/ide/pci/tc86c001.c |8 +++-
14 files changed, 38 insertions(+), 63 deletions(-)
Index: b/drivers/ide/pci/aec62xx.c
===
--- a/drivers/ide/pci/aec62xx.c
+++ b/drivers/ide/pci/aec62xx.c
@@ -214,12 +214,10 @@ static int aec62xx_config_drive_xfer_rat
if (ide_use_dma(drive) && config_chipset_for_dma(drive))
return hwif->ide_dma_on(drive);
- if (ide_use_fast_pio(drive)) {
+ if (ide_use_fast_pio(drive))
aec62xx_tune_drive(drive, 5);
- return hwif->ide_dma_off_quietly(drive);
- }
- /* IORDY not supported */
- return 0;
+
+ return hwif->ide_dma_off_quietly(drive);
}
static int aec62xx_irq_timeout (ide_drive_t *drive)
Index: b/drivers/ide/pci/atiixp.c
===
--- a/drivers/ide/pci/atiixp.c
+++ b/drivers/ide/pci/atiixp.c
@@ -264,10 +264,9 @@ static int atiixp_dma_check(ide_drive_t
tspeed = ide_get_best_pio_mode(drive, 255, 5, NULL);
speed = atiixp_dma_2_pio(XFER_PIO_0 + tspeed) + XFER_PIO_0;
hwif->speedproc(drive, speed);
- return hwif->ide_dma_off_quietly(drive);
}
- /* IORDY not supported */
- return 0;
+
+ return hwif->ide_dma_off_quietly(drive);
}
/**
Index: b/drivers/ide/pci/cmd64x.c
===
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -479,12 +479,10 @@ static int cmd64x_config_drive_for_dma (
if (ide_use_dma(drive) && config_chipset_for_dma(drive))
return hwif->ide_dma_on(drive);
- if (ide_use_fast_pio(drive)) {
+ if (ide_use_fast_pio(drive))
config_chipset_for_pio(drive, 1);
- return hwif->ide_dma_off_quietly(drive);
- }
- /* IORDY not supported */
- return 0;
+
+ return hwif->ide_dma_off_quietly(drive);
}
static int cmd64x_alt_dma_status (struct pci_dev *dev)
Index: b/drivers/ide/pci/cs5535.c
===
--- a/drivers/ide/pci/cs5535.c
+++ b/drivers/ide/pci/cs5535.c
@@ -206,10 +206,9 @@ static int cs5535_dma_check(ide_drive_t
if (ide_use_fast_pio(drive)) {
speed = ide_get_best_pio_mode(drive, 255, 4, NULL);
cs5535_set_drive(drive, speed);
- return hwif->ide_dma_off_quietly(drive);
}
- /* IORDY not supported */
- return 0;
+
+ return hwif->ide_dma_off_quietly(drive);
}
static u8 __devinit cs5535_cable_detect(struct pci_dev *dev)
Index: b/drivers/ide/pci/hpt34x.c
===
--- a/drivers/ide/pci/hpt34x.c
+++ b/drivers/ide/pci/hpt34x.c
@@ -120,12 +120,10 @@ static int hpt34x_config_drive_xfer_rate
return hwif->ide_dma_on(drive);
#endif
- if (ide_use_fast_pio(drive)) {
+ if (ide_use_fast_pio(drive))
hpt34x_tune_drive(drive, 255);
- return hwif->ide_dma_off_quietly(drive);
- }
- /* IORDY not supported */
- return 0;
+
+ return hwif->ide_dma_off_quietly(drive);
}
/*
Index: b/drivers/ide/pci/hpt366.c
===
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -743,12 +743,10 @@ static int hpt366_config_drive_xfer_rate
if (ide_use_dma(drive) && config_chipset_for_dma(drive))
return hwif->ide_dma_on(drive);
- if (ide_use_fast_pio(drive)) {
+ if (ide_use_fast_pio(drive))
hpt3xx_tune_drive(drive, 255);
- return hwif->ide_dma_off_quietly(drive);
- }
- /* IORDY not supported */
- return 0;
+
+ return hwif->ide_dma_off_quietly(drive);
}
/*
Index: b/drivers/ide/pci/pdc202xx_new.c
===
--- a/drivers/ide/pci/pdc202xx_new.c
+++ b/drivers/ide/pci/pdc202xx_new.c
@@ -288,12 +288,10 @@ static int pdcnew_config_drive_xfer_rate
[PATCH 3/15] it8213: fix build and ->ultra_mask
[PATCH] it8213: fix build and ->ultra_mask
* PCI_DEVICE_ID_ITE_8213 is only defined in -mm kernels,
so just use PCI Device ID (0x8213) directly
* fix ->ultra_mask to indicate UDMA6 support
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/it8213.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ide/pci/it8213.c
===
--- a/drivers/ide/pci/it8213.c
+++ b/drivers/ide/pci/it8213.c
@@ -282,7 +282,7 @@ static void __devinit init_hwif_it8213(i
return;
hwif->atapi_dma = 1;
- hwif->ultra_mask = 0x3f;
+ hwif->ultra_mask = 0x7f;
hwif->mwdma_mask = 0x06;
hwif->swdma_mask = 0x04;
@@ -338,7 +338,7 @@ static int __devinit it8213_init_one(str
static struct pci_device_id it8213_pci_tbl[] = {
- { PCI_VENDOR_ID_ITE, PCI_DEVICE_ID_ITE_8213, PCI_ANY_ID, PCI_ANY_ID,
0, 0, 0},
+ { PCI_VENDOR_ID_ITE, 0x8213, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0, },
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/15] ide: fix UDMA/MWDMA/SWDMA masks
[PATCH] ide: fix UDMA/MWDMA/SWDMA masks
* use 0x00 instead of 0x80 to disable ->{ultra,mwdma,swdma}_mask
* add udma_mask field to ide_pci_device_t and use it to initialize
->ultra_mask in aec62xx, pdc202xx_new and pdc202xx_old drivers
* fix UDMA masks to match with chipset specific *_ratemask()
(alim15x3, hpt366, serverworks and siimage drivers need UDMA mask
filtering method - done in the next patch)
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide.c |3 ---
drivers/ide/pci/aec62xx.c | 20 ++--
drivers/ide/pci/alim15x3.c | 13 +++--
drivers/ide/pci/cmd64x.c |5 +++--
drivers/ide/pci/pdc202xx_new.c |9 -
drivers/ide/pci/pdc202xx_old.c |7 ++-
drivers/ide/pci/piix.c |6 +-
drivers/ide/pci/sis5513.c |5 -
include/linux/ide.h|1 +
9 files changed, 56 insertions(+), 13 deletions(-)
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -222,9 +222,6 @@ static void init_hwif_data(ide_hwif_t *h
hwif->bus_state = BUSSTATE_ON;
hwif->atapi_dma = 0;/* disable all atapi dma */
- hwif->ultra_mask = 0x80;/* disable all ultra */
- hwif->mwdma_mask = 0x80;/* disable all mwdma */
- hwif->swdma_mask = 0x80;/* disable all swdma */
init_completion(&hwif->gendev_rel_comp);
Index: b/drivers/ide/pci/aec62xx.c
===
--- a/drivers/ide/pci/aec62xx.c
+++ b/drivers/ide/pci/aec62xx.c
@@ -270,11 +270,13 @@ static unsigned int __devinit init_chips
static void __devinit init_hwif_aec62xx(ide_hwif_t *hwif)
{
+ struct pci_dev *dev = hwif->pci_dev;
+
hwif->autodma = 0;
hwif->tuneproc = &aec62xx_tune_drive;
hwif->speedproc = &aec62xx_tune_chipset;
- if (hwif->pci_dev->device == PCI_DEVICE_ID_ARTOP_ATP850UF)
+ if (dev->device == PCI_DEVICE_ID_ARTOP_ATP850UF)
hwif->serialized = hwif->channel;
if (hwif->mate)
@@ -286,7 +288,16 @@ static void __devinit init_hwif_aec62xx(
return;
}
- hwif->ultra_mask = 0x7f;
+ hwif->ultra_mask = hwif->cds->udma_mask;
+
+ /* atp865 and atp865r */
+ if (hwif->ultra_mask == 0x3f) {
+ unsigned long io = pci_resource_start(dev, 4);
+
+ if (inb(io) & 0x10)
+ hwif->ultra_mask = 0x7f; /* udma0-6 */
+ }
+
hwif->mwdma_mask = 0x07;
hwif->swdma_mask = 0x07;
@@ -354,6 +365,7 @@ static ide_pci_device_t aec62xx_chipsets
.autodma= AUTODMA,
.enablebits = {{0x4a,0x02,0x02}, {0x4a,0x04,0x04}},
.bootable = OFF_BOARD,
+ .udma_mask = 0x07, /* udma0-2 */
},{ /* 1 */
.name = "AEC6260",
.init_setup = init_setup_aec62xx,
@@ -363,6 +375,7 @@ static ide_pci_device_t aec62xx_chipsets
.channels = 2,
.autodma= NOAUTODMA,
.bootable = OFF_BOARD,
+ .udma_mask = 0x1f, /* udma0-4 */
},{ /* 2 */
.name = "AEC6260R",
.init_setup = init_setup_aec62xx,
@@ -373,6 +386,7 @@ static ide_pci_device_t aec62xx_chipsets
.autodma= AUTODMA,
.enablebits = {{0x4a,0x02,0x02}, {0x4a,0x04,0x04}},
.bootable = NEVER_BOARD,
+ .udma_mask = 0x1f, /* udma0-4 */
},{ /* 3 */
.name = "AEC6X80",
.init_setup = init_setup_aec6x80,
@@ -382,6 +396,7 @@ static ide_pci_device_t aec62xx_chipsets
.channels = 2,
.autodma= AUTODMA,
.bootable = OFF_BOARD,
+ .udma_mask = 0x3f, /* udma0-5 */
},{ /* 4 */
.name = "AEC6X80R",
.init_setup = init_setup_aec6x80,
@@ -392,6 +407,7 @@ static ide_pci_device_t aec62xx_chipsets
.autodma= AUTODMA,
.enablebits = {{0x4a,0x02,0x02}, {0x4a,0x04,0x04}},
.bootable = OFF_BOARD,
+ .udma_mask = 0x3f, /* udma0-5 */
}
};
Index: b/drivers/ide/pci/alim15x3.c
===
--- a/drivers/ide/pci/alim15x3.c
+++ b/drivers/ide/pci/alim15x3.c
@@ -765,8 +765,17 @@ static void __devinit init_hwif_common_a
hwif->atapi_dma = 1;
- if (m5229_revision > 0x20)
- hwif->ultra_mask = 0x7f;
+ if (m5229_revision <= 0x20)
+ hwif->ultra_mask = 0x00; /* no udma */
+ else if (m5229_revision < 0xC2)
+ hwif->u
[PATCH 12/15] ide: make ide_hwif_t.ide_dma_host_on void
[PATCH] ide: make ide_hwif_t.ide_dma_host_on void
* since ide_hwif_t.ide_dma_host_on is called either when drive->using_dma == 1
or when return value is discarded make it void, also drop "ide_" prefix
* make __ide_dma_host_on() void and drop "__" prefix
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/arm/icside.c |8
drivers/ide/cris/ide-cris.c |2 +-
drivers/ide/ide-dma.c | 17 +++--
drivers/ide/ide-iops.c|2 +-
drivers/ide/ide.c |2 +-
drivers/ide/mips/au1xxx-ide.c |8
drivers/ide/pci/atiixp.c |6 +++---
drivers/ide/pci/sgiioc4.c | 11 +++
drivers/ide/ppc/pmac.c|6 ++
include/linux/ide.h |4 ++--
10 files changed, 28 insertions(+), 38 deletions(-)
Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -316,15 +316,15 @@ static void icside_dma_off_quietly(ide_d
drive->using_dma = 0;
}
-static int icside_dma_host_on(ide_drive_t *drive)
+static void icside_dma_host_on(ide_drive_t *drive)
{
- return 0;
}
static int icside_dma_on(ide_drive_t *drive)
{
drive->using_dma = 1;
- return icside_dma_host_on(drive);
+
+ return 0;
}
static int icside_dma_check(ide_drive_t *drive)
@@ -494,7 +494,7 @@ static void icside_dma_init(ide_hwif_t *
hwif->ide_dma_check = icside_dma_check;
hwif->dma_host_off = icside_dma_host_off;
hwif->dma_off_quietly = icside_dma_off_quietly;
- hwif->ide_dma_host_on = icside_dma_host_on;
+ hwif->dma_host_on = icside_dma_host_on;
hwif->ide_dma_on= icside_dma_on;
hwif->dma_setup = icside_dma_setup;
hwif->dma_exec_cmd = icside_dma_exec_cmd;
Index: b/drivers/ide/cris/ide-cris.c
===
--- a/drivers/ide/cris/ide-cris.c
+++ b/drivers/ide/cris/ide-cris.c
@@ -818,7 +818,7 @@ init_e100_ide (void)
hwif->INB = &cris_ide_inb;
hwif->INW = &cris_ide_inw;
hwif->dma_host_off = &cris_dma_off;
- hwif->ide_dma_host_on = &cris_dma_on;
+ hwif->dma_host_on = &cris_dma_on;
hwif->dma_off_quietly = &cris_dma_off;
hwif->udma_four = 0;
hwif->ultra_mask = cris_ultra_mask;
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -468,14 +468,14 @@ EXPORT_SYMBOL(ide_dma_off);
#ifdef CONFIG_BLK_DEV_IDEDMA_PCI
/**
- * __ide_dma_host_on - Enable DMA on a host
+ * ide_dma_host_on - Enable DMA on a host
* @drive: drive to enable for DMA
*
* Enable DMA on an IDE controller following generic bus mastering
* IDE controller behaviour
*/
-
-int __ide_dma_host_on (ide_drive_t *drive)
+
+void ide_dma_host_on(ide_drive_t *drive)
{
if (drive->using_dma) {
ide_hwif_t *hwif= HWIF(drive);
@@ -483,12 +483,10 @@ int __ide_dma_host_on (ide_drive_t *driv
u8 dma_stat = hwif->INB(hwif->dma_status);
hwif->OUTB((dma_stat|(1<<(5+unit))), hwif->dma_status);
- return 0;
}
- return 1;
}
-EXPORT_SYMBOL(__ide_dma_host_on);
+EXPORT_SYMBOL(ide_dma_host_on);
/**
* __ide_dma_on- Enable DMA on a device
@@ -506,8 +504,7 @@ int __ide_dma_on (ide_drive_t *drive)
drive->using_dma = 1;
ide_toggle_bounce(drive, 1);
- if (HWIF(drive)->ide_dma_host_on(drive))
- return 1;
+ drive->hwif->dma_host_on(drive);
return 0;
}
@@ -940,8 +937,8 @@ void ide_setup_dma (ide_hwif_t *hwif, un
hwif->dma_host_off = &ide_dma_host_off;
if (!hwif->ide_dma_on)
hwif->ide_dma_on = &__ide_dma_on;
- if (!hwif->ide_dma_host_on)
- hwif->ide_dma_host_on = &__ide_dma_host_on;
+ if (!hwif->dma_host_on)
+ hwif->dma_host_on = &ide_dma_host_on;
if (!hwif->ide_dma_check)
hwif->ide_dma_check = &__ide_dma_check;
if (!hwif->dma_setup)
Index: b/drivers/ide/ide-iops.c
===
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -830,7 +830,7 @@ int ide_config_drive_speed (ide_drive_t
#ifdef CONFIG_BLK_DEV_IDEDMA
if (speed >= XFER_SW_DMA_0)
- hwif->ide_dma_host_on(drive);
+ hwif->dma_host_on(drive);
else if (hwif->ide_dma_check) /* check if host supports DMA */
hwif->dma_off_quietly(drive);
#endif
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
++
[PATCH 9/15] sgiioc4: fix sgiioc4_ide_dma_check() to enable/disable DMA properly
[PATCH] sgiioc4: fix sgiioc4_ide_dma_check() to enable/disable DMA properly
* use sgiioc4_ide_dma_{on,off_quietly}() instead of changing
drive->using_dma directly
* fix warning message
* add FIXME
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/sgiioc4.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
Index: b/drivers/ide/pci/sgiioc4.c
===
--- a/drivers/ide/pci/sgiioc4.c
+++ b/drivers/ide/pci/sgiioc4.c
@@ -275,21 +275,6 @@ sgiioc4_ide_dma_end(ide_drive_t * drive)
}
static int
-sgiioc4_ide_dma_check(ide_drive_t * drive)
-{
- if (ide_config_drive_speed(drive, XFER_MW_DMA_2) != 0) {
- printk(KERN_INFO
- "Couldnot set %s in Multimode-2 DMA mode | "
- "Drive %s using PIO instead\n",
- drive->name, drive->name);
- drive->using_dma = 0;
- } else
- drive->using_dma = 1;
-
- return 0;
-}
-
-static int
sgiioc4_ide_dma_on(ide_drive_t * drive)
{
drive->using_dma = 1;
@@ -305,6 +290,17 @@ sgiioc4_ide_dma_off_quietly(ide_drive_t
return HWIF(drive)->ide_dma_host_off(drive);
}
+static int sgiioc4_ide_dma_check(ide_drive_t *drive)
+{
+ /* FIXME: check for available DMA modes */
+ if (ide_config_drive_speed(drive, XFER_MW_DMA_2) != 0) {
+ printk(KERN_WARNING "%s: couldn't set MWDMA2 mode, "
+ "using PIO instead\n", drive->name);
+ return sgiioc4_ide_dma_off_quietly(drive);
+ } else
+ return sgiioc4_ide_dma_on(drive);
+}
+
/* returns 1 if dma irq issued, 0 otherwise */
static int
sgiioc4_ide_dma_test_irq(ide_drive_t * drive)
-
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/15] via82cxxx/pata_via: correct PCI_DEVICE_ID_VIA_SATA_EIDE ID and add support for CX700 and 8237S
[PATCH] via82cxxx/pata_via: correct PCI_DEVICE_ID_VIA_SATA_EIDE ID and add
support for CX700 and 8237S
This patch:
* Corrects the wrong device ID of PCI_DEVICE_ID_VIA_SATA_EIDE
from 0x0581 to 0x5324.
* Adds VIA CX700 and VT8237S support in drivers/ide/pci/via82cxxx.c
* Adds VIA VT8237S support in drivers/ata/pata_via.c
Signed-off-by: Josepch Chan <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ata/pata_via.c |1 +
drivers/ide/pci/via82cxxx.c |3 +++
include/linux/pci_ids.h |3 ++-
3 files changed, 6 insertions(+), 1 deletion(-)
Index: b/drivers/ata/pata_via.c
===
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -95,6 +95,7 @@ static const struct via_isa_bridge {
u8 rev_max;
u16 flags;
} via_isa_bridges[] = {
+ { "vt8237s",PCI_DEVICE_ID_VIA_8237S,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "cx700", PCI_DEVICE_ID_VIA_CX700,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST | VIA_NO_ENABLES},
Index: b/drivers/ide/pci/via82cxxx.c
===
--- a/drivers/ide/pci/via82cxxx.c
+++ b/drivers/ide/pci/via82cxxx.c
@@ -78,6 +78,8 @@ static struct via_isa_bridge {
u8 rev_max;
u16 flags;
} via_isa_bridges[] = {
+ { "cx7000", PCI_DEVICE_ID_VIA_CX700, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
+ { "vt8237s",PCI_DEVICE_ID_VIA_8237S,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
@@ -504,6 +506,7 @@ static struct pci_device_id via_pci_tbl[
{ PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_6410, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
+ { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_SATA_EIDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
{ 0, },
};
MODULE_DEVICE_TABLE(pci, via_pci_tbl);
Index: b/include/linux/pci_ids.h
===
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1283,7 +1283,6 @@
#define PCI_DEVICE_ID_VIA_82C561 0x0561
#define PCI_DEVICE_ID_VIA_82C586_1 0x0571
#define PCI_DEVICE_ID_VIA_82C576 0x0576
-#define PCI_DEVICE_ID_VIA_SATA_EIDE0x0581
#define PCI_DEVICE_ID_VIA_82C586_0 0x0586
#define PCI_DEVICE_ID_VIA_82C596 0x0596
#define PCI_DEVICE_ID_VIA_82C597_0 0x0597
@@ -1326,6 +1325,8 @@
#define PCI_DEVICE_ID_VIA_8237 0x3227
#define PCI_DEVICE_ID_VIA_8251 0x3287
#define PCI_DEVICE_ID_VIA_8237A0x3337
+#define PCI_DEVICE_ID_VIA_8237S0x3372
+#define PCI_DEVICE_ID_VIA_SATA_EIDE0x5324
#define PCI_DEVICE_ID_VIA_8231 0x8231
#define PCI_DEVICE_ID_VIA_8231_4 0x8235
#define PCI_DEVICE_ID_VIA_8365_1 0x8305
-
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 15/15] ide: add ide_tune_dma() helper
[PATCH] ide: add ide_tune_dma() helper
After reworking the code responsible for selecting the best DMA
transfer mode it is now possible to add generic ide_tune_dma() helper.
Convert some IDE PCI host drivers to use it (the ones left need more work).
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-dma.c | 20
drivers/ide/pci/aec62xx.c | 13 +
drivers/ide/pci/atiixp.c | 22 +-
drivers/ide/pci/cs5535.c | 15 +--
drivers/ide/pci/hpt34x.c | 20 +---
drivers/ide/pci/hpt366.c | 20 +---
drivers/ide/pci/it8213.c | 21 +
drivers/ide/pci/jmicron.c | 21 +
drivers/ide/pci/piix.c | 26 +-
drivers/ide/pci/sis5513.c | 21 +
drivers/ide/pci/slc90e66.c | 13 +
drivers/ide/pci/tc86c001.c | 13 +
drivers/ide/pci/triflex.c | 13 +
include/linux/ide.h|2 ++
14 files changed, 34 insertions(+), 206 deletions(-)
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -779,6 +779,26 @@ u8 ide_max_dma_mode(ide_drive_t *drive)
EXPORT_SYMBOL_GPL(ide_max_dma_mode);
+int ide_tune_dma(ide_drive_t *drive)
+{
+ u8 speed;
+
+ /* TODO: use only ide_max_dma_mode() */
+ if (!ide_use_dma(drive))
+ return 0;
+
+ speed = ide_max_dma_mode(drive);
+
+ if (!speed)
+ return 0;
+
+ drive->hwif->speedproc(drive, speed);
+
+ return ide_dma_enable(drive);
+}
+
+EXPORT_SYMBOL_GPL(ide_tune_dma);
+
void ide_dma_verbose(ide_drive_t *drive)
{
struct hd_driveid *id = drive->id;
Index: b/drivers/ide/pci/aec62xx.c
===
--- a/drivers/ide/pci/aec62xx.c
+++ b/drivers/ide/pci/aec62xx.c
@@ -154,17 +154,6 @@ static int aec62xx_tune_chipset (ide_dri
}
}
-static int config_chipset_for_dma (ide_drive_t *drive)
-{
- u8 speed = ide_max_dma_mode(drive);
-
- if (!(speed))
- return 0;
-
- (void) aec62xx_tune_chipset(drive, speed);
- return ide_dma_enable(drive);
-}
-
static void aec62xx_tune_drive (ide_drive_t *drive, u8 pio)
{
u8 speed = 0;
@@ -183,7 +172,7 @@ static void aec62xx_tune_drive (ide_driv
static int aec62xx_config_drive_xfer_rate (ide_drive_t *drive)
{
- if (ide_use_dma(drive) && config_chipset_for_dma(drive))
+ if (ide_tune_dma(drive))
return 0;
if (ide_use_fast_pio(drive))
Index: b/drivers/ide/pci/atiixp.c
===
--- a/drivers/ide/pci/atiixp.c
+++ b/drivers/ide/pci/atiixp.c
@@ -207,26 +207,6 @@ static int atiixp_speedproc(ide_drive_t
}
/**
- * atiixp_config_drive_for_dma - configure drive for DMA
- * @drive: IDE drive to configure
- *
- * Set up a ATIIXP interface channel for the best available speed.
- * We prefer UDMA if it is available and then MWDMA. If DMA is
- * not available we switch to PIO and return 0.
- */
-
-static int atiixp_config_drive_for_dma(ide_drive_t *drive)
-{
- u8 speed = ide_max_dma_mode(drive);
-
- if (!speed)
- return 0;
-
- (void) atiixp_speedproc(drive, speed);
- return ide_dma_enable(drive);
-}
-
-/**
* atiixp_dma_check- set up an IDE device
* @drive: IDE drive to configure
*
@@ -240,7 +220,7 @@ static int atiixp_dma_check(ide_drive_t
drive->init_speed = 0;
- if (ide_use_dma(drive) && atiixp_config_drive_for_dma(drive))
+ if (ide_tune_dma(drive))
return 0;
if (ide_use_fast_pio(drive)) {
Index: b/drivers/ide/pci/cs5535.c
===
--- a/drivers/ide/pci/cs5535.c
+++ b/drivers/ide/pci/cs5535.c
@@ -164,26 +164,13 @@ static void cs5535_tuneproc(ide_drive_t
cs5535_set_speed(drive, xferspeed);
}
-static int cs5535_config_drive_for_dma(ide_drive_t *drive)
-{
- u8 speed = ide_max_dma_mode(drive);
-
- /* If no DMA speed was available then let dma_check hit pio */
- if (!speed) {
- return 0;
- }
-
- cs5535_set_drive(drive, speed);
- return ide_dma_enable(drive);
-}
-
static int cs5535_dma_check(ide_drive_t *drive)
{
u8 speed;
drive->init_speed = 0;
- if (ide_use_dma(drive) && cs5535_config_drive_for_dma(drive))
+ if (ide_tune_dma(drive))
return 0;
if (ide_use_fast_pio(drive)) {
Index: b/drivers/ide/pci/hpt34x.c
===
--- a/drivers/ide/pci/hpt34x.c
+++ b/drivers/ide/pci/hpt34x.c
@@ -84,29 +84,11 @@ static void hpt34x_tune_drive (ide_drive
[PATCH 14/15] ide: rework the code for selecting the best DMA transfer mode
[PATCH] ide: rework the code for selecting the best DMA transfer mode
Depends on the "ide: fix UDMA/MWDMA/SWDMA masks" patch.
* add ide_hwif_t.filter_udma_mask hook for filtering UDMA mask
(use it in alim15x3, hpt366, siimage and serverworks drivers)
* add ide_max_dma_mode() for finding best DMA mode for the device
(loosely based on some older libata-core.c code)
* convert ide_dma_speed() users to use ide_max_dma_mode()
* make ide_rate_filter() take "ide_drive_t *drive" as an argument instead
of "u8 mode" and teach it to how to use UDMA mask to do filtering
* use ide_rate_filter() in hpt366 driver
* remove no longer needed ide_dma_speed() and *_ratemask()
* unexport eighty_ninty_three()
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/arm/icside.c |2
drivers/ide/cris/ide-cris.c|2
drivers/ide/ide-dma.c | 74
drivers/ide/ide-iops.c |2
drivers/ide/ide-lib.c | 125 +
drivers/ide/ide.c |1
drivers/ide/pci/aec62xx.c | 32 --
drivers/ide/pci/alim15x3.c | 76 +---
drivers/ide/pci/atiixp.c | 20 --
drivers/ide/pci/cmd64x.c | 66 -
drivers/ide/pci/cs5535.c | 20 --
drivers/ide/pci/hpt34x.c |9 --
drivers/ide/pci/hpt366.c | 67 +++--
drivers/ide/pci/it8213.c | 20 --
drivers/ide/pci/it821x.c | 20 --
drivers/ide/pci/jmicron.c | 21 --
drivers/ide/pci/pdc202xx_new.c | 14
drivers/ide/pci/pdc202xx_old.c | 27
drivers/ide/pci/piix.c | 66 -
drivers/ide/pci/serverworks.c | 31 ++
drivers/ide/pci/siimage.c | 45 ++
drivers/ide/pci/sis5513.c | 14
drivers/ide/pci/slc90e66.c | 13
drivers/ide/pci/tc86c001.c |9 --
drivers/ide/pci/triflex.c |4 -
include/linux/ide.h| 10 +--
26 files changed, 235 insertions(+), 555 deletions(-)
Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -347,7 +347,7 @@ static int icside_dma_check(ide_drive_t
* Enable DMA on any drive that has multiword DMA
*/
if (id->field_valid & 2) {
- xfer_mode = ide_dma_speed(drive, 0);
+ xfer_mode = ide_max_dma_mode(drive);
goto out;
}
Index: b/drivers/ide/cris/ide-cris.c
===
--- a/drivers/ide/cris/ide-cris.c
+++ b/drivers/ide/cris/ide-cris.c
@@ -1006,7 +1006,7 @@ static int cris_ide_build_dmatable (ide_
static int cris_config_drive_for_dma (ide_drive_t *drive)
{
- u8 speed = ide_dma_speed(drive, 1);
+ u8 speed = ide_max_dma_mode(drive);
if (!speed)
return 0;
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -705,6 +705,80 @@ int ide_use_dma(ide_drive_t *drive)
EXPORT_SYMBOL_GPL(ide_use_dma);
+static const u8 xfer_mode_bases[] = {
+ XFER_UDMA_0,
+ XFER_MW_DMA_0,
+ XFER_SW_DMA_0,
+};
+
+static unsigned int ide_get_mode_mask(ide_drive_t *drive, u8 base)
+{
+ struct hd_driveid *id = drive->id;
+ ide_hwif_t *hwif = drive->hwif;
+ unsigned int mask = 0;
+
+ switch(base) {
+ case XFER_UDMA_0:
+ if ((id->field_valid & 4) == 0)
+ break;
+
+ mask = id->dma_ultra & hwif->ultra_mask;
+
+ if (hwif->filter_udma_mask)
+ mask &= hwif->filter_udma_mask(drive);
+
+ if ((mask & 0x78) && (eighty_ninty_three(drive) == 0))
+ mask &= 0x07;
+ break;
+ case XFER_MW_DMA_0:
+ mask = id->dma_mword & hwif->mwdma_mask;
+ break;
+ case XFER_SW_DMA_0:
+ mask = id->dma_1word & hwif->swdma_mask;
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ return mask;
+}
+
+/**
+ * ide_max_dma_mode- compute DMA speed
+ * @drive: IDE device
+ *
+ * Checks the drive capabilities and returns the speed to use
+ * for the DMA transfer. Returns 0 if the drive is incapable
+ * of DMA transfers.
+ */
+
+u8 ide_max_dma_mode(ide_drive_t *drive)
+{
+ ide_hwif_t *hwif = drive->hwif;
+ unsigned int mask;
+ int x, i;
+ u8 mode = 0;
+
+ if (drive->media != ide_disk && hwif->atapi_dma == 0)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(xfer_mode_bases); i++) {
+ mask = ide_get_mode_mask(drive, xfer_mode_bases[i]);
+ x = fls(mask) - 1;
+
[PATCH 10/15] ide: add ide_set_dma() helper
[PATCH] ide: add ide_set_dma() helper
* add ide_set_dma() helper and make ide_hwif_t.ide_dma_check return
-1 when DMA needs to be disabled (== need to call ->ide_dma_off_quietly)
0 when DMA needs to be enabled (== need to call ->ide_dma_on)
1 when DMA setting shouldn't be changed
* fix IDE code to use ide_set_dma() instead if using ->ide_dma_check directly
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/arm/icside.c |5 +
drivers/ide/cris/ide-cris.c|6 ++
drivers/ide/ide-dma.c | 37 ++---
drivers/ide/ide-io.c |2 +-
drivers/ide/ide-probe.c|2 +-
drivers/ide/ide.c |3 ++-
drivers/ide/mips/au1xxx-ide.c |4 ++--
drivers/ide/pci/aec62xx.c |6 ++
drivers/ide/pci/alim15x3.c | 11 +--
drivers/ide/pci/amd74xx.c |5 +++--
drivers/ide/pci/atiixp.c |7 +++
drivers/ide/pci/cmd64x.c |6 ++
drivers/ide/pci/cs5520.c |5 ++---
drivers/ide/pci/cs5530.c |5 +
drivers/ide/pci/cs5535.c |5 ++---
drivers/ide/pci/hpt34x.c |8 +++-
drivers/ide/pci/hpt366.c |6 ++
drivers/ide/pci/it8213.c | 14 ++
drivers/ide/pci/it821x.c | 12 +---
drivers/ide/pci/jmicron.c | 10 --
drivers/ide/pci/ns87415.c |3 ++-
drivers/ide/pci/pdc202xx_new.c |8 +++-
drivers/ide/pci/pdc202xx_old.c |8 +++-
drivers/ide/pci/piix.c | 10 --
drivers/ide/pci/sc1200.c |5 +
drivers/ide/pci/serverworks.c |6 ++
drivers/ide/pci/sgiioc4.c |4 ++--
drivers/ide/pci/siimage.c |6 ++
drivers/ide/pci/sis5513.c |6 ++
drivers/ide/pci/sl82c105.c |6 +++---
drivers/ide/pci/slc90e66.c | 10 --
drivers/ide/pci/tc86c001.c |6 ++
drivers/ide/pci/triflex.c |9 -
drivers/ide/pci/via82cxxx.c|5 +++--
include/linux/ide.h|2 ++
35 files changed, 118 insertions(+), 135 deletions(-)
Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -365,10 +365,7 @@ static int icside_dma_check(ide_drive_t
out:
on = icside_set_speed(drive, xfer_mode);
- if (on)
- return icside_dma_on(drive);
- else
- return icside_dma_off_quietly(drive);
+ return on ? 0 : -1;
}
static int icside_dma_end(ide_drive_t *drive)
Index: b/drivers/ide/cris/ide-cris.c
===
--- a/drivers/ide/cris/ide-cris.c
+++ b/drivers/ide/cris/ide-cris.c
@@ -1048,12 +1048,10 @@ static ide_startstop_t cris_dma_intr (id
static int cris_dma_check(ide_drive_t *drive)
{
- ide_hwif_t *hwif = drive->hwif;
-
if (ide_use_dma(drive) && cris_config_drive_for_dma(drive))
- return hwif->ide_dma_on(drive);
+ return 0;
- return hwif->ide_dma_off_quietly(drive);
+ return -1;
}
static int cris_dma_end(ide_drive_t *drive)
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -348,15 +348,14 @@ EXPORT_SYMBOL_GPL(ide_destroy_dmatable);
static int config_drive_for_dma (ide_drive_t *drive)
{
struct hd_driveid *id = drive->id;
- ide_hwif_t *hwif = HWIF(drive);
- if ((id->capability & 1) && hwif->autodma) {
+ if ((id->capability & 1) && drive->hwif->autodma) {
/*
* Enable DMA on any drive that has
* UltraDMA (mode 0/1/2/3/4/5/6) enabled
*/
if ((id->field_valid & 4) && ((id->dma_ultra >> 8) & 0x7f))
- return hwif->ide_dma_on(drive);
+ return 0;
/*
* Enable DMA on any drive that has mode2 DMA
* (multi or single) enabled
@@ -364,14 +363,14 @@ static int config_drive_for_dma (ide_dri
if (id->field_valid & 2)/* regular DMA */
if ((id->dma_mword & 0x404) == 0x404 ||
(id->dma_1word & 0x404) == 0x404)
- return hwif->ide_dma_on(drive);
+ return 0;
/* Consult the list of known "good" drives */
if (__ide_dma_good_drive(drive))
- return hwif->ide_dma_on(drive);
+ return 0;
}
-// if (hwif->tuneproc != NULL) hwif->tuneproc(drive, 255);
- return hwif->ide_dma_off_quietly(drive);
+
+ return -1;
}
/**
@@ -765,6 +764,30 @@ bug_dma_off:
EXPORT_SYMBOL(ide_dma_verbose);
+int ide_set_dma(ide_drive_t *drive)
+{
+ ide_hwif_t *hwif =
[PATCH 11/15] ide: make ide_hwif_t.ide_dma_{host_off,off_quietly} void
[PATCH] ide: make ide_hwif_t.ide_dma_{host_off,off_quietly} void
* since ide_hwif_t.ide_dma_{host_off,off_quietly} always return '0'
make these functions void and while at it drop "ide_" prefix
* fix comment for __ide_dma_off_quietly()
* make __ide_dma_{host_off,off_quietly,off}() void and drop "__" prefix
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/arm/icside.c | 10 --
drivers/ide/cris/ide-cris.c | 14 ++
drivers/ide/ide-cd.c |6 +++---
drivers/ide/ide-dma.c | 39 ++-
drivers/ide/ide-floppy.c |8
drivers/ide/ide-io.c |2 +-
drivers/ide/ide-iops.c|8
drivers/ide/ide-probe.c |2 +-
drivers/ide/ide-tape.c|4 ++--
drivers/ide/ide.c | 10 --
drivers/ide/mips/au1xxx-ide.c | 11 ---
drivers/ide/pci/atiixp.c |6 +++---
drivers/ide/pci/cs5530.c |2 +-
drivers/ide/pci/it821x.c |2 +-
drivers/ide/pci/sc1200.c |6 +++---
drivers/ide/pci/sgiioc4.c | 14 +-
drivers/ide/pci/sl82c105.c| 14 ++
drivers/ide/ppc/pmac.c|8 +++-
include/linux/ide.h | 12 ++--
19 files changed, 79 insertions(+), 99 deletions(-)
Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -307,15 +307,13 @@ static int icside_set_speed(ide_drive_t
return on;
}
-static int icside_dma_host_off(ide_drive_t *drive)
+static void icside_dma_host_off(ide_drive_t *drive)
{
- return 0;
}
-static int icside_dma_off_quietly(ide_drive_t *drive)
+static void icside_dma_off_quietly(ide_drive_t *drive)
{
drive->using_dma = 0;
- return icside_dma_host_off(drive);
}
static int icside_dma_host_on(ide_drive_t *drive)
@@ -494,8 +492,8 @@ static void icside_dma_init(ide_hwif_t *
hwif->autodma = autodma;
hwif->ide_dma_check = icside_dma_check;
- hwif->ide_dma_host_off = icside_dma_host_off;
- hwif->ide_dma_off_quietly = icside_dma_off_quietly;
+ hwif->dma_host_off = icside_dma_host_off;
+ hwif->dma_off_quietly = icside_dma_off_quietly;
hwif->ide_dma_host_on = icside_dma_host_on;
hwif->ide_dma_on= icside_dma_on;
hwif->dma_setup = icside_dma_setup;
Index: b/drivers/ide/cris/ide-cris.c
===
--- a/drivers/ide/cris/ide-cris.c
+++ b/drivers/ide/cris/ide-cris.c
@@ -682,9 +682,12 @@ static void cris_ide_input_data (ide_dri
static void cris_ide_output_data (ide_drive_t *drive, void *, unsigned int);
static void cris_atapi_input_bytes(ide_drive_t *drive, void *, unsigned int);
static void cris_atapi_output_bytes(ide_drive_t *drive, void *, unsigned int);
-static int cris_dma_off (ide_drive_t *drive);
static int cris_dma_on (ide_drive_t *drive);
+static void cris_dma_off(ide_drive_t *drive)
+{
+}
+
static void tune_cris_ide(ide_drive_t *drive, u8 pio)
{
int setup, strobe, hold;
@@ -814,9 +817,9 @@ init_e100_ide (void)
hwif->OUTBSYNC = &cris_ide_outbsync;
hwif->INB = &cris_ide_inb;
hwif->INW = &cris_ide_inw;
- hwif->ide_dma_host_off = &cris_dma_off;
+ hwif->dma_host_off = &cris_dma_off;
hwif->ide_dma_host_on = &cris_dma_on;
- hwif->ide_dma_off_quietly = &cris_dma_off;
+ hwif->dma_off_quietly = &cris_dma_off;
hwif->udma_four = 0;
hwif->ultra_mask = cris_ultra_mask;
hwif->mwdma_mask = 0x07; /* Multiword DMA 0-2 */
@@ -838,11 +841,6 @@ init_e100_ide (void)
cris_ide_set_speed(TYPE_UDMA, ATA_UDMA2_CYC, ATA_UDMA2_DVS, 0);
}
-static int cris_dma_off (ide_drive_t *drive)
-{
- return 0;
-}
-
static int cris_dma_on (ide_drive_t *drive)
{
return 0;
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1103,7 +1103,7 @@ static ide_startstop_t cdrom_read_intr (
if (dma) {
info->dma = 0;
if ((dma_error = HWIF(drive)->ide_dma_end(drive)))
- __ide_dma_off(drive);
+ ide_dma_off(drive);
}
if (cdrom_decode_status(drive, 0, &stat))
@@ -1699,7 +1699,7 @@ static ide_startstop_t cdrom_newpc_intr(
if (dma) {
if (dma_error) {
printk(KERN_ERR "ide-cd: dma error\n");
- __ide_dma_off(drive);
+ ide_dma_off(drive);
return ide_error(drive, "dma error", stat);
}
@@ -1825,7 +1825,7 @@ static ide_startstop_t cdrom_write_intr(
[PATCH 7/15] piix: cleanup
[PATCH] piix: cleanup
* disable DMA masks if no_piix_dma is set and remove now
not needed no_piix_dma_check from piix_config_drive_for_dma()
* there is no need to read register 0x55 in init_hwif_piix()
* move cable detection code to piix_cable_detect()
* remove unreachable 82371MX code from init_hwif_piix()
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/piix.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
Index: b/drivers/ide/pci/piix.c
===
--- a/drivers/ide/pci/piix.c
+++ b/drivers/ide/pci/piix.c
@@ -369,7 +369,7 @@ static int piix_config_drive_for_dma (id
* If no DMA speed was available or the chipset has DMA bugs
* then disable DMA and use PIO
*/
- if (!speed || no_piix_dma)
+ if (!speed)
return 0;
(void) piix_tune_chipset(drive, speed);
@@ -444,6 +444,16 @@ static unsigned int __devinit init_chips
return 0;
}
+static int __devinit piix_cable_detect(ide_hwif_t *hwif)
+{
+ struct pci_dev *dev = hwif->pci_dev;
+ u8 reg54h = 0, mask = hwif->channel ? 0xc0 : 0x30;
+
+ pci_read_config_byte(dev, 0x54, ®54h);
+
+ return (reg54h & mask) ? 1 : 0;
+}
+
/**
* init_hwif_piix - fill in the hwif for the PIIX
* @hwif: IDE interface
@@ -454,9 +464,6 @@ static unsigned int __devinit init_chips
static void __devinit init_hwif_piix(ide_hwif_t *hwif)
{
- u8 reg54h = 0, reg55h = 0, ata66 = 0;
- u8 mask = hwif->channel ? 0xc0 : 0x30;
-
#ifndef CONFIG_IA64
if (!hwif->irq)
hwif->irq = hwif->channel ? 15 : 14;
@@ -486,9 +493,6 @@ static void __devinit init_hwif_piix(ide
hwif->swdma_mask = 0x04;
switch(hwif->pci_dev->device) {
- case PCI_DEVICE_ID_INTEL_82371MX:
- hwif->mwdma_mask = 0x80;
- hwif->swdma_mask = 0x80;
case PCI_DEVICE_ID_INTEL_82371FB_0:
case PCI_DEVICE_ID_INTEL_82371FB_1:
case PCI_DEVICE_ID_INTEL_82371SB_1:
@@ -501,14 +505,14 @@ static void __devinit init_hwif_piix(ide
hwif->ultra_mask = 0x07;
break;
default:
- pci_read_config_byte(hwif->pci_dev, 0x54, ®54h);
- pci_read_config_byte(hwif->pci_dev, 0x55, ®55h);
- ata66 = (reg54h & mask) ? 1 : 0;
+ if (!hwif->udma_four)
+ hwif->udma_four = piix_cable_detect(hwif);
break;
}
- if (!(hwif->udma_four))
- hwif->udma_four = ata66;
+ if (no_piix_dma)
+ hwif->ultra_mask = hwif->mwdma_mask = hwif->swdma_mask = 0;
+
hwif->ide_dma_check = &piix_config_drive_xfer_rate;
if (!noautodma)
hwif->autodma = 1;
-
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 5/15] hpt34x: hpt34x_tune_chipset() (->speedproc) fix
[PATCH] hpt34x: hpt34x_tune_chipset() (->speedproc) fix
* remember to clear reg2 bits for the current device before setting mode
* remove no longer needed hpt34x_clear_chipset()
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/hpt34x.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
Index: b/drivers/ide/pci/hpt34x.c
===
--- a/drivers/ide/pci/hpt34x.c
+++ b/drivers/ide/pci/hpt34x.c
@@ -48,19 +48,6 @@ static u8 hpt34x_ratemask (ide_drive_t *
return 1;
}
-static void hpt34x_clear_chipset (ide_drive_t *drive)
-{
- struct pci_dev *dev = HWIF(drive)->pci_dev;
- u32 reg1 = 0, tmp1 = 0, reg2 = 0, tmp2 = 0;
-
- pci_read_config_dword(dev, 0x44, ®1);
- pci_read_config_dword(dev, 0x48, ®2);
- tmp1 = ((0x00 << (3*drive->dn)) | (reg1 & ~(7 << (3*drive->dn;
- tmp2 = (reg2 & ~(0x11 << drive->dn));
- pci_write_config_dword(dev, 0x44, tmp1);
- pci_write_config_dword(dev, 0x48, tmp2);
-}
-
static int hpt34x_tune_chipset (ide_drive_t *drive, u8 xferspeed)
{
struct pci_dev *dev = HWIF(drive)->pci_dev;
@@ -81,7 +68,7 @@ static int hpt34x_tune_chipset (ide_driv
pci_read_config_dword(dev, 0x44, ®1);
pci_read_config_dword(dev, 0x48, ®2);
tmp1 = ((lo_speed << (3*drive->dn)) | (reg1 & ~(7 << (3*drive->dn;
- tmp2 = ((hi_speed << drive->dn) | reg2);
+ tmp2 = ((hi_speed << drive->dn) | (reg2 & ~(0x11 << drive->dn)));
pci_write_config_dword(dev, 0x44, tmp1);
pci_write_config_dword(dev, 0x48, tmp2);
@@ -99,7 +86,6 @@ static int hpt34x_tune_chipset (ide_driv
static void hpt34x_tune_drive (ide_drive_t *drive, u8 pio)
{
pio = ide_get_best_pio_mode(drive, pio, 5, NULL);
- hpt34x_clear_chipset(drive);
(void) hpt34x_tune_chipset(drive, (XFER_PIO_0 + pio));
}
@@ -117,7 +103,6 @@ static int config_chipset_for_dma (ide_d
if (!(speed))
return 0;
- hpt34x_clear_chipset(drive);
(void) hpt34x_tune_chipset(drive, speed);
return ide_dma_enable(drive);
}
-
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/15] ide: convert ide_hwif_t.mmio into flag
[PATCH] ide: convert ide_hwif_t.mmio into flag
All users of ->mmio == 1 are gone so convert ->mmio into flag.
Noticed by Alan Cox.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/arm/icside.c |2 +-
drivers/ide/arm/rapide.c |2 +-
drivers/ide/cris/ide-cris.c |2 +-
drivers/ide/h8300/ide-h8300.c |2 +-
drivers/ide/ide-dma.c |8
drivers/ide/ide.c |5 ++---
drivers/ide/legacy/buddha.c |2 +-
drivers/ide/legacy/gayle.c|2 +-
drivers/ide/legacy/macide.c |2 +-
drivers/ide/legacy/q40ide.c |2 +-
drivers/ide/mips/au1xxx-ide.c |3 ++-
drivers/ide/mips/swarm.c |2 +-
drivers/ide/pci/sgiioc4.c |2 +-
drivers/ide/pci/siimage.c |3 ++-
drivers/ide/ppc/pmac.c|2 +-
include/linux/ide.h |2 +-
16 files changed, 22 insertions(+), 21 deletions(-)
Index: b/drivers/ide/arm/icside.c
===
--- a/drivers/ide/arm/icside.c
+++ b/drivers/ide/arm/icside.c
@@ -556,7 +556,7 @@ icside_setup(void __iomem *base, struct
* Ensure we're using MMIO
*/
default_hwif_mmiops(hwif);
- hwif->mmio = 2;
+ hwif->mmio = 1;
for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
hwif->hw.io_ports[i] = port;
Index: b/drivers/ide/arm/rapide.c
===
--- a/drivers/ide/arm/rapide.c
+++ b/drivers/ide/arm/rapide.c
@@ -46,7 +46,7 @@ rapide_locate_hwif(void __iomem *base, v
hwif->hw.io_ports[IDE_CONTROL_OFFSET] = (unsigned long)ctrl;
hwif->io_ports[IDE_CONTROL_OFFSET] = (unsigned long)ctrl;
hwif->hw.irq = hwif->irq = irq;
- hwif->mmio = 2;
+ hwif->mmio = 1;
default_hwif_mmiops(hwif);
return hwif;
Index: b/drivers/ide/cris/ide-cris.c
===
--- a/drivers/ide/cris/ide-cris.c
+++ b/drivers/ide/cris/ide-cris.c
@@ -795,7 +795,7 @@ init_e100_ide (void)
0, 0, cris_ide_ack_intr,
ide_default_irq(0));
ide_register_hw(&hw, &hwif);
- hwif->mmio = 2;
+ hwif->mmio = 1;
hwif->chipset = ide_etrax100;
hwif->tuneproc = &tune_cris_ide;
hwif->speedproc = &speed_cris_ide;
Index: b/drivers/ide/h8300/ide-h8300.c
===
--- a/drivers/ide/h8300/ide-h8300.c
+++ b/drivers/ide/h8300/ide-h8300.c
@@ -76,7 +76,7 @@ static inline void hwif_setup(ide_hwif_t
{
default_hwif_iops(hwif);
- hwif->mmio = 2;
+ hwif->mmio = 1;
hwif->OUTW = mm_outw;
hwif->OUTSW = mm_outsw;
hwif->INW = mm_inw;
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -565,7 +565,7 @@ int ide_dma_setup(ide_drive_t *drive)
}
/* PRD table */
- if (hwif->mmio == 2)
+ if (hwif->mmio)
writel(hwif->dmatable_dma, (void __iomem *)hwif->dma_prdtable);
else
outl(hwif->dmatable_dma, hwif->dma_prdtable);
@@ -815,7 +815,7 @@ int ide_release_dma(ide_hwif_t *hwif)
{
ide_release_dma_engine(hwif);
- if (hwif->mmio == 2)
+ if (hwif->mmio)
return 1;
else
return ide_release_iomio_dma(hwif);
@@ -884,9 +884,9 @@ static int ide_iomio_dma(ide_hwif_t *hwi
static int ide_dma_iobase(ide_hwif_t *hwif, unsigned long base, unsigned int
ports)
{
- if (hwif->mmio == 2)
+ if (hwif->mmio)
return ide_mapped_mmio_dma(hwif, base,ports);
- BUG_ON(hwif->mmio == 1);
+
return ide_iomio_dma(hwif, base, ports);
}
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -389,9 +389,8 @@ int ide_hwif_request_regions(ide_hwif_t
unsigned long addr;
unsigned int i;
- if (hwif->mmio == 2)
+ if (hwif->mmio)
return 0;
- BUG_ON(hwif->mmio == 1);
addr = hwif->io_ports[IDE_CONTROL_OFFSET];
if (addr && !hwif_request_region(hwif, addr, 1))
goto control_region_busy;
@@ -438,7 +437,7 @@ void ide_hwif_release_regions(ide_hwif_t
{
u32 i = 0;
- if (hwif->mmio == 2)
+ if (hwif->mmio)
return;
if (hwif->io_ports[IDE_CONTROL_OFFSET])
release_region(hwif->io_ports[IDE_CONTROL_OFFSET], 1);
Index: b/drivers/ide/legacy/buddha.c
===
--- a/drivers/ide/legacy/buddha.c
+++ b/drivers/ide/legacy/buddha.c
@@ -215,7 +215,7 @@ f
[PATCH 1/15] ACPI support for IDE devices
[PATCH] ACPI support for IDE devices
This patch implements ACPI integration for generic IDE devices.
The ACPI spec mandates that some methods are called during suspend and
resume. And consequently there most modern Laptops cannot resume
properly without it.
According to the spec, we should call '_GTM' (Get Timing) upon suspend
to store the current IDE adapter settings.
Upon resume we should call '_STM' (Set Timing) to initialize the
adapter with the stored settings; afterwards '_GTF' (Get Taskfile)
should be called which returns a buffer with some IDE initialisation
commands. Those commands should be passed to the drive.
There are two module params which control the behaviour of this patch:
'ide=noacpi'
Do not call any ACPI methods (Disables any ACPI method calls)
'ide=acpigtf'
Enable execution of _GTF methods upon resume.
Has no effect if 'ide=noacpi' is set.
'ide=acpionboot'
Enable execution of ACPI methods during boot.
This might be required on some machines if 'ide=acpigtf' is
selected as some machines modify the _GTF information
depending on the drive identification passed down with _STM.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/Kconfig |7
drivers/ide/Makefile|1
drivers/ide/ide-acpi.c | 696
drivers/ide/ide-probe.c |3
drivers/ide/ide.c | 36 ++
include/linux/ide.h | 27 +
6 files changed, 770 insertions(+)
Index: b/drivers/ide/Kconfig
===
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -271,6 +271,13 @@ config BLK_DEV_IDESCSI
If both this SCSI emulation and native ATAPI support are compiled
into the kernel, the native support will be used.
+config BLK_DEV_IDEACPI
+ bool "IDE ACPI support"
+ depends on ACPI
+ ---help---
+ Implement ACPI support for generic IDE devices. On modern
+ machines ACPI support is required to properly handle ACPI S3 states.
+
config IDE_TASK_IOCTL
bool "IDE Taskfile Access"
help
Index: b/drivers/ide/Makefile
===
--- a/drivers/ide/Makefile
+++ b/drivers/ide/Makefile
@@ -22,6 +22,7 @@ ide-core-$(CONFIG_BLK_DEV_IDEPCI) += set
ide-core-$(CONFIG_BLK_DEV_IDEDMA) += ide-dma.o
ide-core-$(CONFIG_PROC_FS) += ide-proc.o
ide-core-$(CONFIG_BLK_DEV_IDEPNP) += ide-pnp.o
+ide-core-$(CONFIG_BLK_DEV_IDEACPI) += ide-acpi.o
# built-in only drivers from arm/
ide-core-$(CONFIG_IDE_ARM) += arm/ide_arm.o
Index: b/drivers/ide/ide-acpi.c
===
--- /dev/null
+++ b/drivers/ide/ide-acpi.c
@@ -0,0 +1,696 @@
+/*
+ * ide-acpi.c
+ * Provides ACPI support for IDE drives.
+ *
+ * Copyright (C) 2005 Intel Corp.
+ * Copyright (C) 2005 Randy Dunlap
+ * Copyright (C) 2006 SUSE Linux Products GmbH
+ * Copyright (C) 2006 Hannes Reinecke
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REGS_PER_GTF 7
+struct taskfile_array {
+ u8 tfa[REGS_PER_GTF]; /* regs. 0x1f1 - 0x1f7 */
+};
+
+struct GTM_buffer {
+ u32 PIO_speed0;
+ u32 DMA_speed0;
+ u32 PIO_speed1;
+ u32 DMA_speed1;
+ u32 GTM_flags;
+};
+
+struct ide_acpi_drive_link {
+ ide_drive_t *drive;
+ acpi_handle obj_handle;
+ u8 idbuff[512];
+};
+
+struct ide_acpi_hwif_link {
+ ide_hwif_t *hwif;
+ acpi_handle obj_handle;
+ struct GTM_buffergtm;
+ struct ide_acpi_drive_link master;
+ struct ide_acpi_drive_link slave;
+};
+
+#undef DEBUGGING
+/* note: adds function name and KERN_DEBUG */
+#ifdef DEBUGGING
+#define DEBPRINT(fmt, args...) \
+ printk(KERN_DEBUG "%s: " fmt, __FUNCTION__, ## args)
+#else
+#define DEBPRINT(fmt, args...) do {} while (0)
+#endif /* DEBUGGING */
+
+extern int ide_noacpi;
+extern int ide_noacpitfs;
+extern int ide_noacpionboot;
+
+/**
+ * ide_get_dev_handle - finds acpi_handle and PCI device.function
+ * @dev: device to locate
+ * @handle: returned acpi_handle for @dev
+ * @pcidevfn: return PCI device.func for @dev
+ *
+ * Returns the ACPI object handle to the corresponding PCI device.
+ *
+ * Returns 0 on success, <0 on error.
+ */
+static int ide_get_dev_handle(struct device *dev, acpi_handle *handle,
+ acpi_integer *pcidevfn)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ unsigned int bus, devnum, func;
+ acpi_integer addr;
+ acpi_handle dev_handle;
+ struct acpi_buffer buffer = {
[PATCH 0/15] IDE quilt tree updated
Hi, I've just updated IDE quilt tree: http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/ New patches: * IDE driver for Delkin/Lexar/ASKA/Workbit/etc. CardBus CF adapters (Mark Lord <[EMAIL PROTECTED]>) * ACPI support for IDE devices (Hannes Reinecke <[EMAIL PROTECTED]>) * ide: unregister ide-pnp driver on unload (Tejun Heo <[EMAIL PROTECTED]>) * via82cxxx/pata_via: correct PCI_DEVICE_ID_VIA_SATA_EIDE ID and add support for CX700 and 8237S (Josepch Chan <[EMAIL PROTECTED]>) * rework of the code selecting the best DMA transfer mode (~500 LOCs less) (me) * some misc fixes/cleanups (me) diffstat: 68 files changed, 3310 insertions(+), 2495 deletions(-) I'm sending only new patches for review/comments. If you would like to see the full quilt series (or to get combined patch) against 2.6.20-rc5, they are available here: http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/releases/ Thanks, Bart - 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: NTFS
> On Fri, 19 Jan 2007 00:27:17 +0100 (CET) Grzegorz Kulewski <[EMAIL > PROTECTED]> wrote: > On Thu, 18 Jan 2007, Andrew Morton wrote: > >> On Thu, 18 Jan 2007 22:38:13 + Christoph Hellwig <[EMAIL PROTECTED]> > >> wrote: > >> On Thu, Jan 18, 2007 at 02:35:06PM -0800, Andrew Morton wrote: > Cool. That means ->put_inode is gone in -mm. Andrew, what are the > plans for sending the patches to make the ext2 preallocation work > like ext3 to Linus? > >>> > >>> Cautious. I'm not sure that we ever want to merge them, really - ext2 is > >>> more a reference filesystem than a real one nowadays, and making it more > >>> complex detracts from that. > >> > >> The again while the old preallocation code might be simpler it's also > >> utterly > >> braindead and we need to make sure no one is going to copy this :) > > > > Good point ;) > > Are you refering to that particular implementation in ext2 or to the > whole method od doing it implemented currently in ext2? It's a patch which cross-ports ext3's block-reservation code into ext2. > When can I read about it (description of the new method/implementation in > ext3 and why is it better) some more? Hard. google(ext3 reservations) is a starting point. - 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: EDAC chipkill messages
Orion Poplawski wrote: Can someone please explain to me what these mean? EDAC k8 MC1: general bus error: participating processor(local node origin), time-out(no timeout) memory transaction type(generic read), mem or i/o(mem access), cache level(generic) EDAC MC1: CE page 0xfbf6f, offset 0x4d0, grain 8, syndrome 0xc8f4, row 1, channel 0, label "": k8_edac EDAC MC1: CE - no information available: k8_edac Error Overflow set EDAC k8 MC1: extended error code: ECC chipkill x4 error Thanks! Sounds like you're having some memory ECC errors.. some Memtest86, etc. runs may be in order. You may be able to figure out from this info what DIMM is having the problem. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: SATA exceptions with 2.6.20-rc5
I heard from Larry Walton who was apparently seeing this problem as well. He tried my recent "sata_nv: cleanup ADMA error handling v2" patch and originally thought it fixed the problem, but it turned out to only make it happen less often. I wouldn't expect that patch to have an effect on this problem. If it seems to reduce the frequency that would tend to be further evidence of some kind of timing-related issue where the code change just happens to make a difference. I'll see if I can come up with a debug patch for people having this problem to try, which prints out when a flush command is issued and what interrupts happen when a flush is pending. There is one important difference between ADMA and non-ADMA mode for non-DMA commands like flushes, which didn't come to mind before: ADMA mode uses MMIO registers on the controller whereas non-ADMA mode uses legacy IO registers. Posted write flushing is a concern with MMIO registers but not with PIO, the libata core is supposed to handle this but maybe it doesn't in some case(s). In fact, just looking at libata-sff.c there's this comment on the ata_exec_command_mmio function: * FIXME: missing write posting for 400nS delay enforcement That seems a bit suspicious.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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/
Linux 2.6.16.38-rc2
Security fixes since 2.6.16.37: - CVE-2006-4814: Fix incorrect user space access locking in mincore() - CVE-2006-5173: i386: save/restore eflags in context switch - CVE-2006-5749: Call init_timer() for ISDN PPP CCP reset state timer - CVE-2006-5755: x86_64: Don't leak NT bit into next task - CVE-2006-5757/CVE-2006-6060: grow_buffers() infinite loop fix - CVE-2006-5823: corrupted cramfs filesystems cause kernel oops - CVE-2006-6053: handle ext3 directory corruption better - CVE-2006-6054: ext2: skip pages past number of blocks in ext2_find_entry - CVE-2006-6056: hfs_fill_super returns success even if no root inode - CVE-2006-6106: Bluetooth: Add packet size checks for CAPI messages Patch location: ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/ git tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git Changes since 2.6.16.38-rc1: Adrian Bunk (1): Linux 2.6.16.38-rc2 Paolo 'Blaisorblade' Giarrusso (1): UML: fix the MODE_TT compilation YOSHIFUJI Hideaki (1): [IPV6] Fix joining all-node multicast group. Makefile |2 +- arch/um/sys-i386/unmap.c | 11 +++ arch/um/sys-x86_64/unmap.c | 11 +++ net/ipv6/addrconf.c|4 net/ipv6/mcast.c |6 -- 5 files changed, 19 insertions(+), 15 deletions(-) - 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: Questions on PCI express AER support in HBA driver
On Thu, Jan 18, 2007 at 11:46:21AM -0800, Allexio Ju wrote: > Hi, > > I've got some questions on supporting PCI Express AER in Linux HBA drivers. > BTW, I'm developing SCSI HBA driver. [...] > What else does SCSI LLD driver need to changed? There are several scsi controllers that handle pci error recovery. For example, look at drivers/scsi/ipr.c, search for struct pci_error_handlers. The callback routines there deal with reseting the driver after an error has been found. I've posted patches in the past for the symbios driver; I suppose it is time to clean them up and resubmit them again; they are not in the kernel yet. I recently posted patches for the Emulex lpfc fibre channel scsi card, google for the subject line "[PATCH] lpfc: add PCI error recovery support" to see what the patch looks like. All of this work was done on powerpc systems. I have only a vague idea of how this works on PC-class Intel platforms. --linas - 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] rdmsr_on_cpu, wrmsr_on_cpu
Andi Kleen wrote: HOWEVER -- and this is where things get gnarly -- the CPUID and MSR drivers would really like to be able to execute CPUID, WRMSR and RDMSR with the entire GPR register set (except the stack pointer) pre-set and post-captured, since it's highly likely that there are going to be nonstandard MSRs and CPUID levels (already witness Intel breaking the CPUID architecture by introducing %ecx dependencies.) That looks like such a specialized requirement that I would suggest you keep that in the drivers. The interface for most users would be just too ugly It would, but rather than having the paravirtualization interfaces duplicate out of control, we could/should implement the less generic features in terms of the more generic, above the pvz layer. -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: NTFS
On Thu, 18 Jan 2007, Andrew Morton wrote: On Thu, 18 Jan 2007 22:38:13 + Christoph Hellwig <[EMAIL PROTECTED]> wrote: On Thu, Jan 18, 2007 at 02:35:06PM -0800, Andrew Morton wrote: Cool. That means ->put_inode is gone in -mm. Andrew, what are the plans for sending the patches to make the ext2 preallocation work like ext3 to Linus? Cautious. I'm not sure that we ever want to merge them, really - ext2 is more a reference filesystem than a real one nowadays, and making it more complex detracts from that. The again while the old preallocation code might be simpler it's also utterly braindead and we need to make sure no one is going to copy this :) Good point ;) Are you refering to that particular implementation in ext2 or to the whole method od doing it implemented currently in ext2? When can I read about it (description of the new method/implementation in ext3 and why is it better) some more? Thanks, Grzegorz Kulewski - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thursday 18 January 2007 22:00, Erik Andersen wrote: > I just tried again and while using iommu=soft does avoid the > corruption problem, as with previous kernels with 2.6.20-rc5 > using iommu=soft still makes my pcHDTV HD5500 DVB cards not work. This must be some separate bug and needs to be fixed anyways. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rdmsr_on_cpu, wrmsr_on_cpu
> HOWEVER -- and this is where things get gnarly -- the CPUID and MSR > drivers would really like to be able to execute CPUID, WRMSR and RDMSR > with the entire GPR register set (except the stack pointer) pre-set and > post-captured, since it's highly likely that there are going to be > nonstandard MSRs and CPUID levels (already witness Intel breaking the > CPUID architecture by introducing %ecx dependencies.) That looks like such a specialized requirement that I would suggest you keep that in the drivers. The interface for most users would be just too ugly -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Print number of oopses in Sysrq-P output
On Friday 19 January 2007 04:05, Alexey Dobriyan wrote:
> @@ -292,9 +292,11 @@ __setup("idle=", idle_setup);
> void show_regs(struct pt_regs * regs)
> {
> unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
> + extern int die_counter;
externs should always be in some .h file, never in a sub scope.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20-rc5] Gigaset ISDN driver error handling fixes (resend)
My apologies if anyone is getting this more than once. I still haven't
seen it appear on the list after two attempts, so I'm sending it again,
this time through a different server.
Subject: [PATCH] Gigaset ISDN driver error handling fixes
From: Tilman Schmidt <[EMAIL PROTECTED]>
Fix several flaws in the error handling of the Siemens Gigaset ISDN
driver, including one that would cause an Oops when connecting more
than one device of the same type.
Signed-off-by: Tilman Schmidt <[EMAIL PROTECTED]>
---
--- linux-2.6.20-rc5-orig/drivers/isdn/gigaset/common.c 2007-01-15
00:50:22.0 +0100
+++ linux-2.6.20-rc5-work/drivers/isdn/gigaset/common.c 2007-01-17
11:45:44.0 +0100
@@ -356,16 +356,17 @@ static struct cardstate *alloc_cs(struct
{
unsigned long flags;
unsigned i;
- static struct cardstate *ret = NULL;
+ struct cardstate *ret = NULL;
spin_lock_irqsave(&drv->lock, flags);
for (i = 0; i < drv->minors; ++i) {
if (!(drv->flags[i] & VALID_MINOR)) {
- drv->flags[i] = VALID_MINOR;
- ret = drv->cs + i;
- }
- if (ret)
+ if (try_module_get(drv->owner)) {
+ drv->flags[i] = VALID_MINOR;
+ ret = drv->cs + i;
+ }
break;
+ }
}
spin_unlock_irqrestore(&drv->lock, flags);
return ret;
@@ -376,6 +377,8 @@ static void free_cs(struct cardstate *cs
unsigned long flags;
struct gigaset_driver *drv = cs->driver;
spin_lock_irqsave(&drv->lock, flags);
+ if (drv->flags[cs->minor_index] & VALID_MINOR)
+ module_put(drv->owner);
drv->flags[cs->minor_index] = 0;
spin_unlock_irqrestore(&drv->lock, flags);
}
@@ -579,7 +582,7 @@ static struct bc_state *gigaset_initbcs(
} else if ((bcs->skb = dev_alloc_skb(SBUFSIZE + HW_HDR_LEN)) != NULL)
skb_reserve(bcs->skb, HW_HDR_LEN);
else {
- warn("could not allocate skb\n");
+ warn("could not allocate skb");
bcs->inputstate |= INS_skip_frame;
}
@@ -632,17 +635,25 @@ struct cardstate *gigaset_initcs(struct
int i;
gig_dbg(DEBUG_INIT, "allocating cs");
- cs = alloc_cs(drv);
- if (!cs)
- goto error;
+ if (!(cs = alloc_cs(drv))) {
+ err("maximum number of devices exceeded");
+ return NULL;
+ }
+ mutex_init(&cs->mutex);
+ mutex_lock(&cs->mutex);
+
gig_dbg(DEBUG_INIT, "allocating bcs[0..%d]", channels - 1);
cs->bcs = kmalloc(channels * sizeof(struct bc_state), GFP_KERNEL);
- if (!cs->bcs)
+ if (!cs->bcs) {
+ err("out of memory");
goto error;
+ }
gig_dbg(DEBUG_INIT, "allocating inbuf");
cs->inbuf = kmalloc(sizeof(struct inbuf_t), GFP_KERNEL);
- if (!cs->inbuf)
+ if (!cs->inbuf) {
+ err("out of memory");
goto error;
+ }
cs->cs_init = 0;
cs->channels = channels;
@@ -654,8 +665,6 @@ struct cardstate *gigaset_initcs(struct
spin_lock_init(&cs->ev_lock);
cs->ev_tail = 0;
cs->ev_head = 0;
- mutex_init(&cs->mutex);
- mutex_lock(&cs->mutex);
tasklet_init(&cs->event_tasklet, &gigaset_handle_event,
(unsigned long) cs);
@@ -684,8 +693,10 @@ struct cardstate *gigaset_initcs(struct
for (i = 0; i < channels; ++i) {
gig_dbg(DEBUG_INIT, "setting up bcs[%d].read", i);
- if (!gigaset_initbcs(cs->bcs + i, cs, i))
+ if (!gigaset_initbcs(cs->bcs + i, cs, i)) {
+ err("could not allocate channel %d data", i);
goto error;
+ }
}
++cs->cs_init;
@@ -720,8 +731,10 @@ struct cardstate *gigaset_initcs(struct
make_valid(cs, VALID_ID);
++cs->cs_init;
gig_dbg(DEBUG_INIT, "setting up hw");
- if (!cs->ops->initcshw(cs))
+ if (!cs->ops->initcshw(cs)) {
+ err("could not allocate device specific data");
goto error;
+ }
++cs->cs_init;
@@ -743,8 +756,8 @@ struct cardstate *gigaset_initcs(struct
mutex_unlock(&cs->mutex);
return cs;
-error: if (cs)
- mutex_unlock(&cs->mutex);
+error:
+ mutex_unlock(&cs->mutex);
gig_dbg(DEBUG_INIT, "failed");
gigaset_freecs(cs);
return NULL;
@@ -1040,7 +1053,6 @@ void gigaset_freedriver(struct gigaset_d
spin_unlock_irqrestore(&driver_lock, flags);
gigaset_if_freedriver(drv);
- module_put(drv->owner);
kfree(drv->cs);
kfree(drv->flags);
@@ -1072,10 +1084,6 @@ struct gigaset_driver *gigaset_initdrive
if (!drv)
return NUL
EDAC chipkill messages
Can someone please explain to me what these mean? EDAC k8 MC1: general bus error: participating processor(local node origin), time-out(no timeout) memory transaction type(generic read), mem or i/o(mem access), cache level(generic) EDAC MC1: CE page 0xfbf6f, offset 0x4d0, grain 8, syndrome 0xc8f4, row 1, channel 0, label "": k8_edac EDAC MC1: CE - no information available: k8_edac Error Overflow set EDAC k8 MC1: extended error code: ECC chipkill x4 error Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.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: NTFS
> On Thu, 18 Jan 2007 22:38:13 + Christoph Hellwig <[EMAIL PROTECTED]> > wrote: > On Thu, Jan 18, 2007 at 02:35:06PM -0800, Andrew Morton wrote: > > > Cool. That means ->put_inode is gone in -mm. Andrew, what are the > > > plans for sending the patches to make the ext2 preallocation work > > > like ext3 to Linus? > > > > Cautious. I'm not sure that we ever want to merge them, really - ext2 is > > more a reference filesystem than a real one nowadays, and making it more > > complex detracts from that. > > The again while the old preallocation code might be simpler it's also utterly > braindead and we need to make sure no one is going to copy this :) Good point ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc5: known unfixed regressions
On Wed, Jan 17, 2007 at 14:43:29 +1100, David Chinner wrote: ... > > > Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS) > > > References : http://lkml.org/lkml/2007/1/5/308 > > > Submitter : Sami Farin <[EMAIL PROTECTED]> > > > Handled-By : David Chinner <[EMAIL PROTECTED]> > > > Status : problem is being discussed > > > > I'm at LCA and been having laptop dramas so the fix is being held up at this > > point. I and trying to test a change right now that adds an optional unmap > > to truncate_inode_pages_range as XFS needs, in some circumstances, to toss > > out dirty pages (with dirty bufferheads) and hence requires truncate > > semantics > > that are currently missing unmap calls. > > > > Semi-untested patch attached below. > > The patch has run XFSQA for about 24 hours now on my test rig without > triggering any problems. I have also ran this for 24h (in patched 2.6.19.2) and no problems noticed :) -- Do what you love because life is too short for anything else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] msr.c: use smp_call_function_single()
Alexey Dobriyan wrote: It will execute rdmsr and wrmsr only on the cpu we need. Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> This is good, but a bit incomplete; see other message recently posted to LKML. Since this affects paravirtualization I want to minimize the number of changes. -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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Friday 19 January 2007 08:57, Chip Coldwell wrote: > But it still might be a reasonable thing to do to test the theory that > the problem is cache coherency across the graphics aperture, even if > it isn't a long-term solution for the problem. I suspect it would disturb timing so badly that it might hide the original problem. If that is true then adding udelays might hide it too. Ok i guess you could test with a UP kernel. There change_page_attr should be much cheaper because it doesn't need to IPI to other CPUs. Also use a .2.6.20-rc* kernel that uses CLFLUSH in there, not WBINVD which is also very costly. Anyways I guess we can just wait what the hardware people figure out. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problems with latest smbfs changes on 2.4.34 and security backports
On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote: > Dann, do you still have your samba server ready to try to reproduce this > problem ? Also, there are very suspect lines right there in the patch : I can set it up again, hopefully have some feedback by tomorrow. -- dann frazier - 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: NTFS
On Thu, Jan 18, 2007 at 02:35:06PM -0800, Andrew Morton wrote: > > Cool. That means ->put_inode is gone in -mm. Andrew, what are the > > plans for sending the patches to make the ext2 preallocation work > > like ext3 to Linus? > > Cautious. I'm not sure that we ever want to merge them, really - ext2 is > more a reference filesystem than a real one nowadays, and making it more > complex detracts from that. The again while the old preallocation code might be simpler it's also utterly braindead and we need to make sure no one is going to copy 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/
Re: [PATCH 2.6.20-rc5 4/4] sys_futex64 : allows 64bit futexes
On Thu, Jan 18, 2007 at 08:45:56AM +0100, Ingo Molnar wrote: > actually, we have a big multiplexer there already, so it's only > symmetric. Nothing is served by doing it half-assed. I raised the issue > of the multiplexer back when the first futex API was merged (years ago), > and it was rejected. Now whether you like it or not we've got to live > with that decision. You are certainly free to introduce a patchset with > a completely new set of syscall vectors to demultiplex all futex APIs, > but to just start a half-done demultiplexing makes zero sense. dding new syscalls for the old functionality is totally pointless as we have to support the old entry point forever anyway. And new code is using the new entry point, so let's get that right. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc5 4/4] sys_futex64 : allows 64bit futexes
On Thu, Jan 18, 2007 at 08:45:56AM +0100, Ingo Molnar wrote:
> include/asm-i386/futex.h:
>
> switch (cmp) {
> case FUTEX_OP_CMP_EQ: ret = (oldval == cmparg); break;
> case FUTEX_OP_CMP_NE: ret = (oldval != cmparg); break;
> case FUTEX_OP_CMP_LT: ret = (oldval < cmparg); break;
> case FUTEX_OP_CMP_GE: ret = (oldval >= cmparg); break;
> case FUTEX_OP_CMP_LE: ret = (oldval <= cmparg); break;
> case FUTEX_OP_CMP_GT: ret = (oldval > cmparg); break;
> default: ret = -ENOSYS;
> }
>
> Pierre correctly matched the existing style.
Old code doing things wrong is no excuse for new code doing the same
mistake. Much better send a patch to fix up the previous unreadable
mess aswell. Then again some indentation fixups won't help that much
to make futrsx not the totally unreadable spaghetti code it's now ;-)
-
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] Kwatch: kernel watchpoints using CPU debug registers
On Thu, Jan 18, 2007 at 08:31:59AM +0100, Ingo Molnar wrote: > > * Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > I'll be happy to move this over to the utrace setting, once it is > > > merged. Do you think it would be better to include the current > > > version of kwatch now or to wait for utrace? > > > > > > Roland, is there a schedule for when you plan to get utrace into > > > -mm? > > > > Even if it goes into mainline soon we'll need a lot of time for all > > architectures to catch up, so I think kwatch should definitely comes > > first. > > i disagree. Utrace is a once-in-a-lifetime opportunity to clean up the > /huge/ ptrace mess. Ptrace has been a very large PITA, for many, many > years, precisely because it was done in the 'oh, lets get this feature > added first, think about it later' manner. Roland's work is a large > logistical undertaking and we should not make it more complex than it > is. Once it's in we can add debugging features ontop of that. To me work > that cleans up existing mess takes precedence before work that adds to > the mess. Utrace doesn't provide any kind of watchpoint infrastructure now, and utrace will take a lot of time to get ready for inclusion, mostly because it really needs asll the arch maintainers to help out (and various not so easy core fixes aswell). I'm all for merging utrace, and I wish we'd be much further into the merging process already, but blocking mostly unrelated functionality for it is more than dumb. > ps. please fix your mailer to not emit those silly Mail-Followup-To > headers! It collapses To: and Cc: lines into one huge unnecessary To: > line. This header is absolutely intentation as far too many folks seem to randomly drop to or cc lines on mailing lists. and of course it's alsmost esential on lists with braindead reply to list policies (e.g. Debian) - 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: Ext3 mounted as ext2 but journal still in effect.
>> You were right, even after making the changes, it seems to be >> telling lies: >> >> # mount >> /dev/hda2 on / type ext2 (rw,usrquota) Roughly speaking: /etc/mtab shows you what you said to mount. /proc/mounts shows what the current kernel state is. These may differ greatly. For all filesystems mounted by you using mount(8), a line is added to /etc/mtab, where the contents of that line is related to the given mount command, but not to what the kernel did. For the root filesystem, mount(8) writes an initial line in /etc/mtab taken from /etc/fstab. Again the information is from you, not from the kernel. >> # dmesg | grep 'Kernel command' >> Kernel command line: ro root=/dev/hda2 rootfstype=ext2 > ... >> /dev/root / ext3 rw 0 0 It would be a bad bug if the kernel mounted its root filesystem with a type different from the type given in "rootfstype=". But I see you use an initrd, and there can be all kinds of commands there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 2.6.21] ehca: ehca_uverbs.c: refactor ehca_mmap() for better readability
On Thu, Jan 18, 2007 at 10:56:01AM -0800, Roland Dreier wrote: > I've kind of lost the plot here. How does this patch fit in with the > previous series of patches you posted? Does it replace them or go on > top of them? It's a cleanup ontop of the actual fix. - 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: NTFS
On Thu, Jan 18, 2007 at 10:25:50AM +, Anton Altaparmakov wrote: > Hi Linus, please pull from > > git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs-2.6.git > > This NTFS update fixes the deadlock reported by Sergey Vlasov in > ntfs_put_inode(). > > The fix was to remove ntfs_put_inode() which should make Christoph > Hellwig (CC:-ed) very happy as he wanted to get rid of ->put_inode > altogether a while ago and NTFS stopped him from doing so and now the > way should be clear for it to happen... (-: Cool. That means ->put_inode is gone in -mm. Andrew, what are the plans for sending the patches to make the ext2 preallocation work like ext3 to 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: configfs: return value for drop_item()/make_item()?
On Thu, Jan 18, 2007 at 01:50:20PM +0100, Michael Noisternig wrote:
> did you get my last reply? I hope you still consider it to be worthwhile
> to comment on. :)
I didn't get it, I'm sorry. I wonder what happened. Did you
send it to me, linux-kernel, or both (both is preferred).
> And sorry for your double-reception of my last mail, I was unwittingly
> ignoring your follow-up-to setting.
I filter dupes by Message-ID :-)
> Original Message
> Subject: Re: configfs: return value for drop_item()/make_item()?
> From: Michael Noisternig
> Date: Tue Jan 16 2007 - 11:40:50 EST
>
> I fully agree with the idea of configfs not being allowed to destroy
> user-created objects. OTOH, while configfs is described as a filesystem
> for user-created objects under user control, compared to sysfs as a
> filesystem for kernel-created objects under kernel control, configfs
> _does_ permit kernel-created objects in a limited way (by filling in
> struct config_group->default_groups), and these objects can only be
> destroyed again by the kernel, and not by the user.
They are not created by a kernel action. They are created as a
direct result of a user action. The user must mkdir(2) the parent in
the chain. Only then do these default_groups appear. Contrast sysfs,
where filesystem structures can be added at any time, from any codepath,
via the sysfs in-kernel API.
> As such I don't understand fully why one doesn't want to merge sysfs and
> configfs (let's call it sysconfs for now) in such a way that it allows
> _both_ user- and kernel-created objects, with user-objects only allowed
> to be destroyed by the user and kernel-objects only by the kernel.
The programming interface is very, very different. Check out
historical messages on this topic:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg95708.html
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg95711.html
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg95714.html
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg95717.html
In addition, userspace would have no idea at any given time
whether they were dealing with kernel managed objects or user managed
ones. So you'd confuse both the driver programmer *and* the userspace
programmer.
> One problem with configfs is that there is too little control over how
> many other objects a particular object may contain. IOW, an object may
> either contain
> - n sub-objects (n entries in ->default_groups), or
> - n..inf sub-objects (n entries in ->default_groups,
> ->make_item()/make_group() supplied)
Clearly you can have 0..N sub-objects by returning NULL from
successive ->make_item() calls, but as you point out, that results in
ENOMEM, not the cleanest error for this case.
> Often however, what you want is that an object may contain 0 or 1 other
> objects. If ->make_item()/make_group() would allow returning a
> meaningful error code the kernel could deny creation of a 2nd object
> other than by pretending to be out of memory.
You make a reasonable case that ENOMEM isn't always the error
you want, but perhaps we can add a better umbrella error code? I'm wary
of introducing PTR_ERR() or any other complexity if we don't _need_ it.
I'm all for thoughts on possibly compromises.
> For another example, and directly related to above link, suppose having
> an object with a number of attributes, one of them being called 'type'.
> Dependent on the value of 'type' this object may contain a particular
> type of sub-object (with type-dependent attributes). E.g. 'type' may be
> empty | 'a' | 'b' | 'ab', then dependent on this there should be 0 or 1
> directories called 'a', and 0 or 1 directories called 'b'. Doing it this
> way means that while the user decides what sub-directory/-ies the object
> has, he does not create them (directly) - it is the kernel which creates
> the object, and as such it is also the kernel only which is permitted to
> destroy the object again - by the user writing a different value to the
> 'type' attribute (or clearing it). sysconfs could solve this.
This is precisely what configfs is designed to forbid. The
kernel does not, ever, create configfs objects on its own. It does it
as a result of userspace action. If you want the following:
# cd mydir
# ls -l
-rw-r--r-- 1 root root0 2006-12-28 07:11 type
# echo 'ab' > type
# ls -l mydir
drwxr-xr-x 2 root root 4096 2007-01-08 14:21 ab
-rw-r--r-- 1 root root2 2007-01-08 14:21 type
# echo '' > type
# ls -l mydir
-rw-r--r-- 1 root root0 2007-01-08 14:22 type
you're never going to get it from configfs. You should be using sysfs.
> Above problem could be solved in a different manner within the realms of
> configfs by not having a 'type' attribute, but the other way around
> defining the (implicit) type of the object by the user creating certain
> sub-directories ('a' and 'b'). I.
Re: [PATCH] rdmsr_on_cpu, wrmsr_on_cpu
Alexey Dobriyan wrote:
There was OpenVZ specific bug rendering some cpufreq drivers unusable
on SMP. In short, when cpufreq code thinks it confined itself to
needed cpu by means of set_cpus_allowed() to execute rdmsr, some
"virtual cpu" feature can migrate process to anywhere. This triggers
bugons and does wrong things in general.
This got fixed by introducing rdmsr_on_cpu and wrmsr_on_cpu executing
rdmsr and wrmsr on given physical cpu by means of
smp_call_function_single().
Dave Jones mentioned cpufreq might be not only user of rdmsr_on_cpu()
and wrmsr_on_cpu(), so I'm going to put them into arch/i386/lib/
(after patch gets some more testing othen than compile and UP run)
The CPUID and MSR drivers need something like this.
HOWEVER -- and this is where things get gnarly -- the CPUID and MSR
drivers would really like to be able to execute CPUID, WRMSR and RDMSR
with the entire GPR register set (except the stack pointer) pre-set and
post-captured, since it's highly likely that there are going to be
nonstandard MSRs and CPUID levels (already witness Intel breaking the
CPUID architecture by introducing %ecx dependencies.)
So I would like to see:
/* It probably makes sense to use the same structure on x86 and
x86-64 */
struct x86_gpr_regs {
u64 rax, rcx, rdx, rbx;
u64 rsp, rbp, rsi, rdi;
u64 r8, r9, r10, r11;
u64 r12, r13, r14, r15;
};
void rdmsr_on_cpu(unsigned cpu,
const struct x86_gpr_regs *in, struct x86_gpr_regs *out);
void wrmsr_on_cpu(unsigned cpu,
const struct x86_gpr_regs *in, struct x86_gpr_regs *out);
void cpuid_on_cpu(unsigned cpu,
const struct x86_gpr_regs *in, struct x86_gpr_regs *out);
This requires assembly to do in the nonparavirtualized case, of course.
I'll try to get that written up in the next day or so.
-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: Kernel headers - linux-atm userspace build broken by recent change; __be16 undefined
it might be that the userspace code shouldnt be including if_arp.h. can you try that instead? In message <[EMAIL PROTECTED]>,Andrew Walrond writes: >Don't know exactly when this change went in, but it's not in 2.6.18.3 >and is in 2.6.19.2+ > > $ diff linux/include/linux/if_arp.h linux-2.6/include/linux/if_arp.h >133,134c133,134 >< unsigned short ar_hrd; /* format of hardware address */ >< unsigned short ar_pro; /* format of protocol address */ >--- > > __be16 ar_hrd; /* format of hardware address */ > > __be16 ar_pro; /* format of protocol address */ >137c137 >< unsigned short ar_op; /* ARP opcode (command) */ >--- > > __be16 ar_op; /* ARP opcode (command) */ > > >This causes the linux-atm userspace compile to fail like this: > >In file included from arp.c:19: >/usr/include/linux/if_arp.h:133: error: expected >specifier-qualifier-list before '__be16' > >I guess if_arp.h needs to include include/linux/byteorder/big_endian.h? > >Andrew Walrond - 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: uClibc - waitid()
You're asking the wrong list. Try the uClibc list at uclibc.org. glibc and uClibc provide C APIs to kernel system calls. uClibc doesn't implement all features that glibc supports - there are several kernel APIs that uClibc doesn't expose. Ask the uClibc folk for advice. -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development Sue Alfano wrote: Can anyone help with this? We have an application that runs fine on our linux workstations, but will not compile to run on a new target. This application is using the WNOWAIT option for the waitid() function. When the source file is compiled for the target using powerpc-uclibc-gcc, it fails because WNOWAIT is not defined. The best that I can tell, waitid() doesn't appear to be supported in uClibc (version 0.9.27). I checked the latest version on the uClibc site, but it doesn't appear to have been considered for inclusion. I looked in glibc (versions 2.4, 2.3.5, and 2.0.6), but could only find emulated/stub/pseudo implementations for waitid(). The Linux man page for waitid() states that it's supported since the 2.6.9 kernel release. At this point I'm not sure where the waitid() source code and WNOWAIT definition is suppose to be (kernel, uClibc, glibc, gcc) or what version of wait.h is actually being used (there appears to be many versions floating around on the machine). Since I'm way off in the weeds on this I was hoping somebody with more Linux experience than me (that would be just about anyone) might be able to shed some light on this problem or point me in a more constructive direction. Do you have any information as to the status of the waitid() support? It must have been available at one time since it's running on my linux workstation (Linux version 2.6.15-1.2054_FC5smp ([EMAIL PROTECTED]) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #1 SMP Tue Mar 14 16:05:46 EST2006). Was there a reason why it wasn't added to uClibc (other than the size issue)? Is there a recommended way to deal with applications that are using waitid() with the WNOWAIT option? Thanks for any assistance, Sue - 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: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi. On Thu, 2007-01-18 at 12:51 +0100, Andreas Mohr wrote: [...] > All in all intel-agp code semi-shattered my universe. > I didn't expect to find all these issues in rather important core code > for a wide-spread chipset vendor - it doesn't even log an > "unhandled chipset: resuming may fail, please report!" message > in the resume handler in case of a missing chipset check > (although it may be debatable whether people are able to see this message > at all). Now that's a really good idea, and simple to do too. For some time I've been thinking of a sysfs entry that could list for you all the drivers in the tree. Perhaps that, combined with your idea (as well as implementing your idea separately) would be helpful? > However since the new AGP code was a heroic refactoring effort > it's understandable that there are some remaining issues. > > Given the myriads of resume issues we experience in general, > it may be wise to do something as simple as a code review of *all* > relevant code no matter how "complete" we expect each driver to be... > (one could e.g. start with reviewing all other AGP chipset drivers). Yes, we really need to get around to checking what drivers do suspend and resume properly for both S3 and S4, and prodding the authors where necessary. Regards, Nigel - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, 18 Jan 2007, Andi Kleen wrote: The Northbridge guarantees coherency over the aperture, but only if the caching attributes match. That's interesting. Makes sense, I suppose. You would need to change_page_attr() every kernel address that is mapped into the IOMMU to use an uncached aperture. AGP does this, but the frequency of mapping for the IOMMU is much higher and it would be prohibitively costly unfortunately. But it still might be a reasonable thing to do to test the theory that the problem is cache coherency across the graphics aperture, even if it isn't a long-term solution for the problem. In the past we saw corruptions from such conflicts, so this is more than just theory. I suspect you traded a more easy to trigger corruption with a more subtle one. Yup. That was the inspiration for the script. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - 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 patch] drivers/net/irda/vlsi_ir.{h,c}: remove kernel 2.4 code
This patch removes kernel 2.4 compatibility code.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/irda/vlsi_ir.c | 16
drivers/net/irda/vlsi_ir.h | 33 -
2 files changed, 8 insertions(+), 41 deletions(-)
--- linux-2.6.20-rc4-mm1/drivers/net/irda/vlsi_ir.h.old 2007-01-18
21:50:43.0 +0100
+++ linux-2.6.20-rc4-mm1/drivers/net/irda/vlsi_ir.h 2007-01-18
21:53:54.0 +0100
@@ -41,39 +41,6 @@
#define PCI_CLASS_SUBCLASS_MASK0x
#endif
-/* in recent 2.5 interrupt handlers have non-void return value */
-#ifndef IRQ_RETVAL
-typedef void irqreturn_t;
-#define IRQ_NONE
-#define IRQ_HANDLED
-#define IRQ_RETVAL(x)
-#endif
-
-/* some stuff need to check kernelversion. Not all 2.5 stuff was present
- * in early 2.5.x - the test is merely to separate 2.4 from 2.5
- */
-#include
-
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
-
-/* PDE() introduced in 2.5.4 */
-#ifdef CONFIG_PROC_FS
-#define PDE(inode) ((inode)->i_private)
-#endif
-
-/* irda crc16 calculation exported in 2.5.42 */
-#define irda_calc_crc16(fcs,buf,len) (GOOD_FCS)
-
-/* we use this for unified pci device name access */
-#define PCIDEV_NAME(pdev) ((pdev)->name)
-
-#else /* 2.5 or later */
-
-/* whatever we get from the associated struct device - bus:slot:dev.fn id */
-#define PCIDEV_NAME(pdev) (pci_name(pdev))
-
-#endif
-
/* */
/* non-standard PCI registers */
--- linux-2.6.20-rc4-mm1/drivers/net/irda/vlsi_ir.c.old 2007-01-18
21:53:58.0 +0100
+++ linux-2.6.20-rc4-mm1/drivers/net/irda/vlsi_ir.c 2007-01-18
21:54:56.0 +0100
@@ -166,7 +166,7 @@
unsigned i;
seq_printf(seq, "\n%s (vid/did: %04x/%04x)\n",
- PCIDEV_NAME(pdev), (int)pdev->vendor, (int)pdev->device);
+ pci_name(pdev), (int)pdev->vendor, (int)pdev->device);
seq_printf(seq, "pci-power-state: %u\n", (unsigned)
pdev->current_state);
seq_printf(seq, "resources: irq=%u / io=0x%04x / dma_mask=0x%016Lx\n",
pdev->irq, (unsigned)pci_resource_start(pdev, 0), (unsigned
long long)pdev->dma_mask);
@@ -1401,7 +1401,7 @@
if (vlsi_start_hw(idev))
IRDA_ERROR("%s: failed to restart hw - %s(%s) unusable!\n",
- __FUNCTION__, PCIDEV_NAME(idev->pdev), ndev->name);
+ __FUNCTION__, pci_name(idev->pdev), ndev->name);
else
netif_start_queue(ndev);
}
@@ -1643,7 +1643,7 @@
pdev->current_state = 0; /* hw must be running now */
IRDA_MESSAGE("%s: IrDA PCI controller %s detected\n",
-drivername, PCIDEV_NAME(pdev));
+drivername, pci_name(pdev));
if ( !pci_resource_start(pdev,0)
|| !(pci_resource_flags(pdev,0) & IORESOURCE_IO) ) {
@@ -1728,7 +1728,7 @@
pci_set_drvdata(pdev, NULL);
- IRDA_MESSAGE("%s: %s removed\n", drivername, PCIDEV_NAME(pdev));
+ IRDA_MESSAGE("%s: %s removed\n", drivername, pci_name(pdev));
}
#ifdef CONFIG_PM
@@ -1748,7 +1748,7 @@
if (!ndev) {
IRDA_ERROR("%s - %s: no netdevice \n",
- __FUNCTION__, PCIDEV_NAME(pdev));
+ __FUNCTION__, pci_name(pdev));
return 0;
}
idev = ndev->priv;
@@ -1759,7 +1759,7 @@
pdev->current_state = state.event;
}
else
- IRDA_ERROR("%s - %s: invalid suspend request %u ->
%u\n", __FUNCTION__, PCIDEV_NAME(pdev), pdev->current_state, state.event);
+ IRDA_ERROR("%s - %s: invalid suspend request %u ->
%u\n", __FUNCTION__, pci_name(pdev), pdev->current_state, state.event);
up(&idev->sem);
return 0;
}
@@ -1787,7 +1787,7 @@
if (!ndev) {
IRDA_ERROR("%s - %s: no netdevice \n",
- __FUNCTION__, PCIDEV_NAME(pdev));
+ __FUNCTION__, pci_name(pdev));
return 0;
}
idev = ndev->priv;
@@ -1795,7 +1795,7 @@
if (pdev->current_state == 0) {
up(&idev->sem);
IRDA_WARNING("%s - %s: already resumed\n",
-__FUNCTION__, PCIDEV_NAME(pdev));
+__FUNCTION__, pci_name(pdev));
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] fs/unionfs/: possible cleanups
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote: >... > - Added the unionfs filesystem driver as git-unionfs.patch (Josef "Jeff" > Sipek <[EMAIL PROTECTED]>) >... > Changes since 2.6.20-rc3-mm1: >... > git-unionfs.patch >... > git trees >... Let's start with a small exercise: Consider sparse tells you about a global function: warning: symbol 'unionfs_d_revalidate_wrap' was not declared. Should it be static? I'll give three possible solutions, spot the one that is always wrong: 1. make the function static 2. add a prototype in a header file 3. add a prototype in the C file If you need a hint, look at what the patch below removes... <-- snip --> This patch contains the following possible cleanups: - every function should #include the headers containing the prototypes of it's global functions - static functions in C files shouldn't be marked "inline", gcc should know best when to inline them - make needlessly global code static - #if 0 the following unused global function: - stale_inode.c: is_stale_inode() Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- fs/unionfs/commonfops.c |6 +-- fs/unionfs/copyup.c | 59 +-- fs/unionfs/dentry.c | 11 +-- fs/unionfs/file.c| 17 +++ fs/unionfs/inode.c | 19 fs/unionfs/main.c|4 +- fs/unionfs/rdstate.c |2 - fs/unionfs/sioq.c|2 - fs/unionfs/sioq.h|1 fs/unionfs/stale_inode.c |9 +++-- fs/unionfs/union.h | 13 11 files changed, 60 insertions(+), 83 deletions(-) --- linux-2.6.20-rc4-mm1/fs/unionfs/union.h.old 2007-01-18 21:02:45.0 +0100 +++ linux-2.6.20-rc4-mm1/fs/unionfs/union.h 2007-01-18 21:32:42.0 +0100 @@ -241,11 +241,6 @@ /* replicates the directory structure upto given dentry in given branch */ extern struct dentry *create_parents(struct inode *dir, struct dentry *dentry, int bindex); -struct dentry *create_parents_named(struct inode *dir, struct dentry *dentry, - const char *name, int bindex); - -/* check if two branches overlap */ -extern int is_branch_overlap(struct dentry *dent1, struct dentry *dent2); /* partial lookup */ extern int unionfs_partial_lookup(struct dentry *dentry); @@ -265,10 +260,6 @@ /* copies a dentry from dbstart to newbindex branch */ extern int copyup_dentry(struct inode *dir, struct dentry *dentry, int bstart, int new_bindex, struct file **copyup_file, loff_t len); -extern int copyup_named_dentry(struct inode *dir, struct dentry *dentry, - int bstart, int new_bindex, const char *name, - int namelen, struct file **copyup_file, - loff_t len); extern int remove_whiteouts(struct dentry *dentry, struct dentry *hidden_dentry, int bindex); @@ -325,9 +316,6 @@ int unionfs_ioctl_queryfile(struct file *file, unsigned int cmd, unsigned long arg); -/* Verify that a branch is valid. */ -int check_branch(struct nameidata *nd); - #ifdef CONFIG_UNION_FS_XATTR /* Extended attribute functions. */ extern void *unionfs_xattr_alloc(size_t size, size_t limit); @@ -395,7 +383,6 @@ } struct dentry *unionfs_lookup_backend(struct dentry *dentry, struct nameidata *nd, int lookupmode); -int is_stale_inode(struct inode *inode); void make_stale_inode(struct inode *inode); #define IS_SET(sb, check_flag) ((check_flag) & MOUNT_FLAG(sb)) --- linux-2.6.20-rc4-mm1/fs/unionfs/copyup.c.old2007-01-18 21:03:05.0 +0100 +++ linux-2.6.20-rc4-mm1/fs/unionfs/copyup.c2007-01-18 21:35:33.0 +0100 @@ -18,6 +18,14 @@ #include "union.h" +static int copyup_named_dentry(struct inode *dir, struct dentry *dentry, + int bstart, int new_bindex, const char *name, + int namelen, struct file **copyup_file, + loff_t len); +static struct dentry *create_parents_named(struct inode *dir, + struct dentry *dentry, + const char *name, int bindex); + #ifdef CONFIG_UNION_FS_XATTR /* copyup all extended attrs for a given dentry */ static int copyup_xattrs(struct dentry *old_hidden_dentry, @@ -129,10 +137,10 @@ * if the object being copied up is a regular file, the file is only created, * the contents have to be copied up separately */ -static inline int __copyup_ndentry(struct dentry *old_hidden_dentry, - struct dentry *new_hidden_dentry, - struct dentry *new_hidden_parent_dentry, - char *symbuf) +static int __copyup_ndentry(struct dentry *old_hidden_dentry, + struct dentry *new_hidden_d
[2.6 patch] arch/i386/kernel/alternative.c should #include
Every file should include the headers containing the prototypes for it's global functions. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 4 Jan 2007 --- linux-2.6.20-rc2-mm1/arch/i386/kernel/alternative.c.old 2007-01-03 23:13:18.0 +0100 +++ linux-2.6.20-rc2-mm1/arch/i386/kernel/alternative.c 2007-01-03 23:13:32.0 +0100 @@ -4,6 +4,7 @@ #include #include #include +#include static int no_replacement= 0; static int smp_alt_once = 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] proper prototype for tosh_smm()
This patch adds a proper prototype for tosh_smm() to include/linux/toshiba.h Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 4 Jan 2007 drivers/video/neofb.c |1 - include/linux/toshiba.h |2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.20-rc2-mm1/include/linux/toshiba.h.old2007-01-03 23:03:10.0 +0100 +++ linux-2.6.20-rc2-mm1/include/linux/toshiba.h2007-01-03 23:03:25.0 +0100 @@ -33,4 +33,6 @@ unsigned int edi __attribute__ ((packed)); } SMMRegisters; +int tosh_smm(SMMRegisters *regs); + #endif --- linux-2.6.20-rc2-mm1/drivers/video/neofb.c.old 2007-01-03 23:03:32.0 +0100 +++ linux-2.6.20-rc2-mm1/drivers/video/neofb.c 2007-01-03 23:03:39.0 +0100 @@ -66,7 +66,6 @@ #include #ifdef CONFIG_TOSHIBA #include -extern int tosh_smm(SMMRegisters *regs); #endif #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
> On Thu, 18 Jan 2007 16:03:38 + Ralf Baechle <[EMAIL PROTECTED]> wrote: > On Fri, Jan 19, 2007 at 12:23:46AM +0900, Atsushi Nemoto wrote: > > > CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size > > might result in allocation failure for the reserving itself on some > > platforms (for example typical 32bit MIPS). Make it (and > > CARDBUS_IO_SIZE too) customizable for such platforms. > > Patch looks technically ok to me, so feel free to add my Acked-by: line. > > The grief I have with this sort of patch is that this kind of detailed > technical knowledge should not be required by a mortal configuring the > Linux kernel. > Yes, it does rater suck. A boot option/module parameter would be better. - 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] faster vgetcpu using sidt (take 2)
> let me know what you think... thanks. It's ok, although I would like to have the file in a separate directory. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Vectored AIO breakage for sockets and pipes ?
I'm not sure what the best way to fix this is. One option is to always make a copy of the iovec and pass that down. Any other thoughts ? Can we use this as another motivation to introduce an iovec container struct instead of passing a raw iov/seg? The transition could turn hand-rolled functions like pipe_iov_copy_to_user() into functions that this iovec struct API provides. I don't know if this would specifically help aio_rw_vect_retry() to know if it should advance the iovec on behalf of its callee who returned positive result codes. Maybe it could use the API to discover a case where ret < size && cur_pos(iov_struct) == initial_pos(iov_struct) via some iovec pos query before rw_op is called? Or maybe the introduction of the API could normalize where the responsibility of advancing the iovec lies. That might be a bit much. Just talkin' here. - z - 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: "obsolete" versus "deprecated", and a new config option?
Robert P. J. Day wrote: that's entirely a judgment call on the part of the code's maintainer. if something is both obsolete and broken, then make it depend on *both* OBSOLETE and BROKEN if you want. no big deal. Yup. OBSOLETE = might be broken, no one is planning to maintain it. BROKEN = known to be broken. They're by and large orthogonal. -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/
[PATCH 5/5] eCryptfs: convert lookup_one_len() to lookup_one_len_nd()
Call the new lookup_one_len_nd() rather than lookup_one_len(). This
fixes an oops when stacked on NFS.
Note that there are still some issues with eCryptfs on NFS having to
do with directory deletion (I'm not getting an oops, just an -EBUSY).
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index 9135718..cf02a66 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -283,7 +283,9 @@ static struct dentry *ecryptfs_lookup(st
int rc = 0;
struct dentry *lower_dir_dentry;
struct dentry *lower_dentry;
+ struct dentry *dentry_save;
struct vfsmount *lower_mnt;
+ struct vfsmount *mnt_save;
char *encoded_name;
unsigned int encoded_namelen;
struct ecryptfs_crypt_stat *crypt_stat = NULL;
@@ -311,9 +313,13 @@ static struct dentry *ecryptfs_lookup(st
}
ecryptfs_printk(KERN_DEBUG, "encoded_name = [%s]; encoded_namelen "
"= [%d]\n", encoded_name, encoded_namelen);
- lower_dentry = lookup_one_len(encoded_name, lower_dir_dentry,
- encoded_namelen - 1);
+ dentry_save = nd->dentry;
+ mnt_save = nd->mnt;
+ lower_dentry = lookup_one_len_nd(encoded_name, lower_dir_dentry,
+(encoded_namelen - 1), nd);
kfree(encoded_name);
+ nd->mnt = mnt_save;
+ nd->dentry = dentry_save;
if (IS_ERR(lower_dentry)) {
ecryptfs_printk(KERN_ERR, "ERR from lower_dentry\n");
rc = PTR_ERR(lower_dentry);
--
1.4.2.4
-
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/5] eCryptfs: add flush_dcache_page() calls
On Tue, Jan 09, 2007 at 02:42:03PM -0800, Andrew Morton wrote:
> On Tue, 9 Jan 2007 16:23:37 -0600
> Michael Halcrow <[EMAIL PROTECTED]> wrote:
> > + set_header_info(page_virt, crypt_stat);
> > + }
>
> The kernel must always run flush_dcache_page() after modifying a pagecache
> page by hand. Please review all of ecryptfs for this.
Call flush_dcache_page() after modifying a pagecache by hand.
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
fs/ecryptfs/mmap.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
b77b1e2cbda1dfa6cc0925bca790701261771c43
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 2a7ba51..59ec097 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -238,7 +238,9 @@ int ecryptfs_do_readpage(struct file *fi
lower_page_data = (char *)kmap_atomic(lower_page, KM_USER1);
memcpy(page_data, lower_page_data, PAGE_CACHE_SIZE);
kunmap_atomic(lower_page_data, KM_USER1);
+ flush_dcache_page(lower_page);
kunmap_atomic(page_data, KM_USER0);
+ flush_dcache_page(page);
rc = 0;
out:
if (likely(lower_page))
@@ -322,6 +324,7 @@ static int ecryptfs_readpage(struct file
set_header_info(page_virt, crypt_stat);
}
kunmap_atomic(page_virt, KM_USER0);
+ flush_dcache_page(page);
if (rc) {
printk(KERN_ERR "Error reading xattr "
"region\n");
@@ -382,6 +385,7 @@ static int fill_zeros_to_end_of_page(str
memset((page_virt + end_byte_in_page), 0,
(PAGE_CACHE_SIZE - end_byte_in_page));
kunmap_atomic(page_virt, KM_USER0);
+ flush_dcache_page(page);
out:
return 0;
}
@@ -456,6 +460,7 @@ static int ecryptfs_write_inode_size_to_
header_virt = kmap_atomic(header_page, KM_USER0);
memcpy(header_virt, &file_size, sizeof(u64));
kunmap_atomic(header_virt, KM_USER0);
+ flush_dcache_page(header_page);
rc = lower_a_ops->commit_write(lower_file, header_page, 0, 8);
if (rc < 0)
ecryptfs_printk(KERN_ERR, "Error commiting header page "
@@ -742,6 +747,7 @@ int write_zeros(struct file *file, pgoff
tmp_page_virt = kmap_atomic(tmp_page, KM_USER0);
memset(((char *)tmp_page_virt + start), 0, num_zeros);
kunmap_atomic(tmp_page_virt, KM_USER0);
+ flush_dcache_page(tmp_page);
rc = ecryptfs_commit_write(file, tmp_page, start, start + num_zeros);
if (rc < 0) {
ecryptfs_printk(KERN_ERR, "Error attempting to write zero's "
--
1.3.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] eCryptfs: open-code flag checking and manipulation
Open-code flag checking and manipulation.
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
Signed-off-by: Trevor Highland <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c | 37 +++--
fs/ecryptfs/debug.c |6 +++---
fs/ecryptfs/ecryptfs_kernel.h |3 ---
fs/ecryptfs/file.c| 17 +++--
fs/ecryptfs/inode.c | 14 ++
fs/ecryptfs/keystore.c| 32 ++--
fs/ecryptfs/mmap.c|8
7 files changed, 49 insertions(+), 68 deletions(-)
3cb9652018a1be5ae400bb9bb105bb5685fbc302
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index ac4ea8d..e03113c 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -207,7 +207,7 @@ ecryptfs_init_crypt_stat(struct ecryptfs
mutex_init(&crypt_stat->cs_mutex);
mutex_init(&crypt_stat->cs_tfm_mutex);
mutex_init(&crypt_stat->cs_hash_tfm_mutex);
- ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_STRUCT_INITIALIZED);
+ crypt_stat->flags |= ECRYPTFS_STRUCT_INITIALIZED;
}
/**
@@ -305,8 +305,7 @@ static int encrypt_scatterlist(struct ec
int rc = 0;
BUG_ON(!crypt_stat || !crypt_stat->tfm
- || !ECRYPTFS_CHECK_FLAG(crypt_stat->flags,
- ECRYPTFS_STRUCT_INITIALIZED));
+ || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED));
if (unlikely(ecryptfs_verbosity > 0)) {
ecryptfs_printk(KERN_DEBUG, "Key size [%d]; key:\n",
crypt_stat->key_size);
@@ -485,7 +484,7 @@ #define ECRYPTFS_PAGE_STATE_WRITTEN 3
lower_inode = ecryptfs_inode_to_lower(ctx->page->mapping->host);
inode_info = ecryptfs_inode_to_private(ctx->page->mapping->host);
crypt_stat = &inode_info->crypt_stat;
- if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED)) {
+ if (!(crypt_stat->flags & ECRYPTFS_ENCRYPTED)) {
rc = ecryptfs_copy_page_to_lower(ctx->page, lower_inode,
ctx->param.lower_file);
if (rc)
@@ -617,7 +616,7 @@ int ecryptfs_decrypt_page(struct file *f
crypt_stat = &(ecryptfs_inode_to_private(
page->mapping->host)->crypt_stat);
lower_inode = ecryptfs_inode_to_lower(page->mapping->host);
- if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED)) {
+ if (!(crypt_stat->flags & ECRYPTFS_ENCRYPTED)) {
rc = ecryptfs_do_readpage(file, page, page->index);
if (rc)
ecryptfs_printk(KERN_ERR, "Error attempting to copy "
@@ -884,7 +883,7 @@ int ecryptfs_compute_root_iv(struct ecry
BUG_ON(crypt_stat->iv_bytes > MD5_DIGEST_SIZE);
BUG_ON(crypt_stat->iv_bytes <= 0);
- if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID)) {
+ if (!(crypt_stat->flags & ECRYPTFS_KEY_VALID)) {
rc = -EINVAL;
ecryptfs_printk(KERN_WARNING, "Session key not valid; "
"cannot generate root IV\n");
@@ -901,8 +900,7 @@ int ecryptfs_compute_root_iv(struct ecry
out:
if (rc) {
memset(crypt_stat->root_iv, 0, crypt_stat->iv_bytes);
- ECRYPTFS_SET_FLAG(crypt_stat->flags,
- ECRYPTFS_SECURITY_WARNING);
+ crypt_stat->flags |= ECRYPTFS_SECURITY_WARNING;
}
return rc;
}
@@ -910,7 +908,7 @@ out:
static void ecryptfs_generate_new_key(struct ecryptfs_crypt_stat *crypt_stat)
{
get_random_bytes(crypt_stat->key, crypt_stat->key_size);
- ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID);
+ crypt_stat->flags |= ECRYPTFS_KEY_VALID;
ecryptfs_compute_root_iv(crypt_stat);
if (unlikely(ecryptfs_verbosity > 0)) {
ecryptfs_printk(KERN_DEBUG, "Generated new session key:\n");
@@ -950,7 +948,7 @@ static void ecryptfs_set_default_crypt_s
ecryptfs_set_default_sizes(crypt_stat);
strcpy(crypt_stat->cipher, ECRYPTFS_DEFAULT_CIPHER);
crypt_stat->key_size = ECRYPTFS_DEFAULT_KEY_BYTES;
- ECRYPTFS_CLEAR_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID);
+ crypt_stat->flags &= ~(ECRYPTFS_KEY_VALID);
crypt_stat->file_version = ECRYPTFS_FILE_VERSION;
crypt_stat->mount_crypt_stat = mount_crypt_stat;
}
@@ -990,8 +988,8 @@ int ecryptfs_new_file_context(struct den
if (mount_crypt_stat->global_auth_tok) {
ecryptfs_printk(KERN_DEBUG, "Initializing context for new "
"file using mount_crypt_stat\n");
- ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED);
- ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID);
+ crypt_stat->flags |= ECRYPTFS_ENCRYPTED;
+ crypt_stat->flags |= ECRYPTFS_KEY_VALID;
[PATCH 2/5] eCryptfs: convert kmap() to kmap_atomic()
On Tue, Jan 09, 2007 at 02:42:03PM -0800, Andrew Morton wrote:
> On Tue, 9 Jan 2007 16:23:37 -0600
> Michael Halcrow <[EMAIL PROTECTED]> wrote:
>
> > + page_virt = (char *)kmap(page);
>
> Do we _have_ to use kmap here? It's slow and theoretically
> deadlocky. kmap_atomic() is much preferred.
>
> Can the other kmap() calls in ecryptfs be converted?
Replace kmap() with kmap_atomic(). Reduce the number of kmaps and the
amount of time that kmaps are held.
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
Signed-off-by: Trevor Highland <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c |8 +--
fs/ecryptfs/ecryptfs_kernel.h |4 -
fs/ecryptfs/mmap.c| 121 -
3 files changed, 39 insertions(+), 94 deletions(-)
fd04da707b2164272acc05a56ff4b71786aad011
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index fbb62c8..ac4ea8d 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -429,10 +429,10 @@ static int ecryptfs_read_in_page(struct
goto out;
}
} else {
- rc = ecryptfs_grab_and_map_lower_page(lower_page, NULL,
- lower_inode,
- lower_page_idx);
- if (rc) {
+ *lower_page = grab_cache_page(lower_inode->i_mapping,
+ lower_page_idx);
+ if (!(*lower_page)) {
+ rc = -EINVAL;
ecryptfs_printk(
KERN_ERR, "Error attempting to grab and map "
"lower page with index [0x%.16x]; rc = [%d]\n",
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 859d31b..0e38d0d 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -527,10 +527,6 @@ int ecryptfs_copy_page_to_lower(struct p
struct file *lower_file);
int ecryptfs_do_readpage(struct file *file, struct page *page,
pgoff_t lower_page_index);
-int ecryptfs_grab_and_map_lower_page(struct page **lower_page,
-char **lower_virt,
-struct inode *lower_inode,
-unsigned long lower_page_index);
int ecryptfs_writepage_and_release_lower_page(struct page *lower_page,
struct inode *lower_inode,
struct writeback_control *wbc);
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 94bcabf..6f167f1 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -234,22 +234,11 @@ int ecryptfs_do_readpage(struct file *fi
goto out;
}
wait_on_page_locked(lower_page);
- page_data = (char *)kmap(page);
- if (!page_data) {
- rc = -ENOMEM;
- ecryptfs_printk(KERN_ERR, "Error mapping page\n");
- goto out;
- }
- lower_page_data = (char *)kmap(lower_page);
- if (!lower_page_data) {
- rc = -ENOMEM;
- ecryptfs_printk(KERN_ERR, "Error mapping page\n");
- kunmap(page);
- goto out;
- }
+ page_data = (char *)kmap_atomic(page, KM_USER0);
+ lower_page_data = (char *)kmap_atomic(lower_page, KM_USER1);
memcpy(page_data, lower_page_data, PAGE_CACHE_SIZE);
- kunmap(lower_page);
- kunmap(page);
+ kunmap_atomic(lower_page_data, KM_USER1);
+ kunmap_atomic(page_data, KM_USER0);
rc = 0;
out:
if (likely(lower_page))
@@ -325,19 +314,14 @@ static int ecryptfs_readpage(struct file
if (page->index < num_pages_in_header_region) {
char *page_virt;
- page_virt = (char *)kmap(page);
- if (!page_virt) {
- rc = -ENOMEM;
- printk(KERN_ERR "Error mapping page\n");
- goto out;
- }
+ page_virt = (char *)kmap_atomic(page, KM_USER0);
memset(page_virt, 0, PAGE_CACHE_SIZE);
if (page->index == 0) {
rc = ecryptfs_read_xattr_region(
page_virt, file->f_path.dentry);
set_header_info(page_virt, crypt_stat);
}
- kunmap(page);
+ kunmap_atomic(page_virt, KM_USER0);
if (rc) {
printk(KERN_ERR "Error reading xattr "
[PATCH 1/5] eCryptfs: convert f_op->write() to vfs_write()
Andrew Morton wrote:
> On Tue, 9 Jan 2007 16:22:55 -0600
> Michael Halcrow <[EMAIL PROTECTED]> wrote:
>
> > + lower_file->f_op->write(lower_file, (char __user *)page_virt,
> > + PAGE_CACHE_SIZE, &lower_file->f_pos);
>
> hm. sys_write() takes a local copy of f_pos and writes that back
> into the struct file.It does this so that two concurrent write()
> callers don't make a mess of f_pos, and of the file contents.
>
> Perhaps ecryptfs should be calling vfs_write()?
>
> That way we'd also get the fsnotify notifications, which ecryptfs
> presently appears to have subverted.
Convert direct calls to f_op->write() into calls to vfs_write().
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c | 27 ++-
fs/ecryptfs/inode.c |2 +-
2 files changed, 23 insertions(+), 6 deletions(-)
b91d05b02335e38e18ffb87de6127b80bfe66dd7
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 8fbc38c..fbb62c8 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1346,24 +1346,41 @@ int ecryptfs_write_metadata_to_contents(
mm_segment_t oldfs;
int current_header_page;
int header_pages;
+ ssize_t size;
+ int rc = 0;
lower_file->f_pos = 0;
oldfs = get_fs();
set_fs(get_ds());
- lower_file->f_op->write(lower_file, (char __user *)page_virt,
- PAGE_CACHE_SIZE, &lower_file->f_pos);
+ size = vfs_write(lower_file, (char __user *)page_virt, PAGE_CACHE_SIZE,
+&lower_file->f_pos);
+ if (size < 0) {
+ rc = (int)size;
+ printk(KERN_ERR "Error attempting to write lower page; "
+ "rc = [%d]\n", rc);
+ set_fs(oldfs);
+ goto out;
+ }
header_pages = ((crypt_stat->header_extent_size
* crypt_stat->num_header_extents_at_front)
/ PAGE_CACHE_SIZE);
memset(page_virt, 0, PAGE_CACHE_SIZE);
current_header_page = 1;
while (current_header_page < header_pages) {
- lower_file->f_op->write(lower_file, (char __user *)page_virt,
- PAGE_CACHE_SIZE, &lower_file->f_pos);
+ size = vfs_write(lower_file, (char __user *)page_virt,
+PAGE_CACHE_SIZE, &lower_file->f_pos);
+ if (size < 0) {
+ rc = (int)size;
+ printk(KERN_ERR "Error attempting to write lower page; "
+ "rc = [%d]\n", rc);
+ set_fs(oldfs);
+ goto out;
+ }
current_header_page++;
}
set_fs(oldfs);
- return 0;
+out:
+ return rc;
}
int ecryptfs_write_metadata_to_xattr(struct dentry *ecryptfs_dentry,
diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index bbc1b4f..7d33917 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -201,7 +201,7 @@ static int ecryptfs_initialize_file(stru
lower_dentry->d_name.name);
inode = ecryptfs_dentry->d_inode;
crypt_stat = &ecryptfs_inode_to_private(inode)->crypt_stat;
- lower_flags = ((O_CREAT | O_WRONLY | O_TRUNC) & O_ACCMODE) | O_RDWR;
+ lower_flags = ((O_CREAT | O_TRUNC) & O_ACCMODE) | O_RDWR;
#if BITS_PER_LONG != 32
lower_flags |= O_LARGEFILE;
#endif
--
1.3.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel headers - linux-atm userspace build broken by recent change; __be16 undefined
Don't know exactly when this change went in, but it's not in 2.6.18.3 and is in 2.6.19.2+ $ diff linux/include/linux/if_arp.h linux-2.6/include/linux/if_arp.h 133,134c133,134 < unsigned short ar_hrd; /* format of hardware address */ < unsigned short ar_pro; /* format of protocol address */ --- > __be16 ar_hrd; /* format of hardware address */ > __be16 ar_pro; /* format of protocol address */ 137c137 < unsigned short ar_op; /* ARP opcode (command) */ --- > __be16 ar_op; /* ARP opcode (command) */ This causes the linux-atm userspace compile to fail like this: In file included from arp.c:19: /usr/include/linux/if_arp.h:133: error: expected specifier-qualifier-list before '__be16' I guess if_arp.h needs to include include/linux/byteorder/big_endian.h? Andrew Walrond - 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] 9p: update documentation regarding server applications
Update the documentation to cover using Inferno as a server for 9p and to include information about spfs (a stable single-threaded stand-alone 9p server). Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]> --- Documentation/filesystems/9p.txt | 20 +--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index 43b89c2..be45fe3 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt @@ -73,8 +73,22 @@ OPTIONS RESOURCES = -The Linux version of the 9p server is now maintained under the npfs project -on sourceforge (http://sourceforge.net/projects/npfs). +Our current recommendation is to use Inferno (http://www.vitanuova.com/inferno) +as the 9p server. You can start a 9p server under Inferno by issuing the +following command: + ; styxlisten -A tcp!*!564 export '#U*' + +The -A specifies an unauthenticated export. The 564 is the port # (you may +have to choose a higher port number if running as a normal user). The '#U*' +specifies exporting the root of the Linux name space. You may specify a +subset of the namespace by extending the path: '#U*'/tmp would just export +/tmp. For more information, see the Inferno manual pages covering styxlisten +and export. + +A Linux version of the 9p server is now maintained under the npfs project +on sourceforge (http://sourceforge.net/projects/npfs). There is also a +more stable single-threaded version of the server (named spfs) available from +the same CVS repository. There are user and developer mailing lists available through the v9fs project on sourceforge (http://sourceforge.net/projects/v9fs). @@ -96,5 +110,5 @@ STATUS The 2.6 kernel support is working on PPC and x86. -PLEASE USE THE SOURCEFORGE BUG-TRACKER TO REPORT PROBLEMS. +PLEASE USE THE KERNEL BUGZILLA TO REPORT PROBLEMS. (http://bugzilla.kernel.org) -- 1.5.0.rc1.gdf1b-dirty - 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 PULL] More hwmon updates for 2.6.20
Hi Linus, Please pull the late hwmon subsystem updates for Linux 2.6.20 from: git://jdelvare.pck.nerim.net/jdelvare-2.6 hwmon-for-linus They fix several problems that were found in the new w83793 hardware monitoring driver. Documentation/hwmon/w83793 |8 +-- drivers/hwmon/hwmon-vid.c |2 - drivers/hwmon/w83793.c | 127 ++-- 3 files changed, 113 insertions(+), 24 deletions(-) --- Gong Jun: hwmon/w83793: Remove the description of AMDSI and update the voltage formula hwmon/w83793: Ignore disabled temperature channels hwmon/w83793: Hide invalid VID readings Jean Delvare: hwmon: Fix the VRD 11 decoding Rudolf Marek: hwmon/w83793: Fix the fan input detection Thanks, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] arch/arm26/kernel/entry.S: remove dead code
CONFIG_ALIGNMENT_TRAP is never set on arm26. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/arm26/kernel/entry.S | 10 -- 1 file changed, 10 deletions(-) --- linux-2.6.20-rc4-mm1/arch/arm26/kernel/entry.S.old 2007-01-18 22:08:51.0 +0100 +++ linux-2.6.20-rc4-mm1/arch/arm26/kernel/entry.S 2007-01-18 22:09:12.0 +0100 @@ -245,11 +245,6 @@ zero_fp get_scno -#ifdef CONFIG_ALIGNMENT_TRAP - ldr ip, __cr_alignment - ldr ip, [ip] - mcr p15, 0, ip, c1, c0 @ update control register -#endif enable_irqs ip str r4, [sp, #-S_OFF]! @ push fifth arg @@ -299,11 +294,6 @@ b ret_slow_syscall .align 5 -#ifdef CONFIG_ALIGNMENT_TRAP - .type __cr_alignment, #object -__cr_alignment: - .word cr_alignment -#endif .type sys_call_table, #object ENTRY(sys_call_table) - 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] pci_bus conversion to struct device
Hello! > So, if it were to stay, where in the tree should it be? Hanging off of > the pci device that is the bridge? Or just placing these files within > the pci device directory itself, as it is the bridge. I originally didn't realize that we already represent devices on the subordinate bus as subdirectories of the bridge device's directory, without any extra level of abstraction. So it probably makes sense to put the bus-specific files there or, in case of a root bus, to /sys/devices/pci:YY/. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "It is only with the heart that one can see rightly; What is essential is invisible to the eye." -- The Little Prince - 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/
[RESEND][PATCH] 9p: fix rename return code
9p doesn't handle renames between directories -- however, we were returning
EPERM instead of EXDEV when we detected this case.
Signed-off-by: Eric Van Hensbergren <[EMAIL PROTECTED]>
---
fs/9p/vfs_inode.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 18f26cd..05d30e8 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -767,7 +767,7 @@ v9fs_vfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
/* 9P can only handle file rename in the same directory */
if (memcmp(&olddirfid->qid, &newdirfid->qid, sizeof(newdirfid->qid))) {
dprintk(DEBUG_ERROR, "old dir and new dir are different\n");
- retval = -EPERM;
+ retval = -EXDEV;
goto FreeFcallnBail;
}
--
1.5.0.rc1.gdf1b-dirty
-
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: Questions on PCI express AER support in HBA driver
What are the expected changes on SCSI LLD driver in regards to PCIE
AER supporting? I understood that the driver need to call following
APIs during probing to enable AER support for the device,
---
if (pci_find_aer_capability(dev)) {
pci_enable_pcie_error_reporting(dev);
}
---
What else does SCSI LLD driver need to changed?
Can anyone provide comment?
Allexio
-
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/
