Re: [Git Patch] Makefile: fix wrong dirs when making cscope
On Mon, Nov 05, 2007 at 08:33:17AM +0100, Sam Ravnborg wrote:
>Hi Wang.
>
>Thanks for this fix, but I have a few comments. See below.
>
>On Mon, Nov 05, 2007 at 03:09:53PM +0800, WANG Cong wrote:
>>
>> Hi, Sam!
>>
>> This patch fixed the following errors when doing "make cscope" and
>> "make cscope ARCH=um".
>>
>> FILELST cscope.files
>> find: arch/i386: No such file or directory
>> MAKEcscope.out
>>
>>
>> FILELST cscope.files
>> find: include/asm-i386: No such file or directory
>> MAKEcscope.out
>>
>>
>> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>> Cc: Sam Ravnborg <[EMAIL PROTECTED]>
>>
>> ---
>> Makefile |4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Index: linux-2.6/Makefile
>> ===
>> --- linux-2.6.orig/Makefile
>> +++ linux-2.6/Makefile
>> @@ -1322,7 +1322,7 @@ ALLSOURCE_ARCHS := $(ARCH) $(SRCARCH)
>> endif
>>
>> define find-sources
>> -( for arch in $(ALLSOURCE_ARCHS) ; do \
>> +( for arch in `echo $(ALLSOURCE_ARCHS)|sed -e "s/i386/x86/"`; do \
>> find $(__srctree)arch/$${arch} $(RCS_FIND_IGNORE) \
>> -name $1 -print; \
>>done ; \
>
>Could you change this such that the substitution takes places where we
>assign ALLSOURCE_ARCHS so all potential users benefit from this fix.
>And on top of this fix it so x86_64 is also replaced by x86 so we fix
>both x86 architectures.
OK. Thank you. I will try to do that. ;)
>
>
>> @@ -1331,7 +1331,7 @@ define find-sources
>>find $(__srctree)include $(RCS_FIND_IGNORE) \
>> \( -name config -o -name 'asm-*' \) -prune \
>> -o -name $1 -print; \
>> - for arch in $(ALLINCLUDE_ARCHS) ; do \
>> + for arch in `echo $(ALLINCLUDE_ARCHS)|sed -e "s/i386/x86/"`; do \
>> find $(__srctree)include/asm-$${arch} $(RCS_FIND_IGNORE) \
>> -name $1 -print; \
>>done ; \
>>
>Same comments for ALLINCLUDE_ARCHS
>
>PS. Yout patch may be obsoleted by ongoing work to eliminate
>ARCH=i386 / ARCH=x86_64. But if/when this hits mainline I dunno so
>please do the requested changes and send me a new patch.
Sam, the root of this problem is the use of `uname -m' command. It always
outputs 'i*86' on x86_32 machines. Unless this output changes or we find another
way to determine the arch, we will always need to fix this.
New patch will come soon.
Thanks.
WANG Cong
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 Patch] Makefile: Remove ncscope.out when make mrproper
On Mon, Nov 05, 2007 at 03:32:33PM +0800, WANG Cong wrote: > > Hi, Sam! > > This patch adds the ncscope.out file into cleaning targets of 'make mrproper'. > > Signed-off-by: WANG Cong <[EMAIL PROTECTED]> > Cc: Sam Ravnborg <[EMAIL PROTECTED]> > > --- > Makefile |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6/Makefile > === > --- linux-2.6.orig/Makefile > +++ linux-2.6/Makefile > @@ -1073,7 +1073,7 @@ MRPROPER_DIRS += include/config include > MRPROPER_FILES += .config .config.old include/asm .version .old_version \ >include/linux/autoconf.h include/linux/version.h \ >include/linux/utsrelease.h\ > - Module.symvers tags TAGS cscope* > + Module.symvers tags TAGS cscope* ncscope.out Hi WANG. ncscope.out is just a temporary file but I see why you like to have it covered. How about modifying the rule to look like this: > - Module.symvers tags TAGS cscope* > + Module.symvers tags TAGS *cscope* Or is this to broad a pattern? Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Patch] Makefile: Remove ncscope.out when make mrproper
Hi, Sam! This patch adds the ncscope.out file into cleaning targets of 'make mrproper'. Signed-off-by: WANG Cong <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> --- Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6/Makefile === --- linux-2.6.orig/Makefile +++ linux-2.6/Makefile @@ -1073,7 +1073,7 @@ MRPROPER_DIRS += include/config include MRPROPER_FILES += .config .config.old include/asm .version .old_version \ include/linux/autoconf.h include/linux/version.h \ include/linux/utsrelease.h\ - Module.symvers tags TAGS cscope* + Module.symvers tags TAGS cscope* ncscope.out # clean - Delete most, but leave enough to build external modules # - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.34-rc1 eat my photo SD card :-(
On Sun, 04 Nov 2007 08:11:10 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote: > > When I put the same card back in the camera and used the camera's dock > to access the data via USB mass storage, everything worked fine. So > it does seem to be at least somewhat MMC-related. > Since there was no error from the mmc level there, I wouldn't be so sure. Could you try a complete fsck of the card to check that the camera is constructing a proper FAT? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Sun, 04 Nov 2007 10:29:43 +0100 Romano Giannetti <[EMAIL PROTECTED]> wrote: > > Can you reproduce this? To help you I need to see the errors given by > > the MMC layer. You should also try reproducing it without a tainted > > kernel (i.e. don't load ndiswrapper). > > I have a spare 128M card I can use to try. The one that failed was a 2G > one. Many of these problems are card specific, so please make sure to also test with the original card. > I will try to reproduce without tainting the kernel (unfortunately, > the Atheros chip I have is not supported by ath5k yet, and the choice is > between ndiswrapper or Vista.). Should I enable some debugging option > for the MMC layer? Not at this point no. The debugging tends to be quite noise so it easily drowns out any temporary problems. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Git Patch] Makefile: fix wrong dirs when making cscope
Hi Wang.
Thanks for this fix, but I have a few comments. See below.
On Mon, Nov 05, 2007 at 03:09:53PM +0800, WANG Cong wrote:
>
> Hi, Sam!
>
> This patch fixed the following errors when doing "make cscope" and
> "make cscope ARCH=um".
>
> FILELST cscope.files
> find: arch/i386: No such file or directory
> MAKEcscope.out
>
>
> FILELST cscope.files
> find: include/asm-i386: No such file or directory
> MAKEcscope.out
>
>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
> Cc: Sam Ravnborg <[EMAIL PROTECTED]>
>
> ---
> Makefile |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/Makefile
> ===
> --- linux-2.6.orig/Makefile
> +++ linux-2.6/Makefile
> @@ -1322,7 +1322,7 @@ ALLSOURCE_ARCHS := $(ARCH) $(SRCARCH)
> endif
>
> define find-sources
> -( for arch in $(ALLSOURCE_ARCHS) ; do \
> +( for arch in `echo $(ALLSOURCE_ARCHS)|sed -e "s/i386/x86/"`; do \
> find $(__srctree)arch/$${arch} $(RCS_FIND_IGNORE) \
> -name $1 -print; \
> done ; \
Could you change this such that the substitution takes places where we
assign ALLSOURCE_ARCHS so all potential users benefit from this fix.
And on top of this fix it so x86_64 is also replaced by x86 so we fix
both x86 architectures.
> @@ -1331,7 +1331,7 @@ define find-sources
> find $(__srctree)include $(RCS_FIND_IGNORE) \
> \( -name config -o -name 'asm-*' \) -prune \
> -o -name $1 -print; \
> - for arch in $(ALLINCLUDE_ARCHS) ; do \
> + for arch in `echo $(ALLINCLUDE_ARCHS)|sed -e "s/i386/x86/"`; do \
> find $(__srctree)include/asm-$${arch} $(RCS_FIND_IGNORE) \
> -name $1 -print; \
> done ; \
>
Same comments for ALLINCLUDE_ARCHS
PS. Yout patch may be obsoleted by ongoing work to eliminate
ARCH=i386 / ARCH=x86_64. But if/when this hits mainline I dunno so
please do the requested changes and send me a new patch.
Tanks,
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 -mm] sisusb: *_ioctl32_conversion functions do not exist in recent kernels
Remove dead code while at it.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.24-rc1-git13-orig/drivers/video/sis/sis.h
linux-2.6.24-rc1-git13/drivers/video/sis/sis.h
--- linux-2.6.24-rc1-git13-orig/drivers/video/sis/sis.h 2007-10-10
05:31:38.0 +0900
+++ linux-2.6.24-rc1-git13/drivers/video/sis/sis.h 2007-11-05
15:24:15.0 +0900
@@ -39,12 +39,7 @@
#include
#ifdef CONFIG_COMPAT
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,10)
-#include
-#define SIS_OLD_CONFIG_COMPAT
-#else
#define SIS_NEW_CONFIG_COMPAT
-#endif
#endif /* CONFIG_COMPAT */
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,8)
@@ -607,9 +602,6 @@ struct sis_video_info {
int haveXGIROM;
int registered;
int warncount;
-#ifdef SIS_OLD_CONFIG_COMPAT
- int ioctl32registered;
-#endif
int sisvga_engine;
int hwcursor_size;
diff -urNp linux-2.6.24-rc1-git13-orig/drivers/video/sis/sis_main.c
linux-2.6.24-rc1-git13/drivers/video/sis/sis_main.c
--- linux-2.6.24-rc1-git13-orig/drivers/video/sis/sis_main.c2007-11-05
10:22:15.0 +0900
+++ linux-2.6.24-rc1-git13/drivers/video/sis/sis_main.c 2007-11-05
15:25:47.0 +0900
@@ -5804,9 +5804,6 @@ sisfb_probe(struct pci_dev *pdev, const
ivideo->pcifunc = PCI_FUNC(pdev->devfn);
ivideo->subsysvendor = pdev->subsystem_vendor;
ivideo->subsysdevice = pdev->subsystem_device;
-#ifdef SIS_OLD_CONFIG_COMPAT
- ivideo->ioctl32registered = 0;
-#endif
#ifndef MODULE
if(sisfb_mode_idx == -1) {
@@ -6419,30 +6416,6 @@ error_3: vfree(ivideo->bios_abase);
ivideo->next = card_list;
card_list = ivideo;
-#ifdef SIS_OLD_CONFIG_COMPAT
- {
- int ret;
- /* Our ioctls are all "32/64bit compatible" */
- ret = register_ioctl32_conversion(FBIO_ALLOC,
NULL);
- ret |= register_ioctl32_conversion(FBIO_FREE,
NULL);
- ret |= register_ioctl32_conversion(FBIOGET_VBLANK,
NULL);
- ret |= register_ioctl32_conversion(SISFB_GET_INFO_SIZE,
NULL);
- ret |= register_ioctl32_conversion(SISFB_GET_INFO,
NULL);
- ret |= register_ioctl32_conversion(SISFB_GET_TVPOSOFFSET,
NULL);
- ret |= register_ioctl32_conversion(SISFB_SET_TVPOSOFFSET,
NULL);
- ret |= register_ioctl32_conversion(SISFB_SET_LOCK,
NULL);
- ret |= register_ioctl32_conversion(SISFB_GET_VBRSTATUS,
NULL);
- ret |= register_ioctl32_conversion(SISFB_GET_AUTOMAXIMIZE,
NULL);
- ret |= register_ioctl32_conversion(SISFB_SET_AUTOMAXIMIZE,
NULL);
- ret |= register_ioctl32_conversion(SISFB_COMMAND,
NULL);
- if(ret)
- printk(KERN_ERR
- "sisfb: Error registering ioctl32
translations\n");
- else
- ivideo->ioctl32registered = 1;
- }
-#endif
-
printk(KERN_INFO "sisfb: 2D acceleration is %s, y-panning %s\n",
ivideo->sisfb_accel ? "enabled" : "disabled",
ivideo->sisfb_ypan ?
@@ -6472,27 +6445,6 @@ static void __devexit sisfb_remove(struc
int registered = ivideo->registered;
int modechanged = ivideo->modechanged;
-#ifdef SIS_OLD_CONFIG_COMPAT
- if(ivideo->ioctl32registered) {
- int ret;
- ret = unregister_ioctl32_conversion(FBIO_ALLOC);
- ret |= unregister_ioctl32_conversion(FBIO_FREE);
- ret |= unregister_ioctl32_conversion(FBIOGET_VBLANK);
- ret |= unregister_ioctl32_conversion(SISFB_GET_INFO_SIZE);
- ret |= unregister_ioctl32_conversion(SISFB_GET_INFO);
- ret |= unregister_ioctl32_conversion(SISFB_GET_TVPOSOFFSET);
- ret |= unregister_ioctl32_conversion(SISFB_SET_TVPOSOFFSET);
- ret |= unregister_ioctl32_conversion(SISFB_SET_LOCK);
- ret |= unregister_ioctl32_conversion(SISFB_GET_VBRSTATUS);
- ret |= unregister_ioctl32_conversion(SISFB_GET_AUTOMAXIMIZE);
- ret |= unregister_ioctl32_conversion(SISFB_SET_AUTOMAXIMIZE);
- ret |= unregister_ioctl32_conversion(SISFB_COMMAND);
- if(ret)
- printk(KERN_ERR
-"sisfb: Error unregistering ioctl32
translations\n");
- }
-#endif
-
/* Unmap */
iounmap(ivideo->mmio_vbase);
iounmap(ivideo->video_vbase);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
[PATCH 1/2 -mm] sis FB driver: *_ioctl32_conversion functions do not exist in recent kernels
Remove dead code while at it.
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.24-rc1-git13-orig/drivers/usb/misc/sisusbvga/sisusb.c
linux-2.6.24-rc1-git13/drivers/usb/misc/sisusbvga/sisusb.c
--- linux-2.6.24-rc1-git13-orig/drivers/usb/misc/sisusbvga/sisusb.c
2007-11-05 10:22:15.0 +0900
+++ linux-2.6.24-rc1-git13/drivers/usb/misc/sisusbvga/sisusb.c 2007-11-05
15:25:51.0 +0900
@@ -3195,20 +3195,6 @@ static int sisusb_probe(struct usb_inter
sisusb->present = 1;
-#ifdef SISUSB_OLD_CONFIG_COMPAT
- {
- int ret;
- /* Our ioctls are all "32/64bit compatible" */
- ret = register_ioctl32_conversion(SISUSB_GET_CONFIG_SIZE, NULL);
- ret |= register_ioctl32_conversion(SISUSB_GET_CONFIG, NULL);
- ret |= register_ioctl32_conversion(SISUSB_COMMAND, NULL);
- if (ret)
- dev_err(>sisusb_dev->dev, "Error registering ioctl32
translations\n");
- else
- sisusb->ioctl32registered = 1;
- }
-#endif
-
if (dev->speed == USB_SPEED_HIGH) {
int initscreen = 1;
#ifdef INCL_SISUSB_CON
@@ -3271,19 +3257,6 @@ static void sisusb_disconnect(struct usb
usb_set_intfdata(intf, NULL);
-#ifdef SISUSB_OLD_CONFIG_COMPAT
- if (sisusb->ioctl32registered) {
- int ret;
- sisusb->ioctl32registered = 0;
- ret = unregister_ioctl32_conversion(SISUSB_GET_CONFIG_SIZE);
- ret |= unregister_ioctl32_conversion(SISUSB_GET_CONFIG);
- ret |= unregister_ioctl32_conversion(SISUSB_COMMAND);
- if (ret) {
- dev_err(>sisusb_dev->dev, "Error unregistering
ioctl32 translations\n");
- }
- }
-#endif
-
sisusb->present = 0;
sisusb->ready = 0;
diff -urNp linux-2.6.24-rc1-git13-orig/drivers/usb/misc/sisusbvga/sisusb.h
linux-2.6.24-rc1-git13/drivers/usb/misc/sisusbvga/sisusb.h
--- linux-2.6.24-rc1-git13-orig/drivers/usb/misc/sisusbvga/sisusb.h
2007-11-05 10:22:15.0 +0900
+++ linux-2.6.24-rc1-git13/drivers/usb/misc/sisusbvga/sisusb.h 2007-11-05
15:20:23.0 +0900
@@ -120,9 +120,6 @@ struct sisusb_usb_data {
int isopen; /* !=0 if open */
int present;/* !=0 if device is present on the bus */
int ready; /* !=0 if device is ready for userland */
-#ifdef SISUSB_OLD_CONFIG_COMPAT
- int ioctl32registered;
-#endif
int numobufs; /* number of obufs = number of out urbs */
char *obuf[NUMOBUFS], *ibuf;/* transfer buffers */
int obufsize, ibufsize;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 Patch] Makefile: fix wrong dirs when making cscope
Hi, Sam!
This patch fixed the following errors when doing "make cscope" and
"make cscope ARCH=um".
FILELST cscope.files
find: arch/i386: No such file or directory
MAKEcscope.out
FILELST cscope.files
find: include/asm-i386: No such file or directory
MAKEcscope.out
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
---
Makefile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -1322,7 +1322,7 @@ ALLSOURCE_ARCHS := $(ARCH) $(SRCARCH)
endif
define find-sources
-( for arch in $(ALLSOURCE_ARCHS) ; do \
+( for arch in `echo $(ALLSOURCE_ARCHS)|sed -e "s/i386/x86/"`; do \
find $(__srctree)arch/$${arch} $(RCS_FIND_IGNORE) \
-name $1 -print; \
done ; \
@@ -1331,7 +1331,7 @@ define find-sources
find $(__srctree)include $(RCS_FIND_IGNORE) \
\( -name config -o -name 'asm-*' \) -prune \
-o -name $1 -print; \
- for arch in $(ALLINCLUDE_ARCHS) ; do \
+ for arch in `echo $(ALLINCLUDE_ARCHS)|sed -e "s/i386/x86/"`; do \
find $(__srctree)include/asm-$${arch} $(RCS_FIND_IGNORE) \
-name $1 -print; \
done ; \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: writeout stalls in current -git
On 11/5/07, David Chinner <[EMAIL PROTECTED]> wrote: > On Sun, Nov 04, 2007 at 12:19:19PM +0100, Torsten Kaiser wrote: > > I can now confirm, that I see this also with the current > > mainline-git-version > > I used 2.6.24-rc1-git-b4f555081fdd27d13e6ff39d455d5aefae9d2c0c > > plus the fix for the sg changes in ieee1394. > > Ok, so it's probably a side effect of the writeback changes. > > Attached are two patches (two because one was in a separate patchset as > a standalone change) that should prevent async writeback from blocking > on locked inode cluster buffers. Apply the xfs-factor-inotobp patch first. > Can you see if this fixes the problem? Applied both patches against the kernel mentioned above. This blows up at boot: [ 80.807589] Filesystem "dm-0": Disabling barriers, not supported by the underlying device [ 80.820241] XFS mounting filesystem dm-0 [ 80.913144] [ cut here ] [ 80.914932] kernel BUG at drivers/md/raid5.c:143! [ 80.916751] invalid opcode: [1] SMP [ 80.918338] CPU 3 [ 80.919142] Modules linked in: [ 80.920345] Pid: 974, comm: md1_raid5 Not tainted 2.6.24-rc1 #3 [ 80.922628] RIP: 0010:[] [] __release_stripe+0x164/0x170 [ 80.925935] RSP: 0018:8100060e7dd0 EFLAGS: 00010002 [ 80.927987] RAX: RBX: 81010141c288 RCX: [ 80.930738] RDX: RSI: 81010141c288 RDI: 810004fb3200 [ 80.933488] RBP: 810004fb3200 R08: R09: 0005 [ 80.936240] R10: 0e00 R11: e200038465e8 R12: 81010141c298 [ 80.938990] R13: 0286 R14: 810004fb3330 R15: [ 80.941741] FS: 0060c870() GS:810100313700() knlGS: [ 80.944861] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 80.947080] CR2: 7fff7b295000 CR3: 000101842000 CR4: 06e0 [ 80.949830] DR0: DR1: DR2: [ 80.952580] DR3: DR6: 0ff0 DR7: 0400 [ 80.955332] Process md1_raid5 (pid: 974, threadinfo 8100060e6000, task 81000645c730) [ 80.958584] Stack: 81010141c288 01f4 810004fb3200 804b6f2d [ 80.961761] 01f4 81010141c288 804c8bd0 [ 80.964681] 8100060e7ee8 804bd094 81000645c730 8100060e7e70 [ 80.967518] Call Trace: [ 80.968558] [] release_stripe+0x3d/0x60 [ 80.970677] [] md_thread+0x0/0x100 [ 80.972629] [] raid5d+0x344/0x450 [ 80.974549] [] process_timeout+0x0/0x10 [ 80.976668] [] schedule_timeout+0x5a/0xd0 [ 80.978855] [] md_thread+0x0/0x100 [ 80.980807] [] md_thread+0x30/0x100 [ 80.982794] [] autoremove_wake_function+0x0/0x30 [ 80.985214] [] md_thread+0x0/0x100 [ 80.987167] [] kthread+0x4b/0x80 [ 80.989054] [] child_rip+0xa/0x12 [ 80.990972] [] kthread+0x0/0x80 [ 80.992824] [] child_rip+0x0/0x12 [ 80.994743] [ 80.995588] [ 80.995588] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 48 83 ec 28 48 89 5c 24 [ 80.999307] RIP [] __release_stripe+0x164/0x170 [ 81.001711] RSP Switching back to unpatched 2.6.23-mm1 boots sucessfull... Torsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Dolding wrote: > On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote: >> --- Peter Dolding <[EMAIL PROTECTED]> wrote: >> Posix capabilities predate SELinux. SELinux is not interested in >> Posix capabilities. >> >>> But no IBM had to do it. >> Err, no. It was done by Andrew Morgan back in the dark ages. >> Why on earth do you think IBM did it? > > Posix file capabilities the option to replace SUID bit with something > more security safe only handing out segments of root power instead of > the complete box and dice like SUID. Even different on a user by user > base. > > Posix capabilites is what Posix file capabilities is based on. Yes I > know the words appear close. The word file is important. Please read > Website. http://www.ibm.com/developerworks/linux/library/l-posixcap.html For the record, I think you are both right. I took a stab at it back when Casey and I first met: ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README all that stuff worked fine it was just a bit ahead of its time... - From memory, at that point in time "extended attributes" were an external patch, and having some trouble getting merged. My sense was that EA was a pre-requisite and I was happy to wait for that support to become integrated before pushing my file capability support. In the midst of all this LSM emerged as a reaction to Linus' clear unhappiness about all extensions security. I didn't have the time to participate in the LSM, and my work sat in the form of these patches. SELinux at that time existed as a separate infrastructure, and evidently did have the time to embrace LSM. > IBM coders worked and got it into the main line really recently to > provide at least some way to avoid fault of SUID of course it could [...] So, yes, IBM (Serge) deserve full credit for starting over, and getting it merged... Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFHLr6EQheEq9QabfIRAsOrAJ9XzTL0Lqm5jaxwO6UoPB9Pwh3SzQCfVWFd cPyjsGp/s6D6HuBE6M4NJH0= =G/ah -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Linux Security *Module* Framework (Was: LSM conversion to static interface
Tetsuo Handa wrote: > I think there are two other problems regarding LSM. > > (1) There is only one "struct security_ops" structure in the system. > > (2) There is only one "void *security" field in "struct task_struct". > > > Years ago, there was only one MAC implementation (i.e. SELinux) > in the mainline kernel. > But now, there are many MAC (or access control/tracking) implementations > waiting for inclusion into the mainline kernel. > The competition for occupying "struct security_ops" has started. > > My idea is that, why not create chains of "struct security_ops" > (i.e. linked list of "struct security_ops") > and allow choosing which chain to use for per a "struct task_struct" basis > (i.e. add "struct security_ops" to "struct task_struct"). > That idea was in the Stacker module, and it was tabled until there is more than one upstream LSM. In particular, it requires 2 or more LSMs that actually make sense to stack together. IMHO TOMOYO/AppArmor/SELinux are all exclusive of one another (in a running kernel) and real stacking is still pending useful component intrusion prevention modules. Such modules can be built, they just have not yet been built. > TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use > "struct security_ops" since SELinux is occupying it. > Just disable SELinux and load TOMOYO. Oh, you can't because someone has made modules not be loadable :( Hmmm, perhaps someone could fix that by reverting the static interface patch ... :) > May be we should consider stackable LSM again? > Exactly. Stacker was shelved, so to speak :) because of the lack of in-kernel modules. Soon it will be time to reconsider that. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 series] DRM memory manager core
> > I think its about time we merged this code, it is in an area of the > kernel wholly self-contained and mostly maintained by me, and adds a > feature that allows userspace graphics to leverage features of graphics > cards that only the binary vendors have done up until now. And I mean to -mm now via my git tree,... and the kernel in the next revision.. Also we couldn't develop this stuff in-tree up until now as the API has undergone a major re-work and is only now what we consider stable.. Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: USB device DMA support on OMAP2
On 11/5/07, David Brownell <[EMAIL PROTECTED]> wrote: > > The current omap udc dosen't support the DMA mode > > It most certainly does!! I think you it has DMA issues on OMAP2. > Ah, Yes, OMAP1 supports the DMA mode. It means the OMAP2 DMA support. > > > and it has some problem at setup time on OMAP2 with previous patch file. > > I found that the code assumes bulk out required the big data transfer. > > But MODE SELECT(6) sent the only 24 bytes. it makes a problem. > > So I implement the small packets handling for it. > > > > It is tested with both linux and windows. > > > > Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]> > > I'll have a look at it, thanks. > > Is this aginst the linux-omap tree, or current kernel.org code? > (There _shouldn't_ be any differences, but I've not checked in > some time now and such issues do creep in from time to time.) > There's some difference related with double buffering. It's against the latest kernel code. I checked it. Thank you, Kyungmin Park - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 series] DRM memory manager core
Hi all, These patches are the first set of patches containing the core components of the DRI memory manger from Tungsten Graphics. At least one patch is too big for the list, and I spent a lot of time getting the separation even to this level... the patches are here: http://people.freedesktop.org/~airlied/ttm/ What is this? The DRI memory manager is a new unified memory manager for GPUs initially targetted at Intel Integrated devices. http://www.tungstengraphics.com/wiki/index.php/TTM_Memory_Manager What's changed recently? The major thrust of recent work has been to try and stabilise the memory manager API (ioctls) such that we believe they are supportable going forward. Thomas Hellstrom (TG), Eric Anholt (Intel) and me (Red Hat), have worked to create a cleaner API that we believe should provide the functionality we need from a GPU memory manager going forward. We have focused on the API as this is set in stone once we merge the code into a stable kernel. What are in these patches? The patches contain the changes to the core DRM infrastructure to add support for fencing and buffer objects. It doesn't contain the AGP backend or the i915 driver which will be posted later. Issues raised previously: 1. use of proc - drm already uses proc so until all of the drm moves out of proc, no point adding a whole new interface just for one info file. 2. heuristic for memory limiting. - Users can allocate a lot of locked memory using the GPU memory manager this is required for graphics applications. The current code just imposes a limit worked out from the amount of low memory. We have talked to benh about trying to solve this in a generic way along with SPU. 3. style - yes the code should nearly all be kernel style, and I don't think it introduces any new compat wrappers or anything for ppl to give out about (except maybe the memory limiter). I think its about time we merged this code, it is in an area of the kernel wholly self-contained and mostly maintained by me, and adds a feature that allows userspace graphics to leverage features of graphics cards that only the binary vendors have done up until now. Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: USB device DMA support on OMAP2
> The current omap udc dosen't support the DMA mode It most certainly does!! I think you it has DMA issues on OMAP2. > and it has some problem at setup time on OMAP2 with previous patch file. > I found that the code assumes bulk out required the big data transfer. > But MODE SELECT(6) sent the only 24 bytes. it makes a problem. > So I implement the small packets handling for it. > > It is tested with both linux and windows. > > Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]> I'll have a look at it, thanks. Is this aginst the linux-omap tree, or current kernel.org code? (There _shouldn't_ be any differences, but I've not checked in some time now and such issues do creep in from time to time.) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2/2] sg_ring instead of scatterlist chaining in virtio
Example using virtio.
The interface actually improves because we don't need to hand two lengths to
add_buf (it needs an input and output sg[], so we used to hand one pointer
and a counter of how many were in and how many out, now we can neatly hand
two separate sgs).
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index a901eee..6a9b54d 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -23,7 +23,9 @@ struct virtio_blk
mempool_t *pool;
/* Scatterlist: can be too big for stack. */
- struct scatterlist sg[3+MAX_PHYS_SEGMENTS];
+ DECLARE_SG(out, 1);
+ DECLARE_SG(in, 1);
+ DECLARE_SG(sg, MAX_PHYS_SEGMENTS);
};
struct virtblk_req
@@ -69,8 +71,8 @@ static bool blk_done(struct virtqueue *vq)
static bool do_req(struct request_queue *q, struct virtio_blk *vblk,
struct request *req)
{
- unsigned long num, out, in;
struct virtblk_req *vbr;
+ struct sg_ring *in;
vbr = mempool_alloc(vblk->pool, GFP_ATOMIC);
if (!vbr)
@@ -94,23 +96,24 @@ static bool do_req(struct request_queue *q, struct
virtio_blk *vblk,
if (blk_barrier_rq(vbr->req))
vbr->out_hdr.type |= VIRTIO_BLK_T_BARRIER;
- /* We have to zero this, otherwise blk_rq_map_sg gets upset. */
- memset(vblk->sg, 0, sizeof(vblk->sg));
- sg_set_buf(>sg[0], >out_hdr, sizeof(vbr->out_hdr));
- num = blk_rq_map_sg(q, vbr->req, vblk->sg+1);
- sg_set_buf(>sg[num+1], >in_hdr, sizeof(vbr->in_hdr));
+ sg_init_single(>out.ring, >out_hdr, sizeof(vbr->out_hdr));
+ sg_ring_init(>sg.ring, ARRAY_SIZE(vblk->sg.sg));
+ vblk->sg.ring.num = blk_rq_map_sg(q, vbr->req, vblk->sg.sg);
+ sg_init_single(>in.ring, >in_hdr, sizeof(vbr->in_hdr));
if (rq_data_dir(vbr->req) == WRITE) {
vbr->out_hdr.type |= VIRTIO_BLK_T_OUT;
- out = 1 + num;
- in = 1;
+ /* Chain write request onto output buffers. */
+ list_add_tail(>sg.ring.list, >out.ring.list);
+ in = >in.ring;
} else {
vbr->out_hdr.type |= VIRTIO_BLK_T_IN;
- out = 1;
- in = 1 + num;
+ /* Chain input (status) buffer at end of read buffers. */
+ list_add_tail(>in.ring.list, >sg.ring.list);
+ in = >sg.ring;
}
- if (vblk->vq->vq_ops->add_buf(vblk->vq, vblk->sg, out, in, vbr)) {
+ if (vblk->vq->vq_ops->add_buf(vblk->vq, >out.ring, in, vbr)) {
mempool_free(vbr, vblk->pool);
return false;
}
@@ -127,7 +130,7 @@ static void do_virtblk_request(struct request_queue *q)
while ((req = elv_next_request(q)) != NULL) {
vblk = req->rq_disk->private_data;
- BUG_ON(req->nr_phys_segments > ARRAY_SIZE(vblk->sg));
+ BUG_ON(req->nr_phys_segments > ARRAY_SIZE(vblk->sg.sg));
/* If this request fails, stop queue and wait for something to
finish to restart it. */
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 100e8a2..e4d90c7 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -54,15 +54,15 @@ static struct hv_ops virtio_cons;
* immediately (lguest's Launcher does). */
static int put_chars(u32 vtermno, const char *buf, int count)
{
- struct scatterlist sg[1];
+ DECLARE_SG(sg, 1);
unsigned int len;
/* This is a convenient routine to initialize a single-elem sg list */
- sg_init_one(sg, buf, count);
+ sg_init_single(, buf, count);
/* add_buf wants a token to identify this buffer: we hand it any
* non-NULL pointer, since there's only ever one buffer. */
- if (out_vq->vq_ops->add_buf(out_vq, sg, 1, 0, (void *)1) == 0) {
+ if (out_vq->vq_ops->add_buf(out_vq, , NULL, (void *)1) == 0) {
/* Tell Host to go! */
out_vq->vq_ops->kick(out_vq);
/* Chill out until it's done with the buffer. */
@@ -78,11 +78,12 @@ static int put_chars(u32 vtermno, const char *buf, int
count)
* queue. */
static void add_inbuf(void)
{
- struct scatterlist sg[1];
- sg_init_one(sg, inbuf, PAGE_SIZE);
+ DECLARE_SG(sg, 1);
+
+ sg_init_single(, inbuf, PAGE_SIZE);
/* We should always be able to add one buffer to an empty queue. */
- if (in_vq->vq_ops->add_buf(in_vq, sg, 0, 1, inbuf) != 0)
+ if (in_vq->vq_ops->add_buf(in_vq, NULL, , inbuf) != 0)
BUG();
in_vq->vq_ops->kick(in_vq);
}
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index e396c9d..2698592 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -143,20 +143,21 @@ drop:
static void try_fill_recv(struct virtnet_info *vi)
{
struct sk_buff *skb;
- struct scatterlist
2.6.24-rc1-gb4f5550 oops
Hi, I got this oops on 2.6.24-rc1-641-gb4f5550: [18073.371126] Unable to handle kernel NULL pointer dereference at 0120 RIP: [18073.371134] [] check_preempt_wakeup+0x6e/0x110 [18073.371144] PGD 81f9067 PUD 81c8067 PMD 0 [18073.371151] Oops: [1] PREEMPT SMP [18073.371157] CPU 2 [18073.371161] Modules linked in: vfat fat [18073.371168] Pid: 4639, comm: kwin Not tainted 2.6.24-rc1 #1 [18073.371171] RIP: 0010:[] [] check_preempt_wakeup+0x6e/0x110 [18073.371177] RSP: 0018:810008531a78 EFLAGS: 00010006 [18073.371179] RAX: RBX: RCX: [18073.371183] RDX: 810004441bf0 RSI: 81000801e860 RDI: 81000444ab80 [18073.371186] RBP: 810008531aa8 R08: 00d0d47a4a90 R09: [18073.371188] R10: 810004441bf0 R11: 0001 R12: 810006520400 [18073.371190] R13: 81000801e860 R14: 81000a63a000 R15: 81000443d8e0 [18073.371193] FS: 2b7d646a86f0() GS:810004c11780() knlGS: [18073.371196] CS: 0010 DS: ES: CR0: 8005003b [18073.371199] CR2: 0120 CR3: 08495000 CR4: 06e0 [18073.371202] DR0: DR1: DR2: [18073.371211] DR3: DR6: 0ff0 DR7: 0400 [18073.371214] Process kwin (pid: 4639, threadinfo 81000853, task 81000840a860) [18073.371216] Stack: 81000444ab80 0001 81000801e860 81000444ab80 [18073.371231] 0002 81000443d8e0 810008531b38 8023061e [18073.371238] 810004441b80 0002 0001 [18073.371245] Call Trace: [18073.371250] [] try_to_wake_up+0x2fe/0x3a0 [18073.371253] [] default_wake_function+0xd/0x10 [18073.371257] [] __wake_up_common+0x5a/0x90 [18073.371260] [] __wake_up_sync+0x4a/0x70 [18073.371264] [] unix_write_space+0x8f/0xa0 [18073.371269] [] sock_wfree+0x49/0x50 [18073.371272] [] __kfree_skb+0x69/0xe0 [18073.371275] [] kfree_skb+0x17/0x30 [18073.371278] [] unix_stream_recvmsg+0x267/0x610 [18073.371283] [] sock_aio_read+0x107/0x110 [18073.371287] [] do_sync_read+0xf1/0x130 [18073.371291] [] sock_ioctl+0x0/0x260 [18073.371295] [] autoremove_wake_function+0x0/0x40 [18073.371299] [] unix_ioctl+0xb2/0xf0 [18073.371302] [] sock_ioctl+0xd1/0x260 [18073.371305] [] do_ioctl+0x31/0x90 [18073.371308] [] vfs_read+0x156/0x160 [18073.371311] [] sys_read+0x50/0x90 [18073.371315] [] system_call+0x7e/0x83 [18073.371317] [18073.371319] [18073.371319] Code: 48 8b 90 20 01 00 00 48 39 93 20 01 00 00 75 e2 48 81 3b 00 [18073.371346] RIP [] check_preempt_wakeup+0x6e/0x110 [18073.371351] RSP [18073.371354] CR2: 0120 [18073.371358] note: kwin[4639] exited with preempt_count 3 Here's my config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc1 # Sun Nov 4 13:21:29 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y
[RFC PATCH 1/2] sg_ring instead of scatterlist chaining
Hi all,
This patch implements a header for a linked list of scatterlist
arrays, rather than using an extra entry and low pointer bits to chain them
together. I've tested that it's sane for virtio (which uses struct
scatterlist).
Features:
1) Neatens code by including length in structure.
2) Avoids end ambiguity by including maximum length too.
3) Works fine with old "sg is an array" interfaces.
4) Kinda icky for stack declaration, so hence a helper is created.
5) Lacks magic.
I reverted (most of?) the scatterlist chaining changes to create these
patches, so it won't apply to your kernels. The reversion patch isn't
interesting, so I haven't posted it.
Thanks,
Rusty.
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 4efbd9c..ce7e581 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -5,6 +5,51 @@
#include
#include
+/**
+ * struct sg_ring - a ring of scatterlists
+ * @list: the list_head chaining them together
+ * @num: the number of valid sg entries
+ * @max: the maximum number of sg entries (size of the sg array).
+ * @sg: the array of scatterlist entries.
+ *
+ * This provides a convenient encapsulation of one or more scatter gather
+ * arrays. */
+struct sg_ring
+{
+ struct list_head list;
+ unsigned int num, max;
+ struct scatterlist sg[0];
+};
+
+/* This helper declares an sg ring on the stack or in a struct. */
+#define DECLARE_SG(name, max) \
+ struct {\
+ struct sg_ring ring;\
+ struct scatterlist sg[max]; \
+ } name
+
+/**
+ * sg_ring_init - initialize a scatterlist ring.
+ * @sg: the sg_ring.
+ * @max: the size of the trailing sg array.
+ *
+ * After initialization sg is alone in the ring. */
+static inline void sg_ring_init(struct sg_ring *sg, unsigned int max)
+{
+ INIT_LIST_HEAD(>list);
+ sg->max = max;
+}
+
+/**
+ * sg_ring_next - next array in a scatterlist ring.
+ * @sg: the sg_ring.
+ *
+ * After initialization sg is alone in the ring. */
+static inline struct sg_ring *sg_ring_next(struct sg_ring *sg)
+{
+ return list_first_entry(>list, struct sg_ring, list);
+}
+
static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
unsigned int buflen)
{
@@ -20,4 +65,20 @@ static inline void sg_init_one(struct scatterlist *sg, const
void *buf,
sg_set_buf(sg, buf, buflen);
}
+/**
+ * sg_init_single - initialize a one-element scatterlist ring.
+ * @sg: the sg_ring.
+ * @buf: the pointer to the buffer.
+ * @buflen: the length of the buffer.
+ *
+ * Does sg_ring_init and also sets up first (and only) sg element. */
+static inline void sg_init_single(struct sg_ring *sg,
+ const void *buf,
+ unsigned int buflen)
+{
+ sg_ring_init(sg, 1);
+ sg->num = 1;
+ sg_init_one(>sg[0], buf, buflen);
+}
+
#endif /* _LINUX_SCATTERLIST_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
USB device DMA support on OMAP2
The current omap udc dosen't support the DMA mode
and it has some problem at setup time on OMAP2 with previous patch file.
I found that the code assumes bulk out required the big data transfer.
But MODE SELECT(6) sent the only 24 bytes. it makes a problem.
So I implement the small packets handling for it.
It is tested with both linux and windows.
Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c
index 983337e..9719f08 100644
--- a/drivers/usb/gadget/omap_udc.c
+++ b/drivers/usb/gadget/omap_udc.c
@@ -4,6 +4,8 @@
* Copyright (C) 2004 Texas Instruments, Inc.
* Copyright (C) 2004-2005 David Brownell
*
+ * OMAP2 & DMA support by Kyungmin Park <[EMAIL PROTECTED]>
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -60,11 +62,6 @@
/* bulk DMA seems to be behaving for both IN and OUT */
#defineUSE_DMA
-/* FIXME: OMAP2 currently has some problem in DMA mode */
-#ifdef CONFIG_ARCH_OMAP2
-#undef USE_DMA
-#endif
-
/* ISO too */
#defineUSE_ISO
@@ -73,6 +70,8 @@
#defineDMA_ADDR_INVALID(~(dma_addr_t)0)
+#define OMAP2_DMA_CH(ch) (((ch) - 1) << 1)
+#define OMAP24XX_DMA(name, ch) (OMAP24XX_DMA_##name + OMAP2_DMA_CH(ch))
/*
* The OMAP UDC needs _very_ early endpoint setup: before enabling the
@@ -571,20 +570,25 @@ static void next_in_dma(struct omap_ep *ep, struct
omap_req *req)
const int sync_mode = cpu_is_omap15xx()
? OMAP_DMA_SYNC_FRAME
: OMAP_DMA_SYNC_ELEMENT;
+ int dma_trigger = 0;
+
+ if (cpu_is_omap24xx())
+ dma_trigger = OMAP24XX_DMA(USB_W2FC_TX0, ep->dma_channel);
/* measure length in either bytes or packets */
if ((cpu_is_omap16xx() && length <= UDC_TXN_TSC)
+ || (cpu_is_omap24xx() && length < ep->maxpacket)
|| (cpu_is_omap15xx() && length < ep->maxpacket)) {
txdma_ctrl = UDC_TXN_EOT | length;
omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S8,
- length, 1, sync_mode, 0, 0);
+ length, 1, sync_mode, dma_trigger, 0);
} else {
length = min(length / ep->maxpacket,
(unsigned) UDC_TXN_TSC + 1);
txdma_ctrl = length;
omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S16,
ep->ep.maxpacket >> 1, length, sync_mode,
- 0, 0);
+ dma_trigger, 0);
length *= ep->maxpacket;
}
omap_set_dma_src_params(ep->lch, OMAP_DMA_PORT_EMIFF,
@@ -622,20 +626,31 @@ static void finish_in_dma(struct omap_ep *ep, struct
omap_req *req, int status)
static void next_out_dma(struct omap_ep *ep, struct omap_req *req)
{
- unsigned packets;
+ unsigned packets = req->req.length - req->req.actual;
+ int dma_trigger = 0;
+
+ if (cpu_is_omap24xx())
+ dma_trigger = OMAP24XX_DMA(USB_W2FC_RX0, ep->dma_channel);
/* NOTE: we filtered out "short reads" before, so we know
* the buffer has only whole numbers of packets.
+* except MODE SELECT(6) sent the 24 bytes data in OMAP24XX DMA mode
*/
-
- /* set up this DMA transfer, enable the fifo, start */
- packets = (req->req.length - req->req.actual) / ep->ep.maxpacket;
- packets = min(packets, (unsigned)UDC_RXN_TC + 1);
- req->dma_bytes = packets * ep->ep.maxpacket;
- omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S16,
- ep->ep.maxpacket >> 1, packets,
- OMAP_DMA_SYNC_ELEMENT,
- 0, 0);
+ if (cpu_is_omap24xx() && packets < ep->maxpacket) {
+ omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S8,
+ packets, 1, OMAP_DMA_SYNC_ELEMENT,
+ dma_trigger, 0);
+ req->dma_bytes = packets;
+ } else {
+ /* set up this DMA transfer, enable the fifo, start */
+ packets /= ep->ep.maxpacket;
+ packets = min(packets, (unsigned)UDC_RXN_TC + 1);
+ req->dma_bytes = packets * ep->ep.maxpacket;
+ omap_set_dma_transfer_params(ep->lch, OMAP_DMA_DATA_TYPE_S16,
+ ep->ep.maxpacket >> 1, packets,
+ OMAP_DMA_SYNC_ELEMENT,
+ dma_trigger, 0);
+ }
omap_set_dma_dest_params(ep->lch, OMAP_DMA_PORT_EMIFF,
OMAP_DMA_AMODE_POST_INC, req->req.dma + req->req.actual,
0, 0);
@@
Re: [PATCH 3/6]] POWERPC: fix memset size error
On Mon, 2007-11-05 at 10:21 +0800, Li Zefan wrote:
> The size passing to memset is wrong.
>
> Signed-off-by Li Zefan <[EMAIL PROTECTED]>
Good catch, looks like a remain of when path was an array on the stack.
Thanks !
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
>
> ---
> arch/powerpc/kernel/prom_init.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 1db10f7..1add6ef 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1244,7 +1244,7 @@ static void __init prom_initialize_tce_table(void)
> local_alloc_bottom = base;
>
> /* It seems OF doesn't null-terminate the path :-( */
> - memset(path, 0, sizeof(path));
> + memset(path, 0, PROM_SCRATCH_SIZE);
> /* Call OF to setup the TCE hardware */
> if (call_prom("package-to-path", 3, 1, node,
> path, PROM_SCRATCH_SIZE-1) == PROM_ERROR) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] ARM: fix memset size error
Robert P. J. Day wrote:
> On Mon, 5 Nov 2007, Li Zefan wrote:
>
>> The size passing to memset is wrong. And here we can replace
>> kmalloc with kzalloc.
>>
>> Signed-off-by Li Zefan <[EMAIL PROTECTED]>
>>
>> ---
>> arch/arm/common/uengine.c |6 ++
>> 1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/common/uengine.c b/arch/arm/common/uengine.c
>> index 95c8508..117cab3 100644
>> --- a/arch/arm/common/uengine.c
>> +++ b/arch/arm/common/uengine.c
>> @@ -374,8 +374,8 @@ static int set_initial_registers(int uengine, struct
>> ixp2000_uengine_code *c)
>> u8 *ucode;
>> int i;
>>
>> -gpr_a = kmalloc(128 * sizeof(u32), GFP_KERNEL);
>> -gpr_b = kmalloc(128 * sizeof(u32), GFP_KERNEL);
>> +gpr_a = kzalloc(128 * sizeof(u32), GFP_KERNEL);
>> +gpr_b = kzalloc(128 * sizeof(u32), GFP_KERNEL);
>> ucode = kmalloc(513 * 5, GFP_KERNEL);
>> if (gpr_a == NULL || gpr_b == NULL || ucode == NULL) {
>> kfree(ucode);
>> @@ -388,8 +388,6 @@ static int set_initial_registers(int uengine, struct
>> ixp2000_uengine_code *c)
>> if (c->uengine_parameters & IXP2000_UENGINE_4_CONTEXTS)
>> per_ctx_regs = 32;
>>
>> -memset(gpr_a, 0, sizeof(gpr_a));
>> -memset(gpr_b, 0, sizeof(gpr_b));
>> for (i = 0; i < 256; i++) {
>> struct ixp2000_reg_value *r = c->initial_reg_values + i;
>> u32 *bank;
>>
> it's unlikely that patch will cause any trouble whatsoever, but
> notice that it *is* changing the underlying logic. those original
> memsets should probably have been written initially as
> "sizeof(*gpr_a)" so they would previously have zeroed only memory the
> ^
> size of a pointer, no?
>
> now, i'm guessing the logic is correct but i figured it's worth
> noting what the code *used* to do. unless i'm misreading something
> horribly.
>
In the for loop, some elems of gpr_a and gpr_b will be assigned with a value,
but not all elems. So those unassigned elems should be filled with 0.
I think it happens now and then to mistake to regard a pointer as a static
array, and I guess this is what sizeof(gpr_a) means.
Li Zefan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Bluez-devel] [BUG] rfcomm]
On 10/24/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > > Hello, > > I have this issue for long time (At least from linux-2.6.18). > I think it is about time I report this... :) > > When coming out of suspend (uswsusp or suspend2) if rfcomm was > active it creates this dump. > > If you need any more info I will be glad to provide. > > Best Regards, > Alon Bar-Lev. > > --- > > Oct 23 17:51:33 alon1 acpid: received event "button/power PWRF 0080 > 0001" > Oct 23 17:51:33 alon1 acpid: notifying client 7903[0:0] > Oct 23 17:51:33 alon1 acpid: notifying client 7804[0:0] > Oct 23 17:51:33 alon1 acpid: executing action "/etc/acpi/default.sh > button/power PWRF 0080 0001" > Oct 23 17:52:13 alon1 ntpd[8186]: synchronized to 192.115.25.179, stratum 2 > Oct 23 17:52:16 alon1 swsusp: Marking nosave pages: 0009f000 - > 0010 > Oct 23 17:52:16 alon1 swsusp: Basic memory bitmaps created > Oct 23 19:41:22 alon1 pppd[25041]: Hangup (SIGHUP) > Oct 23 19:41:22 alon1 pppd[25041]: Modem hangup > Oct 23 19:41:22 alon1 pppd[25041]: Connect time 384.5 minutes. > Oct 23 19:41:22 alon1 pppd[25041]: Sent 512470 bytes, received 1546102 bytes. > Oct 23 19:41:22 alon1 pppd[25041]: Connection terminated. > Oct 23 19:41:40 alon1 Stopping tasks ... done. > Oct 23 19:41:40 alon1 Shrinking memory... - \ | / - \ | / - \ | / - \ | / - > \ | / - \ | / - \ | / - \ | / - \ | / - \ | done (224831 pages freed) > Oct 23 19:41:40 alon1 Freed 899324 kbytes in 14.70 seconds (61.17 MB/s) > Oct 23 19:41:40 alon1 Suspending console(s) > Oct 23 19:41:40 alon1 usbfs 2-2:1.0: no suspend for driver usbfs? > Oct 23 19:41:40 alon1 pnp: Device 00:0c disabled. > Oct 23 19:41:40 alon1 eth0: Going into suspend... > Oct 23 19:41:40 alon1 ACPI: PCI interrupt for device :02:02.0 disabled > Oct 23 19:41:40 alon1 ACPI handle has no context! > Oct 23 19:41:40 alon1 ACPI: PCI interrupt for device :02:01.0 disabled > Oct 23 19:41:40 alon1 ACPI handle has no context! > Oct 23 19:41:40 alon1 radeonfb (:01:00.0): suspending for event: 1... > Oct 23 19:41:40 alon1 ACPI: PCI interrupt for device :00:1f.5 disabled > Oct 23 19:41:40 alon1 ACPI: PCI interrupt for device :00:1d.7 disabled > Oct 23 19:41:40 alon1 ACPI: PCI interrupt for device :00:1d.2 disabled > Oct 23 19:41:40 alon1 ACPI: PCI interrupt for device :00:1d.1 disabled > Oct 23 19:41:40 alon1 ACPI: PCI interrupt for device :00:1d.0 disabled > Oct 23 19:41:40 alon1 swsusp: critical section: > Oct 23 19:41:40 alon1 swsusp: Need to copy 126188 pages > Oct 23 19:41:40 alon1 Intel machine check architecture supported. > Oct 23 19:41:40 alon1 Intel machine check reporting enabled on CPU#0. > Oct 23 19:41:40 alon1 ACPI: PCI Interrupt :00:1d.0[A] -> Link [LNKA] -> > GSI 11 (level, low) -> IRQ 11 > Oct 23 19:41:40 alon1 PCI: Setting latency timer of device :00:1d.0 to 64 > Oct 23 19:41:40 alon1 usb usb1: root hub lost power or was reset > Oct 23 19:41:40 alon1 ACPI: PCI Interrupt :00:1d.1[B] -> Link [LNKD] -> > GSI 11 (level, low) -> IRQ 11 > Oct 23 19:41:40 alon1 PCI: Setting latency timer of device :00:1d.1 to 64 > Oct 23 19:41:40 alon1 usb usb2: root hub lost power or was reset > Oct 23 19:41:40 alon1 ACPI: PCI Interrupt :00:1d.2[C] -> Link [LNKC] -> > GSI 11 (level, low) -> IRQ 11 > Oct 23 19:41:40 alon1 PCI: Setting latency timer of device :00:1d.2 to 64 > Oct 23 19:41:40 alon1 usb usb3: root hub lost power or was reset > Oct 23 19:41:40 alon1 ACPI: PCI Interrupt :00:1d.7[D] -> Link [LNKH] -> > GSI 11 (level, low) -> IRQ 11 > Oct 23 19:41:40 alon1 PCI: Setting latency timer of device :00:1d.7 to 64 > Oct 23 19:41:40 alon1 usb usb4: root hub lost power or was reset > Oct 23 19:41:40 alon1 ehci_hcd :00:1d.7: debug port 1 > Oct 23 19:41:40 alon1 PCI: cache line size of 32 is not supported by device > :00:1d.7 > Oct 23 19:41:40 alon1 PCI: Setting latency timer of device :00:1e.0 to 64 > Oct 23 19:41:40 alon1 ACPI: PCI Interrupt :00:1f.1[A] -> Link [LNKC] -> > GSI 11 (level, low) -> IRQ 11 > Oct 23 19:41:42 alon1 PM: Writing back config space on device :00:1f.5 at > offset 1 (was 297, writing 293) > Oct 23 19:41:42 alon1 ACPI: PCI Interrupt :00:1f.5[B] -> Link [LNKB] -> > GSI 11 (level, low) -> IRQ 11 > Oct 23 19:41:42 alon1 PCI: Setting latency timer of device :00:1f.5 to 64 > Oct 23 19:41:42 alon1 radeonfb (:01:00.0): resuming from state: 1... > Oct 23 19:41:42 alon1 PM: Writing back config space on device :02:00.0 at > offset f (was 3c0010b, writing 5c0010b) > Oct 23 19:41:42 alon1 PM: Writing back config space on device :02:00.0 at > offset 3 (was 824008, writing 82a810) > Oct 23 19:41:42 alon1 PM: Writing back config space on device :02:00.0 at > offset 1 (was 2100107, writing 217) > Oct 23 19:41:42 alon1 PM: Writing back config space on device :02:00.1 at > offset f (was 3c0020b, writing 5c0020b) > Oct 23 19:41:42 alon1 PM: Writing back config
[PATCH]bluetooth rfcomm_dev refcount bug fix
In the rfcomm_tty_hangup the rfcomm_dev refcnt should be dropped later.
If rfcomm_dev is destructed in tty_hangup function, then the later tty_close
function will oops.
BUG: unable to handle kernel NULL pointer dereference at virtual address
0008
printing eip: c01c0884 *pde =
Oops: [#1] PREEMPT SMP
Modules linked in: bnep rfcomm l2cap snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss e100
psmouse btusb bluetooth evdev sg thermal snd_hda_intel snd_pcm serio_raw
snd_timer snd processor button rtc_cmos pcspkr rtc_core rtc_lib intel_agp
agpgart soundcore snd_page_alloc i2c_i801
Pid: 2621, comm: rfcomm Not tainted (2.6.24-rc1 #3)
EIP: 0060:[] EFLAGS: 00010246 CPU: 1
EIP is at sysfs_move_dir+0x24/0x1d0
EAX: c04e4028 EBX: c1c3314c ECX: EDX: c1c3314c
ESI: c1c3314c EDI: EBP: ESP: c2e7be1c
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process rfcomm (pid: 2621, ti=c2e7a000 task=c2764590 task.ti=c2e7a000)
Stack: 000a 3d92326f c26dcd90 c048ff2b c278dda8
c1c3314c c2780690 c26dcd90 c0249d22 c26dcd90 c048ff1d c2780690 fff4
c26dcd90 c278dd20 c1c3314c c02b43bb c278dda8
Call Trace:
[] kobject_move+0xa2/0x120
[] device_move+0x5b/0x120
[] rfcomm_tty_close+0x8e/0xd0 [rfcomm]
[] release_dev+0x58a/0x6b0
[] con_put_char+0x30/0x40
[] remove_wait_queue+0x1a/0x50
[] default_wake_function+0x0/0x10
[] write_chan+0x1b9/0x200
[] __wake_up+0x3e/0x60
[] tty_ldisc_deref+0x63/0x80
[] tty_release+0xf/0x20
[] __fput+0x14e/0x180
[] filp_close+0x3c/0x80
[] sys_close+0x69/0xd0
[] syscall_call+0x7/0xb
[] wait_for_common+0x60/0x160
===
Code: 6c 24 28 83 c4 2c c3 55 57 31 ff 56 53 83 ec 1c 89 d3 8b 68 1c 31 c0 89
44 24 18 31 c0 89 44 24 14 b8 28 40 4e c0 e8 0c fe 23 00 <8b> 55 08 85 d2 0f 84
65 01 00 00 8b 73 1c b8 a0 40 4e c0 85 f6
EIP: [] sysfs_move_dir+0x24/0x1d0 SS:ESP 0068:c2e7be1c
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
net/bluetooth/rfcomm/tty.c |7 ---
1 file changed, 7 deletions(-)
diff -upr linux/net/bluetooth/rfcomm/tty.c linux.new/net/bluetooth/rfcomm/tty.c
--- linux/net/bluetooth/rfcomm/tty.c2007-11-05 11:28:49.0 +0800
+++ linux.new/net/bluetooth/rfcomm/tty.c2007-11-05 11:30:59.0
+0800
@@ -1018,13 +1018,6 @@ static void rfcomm_tty_hangup(struct tty
return;
rfcomm_tty_flush_buffer(tty);
-
- if (test_bit(RFCOMM_RELEASE_ONHUP, >flags)) {
- if (rfcomm_dev_get(dev->id) == NULL)
- return;
- rfcomm_dev_del(dev);
- rfcomm_dev_put(dev);
- }
}
static int rfcomm_tty_read_proc(char *buf, char **start, off_t offset, int
len, int *eof, void *unused)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] ARM: fix memset size error
On Mon, 5 Nov 2007, Li Zefan wrote:
> The size passing to memset is wrong. And here we can replace
> kmalloc with kzalloc.
>
> Signed-off-by Li Zefan <[EMAIL PROTECTED]>
>
> ---
> arch/arm/common/uengine.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/common/uengine.c b/arch/arm/common/uengine.c
> index 95c8508..117cab3 100644
> --- a/arch/arm/common/uengine.c
> +++ b/arch/arm/common/uengine.c
> @@ -374,8 +374,8 @@ static int set_initial_registers(int uengine, struct
> ixp2000_uengine_code *c)
> u8 *ucode;
> int i;
>
> - gpr_a = kmalloc(128 * sizeof(u32), GFP_KERNEL);
> - gpr_b = kmalloc(128 * sizeof(u32), GFP_KERNEL);
> + gpr_a = kzalloc(128 * sizeof(u32), GFP_KERNEL);
> + gpr_b = kzalloc(128 * sizeof(u32), GFP_KERNEL);
> ucode = kmalloc(513 * 5, GFP_KERNEL);
> if (gpr_a == NULL || gpr_b == NULL || ucode == NULL) {
> kfree(ucode);
> @@ -388,8 +388,6 @@ static int set_initial_registers(int uengine, struct
> ixp2000_uengine_code *c)
> if (c->uengine_parameters & IXP2000_UENGINE_4_CONTEXTS)
> per_ctx_regs = 32;
>
> - memset(gpr_a, 0, sizeof(gpr_a));
> - memset(gpr_b, 0, sizeof(gpr_b));
> for (i = 0; i < 256; i++) {
> struct ixp2000_reg_value *r = c->initial_reg_values + i;
> u32 *bank;
>
it's unlikely that patch will cause any trouble whatsoever, but
notice that it *is* changing the underlying logic. those original
memsets should probably have been written initially as
"sizeof(*gpr_a)" so they would previously have zeroed only memory the
^
size of a pointer, no?
now, i'm guessing the logic is correct but i figured it's worth
noting what the code *used* to do. unless i'm misreading something
horribly.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Sun, 4 Nov 2007 17:34:39 +0100 > But the main point that stuff like e.g. -I/usr/local/dist/include that > might in some environments be correct for all and required for most > userspace software should not leak into the kernel still stands. You can have a "myconfigure" shell script that runs ./configure in the current directory with the args you want for stuff like that. There is no need to contaminate your environment by setting CFLAGS globally. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Sun, 4 Nov 2007 16:29:30 +0100 > On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote: > > People can't have it both ways. CFLAGS has global meaning in every > > Makefile based build tree, it's not an "autoconf" thing. This is well > > established practice, and I think it's a good thing the kernel does it > > now too. > > Makefiles do normally not pick such variables from the environment. The absolutely do. All of the default builtin compilation rules inside of GNU make, and every other UNIX make out there, do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86 setup: correct booting on 486 (revised)
Just for the record, I realized this patch could be done slightly cleaner and cleaned it up accordingly. git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git for-linus H. Peter Anvin (2): x86 setup: add a near jump to serialize %cr0 on 386/486 x86 setup: set %ebx == %ebp == %edi == 0 on protected mode entry arch/x86/boot/pmjump.S |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) commit 9f259cc59ba45b8db401d60be9700e275676fb15 Author: H. Peter Anvin <[EMAIL PROTECTED]> Date: Sun Nov 4 17:54:31 2007 -0800 x86 setup: set %ebx == %ebp == %edi == 0 on protected mode entry In accordance with the newly formalized 32-bit boot protocol, set %ebx == %ebp == %edi == 0 in order to support future extensions to the protocol. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S index 26baeab..fa6bed1 100644 --- a/arch/x86/boot/pmjump.S +++ b/arch/x86/boot/pmjump.S @@ -28,11 +28,13 @@ * void protected_mode_jump(u32 entrypoint, u32 bootparams); */ protected_mode_jump: - xorl%ebx, %ebx # Flag to indicate this is a boot movl%edx, %esi # Pointer to boot_params table movl%eax, 2f# Patch ljmpl instruction movw$__BOOT_DS, %cx + xorl%ebx, %ebx # Per the 32-bit boot protocol + xorl%ebp, %ebp # Per the 32-bit boot protocol + xorl%edi, %edi # Per the 32-bit boot protocol movl%cr0, %edx orb $1, %dl # Protected mode (PE) bit commit 7ed192906a2144ebc8ca2925a85d27b9c5355668 Author: H. Peter Anvin <[EMAIL PROTECTED]> Date: Sun Nov 4 17:50:12 2007 -0800 x86 setup: add a near jump to serialize %cr0 on 386/486 The 386 and 486 needs a jump immediately after setting %cr0 in order to serialize the pipeline. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S index 2e55923..26baeab 100644 --- a/arch/x86/boot/pmjump.S +++ b/arch/x86/boot/pmjump.S @@ -31,14 +31,14 @@ protected_mode_jump: xorl%ebx, %ebx # Flag to indicate this is a boot movl%edx, %esi # Pointer to boot_params table movl%eax, 2f# Patch ljmpl instruction - jmp 1f # Short jump to flush instruction q. -1: movw$__BOOT_DS, %cx movl%cr0, %edx orb $1, %dl # Protected mode (PE) bit movl%edx, %cr0 + jmp 1f # Short jump to serialize on 386/486 +1: movw%cx, %ds movw%cx, %es - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: device struct bloat
On Sun, Nov 04, 2007 at 09:29:18PM +0100, Peter Zijlstra wrote: > > On Sat, 2007-11-03 at 12:48 -0700, Stephen Hemminger wrote: > > The sizeof(struct device) is way too big, especially in the network device > > case. > > We want to support 1000's of device's and the change from class_device to > > net_device has caused needless bloat. > > > > sizeof(struct device) = 272 > > sizeof(struct class_device) = 92 > > * not the class_id in class_device could also be removed or changed to > > a ptr, since it is redundant for net_devices. > > The thing that surprised me most was that it contains a struct > semaphore, Greg, is that really needed? Yes, it serializes bind and unbind stuff for the device. There are comments about it in drivers/base/dd.c if you want to look into it. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: duplicated include files
On Sun, 4 Nov 2007, Jeremy Fitzhardinge wrote: > Robert P. J. Day wrote: > > actually, one wonders if there's any value in keeping any references > > to other version control systems such as subversion, SCCS, CVS, > > mercurial, etc. > > What do you mean by "other"? git doesn't have a monopoly, and the > kernel should support people using a reasonable set of version > control systems. Supporting VSS would be strange, but nothing wrong > with the set you listed, if people find those systems useful. It's > not like it amounts to a huge amount of effort to do so. you're right, my mistake, i was just caught up in a git-centered perspective. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] IA64: fix memset size error
On Mon, Nov 05, 2007 at 10:20:12AM +0800, Li Zefan wrote:
> Li Zefan wrote:
> > The size arguments passing to memset is wrong.
> >
> > Signed-off-by Li Zefan <[EMAIL PROTECTED]>
This looks correct to me. Acked.
> >
> > ---
> > drivers/video/ps3fb.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
>
> Sorry, please ignore the wrong patch, and here is the right one:
>
> ---
> arch/ia64/kernel/efi.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
> index 3f7ea13..0e4ef20 100644
> --- a/arch/ia64/kernel/efi.c
> +++ b/arch/ia64/kernel/efi.c
> @@ -218,7 +218,7 @@ efi_gettimeofday (struct timespec *ts)
> {
> efi_time_t tm;
>
> - memset(ts, 0, sizeof(ts));
> + memset(ts, 0, sizeof(*ts));
> if ((*efi.get_time)(, NULL) != EFI_SUCCESS)
> return;
>
> --
> 1.5.3.rc7
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] IA64: fix memset size error
On Mon, Nov 05, 2007 at 10:17:24AM +0800, Li Zefan wrote:
> The size arguments passing to memset is wrong.
>
> Signed-off-by Li Zefan <[EMAIL PROTECTED]>
This looks correct to me. Acked.
> ---
> drivers/video/ps3fb.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> index b3463dd..75836aa 100644
> --- a/drivers/video/ps3fb.c
> +++ b/drivers/video/ps3fb.c
> @@ -727,7 +727,7 @@ static int ps3fb_blank(int blank, struct fb_info *info)
>
> static int ps3fb_get_vblank(struct fb_vblank *vblank)
> {
> - memset(vblank, 0, sizeof());
> + memset(vblank, 0, sizeof(*vblank));
> vblank->flags = FB_VBLANK_HAVE_VSYNC;
> return 0;
> }
> --
> 1.5.3.rc7
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] POSIX TIMER: coding style: no space between asterisk and variable name
Here we delete the space between '*' and the following variable/function
name.
Signed-off-by Li Zefan <[EMAIL PROTECTED]>
---
include/linux/posix-timers.h | 16
kernel/posix-timers.c|8
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
index a7dd38f..83adff7 100644
--- a/include/linux/posix-timers.h
+++ b/include/linux/posix-timers.h
@@ -67,19 +67,19 @@ struct k_itimer {
struct k_clock {
int res;/* in nanoseconds */
int (*clock_getres) (const clockid_t which_clock, struct timespec *tp);
- int (*clock_set) (const clockid_t which_clock, struct timespec * tp);
- int (*clock_get) (const clockid_t which_clock, struct timespec * tp);
+ int (*clock_set) (const clockid_t which_clock, struct timespec *tp);
+ int (*clock_get) (const clockid_t which_clock, struct timespec *tp);
int (*timer_create) (struct k_itimer *timer);
int (*nsleep) (const clockid_t which_clock, int flags,
struct timespec *, struct timespec __user *);
long (*nsleep_restart) (struct restart_block *restart_block);
- int (*timer_set) (struct k_itimer * timr, int flags,
- struct itimerspec * new_setting,
- struct itimerspec * old_setting);
- int (*timer_del) (struct k_itimer * timr);
+ int (*timer_set) (struct k_itimer *timr, int flags,
+ struct itimerspec *new_setting,
+ struct itimerspec *old_setting);
+ int (*timer_del) (struct k_itimer *timr);
#define TIMER_RETRY 1
- void (*timer_get) (struct k_itimer * timr,
- struct itimerspec * cur_setting);
+ void (*timer_get) (struct k_itimer *timr,
+ struct itimerspec *cur_setting);
};
void register_posix_clock(const clockid_t clock_id, struct k_clock *new_clock);
diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
index f1461f8..1c4c04c 100644
--- a/kernel/posix-timers.c
+++ b/kernel/posix-timers.c
@@ -398,7 +398,7 @@ static enum hrtimer_restart posix_timer_fn(struct hrtimer
*timer)
return ret;
}
-static struct task_struct * good_sigevent(sigevent_t * event)
+static struct task_struct *good_sigevent(sigevent_t *event)
{
struct task_struct *rtn = current->group_leader;
@@ -427,7 +427,7 @@ void register_posix_clock(const clockid_t clock_id, struct
k_clock *new_clock)
}
EXPORT_SYMBOL_GPL(register_posix_clock);
-static struct k_itimer * alloc_posix_timer(void)
+static struct k_itimer *alloc_posix_timer(void)
{
struct k_itimer *tmr;
tmr = kmem_cache_zalloc(posix_timers_cache, GFP_KERNEL);
@@ -462,7 +462,7 @@ static void release_posix_timer(struct k_itimer *tmr, int
it_id_set)
asmlinkage long
sys_timer_create(const clockid_t which_clock,
struct sigevent __user *timer_event_spec,
-timer_t __user * created_timer_id)
+timer_t __user *created_timer_id)
{
int error = 0;
struct k_itimer *new_timer = NULL;
@@ -593,7 +593,7 @@ out:
* the find to the timer lock. To avoid a dead lock, the timer id MUST
* be release with out holding the timer lock.
*/
-static struct k_itimer * lock_timer(timer_t timer_id, unsigned long *flags)
+static struct k_itimer *lock_timer(timer_t timer_id, unsigned long *flags)
{
struct k_itimer *timr;
/*
--
1.5.3.rc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] POSIX TIMER: coding style: leave a space after the comma
Here we add a space after ','
Signed-off-by Li Zefan <[EMAIL PROTECTED]>
---
kernel/posix-timers.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
index 35b4bbf..f1461f8 100644
--- a/kernel/posix-timers.c
+++ b/kernel/posix-timers.c
@@ -296,7 +296,7 @@ void do_schedule_next_timer(struct siginfo *info)
unlock_timer(timr, flags);
}
-int posix_timer_event(struct k_itimer *timr,int si_private)
+int posix_timer_event(struct k_itimer *timr, int si_private)
{
memset(>sigq->info, 0, sizeof(siginfo_t));
timr->sigq->info.si_sys_private = si_private;
--
1.5.3.rc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] POSIX TIMER: coding style fixes
Hi, These two patches fix the coding style in posix timer. Li Zefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: duplicated include files
On Sun, Nov 04, 2007 at 08:03:48PM +0100, Adrian Bunk wrote: > BTW: "make includecheck" already does the same... > When was that added? It's not listed in the 'make help', and I see there's a versioncheck too that's not reported. Some of these are actually useful, I wonder what else is lurking in the depths of undocumented Makefile target land ;-) docs: Add includecheck/versioncheck to 'make help' Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> --- diff --git a/Makefile b/Makefile index 188c3b6..1ab40ac 100644 --- a/Makefile +++ b/Makefile @@ -1168,6 +1168,8 @@ help: @echo '' @echo 'Static analysers' @echo ' checkstack - Generate a list of stack hogs' + @echo ' versioncheck- Sanity check on version.h usage' + @echo ' includecheck- Sanity check on duplicate includes' @echo ' namespacecheck - Name space analysis on compiled kernel' @echo ' export_report - List the usages of all exported symbols' @if [ -r $(srctree)/include/asm-$(SRCARCH)/Kbuild ]; then \ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Spelling fix: lenght->length
On 11/4/07, Paulius Zaleckas <[EMAIL PROTECTED]> wrote:
I noticed a couple of additional typos, in the diff-provided material
near the patch.
> diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
> index 2d48018..837183c 100644
> --- a/arch/ppc/syslib/ppc_sys.c
> +++ b/arch/ppc/syslib/ppc_sys.c
> @@ -185,7 +185,7 @@ void platform_notify_map(const struct
> platform_notify_dev_map *map,
> */
>
> /*
> - Here we'll replace .name pointers with fixed-lenght strings
> + Here we'll replace .name pointers with fixed-length strings
> Hereby, this should be called *before* any func stuff triggeded.
---
Not your patch, but "triggeded" -> "triggered"; and I'm wondering what
the "Hereby"
is supposed to mean - seems like it might be meant to be "Therefore".
---
> */
> void ppc_sys_device_initfunc(void)
> diff --git a/drivers/media/video/pwc/pwc-if.c
> b/drivers/media/video/pwc/pwc-if.c
> index 7300ace..f991d72 100644
> --- a/drivers/media/video/pwc/pwc-if.c
> +++ b/drivers/media/video/pwc/pwc-if.c
> @@ -542,7 +542,7 @@ int pwc_handle_frame(struct pwc_device *pdev)
> }
>
> if (pdev->read_frame != NULL) {
> - /* Decompression is a lenghty process, so it's outside of the
> lock.
> + /* Decompression is a lengthy process, so it's outside of the
> lock.
>This gives the isoc_handler the opportunity to fill more
> frames
>in the mean time.
---
"mean time" -> "meantime"
---
> */
--
scott preece
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] W1: fix memset size error
The size arguments passing to memset is wrong.
Signed-off-by Li Zefan <[EMAIL PROTECTED]>
---
drivers/w1/masters/ds2490.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/w1/masters/ds2490.c b/drivers/w1/masters/ds2490.c
index 299e274..b63b5e0 100644
--- a/drivers/w1/masters/ds2490.c
+++ b/drivers/w1/masters/ds2490.c
@@ -233,7 +233,7 @@ static int ds_recv_status_nodump(struct ds_device *dev,
struct ds_status *st,
{
int count, err;
- memset(st, 0, sizeof(st));
+ memset(st, 0, sizeof(*st));
count = 0;
err = usb_bulk_msg(dev->udev, usb_rcvbulkpipe(dev->udev,
dev->ep[EP_STATUS]), buf, size, , 100);
--
1.5.3.rc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] drivers/video/ps3fb: fix memset size error
The size passing to memset is wrong.
Signed-off-by Li Zefan <[EMAIL PROTECTED]>
---
drivers/video/ps3fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index b3463dd..75836aa 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -727,7 +727,7 @@ static int ps3fb_blank(int blank, struct fb_info *info)
static int ps3fb_get_vblank(struct fb_vblank *vblank)
{
- memset(vblank, 0, sizeof());
+ memset(vblank, 0, sizeof(*vblank));
vblank->flags = FB_VBLANK_HAVE_VSYNC;
return 0;
}
--
1.5.3.rc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] DRM: fix memset size error
The size passing to memset is wrong. Signed-off-by Li Zefan <[EMAIL PROTECTED]> --- drivers/char/drm/drm_ioctl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/drm/drm_ioctl.c b/drivers/char/drm/drm_ioctl.c index d9be146..3cbebf8 100644 --- a/drivers/char/drm/drm_ioctl.c +++ b/drivers/char/drm/drm_ioctl.c @@ -272,7 +272,7 @@ int drm_getstats(struct drm_device *dev, void *data, struct drm_stats *stats = data; int i; - memset(stats, 0, sizeof(stats)); + memset(stats, 0, sizeof(*stats)); mutex_lock(>struct_mutex); -- 1.5.3.rc7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6]] POWERPC: fix memset size error
The size passing to memset is wrong.
Signed-off-by Li Zefan <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/prom_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1db10f7..1add6ef 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1244,7 +1244,7 @@ static void __init prom_initialize_tce_table(void)
local_alloc_bottom = base;
/* It seems OF doesn't null-terminate the path :-( */
- memset(path, 0, sizeof(path));
+ memset(path, 0, PROM_SCRATCH_SIZE);
/* Call OF to setup the TCE hardware */
if (call_prom("package-to-path", 3, 1, node,
path, PROM_SCRATCH_SIZE-1) == PROM_ERROR) {
--
1.5.3.rc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] IA64: fix memset size error
Li Zefan wrote:
> The size arguments passing to memset is wrong.
>
> Signed-off-by Li Zefan <[EMAIL PROTECTED]>
>
> ---
> drivers/video/ps3fb.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
Sorry, please ignore the wrong patch, and here is the right one:
---
arch/ia64/kernel/efi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 3f7ea13..0e4ef20 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -218,7 +218,7 @@ efi_gettimeofday (struct timespec *ts)
{
efi_time_t tm;
- memset(ts, 0, sizeof(ts));
+ memset(ts, 0, sizeof(*ts));
if ((*efi.get_time)(, NULL) != EFI_SUCCESS)
return;
--
1.5.3.rc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] ARM: fix memset size error
The size passing to memset is wrong. And here we can replace
kmalloc with kzalloc.
Signed-off-by Li Zefan <[EMAIL PROTECTED]>
---
arch/arm/common/uengine.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/common/uengine.c b/arch/arm/common/uengine.c
index 95c8508..117cab3 100644
--- a/arch/arm/common/uengine.c
+++ b/arch/arm/common/uengine.c
@@ -374,8 +374,8 @@ static int set_initial_registers(int uengine, struct
ixp2000_uengine_code *c)
u8 *ucode;
int i;
- gpr_a = kmalloc(128 * sizeof(u32), GFP_KERNEL);
- gpr_b = kmalloc(128 * sizeof(u32), GFP_KERNEL);
+ gpr_a = kzalloc(128 * sizeof(u32), GFP_KERNEL);
+ gpr_b = kzalloc(128 * sizeof(u32), GFP_KERNEL);
ucode = kmalloc(513 * 5, GFP_KERNEL);
if (gpr_a == NULL || gpr_b == NULL || ucode == NULL) {
kfree(ucode);
@@ -388,8 +388,6 @@ static int set_initial_registers(int uengine, struct
ixp2000_uengine_code *c)
if (c->uengine_parameters & IXP2000_UENGINE_4_CONTEXTS)
per_ctx_regs = 32;
- memset(gpr_a, 0, sizeof(gpr_a));
- memset(gpr_b, 0, sizeof(gpr_b));
for (i = 0; i < 256; i++) {
struct ixp2000_reg_value *r = c->initial_reg_values + i;
u32 *bank;
--
1.5.3.rc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] IA64: fix memset size error
The size arguments passing to memset is wrong.
Signed-off-by Li Zefan <[EMAIL PROTECTED]>
---
drivers/video/ps3fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index b3463dd..75836aa 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -727,7 +727,7 @@ static int ps3fb_blank(int blank, struct fb_info *info)
static int ps3fb_get_vblank(struct fb_vblank *vblank)
{
- memset(vblank, 0, sizeof());
+ memset(vblank, 0, sizeof(*vblank));
vblank->flags = FB_VBLANK_HAVE_VSYNC;
return 0;
}
--
1.5.3.rc7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] drm patches for 2.6.24-rc2
Typical of me, I found another issue so I've just repushed the tree..
If you have or haven't pulled, please re-pull..
Please pull from 'drm-patches' branch of
master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
to receive the following updates:
drivers/char/drm/drmP.h |2 --
drivers/char/drm/drm_os_linux.h |8
drivers/char/drm/radeon_cp.c|5 +++--
drivers/char/drm/radeon_drv.h |1 +
drivers/char/drm/savage_bci.c |3 ---
drivers/char/drm/sis_mm.c |1 +
6 files changed, 5 insertions(+), 15 deletions(-)
Dave Airlie (3):
radeon: set the address to access the GART table on the CPU side correctly
drm: remove second forward decleration of drm device struct.
drm: remove remnants of DRM_COPY_FROM/TO_USER_IOCTL
Roel Kluin (1):
drm/sis: missing mutex unlock in error path.
diff --git a/drivers/char/drm/drmP.h b/drivers/char/drm/drmP.h
index 9dd0760..dde02a1 100644
--- a/drivers/char/drm/drmP.h
+++ b/drivers/char/drm/drmP.h
@@ -559,8 +559,6 @@ struct drm_mm {
* a family of cards. There will one drm_device for each card present
* in this family
*/
-struct drm_device;
-
struct drm_driver {
int (*load) (struct drm_device *, unsigned long flags);
int (*firstopen) (struct drm_device *);
diff --git a/drivers/char/drm/drm_os_linux.h b/drivers/char/drm/drm_os_linux.h
index 76e44ac..daa69c9 100644
--- a/drivers/char/drm/drm_os_linux.h
+++ b/drivers/char/drm/drm_os_linux.h
@@ -62,14 +62,6 @@ static __inline__ int mtrr_del(int reg, unsigned long base,
unsigned long size)
#endif
-/** For data going into the kernel through the ioctl argument */
-#define DRM_COPY_FROM_USER_IOCTL(arg1, arg2, arg3) \
- if ( copy_from_user(, arg2, arg3) )\
- return -EFAULT
-/** For data going from the kernel through the ioctl argument */
-#define DRM_COPY_TO_USER_IOCTL(arg1, arg2, arg3) \
- if ( copy_to_user(arg1, , arg3) ) \
- return -EFAULT
/** Other copying of data to kernel space */
#define DRM_COPY_FROM_USER(arg1, arg2, arg3) \
copy_from_user(arg1, arg2, arg3)
diff --git a/drivers/char/drm/radeon_cp.c b/drivers/char/drm/radeon_cp.c
index 335423c..24fca8e 100644
--- a/drivers/char/drm/radeon_cp.c
+++ b/drivers/char/drm/radeon_cp.c
@@ -1679,7 +1679,7 @@ static int radeon_do_init_cp(struct drm_device * dev,
drm_radeon_init_t * init)
dev_priv->gart_info.bus_addr =
dev_priv->pcigart_offset + dev_priv->fb_location;
dev_priv->gart_info.mapping.offset =
- dev_priv->gart_info.bus_addr;
+ dev_priv->pcigart_offset + dev_priv->fb_aper_offset;
dev_priv->gart_info.mapping.size =
dev_priv->gart_info.table_size;
@@ -2275,7 +2275,8 @@ int radeon_driver_firstopen(struct drm_device *dev)
if (ret != 0)
return ret;
- ret = drm_addmap(dev, drm_get_resource_start(dev, 0),
+ dev_priv->fb_aper_offset = drm_get_resource_start(dev, 0);
+ ret = drm_addmap(dev, dev_priv->fb_aper_offset,
drm_get_resource_len(dev, 0), _DRM_FRAME_BUFFER,
_DRM_WRITE_COMBINING, );
if (ret != 0)
diff --git a/drivers/char/drm/radeon_drv.h b/drivers/char/drm/radeon_drv.h
index e4077bc..bfbb60a 100644
--- a/drivers/char/drm/radeon_drv.h
+++ b/drivers/char/drm/radeon_drv.h
@@ -293,6 +293,7 @@ typedef struct drm_radeon_private {
/* starting from here on, data is preserved accross an open */
uint32_t flags; /* see radeon_chip_flags */
+ unsigned long fb_aper_offset;
} drm_radeon_private_t;
typedef struct drm_radeon_buf_priv {
diff --git a/drivers/char/drm/savage_bci.c b/drivers/char/drm/savage_bci.c
index 59484d5..d465b2f 100644
--- a/drivers/char/drm/savage_bci.c
+++ b/drivers/char/drm/savage_bci.c
@@ -968,9 +968,6 @@ static int savage_bci_event_wait(struct drm_device *dev,
void *data, struct drm_
DRM_DEBUG("\n");
- DRM_COPY_FROM_USER_IOCTL(event, (drm_savage_event_wait_t __user *) data,
-sizeof(event));
-
UPDATE_EVENT_COUNTER();
if (dev_priv->status_ptr)
hw_e = dev_priv->status_ptr[1] & 0x;
diff --git a/drivers/char/drm/sis_mm.c b/drivers/char/drm/sis_mm.c
index 6be1c57..a6b7ccd 100644
--- a/drivers/char/drm/sis_mm.c
+++ b/drivers/char/drm/sis_mm.c
@@ -134,6 +134,7 @@ static int sis_drm_alloc(struct drm_device *dev, struct
drm_file *file_priv,
dev_priv->agp_initialized)) {
DRM_ERROR
("Attempt to allocate from uninitialized memory
manager.\n");
+ mutex_unlock(>struct_mutex);
return -EINVAL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
[GIT PULL] x86 setup: correct booting on 486 (revised)
Hi Linus; please pull: git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git for-linus H. Peter Anvin (2): x86 setup: add a near jump to serialize %cr0 on 386/486 x86 setup: set %ebx == %ebp == %edi == 0 on protected mode entry arch/x86/boot/pmjump.S | 12 1 files changed, 8 insertions(+), 4 deletions(-) commit 142a92e61f9c405a114cb2bfaf3ce3f537a48a89 Author: H. Peter Anvin <[EMAIL PROTECTED]> Date: Sun Nov 4 17:54:31 2007 -0800 x86 setup: set %ebx == %ebp == %edi == 0 on protected mode entry In accordance with the newly formalized 32-bit boot protocol, set %ebx == %ebp == %edi == 0 in order to support future extensions to the protocol. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S index 18732f7..0d24e96 100644 --- a/arch/x86/boot/pmjump.S +++ b/arch/x86/boot/pmjump.S @@ -28,13 +28,15 @@ * void protected_mode_jump(u32 entrypoint, u32 bootparams); */ protected_mode_jump: - xorl%ebx, %ebx # Flag to indicate this is a boot movl%edx, %esi # Pointer to boot_params table movl%eax, 3f# Patch ljmpl instruction jmp 1f # Short jump to flush instruction q. 1: movw$__BOOT_DS, %cx + xorl%ebx, %ebx # Per the 32-bit boot protocol + xorl%ebp, %ebp # Per the 32-bit boot protocol + xorl%edi, %edi # Per the 32-bit boot protocol movl%cr0, %edx orb $1, %dl # Protected mode (PE) bit commit ad676d0fdf2e59ccc28ee9f6f9593ff14a3d8a5a Author: H. Peter Anvin <[EMAIL PROTECTED]> Date: Sun Nov 4 17:50:12 2007 -0800 x86 setup: add a near jump to serialize %cr0 on 386/486 The 386 and 486 needs a jump immediately after setting %cr0 in order to serialize the pipeline. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S index 2e55923..18732f7 100644 --- a/arch/x86/boot/pmjump.S +++ b/arch/x86/boot/pmjump.S @@ -30,15 +30,17 @@ protected_mode_jump: xorl%ebx, %ebx # Flag to indicate this is a boot movl%edx, %esi # Pointer to boot_params table - movl%eax, 2f# Patch ljmpl instruction + movl%eax, 3f# Patch ljmpl instruction jmp 1f # Short jump to flush instruction q. - 1: + movw$__BOOT_DS, %cx movl%cr0, %edx orb $1, %dl # Protected mode (PE) bit movl%edx, %cr0 + jmp 2f # Short jump to serialize on 386/486 +2: movw%cx, %ds movw%cx, %es @@ -48,7 +50,7 @@ protected_mode_jump: # Jump to the 32-bit entrypoint .byte 0x66, 0xea # ljmpl opcode -2: .long 0 # offset +3: .long 0 # offset .word __BOOT_CS # segment .size protected_mode_jump, .-protected_mode_jump - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/6] fix memset size error
This series of six proposed patches fix the same kind of bug. The size passing to memset is the size of a pointer i.e. sizeof(ptr), and normally the right thing is sizeof(*ptr). Li Zefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Add and use media change notification
On Sun, 4 Nov 2007, Jeff Garzik wrote: > > The end to CD-ROM polling... newer SATA ATAPI hardware will emit > 'asynchronous notification' events when media is changed. This adds > support. I *really* didn't want to pull this. Not only is it after the -rc1 period, but I also think you pushed this ina really offensive manner, and I don't like how you and James have made this whole thing personal. You guys need to sort it out, and there is no way you can blame James for all your troubles, since I've heard the same kind of complaints about every single maintainer out there (including you) about some driver or other infrastructure issue. So I'm unhappy about pulling this. That said, I did finally decide to just pull it. Partly because the concept apparently has been in -mm for a while anyway (even if the final patch has not - but the patch itself isn't that large, I'd worry more about thngs like certain hardware simply not doing things right), but mostly because I hate it when others hold up driver features, and I decided that in this case this really is something that is better done earlier rather than later, to get exposure as soon as possible. But I really think you need to lay off James, and help him rather than make every single complaint a big flame-war! Please, Jeff? 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: writeout stalls in current -git
On Sun, Nov 04, 2007 at 12:19:19PM +0100, Torsten Kaiser wrote:
> On 11/2/07, David Chinner <[EMAIL PROTECTED]> wrote:
> > That's stalled waiting on the inode cluster buffer lock. That implies
> > that the inode lcuser is already being written out and the inode has
> > been redirtied during writeout.
> >
> > Does the kernel you are testing have the "flush inodes in ascending
> > inode number order" patches applied? If so, can you remove that
> > patch and see if the problem goes away?
>
> I can now confirm, that I see this also with the current mainline-git-version
> I used 2.6.24-rc1-git-b4f555081fdd27d13e6ff39d455d5aefae9d2c0c
> plus the fix for the sg changes in ieee1394.
Ok, so it's probably a side effect of the writeback changes.
Attached are two patches (two because one was in a separate patchset as
a standalone change) that should prevent async writeback from blocking
on locked inode cluster buffers. Apply the xfs-factor-inotobp patch first.
Can you see if this fixes the problem?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
---
fs/xfs/xfs_inode.c | 283 -
1 file changed, 129 insertions(+), 154 deletions(-)
Index: 2.6.x-xfs-new/fs/xfs/xfs_inode.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode.c 2007-09-12 15:41:22.0
+1000
+++ 2.6.x-xfs-new/fs/xfs/xfs_inode.c2007-09-13 08:57:06.395641940 +1000
@@ -124,6 +124,126 @@ xfs_inobp_check(
#endif
/*
+ * Simple wrapper for calling xfs_imap() that includes error
+ * and bounds checking
+ */
+STATIC int
+xfs_ino_to_imap(
+ xfs_mount_t *mp,
+ xfs_trans_t *tp,
+ xfs_ino_t ino,
+ xfs_imap_t *imap,
+ uintimap_flags)
+{
+ int error;
+
+ error = xfs_imap(mp, tp, ino, imap, imap_flags);
+ if (error) {
+ cmn_err(CE_WARN, "xfs_ino_to_imap: xfs_imap() returned an "
+ "error %d on %s. Returning error.",
+ error, mp->m_fsname);
+ return error;
+ }
+
+ /*
+* If the inode number maps to a block outside the bounds
+* of the file system then return NULL rather than calling
+* read_buf and panicing when we get an error from the
+* driver.
+*/
+ if ((imap->im_blkno + imap->im_len) >
+ XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks)) {
+ xfs_fs_cmn_err(CE_ALERT, mp, "xfs_ino_to_imap: "
+ "(imap->im_blkno (0x%llx) + imap->im_len (0x%llx)) > "
+ " XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks) (0x%llx)",
+ (unsigned long long) imap->im_blkno,
+ (unsigned long long) imap->im_len,
+ XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks));
+ return XFS_ERROR(EINVAL);
+ }
+ return 0;
+}
+
+/*
+ * Find the buffer associated with the given inode map
+ * We do basic validation checks on the buffer once it has been
+ * retrieved from disk.
+ */
+STATIC int
+xfs_imap_to_bp(
+ xfs_mount_t *mp,
+ xfs_trans_t *tp,
+ xfs_imap_t *imap,
+ xfs_buf_t **bpp,
+ uintbuf_flags,
+ uintimap_flags)
+{
+ int error;
+ int i;
+ int ni;
+ xfs_buf_t *bp;
+
+ error = xfs_trans_read_buf(mp, tp, mp->m_ddev_targp, imap->im_blkno,
+ (int)imap->im_len, XFS_BUF_LOCK, );
+ if (error) {
+ cmn_err(CE_WARN, "xfs_imap_to_bp: xfs_trans_read_buf()returned "
+ "an error %d on %s. Returning error.",
+ error, mp->m_fsname);
+ return error;
+ }
+
+ /*
+* Validate the magic number and version of every inode in the buffer
+* (if DEBUG kernel) or the first inode in the buffer, otherwise.
+*/
+#ifdef DEBUG
+ ni = BBTOB(imap->im_len) >> mp->m_sb.sb_inodelog;
+#else /* usual case */
+ ni = 1;
+#endif
+
+ for (i = 0; i < ni; i++) {
+ int di_ok;
+ xfs_dinode_t*dip;
+
+ dip = (xfs_dinode_t *)xfs_buf_offset(bp,
+ (i << mp->m_sb.sb_inodelog));
+ di_ok = be16_to_cpu(dip->di_core.di_magic) == XFS_DINODE_MAGIC
&&
+ XFS_DINODE_GOOD_VERSION(dip->di_core.di_version);
+ if (unlikely(XFS_TEST_ERROR(!di_ok, mp,
+ XFS_ERRTAG_ITOBP_INOTOBP,
+ XFS_RANDOM_ITOBP_INOTOBP))) {
+ if (imap_flags & XFS_IMAP_BULKSTAT) {
+ xfs_trans_brelse(tp, bp);
+ return XFS_ERROR(EINVAL);
Re: aim7 -30% regression in 2.6.24-rc1
On Thu, 2007-11-01 at 11:02 +0100, Cyrus Massoumi wrote: > Zhang, Yanmin wrote: > > On Wed, 2007-10-31 at 17:57 +0800, Zhang, Yanmin wrote: > >> On Tue, 2007-10-30 at 16:36 +0800, Zhang, Yanmin wrote: > >>> On Tue, 2007-10-30 at 08:26 +0100, Ingo Molnar wrote: > * Zhang, Yanmin <[EMAIL PROTECTED]> wrote: > > > sub-bisecting captured patch > > 38ad464d410dadceda1563f36bdb0be7fe4c8938(sched: uniform tunings) > > caused 20% regression of aim7. > > > > The last 10% should be also related to sched parameters, such like > > sysctl_sched_min_granularity. > ah, interesting. Since you have CONFIG_SCHED_DEBUG enabled, could you > please try to figure out what the best value for > /proc/sys/kernel_sched_latency, /proc/sys/kernel_sched_nr_latency and > /proc/sys/kernel_sched_min_granularity is? > > there's a tuning constraint for kernel_sched_nr_latency: > > - kernel_sched_nr_latency should always be set to > kernel_sched_latency/kernel_sched_min_granularity. (it's not a free > tunable) > > i suspect a good approach would be to double the value of > kernel_sched_latency and kernel_sched_nr_latency in each tuning > iteration, while keeping kernel_sched_min_granularity unchanged. That > will excercise the tuning values of the 2.6.23 kernel as well. > >>> I followed your idea to test 2.6.24-rc1. The improvement is slow. > >>> When sched_nr_latency=2560 and sched_latency_ns=64000, the performance > >>> is still about 15% less than 2.6.23. > >> I got the aim7 30% regression on my new upgraded stoakley machine. I found > >> this mahcine is slower than the old one. Maybe BIOS has issues, or > >> memeory(Might not > >> be dual-channel?) is slow. So I retested it on the old machine and found > >> on the old > >> stoakley machine, the regression is about 6%, quite similiar to the > >> regression on tigerton > >> machine. > >> > >> By sched_nr_latency=640 and sched_latency_ns=64000 on the old stoakley > >> machine, > >> the regression becomes about 2%. Other latency has more regression. > >> > >> On my tulsa machine, by sched_nr_latency=640 and > >> sched_latency_ns=64000, > >> the regression becomes less than 1% (The original regression is about 20%). > > I rerun SPECjbb by ched_nr_latency=640 and sched_latency_ns=64000. On > > tigerton, > > the regression is still more than 40%. On stoakley machine, it becomes > > worse (26%, > > original is 9%). I will do more investigation to make sure SPECjbb > > regression is > > also casued by the bad default values. > > > > We need a smarter method to calculate the best default values for the key > > tuning > > parameters. > > > > One interesting is sysbench+mysql(readonly) got the same result like 2.6.22 > > (no > > regression). Good job! > > Do you mean you couldn't reproduce the regression which was reported > with 2.6.23 (http://lkml.org/lkml/2007/10/30/53) with 2.6.24-rc1? It looks like you missed my emails. Firstly, I reproduced (or just find the same myself :) ) the issue with kernel 2.6.22, 2.6.23-rc and 2.6.23. Ingo wrote a big patch to fix it and the new patch is in 2.6.24-rc1 now. Then I retested it with 2.6.24-rc1 on a couple of x86_64 machines. The issue disappeared. You could test it with 2.6.24-rc1. > It > would be nice if you could provide some numbers for 2.6.22, 2.6.23 and > 2.6.24-rc1. Sorry. Intel policy doesn't allow me to publish the numbers because only specific departments in Intel could do that. But I could talk the regression percentage. -yanmin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix i486 boot failure due to stale %ds
On Sun, 04 Nov 2007 15:51:43 -0800, H. Peter Anvin wrote: > Mikael, can you try this patch (rev 3) on your 486? It works fine. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
duplicate device name print out by dev_xxxx
All, I found in recent kernel that dev_() macros will print out duplicate device name, which is a bit ugly. And this is true at least for platform_device. The reason is due to dev_printk() printing out both dev_driver_string(dev) and (dev)->bus_id, the latter is assigned with the same driver name for a platform_device. Any idea on this? -- Cheers - eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 setup: correct booting on 486DX4
On Sun, 4 Nov 2007, Eric W. Biederman wrote: > > I do seem to recall etherboot having a far jump in that spot and it > working on everything from a 386 on up. So I'm not certain if the > kind of jump matters. Still the kernel has a lot more exposure. I actually suspect you could have just about anything in there, including just a couple of nops, or just avoiding certain instructions for a few cycles. The i386/i486 pipeline isn't actually all that long (I ca't find it here, but I want to say it was just five stages), and the whole/only issue with writing to cr0 on those CPU's is literally that there isn't any forwarding of the cr0 state, so any instruction that actually has depend on the cr0 value needs to have that value stable in the register by the time it executes. So I literally suspect that just a couple of no-ops in between the move to cr0 and any instruction that depends on the state of the PE bit would be ok. And there aren't that many instructions that do, it's generally just the ones that load a segment that can care. But I'd actually be worried about a ljmp directly after the "move to cr0", exactly because an ljump actually does have semantic dependencies on the PE bit. But it's quite likely that ljmp is microcoded (it takes 12+ cycles even in real mode), and since microcode was nonpipelined, that would hide it. But "move to segment" is definitely *not* microcoded in real mode (it's documented as just two cycles for reg->seg), so I'm not at all surprised that "mov->cr0" followed immediately by "mov->seg" will not work. In short: - far jumps are in the "dangerous instruction" category after a change to PE. I would suggest not using it, although I also suspect that it probably works if only because it's probably microcoded on at least an i386. - instead of a short taken jump, you can almost certainly use anything that is microcoded or just otherwise takes enough cycles (where "enough" is likely in the 5-10 range) to make sure the writeback to CR0 is stable by the time any instruction uses it. - almost anything that doesn't actually involve a segment descriptor lookup is probably not going to care at all about the value of PE. The PE bit really doesn't affect all that much of the x86 instruction set, and if an instruction doesn't care, it doesn't matter whether it's executed with the old or the new value. 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/
[git pull] drm patches for 2.6.24-rc2
Hi Linus,
Please pull from 'drm-patches' branch of
master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
to receive the following updates:
drivers/char/drm/radeon_cp.c |5 +++--
drivers/char/drm/radeon_drv.h |1 +
drivers/char/drm/sis_mm.c |1 +
3 files changed, 5 insertions(+), 2 deletions(-)
Dave Airlie (1):
radeon: set the address to access the GART table on the CPU side correctly
Roel Kluin (1):
drm/sis: missing mutex unlock in error path.
diff --git a/drivers/char/drm/radeon_cp.c b/drivers/char/drm/radeon_cp.c
index 335423c..24fca8e 100644
--- a/drivers/char/drm/radeon_cp.c
+++ b/drivers/char/drm/radeon_cp.c
@@ -1679,7 +1679,7 @@ static int radeon_do_init_cp(struct drm_device * dev,
drm_radeon_init_t * init)
dev_priv->gart_info.bus_addr =
dev_priv->pcigart_offset + dev_priv->fb_location;
dev_priv->gart_info.mapping.offset =
- dev_priv->gart_info.bus_addr;
+ dev_priv->pcigart_offset + dev_priv->fb_aper_offset;
dev_priv->gart_info.mapping.size =
dev_priv->gart_info.table_size;
@@ -2275,7 +2275,8 @@ int radeon_driver_firstopen(struct drm_device *dev)
if (ret != 0)
return ret;
- ret = drm_addmap(dev, drm_get_resource_start(dev, 0),
+ dev_priv->fb_aper_offset = drm_get_resource_start(dev, 0);
+ ret = drm_addmap(dev, dev_priv->fb_aper_offset,
drm_get_resource_len(dev, 0), _DRM_FRAME_BUFFER,
_DRM_WRITE_COMBINING, );
if (ret != 0)
diff --git a/drivers/char/drm/radeon_drv.h b/drivers/char/drm/radeon_drv.h
index e4077bc..bfbb60a 100644
--- a/drivers/char/drm/radeon_drv.h
+++ b/drivers/char/drm/radeon_drv.h
@@ -293,6 +293,7 @@ typedef struct drm_radeon_private {
/* starting from here on, data is preserved accross an open */
uint32_t flags; /* see radeon_chip_flags */
+ unsigned long fb_aper_offset;
} drm_radeon_private_t;
typedef struct drm_radeon_buf_priv {
diff --git a/drivers/char/drm/sis_mm.c b/drivers/char/drm/sis_mm.c
index 6be1c57..a6b7ccd 100644
--- a/drivers/char/drm/sis_mm.c
+++ b/drivers/char/drm/sis_mm.c
@@ -134,6 +134,7 @@ static int sis_drm_alloc(struct drm_device *dev, struct
drm_file *file_priv,
dev_priv->agp_initialized)) {
DRM_ERROR
("Attempt to allocate from uninitialized memory
manager.\n");
+ mutex_unlock(>struct_mutex);
return -EINVAL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Smackv10: Smack rules grammar + their stateful parser(2)
On Sat, Nov 03, 2007 at 06:43:06PM +0200, Ahmed S. Darwish wrote:
> On Fri, Nov 02, 2007 at 01:50:55PM -0700, Casey Schaufler wrote:
> >
> > Still to come:
> >
> > - Final cleanup of smack_load_write and smack_cipso_write.
>
> Hi All,
>
> After agreeing with Casey on the "load" input grammar yesterday, here's
> the final grammar and its parser (which needs more testing):
>
> A Smack Rule in an "egrep" format is:
>
> "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n"
>
> where Subject/Object strings are in the form:
>
> "^[^/[:space:][:cntrl:]]{1,SMK_MAXLEN}$"
>
> Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
> ---
>
Same parser with adhering Casey's concers about previous one
and with using the FSM states in a more readable way.
I've double-checked the code for any possible off-by-one/overflow
errors. Could someone overcheck this for any possible hidden
security holes. Al, please :) ?
diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index 3572ae5..c9461cb 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "smack.h"
/*
@@ -67,6 +68,47 @@ struct smk_list_entry *smack_list;
#defineSEQ_READ_FINISHED 1
/*
+ * Disable concurrent writing open() operations
+ */
+static struct semaphore smack_write_sem;
+
+/*
+ * States for parsing /smack/load rules
+ */
+enum load_state {
+ bol = 0,/* At Beginning Of Line */
+ subject = 1,/* At a "subject" token */
+ object = 2,/* At an "object" token */
+ access = 3,/* At an "access" token */
+ newline = 4,/* At end Of Line */
+ blank= 5,/* At a space or tab */
+};
+
+/*
+ * Represent current parsing state of /smack/load. Struct
+ * also stores data needed between an open-release session's
+ * multiple write() calls
+ */
+static struct smack_load_state {
+ enum load_state state; /* Current FSM parsing state */
+ enum load_state prevstate; /* Previous FSM state */
+ enum load_state prevtoken; /* Handle state = prevstate = blank */
+ struct smack_rule rule; /* Rule to be loaded */
+ int label_len; /* Subject/Object labels length so far */
+ char subject[SMK_LABELLEN]; /* Subject label */
+ char object[SMK_LABELLEN]; /* Object label */
+} *load_state;
+
+/*
+ * Rule's tokens separators are spaces and tabs only
+ */
+static inline int isblank(char c)
+{
+ return (c == ' ' || c == '\t');
+}
+
+
+/*
* Seq_file read operations for /smack/load
*/
@@ -131,12 +173,43 @@ static struct seq_operations load_seq_ops = {
* @inode: inode structure representing file
* @file: "load" file pointer
*
- * Connect our load_seq_* operations with /smack/load
- * file_operations
+ * For reading, use load_seq_* seq_file reading operations.
+ * For writing, prepare a load_state struct to parse
+ * incoming rules.
*/
static int smk_open_load(struct inode *inode, struct file *file)
{
- return seq_open(file, _seq_ops);
+ if ((file->f_flags & O_ACCMODE) == O_RDONLY)
+ return seq_open(file, _seq_ops);
+
+ if (down_interruptible(_write_sem))
+ return -ERESTARTSYS;
+
+ load_state = kzalloc(sizeof(struct smack_load_state), GFP_KERNEL);
+ if (!load_state)
+ return -ENOMEM;
+
+ return 0;
+}
+
+/**
+ * smk_release_load - release() for /smack/load
+ * @inode: inode structure representing file
+ * @file: "load" file pointer
+ *
+ * For a reading session, use the seq_file release
+ * implementation.
+ * Otherwise, we are at the end of a writing session so
+ * clean everything up.
+ */
+static int smk_release_load(struct inode *inode, struct file *file)
+{
+ if ((file->f_flags & O_ACCMODE) == O_RDONLY)
+ return seq_release(inode, file);
+
+ kfree(load_state);
+ up(_write_sem);
+ return 0;
}
/**
@@ -174,7 +247,6 @@ static void smk_set_access(struct smack_rule *srp)
return;
}
-
/**
* smk_write_load - write() for /smack/load
* @filp: file pointer, not actually used
@@ -182,19 +254,26 @@ static void smk_set_access(struct smack_rule *srp)
* @count: bytes sent
* @ppos: where to start
*
- * Returns number of bytes written or error code, as appropriate
+ * Parse smack rules in below extended regex format:
+ * "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*$"
+ * Where Subject/Object are: "^[^/[:space:][:cntrl:]]{1,SMK_MAXLEN}$"
+ *
+ * Handle defragmented rules over several write calls using the
+ * load_state structure.
*/
static ssize_t smk_write_load(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
- struct smack_rule rule;
- ssize_t rc = count;
+ struct smack_rule *rule = _state->rule;
Re: [GIT PULL] x86 setup: correct booting on 486DX4
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Linus Torvalds wrote: >> >> And Linux always did it correctly. I don't understand why you disagree, and >> why Jeremy says >> >> "Having successfully broken the rules for a long time so far,maybe >> we can get away with still cutting corners..." >> >> when the fact is, we used to *not* cut corners, we used to *not* break the >> rules, and what we used to do (a short jump immediately after setting PE) was >> exactly what Intel always said you should do, and there is no question >> what-so-ever about it. >> > > Apparently because the Intel documentation disagrees with itself. That's all. Yes. Let's go back to the tested version with the short jump, that looks safest as it is what we have always done, and we certainly need some kind of jump in there. I do seem to recall etherboot having a far jump in that spot and it working on everything from a 386 on up. So I'm not certain if the kind of jump matters. Still the kernel has a lot more exposure. At the same time it does look like we really do enter protected mode with a valid gdt after the short jump so doing the segments loads as I did originally in 32bit mode looks like it was excessively conservative. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: b43 on HP nx6325 w/ openSUSE 10.3 (x86_64)
Rafael J. Wysocki wrote: > Hi, > > I'm trying to make the b43 driver work on an HP nx6325 with openSUSE 10.3 > (64-bit). In short, it sort of works, but some things are a bit ugly. > > The kernel is the current -git (approx. 2.6.24-rc1-git13) with the following > extra patches applied: > > b43: Fix rfkill callback deadlock > b43: debugfs SHM read buffer overrun fix > b43: Rewrite and fix rfkill init > > and I'm using the firmware from > http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 > > Here's the debug info from dmesg: > > b43-phy1: Broadcom 4311 WLAN found > b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 > b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 > b43-phy1 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) > Registered led device: b43-phy1:tx > Registered led device: b43-phy1:rx > b43-phy1 debug: Chip initialized > b43-phy1 debug: 32-bit DMA initialized > b43-phy1 debug: Wireless interface started > b43-phy1 debug: Adding Interface type 2 > > Now, the first problem is that the card seems to lose frames from time to > time. This is visible in the output of mtr and while trying to transfer large > files using scp. With scp the transfer just stalls and stays this way > although > the other end is pingable etc. (eg. attempting to transfer more than 400 MB at > once triggers this 100% of the time). > > If you can suggest some more specific tests to me, I'll run them and report > back. > > The second problem is that YaST is apparently unable to detect the device, > which sort of sucks, because it leads to configuration problems (basically, > you > need to set up everything manually). Evidently, udev manages to handle it, so > this may be related to HAL. Anyway, it looks like the problem is related to > the fact that the device is not present under /sys/bus/pci/devices/ directly, > but you need to go through the ssb0:0 subdirectory to get to it. > > Do you have any ideas how to tell the user space stuff where the devices is > in sysfs? Your configuration is exactly like mine - openSUSE 10.3, x86_64 with Linus's latest git, and a 4311. I have not used mtr or scp and cannot comment on your transfer problems. I have had 0 problems configuring the device with YaST. On the x86_64 laptop, I let NetworkManager control the wireless connection, but I have also used the traditional ifup/ifdown method. On an i386 system, I use ifup/ifdown as I don't run X on that machine. Both make fast connections. Larry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix i486 boot failure due to stale %ds
On Sun, 4 Nov 2007, Linus Torvalds wrote: > > So I'd suggest having both jumps back-to-back, but realistically, the > first regular short jump is actually the one that is more important. > That's the one that really matters on i386/i486 class machines, and later > CPU's will generally do the right thing even with _neither_ jump there. That's obviously badly phrased. The far jump is obviously required on all CPU's in order for us to actually finally get to 32-bit protected mode and reload CS, but what I *meant* was that we certainly also know that "unreal mode" works and is used by various strange DOS extenders, and that not doing the far jump isn't really required for having a "working setup" - it's just going to be a rather limited mode. So the short jump is required for the code to *work*. The long jump is required only to get us the 32-bit mode we *want* and out of the odd "half-way" state. Two different issues. 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] fix i486 boot failure due to stale %ds
On Sun, 4 Nov 2007, H. Peter Anvin wrote: > > Joy. Apparently the Intel documentation is actually self-inconsistent. > Section 9.9.1, page 9-17 does indeed have the "far jump or call" injunction, > whereas the sample code in section 9.10.1, page 9-27, line 180 does a near > jump! See the older code. There's literally two different issues: - flushing the pipeline. Using a regular short jump is not only sufficient, but is a good idea because the byte sequence has no dependency on any modes, so it is guaranteed to flush any pipeline without itself having any behavioural differences. This part is a no-op for later CPU's: they simply won't care, since they serialize the pipeline on their own (and the have to, since a correctly predicted branch no longer flushes it anyway). So this is purely a i386/i486 thing (and *maybe* Pentium, but definitely not PPro and later) - setting up the proper protected mode bits in CS. This obviously changes the CS itself, and anything that depends on any shadow state in CS will need this to happen first. In practice, very few things really depend on the CS bits, of course. Doing them back-to-back is obviously the best situation, and leaves the minimum footprint for any dubious undocumented behaviour. That said, while the whole thing with shadow segment table is strictly speaking probably "undocumented" behaviour, it's certainly a reality, and lots of code has depended on the fact that even though you haven't reloaded a segment, the segment continues to work across mode switches thanks to the shadow table. So it's not like there's any real secret to what happens until the longjump has been executed: we continue running with the CS shadow table entry being in "real mode", and the effect of that tends to be minimal. But in theory, the CS table entry could affect how instructions actually act, even though in practice I don't think it really has any real effect outside of the actual segment access check (and certainly did not in the i386/i486 timeframe). So I'd suggest having both jumps back-to-back, but realistically, the first regular short jump is actually the one that is more important. That's the one that really matters on i386/i486 class machines, and later CPU's will generally do the right thing even with _neither_ jump there. 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: [GIT PULL] x86 setup: correct booting on 486DX4
H. Peter Anvin wrote: Apparently because the Intel documentation disagrees with itself. That's all. Just to be perfectly clear: I much prefer the code with the short (near) jump, because it keeps the code cleaner. I have sent a patch to Mikael to test out. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 setup: correct booting on 486DX4
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Hi Linus; please pull: > > git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git > for-linus > > H. Peter Anvin (1): > x86 setup: correct booting on 486DX4 > > arch/x86/boot/pmjump.S | 32 +--- > 1 files changed, 21 insertions(+), 11 deletions(-) > > [Full diff and log follows] Looks reasonable to me. > commit ac3b37b78c5f0f0be0b476a35370650f7bad482f > Author: H. Peter Anvin <[EMAIL PROTECTED]> > Date: Sun Nov 4 14:33:41 2007 -0800 > > x86 setup: correct booting on 486DX4 > > Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so > we really do need the far jump immediately afterwards. This means > losing the nice separation between 16- and 32-bit code, but c'est la > vie. > > Also pass %ebx = %edi = %ebp = 0 to support future extension of the > 32-bit boot protocol. > > Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> > > diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S > index 2e55923..17e6dec 100644 > --- a/arch/x86/boot/pmjump.S > +++ b/arch/x86/boot/pmjump.S > @@ -28,27 +28,37 @@ > * void protected_mode_jump(u32 entrypoint, u32 bootparams); > */ > protected_mode_jump: > - xorl%ebx, %ebx # Flag to indicate this is a boot > movl%edx, %esi # Pointer to boot_params table > - movl%eax, 2f# Patch ljmpl instruction > + > + xorl%edx, %edx > + movw%cs, %dx > + shll$4, %edx# Patch ljmpl instruction > + addl%edx, 2f > jmp 1f # Short jump to flush instruction q. > > 1: > movw$__BOOT_DS, %cx > + xorl%ebx, %ebx # Per protocol > + xorl%ebp, %ebp # Per protocol > + xorl%edi, %edi # Per protocol > > movl%cr0, %edx > orb $1, %dl # Protected mode (PE) bit > movl%edx, %cr0 > + > + .byte 0x66, 0xea # ljmpl opcode > +2: .long 3f # Offset > + .word __BOOT_CS # Segment > > - movw%cx, %ds > - movw%cx, %es > - movw%cx, %fs > - movw%cx, %gs > - movw%cx, %ss > + .code32 > +3: > + movl%ecx, %ds > + movl%ecx, %es > + movl%ecx, %fs > + movl%ecx, %gs > + movl%ecx, %ss > > # Jump to the 32-bit entrypoint > - .byte 0x66, 0xea # ljmpl opcode > -2: .long 0 # offset > - .word __BOOT_CS # segment > - > + jmpl*%eax > + > .size protected_mode_jump, .-protected_mode_jump - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: "Fix ATAPI transfer lengths" causes CD writing regression
Tejun Heo wrote:
However, there's still remaining issues. What does happen if you raise
allocation length and buffersize of the test program to 16? ie. Change
0x0a in cmd[] to 0x10 and increase buffer[10] to buffer[16].
Eek. The process hangs in D state for a good 60 seconds or so.
Caught a trace with sysrq.
<6>a.out D 00200202 0 7015 3217
<4> b801fc7c 00200082 b029d5cb 00200202 b04a4c00 b04a4c00 b046ee58
b0472040
<4> b24fa000 b24fa140 b17fc040 b264e000 b801fb80 b264e000
b01f266c
<4> b278f800 00200202 b0285eb7 7fff 7fff b801fc7c b801fc7c
b035327c
<4>Call Trace:
<4> [] ata_scsi_translate+0xd7/0x105
<4> [] elv_next_request+0xe3/0xf2
<4> [] scsi_dispatch_cmd+0x172/0x1aa
<4> [] schedule_timeout+0x13/0x8d
<4> [] del_timer+0x48/0x4e
<4> [] wait_for_common+0xb2/0x118
<4> [] default_wake_function+0x0/0x8
<4> [] blk_execute_rq+0xa6/0xbc
<4> [] blk_end_sync_rq+0x0/0x23
<4> [] bio_add_pc_page+0x23/0x28
<4> [] bio_copy_user+0x116/0x221
<4> [] bio_phys_segments+0xe/0x14
<4> [] blk_rq_bio_prep+0x28/0xa4
<4> [] blk_rq_append_bio+0x11/0x3a
<4> [] blk_rq_map_user+0xfc/0x17f
<4> [] sg_io+0x20e/0x2f0
<4> [] scsi_cmd_ioctl+0x1b3/0x34b
When it unhung, this appeared in the logs
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/01:00:00:10:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 16 in
res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata2.00: status: { DRDY }
ata2: port is slow to respond, please be patient (Status 0xd0)
ata2: device not ready (errno=-16), forcing hardreset
ata2: soft resetting link
ata2.00: configured for UDMA/33
ata2: EH complete
And the app itself outputted:
result 0
check sense data:
72 0b 00 00 00 00 00 0e 09 0c 00 00 00 03 00 00 00 00 00
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86 setup: correct booting on 486DX4
Linus Torvalds wrote: And Linux always did it correctly. I don't understand why you disagree, and why Jeremy says "Having successfully broken the rules for a long time so far, maybe we can get away with still cutting corners..." when the fact is, we used to *not* cut corners, we used to *not* break the rules, and what we used to do (a short jump immediately after setting PE) was exactly what Intel always said you should do, and there is no question what-so-ever about it. Apparently because the Intel documentation disagrees with itself. That's all. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Fix ATAPI transfer lengths" causes CD writing regression
Alan Cox wrote: >> Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and >> exceeds the limit, we consider it as HSM violation and have EH handle it. > > On a DMA transfer its basically out of our control (and a PIO drain will > lock some controllers solid until power cycle), Do such controllers lock up on PIO draining after PIO transfers too? Can you tell which are those controllers? > but on PIO we know we > never set a chunk size over 64K, so if we exceed 64K its time to apply a > larger hammer Draining is related to the amount of data the drive responds not to the chunk size. I agree 64k should be enough for most cases but I think there can be corner cases where this doesn't hold. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1: OOPS at acpi_battery_update
On Monday, 5 of November 2007, Michael (rabenkind) Brandstetter wrote: > Am Sonntag, 4. November 2007 14:17:23 schrieben Sie: > > On Sunday, 4 of November 2007, Romano Giannetti wrote: > > > On Fri, 2007-11-02 at 17:08 +0100, Rafael J. Wysocki wrote: > > > > On Friday, 2 November 2007 00:14, Andrew Morton wrote: > > > > > On Mon, 29 Oct 2007 11:11:04 +0100 > > Hello! > > > > [OOPS removed] > > > > > > > > Did any earlier kernels do this? In other words, do you believe that > > > > > this is a bug which we added after 2.6.23 was released? > > Yes the kernels prior to 2.6.24-rc1 did not have this bug. > > The oops always appear when i plug in or remove the battery. > > > > Never noticed it before. But it's happening just sometime (I've had it > > > just two times), so I cannot be sure. > > > > > > > This might be the same as > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9283 > > > > > > Hmmm... there is too little info for my level in that bug report to > > > understand if it's the same. > > > > Then, please apply the patch from > > > > http://bugzilla.kernel.org/attachment.cgi?id=13376=view > > > > and see if the problem goes away. > > The bug went away on my Dell Latitude C610. I applied the patch on two boxes > (2.6.24-rc1-git12) and the haldaemon is not killed and no oops when i remove > the battery or plug it in. > > But on the Portege 3110CT the bug remains. Well, please create a bug report at http://bugzilla.kernel.org regarding this bug and place all of the relevant information in there (including what boxes are fixed by the above patch etc.) Also please add my address to the report's CC list. Thanks, 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/
Re: [GIT PULL] x86 setup: correct booting on 486DX4
On Sun, 4 Nov 2007, H. Peter Anvin wrote: > > It's not an instruction-decoding issue at all (that's a 16- vs 32-bit issue, > which can only be changed by a ljmp). Apparently the 486DX4 mis-executes the > load to segment register, which is an EU function in that context. (And yes, > it's sort-of-documented behaviour in the sense that the documentation says "do > things this way", but the Intel docs are unfortunately full of "do things this > way" which don't make sense and occasionally are actively harmful, too.) I still disagree. I took out "Programming the 80386" just to check, and the documentation very clearly states that when changing the CR0 bits (I quote): "The program must execute a jump instruction immediately after changing the value of the PE bit in order to flush the execution pipeline of any instructions that may have been fetched in the wrong mode. [...]" In other words, not only is this documented since day 1, it makes total sense, and they even said exactöy *why* that jump had to be done. In fact, there's even a code example. It's page 624 in my copy of the book, and yes, it has a short jump to flush things, followed by a long jump. The code there looks like this: ; * ; ** [4] Enter Protected Mode ; * SMSW AX OR AX, PE LMSW AX JMP Flush Flush: JMP far ptr Start32 which is pretty damn conclusive. It's documented, it has examples, it works. In other words, it's how you should do things. And Linux always did it correctly. I don't understand why you disagree, and why Jeremy says "Having successfully broken the rules for a long time so far, maybe we can get away with still cutting corners..." when the fact is, we used to *not* cut corners, we used to *not* break the rules, and what we used to do (a short jump immediately after setting PE) was exactly what Intel always said you should do, and there is no question what-so-ever about it. So here's a suggestion: - make the code do what it used to do. A regular jump to flush the pipeline. Which is what Intel has always said should be done. and I really don't see that there is any argument about this. 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/
b43 on HP nx6325 w/ openSUSE 10.3 (x86_64)
Hi, I'm trying to make the b43 driver work on an HP nx6325 with openSUSE 10.3 (64-bit). In short, it sort of works, but some things are a bit ugly. The kernel is the current -git (approx. 2.6.24-rc1-git13) with the following extra patches applied: b43: Fix rfkill callback deadlock b43: debugfs SHM read buffer overrun fix b43: Rewrite and fix rfkill init and I'm using the firmware from http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 Here's the debug info from dmesg: b43-phy1: Broadcom 4311 WLAN found b43-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 b43-phy1 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) Registered led device: b43-phy1:tx Registered led device: b43-phy1:rx b43-phy1 debug: Chip initialized b43-phy1 debug: 32-bit DMA initialized b43-phy1 debug: Wireless interface started b43-phy1 debug: Adding Interface type 2 Now, the first problem is that the card seems to lose frames from time to time. This is visible in the output of mtr and while trying to transfer large files using scp. With scp the transfer just stalls and stays this way although the other end is pingable etc. (eg. attempting to transfer more than 400 MB at once triggers this 100% of the time). If you can suggest some more specific tests to me, I'll run them and report back. The second problem is that YaST is apparently unable to detect the device, which sort of sucks, because it leads to configuration problems (basically, you need to set up everything manually). Evidently, udev manages to handle it, so this may be related to HAL. Anyway, it looks like the problem is related to the fact that the device is not present under /sys/bus/pci/devices/ directly, but you need to go through the ssb0:0 subdirectory to get to it. Do you have any ideas how to tell the user space stuff where the devices is in sysfs? 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/
Re: [PATCH] fix i486 boot failure due to stale %ds
Mikael, can you try this patch (rev 3) on your 486? -hpa diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S index 2e55923..d93a0c2 100644 --- a/arch/x86/boot/pmjump.S +++ b/arch/x86/boot/pmjump.S @@ -28,17 +28,21 @@ * void protected_mode_jump(u32 entrypoint, u32 bootparams); */ protected_mode_jump: - xorl%ebx, %ebx # Flag to indicate this is a boot movl%edx, %esi # Pointer to boot_params table - movl%eax, 2f# Patch ljmpl instruction + movl%eax, 3f# Patch ljmpl instruction jmp 1f # Short jump to flush instruction q. - 1: + movw$__BOOT_DS, %cx + xorl%ebx, %ebx # Per protocol + xorl%ebp, %ebp # Per protocol + xorl%edi, %edi # Per protocol movl%cr0, %edx orb $1, %dl # Protected mode (PE) bit movl%edx, %cr0 + jmp 2f # Short jump to serialize +2: movw%cx, %ds movw%cx, %es @@ -48,7 +52,7 @@ protected_mode_jump: # Jump to the 32-bit entrypoint .byte 0x66, 0xea # ljmpl opcode -2: .long 0 # offset +3: .long 0 # offset .word __BOOT_CS # segment .size protected_mode_jump, .-protected_mode_jump
Re: [PATCH] fix i486 boot failure due to stale %ds
Jeremy Fitzhardinge wrote: Maybe not. I had a look in Intel's SDM Vol3, and the section "switching to protected mode" specifies that a move to %cr0 that sets PE should immediately be followed by a far jmp or call. Yes, that's what the spec says. I queried this a few months ago, but hpa used his convincing voice and said that in practice it isn't necessary; there are no known cpus which need this, and any that do would cause other things to break. But I guess now we have the counter-example... Joy. Apparently the Intel documentation is actually self-inconsistent. Section 9.9.1, page 9-17 does indeed have the "far jump or call" injunction, whereas the sample code in section 9.10.1, page 9-27, line 180 does a near jump! -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: duplicated include files
On Sun, 2007-11-04 at 14:49 -0500, Robert P. J. Day wrote: [...] > actually, one wonders if there's any value in keeping any references > to other version control systems such as subversion, SCCS, CVS, > mercurial, etc. Lots of people have their working trees in CVS, Subversion, So it probably annoys them and doesn't really buy anything IMHO. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: "Fix ATAPI transfer lengths" causes CD writing regression
> Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and > exceeds the limit, we consider it as HSM violation and have EH handle it. On a DMA transfer its basically out of our control (and a PIO drain will lock some controllers solid until power cycle), but on PIO we know we never set a chunk size over 64K, so if we exceed 64K its time to apply a larger hammer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Prism54: Convert mgmt_sem to the mutex API
On Thursday 01 November 2007 08:19:02 Matthias Kaehlcke wrote:
> Prism54: Convert mgmt_sem to the mutex API
>
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
>
> --
>
> diff --git a/drivers/net/wireless/prism54/islpci_dev.c
> b/drivers/net/wireless/prism54/islpci_dev.c
> index 219dd65..dbb538c 100644
> --- a/drivers/net/wireless/prism54/islpci_dev.c
> +++ b/drivers/net/wireless/prism54/islpci_dev.c
> @@ -861,7 +861,7 @@ islpci_setup(struct pci_dev *pdev)
> init_waitqueue_head(>reset_done);
>
> /* init the queue read locks, process wait counter */
> - sema_init(>mgmt_sem, 1);
> + mutex_init(>mgmt_lock);
> priv->mgmt_received = NULL;
> init_waitqueue_head(>mgmt_wqueue);
> sema_init(>stats_sem, 1);
> diff --git a/drivers/net/wireless/prism54/islpci_dev.h
> b/drivers/net/wireless/prism54/islpci_dev.h
> index 73d..4e0182c 100644
> --- a/drivers/net/wireless/prism54/islpci_dev.h
> +++ b/drivers/net/wireless/prism54/islpci_dev.h
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include "isl_38xx.h"
> #include "isl_oid.h"
> @@ -164,7 +165,7 @@ typedef struct {
> wait_queue_head_t reset_done;
>
> /* used by islpci_mgt_transaction */
> - struct semaphore mgmt_sem; /* serialize access to mailbox and wqueue */
> + struct mutex mgmt_lock; /* serialize access to mailbox and wqueue */
> struct islpci_mgmtframe *mgmt_received; /* mbox for incoming frame */
> wait_queue_head_t mgmt_wqueue;/* waitqueue for mbox */
>
Uhm, so this mutex is not used? Why not remove it then?
--
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: [GIT PULL] x86 setup: correct booting on 486DX4
Linus Torvalds wrote: On Sun, 4 Nov 2007, Linus Torvalds wrote: I'm not entirely sure that it needs to be a long-jump, btw. I think any regular branch is sufficient. You obviously *do* need to make the long jump later (to reload %cs in protected mode), but I'm not sure it's needed in that place. I forget the exact rules (but they definitely were documented). Hmm. The original Linux code did movw$1, %ax lmsw%ax jmp flush_instr flush_instr: and I think that was straigh out of the documentation. So yeah, I think that's the right fix - not a longjmp (which in itself is dangerous: it potentially behaves *differently* on different CPU's, since some CPU's may do the long jump with pre-protected-mode semantics, while others will do it with protected mode already in effect!) Just looked it up; it was a bit hard to find (it is Intel vol 3 page 9-27, at least in the version I have), but you're right -- the documentation only demands a short jump here, not a long jmp (which actually makes sense given what I remembered that a long jump should be deferrable here.) So yes, that is definitely the right fix and avoids the ugly mixing of code. I'll update the patch. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1: OOPS at acpi_battery_update
Am Sonntag, 4. November 2007 14:17:23 schrieben Sie: > On Sunday, 4 of November 2007, Romano Giannetti wrote: > > On Fri, 2007-11-02 at 17:08 +0100, Rafael J. Wysocki wrote: > > > On Friday, 2 November 2007 00:14, Andrew Morton wrote: > > > > On Mon, 29 Oct 2007 11:11:04 +0100 Hello! > > [OOPS removed] > > > > > > Did any earlier kernels do this? In other words, do you believe that > > > > this is a bug which we added after 2.6.23 was released? Yes the kernels prior to 2.6.24-rc1 did not have this bug. The oops always appear when i plug in or remove the battery. > > Never noticed it before. But it's happening just sometime (I've had it > > just two times), so I cannot be sure. > > > > > This might be the same as > > > http://bugzilla.kernel.org/show_bug.cgi?id=9283 > > > > Hmmm... there is too little info for my level in that bug report to > > understand if it's the same. > > Then, please apply the patch from > > http://bugzilla.kernel.org/attachment.cgi?id=13376=view > > and see if the problem goes away. The bug went away on my Dell Latitude C610. I applied the patch on two boxes (2.6.24-rc1-git12) and the haldaemon is not killed and no oops when i remove the battery or plug it in. But on the Portege 3110CT the bug remains. greetz Michael :)) -- Duisburger Linux User Group Free Software Foundation Europe /"\ASCII Ribbon Campaign \ /No HTML/RTF in email x No Word docs in email / \Respect for open standards - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86 setup: correct booting on 486DX4
Linus Torvalds wrote: On Sun, 4 Nov 2007, H. Peter Anvin wrote: Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so we really do need the far jump immediately afterwards. Hmm. I'm not sure I agree with the commit message. This is documented behaviour on i386 and i486: instruction decoding is decoupled from execution, so things that change processor mode have to do a jump to make sure that %cr0 changes take effect. It's not an instruction-decoding issue at all (that's a 16- vs 32-bit issue, which can only be changed by a ljmp). Apparently the 486DX4 mis-executes the load to segment register, which is an EU function in that context. (And yes, it's sort-of-documented behaviour in the sense that the documentation says "do things this way", but the Intel docs are unfortunately full of "do things this way" which don't make sense and occasionally are actively harmful, too.) I'm not entirely sure that it needs to be a long-jump, btw. I think any regular branch is sufficient. You obviously *do* need to make the long jump later (to reload %cs in protected mode), but I'm not sure it's needed in that place. I forget the exact rules (but they definitely were documented). That's exactly the issue here. The code without this patch deferred the long jump until after the segment loads, this worked on all processors except, apparently, the 486DX4. Hence, move the ljmp up to the earliest possible location. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 setup: correct booting on 486DX4
Linus Torvalds wrote: > I'm not entirely sure that it needs to be a long-jump, btw. I think any > regular branch is sufficient. You obviously *do* need to make the long > jump later (to reload %cs in protected mode), but I'm not sure it's needed > in that place. I forget the exact rules (but they definitely were > documented). Yes, it says it needs to be a far jmp or call (and if you enabled paging in the cr0 load, you need to identity-map the branch target). Having successfully broken the rules for a long time so far, maybe we can get away with still cutting corners... but it doesn't seem particularly worthwhile since we've been caught once. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PID namespaces break initrd+hibernate combination?
On Sunday, 4 of November 2007, Nigel Cunningham wrote: > Hi all. > > Please excuse me if this has already been answered. I'm not currently > subscribed to LKML. > > I've just been preparing a new tux-on-ice release against Linus' current > tree, and encountered a failure to freeze pid 1 when seeking to resume, using > an initrd: > > [ 74.192734] Freezing of tasks failed after 19.99 seconds (1 tasks refusing > to freeze): > [ 74.193502] taskPC stack pid father > [ 74.193504] swapper S 810002023030 4968 1 0 > [ 74.193512] 81000203fdb0 0046 810002023040 > 810003249140 > [ 74.194296] 81000203fd80 803150a1 81000203fdb0 > 810002023180 > [ 74.195087] 810002023030 0004 0001 > 0001 > [ 74.195860] Call Trace: > [ 74.196123] [] security_task_wait+0x11/0x20 > [ 74.196692] [] do_wait+0x51d/0xda0 > [ 74.197187] [] default_wake_function+0x0/0x10 > [ 74.197772] [] sys_wait4+0x2c/0x30 > [ 74.198264] [] initrd_load+0x175/0x370 > [ 74.198794] [] prepare_namespace+0x8f/0x1d0 > [ 74.199362] [] kernel_init+0x1ad/0x2b0 > [ 74.199889] [] _spin_unlock_irq+0x26/0x60 > [ 74.200439] [] finish_task_switch+0x67/0xc0 > [ 74.201008] [] child_rip+0xa/0x12 > [ 74.201494] [] acpi_os_acquire_lock+0x9/0xb > [ 74.202063] [] kernel_init+0x0/0x2b0 > [ 74.202570] [] child_rip+0x0/0x12 > > I believe it might be related to pid namespaces, but am not completely sure > yet (will do a git bisect if needs be). > > So, then, I'm writing to ask: Is this a known issue? Is there any fix already > available that I've not found in my googling? Not known to me and I haven't tried the PID namespaces yet. 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/
Re: [GIT PULL] x86 setup: correct booting on 486DX4
On Sun, 4 Nov 2007, Linus Torvalds wrote: > > I'm not entirely sure that it needs to be a long-jump, btw. I think any > regular branch is sufficient. You obviously *do* need to make the long > jump later (to reload %cs in protected mode), but I'm not sure it's needed > in that place. I forget the exact rules (but they definitely were > documented). Hmm. The original Linux code did movw$1, %ax lmsw%ax jmp flush_instr flush_instr: and I think that was straigh out of the documentation. So yeah, I think that's the right fix - not a longjmp (which in itself is dangerous: it potentially behaves *differently* on different CPU's, since some CPU's may do the long jump with pre-protected-mode semantics, while others will do it with protected mode already in effect!) 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/
[to-be-posted-soon] Multiple handlers per marker
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: > * Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: > > * Mike Mason ([EMAIL PROTECTED]) wrote: > > > Hi Mathieu, > > > > > > Are you aware of any working being done to allow multiple handlers to be > > > attached to a marker? Something like what kprobes allows. I've started > > > to > > > look into this and don't want to duplicate efforts. > > > > > > > Nope, but I know we will have to address this. > > > > Something along the lines of walking an RCU list of function pointers, > > calling them. > > > > The only downside I see is that we will have to pass a va_list * instead > > of real va args. The could make the marker site a little bit bigger and > > will change the probe callback arguments. > > > > What do you think about these ideas ? > > > > If we can find a way to make the common case (only one probe connected) > > _ultra_ fast, and yet architecture independent, that would be awesome. A > > simple call is kind of hard to beat though.. So we may have to think > > about a design with : > > > > - One call at the marker site > > - if 1 probe is installed : > > - If the format string is empty, connect a probe without va args. > > - If the format string is not empty, connect a "stage 1" probe that takes > > the va args, starts/ends the va_list and calls _one_ function (let's > > call it "stage 2" probe), that takes va_list as parameter. > > - if more than 1 probe is installed : > > - The stage 1 probe creates the va_list and passes it to each function > > connected, iterated with an RCU list. > > > > What do you think ? > > > > Mathieu > > > > I'm working on an implementation. > It's ready for testing. Please grab http://ltt.polymtl.ca/lttng/patch-2.6.24-rc1-git13-lttng-0.10-pre18.tar.bz2 patch name : markers-support-multiple-probes.patch It still need to go through patchcheck.pl and some polishing, but it seems to work fine for me with multiple probes (the sample marker, sample probe and multiple instances of my lttng probes can connect/disconnect without problem). Currently, the "connect/disconnect" and "arm/disarm" operations are separate. However, they could be merged. Any comment/preference on this? Being separate, a probe provider can wait until the very last moment before it activates its markers, with a minimalistic impact on the system, but it is not such a strong argument. Mathieu -- 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: duplicated include files
Robert P. J. Day wrote: > actually, one wonders if there's any value in keeping any references > to other version control systems such as subversion, SCCS, CVS, > mercurial, etc. > What do you mean by "other"? git doesn't have a monopoly, and the kernel should support people using a reasonable set of version control systems. Supporting VSS would be strange, but nothing wrong with the set you listed, if people find those systems useful. It's not like it amounts to a huge amount of effort to do so. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Opteron box and 4Gb memory
On Thu, 25 Oct 2007 14:58:10 -0700, "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > J.A. Magallon wrote: > > Hi... > > > > I have some Quad-Opteron boxes with 4Gb memory and two of them are > > running two different Linux distros. > > > > Box one sees 4Gb of memory, but box two just sees 3. > > Their mtrr setups are different: > > > > Why ? Is it a bios setup problem ? A kernel problem ? > > grep HIGHMEN in configs for both kernels does not give anything, so > > I still understand less this thing... > > > > It would depend on how the BIOS programmed the memory controllers. For > 32-bit (and lots of device) compatibility, a memory hole is required > below 4 GB. Not all memory controllers can remap memory in the 3-4 GB > range above the 4 GB memory; I'm not sure if that varies with the > different Opteron processors. > Well, I was able to get about 3 Gb with MTRR=discrete in the BIOS, but I'm still in the process to find the 'software hole' option to get the rest of the 4Gb... But now another (perhaps related) question has arised... I like all those 5-line progams to test system performance...;). I just wrote a simple program that sums/muls int/float vectors with scalar/sse operations. And my opteron box looks terribly slow. This is my MacPro, Xeon 5130: belly:~/bn> bn proc: 4 x MacPro1,1 @ 2000 MHz ram: 2048 Mb os: unx, Darwin, 9.0.0 cc: gcc-4.0.1 vector size : 8 x 1024 x 1024 allocation: 0.01 ms int scl add: .. 36.78 ms, 228.07 Mips | 114.03 Mips /GHz int scl mul: .. 34.30 ms, 244.60 Mips | 122.30 Mips /GHz flt scl add: .. 34.28 ms, 244.73 Mflops | 122.37 Mflops/GHz flt vec add: ..7.89 ms, 1063.15 Mflops | 531.58 Mflops/GHz flt scl mul: .. 34.20 ms, 245.28 Mflops | 122.64 Mflops/GHz flt vec mul: ..7.90 ms, 1061.77 Mflops | 530.89 Mflops/GHz total: 3322.19 ms This is a normal (I think) opteron box (Opteron 846): selene:~/bn> g proc: 4 x x86_64 @ 2004 MHz ram: 3496 Mb os: unx, Linux, 2.6.9-42.0.10.ELsmp cc: gcc-4.0.2 vector size : 8 x 1024 x 1024 allocation: 0.05 ms int scl add: .. 45.98 ms, 182.42 Mips | 91.03 Mips /GHz int scl mul: .. 44.31 ms, 189.30 Mips | 94.46 Mips /GHz flt scl add: .. 44.52 ms, 188.41 Mflops | 94.02 Mflops/GHz flt vec add: .. 10.03 ms, 836.70 Mflops | 417.52 Mflops/GHz flt scl mul: .. 43.32 ms, 193.63 Mflops | 96.62 Mflops/GHz flt vec mul: .. 10.02 ms, 836.98 Mflops | 417.65 Mflops/GHz total: 4705.07 ms And this is my opteron (Opteron 275) cicely:~/bn> g proc: 4 x x86_64 @ 2200 MHz ram: 2914 Mb os: unx, Linux, 2.6.23.1-desktop-1mdv cc: gcc-4.0.2 vector size : 8 x 1024 x 1024 allocation: 0.03 ms int scl add: .. 87.67 ms, 95.68 Mips | 43.49 Mips /GHz int scl mul: .. 85.48 ms, 98.13 Mips | 44.61 Mips /GHz flt scl add: .. 85.90 ms, 97.66 Mflops | 44.39 Mflops/GHz flt vec add: .. 19.51 ms, 429.96 Mflops | 195.44 Mflops/GHz flt scl mul: .. 85.86 ms, 97.70 Mflops | 44.41 Mflops/GHz flt vec mul: .. 19.50 ms, 430.11 Mflops | 195.50 Mflops/GHz total: 6334.96 ms As I read in AMD site, the only difference that matters in models is the xx5 vx xx6, related to fequency, but the processors should be just the same. As this only does intensive memory/fp operations, I'm not going to blame gcc nor kernel versions here (I have compared gcc 3.4, 4.0, 4.1, and 4.2 on one of the boxes and results are very similar, the code is really stupid and not very suitable for compiler smartness...). I suspect it is a memory problem. It can be hardware or caused by incorrect BIOS/kernel-mtrr setup: selene:~> cat /proc/mtrr reg00: base=0x ( 0MB), size=16384MB: write-back, count=1 reg01: base=0xf000 (3840MB), size= 256MB: uncachable, count=1 cicely:~> cat /proc/mtrr reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size= 512MB: write-back, count=1 reg02: base=0xa000 (2560MB), size= 256MB: write-back, count=1 reg03: base=0xb000 (2816MB), size= 128MB: write-back, count=1 reg04: base=0xb800 (2944MB), size= 16MB: write-back, count=1 Any idea on what can be going on here ? I have asked the 'good opteron' admin info about the mobo an memory of the box. Any help will be _very_ appreciated. TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo
Re: [GIT PULL] x86 setup: correct booting on 486DX4
On Sun, 4 Nov 2007, H. Peter Anvin wrote: > > Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so > we really do need the far jump immediately afterwards. Hmm. I'm not sure I agree with the commit message. This is documented behaviour on i386 and i486: instruction decoding is decoupled from execution, so things that change processor mode have to do a jump to make sure that %cr0 changes take effect. I'm not entirely sure that it needs to be a long-jump, btw. I think any regular branch is sufficient. You obviously *do* need to make the long jump later (to reload %cs in protected mode), but I'm not sure it's needed in that place. I forget the exact rules (but they definitely were documented). 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] fix i486 boot failure due to stale %ds
Jeremy Fitzhardinge wrote: Yes, that's what the spec says. I queried this a few months ago, but hpa used his convincing voice and said that in practice it isn't necessary; there are no known cpus which need this, and any that do would cause other things to break. But I guess now we have the counter-example... Yup. I owe you a beverage :) -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix i486 boot failure due to stale %ds
Mikael Pettersson wrote: > On Sun, 04 Nov 2007 11:41:58 -0800, H. Peter Anvin wrote: > >> Mikael Pettersson wrote: >> >>> First patch didn't build. Second patch builds and boots Ok. >>> >>> So this means the 486 DX4 has a buggy mov to %cr0? >>> >>> >> Apparently. >> > > Maybe not. I had a look in Intel's SDM Vol3, and the > section "switching to protected mode" specifies that > a move to %cr0 that sets PE should immediately be > followed by a far jmp or call. > Yes, that's what the spec says. I queried this a few months ago, but hpa used his convincing voice and said that in practice it isn't necessary; there are no known cpus which need this, and any that do would cause other things to break. But I guess now we have the counter-example... J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Quad core CPU detected but shows as single core in 2.6.23.1
> Would it not be as simple as looking at the BIOS provided topology > information? If nr sockets > 4 assume multiple board. There is no reason multiple two socket boards couldn't be connected with HT cables to form a larger system. Then you might end up with a 4 socket system with multiple oscillators. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix i486 boot failure due to stale %ds
Mikael Pettersson <[EMAIL PROTECTED]> writes: > Maybe not. I had a look in Intel's SDM Vol3, and the > section "switching to protected mode" specifies that > a move to %cr0 that sets PE should immediately be > followed by a far jmp or call. They write that "random > failures can occur if other instructions exist between > [the move to %cr0] and [the far jmp/call]". The current > version of pmjump.S does exactly that: it executes > a bunch of moves to segment registers in that window. iirc various Intel VT hypervisor implementations also have trouble with not following this restriction. At least in the early Xen days it was a frequent reason for boot failure. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Andreas Mohr <[EMAIL PROTECTED]> writes: > EEPROM dump (VT6306) > 00: 00 11 06 66 45 55 56 E1 04 04 32 55 F8 00 A2 02 - GUID > 10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73 - subs ID - > 20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF > > Your VT6307 chip is in OHCI 1.0 mode Thanks for the data. It's the same as for all my VT6307, excluding GUID (different for every card) and PCI subsystem vendor/device IDs. I guess Stefan could now try to write these values (except GUID and probably PCI subsystem IDs, and with OHCI 1.1 bit) to the "bad" card :-) I wouldn't try with a good card yet, though (unless you know how to repair it and/or you want to risk it, and/or you want to use the DOS utility mentioned by Stefan). I would try myself but I have no VT6306. BTW I don't know where I found the info about VT6306 not working with I^2C EEPROMs but it seems to be false, the datasheets claim both chips can get startup info from 4-wire or I^2C EEPROM. Given that both chips have identical EEPROM interface (except "fast I^2C mode" which means nothing) I'd be surprised if the program can't set OHCI 1.1 on VT6306. > And viewing from a quite problematic angle (card is in running PC, > difficult to view) strongly seems to indicate a VT630_6_ (the "6" is > quite clearly visible). > This means that I currently cannot offer any mfct. date data however, > unfortunately. Yeah. I think (feel or something) VIA does the usual thing with revision numbers so rev 0x46 means always the same silicon (VT6306) and rev 0x80 is always the same VT6307. There might be other revisions but I think we won't find non-VT6306 rev 0x46 or non-VT6307 rev 0x80. And, for someone using the old driver, VT6306 should probably have 8/8 IR/IT contexts while VT6307 - 4/8 (the new driver doesn't seem to show this info and I think VT6306 can be limited to 4 as well). -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86 setup: correct booting on 486DX4
Hi Linus; please pull: git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git for-linus H. Peter Anvin (1): x86 setup: correct booting on 486DX4 arch/x86/boot/pmjump.S | 32 +--- 1 files changed, 21 insertions(+), 11 deletions(-) [Full diff and log follows] commit ac3b37b78c5f0f0be0b476a35370650f7bad482f Author: H. Peter Anvin <[EMAIL PROTECTED]> Date: Sun Nov 4 14:33:41 2007 -0800 x86 setup: correct booting on 486DX4 Apparently, the 486DX4 does not correctly serialize a mov to %cr0, so we really do need the far jump immediately afterwards. This means losing the nice separation between 16- and 32-bit code, but c'est la vie. Also pass %ebx = %edi = %ebp = 0 to support future extension of the 32-bit boot protocol. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S index 2e55923..17e6dec 100644 --- a/arch/x86/boot/pmjump.S +++ b/arch/x86/boot/pmjump.S @@ -28,27 +28,37 @@ * void protected_mode_jump(u32 entrypoint, u32 bootparams); */ protected_mode_jump: - xorl%ebx, %ebx # Flag to indicate this is a boot movl%edx, %esi # Pointer to boot_params table - movl%eax, 2f# Patch ljmpl instruction + + xorl%edx, %edx + movw%cs, %dx + shll$4, %edx# Patch ljmpl instruction + addl%edx, 2f jmp 1f # Short jump to flush instruction q. 1: movw$__BOOT_DS, %cx + xorl%ebx, %ebx # Per protocol + xorl%ebp, %ebp # Per protocol + xorl%edi, %edi # Per protocol movl%cr0, %edx orb $1, %dl # Protected mode (PE) bit movl%edx, %cr0 + + .byte 0x66, 0xea # ljmpl opcode +2: .long 3f # Offset + .word __BOOT_CS # Segment - movw%cx, %ds - movw%cx, %es - movw%cx, %fs - movw%cx, %gs - movw%cx, %ss + .code32 +3: + movl%ecx, %ds + movl%ecx, %es + movl%ecx, %fs + movl%ecx, %gs + movl%ecx, %ss # Jump to the 32-bit entrypoint - .byte 0x66, 0xea # ljmpl opcode -2: .long 0 # offset - .word __BOOT_CS # segment - + jmpl*%eax + .size protected_mode_jump, .-protected_mode_jump - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: textsearch in module = BUG: scheduling while atomic
I change the algo, from "bm" to "kmp" and probably resolve. I will make more tests and if error occour i post latter... Thanks so much. Felipe Dias On 11/4/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: > On 11/04/2007 11:16 PM, Jiri Slaby wrote: > > On 11/04/2007 11:05 PM, Felipe Dias wrote: > >> Ow sorry... the warning: > >> > >> BUG: scheduling while atomic: gnome-cups-icon/0x0101/3827 > >> [] __sched_text_start+0x56/0x7c8 > >> [] autoremove_wake_function+0x14/0x33 > >> [] __wake_up_common+0x35/0x53 > >> [] __wake_up+0x32/0x43 > >> [] wait_for_completion+0x6a/0x9f > >> [] default_wake_function+0x0/0xc > >> [] call_usermodehelper_keys+0xad/0xc5 > >> [] request_module+0xd5/0xe6 > > > > Seems like it is not inteded for using in atomic at all (you probably > > passed an > > unknown algo here to the prepare function). You seem to have to use a > > workqueue > > if it is possible or prepare the serach before the interrupt occurs. > > Or pass 0 instead of TS_AUTOLOAD. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Prism54: Convert mgmt_sem to the mutex API
Prism54: Convert mgmt_sem to the mutex API
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
--
diff --git a/drivers/net/wireless/prism54/islpci_dev.c
b/drivers/net/wireless/prism54/islpci_dev.c
index 219dd65..dbb538c 100644
--- a/drivers/net/wireless/prism54/islpci_dev.c
+++ b/drivers/net/wireless/prism54/islpci_dev.c
@@ -861,7 +861,7 @@ islpci_setup(struct pci_dev *pdev)
init_waitqueue_head(>reset_done);
/* init the queue read locks, process wait counter */
- sema_init(>mgmt_sem, 1);
+ mutex_init(>mgmt_lock);
priv->mgmt_received = NULL;
init_waitqueue_head(>mgmt_wqueue);
sema_init(>stats_sem, 1);
diff --git a/drivers/net/wireless/prism54/islpci_dev.h
b/drivers/net/wireless/prism54/islpci_dev.h
index 73d..4e0182c 100644
--- a/drivers/net/wireless/prism54/islpci_dev.h
+++ b/drivers/net/wireless/prism54/islpci_dev.h
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "isl_38xx.h"
#include "isl_oid.h"
@@ -164,7 +165,7 @@ typedef struct {
wait_queue_head_t reset_done;
/* used by islpci_mgt_transaction */
- struct semaphore mgmt_sem; /* serialize access to mailbox and wqueue */
+ struct mutex mgmt_lock; /* serialize access to mailbox and wqueue */
struct islpci_mgmtframe *mgmt_received; /* mbox for incoming frame */
wait_queue_head_t mgmt_wqueue;/* waitqueue for mbox */
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
The yellow ships hung in the air just like bricks dont do
(The Hitch-Hiker's Guide to the Galaxy)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PID namespaces break initrd+hibernate combination?
Hi all. Please excuse me if this has already been answered. I'm not currently subscribed to LKML. I've just been preparing a new tux-on-ice release against Linus' current tree, and encountered a failure to freeze pid 1 when seeking to resume, using an initrd: [ 74.192734] Freezing of tasks failed after 19.99 seconds (1 tasks refusing to freeze): [ 74.193502] taskPC stack pid father [ 74.193504] swapper S 810002023030 4968 1 0 [ 74.193512] 81000203fdb0 0046 810002023040 810003249140 [ 74.194296] 81000203fd80 803150a1 81000203fdb0 810002023180 [ 74.195087] 810002023030 0004 0001 0001 [ 74.195860] Call Trace: [ 74.196123] [] security_task_wait+0x11/0x20 [ 74.196692] [] do_wait+0x51d/0xda0 [ 74.197187] [] default_wake_function+0x0/0x10 [ 74.197772] [] sys_wait4+0x2c/0x30 [ 74.198264] [] initrd_load+0x175/0x370 [ 74.198794] [] prepare_namespace+0x8f/0x1d0 [ 74.199362] [] kernel_init+0x1ad/0x2b0 [ 74.199889] [] _spin_unlock_irq+0x26/0x60 [ 74.200439] [] finish_task_switch+0x67/0xc0 [ 74.201008] [] child_rip+0xa/0x12 [ 74.201494] [] acpi_os_acquire_lock+0x9/0xb [ 74.202063] [] kernel_init+0x0/0x2b0 [ 74.202570] [] child_rip+0x0/0x12 I believe it might be related to pid namespaces, but am not completely sure yet (will do a git bisect if needs be). So, then, I'm writing to ask: Is this a known issue? Is there any fix already available that I've not found in my googling? Regards, Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Makefile: add 'includecheck' help text
On Sun, Nov 04, 2007 at 12:01:55PM -0800, Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > Add 'includecheck' to the Static analyzers help list. Thanks Randy - applied. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix i486 boot failure due to stale %ds
Mikael Pettersson wrote: Maybe not. I had a look in Intel's SDM Vol3, and the section "switching to protected mode" specifies that a move to %cr0 that sets PE should immediately be followed by a far jmp or call. They write that "random failures can occur if other instructions exist between [the move to %cr0] and [the far jmp/call]". The current version of pmjump.S does exactly that: it executes a bunch of moves to segment registers in that window. (Section 9.9.1 in the Sept. 2005 revision I have in front of me.) Similarly, section "serializing instructions" writes that a move to %cr0 that enables or disables paging should be followed by a jump. They write that this isn't required in P4 or P6 family processors, but is required for compatibility with other ia32 processors. Reading between the lines, they imply that older ia32 processors don't treat %cr0 writes as completely serializing. (Section 7.4 in the Sept. 2005 revision.) The problem is that Intel has a tendency to exaggerate in their documentation; in particular, they tend not to remove restrictions that are long-since obsolete. However, it sounds like you have actually found a CPU for which this restriction is motivated. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: textsearch in module = BUG: scheduling while atomic
On 11/04/2007 11:16 PM, Jiri Slaby wrote: > On 11/04/2007 11:05 PM, Felipe Dias wrote: >> Ow sorry... the warning: >> >> BUG: scheduling while atomic: gnome-cups-icon/0x0101/3827 >> [] __sched_text_start+0x56/0x7c8 >> [] autoremove_wake_function+0x14/0x33 >> [] __wake_up_common+0x35/0x53 >> [] __wake_up+0x32/0x43 >> [] wait_for_completion+0x6a/0x9f >> [] default_wake_function+0x0/0xc >> [] call_usermodehelper_keys+0xad/0xc5 >> [] request_module+0xd5/0xe6 > > Seems like it is not inteded for using in atomic at all (you probably passed > an > unknown algo here to the prepare function). You seem to have to use a > workqueue > if it is possible or prepare the serach before the interrupt occurs. Or pass 0 instead of TS_AUTOLOAD. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: textsearch in module = BUG: scheduling while atomic
On 11/04/2007 11:05 PM, Felipe Dias wrote: > Ow sorry... the warning: > > BUG: scheduling while atomic: gnome-cups-icon/0x0101/3827 > [] __sched_text_start+0x56/0x7c8 > [] autoremove_wake_function+0x14/0x33 > [] __wake_up_common+0x35/0x53 > [] __wake_up+0x32/0x43 > [] wait_for_completion+0x6a/0x9f > [] default_wake_function+0x0/0xc > [] call_usermodehelper_keys+0xad/0xc5 > [] request_module+0xd5/0xe6 Seems like it is not inteded for using in atomic at all (you probably passed an unknown algo here to the prepare function). You seem to have to use a workqueue if it is possible or prepare the serach before the interrupt occurs. Post your code if you want more appropriate answer. > [] __next_cpu+0x12/0x21 > [] find_busiest_group+0x1d6/0x55a > [] textsearch_prepare+0x8c/0x11a > [] __find_get_block_slow+0x127/0x131 > [] hook_test+0x4c/0xb6 [test_mod] > [] __find_get_block+0x13f/0x149 > [] nf_iterate+0x38/0x6a > [] ip_rcv_finish+0x0/0x294 > [] nf_hook_slow+0x4d/0xb5 > [] ip_rcv_finish+0x0/0x294 > [] ip_rcv+0x20b/0x4bd > [] ip_rcv_finish+0x0/0x294 > [] search_by_key+0x17f/0xe87 [reiserfs] > [] del_timer_sync+0xa/0x14 > [] schedule_timeout+0x79/0x8d > [] netif_receive_skb+0x2ef/0x309 > [] __nla_put+0xe/0x25 > [] process_backlog+0x7c/0xe9 > [] net_rx_action+0x95/0x186 > [] __do_softirq+0x6c/0xcf > [] do_softirq+0x32/0x36 > [] local_bh_enable+0x7b/0x89 > [] dev_queue_xmit+0x202/0x221 > [] ip_output+0x269/0x2a3 > [] ip_queue_xmit+0x358/0x39a > [] __alloc_pages+0x64/0x2a8 > [] cache_alloc_refill+0x74/0x45f > [] tcp_v4_send_check+0x86/0xbc > [] tcp_transmit_skb+0x618/0x652 > [] __alloc_skb+0x47/0x104 > [] tcp_connect+0x2a3/0x31d > [] tcp_v4_connect+0x493/0x5a4 > [] touch_atime+0x8b/0xac > [] inet_stream_connect+0x87/0x20d > [] copy_from_user+0x23/0x4f > [] sys_connect+0x82/0xad > [] _spin_lock_bh+0x8/0x18 > [] _spin_lock_bh+0x8/0x18 > [] release_sock+0x12/0x8c > [] tcp_setsockopt+0x309/0x321 > [] d_alloc+0x14b/0x17e > [] d_instantiate+0x66/0x6a > [] sock_common_setsockopt+0x1d/0x22 > [] sys_setsockopt+0x88/0xa7 > [] sys_socketcall+0x8f/0x242 > [] sysenter_past_esp+0x5f/0x85 > === regards, -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fat: optimize fat_count_free_clusters()
On large partition, scanning the free clusters is very slow if users
doesn't use "usefree" option.
For optimizing it, this patch uses sb_breadahead() to read of FAT
sectors. On some user's 15GB partition, this patch improved it very
much (1min => 600ms).
The following is the result of 2GB partition on my machine.
without patch:
[EMAIL PROTECTED] (/)# time df -h > /dev/null
real0m1.202s
user0m0.000s
sys 0m0.440s
with patch:
[EMAIL PROTECTED] (/)# time df -h > /dev/null
real0m0.378s
user0m0.012s
sys 0m0.168s
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
fs/fat/fatent.c | 28
1 file changed, 28 insertions(+)
diff -puN fs/fat/fatent.c~fat_optimize-count-freeclus fs/fat/fatent.c
--- linux-2.6/fs/fat/fatent.c~fat_optimize-count-freeclus 2007-11-05
06:01:10.0 +0900
+++ linux-2.6-hirofumi/fs/fat/fatent.c 2007-11-05 06:01:10.0 +0900
@@ -590,21 +590,49 @@ error:
EXPORT_SYMBOL_GPL(fat_free_clusters);
+/* 128kb is the whole sectors for FAT12 and FAT16 */
+#define FAT_READA_SIZE (128 * 1024)
+
+static void fat_ent_reada(struct super_block *sb, struct fat_entry *fatent,
+ unsigned long reada_blocks)
+{
+ struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
+ sector_t blocknr;
+ int i, offset;
+
+ ops->ent_blocknr(sb, fatent->entry, , );
+
+ for (i = 0; i < reada_blocks; i++)
+ sb_breadahead(sb, blocknr + i);
+}
+
int fat_count_free_clusters(struct super_block *sb)
{
struct msdos_sb_info *sbi = MSDOS_SB(sb);
struct fatent_operations *ops = sbi->fatent_ops;
struct fat_entry fatent;
+ unsigned long reada_blocks, reada_mask, cur_block;
int err = 0, free;
lock_fat(sbi);
if (sbi->free_clusters != -1)
goto out;
+ reada_blocks = FAT_READA_SIZE >> sb->s_blocksize_bits;
+ reada_mask = reada_blocks - 1;
+ cur_block = 0;
+
free = 0;
fatent_init();
fatent_set_entry(, FAT_START_ENT);
while (fatent.entry < sbi->max_cluster) {
+ /* readahead of fat blocks */
+ if ((cur_block & reada_mask) == 0) {
+ unsigned long rest = sbi->fat_length - cur_block;
+ fat_ent_reada(sb, , min(reada_blocks, rest));
+ }
+ cur_block++;
+
err = fat_ent_read_block(sb, );
if (err)
goto out;
_
--
OGAWA Hirofumi <[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 1/2] FAT: Fix printk format strings.
From: Vegard Nossum <[EMAIL PROTECTED]>
This makes sure printk format strings contain no more than a single
line.
Signed-off-by: Vegard Nossum <[EMAIL PROTECTED]>
[the message was tweaked.]
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
fs/fat/inode.c |6 ++
fs/fat/misc.c |5 ++---
2 files changed, 4 insertions(+), 7 deletions(-)
diff -puN fs/fat/inode.c~fat_fix-printk-format-str fs/fat/inode.c
--- linux-2.6/fs/fat/inode.c~fat_fix-printk-format-str 2007-11-05
05:43:31.0 +0900
+++ linux-2.6-hirofumi/fs/fat/inode.c 2007-11-05 05:43:31.0 +0900
@@ -1295,10 +1295,8 @@ int fat_fill_super(struct super_block *s
fsinfo = (struct fat_boot_fsinfo *)fsinfo_bh->b_data;
if (!IS_FSINFO(fsinfo)) {
- printk(KERN_WARNING
- "FAT: Did not find valid FSINFO signature.\n"
- " Found signature1 0x%08x signature2 0x%08x"
- " (sector = %lu)\n",
+ printk(KERN_WARNING "FAT: Invalid FSINFO signature: "
+ "0x%08x, 0x%08x (sector = %lu)\n",
le32_to_cpu(fsinfo->signature1),
le32_to_cpu(fsinfo->signature2),
sbi->fsinfo_sector);
diff -puN fs/fat/misc.c~fat_fix-printk-format-str fs/fat/misc.c
--- linux-2.6/fs/fat/misc.c~fat_fix-printk-format-str 2007-11-05
05:43:31.0 +0900
+++ linux-2.6-hirofumi/fs/fat/misc.c2007-11-05 05:59:53.0 +0900
@@ -55,9 +55,8 @@ void fat_clusters_flush(struct super_blo
fsinfo = (struct fat_boot_fsinfo *)bh->b_data;
/* Sanity check */
if (!IS_FSINFO(fsinfo)) {
- printk(KERN_ERR "FAT: Did not find valid FSINFO signature.\n"
- " Found signature1 0x%08x signature2 0x%08x"
- " (sector = %lu)\n",
+ printk(KERN_ERR "FAT: Invalid FSINFO signature: "
+ "0x%08x, 0x%08x (sector = %lu)\n",
le32_to_cpu(fsinfo->signature1),
le32_to_cpu(fsinfo->signature2),
sbi->fsinfo_sector);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: textsearch in module = BUG: scheduling while atomic
Ow sorry... the warning: BUG: scheduling while atomic: gnome-cups-icon/0x0101/3827 [] __sched_text_start+0x56/0x7c8 [] autoremove_wake_function+0x14/0x33 [] __wake_up_common+0x35/0x53 [] __wake_up+0x32/0x43 [] wait_for_completion+0x6a/0x9f [] default_wake_function+0x0/0xc [] call_usermodehelper_keys+0xad/0xc5 [] request_module+0xd5/0xe6 [] __next_cpu+0x12/0x21 [] find_busiest_group+0x1d6/0x55a [] textsearch_prepare+0x8c/0x11a [] __find_get_block_slow+0x127/0x131 [] hook_test+0x4c/0xb6 [test_mod] [] __find_get_block+0x13f/0x149 [] nf_iterate+0x38/0x6a [] ip_rcv_finish+0x0/0x294 [] nf_hook_slow+0x4d/0xb5 [] ip_rcv_finish+0x0/0x294 [] ip_rcv+0x20b/0x4bd [] ip_rcv_finish+0x0/0x294 [] search_by_key+0x17f/0xe87 [reiserfs] [] del_timer_sync+0xa/0x14 [] schedule_timeout+0x79/0x8d [] netif_receive_skb+0x2ef/0x309 [] __nla_put+0xe/0x25 [] process_backlog+0x7c/0xe9 [] net_rx_action+0x95/0x186 [] __do_softirq+0x6c/0xcf [] do_softirq+0x32/0x36 [] local_bh_enable+0x7b/0x89 [] dev_queue_xmit+0x202/0x221 [] ip_output+0x269/0x2a3 [] ip_queue_xmit+0x358/0x39a [] __alloc_pages+0x64/0x2a8 [] cache_alloc_refill+0x74/0x45f [] tcp_v4_send_check+0x86/0xbc [] tcp_transmit_skb+0x618/0x652 [] __alloc_skb+0x47/0x104 [] tcp_connect+0x2a3/0x31d [] tcp_v4_connect+0x493/0x5a4 [] touch_atime+0x8b/0xac [] inet_stream_connect+0x87/0x20d [] copy_from_user+0x23/0x4f [] sys_connect+0x82/0xad [] _spin_lock_bh+0x8/0x18 [] _spin_lock_bh+0x8/0x18 [] release_sock+0x12/0x8c [] tcp_setsockopt+0x309/0x321 [] d_alloc+0x14b/0x17e [] d_instantiate+0x66/0x6a [] sock_common_setsockopt+0x1d/0x22 [] sys_setsockopt+0x88/0xa7 [] sys_socketcall+0x8f/0x242 [] sysenter_past_esp+0x5f/0x85 === Thanks, Felipe Dias On 11/4/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: > On 11/04/2007 09:22 PM, Felipe Dias wrote: > > Hi, thanks for your fast reply, I try, I put GFP_ATOMIC. > > The error remains, but with less frequency. The sometimes appears, is > > not where he does the checking. Any ideia ? > > Post the trace (the BUG warning) with the GFP_ATOMIC used. > > regards, > -- > Jiri Slaby ([EMAIL PROTECTED]) > Faculty of Informatics, Masaryk University > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix i486 boot failure due to stale %ds
On Sun, 04 Nov 2007 11:41:58 -0800, H. Peter Anvin wrote: > Mikael Pettersson wrote: > > > > First patch didn't build. Second patch builds and boots Ok. > > > > So this means the 486 DX4 has a buggy mov to %cr0? > > > > Apparently. Maybe not. I had a look in Intel's SDM Vol3, and the section "switching to protected mode" specifies that a move to %cr0 that sets PE should immediately be followed by a far jmp or call. They write that "random failures can occur if other instructions exist between [the move to %cr0] and [the far jmp/call]". The current version of pmjump.S does exactly that: it executes a bunch of moves to segment registers in that window. (Section 9.9.1 in the Sept. 2005 revision I have in front of me.) Similarly, section "serializing instructions" writes that a move to %cr0 that enables or disables paging should be followed by a jump. They write that this isn't required in P4 or P6 family processors, but is required for compatibility with other ia32 processors. Reading between the lines, they imply that older ia32 processors don't treat %cr0 writes as completely serializing. (Section 7.4 in the Sept. 2005 revision.) /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: mdadm/raid5 hung/d-state
On Mon, 5 Nov 2007, Neil Brown wrote: On Sunday November 4, [EMAIL PROTECTED] wrote: # ps auxww | grep D USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush] root 274 0.0 0.0 0 0 ?DOct21 13:00 [pdflush] After several days/weeks, this is the second time this has happened, while doing regular file I/O (decompressing a file), everything on the device went into D-state. At a guess (I haven't looked closely) I'd say it is the bug that was meant to be fixed by commit 4ae3f847e49e3787eca91bced31f8fd328d50496 except that patch applied badly and needed to be fixed with the following patch (not in git yet). These have been sent to stable@ and should be in the queue for 2.6.23.2 Ah, thanks Neil, will be updating as soon as it is released, thanks. Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
