[PATCH] Add section IDs to Documentation/DocBook/filesystems.tmpl
From: Rob Landley <[EMAIL PROTECTED]> Add recommended section IDs to Documentation/DocBook/filesystems.tmpl Signed-off-by: Rob Landley <[EMAIL PROTECTED]> --- Documentation/DocBook/filesystems.tmpl | 36 +++ 1 file changed, 18 insertions(+), 18 deletions(-) diff -r 79f0ea1e0e70 Documentation/DocBook/filesystems.tmpl --- a/Documentation/DocBook/filesystems.tmplTue Oct 09 21:00:40 2007 + +++ b/Documentation/DocBook/filesystems.tmplSat Oct 13 23:16:49 2007 -0500 @@ -40,25 +40,25 @@ The Linux VFS - The Filesystem types + The Filesystem types !Iinclude/linux/fs.h - The Directory Cache + The Directory Cache !Efs/dcache.c !Iinclude/linux/dcache.h - Inode Handling + Inode Handling !Efs/inode.c !Efs/bad_inode.c - Registration and Superblocks + Registration and Superblocks !Efs/super.c - File Locks + File Locks !Efs/locks.c !Ifs/locks.c - Other Functions + Other Functions !Efs/mpage.c !Efs/namei.c !Efs/buffer.c @@ -73,11 +73,11 @@ The proc filesystem - sysctl interface + sysctl interface !Ekernel/sysctl.c - proc filesystem interface + proc filesystem interface !Ifs/proc/base.c @@ -92,7 +92,7 @@ The debugfs filesystem - debugfs interface + debugfs interface !Efs/debugfs/inode.c !Efs/debugfs/file.c @@ -134,9 +134,9 @@ The Linux Journalling API - + Overview - + Details The journalling layer is easy to use. You need to @@ -307,7 +307,7 @@ particular inode. - + Summary Using the journal is a matter of wrapping the different context changes, @@ -349,7 +349,7 @@ an example. - + Data Types The journalling layer uses typedefs to 'hide' the concrete definitions @@ -358,27 +358,27 @@ an example. Obviously the hiding is not enforced as this is 'C'. - Structures + Structures !Iinclude/linux/jbd.h - + Functions The functions here are split into two groups those that affect a journal as a whole, and those which are used to manage transactions - Journal Level + Journal Level !Efs/jbd/journal.c !Ifs/jbd/recovery.c - Transasction Level + Transasction Level !Efs/jbd/transaction.c - + See also -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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-sched patch won't boot on SN arch, 2.6.23-mm1
The git-sched patch in 2.6.23-mm1 freezes my ia64 SN Altix hard on boot. Not good (tm). Something broke between the git-sched patch of Sept 26 in 2.6.23-rc8-mm2 and the git-sched patch of Oct 10 in 2.6.23-mm1 on my ia64 SN Altix system using sn2_defconfig. I can boot 2.6.23-rc8-mm2 fine, but I freeze early in boot on 2.6.23-mm1, after the following prints on the console: McKinley Errata 9 workaround not needed; disabling it SLUB: Genslabs=26, HWalign=128, Order=0-2, MinObjects=8, CPUs=8, Nodes=1024 Dentry cache hash table entries: 1048576 (order: 9, 8388608 bytes) Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes) Mount-cache hash table entries: 1024 ACPI: Core revision 20070126 Boot processor id 0x0/0x0 Brought up 8 CPUs Total of 8 processors activated (15564.80 BogoMIPS). The next output that I -would- have expected, based on successful boots without this patch, but never get, is: net_namespace: 120 bytes DMI not present or invalid. xor: measuring software checksum speed ia64 : 2692.000 MB/sec xor: using function: ia64 (2692.000 MB/sec) NET: Registered protocol family 16 ACPI DSDT OEM Rev 0x20101 My .config has the following elements matching "SCHED" # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_SCHED_SMT=y # CONFIG_NET_SCHED is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set CONFIG_SCHED_DEBUG=y # CONFIG_SCHEDSTATS is not set I'm pretty certain that I also saw this hang with the config setting: CONFIG_FAIR_GROUP_SCHED=y though there is a small chance I'm confused on that point. You'll probably need more information, but I can't guess what, so ask away. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What still uses the block layer?
Matthew Wilcox wrote: You really need to get the fuck over yourself. That is so rude. You need to learn some manners. - 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] more uevent fallout (drivers/base/memory.c)
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index cb99dae..7a1390c 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -34,7 +34,7 @@ static const char *memory_uevent_name(struct kset *kset,
struct kobject *kobj)
return MEMORY_CLASS_NAME;
}
-static int memory_uevent(struct kset *kset, struct kobj_uevent_env *env)
+static int memory_uevent(struct kset *kset, struct kobject *obj, struct
kobj_uevent_env *env)
{
int retval = 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/
Re: 2.6.23: No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
On Sat, 2007-10-13 at 20:13 +0200, Frans Pop wrote: > I could solve this issue in two ways: > - boot with VGA=791 parameter (initial boot was without VGA= parameter) > - compile kernel without FRAMEBUFFER_CONSOLE_DETECT_PRIMARY set (I also > unset FB_VIRTUAL, but without its boot param that should be a no-op) After looking at vfb.c again, it seems the default is for vfb to be enabled and you have to actively disable vfb either with video=vfb:disable or video=vfb:off I have to change this behavior. In the meantime, try one of the above options. (I was also under the impression that vfb must be explicitly enabled with a boot option...I remember now, the option vfb_enable defaults to false when compiled as a module, and to true if compiled statically.) Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [Patch] calgary iommu: Use the first kernel's tce tables in kdump
On Wed, Oct 10, 2007 at 11:00:58AM +0530, Vivek Goyal wrote: > On Tue, Oct 09, 2007 at 11:06:23PM +0200, Muli Ben-Yehuda wrote: > > Hi Chandru, > > > > Thanks for the patch. Comments on the patch below, but first a general > > question for my education: the main problem here that aacraid > > continues DMA'ing when it shouldn't. Why can't we shut it down > > cleanly? Even without the presence of an IOMMU, it seems dangerous to > > let an adapter continue DMA'ing to and from memory when the kernel is > > an inconsistent state. > > > > Hi Muli, > > After the kernel crash, we can't rely on the crashed kernel's data > structures or methods any more. We can't call the device shutdown > methods of all the device drivers as we might be invoking a driver > which actually might have caused the crash. Hence we don't perform > any device shutdown in the case of kdump. Instead after the crash, > we try to take the shortest route to second kernel (Execute minimum > code in crashed kernel). > > Whatever special handling is required to bring up the second kernel on > a potentially unknown state hardware, is taken in second kernel. That makes sense, but does it really make more sense to set-up proper IOMMU translation tables for DMA's which have been triggered from the first kernel than to either quiesce the device ASAP (this means before enabling IOMMU translation...) or to trap such DMA's and continue, rather than letting them go through? > We will not be too concerned about ongoing DMA's as long as there is no > corruption of tce tables. That would mean DMA is happening in first > kernel's memory buffer and second kernel is not impacted. But if TCE > tables themselves are corrupted, then it can potentially interfere with > second kernel's operation. Don't know how it can be addressed. I worry about two cases: the first is TCE table corruption, the second is DMA's to areas which were fine in the first kernel but are wrong for the second kernel. > > The patch below looks reasonable *if* that is the least worst way > > of doing it - let's see if we can come up with something cleaner > > that doesn't rely in the new kernel on data (which may or may not > > be corrupted...) from the old kernel. > > I think the issue here is that some DMA was going on when first > kernel crashed. After the crash, second kernel booted and created > new TCE tables and switched to it. This resulted in ongoing DMA > failure and hardware raised an alarm. > > In this case, probably it would make sense to re-use the TCE tables > of previous kernel (until and unless we have a way to tell hardware > not to flag a DMA error if TCE mapping is changed while DMA is going > on ?) We don't have a way to do that, but we should be able to trap the DMA, figure out that we're in a kdump kernel, and then just ignore it and continue. > I think, we also need to reserve some TCE table entries (in first > kernel), which can be used by second kernel for saving kernel core > file to disk. There might be a case where first kernel has used up > all TCE entries and second kernel can't allocate more. I think ppc64 > has taken the approach of freeing some entries in second kernel but > that will have the problem as you might be clearing an entry which > is being used by ongoing DMA. That's a good point - how do PPC (or other architectures with an isolation-capable IOMMU) handle this whole issue? Cheers, Muli -- SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007 http://www.haifa.il.ibm.com/Workshops/systor2007/ Virtualization workshop: Oct 29th, 2007 | Storage workshop: Oct 30th, 2007 - 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] git scsi misc include fix
From: Paul Jackson <[EMAIL PROTECTED]> The added line in scsi_eh.h: struct scatterlist sense_sgl; fails to compile, with the error: field 'sense_sgl' has incomplete type unless scatterlist.h happens to be included somehow already ... which it isn't always. So include scatterlist.h in scsi_eh.h directly. Signed-off-by: Paul Jackson <[EMAIL PROTECTED]> --- This patch goes after the patch 'git-scsi-misc.patch' include/scsi/scsi_eh.h |1 + 1 file changed, 1 insertion(+) --- 2.6.23-mm1.orig/include/scsi/scsi_eh.h 2007-10-13 01:13:26.568876534 -0700 +++ 2.6.23-mm1/include/scsi/scsi_eh.h 2007-10-13 01:31:32.911855338 -0700 @@ -2,6 +2,7 @@ #define _SCSI_SCSI_EH_H #include +#include struct scsi_device; struct Scsi_Host; -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] MMC/SD: Fix regression in 2.6.23-git3 due to change in calling add_uevent_var
In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence
for add_uevent_var was changed. This patch propagates this change to
MMC/SD card support.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Linus, Andrew,
The wring patch was sent the first time.
Sorry,
Larry
drivers/mmc/core/sdio_bus.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
Index: linux-2.6/drivers/mmc/core/sdio_bus.c
===
--- linux-2.6.orig/drivers/mmc/core/sdio_bus.c
+++ linux-2.6/drivers/mmc/core/sdio_bus.c
@@ -96,30 +96,21 @@ static int sdio_bus_match(struct device
}
static int
-sdio_bus_uevent(struct device *dev, char **envp, int num_envp, char *buf,
- int buf_size)
+sdio_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct sdio_func *func = dev_to_sdio_func(dev);
- int i = 0, length = 0;
- if (add_uevent_var(envp, num_envp, ,
- buf, buf_size, ,
- "SDIO_CLASS=%02X", func->class))
+ if (add_uevent_var(env, "SDIO_CLASS=%02X", func->class))
return -ENOMEM;
- if (add_uevent_var(envp, num_envp, ,
- buf, buf_size, ,
- "SDIO_ID=%04X:%04X", func->vendor, func->device))
+ if (add_uevent_var(env, "SDIO_ID=%04X:%04X", func->vendor,
+ func->device))
return -ENOMEM;
- if (add_uevent_var(envp, num_envp, ,
- buf, buf_size, ,
- "MODALIAS=sdio:c%02Xv%04Xd%04X",
+ if (add_uevent_var(env, "MODALIAS=sdio:c%02Xv%04Xd%04X",
func->class, func->vendor, func->device))
return -ENOMEM;
- envp[i] = NULL;
-
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/
Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
From: Komuro <[EMAIL PROTECTED]> Date: Sun, 14 Oct 2007 13:53:56 +0900 > Sorry, my mailer's mail-address setting is wrong. Thank you for fixing 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: 2.6.23: No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
On Sat, 2007-10-13 at 20:13 +0200, Frans Pop wrote: > While running a test with current Linus' git tree, I ran into the following > issue. The issue is also present in stable 2.6.23. > > System x86_64; Pentium D; Intel 82945G/GZ on-board graphics > > After initial boot messages all output to console stops. The last visible > messages are: > checking if image is initramfs...<6>Switched to high resolution mode on CPU 1 > Switched to high resolution mode on CPU 0 > > After that, nothing until XOrg starts up and graphical login/desktop on VT7 > are displayed normal. > Switching back to VT1-VT5 gives nothing: no login prompts, just nothing. > Can you also post your dmesg and /proc/cdmline? Tony - 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] MMC/SD: Fix regression in 2.6.23-git3 due to change in calling add_uevent_var
In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence
for add_uevent_var was changed, but the ssb driver was not modified, which
leads to a "Unable to handle kernel paging request" oops. This patch fixes
the problem.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
drivers/ssb/main.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
Index: linux-2.6/drivers/ssb/main.c
===
--- linux-2.6.orig/drivers/ssb/main.c
+++ linux-2.6/drivers/ssb/main.c
@@ -320,22 +320,17 @@ static int ssb_bus_match(struct device *
return 0;
}
-static int ssb_device_uevent(struct device *dev, char **envp, int num_envp,
-char *buffer, int buffer_size)
+static int ssb_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct ssb_device *ssb_dev = dev_to_ssb_dev(dev);
- int ret, i = 0, length = 0;
+ int ret;
if (!dev)
return -ENODEV;
- ret = add_uevent_var(envp, num_envp, ,
-buffer, buffer_size, ,
-"MODALIAS=ssb:v%04Xid%04Xrev%02X",
+ ret = add_uevent_var(env, "MODALIAS=ssb:v%04Xid%04Xrev%02X",
ssb_dev->id.vendor, ssb_dev->id.coreid,
ssb_dev->id.revision);
- envp[i] = NULL;
-
return ret;
}
-
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: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
Dear David Sorry, my mailer's mail-address setting is wrong. Best Regards Komuro - 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] ssb: Fix regression in 2.6.23-git3 due to change in calling add_uevent_var
In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence
for add_uevent_var was changed, but the ssb driver was not modified, which
leads to a "Unable to handle kernel paging request" oops. This patch fixes
the problem.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
drivers/ssb/main.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
Index: linux-2.6/drivers/ssb/main.c
===
--- linux-2.6.orig/drivers/ssb/main.c
+++ linux-2.6/drivers/ssb/main.c
@@ -320,22 +320,17 @@ static int ssb_bus_match(struct device *
return 0;
}
-static int ssb_device_uevent(struct device *dev, char **envp, int num_envp,
-char *buffer, int buffer_size)
+static int ssb_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct ssb_device *ssb_dev = dev_to_ssb_dev(dev);
- int ret, i = 0, length = 0;
+ int ret;
if (!dev)
return -ENODEV;
- ret = add_uevent_var(envp, num_envp, ,
-buffer, buffer_size, ,
-"MODALIAS=ssb:v%04Xid%04Xrev%02X",
+ ret = add_uevent_var(env, "MODALIAS=ssb:v%04Xid%04Xrev%02X",
ssb_dev->id.vendor, ssb_dev->id.coreid,
ssb_dev->id.revision);
- envp[i] = NULL;
-
return ret;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix "make htmldocs" build break.
From: Rob Landley <[EMAIL PROTECTED]> Fix two htmldocs build breaks, introduced by moving include/linux/usb_gadget.h to include/linux/usb/gadget.h and combining resume.c and suspend.c into main.c in drivers/base/power. Signed-off-by: Rob Landley <[EMAIL PROTECTED]> --- Documentation/DocBook/gadget.tmpl |6 +++--- Documentation/DocBook/kernel-api.tmpl |3 +-- 2 files changed, 4 insertions(+), 5 deletions(-) diff -r aa4dbd059380 Documentation/DocBook/gadget.tmpl --- a/Documentation/DocBook/gadget.tmpl Sat Oct 13 18:16:49 2007 -0700 +++ b/Documentation/DocBook/gadget.tmpl Sat Oct 13 23:51:56 2007 -0500 @@ -144,7 +144,7 @@ with the lowest level (which directly ha This is the lowest software level. It is the only layer that talks to hardware, through registers, fifos, dma, irqs, and the like. - The linux/usb_gadget.h API abstracts + The linux/usb/gadget.h API abstracts the peripheral controller endpoint hardware. That hardware is exposed through endpoint objects, which accept streams of IN/OUT buffers, and through callbacks that interact @@ -494,7 +494,7 @@ side drivers (and usbcore). Core Objects and Methods These are declared in -linux/usb_gadget.h, +linux/usb/gadget.h, and are used by gadget drivers to interact with USB peripheral controller drivers. @@ -509,7 +509,7 @@ USB peripheral controller drivers. unless the explanations are trivial. --> -!Iinclude/linux/usb_gadget.h +!Iinclude/linux/usb/gadget.h Optional Utilities diff -r aa4dbd059380 Documentation/DocBook/kernel-api.tmpl --- a/Documentation/DocBook/kernel-api.tmpl Sat Oct 13 18:16:49 2007 -0700 +++ b/Documentation/DocBook/kernel-api.tmpl Sat Oct 13 23:51:56 2007 -0500 @@ -386,8 +386,7 @@ X!Edrivers/base/interface.c !Edrivers/base/bus.c Device Drivers Power Management -!Edrivers/base/power/resume.c -!Edrivers/base/power/suspend.c +!Edrivers/base/power/main.c Device Drivers ACPI Support
[PATCH] missing include in ssb
Using readw() and friends => needs to pull io.h and not all targets are doing that via indirect chains. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/drivers/ssb/pcmcia.c b/drivers/ssb/pcmcia.c index 7c77360..b6abee8 100644 --- a/drivers/ssb/pcmcia.c +++ b/drivers/ssb/pcmcia.c @@ -10,6 +10,7 @@ #include #include +#include #include #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/
[PATCH] typo in ibm_newemac/rgmii.c
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c index bcd7fc6..3f57d6c 100644 --- a/drivers/net/ibm_newemac/rgmii.c +++ b/drivers/net/ibm_newemac/rgmii.c @@ -251,7 +251,7 @@ static int __devinit rgmii_probe(struct of_device *ofdev, } /* Check for RGMII type */ - if (device_is_compatible(ofdev->node, "ibm,rgmii-axon")) + if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon")) dev->type = RGMII_AXON; else dev->type = RGMII_STANDARD; - 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: [git pull] Input updates for 2.6.24-rc0
Dmitry Torokhov wrote: [...] > Input: tsdev - implement proper locking [...] > delete mode 100644 drivers/input/tsdev.c This fixes all locking issues indeed :) - 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] uevent environment changes fallout
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index 0713a8c..233d0f9 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -96,30 +96,23 @@ static int sdio_bus_match(struct device *dev, struct
device_driver *drv)
}
static int
-sdio_bus_uevent(struct device *dev, char **envp, int num_envp, char *buf,
- int buf_size)
+sdio_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct sdio_func *func = dev_to_sdio_func(dev);
- int i = 0, length = 0;
- if (add_uevent_var(envp, num_envp, ,
- buf, buf_size, ,
+ if (add_uevent_var(env,
"SDIO_CLASS=%02X", func->class))
return -ENOMEM;
- if (add_uevent_var(envp, num_envp, ,
- buf, buf_size, ,
+ if (add_uevent_var(env,
"SDIO_ID=%04X:%04X", func->vendor, func->device))
return -ENOMEM;
- if (add_uevent_var(envp, num_envp, ,
- buf, buf_size, ,
+ if (add_uevent_var(env,
"MODALIAS=sdio:c%02Xv%04Xd%04X",
func->class, func->vendor, func->device))
return -ENOMEM;
- envp[i] = NULL;
-
return 0;
}
diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index cfd13eb..c12a741 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -321,23 +321,17 @@ static int ssb_bus_match(struct device *dev, struct
device_driver *drv)
return 0;
}
-static int ssb_device_uevent(struct device *dev, char **envp, int num_envp,
-char *buffer, int buffer_size)
+static int ssb_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct ssb_device *ssb_dev = dev_to_ssb_dev(dev);
- int ret, i = 0, length = 0;
if (!dev)
return -ENODEV;
- ret = add_uevent_var(envp, num_envp, ,
-buffer, buffer_size, ,
+ return add_uevent_var(env,
"MODALIAS=ssb:v%04Xid%04Xrev%02X",
ssb_dev->id.vendor, ssb_dev->id.coreid,
ssb_dev->id.revision);
- envp[i] = NULL;
-
- return ret;
}
static struct bus_type ssb_bustype = {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mpc52xx-uart: fix compile warning (format type mismatch)
From: Grant Likely <[EMAIL PROTECTED]>
Trivial compile warning fix
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/serial/mpc52xx_uart.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 035cca0..ec36ad7 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -756,8 +756,8 @@ mpc52xx_console_setup(struct console *co, char *options)
if (port->membase == NULL)
return -EINVAL;
- pr_debug("mpc52xx-psc uart at %lx, mapped to %p, irq=%x, freq=%i\n",
-port->mapbase, port->membase, port->irq, port->uartclk);
+ pr_debug("mpc52xx-psc uart at %p, mapped to %p, irq=%x, freq=%i\n",
+(void*)port->mapbase, port->membase, port->irq, port->uartclk);
/* Setup the port parameters accoding to options */
if (options)
@@ -974,8 +974,8 @@ mpc52xx_uart_of_probe(struct of_device *op, const struct
of_device_id *match)
port->mapbase = res.start;
port->irq = irq_of_parse_and_map(op->node, 0);
- dev_dbg(>dev, "mpc52xx-psc uart at %lx, irq=%x, freq=%i\n",
- port->mapbase, port->irq, port->uartclk);
+ dev_dbg(>dev, "mpc52xx-psc uart at %p, irq=%x, freq=%i\n",
+ (void*)port->mapbase, port->irq, port->uartclk);
if ((port->irq==NO_IRQ) || !port->mapbase) {
printk(KERN_ERR "Could not allocate resources for PSC\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mpc52xx-ata: fix compile warning (unused variable)
From: Grant Likely <[EMAIL PROTECTED]> Trivial unused variable fix Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- drivers/ata/pata_mpc52xx.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c index 099f4cd..f1c3f4d 100644 --- a/drivers/ata/pata_mpc52xx.c +++ b/drivers/ata/pata_mpc52xx.c @@ -309,7 +309,6 @@ mpc52xx_ata_init_one(struct device *dev, struct mpc52xx_ata_priv *priv) struct ata_host *host; struct ata_port *ap; struct ata_ioports *aio; - int rc; host = ata_host_alloc(dev, 1); if (!host) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend Broken (Re: 2.6.23-mm1)
On Sat, Oct 13, 2007 at 08:33:45PM +0200, Rafael J. Wysocki wrote: > Hi, > > On Saturday, 13 October 2007 19:58, Dhaval Giani wrote: > > Hi, > > > > I just tried 2.6.23-mm1 and suspend is not working there. automount > > refuses to go in the freezer. I've attached dmesg (three attempts to > > suspend so it gets a bit big). Suspend works on 2.6.23 and sched-devel. > > > > Another funny thing that I've noticed on -mm is that amarok refuses to > > load a playlist. It works properly on sched-devel tree. > > Could you please try to find the patch that introduces this issue (using > bisection)? The winner is freezer-use-wait-queue-instead-of-busy-looping.patch -- regards, Dhaval - 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: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
From: Komuro <[EMAIL PROTECTED]> Date: Sun, 14 Oct 2007 13:28:51 +0900 > > Dear David > > >Komuro, every single email I sent to you bounces with "user unknown", > >I bet it is some spam filter or similar that doesn't like the > >fact that I lack reverse DNS. > > >From mailing-list-archive, > I can read your email. Then why is your site sending everyone back bounces like the following, when email is sent to you? <[EMAIL PROTECTED]>: host mx.nifty.com[202.248.238.10] said: 550 5.1.1 <[EMAIL PROTECTED]>... User unknown (in reply to RCPT TO command) - 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: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
David Miller wrote: From: Komuro <[EMAIL PROTECTED]> Date: Sun, 14 Oct 2007 10:02:45 +0900 Dear David Actually, tcp_sk(sk)->snd_ssthresh is not initialized, if initial_ssthresh is 0. Komuro, every single email I sent to you bounces with "user unknown", I bet it is some spam filter or similar that doesn't like the fact that I lack reverse DNS. Can someone tell Komuro this side-band? He also missed my previous reply, which directed him to make his report on [EMAIL PROTECTED] which is very important. I get bounces too, but Komuro <[EMAIL PROTECTED]> seems to work. 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: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
Dear David
>Komuro, every single email I sent to you bounces with "user unknown",
>I bet it is some spam filter or similar that doesn't like the
>fact that I lack reverse DNS.
>From mailing-list-archive,
I can read your email.
Best Regards
Komuro
> Dear David
>
> Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
> if initial_ssthresh is 0.
>
> The patch should be
>
> static void bictcp_init(struct sock *sk)
> {
> bictcp_reset(inet_csk_ca(sk));
> - if (initial_ssthresh)
> - tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
> +
> + tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
> }
>
> Best Regards
> Komuro
>
> >
> > Dear David
> >
> > The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC."
> > is not very safe.
> >
> > With this patch, ftp-transfer stops in my system.
> > (vsftpd-2.0.5-8)
> >
> > Please revert this patch.
> >
> >
> > Best Regards
> > Komuro
> >
> > >commit 66e1e3b20cbbf99da63e6c1af0fc6d39c2ed099a
> > >Author: David S. Miller <[EMAIL PROTECTED]>
> > >Date: Wed Jun 13 01:03:53 2007 -0700
> > >
> > >[TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
> > >
> > >Because of the current default of 100, Cubic and BIC perform very
> > >poorly compared to standard Reno.
> > >
> > >In the worst case, this change makes Cubic and BIC as aggressive as
> > >Reno. So this change should be very safe.
> > >
> > >Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
> > >
> > >diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c
> > >index 281c9f9..dd9ef65 100644
> > >--- a/net/ipv4/tcp_bic.c
> > >+++ b/net/ipv4/tcp_bic.c
> > >@@ -29,7 +29,7 @@ static int fast_convergence = 1;
> > > static int max_increment = 16;
> > > static int low_window = 14;
> > > static int beta = 819;/* = 819/1024 (BICTCP_BETA_SCALE) */
> > >-static int initial_ssthresh = 100;
> > >+static int initial_ssthresh;
> > > static int smooth_part = 20;
> > >
> > > module_param(fast_convergence, int, 0644);
> > >diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
> > >index 1422448..ebfaac2 100644
> > >--- a/net/ipv4/tcp_cubic.c
> > >+++ b/net/ipv4/tcp_cubic.c
> > >@@ -29,7 +29,7 @@
> > > static int fast_convergence __read_mostly = 1;
> > > static int max_increment __read_mostly = 16;
> > > static int beta __read_mostly = 819; /* = 819/1024
> > > (BICTCP_BETA_SCALE) */
> > >-static int initial_ssthresh __read_mostly = 100;
> > >+static int initial_ssthresh __read_mostly;
> > > static int bic_scale __read_mostly = 41;
> > > static int tcp_friendliness __read_mostly = 1;
> > >
>
>
> --
> Komuro <[EMAIL PROTECTED]>
--
Komuro <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Compile error fixes
Linus, Here are two fixes which should go in immediately. The first is change to lite5200 which got lost when it was merged. The second is a brown-paper-bag typo. Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] XilinxFB: typo bugfix
From: Grant Likely <[EMAIL PROTECTED]>
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/video/xilinxfb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 6ef99b2..e38d3b7 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -84,7 +84,7 @@ static struct xilinxfb_platform_data xilinx_fb_default_pdata
= {
.xres = 640,
.yres = 480,
.xvirt = 1024,
- .yvirt = 480;
+ .yvirt = 480,
};
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Lite5200 shouldn't mess with ROOT_DEV
From: Grant Likely <[EMAIL PROTECTED]> There is no good reason for board platform code to mess with the ROOT_DEV. Remove it from all in-tree platforms except powermac This is a follow on to commit 745e1027751acbc1f14f8bbef378b491242b9c83. The original patch had this change to lite5200.c, but it got dropped in the psycho madness that is the 2.6.24 merge window. Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- arch/powerpc/platforms/52xx/lite5200.c | 12 1 files changed, 0 insertions(+), 12 deletions(-) diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c index 0caa3d9..a0b4934 100644 --- a/arch/powerpc/platforms/52xx/lite5200.c +++ b/arch/powerpc/platforms/52xx/lite5200.c @@ -156,18 +156,6 @@ static void __init lite5200_setup_arch(void) of_node_put(np); } #endif - -#ifdef CONFIG_BLK_DEV_INITRD - if (initrd_start) - ROOT_DEV = Root_RAM0; - else -#endif -#ifdef CONFIG_ROOT_NFS - ROOT_DEV = Root_NFS; -#else - ROOT_DEV = Root_HDA1; -#endif - } /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-mm1 thread exit_group issue
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> On 10/12, Andrew Morton wrote:
> >
> > On Fri, 12 Oct 2007 15:47:59 -0400
> > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Andrew,
> > >
> > > I noticed a regression between 2.6.23-rc8-mm2 and 2.6.23-mm1 (with your
> > > hotfixes). User space threads seems to receive a ERESTART_RESTARTBLOCK
> > > as soon as a thread does a pthread_join on them. The previous behavior
> > > was to wait for them to exit by taking a futex.
>
> No, the reason is that pthread_join() succeeds while it shouldn't. The main
> thread does exit_group() and kills the sub-thread sleeping in nanosleep.
> ERESTART_RESTARTBLOCK is not delivered to the user-space (sub-thread is
> dying),
> it is just reported by gdb.
>
> > > I provide a toy program that shows the problem. On 2.6.23-rc8-mm2, it
> > > loops forever (as it should). On 2.6.23-mm1, it exits after 10 seconds.
>
> I bet something like this
>
> void *threda(void *arg)
> {
> for (;;)
> pause();
> return NULL;
> }
>
> int main(void)
> {
> pthread_t tid;
>
> pthread_create(, NULL, thread, NULL);
> pthread_join(tid, NULL);
>
> return 0;
> }
>
> won't work as well.
>
> > > Any idea on what may cause this problem ?
>
> Because do_fork() doesn't use parent_tidptr. At all! So it is very clear
> why 2.6.23-mm1 is broken.
>
> > Bisection shows that this problem is caused by these two patches:
> >
> > pid-namespaces-allow-cloning-of-new-namespace.patch
>
> This? http://marc.info/?l=linux-mm-commits=118712242002039
>
> Pavel, this patch has a subtle difference compared to what we discussed on
> containers list. It moves put_user(parent_tidptr) from copy_process() to
> do_fork(), so we don't report child's pid if copy_process() failed. I do
> not think this is bad, but Eric seems to disagree with such a change.
>
> But I can't understand why Andrew sees the same problem _after_ this patch!
>
> And which patch removed the "put_user(nr, parent_tidptr)" chunk?
>
> Andrew, could I get the kernel source after bisection somehow? (I am not
> familiar with guilt, will try to study it later)
>
> Mathieu, could you try the patch below?
>
Hi Oleg,
Yes, it runs fine with this patch.
Thanks,
Mathieu
> Oleg.
>
> --- kernel/fork.c~2007-10-13 15:41:35.0 +0400
> +++ kernel/fork.c 2007-10-13 15:41:41.0 +0400
> @@ -1443,6 +1443,9 @@ long do_fork(unsigned long clone_flags,
> task_pid_nr_ns(p, current->nsproxy->pid_ns) :
> task_pid_vnr(p);
>
> + if (clone_flags & CLONE_PARENT_SETTID)
> + put_user(nr, parent_tidptr);
> +
> if (clone_flags & CLONE_VFORK) {
> p->vfork_done =
> init_completion();
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
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] usb build failure, latest -git
* Al Viro <[EMAIL PROTECTED]> wrote: > On Sun, Oct 14, 2007 at 05:29:48AM +0200, Ingo Molnar wrote: > > > > FYI, the attached config fails to build on most recent -git with: > > > > In file included from drivers/usb/host/ohci-hcd.c:1038: > > drivers/usb/host/ohci-ssb.c:120: error: 'ohci_bus_suspend' undeclared here > > (not in a function) > > drivers/usb/host/ohci-ssb.c:121: error: 'ohci_bus_resume' undeclared here > > (not in a function) > > make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1 > > Subject: [PATCH] ohci-ssb with !CONFIG_PM thanks :-) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] usb build failure, latest -git
Ingo Molnar wrote: > FYI, the attached config fails to build on most recent -git with: > > In file included from drivers/usb/host/ohci-hcd.c:1038: > drivers/usb/host/ohci-ssb.c:120: error: 'ohci_bus_suspend' undeclared here > (not in a function) > drivers/usb/host/ohci-ssb.c:121: error: 'ohci_bus_resume' undeclared here > (not in a function) > make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1 Patch posted by Al Viro should fix that I think. http://lkml.org/lkml/2007/10/13/221 Regards, Gabriel - 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] usb build failure, latest -git
On Sun, Oct 14, 2007 at 05:29:48AM +0200, Ingo Molnar wrote: > > FYI, the attached config fails to build on most recent -git with: > > In file included from drivers/usb/host/ohci-hcd.c:1038: > drivers/usb/host/ohci-ssb.c:120: error: 'ohci_bus_suspend' undeclared here > (not in a function) > drivers/usb/host/ohci-ssb.c:121: error: 'ohci_bus_resume' undeclared here > (not in a function) > make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1 Subject: [PATCH] ohci-ssb with !CONFIG_PM - 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/
[bug] usb build failure, latest -git
FYI, the attached config fails to build on most recent -git with: In file included from drivers/usb/host/ohci-hcd.c:1038: drivers/usb/host/ohci-ssb.c:120: error: 'ohci_bus_suspend' undeclared here (not in a function) drivers/usb/host/ohci-ssb.c:121: error: 'ohci_bus_resume' undeclared here (not in a function) make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1 found via randconfig testing. Ingo # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23 # Sat Oct 13 17:48:44 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_BOOTPARAM_SUPPORT=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=20 # CONFIG_BOOTPARAM_MAXCPUS_1 is not set # CONFIG_BOOTPARAM_NOSMP is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set # CONFIG_HOTPLUG is not set CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set # CONFIG_BASE_FULL is not set CONFIG_FUTEX=y # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set # CONFIG_EVENTFD is not set # CONFIG_SHMEM is not set # CONFIG_VM_EVENT_COUNTERS is not set # CONFIG_SLAB is not set # CONFIG_SLUB is not set CONFIG_SLOB=y CONFIG_RT_MUTEXES=y CONFIG_TINY_SHMEM=y CONFIG_BASE_SMALL=1 # CONFIG_MODULES is not set CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set # CONFIG_BOOTPARAM_NO_HZ_OFF is not set CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_BOOTPARAM_HIGHRES_OFF=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set CONFIG_PARAVIRT=y CONFIG_XEN=y # CONFIG_VMI is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMII=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_VM86 is not set CONFIG_TOSHIBA=y CONFIG_I8K=y CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # CONFIG_EDD=y CONFIG_DELL_RBU=y CONFIG_DCDBAS=y # CONFIG_DMIID is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set # CONFIG_VMSPLIT_3G is not set #
Re: x86: merge some trivially mergeable headers
> Roland, thanks for providing this. I have some of those already, but I > really appreciate the help. I take yours and the previously posted and > push them out into a cleanup branch on my x86 git tree. No problem, this merging work is the perfect thing when I need a break-- mindless enough to be relaxing, but useful enough that I don't feel guilty... Anyway, I assume you meant to write "I [will] take yours", since I don't see anything at all in tglx/linux-2.6-x86.git right now. I'll check again on Monday and base my work on your tree. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
From: Komuro <[EMAIL PROTECTED]> Date: Sun, 14 Oct 2007 10:02:45 +0900 > Dear David > > Actually, tcp_sk(sk)->snd_ssthresh is not initialized, > if initial_ssthresh is 0. Komuro, every single email I sent to you bounces with "user unknown", I bet it is some spam filter or similar that doesn't like the fact that I lack reverse DNS. Can someone tell Komuro this side-band? He also missed my previous reply, which directed him to make his report on [EMAIL PROTECTED] which is very important. - 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] Update Jens Axboe's email in Documentation/*
From: Rob Landley <[EMAIL PROTECTED]> Jens Axboe's old email address bounces. Signed-off-by: Rob Landley <[EMAIL PROTECTED]> --- He's emailing from oracle.com these days, and the old one bounced with: <[EMAIL PROTECTED]>: host mx2.suse.de[195.135.220.15] said: 550 <[EMAIL PROTECTED]>: Recipient address rejected: User has moved to (in reply to RCPT TO command) Documentation/DMA-mapping.txt|2 +- Documentation/HOWTO |2 +- Documentation/block/biodoc.txt |4 ++-- Documentation/block/deadline-iosched.txt |2 +- Documentation/block/ioprio.txt |2 +- Documentation/block/request.txt |2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff -r 79f0ea1e0e70 Documentation/DMA-mapping.txt --- a/Documentation/DMA-mapping.txt Tue Oct 09 21:00:40 2007 + +++ b/Documentation/DMA-mapping.txt Sat Oct 13 20:51:42 2007 -0500 @@ -782,5 +782,5 @@ following people: Jay Estabrook <[EMAIL PROTECTED]> Thomas Sailer <[EMAIL PROTECTED]> Andrea Arcangeli <[EMAIL PROTECTED]> - Jens Axboe <[EMAIL PROTECTED]> + Jens Axboe <[EMAIL PROTECTED]> David Mosberger-Tang <[EMAIL PROTECTED]> diff -r 79f0ea1e0e70 Documentation/HOWTO --- a/Documentation/HOWTO Tue Oct 09 21:00:40 2007 + +++ b/Documentation/HOWTO Sat Oct 13 20:51:42 2007 -0500 @@ -330,7 +330,7 @@ Here is a list of some of the different - ACPI development tree, Len Brown <[EMAIL PROTECTED]> git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git -- Block development tree, Jens Axboe <[EMAIL PROTECTED]> +- Block development tree, Jens Axboe <[EMAIL PROTECTED]> git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git - DRM development tree, Dave Airlie <[EMAIL PROTECTED]> diff -r 79f0ea1e0e70 Documentation/block/biodoc.txt --- a/Documentation/block/biodoc.txtTue Oct 09 21:00:40 2007 + +++ b/Documentation/block/biodoc.txtSat Oct 13 20:51:42 2007 -0500 @@ -2,7 +2,7 @@ = Notes Written on Jan 15, 2002: - Jens Axboe <[EMAIL PROTECTED]> + Jens Axboe <[EMAIL PROTECTED]> Suparna Bhattacharya <[EMAIL PROTECTED]> Last Updated May 2, 2002 @@ -21,7 +21,7 @@ Credits: - 2.5 bio rewrite: - Jens Axboe <[EMAIL PROTECTED]> + Jens Axboe <[EMAIL PROTECTED]> Many aspects of the generic block layer redesign were driven by and evolved over discussions, prior patches and the collective experience of several diff -r 79f0ea1e0e70 Documentation/block/deadline-iosched.txt --- a/Documentation/block/deadline-iosched.txt Tue Oct 09 21:00:40 2007 + +++ b/Documentation/block/deadline-iosched.txt Sat Oct 13 20:51:42 2007 -0500 @@ -73,6 +73,6 @@ rbtree front sector lookup when the io s rbtree front sector lookup when the io scheduler merge function is called. -Nov 11 2002, Jens Axboe <[EMAIL PROTECTED]> +Nov 11 2002, Jens Axboe <[EMAIL PROTECTED]> diff -r 79f0ea1e0e70 Documentation/block/ioprio.txt --- a/Documentation/block/ioprio.txtTue Oct 09 21:00:40 2007 + +++ b/Documentation/block/ioprio.txtSat Oct 13 20:51:42 2007 -0500 @@ -173,4 +173,4 @@ int main(int argc, char *argv[]) ---> snip ionice.c tool <--- -March 11 2005, Jens Axboe <[EMAIL PROTECTED]> +March 11 2005, Jens Axboe <[EMAIL PROTECTED]> diff -r 79f0ea1e0e70 Documentation/block/request.txt --- a/Documentation/block/request.txt Tue Oct 09 21:00:40 2007 + +++ b/Documentation/block/request.txt Sat Oct 13 20:51:42 2007 -0500 @@ -1,7 +1,7 @@ struct request documentation -Jens Axboe <[EMAIL PROTECTED]> 27/05/02 +Jens Axboe <[EMAIL PROTECTED]> 27/05/02 1.0 Index -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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] JFS: Bio cleanup: Replace missing return statements
On Sat, 2007-10-13 at 12:28 -0700, Randy Dunlap wrote: > On Sat, 13 Oct 2007 15:11:10 -0400 Jeff Garzik wrote: > > > > > From: Dave Kleikamp <[EMAIL PROTECTED]> > > > > commit 6712ecf8f648118c3363c142196418f89a510b90 removed some "return 0;" > > statements, rather than changing them to null returns. > > Is my git tree mucked up? It looks to me like it was commit > e30408b2a99cb7b8bf529c7dc2328a19d71894cf that removed the return 0's. Yeah. It was that one. I cut and pasted the wrong one for the comment. Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center - 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: First stab at Elantech touchpad driver for 2.6.22.6. Testers wanted!
Hi Dmitry, On Tue, Oct 09, 2007 at 04:01:58PM -0400, Dmitry Torokhov wrote: > On 9/13/07, Arjan Opmeer <[EMAIL PROTECTED]> wrote: > > > > This is a first stab at a Linux driver for the Elantech touchpad as > > found on some laptops (e.g. MSI MS-1035 aka L725). > > Since the touchpad supports absolute mode I'd recommend removing > support for extended relative mode and concentrating on making > absolute mode work so that Synaptics X driver can be used with this > touchpad as well. Well, from the few reports I got it seems not all Elantech touchpads are created equal. And as we don't have any documentation on these touchpads I really don't know whether they all support absolute mode, have the same parameters or use the same protocol for it. So for the time being I really would like to keep support for absolute as well as relative mode in to make it easier for users to switch and test and find out and report where thing go wrong. Maybe that once we find out more about these touchpads and the possible different version we can focus on a solution that will fit all. But let's not do it while users are still trying whether the driver works for them at all... :) Arjan - 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: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
Dear David
Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
if initial_ssthresh is 0.
The patch should be
static void bictcp_init(struct sock *sk)
{
bictcp_reset(inet_csk_ca(sk));
- if (initial_ssthresh)
- tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
+
+ tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
}
Best Regards
Komuro
>
> Dear David
>
> The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC."
> is not very safe.
>
> With this patch, ftp-transfer stops in my system.
> (vsftpd-2.0.5-8)
>
> Please revert this patch.
>
>
> Best Regards
> Komuro
>
> >commit 66e1e3b20cbbf99da63e6c1af0fc6d39c2ed099a
> >Author: David S. Miller <[EMAIL PROTECTED]>
> >Date: Wed Jun 13 01:03:53 2007 -0700
> >
> >[TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
> >
> >Because of the current default of 100, Cubic and BIC perform very
> >poorly compared to standard Reno.
> >
> >In the worst case, this change makes Cubic and BIC as aggressive as
> >Reno. So this change should be very safe.
> >
> >Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
> >
> >diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c
> >index 281c9f9..dd9ef65 100644
> >--- a/net/ipv4/tcp_bic.c
> >+++ b/net/ipv4/tcp_bic.c
> >@@ -29,7 +29,7 @@ static int fast_convergence = 1;
> > static int max_increment = 16;
> > static int low_window = 14;
> > static int beta = 819; /* = 819/1024 (BICTCP_BETA_SCALE) */
> >-static int initial_ssthresh = 100;
> >+static int initial_ssthresh;
> > static int smooth_part = 20;
> >
> > module_param(fast_convergence, int, 0644);
> >diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
> >index 1422448..ebfaac2 100644
> >--- a/net/ipv4/tcp_cubic.c
> >+++ b/net/ipv4/tcp_cubic.c
> >@@ -29,7 +29,7 @@
> > static int fast_convergence __read_mostly = 1;
> > static int max_increment __read_mostly = 16;
> > static int beta __read_mostly = 819;/* = 819/1024
> > (BICTCP_BETA_SCALE) */
> >-static int initial_ssthresh __read_mostly = 100;
> >+static int initial_ssthresh __read_mostly;
> > static int bic_scale __read_mostly = 41;
> > static int tcp_friendliness __read_mostly = 1;
> >
--
Komuro <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git3 compilation broken, asm headers missing?
On 10/14/07, Patrizio Bassi <[EMAIL PROTECTED]> wrote: > Thomas Gleixner ha scritto: > > On Sat, 13 Oct 2007, Patrizio Bassi wrote: > > > >> include/linux/types.h:15:23: error: asm/types.h: No such file or directory > >> In file included from include/linux/prefetch.h:13, > >> from include/linux/list.h:8, > >> from include/linux/module.h:9, > >> from include/linux/crypto.h:21, > >> from arch/x86/kernel/asm-offsets_32.c:7, > >> from arch/x86/kernel/asm-offsets.c:2: > >> > >> full log attached. > >> > > > > That's a stale include/asm symlink. Can you save your .config file and do > > > > make mrproper > > > > please and check if it's solved. > > > > Thanks, > > > > tglx > > > > > > > seems ok now > > Thanks! Same issue here, and as well making mrproper fixes it. Thanks, ciao, --alessandro "you feel the sweet breath of time it's whispering, its truth not mine" (Interpol, 'No I In Threesome') - 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] frv: Remove duplicate output of .exit.data
Maciej W. Rozycki <[EMAIL PROTECTED]> wrote: > When CONFIG_DEBUG_INFO is unset the input .exit.data sections are copied > twice to vmlinux. Remove the copy made to .init.text and keep one in > .data only. No, they aren't. I believe the linker only makes one copy of each section, and once a copy is inserted, all other attempts to make a copy of it are ignored. NAK. David - 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.23-git3 jfs/bio bug
On Sat, Oct 13, 2007 at 12:58:00PM -0500, Dave Kleikamp wrote: > On Sat, 2007-10-13 at 10:25 -0700, Randy Dunlap wrote: > > [ 9158.155844] JFS: nTxBlock = 8192, nTxLock = 65536 > > [ 9159.199567] BUG at fs/jfs/jfs_logmgr.c:2333 assert(bp->l_flag & > > lbmRELEASE) > > [ 9159.206566] [ cut here ] > > [ 9159.211189] kernel BUG at fs/jfs/jfs_logmgr.c:2333! > > [ 9159.216066] invalid opcode: [1] SMP > > [ 9159.220108] CPU 2 > > [ 9159.222144] Modules linked in: jfs loop > > [ 9159.226034] Pid: 0, comm: swapper Not tainted 2.6.23-git3 #1 > > [ 9159.231688] RIP: 0010:[] [] > > :jfs:lbmIODone+0x317/0x367 > > [ 9159.240063] RSP: 0018:81011fcefc90 EFLAGS: 00010286 > > [ 9159.245372] RAX: 0052 RBX: 81011fcfe800 RCX: > > > > [ 9159.252499] RDX: 0001 RSI: 0082 RDI: > > 0001 > > [ 9159.259626] RBP: 81011fcefcc0 R08: 806e43b8 R09: > > 0086 > > [ 9159.266754] R10: 0082 R11: 8073d000 R12: > > 0282 > > [ 9159.273881] R13: 81011d451740 R14: R15: > > 1000 > > [ 9159.281009] FS: () GS:81011fc75840() > > knlGS: > > [ 9159.289089] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > > [ 9159.294830] CR2: 2adf5b051180 CR3: 00010416b000 CR4: > > 06e0 > > [ 9159.301959] DR0: DR1: DR2: > > > > [ 9159.309087] DR3: DR6: 4ff0 DR7: > > 0400 > > [ 9159.316215] Process swapper (pid: 0, threadinfo 81011fce8000, task > > 81011fca3820) > > [ 9159.324293] Stack: 81011fcefca0 81010f51e800 > > 8101061b7728 > > [ 9159.332374] 1000 81011fcefcd0 > > 802ac695 > > [ 9159.339830] 81011fcefcf0 803404a6 1000 > > 81010f51e800 > > [ 9159.347096] Call Trace: > > [ 9159.349738][] bio_endio+0x28/0x2a > > [ 9159.355423] [] req_bio_endio+0x79/0x93 > > [ 9159.360817] [] __end_that_request_first+0x101/0x2cb > > [ 9159.367339] [] end_that_request_chunk+0x9/0xb > > [ 9159.373341] [] scsi_end_request+0x30/0xd5 > > [ 9159.378995] [] scsi_io_completion+0x15a/0x390 > > [ 9159.384998] [] sd_rw_intr+0x2d1/0x305 > > [ 9159.390307] [] scsi_finish_command+0x98/0xa1 > > [ 9159.396220] [] scsi_softirq_done+0xf1/0xfa > > [ 9159.401963] [] blk_done_softirq+0x63/0x72 > > [ 9159.407619] [] __do_softirq+0x57/0xc7 > > [ 9159.412927] [] call_softirq+0x1c/0x28 > > [ 9159.418235] [] do_softirq+0x34/0x87 > > [ 9159.423370] [] irq_exit+0x3f/0x41 > > [ 9159.428333] [] do_IRQ+0x144/0x169 > > [ 9159.433296] [] mwait_idle+0x0/0x4e > > [ 9159.438344] [] ret_from_intr+0x0/0xa > > [ 9159.443566][] mwait_idle+0x46/0x4e > > [ 9159.449335] [] enter_idle+0x22/0x24 > > [ 9159.454470] [] cpu_idle+0x93/0xb6 > > [ 9159.459434] [] start_secondary+0x2b7/0x2c6 > > [ 9159.465173] > > [ 9159.466670] > > [ 9159.466671] Code: 0f 0b eb fe a8 10 75 25 48 c7 c1 6e 6b 02 88 ba 1e 09 > > 00 00 > > [ 9159.475739] RIP [] :jfs:lbmIODone+0x317/0x367 > > [ 9159.481775] RSP > > [ 9159.485552] Kernel panic - not syncing: Fatal exception > > [ 9159.490780] Rebooting in 30 seconds.. > > I don't have time to test this now, but the bio_endio patches ended up > removing some return statements that need to stay. I think this should > fix it. > > JFS: Bio cleanup: Replace missing return statements > > commit 6712ecf8f648118c3363c142196418f89a510b90 removed some "return 0;" > statements, rather than changing them to null returns. > > Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]> Ouch, yes indeed. 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.23-git3 compilation broken, asm headers missing?
Thomas Gleixner ha scritto: > On Sat, 13 Oct 2007, Patrizio Bassi wrote: > >> include/linux/types.h:15:23: error: asm/types.h: No such file or directory >> In file included from include/linux/prefetch.h:13, >> from include/linux/list.h:8, >> from include/linux/module.h:9, >> from include/linux/crypto.h:21, >> from arch/x86/kernel/asm-offsets_32.c:7, >> from arch/x86/kernel/asm-offsets.c:2: >> >> full log attached. >> > > That's a stale include/asm symlink. Can you save your .config file and do > > make mrproper > > please and check if it's solved. > > Thanks, > > tglx > > > seems ok now Thanks! -- Patrizio Bassi www.patriziobassi.it - 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: [git patches] IDE updates (part 2)
Proposed addition to icside part, provided that ARM folks ACK it - gets
icside to build and AFAICS it's correct:
diff --git a/drivers/ata/pata_icside.c b/drivers/ata/pata_icside.c
index be30923..842fe08 100644
--- a/drivers/ata/pata_icside.c
+++ b/drivers/ata/pata_icside.c
@@ -332,12 +332,13 @@ static void ata_dummy_noret(struct ata_port *port)
{
}
-static void pata_icside_postreset(struct ata_port *ap, unsigned int *classes)
+static void pata_icside_postreset(struct ata_link *link, unsigned int *classes)
{
+ struct ata_port *ap = link->ap;
struct pata_icside_state *state = ap->host->private_data;
if (classes[0] != ATA_DEV_NONE || classes[1] != ATA_DEV_NONE)
- return ata_std_postreset(ap, classes);
+ return ata_std_postreset(link, classes);
state->port[ap->port_no].disabled = 1;
@@ -395,29 +396,30 @@ static struct ata_port_operations pata_icside_port_ops = {
static void __devinit
pata_icside_setup_ioaddr(struct ata_port *ap, void __iomem *base,
-const struct portinfo *info)
+struct pata_icside_info *info,
+const struct portinfo *port)
{
struct ata_ioports *ioaddr = >ioaddr;
- void __iomem *cmd = base + info->dataoffset;
+ void __iomem *cmd = base + port->dataoffset;
ioaddr->cmd_addr= cmd;
- ioaddr->data_addr = cmd + (ATA_REG_DATA<< info->stepping);
- ioaddr->error_addr = cmd + (ATA_REG_ERR << info->stepping);
- ioaddr->feature_addr= cmd + (ATA_REG_FEATURE << info->stepping);
- ioaddr->nsect_addr = cmd + (ATA_REG_NSECT << info->stepping);
- ioaddr->lbal_addr = cmd + (ATA_REG_LBAL<< info->stepping);
- ioaddr->lbam_addr = cmd + (ATA_REG_LBAM<< info->stepping);
- ioaddr->lbah_addr = cmd + (ATA_REG_LBAH<< info->stepping);
- ioaddr->device_addr = cmd + (ATA_REG_DEVICE << info->stepping);
- ioaddr->status_addr = cmd + (ATA_REG_STATUS << info->stepping);
- ioaddr->command_addr= cmd + (ATA_REG_CMD << info->stepping);
-
- ioaddr->ctl_addr= base + info->ctrloffset;
+ ioaddr->data_addr = cmd + (ATA_REG_DATA<< port->stepping);
+ ioaddr->error_addr = cmd + (ATA_REG_ERR << port->stepping);
+ ioaddr->feature_addr= cmd + (ATA_REG_FEATURE << port->stepping);
+ ioaddr->nsect_addr = cmd + (ATA_REG_NSECT << port->stepping);
+ ioaddr->lbal_addr = cmd + (ATA_REG_LBAL<< port->stepping);
+ ioaddr->lbam_addr = cmd + (ATA_REG_LBAM<< port->stepping);
+ ioaddr->lbah_addr = cmd + (ATA_REG_LBAH<< port->stepping);
+ ioaddr->device_addr = cmd + (ATA_REG_DEVICE << port->stepping);
+ ioaddr->status_addr = cmd + (ATA_REG_STATUS << port->stepping);
+ ioaddr->command_addr= cmd + (ATA_REG_CMD << port->stepping);
+
+ ioaddr->ctl_addr= base + port->ctrloffset;
ioaddr->altstatus_addr = ioaddr->ctl_addr;
ata_port_desc(ap, "cmd 0x%lx ctl 0x%lx",
- info->raw_base + info->dataoffset,
- info->raw_base + info->ctrloffset);
+ info->raw_base + port->dataoffset,
+ info->raw_base + port->ctrloffset);
if (info->raw_ioc_base)
ata_port_desc(ap, "iocbase 0x%lx", info->raw_ioc_base);
@@ -441,7 +443,7 @@ static int __devinit pata_icside_register_v5(struct
pata_icside_info *info)
info->nr_ports = 1;
info->port[0] = _icside_portinfo_v5;
- info->raw_base = ecard_resource_start(ec, ECARD_RES_MEMC);
+ info->raw_base = ecard_resource_start(info->ec, ECARD_RES_MEMC);
return 0;
}
@@ -522,7 +524,7 @@ static int __devinit pata_icside_add_ports(struct
pata_icside_info *info)
ap->flags |= ATA_FLAG_SLAVE_POSS;
ap->ops = _icside_port_ops;
- pata_icside_setup_ioaddr(ap, info->base, info->port[i]);
+ pata_icside_setup_ioaddr(ap, info->base, info, info->port[i]);
}
return ata_host_activate(host, ec->irq, ata_interrupt, 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/
Re: [PATCH 00/52] Introduce credential record
Theodore Tso <[EMAIL PROTECTED]> wrote: >I'm going to ask a stupid question, and I probably missed something > in the 52 patches, but I see how the credential is used to do > access checks, but why does the credentials record need to passed all > the way into block allocator? What is it used for there? Ext2, 3 & 4 use it to determine whether someone has the right to use the reserved space according to whether their UID/GID match those in the superblock. See ext3_has_free_blocks() for an example. David - 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: [git patches] IDE updates (part 2)
On Sun, 2007-10-14 at 00:41 +0200, Bartlomiej Zolnierkiewicz wrote: > On Sunday 14 October 2007, Alan Cox wrote: > > > > > /* Probably a PCI interface... */ > > > > > for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; ++i) > > > > > hw->io_ports[i] = data_port + i - > > > > > IDE_DATA_OFFSET; > > > > > hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; > > > > Ok so in actual fact > > > > - The piece of code above can't be executed anyway > > - The ctrl_port argument is not needed ? > > pmac_ide_init_hwif_ports() is also called by ide_init_hwif_ports() > through ppc_ide_md.init_hwif. In which case it should be called with a ctrl_port right ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.1] possible circular locking dependency detected
On Sun, 2007-10-14 at 01:19 +0200, Peter Zijlstra wrote: > On Sun, 2007-10-14 at 00:36 +0200, Folkert van Heusden wrote: > > I've got a deja-vu feeling for this one but in any case: > > > I seems that patch hasn't made it into .23... I'll stick it in the > lockdep tree aimed at .24. Could you try: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-lockdep.git v2.6.24-lockdep on top of current -linus, I just pushed out the patch that should fix it: lockdep: per filesystem inode lock class (still hasn't replicated though, so might take a while) - 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: regression(?): starting with 2.6.21 sending packets became broken.
On Sat, 13 Oct 2007 22:35:25 +0200 (CEST)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Oct 13 2007 19:59, David wrote:
> >Try
> >
> >echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
> >
> >I bet you have broken router(s) between your machine and the problem
> >site(s).
>
> There is an xt_TCPOPTSTRIP module in the works that allows you to strip
> Window Scaling only on the connections you want (rather than globally);
> seems to be in for 2.6.24 at earliest, though it's there is also the
> standalone patch.
You can also do it on a per route basis which is easier than bothering
with filtering rules by just enforcing a window size limit.
ip route add {broken_dst}/32 via {gateway} window 65535
Long description at:
http://lwn.net/Articles/92727/
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23.1] possible circular locking dependency detected
On Sun, 2007-10-14 at 00:36 +0200, Folkert van Heusden wrote:
> I've got a deja-vu feeling for this one but in any case:
>
>
> [ 7393.894980] ===
> [ 7393.895081] [ INFO: possible circular locking dependency detected ]
> [ 7393.895130] 2.6.23.1 #2
> [ 7393.895175] ---
> [ 7393.895225] moo/28246 is trying to acquire lock:
> [ 7393.895275] (tty_mutex){--..}, at: [] mutex_lock+0x8/0xa
> [ 7393.895486]
> [ 7393.895487] but task is already holding lock:
> [ 7393.895578] (>s_dquot.dqptr_sem){}, at: []
> dquot_alloc_space+0x50/0x189
> [ 7393.895784]
> [ 7393.895785] which lock already depends on the new lock.
> [ 7393.895788]
> [ 7393.895915]
> [ 7393.895916] the existing dependency chain (in reverse order) is:
> [ 7393.896003]
> [ 7393.896005] -> #3 (>s_dquot.dqptr_sem){}:
> [ 7393.896209][] check_prev_add+0xc4/0x1fb
> [ 7393.896555][] check_prevs_add+0x8b/0xe8
> [ 7393.896890][] validate_chain+0x22b/0x354
> [ 7393.897223][] __lock_acquire+0x1a0/0x74a
> [ 7393.897553][] lock_acquire+0x6b/0x8a
> [ 7393.897882][] down_read+0x2b/0x3d
> [ 7393.898205][] dquot_alloc_space+0x50/0x189
> [ 7393.898537][] ext3_new_blocks+0x44b/0x5a2
> [ 7393.898868][] ext3_alloc_blocks+0x40/0xdf
> [ 7393.899194][] ext3_alloc_branch+0x50/0x21b
> [ 7393.899527][] ext3_get_blocks_handle+0x1b8/0x367
> [ 7393.899858][] ext3_getblk+0x97/0x228
> [ 7393.900186][] ext3_bread+0x1a/0x78
> [ 7393.900514][] ext3_mkdir+0xf2/0x270
> [ 7393.900851][] vfs_mkdir+0xb3/0x161
> [ 7393.901174][] sys_mkdirat+0x8c/0xc4
> [ 7393.901512][] sys_mkdir+0x20/0x22
> [ 7393.901841][] syscall_call+0x7/0xb
> [ 7393.902169][] 0x
> [ 7393.902511]
> [ 7393.902512] -> #2 (>truncate_mutex){--..}:
> [ 7393.902706][] check_prev_add+0xc4/0x1fb
> [ 7393.903033][] check_prevs_add+0x8b/0xe8
> [ 7393.903364][] validate_chain+0x22b/0x354
> [ 7393.903700][] __lock_acquire+0x1a0/0x74a
> [ 7393.904353][] lock_acquire+0x6b/0x8a
> [ 7393.904682][] __mutex_lock_slowpath+0x75/0x299
> [ 7393.905015][] mutex_lock+0x8/0xa
> [ 7393.905339][] ext3_get_blocks_handle+0xd9/0x367
> [ 7393.905675][] ext3_get_block+0x78/0xe3
> [ 7393.906009][] __block_prepare_write+0x168/0x415
> [ 7393.906339][] block_prepare_write+0x28/0x3b
> [ 7393.906673][] ext3_prepare_write+0xe3/0x17e
> [ 7393.907002][] generic_file_buffered_write+0x1cb/0x62b
> [ 7393.907333][] __generic_file_aio_write_nolock+0x23a/0x53d
> [ 7393.907667][] generic_file_aio_write+0x58/0xc4
> [ 7393.907998][] ext3_file_write+0x2d/0xba
> [ 7393.908324][] do_sync_write+0xc7/0x116
> [ 7393.908655][] vfs_write+0x158/0x15d
> [ 7393.908981][] sys_write+0x3d/0x64
> [ 7393.909310][] syscall_call+0x7/0xb
> [ 7393.909635][] 0x
> [ 7393.909974]
> [ 7393.909976] -> #1 (>i_mutex){--..}:
> [ 7393.910163][] check_prev_add+0xc4/0x1fb
> [ 7393.910496][] check_prevs_add+0x8b/0xe8
> [ 7393.910823][] validate_chain+0x22b/0x354
> [ 7393.911152][] __lock_acquire+0x1a0/0x74a
> [ 7393.911478][] lock_acquire+0x6b/0x8a
> [ 7393.911807][] __mutex_lock_slowpath+0x75/0x299
> [ 7393.912137][] mutex_lock+0x8/0xa
> [ 7393.912465][] get_node+0x21/0x4d
> [ 7393.912788][] devpts_get_tty+0xb/0x3b
> [ 7393.913398][] init_dev+0x22b/0x58b
> [ 7393.913718][] ptmx_open+0x90/0x1c9
> [ 7393.913992][] chrdev_open+0xaf/0x171
> [ 7393.914001][] __dentry_open+0x152/0x1d3
> [ 7393.914008][] nameidata_to_filp+0x28/0x3f
> [ 7393.914018][] do_filp_open+0x46/0x53
> [ 7393.914024][] do_sys_open+0x54/0xda
> [ 7393.914031][] sys_open+0x1c/0x1e
> [ 7393.914038][] syscall_call+0x7/0xb
> [ 7393.914046][] 0x
> [ 7393.914069]
> [ 7393.914070] -> #0 (tty_mutex){--..}:
> [ 7393.914074][] check_prev_add+0x34/0x1fb
> [ 7393.914084][] check_prevs_add+0x8b/0xe8
> [ 7393.914092][] validate_chain+0x22b/0x354
> [ 7393.914103][] __lock_acquire+0x1a0/0x74a
> [ 7393.914111][] lock_acquire+0x6b/0x8a
> [ 7393.914117][] __mutex_lock_slowpath+0x75/0x299
> [ 7393.914126][] mutex_lock+0x8/0xa
> [ 7393.914134][] print_warning+0x8c/0x15d
> [ 7393.914143][] dquot_alloc_space+0x184/0x189
> [ 7393.914154][] ext3_new_blocks+0x44b/0x5a2
> [ 7393.914162][] ext3_alloc_blocks+0x40/0xdf
> [ 7393.914170][] ext3_alloc_branch+0x50/0x21b
> [ 7393.914177][] ext3_get_blocks_handle+0x1b8/0x367
> [ 7393.914185][] ext3_get_block+0x78/0xe3
> [ 7393.914195][] __block_prepare_write+0x168/0x415
> [ 7393.914203]
Re: [PATCH] sched: high-res preemption tick
On Sun, 2007-10-14 at 01:13 +0200, Peter Zijlstra wrote: > On Sat, 2007-10-13 at 11:17 +0200, Peter Zijlstra wrote: > > > > Ah, but HRTICK is not compatible with PREEMPT_RESTRICT, it will be > > > similar to !WAKEUP_PREEMPT. > > > > (I do plan to fix that eventually, just need to do it) > > I guess something like this ought to do, but its a tad late so I'm quite > sure :-) I guess that proves it that should have read: ... so I'm _not_ quite sure. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: high-res preemption tick
On Sat, 2007-10-13 at 11:17 +0200, Peter Zijlstra wrote:
> > Ah, but HRTICK is not compatible with PREEMPT_RESTRICT, it will be
> > similar to !WAKEUP_PREEMPT.
>
> (I do plan to fix that eventually, just need to do it)
I guess something like this ought to do, but its a tad late so I'm quite
sure :-)
---
kernel/sched_fair.c | 44 +---
1 file changed, 37 insertions(+), 7 deletions(-)
Index: linux-2.6/kernel/sched_fair.c
===
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -737,6 +737,24 @@ static inline struct sched_entity *paren
#endif /* CONFIG_FAIR_GROUP_SCHED */
+/*
+ * does pse (newly woken task) preempt se (current task)
+ */
+static int wakeup_preempt(struct sched_entity *se, struct sched_entity *pse)
+{
+ s64 delta, gran;
+
+ delta = se->vruntime - pse->vruntime;
+ gran = sysctl_sched_wakeup_granularity;
+ if (unlikely(se->load.weight != NICE_0_LOAD))
+ gran = calc_delta_fair(gran, >load);
+
+ if (delta > gran)
+ return 1;
+
+ return 0;
+}
+
#ifdef CONFIG_SCHED_HRTICK
static void hrtick_start_fair(struct rq *rq, struct task_struct *p)
{
@@ -764,6 +782,24 @@ static void hrtick_start_fair(struct rq
if (!requeue)
delta = max(1LL, delta);
+ /*
+* if we delayed wakeup preemption, shorten the slice to at most
+* 1 jiffy (does this call for yet another sysctl_sched_?)
+*/
+ if (sched_feat(PREEMPT_RESTRICT) && first_fair(cfs_rq)) {
+ struct sched_entity *next = __pick_next_entity(cfs_rq);
+
+ if (wakeup_preempt(se, next)) {
+ u64 wakeup = NSEC_PER_SEC / HZ;
+ s64 delta2 = wakeup - ran;
+
+ if (delta2 < 0)
+ resched_task(rq->curr);
+ else
+ delta = min(delta, delta2);
+ }
+ }
+
hrtick_start(rq, delta, requeue);
}
}
@@ -866,7 +902,6 @@ static void check_preempt_wakeup(struct
struct task_struct *curr = rq->curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = >se, *pse = >se;
- s64 delta, gran;
if (unlikely(rt_prio(p->prio))) {
update_rq_clock(rq);
@@ -887,12 +922,7 @@ static void check_preempt_wakeup(struct
pse = parent_entity(pse);
}
- delta = se->vruntime - pse->vruntime;
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se->load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, >load);
-
- if (delta > gran) {
+ if (wakeup_preempt(se, pse)) {
int now = !sched_feat(PREEMPT_RESTRICT);
if (now || p->prio < curr->prio || !se->peer_preempt++)
-
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/
PROBLEM: kernel panic
Machine lockup with caps lock/num lock flashing or complete reboot/panic. I get various lockup issues with this kernel, (2.6.23 also similar problem). I had problems getting e1000 lan module to work (it was fine in 2.6.21.5). I disabled it and installed a different lan card that seems to work "better". Dual head machine 1GB RAM, nvidia driver x86-100.14.19 Here is output of ver_linux: - Linux zion 2.6.23-rc9 #3 Fri Oct 12 18:27:56 PDT 2007 i686 GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP Linux C Library3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 105 Modules Loaded nfs lockd sunrpc nvidia i2c_core af_packet ipv6 capability commoncap ppdev lp ac battery dm_mod e1000 loop snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer parport_pc button parport snd 8250_pnp 8250 serial_core soundcore shpchp pci_hotplug snd_page_alloc rng_core floppy intel_agp agpgart rtc sg evdev sr_mod usbhid sd_mod ata_piix 8139too ata_generic ehci_hcd uhci_hcd mii bitrev crc32 libata generic usbcore thermal processor fan unix ext3 jbd piix ide_disk ide_cd cdrom ide_scsi scsi_mod ide_core - Here is output from syslog as it went down: Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: Oops: 0002 [#1] Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: CPU:0 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: EIP:0060:[]Tainted: PVLI Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: EFLAGS: 00010206 (2.6.23-rc9 #3) Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: EIP is at 0xe1168fde Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: esi: f8f34700 edi: ebp: 0001 esp: e7cf3e00 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: ds: 007b es: 007b fs: gs: 0033 ss: 0068 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: Process firefox-bin (pid: 8397, ti=e7cf2000 task=f258ca90 task.ti=e 7cf2000) Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: Stack: f8f18eb7 c01367f6 e7cf3e48 03e8 03e8 ed3e97c0 f1f6db 9c f1f6db9c Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel:e7cf3f54 f8f60ec2 0004257b f1f037dc e7cf3f 54 c01563d0 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel:019cc780 e7cf3eb0 c0155a63 dfff38c0 c014e001 019cc780 f1f037 dc dfe0ecf4 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: Call Trace: Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] rpcauth_lookupcred+0x63/0x87 [sunrpc] Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] pagevec_lookup+0x1c/0x22 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] nfs_permission+0xab/0x183 [nfs] Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] __d_lookup+0x8b/0xbf Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] dput+0x15/0xcb Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] nfs_permission+0x0/0x183 [nfs] Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] __link_path_walk+0x11c/0xa79 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] setup_sigcontext+0x104/0x187 Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] link_path_walk+0x42/0xaf Read from remote host 192.168.1.175: Connection reset by peer Connection to 192.168.1.175 closed. Message from [EMAIL PROTECTED] at Sat Oct 13 15:22:34 2007 ... zion kernel: [] permission+0x9e/0xdb /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.40GHz stepping: 7 cpu MHz : 2411.749 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags
Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
From: David Miller <[EMAIL PROTECTED]> Date: Sat, 13 Oct 2007 15:52:11 -0700 (PDT) > From: Komuro <[EMAIL PROTECTED]> > Date: Sun, 14 Oct 2007 07:36:58 +0900 BTW, even my reply didn't reach him, nifty.com reports "user unknown" for him. I really, truly, suspect therefore that he has other kinds of issues at his site :-) - 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: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
From: Komuro <[EMAIL PROTECTED]> Date: Sun, 14 Oct 2007 07:36:58 +0900 > > Dear David > > The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC." > is not very safe. > > With this patch, ftp-transfer stops in my system. > (vsftpd-2.0.5-8) > > Please revert this patch. No, I will not revert it with so little information, that would be a knee-jerk reaction. Let's anaylyze the problem first. Please: 1) Send this report to the correct place, which is [EMAIL PROTECTED], so that the networking developers can analyze the bug. Most of the core networking developers do not read linux-kernel so they did not see your report. 2) Provide a test case that the developers can use the precisely reproduce the problem. Your problem may be dependant upon the remote system or infrastructure such as firewalls that sit between your machine and the remote one, so it may instead be useful to provide a tcpdump of the failing transfer. I suspect some intermediate node, such as a firewall, is corrupting your connection and causing the transfer to fail, and thus reverting the BIC/CUBIC patch is just a workaround. There are no other reports like your's and that change has been in the tree for long enough to get substantial exposure. - 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/
[RFC][PATCH] sched: SCHED_FIFO watchdog timer
The below patch is an idea proposed by tglx and depends on sched-devel +
the hrtick patch previously posted.
The current watchdog action is to demote the task to SCHED_NORMAL,
however it might be wanted to deliver a signal instead (or have more per
task configuration state). Which is why I added Lennart to the CC list
as I gathered he would like something like this for PulseAudio.
---
Subject: sched: SCHED_FIFO watchdog timer
Set a per task (rlimit based) limit on SCHED_FIFO runtime. When the
limit is exceeded the task is demoted back to SCHED_NORMAL.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/asm-generic/resource.h |5 +++--
kernel/sched.c |5 +
kernel/sched_rt.c | 36
3 files changed, 44 insertions(+), 2 deletions(-)
Index: linux-2.6/include/asm-generic/resource.h
===
--- linux-2.6.orig/include/asm-generic/resource.h
+++ linux-2.6/include/asm-generic/resource.h
@@ -44,8 +44,8 @@
#define RLIMIT_NICE13 /* max nice prio allowed to raise to
0-39 for nice level 19 .. -20 */
#define RLIMIT_RTPRIO 14 /* maximum realtime priority */
-
-#define RLIM_NLIMITS 15
+#define RLIMIT_FIFOTIME15 /* timeout for fifo slices in
us */
+#define RLIM_NLIMITS 16
/*
* SuS says limits have to be unsigned.
@@ -86,6 +86,7 @@
[RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
[RLIMIT_NICE] = { 0, 0 }, \
[RLIMIT_RTPRIO] = { 0, 0 }, \
+ [RLIMIT_FIFOTIME] = { RLIM_INFINITY, RLIM_INFINITY }, \
}
#endif /* __KERNEL__ */
Index: linux-2.6/kernel/sched_rt.c
===
--- linux-2.6.orig/kernel/sched_rt.c
+++ linux-2.6/kernel/sched_rt.c
@@ -89,6 +89,14 @@ static struct task_struct *pick_next_tas
next->se.exec_start = rq->clock;
+ if (next->policy == SCHED_FIFO) {
+ unsigned long fifotime;
+
+ fifotime = rq->curr->signal->rlim[RLIMIT_FIFOTIME].rlim_cur;
+ if (fifotime != RLIM_INFINITY)
+ hrtick_start(rq, (u64)fifotime * 1000, 0);
+ }
+
return next;
}
@@ -194,8 +202,36 @@ load_balance_rt(struct rq *this_rq, int
return load_moved;
}
+#ifdef CONFIG_SCHED_HRT_TICK
+static int fifo_watchdog(struct rq *rq, struct task_struct *p, int queued)
+{
+ if (likely(!queued || p->policy != SCHED_FIFO))
+ return 0;
+
+ /*
+* task has been naughty, turn into SCHED_NORMAL
+*/
+ printk(KERN_INFO "SCHED_FIFO task %s/%d exceeded his runtime quota,"
+ " demoting to regular task\n", p->comm, task_pid_nr(p));
+ deactivate_task(rq, p, 0);
+ __setscheduler(rq, p, SCHED_NORMAL, 0);
+ activate_task(rq, p, 0);
+ resched_task(p);
+
+ return 1;
+}
+#else
+static inline int fifo_watchdog(struct rq *rq, struct task_struct *p, int
queued)
+{
+ return 0;
+}
+#endif
+
static void task_tick_rt(struct rq *rq, struct task_struct *p, int queued)
{
+ if (fifo_watchdog(rq, p, queued))
+ return;
+
/*
* RR tasks need a special form of timeslice management.
* FIFO tasks have no timeslices.
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -132,6 +132,11 @@ static inline void sg_inc_cpu_power(stru
}
#endif
+static void deactivate_task(struct rq *rq, struct task_struct *p, int sleep);
+static void activate_task(struct rq *rq, struct task_struct *p, int wakeup);
+static void
+__setscheduler(struct rq *rq, struct task_struct *p, int policy, int prio);
+
static inline int rt_policy(int policy)
{
if (unlikely(policy == SCHED_FIFO) || unlikely(policy == SCHED_RR))
-
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.23.1] possible circular locking dependency detected
I've got a deja-vu feeling for this one but in any case:
[ 7393.894980] ===
[ 7393.895081] [ INFO: possible circular locking dependency detected ]
[ 7393.895130] 2.6.23.1 #2
[ 7393.895175] ---
[ 7393.895225] moo/28246 is trying to acquire lock:
[ 7393.895275] (tty_mutex){--..}, at: [] mutex_lock+0x8/0xa
[ 7393.895486]
[ 7393.895487] but task is already holding lock:
[ 7393.895578] (>s_dquot.dqptr_sem){}, at: []
dquot_alloc_space+0x50/0x189
[ 7393.895784]
[ 7393.895785] which lock already depends on the new lock.
[ 7393.895788]
[ 7393.895915]
[ 7393.895916] the existing dependency chain (in reverse order) is:
[ 7393.896003]
[ 7393.896005] -> #3 (>s_dquot.dqptr_sem){}:
[ 7393.896209][] check_prev_add+0xc4/0x1fb
[ 7393.896555][] check_prevs_add+0x8b/0xe8
[ 7393.896890][] validate_chain+0x22b/0x354
[ 7393.897223][] __lock_acquire+0x1a0/0x74a
[ 7393.897553][] lock_acquire+0x6b/0x8a
[ 7393.897882][] down_read+0x2b/0x3d
[ 7393.898205][] dquot_alloc_space+0x50/0x189
[ 7393.898537][] ext3_new_blocks+0x44b/0x5a2
[ 7393.898868][] ext3_alloc_blocks+0x40/0xdf
[ 7393.899194][] ext3_alloc_branch+0x50/0x21b
[ 7393.899527][] ext3_get_blocks_handle+0x1b8/0x367
[ 7393.899858][] ext3_getblk+0x97/0x228
[ 7393.900186][] ext3_bread+0x1a/0x78
[ 7393.900514][] ext3_mkdir+0xf2/0x270
[ 7393.900851][] vfs_mkdir+0xb3/0x161
[ 7393.901174][] sys_mkdirat+0x8c/0xc4
[ 7393.901512][] sys_mkdir+0x20/0x22
[ 7393.901841][] syscall_call+0x7/0xb
[ 7393.902169][] 0x
[ 7393.902511]
[ 7393.902512] -> #2 (>truncate_mutex){--..}:
[ 7393.902706][] check_prev_add+0xc4/0x1fb
[ 7393.903033][] check_prevs_add+0x8b/0xe8
[ 7393.903364][] validate_chain+0x22b/0x354
[ 7393.903700][] __lock_acquire+0x1a0/0x74a
[ 7393.904353][] lock_acquire+0x6b/0x8a
[ 7393.904682][] __mutex_lock_slowpath+0x75/0x299
[ 7393.905015][] mutex_lock+0x8/0xa
[ 7393.905339][] ext3_get_blocks_handle+0xd9/0x367
[ 7393.905675][] ext3_get_block+0x78/0xe3
[ 7393.906009][] __block_prepare_write+0x168/0x415
[ 7393.906339][] block_prepare_write+0x28/0x3b
[ 7393.906673][] ext3_prepare_write+0xe3/0x17e
[ 7393.907002][] generic_file_buffered_write+0x1cb/0x62b
[ 7393.907333][] __generic_file_aio_write_nolock+0x23a/0x53d
[ 7393.907667][] generic_file_aio_write+0x58/0xc4
[ 7393.907998][] ext3_file_write+0x2d/0xba
[ 7393.908324][] do_sync_write+0xc7/0x116
[ 7393.908655][] vfs_write+0x158/0x15d
[ 7393.908981][] sys_write+0x3d/0x64
[ 7393.909310][] syscall_call+0x7/0xb
[ 7393.909635][] 0x
[ 7393.909974]
[ 7393.909976] -> #1 (>i_mutex){--..}:
[ 7393.910163][] check_prev_add+0xc4/0x1fb
[ 7393.910496][] check_prevs_add+0x8b/0xe8
[ 7393.910823][] validate_chain+0x22b/0x354
[ 7393.911152][] __lock_acquire+0x1a0/0x74a
[ 7393.911478][] lock_acquire+0x6b/0x8a
[ 7393.911807][] __mutex_lock_slowpath+0x75/0x299
[ 7393.912137][] mutex_lock+0x8/0xa
[ 7393.912465][] get_node+0x21/0x4d
[ 7393.912788][] devpts_get_tty+0xb/0x3b
[ 7393.913398][] init_dev+0x22b/0x58b
[ 7393.913718][] ptmx_open+0x90/0x1c9
[ 7393.913992][] chrdev_open+0xaf/0x171
[ 7393.914001][] __dentry_open+0x152/0x1d3
[ 7393.914008][] nameidata_to_filp+0x28/0x3f
[ 7393.914018][] do_filp_open+0x46/0x53
[ 7393.914024][] do_sys_open+0x54/0xda
[ 7393.914031][] sys_open+0x1c/0x1e
[ 7393.914038][] syscall_call+0x7/0xb
[ 7393.914046][] 0x
[ 7393.914069]
[ 7393.914070] -> #0 (tty_mutex){--..}:
[ 7393.914074][] check_prev_add+0x34/0x1fb
[ 7393.914084][] check_prevs_add+0x8b/0xe8
[ 7393.914092][] validate_chain+0x22b/0x354
[ 7393.914103][] __lock_acquire+0x1a0/0x74a
[ 7393.914111][] lock_acquire+0x6b/0x8a
[ 7393.914117][] __mutex_lock_slowpath+0x75/0x299
[ 7393.914126][] mutex_lock+0x8/0xa
[ 7393.914134][] print_warning+0x8c/0x15d
[ 7393.914143][] dquot_alloc_space+0x184/0x189
[ 7393.914154][] ext3_new_blocks+0x44b/0x5a2
[ 7393.914162][] ext3_alloc_blocks+0x40/0xdf
[ 7393.914170][] ext3_alloc_branch+0x50/0x21b
[ 7393.914177][] ext3_get_blocks_handle+0x1b8/0x367
[ 7393.914185][] ext3_get_block+0x78/0xe3
[ 7393.914195][] __block_prepare_write+0x168/0x415
[ 7393.914203][] block_prepare_write+0x28/0x3b
[ 7393.914211][] ext3_prepare_write+0xe3/0x17e
[ 7393.914218][] generic_file_buffered_write+0x1cb/0x62b
[ 7393.914226][] __generic_file_aio_write_nolock+0x23a/0x53d
[ 7393.914238][]
[NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
Dear David The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC." is not very safe. With this patch, ftp-transfer stops in my system. (vsftpd-2.0.5-8) Please revert this patch. Best Regards Komuro >commit 66e1e3b20cbbf99da63e6c1af0fc6d39c2ed099a >Author: David S. Miller <[EMAIL PROTECTED]> >Date: Wed Jun 13 01:03:53 2007 -0700 > >[TCP]: Set initial_ssthresh default to zero in Cubic and BIC. > >Because of the current default of 100, Cubic and BIC perform very >poorly compared to standard Reno. > >In the worst case, this change makes Cubic and BIC as aggressive as >Reno. So this change should be very safe. > >Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > >diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c >index 281c9f9..dd9ef65 100644 >--- a/net/ipv4/tcp_bic.c >+++ b/net/ipv4/tcp_bic.c >@@ -29,7 +29,7 @@ static int fast_convergence = 1; > static int max_increment = 16; > static int low_window = 14; > static int beta = 819;/* = 819/1024 (BICTCP_BETA_SCALE) */ >-static int initial_ssthresh = 100; >+static int initial_ssthresh; > static int smooth_part = 20; > > module_param(fast_convergence, int, 0644); >diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c >index 1422448..ebfaac2 100644 >--- a/net/ipv4/tcp_cubic.c >+++ b/net/ipv4/tcp_cubic.c >@@ -29,7 +29,7 @@ > static int fast_convergence __read_mostly = 1; > static int max_increment __read_mostly = 16; > static int beta __read_mostly = 819; /* = 819/1024 (BICTCP_BETA_SCALE) */ >-static int initial_ssthresh __read_mostly = 100; >+static int initial_ssthresh __read_mostly; > static int bic_scale __read_mostly = 41; > static int tcp_friendliness __read_mostly = 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/
Re: [git patches] IDE updates (part 2)
On Sunday 14 October 2007, Alan Cox wrote: > > > > /* Probably a PCI interface... */ > > > > for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; ++i) > > > > hw->io_ports[i] = data_port + i - > > > > IDE_DATA_OFFSET; > > > > hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; > > Ok so in actual fact > > - The piece of code above can't be executed anyway > - The ctrl_port argument is not needed ? pmac_ide_init_hwif_ports() is also called by ide_init_hwif_ports() through ppc_ide_md.init_hwif. 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: [git patches] IDE updates (part 2)
> > > /* Probably a PCI interface... */ > > > for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; ++i) > > > hw->io_ports[i] = data_port + i - IDE_DATA_OFFSET; > > > hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; Ok so in actual fact - The piece of code above can't be executed anyway - The ctrl_port argument is not needed ? Alan - 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] NTFS error messages: replace static char pointers by static char arrays
>>> The patch below contains a small code clean-up for the NTFS driver: all >>> static char pointers to error message strings have been replaced by >>> static char arrays. While doing that clean-up, shouldn't these be converted as well? [EMAIL PROTECTED]:/usr/src/linux$ find . -name \*.c -print0 | xargs -0 grep "^ *char *\* *[a-zA-Z0-9_]* *= *\".*\".*;" ./arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c:char *toshiba_name = ""; ./arch/ppc/boot/simple/misc-embedded.c:char *bootrom_cmdline = ""; ./arch/blackfin/mach-bf561/boards/ezkit.c:char *bfin_board_name = "ADDS-BF561-EZKIT"; ./arch/blackfin/mach-bf561/boards/generic_board.c:char *bfin_board_name = "UNKNOWN BOARD"; ./arch/blackfin/mach-bf561/boards/tepla.c:char *bfin_board_name = "Tepla-BF561"; ./arch/blackfin/mach-bf561/boards/cm_bf561.c:char *bfin_board_name = "Bluetechnix CM BF561"; ./arch/blackfin/mach-bf533/boards/ezkit.c:char *bfin_board_name = "ADDS-BF533-EZKIT"; ./arch/blackfin/mach-bf533/boards/cm_bf533.c:char *bfin_board_name = "Bluetechnix CM BF533"; ./arch/blackfin/mach-bf533/boards/stamp.c:char *bfin_board_name = "ADDS-BF533-STAMP"; ./arch/blackfin/mach-bf533/boards/generic_board.c:char *bfin_board_name = "UNKNOWN BOARD"; ./arch/blackfin/mach-bf537/boards/stamp.c:char *bfin_board_name = "ADDS-BF537-STAMP"; ./arch/blackfin/mach-bf537/boards/generic_board.c:char *bfin_board_name = "UNKNOWN BOARD"; ./arch/blackfin/mach-bf537/boards/pnav10.c:char *bfin_board_name = "PNAV-1.0"; ./arch/blackfin/mach-bf537/boards/cm_bf537.c:char *bfin_board_name = "Bluetechnix CM BF537"; ./arch/blackfin/mach-bf548/boards/ezkit.c:char *bfin_board_name = "ADSP-BF548-EZKIT"; ./drivers/net/pcmcia/fmvj18x_cs.c:char *card_name = "unknown"; ./drivers/atm/fore200e_mkfirm.c:char* default_basename = "pca200e"; /* was initially written for the PCA-200E firmware */ ./drivers/atm/fore200e_mkfirm.c:char* default_infname = ""; ./drivers/atm/fore200e_mkfirm.c:char* default_outfname = ""; ./drivers/scsi/aic7xxx_old.c: char *channel = ""; ./drivers/scsi/aic7xxx_old/aic7xxx_proc.c:char *channel = ""; ./drivers/scsi/aic7xxx_old/aic7xxx_proc.c:char *ultra = ""; ./drivers/scsi/aic7xxx_old/aic7xxx_proc.c:char *wide = "Narrow "; ./drivers/isdn/i4l/isdn_ppp.c:char *isdn_ppp_revision = "$Revision: 1.1.2.3 $"; ./drivers/isdn/i4l/isdn_tty.c:char *isdn_tty_revision = "$Revision: 1.1.2.3 $"; ./drivers/isdn/i4l/isdn_net.c:char *isdn_net_revision = "$Revision: 1.1.2.2 $"; ./drivers/isdn/i4l/isdn_audio.c:char *isdn_audio_revision = "$Revision: 1.1.2.2 $"; ./drivers/isdn/i4l/isdn_v110.c:char *isdn_v110_revision = "$Revision: 1.1.2.2 $"; ./drivers/isdn/hysdn/hysdn_net.c:char *hysdn_net_revision = "$Revision: 1.8.6.4 $"; ./drivers/isdn/hardware/eicon/diva_didd.c:char *DRIVERRELEASE_DIDD = "2.0"; ./drivers/isdn/hardware/eicon/divasmain.c:char *DRIVERRELEASE_DIVAS = "2.0"; ./drivers/isdn/hardware/eicon/divasi.c:char *DRIVERRELEASE_IDI = "2.0"; ./drivers/isdn/hardware/eicon/divamnt.c:char *DRIVERRELEASE_MNT = "2.0"; ./drivers/serial/mcfserial.c:char *mcfrs_drivername = "ColdFire internal UART serial driver version 1.00\n"; Folkert van Heusden -- MultiTail is a versatile tool for watching logfiles and output of commands. Filtering, coloring, merging, diff-view, etc. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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/
[2.6.23-mm1] CONFIG_LOCALVERSION handling broken
Something seems to be amiss with CONFIG_LOCALVERSION handling.
I am routinely building with
CONFIG_LOCALVERSION="-testing"
CONFIG_LOCALVERSION_AUTO=y
My usual sequence of "make ; sudo make modules_install install"
has worked fine for all of 2.6.23{-rc?{,-mm?},}. For 2.6.23-mm1
it fails with:
[EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> sudo make modules_install
install
root's password:
INSTALL arch/i386/crypto/aes-i586.ko
[...]
INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map
2.6.23-mm1; fi
sh /home/ts/kernel/linux-2.6.23-mm1-work/arch/i386/boot/install.sh 2.6.23-mm1
arch/i386/boot/bzImage System.map "/boot"
Root device:/dev/system/root (mounted on / as ext3)
Module list:processor thermal ahci pata_marvell aic7xxx fan jbd ext3 dm_mod
edd dm-mod dm-snapshot (xennet xenblk dm-mod dm-snapshot)
Kernel image: /boot/vmlinuz-2.6.23-mm1
Initrd image: /boot/initrd-2.6.23-mm1
No modules found for kernel 2.6.23-mm1-testing
[EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work>
That is, both "make modules_install" and "make install" omit
the "-testing" suffix, "make modules_install" installing the
modules into /lib/modules/2.6.23-mm1 instead of
/lib/modules/2.6.23-mm1-testing, and "make install" passing
"2.6.23-mm1" without the "-testing" suffix to the install.sh
script, but mkinitrd suddenly rediscovers the real kernel
version string and consequently looks for modules in
/lib/modules/2.6.23-mm1-testing, so initrd creation fails.
Ideas?
--
Tilman Schmidt E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
signature.asc
Description: OpenPGP digital signature
[GIT PULL] i2c updates for 2.6.24
Linus, Please pull the i2c subsystem updates for Linux 2.6.24 from: git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus There is one new I2C bus driver (i2c-davinci), support for the Intel Tolapai SMBus, some more conversions to the new i2c model, and a dozen random fixes and cleanups. Documentation/i2c/busses/i2c-i801 |3 +- Documentation/i2c/chips/pcf8574|8 +- Documentation/i2c/dev-interface| 11 +- Documentation/i2c/i2c-stub | 18 +- arch/arm/mach-omap1/board-h2.c | 45 ++- arch/arm/mach-omap1/board-h3.c | 39 ++- arch/arm/mach-omap1/board-osk.c| 64 +++- drivers/i2c/busses/Kconfig | 23 +- drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-amd8111.c |2 +- drivers/i2c/busses/i2c-au1550.c| 11 +- drivers/i2c/busses/i2c-bfin-twi.c | 16 - drivers/i2c/busses/i2c-davinci.c | 586 drivers/i2c/busses/i2c-i801.c |5 +- drivers/i2c/busses/i2c-ibm_iic.c |9 +- drivers/i2c/busses/i2c-iop3xx.c|8 - drivers/i2c/busses/i2c-nforce2.c | 83 +++- drivers/i2c/busses/i2c-stub.c | 79 +++- drivers/i2c/chips/pcf8574.c| 14 +- drivers/i2c/chips/tps65010.c | 299 drivers/i2c/i2c-core.c | 50 +-- drivers/i2c/i2c-dev.c | 20 +- drivers/media/video/bt8xx/bttv-i2c.c |7 - drivers/media/video/cx23885/cx23885-i2c.c |7 - drivers/media/video/em28xx/em28xx-i2c.c| 10 - drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |7 - drivers/media/video/saa7134/saa7134-i2c.c |7 - drivers/media/video/usbvision/usbvision-i2c.c |6 - drivers/media/video/w9968cf.c | 11 - include/asm-arm/arch-davinci/i2c.h | 21 + include/linux/i2c-dev.h| 31 ++- include/linux/i2c.h| 102 ++--- include/linux/mod_devicetable.h|5 - scripts/mod/file2alias.c | 11 - 34 files changed, 1154 insertions(+), 465 deletions(-) create mode 100644 drivers/i2c/busses/i2c-davinci.c create mode 100644 include/asm-arm/arch-davinci/i2c.h --- Adrian Bunk (1): i2c-core: Make some code static Chris David (1): i2c-au1550: Fix a misused register problem David Brownell (10): i2c: New-style devices can support driver model wakeup flags i2c/tps65010: New-style driver updates, part 1 i2c/tps65010: New-style driver updates, part 2 i2c: Document struct i2c_msg i2c-dev: Reject I2C_M_RECV_LEN i2c: Remove NOP i2c_algorithm.algo_control() methods i2c: Remove i2c_algorithm.algo_control() i2c: Move i2c-dev interfaces to i2c-dev.h i2c-at91: Mark as broken i2c: Rename the PEC functionality bit Francis Moreau (1): i2c-bfin-twi: Remove useless twi_lock mutex Jason Gaston (1): i2c-i801: Add support for the Intel Tolapai SMBus Jean Delvare (5): i2c: Kill struct i2c_device_id i2c/pcf8574: No arbitrary initialization i2c-stub: Support multiple chips cx23885: Drop empty i2c algorithm control callback i2c-nforce2: Declare PEC as supported Oleg Ryjkov (2): i2c-nforce2: Move status checking to a separate function i2c-nforce2: Abort the transaction on error Stefan Roese (1): i2c-ibm_iic: Add support for new-style clients Vladimir Barinov (1): i2c: Add DaVinci I2C controller support 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/
Re: What still uses the block layer?
On Thu, Oct 11, 2007 at 08:11:21PM -0500, Rob Landley wrote: > My impression from asking questions on the linux-scsi mailing list is that > the > scsi upper/middle/lower layers doesn't use the block layer described in > Documentation/block/*. Entirely incorrect. > Instead of using the block layer, SCSI reinvents this particular wheel > itself. > There's a scsi "upper layer" that provides /dev nodes, scsi low-level > drivers, and a gigantic glue layer in between call the "scsi midlayer" that's > something like a networking stack, and is responsible for losing track of all > your devices so that the one SATA disk hardwired into your laptop might be > sda or sdc depending on whether or not you had a USB key plugged in when you > booted up. Anyway, the block layer isn't between any of these three, that I > can tell. You really need to get the fuck over yourself. > Now that IDE disks have been rerouted through the scsi layer, SATA goes > through the scsi layer, USB goes through the scsi layer, firewire goes > through the scsi layer... What's left? It seems like everything but > ramdisks have now been routed through the scsi layer. My laptop hasn't got a > single SCSI device but it also hasn't got any block devices that don't show > up as scsi. That's nice. Why not take a look in drivers/block? Floppy, CCISS, CPQDA, UMEM, UBD, loop, NBD, SX8, UB, AoE, and many more. > So what's still using the block layer? How do the scsi layers and the block > layer relate? I'm confused! (This is normal for me, but still...) sd and sr are block drivers. In fact, the whole SCSI subsystem ... depends on BLOCK Just take a look at sd.c. The init code reads: for (i = 0; i < SD_MAJORS; i++) if (register_blkdev(sd_major(i), "sd") == 0) majors++; Then look at struct scsi_cmnd. It has a pointer to the block request that was passed down to it. struct scsi_device has a pointer to the block request_queue that's associated with the device. Block is what has elevators and io schedulers -- that work isn't duplicated by scsi. There's work to push more of scsi's infrastructure up into the block layer, so non-scsi block devices can take advantage of it. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] IDE updates (part 2)
On Saturday 13 October 2007, Alan Cox wrote:
> > Comment in pmac_ide_init_hwif_ports() is highly misleading as this function
> > returns early only for "normal" IDE PCI devices (pmac_ide_init_hwif_ports()
> > can be called outside ide-pmac driver through ppc_ide_md).
>
> Follow the code you pasted
>
> > pmif->regbase = (unsigned long) base + 0x2000;
> > ...
> > rc = pmac_ide_setup_device(pmif, hwif);
>
> Ok so regbase is set
>
> > ...
> > }
> >
> > static int
> > pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
> > {
> > ...
> > pmac_ide_init_hwif_ports(>hw, pmif->regbase, 0, >irq);
>
> Now we pass a honking great zero for the ctrl_port
> > ...
> > }
> >
> > void
> > pmac_ide_init_hwif_ports(hw_regs_t *hw,
> > unsigned long data_port, unsigned long ctrl_port,
> > int *irq)
> > {
> > ...
> > for (ix = 0; ix < MAX_HWIFS; ++ix)
this loop is a tricky part, regbase is set so we break out early
> > if (data_port == pmac_ide[ix].regbase)
> > break;
> > ---> since pmif->regbase was set earlier ix will be < MAX_HWIFS
^^
> > if (ix >= MAX_HWIFS) {
^^^
> > /* Probably a PCI interface... */
> > for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; ++i)
> > hw->io_ports[i] = data_port + i - IDE_DATA_OFFSET;
> > hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
>
> Which is zero..
>
>
> See the problem ?
-
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.23-rc4-mm1 myri10ge module link error on x86_64
On 9/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > David Miller wrote: > > From: David Miller <[EMAIL PROTECTED]> > > Date: Thu, 06 Sep 2007 13:40:38 -0700 (PDT) > > > >> From: Mathieu Desnoyers <[EMAIL PROTECTED]> > >> Date: Thu, 6 Sep 2007 15:37:51 -0400 > >> > >>> I got a link error on myri10ge when building 2.6.23-rc4-mm1 on x86_64 : > >>> > >>> ERROR: "lro_flush_all" [drivers/net/myri10ge/myri10ge.ko] undefined! > >>> ERROR: "lro_receive_frags" [drivers/net/myri10ge/myri10ge.ko] undefined! > >>> make[2]: *** [__modpost] Error 1 > >>> make[1]: *** [modules] Error 2 > >>> make: *** [_all] Error 2 > >> myri10ge needs some LRO ifdeffery. > > > > Actually the fix is even simpler, missing select in Kconfig. > > > > I've checked the following fix for this into the net-2.6.24 > > tree. > > > > commit 9fd380e892e078b582920325357292c07cc9 > > Author: David S. Miller <[EMAIL PROTECTED](none)> > > Date: Thu Sep 6 21:44:36 2007 +0100 > > > > [MYRI10GE]: Need to select INET_LRO. > > > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > > index b92b7dc..7d1a84e 100644 > > --- a/drivers/net/Kconfig > > +++ b/drivers/net/Kconfig > > @@ -2496,6 +2496,7 @@ config MYRI10GE > > depends on PCI > > select FW_LOADER > > select CRC32 > > + select INET_LRO > > Yes, that's the correct fix. ACK. This bug still exists, though now it is in mainline. I just bisected to it with this config[1], unless, of course randconfig is still making bad configs. Errors out with: drivers/built-in.o: In function `myri10ge_poll': myri10ge.c:(.text+0xce259): undefined reference to `lro_receive_frags' myri10ge.c:(.text+0xce37c): undefined reference to `lro_flush_all' It bisects back to this with this: [EMAIL PROTECTED] /tmp/tester/linux-2.6 $ git-bisect bad 1e6e9342d41ff80ced0ad5dfcf084926700cdfc5 is first bad commit commit 1e6e9342d41ff80ced0ad5dfcf084926700cdfc5 Author: Andrew Gallatin <[EMAIL PROTECTED]> Date: Mon Sep 17 11:37:42 2007 -0700 [MYRI10GE]: Use LRO. Singed off by: Andrew Gallatin <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> This is with linux-2.6.git master: 8d8fe64237646fdd2c2de2722ec4189a5999119d [1] http://avuton.googlepages.com/undef-reference-lro_receive_frags.config -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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: [git patches] IDE updates (part 2)
> Comment in pmac_ide_init_hwif_ports() is highly misleading as this function
> returns early only for "normal" IDE PCI devices (pmac_ide_init_hwif_ports()
> can be called outside ide-pmac driver through ppc_ide_md).
Follow the code you pasted
> pmif->regbase = (unsigned long) base + 0x2000;
> ...
> rc = pmac_ide_setup_device(pmif, hwif);
Ok so regbase is set
> ...
> }
>
> static int
> pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
> {
> ...
> pmac_ide_init_hwif_ports(>hw, pmif->regbase, 0, >irq);
Now we pass a honking great zero for the ctrl_port
> ...
> }
>
> void
> pmac_ide_init_hwif_ports(hw_regs_t *hw,
> unsigned long data_port, unsigned long ctrl_port,
> int *irq)
> {
> ...
> for (ix = 0; ix < MAX_HWIFS; ++ix)
> if (data_port == pmac_ide[ix].regbase)
> break;
> ---> since pmif->regbase was set earlier ix will be < MAX_HWIFS
> if (ix >= MAX_HWIFS) {
> /* Probably a PCI interface... */
> for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; ++i)
> hw->io_ports[i] = data_port + i - IDE_DATA_OFFSET;
> hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
Which is zero..
See the problem ?
Alan
-
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] ohci-ssb with !CONFIG_PM
ohci_bus_{suspend,resume} exists only if we have CONFIG_PM;
do the same thing as other subdrivers...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
b0b4f616f9ca381aa6a8559923137ce7cadc4108
diff --git a/drivers/usb/host/ohci-ssb.c b/drivers/usb/host/ohci-ssb.c
index bc3e785..fe70e72 100644
--- a/drivers/usb/host/ohci-ssb.c
+++ b/drivers/usb/host/ohci-ssb.c
@@ -117,8 +117,10 @@ static const struct hc_driver ssb_ohci_hc_driver = {
.hub_status_data= ohci_hub_status_data,
.hub_control= ohci_hub_control,
.hub_irq_enable = ohci_rhsc_enable,
+#ifdef CONFIG_PM
.bus_suspend= ohci_bus_suspend,
.bus_resume = ohci_bus_resume,
+#endif
.start_port_reset = ohci_start_port_reset,
};
-
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] please pull infiniband.git for-linus
Linus, please pull from master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This tree is also available from kernel.org mirrors at: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This will get one bug fix for a problem that completely kills the mlx4 driver: Roland Dreier (1): mlx4_core: Fix infinite loop on device initialization drivers/net/mlx4/main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c index e029b8a..89b3f0b 100644 --- a/drivers/net/mlx4/main.c +++ b/drivers/net/mlx4/main.c @@ -884,7 +884,7 @@ static int __devinit mlx4_init_one(struct pci_dev *pdev, ++mlx4_version_printed; } - return mlx4_init_one(pdev, id); + return __mlx4_init_one(pdev, id); } static void mlx4_remove_one(struct pci_dev *pdev) - 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: x86: merge some trivially mergeable headers
On Sat, 13 Oct 2007, Roland Dreier wrote: > Merge errno.h, resource.h, rtc.h, sections.h, serial.h and sockios.h, > where i386 and x86_64 have no or only trivial comment/include guard > differences. > > Build tested on both 32-bit and 64-bit, and booted on 64-bit. > > Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> > --- > Not sure who's merging this type of stuff so I just picked a grab bag > of people to put on the To: line. > > Also I'm not sure if someone else is already working on this, so I'm > just sending out about 15 minutes of work. If this is helpful I'll do > more of the easy ones... Roland, thanks for providing this. I have some of those already, but I really appreciate the help. I take yours and the previously posted and push them out into a cleanup branch on my x86 git tree. I guess it will be unavoidable that there will be some overlap on the low hanging fruit merges, but anyone who is tackling a more complex one should make this public upfront so we can avoid the redundant work. Thanks, tglx - 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: [git patches] IDE updates (part 2)
On Saturday 13 October 2007, Alan Cox wrote:
> On Sat, 13 Oct 2007 18:25:24 +0200
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi,
> >
> > highlights of this update:
> >
> > * Rework of IDE PMAC host driver: bugfixes, removal of the code
> > duplicated from the IDE core and conversion to use the generic
> > DMA tuning code path (the rework cuts ide-pmac.c by ~200 LOC).
>
> Reading the current driver from the git tree I don't see how the PCI
> driver ever sets the ctl register base. It seems to always be set to zero
> which means you can't issue SRST and reset sequences ?
Hi Alan,
Comment in pmac_ide_init_hwif_ports() is highly misleading as this function
returns early only for "normal" IDE PCI devices (pmac_ide_init_hwif_ports()
can be called outside ide-pmac driver through ppc_ide_md).
static int __devinit
pmac_ide_pci_attach(struct pci_dev *pdev, const struct pci_device_id *id)
{
...
pmif = _ide[i];
...
pmif->regbase = (unsigned long) base + 0x2000;
...
rc = pmac_ide_setup_device(pmif, hwif);
...
}
static int
pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
{
...
pmac_ide_init_hwif_ports(>hw, pmif->regbase, 0, >irq);
...
}
void
pmac_ide_init_hwif_ports(hw_regs_t *hw,
unsigned long data_port, unsigned long ctrl_port,
int *irq)
{
...
for (ix = 0; ix < MAX_HWIFS; ++ix)
if (data_port == pmac_ide[ix].regbase)
break;
---> since pmif->regbase was set earlier ix will be < MAX_HWIFS
if (ix >= MAX_HWIFS) {
/* Probably a PCI interface... */
for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; ++i)
hw->io_ports[i] = data_port + i - IDE_DATA_OFFSET;
hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
return;
}
for (i = 0; i < 8; ++i)
hw->io_ports[i] = data_port + i * 0x10;
---> ctl register base will be set here
hw->io_ports[8] = data_port + 0x160;
...
}
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/
x86: merge some trivially mergeable headers
Merge errno.h, resource.h, rtc.h, sections.h, serial.h and sockios.h, where i386 and x86_64 have no or only trivial comment/include guard differences. Build tested on both 32-bit and 64-bit, and booted on 64-bit. Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- Not sure who's merging this type of stuff so I just picked a grab bag of people to put on the To: line. Also I'm not sure if someone else is already working on this, so I'm just sending out about 15 minutes of work. If this is helpful I'll do more of the easy ones... include/asm-x86/errno.h | 19 --- include/asm-x86/errno_32.h|6 -- include/asm-x86/errno_64.h|6 -- include/asm-x86/resource.h| 19 --- include/asm-x86/resource_32.h |6 -- include/asm-x86/resource_64.h |6 -- include/asm-x86/rtc.h | 15 ++- include/asm-x86/rtc_32.h | 10 -- include/asm-x86/rtc_64.h | 10 -- include/asm-x86/sections.h|9 + include/asm-x86/sections_32.h |7 --- include/asm-x86/sections_64.h |7 --- include/asm-x86/serial.h | 30 +++--- include/asm-x86/serial_32.h | 29 - include/asm-x86/serial_64.h | 29 - include/asm-x86/sockios.h | 26 +++--- include/asm-x86/sockios_32.h | 13 - include/asm-x86/sockios_64.h | 13 - 18 files changed, 73 insertions(+), 187 deletions(-) delete mode 100644 include/asm-x86/errno_32.h delete mode 100644 include/asm-x86/errno_64.h delete mode 100644 include/asm-x86/resource_32.h delete mode 100644 include/asm-x86/resource_64.h delete mode 100644 include/asm-x86/rtc_32.h delete mode 100644 include/asm-x86/rtc_64.h delete mode 100644 include/asm-x86/sections_32.h delete mode 100644 include/asm-x86/sections_64.h delete mode 100644 include/asm-x86/serial_32.h delete mode 100644 include/asm-x86/serial_64.h delete mode 100644 include/asm-x86/sockios_32.h delete mode 100644 include/asm-x86/sockios_64.h diff --git a/include/asm-x86/errno.h b/include/asm-x86/errno.h index 9d511be..e06fe53 100644 --- a/include/asm-x86/errno.h +++ b/include/asm-x86/errno.h @@ -1,13 +1,10 @@ #ifdef __KERNEL__ -# ifdef CONFIG_X86_32 -# include "errno_32.h" -# else -# include "errno_64.h" -# endif -#else -# ifdef __i386__ -# include "errno_32.h" -# else -# include "errno_64.h" -# endif + +#ifndef _ASM_X86_ERRNO_H +#define _ASM_X86_ERRNO_H + +#include + +#endif /* _ASM_X86_ERRNO_H */ + #endif diff --git a/include/asm-x86/errno_32.h b/include/asm-x86/errno_32.h deleted file mode 100644 index 969b343..000 --- a/include/asm-x86/errno_32.h +++ /dev/null @@ -1,6 +0,0 @@ -#ifndef _I386_ERRNO_H -#define _I386_ERRNO_H - -#include - -#endif diff --git a/include/asm-x86/errno_64.h b/include/asm-x86/errno_64.h deleted file mode 100644 index 3111821..000 --- a/include/asm-x86/errno_64.h +++ /dev/null @@ -1,6 +0,0 @@ -#ifndef _X8664_ERRNO_H -#define _X8664_ERRNO_H - -#include - -#endif diff --git a/include/asm-x86/resource.h b/include/asm-x86/resource.h index 732410a..df20199 100644 --- a/include/asm-x86/resource.h +++ b/include/asm-x86/resource.h @@ -1,13 +1,10 @@ #ifdef __KERNEL__ -# ifdef CONFIG_X86_32 -# include "resource_32.h" -# else -# include "resource_64.h" -# endif -#else -# ifdef __i386__ -# include "resource_32.h" -# else -# include "resource_64.h" -# endif + +#ifndef _ASM_X86_RESOURCE_H +#define _ASM_X86_RESOURCE_H + +#include + +#endif /* _ASM_X86_RESOURCE_H */ + #endif diff --git a/include/asm-x86/resource_32.h b/include/asm-x86/resource_32.h deleted file mode 100644 index 6c1ea37..000 --- a/include/asm-x86/resource_32.h +++ /dev/null @@ -1,6 +0,0 @@ -#ifndef _I386_RESOURCE_H -#define _I386_RESOURCE_H - -#include - -#endif diff --git a/include/asm-x86/resource_64.h b/include/asm-x86/resource_64.h deleted file mode 100644 index f40b406..000 --- a/include/asm-x86/resource_64.h +++ /dev/null @@ -1,6 +0,0 @@ -#ifndef _X8664_RESOURCE_H -#define _X8664_RESOURCE_H - -#include - -#endif diff --git a/include/asm-x86/rtc.h b/include/asm-x86/rtc.h index 1f0c98e..70838ea 100644 --- a/include/asm-x86/rtc.h +++ b/include/asm-x86/rtc.h @@ -1,5 +1,10 @@ -#ifdef CONFIG_X86_32 -# include "rtc_32.h" -#else -# include "rtc_64.h" -#endif +#ifndef _ASM_X86_RTC_H +#define _ASM_X86_RTC_H + +/* + * x86 uses the default access methods for the RTC. + */ + +#include + +#endif /* _ASM_X86_RTC_H */ diff --git a/include/asm-x86/rtc_32.h b/include/asm-x86/rtc_32.h deleted file mode 100644 index ffd0210..000 --- a/include/asm-x86/rtc_32.h +++ /dev/null @@ -1,10 +0,0 @@ -#ifndef _I386_RTC_H -#define _I386_RTC_H - -/* - * x86 uses the default access methods for the RTC. - */ - -#include - -#endif diff --git a/include/asm-x86/rtc_64.h b/include/asm-x86/rtc_64.h deleted file mode 100644 index 18ed713..000 ---
Re: [PATCH] missing includes in arch/powerpc/platforms/52xx/lite5200.c
On Sat, Oct 13, 2007 at 02:35:26PM -0600, Grant Likely wrote: > On 10/13/07, Al Viro <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > > Nak, this patch should be used to fix it instead. A change to > lite5200 got dropped during merging. > > http://patchwork.ozlabs.org/linuxppc/patch?id=14077 Fine by me. - 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: regression(?): starting with 2.6.21 sending packets became broken.
On Oct 13 2007 19:59, David wrote: >Try > >echo 0 > /proc/sys/net/ipv4/tcp_window_scaling > >I bet you have broken router(s) between your machine and the problem >site(s). There is an xt_TCPOPTSTRIP module in the works that allows you to strip Window Scaling only on the connections you want (rather than globally); seems to be in for 2.6.24 at earliest, though it's there is also the standalone patch. - 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] missing includes in arch/powerpc/platforms/52xx/lite5200.c
On 10/13/07, Al Viro <[EMAIL PROTECTED]> wrote: > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Nak, this patch should be used to fix it instead. A change to lite5200 got dropped during merging. http://patchwork.ozlabs.org/linuxppc/patch?id=14077 Cheers, g. > --- > diff --git a/arch/powerpc/platforms/52xx/lite5200.c > b/arch/powerpc/platforms/52xx/lite5200.c > index 0caa3d9..774f249 100644 > --- a/arch/powerpc/platforms/52xx/lite5200.c > +++ b/arch/powerpc/platforms/52xx/lite5200.c > @@ -18,6 +18,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > ___ > Linuxppc-dev mailing list > [EMAIL PROTECTED] > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 - 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] Input updates for 2.6.24-rc0
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get a bunch new drivers, fixes for existing ones and also input core will finally have proper locking. Changelog: - Adrian McMenamin (1): Input: add support for SEGA Dreamcast keyboard Alon Ziv (1): Input: psmouse - reset harder during probe Andreas Herrmann (1): Input: auto-select INPUT for MAC_EMUMOUSEBTN option Andrew McNabb (1): Input: adbhid - produce all CapsLock key events Andrew Morton (1): Input: iforce - de-dosify iforce-protocol.txt Anti Sullin (2): Input: gpio_keys - verify that supplied GPIO numbers are valid Input: gpio-keys - add suspend/resume support Daniel Ritz (1): Input: usbtouchscreen - support DMC devices with empty EEPROM Dmitry Torokhov (18): Input: xpad - use le16_to_cpup when parsing data stream Input: mark some functions __must_check Input: implement proper locking in input core Input: evdev - implement proper locking Input: mousedev - implement proper locking Input: joydev - implement proper locking Input: tsdev - implement proper locking Input: remove ec3104_keyb driver Input: lifebook - add signature of Panasonic CF-72 HWMON: applesmc - convert to use input-polldev HWMON: ams - convert to use input-polldev Input: xpad - fix dependancy on LEDS class Input: jornada720_kbd - send MSC_SCAN events Input: ALPS - add signature for ThinkPad R61 Input: lifebook - fix X and Y axis range Input: omap-keyboard - don't pretend we support changing keymap HWMON: hdaps - switch to using input-polldev Input: use full RCU API Ilya Frolov (1): Input: usbtouchscreen - add support for GeneralTouch devices Kristoffer Ericson (3): Input: add support for HP Jornada onboard keyboard (HP6XX) Input: add support for HP Jornada 7xx onboard keyboard Input: add support for the HP Jornada 7xx (710/720/728) touchscreen Markus Armbruster (1): Input: i8042 - restore control register when enabling port fails Michael Hennerich (1): Input: add support for Blackfin BF54x Keypad controller Oliver Neukum (1): Input: fix open count handling in input interfaces Ondrej Zary (1): Input: usbtouchscreen - add support for IdealTEK URTC1000 Rene Herman (1): Input: ucb1400_ts - use schedule_timeout_uninterruptible Richard Purdie (1): Input: remove tsdev interface Samuel Thibault (1): Input: keyboard - add CapsShift lock Soeren Sonnenburg (1): Input: appletouch - another fix for idle reset logic Stephen Hemminger (1): Input: polled device power saving William Pettersson (1): Input: ALPS - add support for model found in Dell Vostro 1400 Diffstat: Documentation/feature-removal-schedule.txt | 14 - Documentation/kernel-parameters.txt |3 - arch/blackfin/mach-bf548/boards/ezkit.c |6 +- drivers/char/ec3104_keyb.c | 457 drivers/hwmon/Kconfig|3 + drivers/hwmon/ams/ams-input.c| 76 ++-- drivers/hwmon/ams/ams.h |5 +- drivers/hwmon/applesmc.c | 83 +-- drivers/hwmon/hdaps.c| 55 +-- drivers/input/Kconfig| 22 - drivers/input/Makefile |1 - drivers/input/evdev.c| 708 drivers/input/input-polldev.c|7 +- drivers/input/input.c| 660 +-- drivers/input/joydev.c | 743 +- drivers/input/joystick/xpad.c| 55 ++- drivers/input/keyboard/Kconfig | 40 ++ drivers/input/keyboard/Makefile |5 +- drivers/input/keyboard/bf54x-keys.c | 382 + drivers/input/keyboard/gpio_keys.c | 81 +++- drivers/input/keyboard/jornada680_kbd.c | 277 ++ drivers/input/keyboard/jornada720_kbd.c | 185 +++ drivers/input/keyboard/maple_keyb.c | 252 + drivers/input/keyboard/omap-keypad.c | 22 +- drivers/input/mouse/alps.c |2 + drivers/input/mouse/appletouch.c | 15 +- drivers/input/mouse/lifebook.c | 10 +- drivers/input/mouse/psmouse-base.c |5 +- drivers/input/mousedev.c | 740 -- drivers/input/serio/i8042.c |4 + drivers/input/touchscreen/Kconfig| 21 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/jornada720_ts.c| 182 +++
Re: [git patches] IDE updates (part 2)
On Sat, 13 Oct 2007 18:25:24 +0200 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > Hi, > > highlights of this update: > > * Rework of IDE PMAC host driver: bugfixes, removal of the code > duplicated from the IDE core and conversion to use the generic > DMA tuning code path (the rework cuts ide-pmac.c by ~200 LOC). Reading the current driver from the git tree I don't see how the PCI driver ever sets the ctl register base. It seems to always be set to zero which means you can't issue SRST and reset sequences ? - 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.23-git3 jfs/bio bug
On Sat, 13 Oct 2007, Dave Kleikamp wrote: > > commit 6712ecf8f648118c3363c142196418f89a510b90 removed some "return 0;" > statements, rather than changing them to null returns. Not commit 6712ecf8f648118c3363c142196418f89a510b90. It was the later e30408b2a99cb7b8bf529c7dc2328a19d71894cf commit by Jeff that removed the returns. Tssk, tssk. 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: [PATCH] JFS: Bio cleanup: Replace missing return statements
On Sat, 13 Oct 2007 15:11:10 -0400 Jeff Garzik wrote:
>
> From: Dave Kleikamp <[EMAIL PROTECTED]>
>
> commit 6712ecf8f648118c3363c142196418f89a510b90 removed some "return 0;"
> statements, rather than changing them to null returns.
Is my git tree mucked up? It looks to me like it was commit
e30408b2a99cb7b8bf529c7dc2328a19d71894cf that removed the return 0's.
> Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
> ---
> Dave sent this under a different cover, but just in case it was missed
> in the middle of the thread, I wanted to make sure it was not missed.
>
> fs/jfs/jfs_logmgr.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
> index ccfd029..15a3974 100644
> --- a/fs/jfs/jfs_logmgr.c
> +++ b/fs/jfs/jfs_logmgr.c
> @@ -2234,6 +2234,8 @@ static void lbmIODone(struct bio *bio, int error)
>
> /* wakeup I/O initiator */
> LCACHE_WAKEUP(>l_ioevent);
> +
> + return;
> }
>
> /*
> @@ -2258,6 +2260,7 @@ static void lbmIODone(struct bio *bio, int error)
> if (bp->l_flag & lbmDIRECT) {
> LCACHE_WAKEUP(>l_ioevent);
> LCACHE_UNLOCK(flags);
> + return;
> }
>
> tail = log->wqueue;
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression(?): starting with 2.6.21 sending packets became broken.
Peter Volkov wrote: > Hello, all on the list. > > Please CC me in answers, I'm not subscribed. Please, if this is wrong > list tell me what is correct. > > Starting with 2.6.21 (or may be 2.6.20 as I have not tried it) kernel I > have problem that most tcp based services freeze at some point of > operation. I've noticed this first on ssh but then found out that at > lease one other service became similarly. The problem sites somewhere in > the kernel as I've compiled 2.6.19, 2.6.21, and 2.6.22 with the > similar .config options (of course not exact, as some options does not > exist in some kernels, but seems that enabled options are all the same) > but I have this problem only with the 21 and 22. I've tried to debug the > problem a bit, but not a lot as that is production box working as linux > based firewall/router. > Try echo 0 > /proc/sys/net/ipv4/tcp_window_scaling I bet you have broken router(s) between your machine and the problem site(s). Cheers David - 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] Version 6 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Fri, Oct 12, 2007 at 10:01:17PM -0700, Casey Schaufler wrote: > > What do you need smk_sb for? Looks like dead weight... Reminant of an abandoned thought process. Cleaning. > smk_read_load(): obvious seq_file candidate. > smk_read_cipso(): ditto. > > What protects smk_cipso_written? BTW, its use on the read side is an > atrocity... > > smk_write_doi() - WTF would NUL-terminate temp[]? You run sscanf on > it... > smk_write_direct() - ditto > smk_write_ambient() - ditto > smk_read_ambient() - who said that you won't get write between strlen() > and simple_read_from_buffer()? Eek. The smackfs code does look pretty crufty in the context of seq_file, doesn't it? I will have a go at cleaning that up some. > smk_import_entry(): > > + for (skp = smack_known; skp != NULL; skp = skp->smk_next) > > + if (skp->smk_known == smack) > > + break; > Really? With smack[] being an auto array? Nope. What you see there is a flaw, a mistake, a bug. And a serious memory use problem, too. Fix in test. Thank you. > That's from quick look through the read/write in there; I hadn't really > looked into parsers or deeper into the guts. Your suggestions regarding seq_file look helpful. Thank you. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scsi on sparc build break in 2.6.23.
On Sat, Oct 13, 2007 at 02:09:35PM -0500, Rob Landley wrote:
> On Thursday 11 October 2007 6:56:59 pm Adrian Bunk wrote:
> > On Thu, Oct 11, 2007 at 05:37:30PM -0500, Rob Landley wrote:
> > > On Thursday 11 October 2007 10:21:49 am Adrian Bunk wrote:
> > > > I assume you have the full .config in your build directory, and could
> > > > have taken it from there?
> > >
> > > Actually I don't. (The extracted source tree is in a temporary directory
> > > which the script deletes afterwards unless I tell it not to. I just
> > > followed my own instructions to create the .config and attach it, but I
> > > see that James Bottomley already diagnosed it and you came up with a
> > > patch. Off to try it...)
> >
> > I was able to follow your instructions for generating it.
> >
> > But I hope you got my point that it's much easier to debug such issues
> > when you generate the .config yourself and attach it when sending the
> > bug report.
>
> *shrug* I find miniconfig much easier to read because I can see what the 50
> or so intentional options are, not just the 1000 or so background options set
> to various default values.
The .config is the canonical format everyone is used to.
It also has advantages like a defined order of the options.
And it is actually an advantage that you see what the other options are
set to (e.g. in this case your miniconfig did not show the value of
CONFIG_HOTPLUG which was the most important option for understanding the
bug) - it doesn't matter whether you {dis,en}abled it intentionally,
all that matter is it's value.
There might be use cases where a miniconfig is better, but for debugging
compile errors a full .config is much better.
> Rob
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
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] Input: Refactor evdev 32bit compat to be shareable with uinput
Currently, evdev has working 32bit compatibility and uinput does not. uinput
needs the input_event code that evdev uses, so let's refactor it so it can
be shared.
Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
---
drivers/input/Makefile |2
drivers/input/evdev.c| 118 ++-
drivers/input/input_compat.c | 89
drivers/input/misc/uinput.c | 23 ++--
include/linux/input_compat.h | 61 ++
5 files changed, 175 insertions(+), 118 deletions(-)
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 15eb752..92f34da 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -5,7 +5,7 @@
# Each configuration option enables a list of files.
obj-$(CONFIG_INPUT)+= input-core.o
-input-core-objs := input.o ff-core.o
+input-core-objs := input.o input_compat.o ff-core.o
obj-$(CONFIG_INPUT_FF_MEMLESS) += ff-memless.o
obj-$(CONFIG_INPUT_POLLDEV)+= input-polldev.o
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 27026f7..91b086c 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -17,9 +17,9 @@
#include
#include
#include
+#include
#include
#include
-#include
struct evdev {
int exist;
@@ -294,110 +294,6 @@ static int evdev_open(struct inode *inode, struct file
*file)
return error;
}
-#ifdef CONFIG_COMPAT
-
-struct input_event_compat {
- struct compat_timeval time;
- __u16 type;
- __u16 code;
- __s32 value;
-};
-
-/* Note to the author of this code: did it ever occur to
- you why the ifdefs are needed? Think about it again. -AK */
-#ifdef CONFIG_X86_64
-# define COMPAT_TEST is_compat_task()
-#elif defined(CONFIG_IA64)
-# define COMPAT_TEST IS_IA32_PROCESS(task_pt_regs(current))
-#elif defined(CONFIG_S390)
-# define COMPAT_TEST test_thread_flag(TIF_31BIT)
-#elif defined(CONFIG_MIPS)
-# define COMPAT_TEST test_thread_flag(TIF_32BIT_ADDR)
-#else
-# define COMPAT_TEST test_thread_flag(TIF_32BIT)
-#endif
-
-static inline size_t evdev_event_size(void)
-{
- return COMPAT_TEST ?
- sizeof(struct input_event_compat) : sizeof(struct input_event);
-}
-
-static int evdev_event_from_user(const char __user *buffer,
-struct input_event *event)
-{
- if (COMPAT_TEST) {
- struct input_event_compat compat_event;
-
- if (copy_from_user(_event, buffer,
- sizeof(struct input_event_compat)))
- return -EFAULT;
-
- event->time.tv_sec = compat_event.time.tv_sec;
- event->time.tv_usec = compat_event.time.tv_usec;
- event->type = compat_event.type;
- event->code = compat_event.code;
- event->value = compat_event.value;
-
- } else {
- if (copy_from_user(event, buffer, sizeof(struct input_event)))
- return -EFAULT;
- }
-
- return 0;
-}
-
-static int evdev_event_to_user(char __user *buffer,
- const struct input_event *event)
-{
- if (COMPAT_TEST) {
- struct input_event_compat compat_event;
-
- compat_event.time.tv_sec = event->time.tv_sec;
- compat_event.time.tv_usec = event->time.tv_usec;
- compat_event.type = event->type;
- compat_event.code = event->code;
- compat_event.value = event->value;
-
- if (copy_to_user(buffer, _event,
-sizeof(struct input_event_compat)))
- return -EFAULT;
-
- } else {
- if (copy_to_user(buffer, event, sizeof(struct input_event)))
- return -EFAULT;
- }
-
- return 0;
-}
-
-#else
-
-static inline size_t evdev_event_size(void)
-{
- return sizeof(struct input_event);
-}
-
-static int evdev_event_from_user(const char __user *buffer,
-struct input_event *event)
-{
- if (copy_from_user(event, buffer, sizeof(struct input_event)))
- return -EFAULT;
-
- return 0;
-}
-
-static int evdev_event_to_user(char __user *buffer,
- const struct input_event *event)
-{
- if (copy_to_user(buffer, event, sizeof(struct input_event)))
- return -EFAULT;
-
- return 0;
-}
-
-#endif /* CONFIG_COMPAT */
-
static ssize_t evdev_write(struct file *file, const char __user *buffer,
size_t count, loff_t *ppos)
{
@@ -417,14 +313,14 @@ static ssize_t evdev_write(struct file *file, const char
__user *buffer,
while (retval < count) {
- if (evdev_event_from_user(buffer + retval, )) {
+ if (input_event_from_user(buffer + retval, )) {
retval = -EFAULT;
goto out;
}
linux-2.6.23-git3: Many sysfs-related warnings in dmesg
Hi, There are many traces like this in my dmesg from 2.6.23-git3 (they don't appear for vanilla 2.6.23): <4>sysfs: duplicate filename 'ethxx1' can not be created WARNING: at /home/rafael/src/linux-2.6/fs/sysfs/dir.c:425 sysfs_add_one() Call Trace: [] sysfs_add_one+0x5c/0xc9 [] sysfs_create_link+0xd1/0x12c [] device_rename+0x17a/0x1db [] dev_change_name+0x114/0x20c [] dev_ifsioc+0x204/0x2d0 [] dev_ioctl+0x520/0x633 [] sk_alloc+0x37/0x10c [] up_read+0x9/0xb [] sock_ioctl+0x1fe/0x20c [] do_ioctl+0x2a/0x77 [] vfs_ioctl+0x251/0x26e [] sys_ioctl+0x5f/0x83 [] system_call+0x7e/0x83 net ethxx1: device_rename: sysfs_create_symlink failed (-17) sysfs: duplicate filename 'eth1' can not be created Everything seems to work, but this just looks fishy. I reported it for at least one -mm of the recent -mm kernels, but no one responded. Greetings, Rafael - 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] JFS: Bio cleanup: Replace missing return statements
From: Dave Kleikamp <[EMAIL PROTECTED]>
commit 6712ecf8f648118c3363c142196418f89a510b90 removed some "return 0;"
statements, rather than changing them to null returns.
Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
Dave sent this under a different cover, but just in case it was missed
in the middle of the thread, I wanted to make sure it was not missed.
fs/jfs/jfs_logmgr.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
index ccfd029..15a3974 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -2234,6 +2234,8 @@ static void lbmIODone(struct bio *bio, int error)
/* wakeup I/O initiator */
LCACHE_WAKEUP(>l_ioevent);
+
+ return;
}
/*
@@ -2258,6 +2260,7 @@ static void lbmIODone(struct bio *bio, int error)
if (bp->l_flag & lbmDIRECT) {
LCACHE_WAKEUP(>l_ioevent);
LCACHE_UNLOCK(flags);
+ return;
}
tail = log->wqueue;
-
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: Scsi on sparc build break in 2.6.23.
On Thursday 11 October 2007 6:56:59 pm Adrian Bunk wrote: > On Thu, Oct 11, 2007 at 05:37:30PM -0500, Rob Landley wrote: > > On Thursday 11 October 2007 10:21:49 am Adrian Bunk wrote: > > > I assume you have the full .config in your build directory, and could > > > have taken it from there? > > > > Actually I don't. (The extracted source tree is in a temporary directory > > which the script deletes afterwards unless I tell it not to. I just > > followed my own instructions to create the .config and attach it, but I > > see that James Bottomley already diagnosed it and you came up with a > > patch. Off to try it...) > > I was able to follow your instructions for generating it. > > But I hope you got my point that it's much easier to debug such issues > when you generate the .config yourself and attach it when sending the > bug report. *shrug* I find miniconfig much easier to read because I can see what the 50 or so intentional options are, not just the 1000 or so background options set to various default values. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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/
What still uses the block layer?
My impression from asking questions on the linux-scsi mailing list is that the scsi upper/middle/lower layers doesn't use the block layer described in Documentation/block/*. For example, the scsi guys say: http://marc.info/?l=linux-scsi=118633268527856=2 Instead of using the block layer, SCSI reinvents this particular wheel itself. There's a scsi "upper layer" that provides /dev nodes, scsi low-level drivers, and a gigantic glue layer in between call the "scsi midlayer" that's something like a networking stack, and is responsible for losing track of all your devices so that the one SATA disk hardwired into your laptop might be sda or sdc depending on whether or not you had a USB key plugged in when you booted up. Anyway, the block layer isn't between any of these three, that I can tell. Now that IDE disks have been rerouted through the scsi layer, SATA goes through the scsi layer, USB goes through the scsi layer, firewire goes through the scsi layer... What's left? It seems like everything but ramdisks have now been routed through the scsi layer. My laptop hasn't got a single SCSI device but it also hasn't got any block devices that don't show up as scsi. So what's still using the block layer? How do the scsi layers and the block layer relate? I'm confused! (This is normal for me, but still...) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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] drivers/pci, drivers/dma: kill unused vars
Kill two never-used (not even in hidden debug macros) variables,
noticed by the compiler.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c |1 -
drivers/pci/hotplug/pci_hotplug_core.c |2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index 41b18c5..d9db64b 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -244,7 +244,6 @@ static void ioat_dma_free_chan_resources(struct dma_chan
*chan)
struct ioat_dma_chan *ioat_chan = to_ioat_chan(chan);
struct ioat_device *ioat_device = to_ioat_device(chan->device);
struct ioat_desc_sw *desc, *_desc;
- u16 chanctrl;
int in_use_descs = 0;
ioat_dma_memcpy_cleanup(ioat_chan);
diff --git a/drivers/pci/hotplug/pci_hotplug_core.c
b/drivers/pci/hotplug/pci_hotplug_core.c
index f0eba53..01c351c 100644
--- a/drivers/pci/hotplug/pci_hotplug_core.c
+++ b/drivers/pci/hotplug/pci_hotplug_core.c
@@ -689,8 +689,6 @@ int pci_hp_deregister (struct hotplug_slot *slot)
int __must_check pci_hp_change_slot_info(struct hotplug_slot *slot,
struct hotplug_slot_info *info)
{
- int retval;
-
if ((slot == NULL) || (info == NULL))
return -ENODEV;
-
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] drivers/char/ip2: fix used-uninit'd bug
Fix bug flagged by a variable-used-uninitialized warning.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/char/ip2/ip2main.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/char/ip2/ip2main.c b/drivers/char/ip2/ip2main.c
index bd94d5f..2a566a0 100644
--- a/drivers/char/ip2/ip2main.c
+++ b/drivers/char/ip2/ip2main.c
@@ -619,11 +619,7 @@ ip2_loadmain(int *iop, int *irqp, unsigned char *firmware,
int firmsize)
ip2config.irq[i] = pci_dev_i->irq;
} else {// ann error
ip2config.addr[i] = 0;
- if (status == PCIBIOS_DEVICE_NOT_FOUND)
{
- printk( KERN_ERR "IP2: PCI
board %d not found\n", i );
- } else {
- printk( KERN_ERR "IP2: PCI
error 0x%x \n", status );
- }
+ printk( KERN_ERR "IP2: PCI board %d not
found\n", i );
}
}
#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/
[PATCH] drivers/block/cpqarray,cciss: kill unused var
The recent bio work and subsequent fixups created unused variables.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/block/cciss.c|1 -
drivers/block/cpqarray.c |3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 28d1457..27401d6 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1191,7 +1191,6 @@ static inline void complete_buffers(struct bio *bio, int
status)
{
while (bio) {
struct bio *xbh = bio->bi_next;
- int nr_sectors = bio_sectors(bio);
bio->bi_next = NULL;
bio_endio(bio, status ? 0 : -EIO);
diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c
index 3853c9a..568603d 100644
--- a/drivers/block/cpqarray.c
+++ b/drivers/block/cpqarray.c
@@ -981,9 +981,8 @@ static void start_io(ctlr_info_t *h)
static inline void complete_buffers(struct bio *bio, int ok)
{
struct bio *xbh;
- while(bio) {
- int nr_sectors = bio_sectors(bio);
+ while (bio) {
xbh = bio->bi_next;
bio->bi_next = NULL;
-
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.23-mm1 gdth doesn't compile with CONFIG_ISA && !CONFIG_EISA
gdth_irq_tab is defined only in #ifdef CONFIG_EISA, but used in
gdth_init_isa()
Signed-off-by: Bernhard Rosenkraenzer <[EMAIL PROTECTED]>
--- linux-2.6.23/drivers/scsi/gdth.c.ark2007-10-13 20:51:32.0
+0200
+++ linux-2.6.23/drivers/scsi/gdth.c2007-10-13 20:52:05.0 +0200
@@ -288,7 +288,7 @@ static struct timer_list gdth_timer;
#ifdef CONFIG_ISA
static unchar gdth_drq_tab[4] = {5,6,7,7};/* DRQ table */
#endif
-#ifdef CONFIG_EISA
+#if defined(CONFIG_EISA) || defined(CONFIG_ISA)
static unchar gdth_irq_tab[6] = {0,10,11,12,14,0};/* IRQ table */
#endif
static unchar gdth_polling; /* polling if TRUE */
-
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.23-mm1 pm_prepare() and _finish() w/ args vs. without
On Saturday, 13 October 2007 20:40, Joseph Fannin wrote:
> On Sat, Oct 13, 2007 at 07:22:48PM +0200, Rafael J. Wysocki wrote:
> > On Saturday, 13 October 2007 17:50, Joseph Fannin wrote:
> > > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > >
> > >
> > > Domen Puncer's change to support "MPC5200 low power mode" (in
> > > powerpc-git, which is in Linus's tree now) adds new code calling
> > > mpc52xx_pm_prepare and _finish with suspend_state_t as an argument,
> > > while Rafael Wysocki's pm-rework-struct-platform_suspend_ops.patch
> > > converts those to take no arguments. So the build fails:
> >
> > Ouch.
> >
> > I think that the appended patch is needed. Unfortunately, I can't test it
> > here.
> >
>
> > --- linux-2.6.23-mm1.orig/include/asm-powerpc/mpc52xx.h
> > +++ linux-2.6.23-mm1/include/asm-powerpc/mpc52xx.h
> > @@ -267,9 +267,9 @@ extern int mpc52xx_set_wakeup_gpio(u8 pi
> > extern int __init lite5200_pm_init(void);
> >
> > /* lite5200 calls mpc5200 suspend functions, so here they are */
> > -extern int mpc52xx_pm_prepare(suspend_state_t);
> > +extern int mpc52xx_pm_prepare(void);
> > extern int mpc52xx_pm_enter(suspend_state_t);
> > -extern int mpc52xx_pm_finish(suspend_state_t);
> > +extern void mpc52xx_pm_finish(void);
>
> These declarations are extern, but
> pm-rework-struct-platform_suspend_ops.patch makes the function
> definitions static, which doesn't seem to be allowed.
Yes. Corrected patch follows.
> After removing the static bits from those two functions in
> mpc52xx_pm.c it builds, but there are lots of warnings, which seem to
> be related:
Well, suspend_state_t is undefined in mpc52xx.h . I've added
#include to the corrected patch below, although I'm not sure
if that's the right thing to do here.
Greetings,
Rafael
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/52xx/lite5200_pm.c | 35 +++---
arch/powerpc/platforms/52xx/mpc52xx_pm.c |4 +--
include/asm-powerpc/mpc52xx.h |6 +++--
3 files changed, 29 insertions(+), 16 deletions(-)
Index: linux-2.6.23-mm1/include/asm-powerpc/mpc52xx.h
===
--- linux-2.6.23-mm1.orig/include/asm-powerpc/mpc52xx.h
+++ linux-2.6.23-mm1/include/asm-powerpc/mpc52xx.h
@@ -18,6 +18,8 @@
#include
#endif /* __ASSEMBLY__ */
+#include
+
/* */
/* Structures mapping of some unit register set */
@@ -267,9 +269,9 @@ extern int mpc52xx_set_wakeup_gpio(u8 pi
extern int __init lite5200_pm_init(void);
/* lite5200 calls mpc5200 suspend functions, so here they are */
-extern int mpc52xx_pm_prepare(suspend_state_t);
+extern int mpc52xx_pm_prepare(void);
extern int mpc52xx_pm_enter(suspend_state_t);
-extern int mpc52xx_pm_finish(suspend_state_t);
+extern void mpc52xx_pm_finish(void);
extern char saved_sram[0x4000]; /* reuse buffer from mpc52xx suspend */
#endif
#endif /* CONFIG_PM */
Index: linux-2.6.23-mm1/arch/powerpc/platforms/52xx/lite5200_pm.c
===
--- linux-2.6.23-mm1.orig/arch/powerpc/platforms/52xx/lite5200_pm.c
+++ linux-2.6.23-mm1/arch/powerpc/platforms/52xx/lite5200_pm.c
@@ -1,5 +1,5 @@
#include
-#include
+#include
#include
#include
#include
@@ -18,6 +18,8 @@ static void __iomem *sram;
static const int sram_size = 0x4000; /* 16 kBytes */
static void __iomem *mbar;
+static suspend_state_t lite5200_pm_target_state;
+
static int lite5200_pm_valid(suspend_state_t state)
{
switch (state) {
@@ -29,13 +31,22 @@ static int lite5200_pm_valid(suspend_sta
}
}
-static int lite5200_pm_prepare(suspend_state_t state)
+static int lite5200_pm_set_target(suspend_state_t state)
+{
+ if (lite5200_pm_valid(state)) {
+ lite5200_pm_target_state = state;
+ return 0;
+ }
+ return -EINVAL;
+}
+
+static int lite5200_pm_prepare(void)
{
/* deep sleep? let mpc52xx code handle that */
- if (state == PM_SUSPEND_STANDBY)
- return mpc52xx_pm_prepare(state);
+ if (lite5200_pm_target_state == PM_SUSPEND_STANDBY)
+ return mpc52xx_pm_prepare();
- if (state != PM_SUSPEND_MEM)
+ if (lite5200_pm_target_state != PM_SUSPEND_MEM)
return -EINVAL;
/* map registers */
@@ -190,24 +201,24 @@ static int lite5200_pm_enter(suspend_sta
return 0;
}
-static int lite5200_pm_finish(suspend_state_t state)
+static void lite5200_pm_finish(void)
{
/* deep sleep? let mpc52xx code handle that */
- if (state == PM_SUSPEND_STANDBY) {
- return mpc52xx_pm_finish(state);
+ if (lite5200_pm_target_state == PM_SUSPEND_STANDBY) {
+ mpc52xx_pm_finish();
Re: [PATCH] 0/3 checkpatch updates, new checkfiles script
In message <[EMAIL PROTECTED]>, Ingo Molnar writes: > > * Erez Zadok <[EMAIL PROTECTED]> wrote: > > > So, I ran the above script and it found nearly 1.5 million reported > > warnings/errors, with drivers being the largest abuser, not > > surprisingly. [...] > > have you tried that with the latest version too: > > > http://www.kernel.org/pub/linux/kernel/people/apw/checkpatch/checkpatch.pl-next > > it outputs far fewer false positives. > > Ingo OK, I just checked the latest version of checkpatch on 2.6.23.1. Here are the stats broken down by subsystem and category of message (error, warning, or subjective check): SUBSYSTEM ErrorWarn Check Total drivers 866113 1680937712 1041918 fs 102133 140161236 117385 arch 78531 328985400 116829 include 41237 429741838 86049 sound 59175 203191184 80678 net68986614 659 14171 crypto4333 467 324832 lib4193 383 614637 kernel 950 895 1622007 scripts1205 742 261973 security 501 591 391131 mm 473 281 79 833 ipc 344 119 30 493 Documentation 191 95 6 292 block 100 146 28 274 init 64 69 28 161 usr 14 19 0 33 TOTAL 1166455 288721 18520 1473696 Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/8] m68k: ignore restart_syscall
Hi, On Sat, 13 Oct 2007, Geert Uytterhoeven wrote: > m68k: ignore restart_syscall, which is not needed on m68k. It's somewhat needed, but nobody has gotten around to actually implement it yet... bye, Roman - 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] fallout from elsa setup split
Al Viro wrote: ... and yes, caller wants it to return int. Signed-off-by: Al Viro <[EMAIL PROTECTED]> ACK (I was just about to send same) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 7/8] b43 wireless needs
On Saturday 13 October 2007 20:38:43 Geert Uytterhoeven wrote: > On Sat, 13 Oct 2007, Larry Finger wrote: > > Geert Uytterhoeven wrote: > > > linux/drivers/net/wireless/b43/pio.h: In function 'b43_pio_write': > > > linux/drivers/net/wireless/b43/pio.h:89: error: implicit declaration of > > > function 'mmiowb' > > > > > > linux/drivers/net/wireless/b43/phy.c: In function 'b43_phy_write': > > > linux/drivers/net/wireless/b43/phy.c:301: error: implicit declaration of > > > function 'mmiowb' > > > > > > linuxdrivers/net/wireless/b43/sysfs.c: In function > > > 'b43_attr_interfmode_store': > > > linuxdrivers/net/wireless/b43/sysfs.c:147: error: implicit declaration of > > > function 'mmiowb' > > > > From the distribution list for this E-mail, I presume this error occurred > > for m68k. Is this correct? > > That's correct. > > > If so, I will probably need to prepare a similar patch for b43legacy. > > I had no problems compiling b43legacy on m68k, though. Probably > was included through some other include file. > Of course it's safer to always #include when using I/O. > > During linking, I did get a bunch of `undefined reference to `dma_*'' > errors, with both b43 and b43legacy (and a few other drivers). Probably > they need to depend on HAS_DMA. > I'll post separate patches for those after I've sorted them out. We could make the b43 and b43legacy DMA engine code depend on HAS_DMA then. So it can still be compiled with PIO. (Though, I don't know if anybody would put such a card into a machine without DMA, anyway). The DMA engine code is a seperate kconfig option. -- Greetings Michael. - 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.23-mm1 pm_prepare() and _finish() w/ args vs. without
On Sat, Oct 13, 2007 at 07:22:48PM +0200, Rafael J. Wysocki wrote: > On Saturday, 13 October 2007 17:50, Joseph Fannin wrote: > > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > > > Domen Puncer's change to support "MPC5200 low power mode" (in > > powerpc-git, which is in Linus's tree now) adds new code calling > > mpc52xx_pm_prepare and _finish with suspend_state_t as an argument, > > while Rafael Wysocki's pm-rework-struct-platform_suspend_ops.patch > > converts those to take no arguments. So the build fails: > > Ouch. > > I think that the appended patch is needed. Unfortunately, I can't test it > here. > > --- linux-2.6.23-mm1.orig/include/asm-powerpc/mpc52xx.h > +++ linux-2.6.23-mm1/include/asm-powerpc/mpc52xx.h > @@ -267,9 +267,9 @@ extern int mpc52xx_set_wakeup_gpio(u8 pi > extern int __init lite5200_pm_init(void); > > /* lite5200 calls mpc5200 suspend functions, so here they are */ > -extern int mpc52xx_pm_prepare(suspend_state_t); > +extern int mpc52xx_pm_prepare(void); > extern int mpc52xx_pm_enter(suspend_state_t); > -extern int mpc52xx_pm_finish(suspend_state_t); > +extern void mpc52xx_pm_finish(void); These declarations are extern, but pm-rework-struct-platform_suspend_ops.patch makes the function definitions static, which doesn't seem to be allowed. After removing the static bits from those two functions in mpc52xx_pm.c it builds, but there are lots of warnings, which seem to be related: CC arch/powerpc/kernel/prom.o In file included from arch/powerpc/platforms/52xx/mpc52xx_pic.c:34: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/platforms/52xx/mpc52xx_common.o arch/powerpc/kernel/prom.c: In function ‘early_init_dt_scan_chosen’: arch/powerpc/kernel/prom.c:784: warning: assignment from incompatible pointer type arch/powerpc/kernel/prom.c:788: warning: assignment from incompatible pointer type In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:20: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/platforms/52xx/mpc52xx_pci.o CC arch/powerpc/kernel/traps.o In file included from arch/powerpc/platforms/52xx/mpc52xx_pci.c:16: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration arch/powerpc/platforms/52xx/mpc52xx_pci.c: In function ‘mpc52xx_pci_setup’: arch/powerpc/platforms/52xx/mpc52xx_pci.c:262: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:262: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:276: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:276: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: cast to pointer from integer of different size arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘resource_size_t’ arch/powerpc/platforms/52xx/mpc52xx_pci.c:295: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ CC arch/powerpc/platforms/52xx/efika.o In file included from arch/powerpc/platforms/52xx/efika.c:36: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration CC arch/powerpc/kernel/setup-common.o CC arch/powerpc/platforms/52xx/lite5200.o In file included from arch/powerpc/platforms/52xx/lite5200.c:44: include/asm/mpc52xx.h:271: warning: parameter names (without types) in function declaration The build is moving though, and I don't actually have this platform -- I just can't avoid building it when building for powermac. Thanks. -- Joseph Fannin [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-mm1
Torsten Kaiser wrote: On 10/13/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Torsten Kaiser wrote: 3 boots, all worked. So I'm very sure that was the bug, but I will now do a little load testing... The only strange thing about 2.6.23-mm1 is, that it takes ~4 second more to boot. So, you basically applied the attached patch? Yeah, absence of qc_defer for an NCQ-capable chip would do it. Yes. The system seems to work correctly now. Thanks for helping track this down. Fix pushed out to libata-dev.git. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fallout from elsa setup split
... and yes, caller wants it to return int.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/isdn/hisax/elsa.c b/drivers/isdn/hisax/elsa.c
index 0c1351b..948a9b2 100644
--- a/drivers/isdn/hisax/elsa.c
+++ b/drivers/isdn/hisax/elsa.c
@@ -1088,7 +1088,7 @@ setup_elsa_pci(struct IsdnCard *card)
#else
-static void __devinit
+static int __devinit
setup_elsa_pci(struct IsdnCard *card)
{
return (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] missing includes in arch/powerpc/platforms/52xx/lite5200.c
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c index 0caa3d9..774f249 100644 --- a/arch/powerpc/platforms/52xx/lite5200.c +++ b/arch/powerpc/platforms/52xx/lite5200.c @@ -18,6 +18,8 @@ #include #include #include +#include +#include #include #include #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 7/8] b43 wireless needs
On Sat, 13 Oct 2007, Larry Finger wrote:
> Geert Uytterhoeven wrote:
> > linux/drivers/net/wireless/b43/pio.h: In function 'b43_pio_write':
> > linux/drivers/net/wireless/b43/pio.h:89: error: implicit declaration of
> > function 'mmiowb'
> >
> > linux/drivers/net/wireless/b43/phy.c: In function 'b43_phy_write':
> > linux/drivers/net/wireless/b43/phy.c:301: error: implicit declaration of
> > function 'mmiowb'
> >
> > linuxdrivers/net/wireless/b43/sysfs.c: In function
> > 'b43_attr_interfmode_store':
> > linuxdrivers/net/wireless/b43/sysfs.c:147: error: implicit declaration of
> > function 'mmiowb'
>
> From the distribution list for this E-mail, I presume this error occurred for
> m68k. Is this correct?
That's correct.
> If so, I will probably need to prepare a similar patch for b43legacy.
I had no problems compiling b43legacy on m68k, though. Probably
was included through some other include file.
Of course it's safer to always #include when using I/O.
During linking, I did get a bunch of `undefined reference to `dma_*''
errors, with both b43 and b43legacy (and a few other drivers). Probably
they need to depend on HAS_DMA.
I'll post separate patches for those after I've sorted them out.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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] checkpatch: Fix line number reporting
In message <[EMAIL PROTECTED]>, Andy Whitcroft writes:
> On Fri, Oct 12, 2007 at 03:26:54PM -0400, Mike D. Day wrote:
> > Fix line number reporting when checking source files (as opposed to
> > patches)
> >
> > Signed-off-by: Mike D. Day <[EMAIL PROTECTED]>
>
> Sorry you've had to fix this about 4 times, mostly because of ongoing
> changes, and slow replication getting in the way. I've applied this
> and you should find it in -next when replication hits. md5sum is
> below of the version with it in, so you can make sure you've got
> the right one.
>
> 54f053c50265e44a6041e3147dc66a69 checkpatch.pl
>
> -apw
Andy, I've tested the --emacs feature in the above latest
checkpatch.pl-next. Below is a patch that completes the functionality of
the --emacs option: it ensures that only the cc-style error messages are
printed, no extra context lines or caret lines, no extra newlines, etc.
Although this patch changes every call to a message-producing function, it
is a trivial change, and I believe it's the cleanest way to handle the
separation between the terse cc-style messages and the verbose default
messages. With this patch, I can finally test a single source file as
follows:
$ ./scripts/checkpatch.pl -q -q --emacs --file path/name/to/file
(Yes, I need two -q).
Cheers,
Erez.
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 13de0e2..051b354 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -511,18 +511,21 @@ sub report_dump {
@report;
}
sub ERROR {
- report("ERROR: $_[0]\n");
+ report("ERROR: $_[0]");
+ report("$_[1]\n") if (!$emacs);
our $clean = 0;
our $cnt_error++;
}
sub WARN {
- report("WARNING: $_[0]\n");
+ report("WARNING: $_[0]");
+ report("$_[1]\n") if (!$emacs);
our $clean = 0;
our $cnt_warn++;
}
sub CHK {
if ($check) {
- report("CHECK: $_[0]\n");
+ report("CHECK: $_[0]");
+ report("$_[1]\n") if (!$emacs);
our $clean = 0;
our $cnt_chk++;
}
@@ -663,18 +666,18 @@ sub process {
# This is a signoff, if ugly, so do not double report.
$signoff++;
if (!($line =~ /^\s*Signed-off-by:/)) {
- WARN("Signed-off-by: is the preferred form\n" .
+ WARN("Signed-off-by: is the preferred form\n",
$herecurr);
}
if ($line =~ /^\s*signed-off-by:\S/i) {
- WARN("need space after Signed-off-by:\n" .
+ WARN("need space after Signed-off-by:\n",
$herecurr);
}
}
# Check for wrappage within a valid hunk of the file
if ($realcnt != 0 && $line !~ m{^(?:\+|-| |$)}) {
- ERROR("patch seems to be corrupt (line wrapped?)\n" .
+ ERROR("patch seems to be corrupt (line wrapped?)\n",
$herecurr) if (!$emitted_corrupt++);
}
@@ -690,7 +693,7 @@ sub process {
| [\xF1-\xF3][\x80-\xBF]{3} # planes
4-15
| \xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16
)*$/x )) {
- ERROR("Invalid UTF-8\n" . $herecurr);
+ ERROR("Invalid UTF-8\n", $herecurr);
}
#ignore lines being removed
@@ -702,15 +705,15 @@ sub process {
#trailing whitespace
if ($line =~ /^\+.*\015/) {
my $herevet = "$here\n" . cat_vet($line) . "\n";
- ERROR("DOS line endings\n" . $herevet);
+ ERROR("DOS line endings\n", $herevet);
} elsif ($line =~ /^\+.*\S\s+$/ || $line =~ /^\+\s+$/) {
my $herevet = "$here\n" . cat_vet($line) . "\n";
- ERROR("trailing whitespace\n" . $herevet);
+ ERROR("trailing whitespace\n", $herevet);
}
#80 column limit
if ($line =~ /^\+/ && !($prevline=~/\/\*\*/) && $length > 80) {
- WARN("line over 80 characters\n" . $herecurr);
+ WARN("line over 80 characters\n", $herecurr);
}
# check we are in a valid source file *.[hc] if not then ignore this hunk
@@ -720,7 +723,7 @@ sub process {
# more than 8 must use tabs.
if ($line=~/^\+\s* \t\s*\S/ or $line=~/^\+\s*\s*/) {
my $herevet = "$here\n" . cat_vet($line) . "\n";
- ERROR("use tabs not spaces\n" . $herevet);
+ ERROR("use tabs not spaces\n", $herevet);
}
# Remove comments from the line before processing.
@@ -786,7
