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

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

[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

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

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

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

[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

[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 ---

[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

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

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. >>

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

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

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

[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:

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

[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

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

[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

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

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]> > > --- >

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

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

[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 =

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

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

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 > >

[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

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 >

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,

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

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

[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

[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 +++

[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

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

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 > +++

[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 ---

[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 +++

[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 ---

[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 ---

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: ---

[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

[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

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

[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

[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

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

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

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

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

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

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

[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

[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

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

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: > >

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

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

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

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 +---

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

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

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

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,

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

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

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);

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

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

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

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

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

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

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

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

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

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

[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

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

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. > >

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:

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

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

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

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

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

[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

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

[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 +++

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

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

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

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 >>

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 > []

[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

[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 |

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 []

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

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 ?

  1   2   3   4   5   >