Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
From: Greg KH <[EMAIL PROTECTED]> Date: Tue, 1 Jan 2008 23:00:08 -0800 > I'm very open to potential patches to do this, just don't ignore the > issues that others have run into in the past when attempting this. Fair enough. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] linux/ufs_fs.h: use __u64 for userspace
On Wed, Jan 02, 2008 at 04:02:42AM +0200, Adrian Bunk wrote: > But userspace anyway can't use them since it doesn't know what "uspi" > is, so you should better reduce the userspace visibility of this header. We had this come up before and the header should not be exported to userspace at all. It documents the ufs ondisk structures which are a) not a user/kernel interface b) may change frequently due to addition of another ufs subvariant. The only non-kernel user of this known to me is silo, which should just have it's own header documenting the solaris sparc ufs variant it needs to understand, possibly by using a copy of the kernel version at any given point of time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
On Wed, Jan 02, 2008 at 07:13:08AM +0100, Andreas Mohr wrote: > Hi, > > On Tue, Jan 01, 2008 at 10:00:06PM -0800, Greg KH wrote: > > Ok, no, I didn't write that patch, I'm getting very confused here. > > > > In 2.6.24-rc6 there is no usage of debugfs in the ohci driver. > > > > In the -mm tree there is a patch, from Tony Jones, that moves some debug > > code out of sysfs and into debugfs where it belongs. It does it for > > both the ehci and ohci USB host controller drivers, and this is the code > > that is incorrect if CONFIG_DEBUGFS is not enabled. > > > > So, for the 2.6.24 release, nothing needs to be changed, all is good, > > and there is no regression. > > > > Right? Or am I still confused about this whole thing? > > Probably, since I also wasn't sure about this getting added to the > post-2.6.23 regressions. I'd expect this problem to be -mm only myself, > but then I didn't actively verify it in code (and I haven't tried -rc6 > proper on that machine yet either, build takes ages ;). > OK, since I cannot really offer anything other than positive feelings about > this being non-rc6 breakage, should I try -rc6 proper, too? Please do, that would be very helpful. As the code being discussed isn't even in Linus's tree, it's hard to see how this could be a proposed fix for the regression :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Tue, Jan 01, 2008 at 09:25:01PM -0800, David Miller wrote: > From: Greg KH <[EMAIL PROTECTED]> > Date: Tue, 1 Jan 2008 21:18:28 -0800 > > > But is the usage of this semaphore in the class code really a problem? > > Has it been seen to cause issues anywhere? Does it show up on any > > benchmarks as being something that really needs to be replaced? > > It's a question of maintainability and simplicity also Greg. > > I actually have no idea why you're making any sort of fuss about this. > To me it's so clear cut that we should do that. For most cases, yes, I agree with this, but due to the lockdep issues that occur here, and the whole mess with the suspend path and locking the device tree, that has been hashed out many times in the past, I am interested in trying to see if there is any real reason why this is absolutely necessary to convert. If no one has noticed any issues in this area, I think the complexity that will be involved in any such conversion will strongly outweigh any simplicity that might be expected. I'm very open to potential patches to do this, just don't ignore the issues that others have run into in the past when attempting this. 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: sata_nv + ADMA + Samsung disk problem
Robert Hancock wrote: > Jeff Garzik wrote: >> Tejun Heo wrote: >>> Thanks a lot for the detailed explanation. Nvidia ppl, any ideas? >>> FLUSH is used regularly. We really need to fix this. >> >> >> I reiterate my opinion :) ... We should remove ADMA support from >> sata_nv. It's only in a few chips, it's not appearing in any new >> chips, and nasty problems have lingered since ADMA support was >> introduced. >> >> Definitely sounds like we should disable ADMA by default for >> 2.6.24-rc, too. > > I wouldn't agree.. It's only in a few chips (CK804/MCP04), but those > chips are very common in desktop, workstation, even some server > machines. Given the huge number of these chips out there, problem > reports have been quite rare. I agree with Jeff here. Maybe not remove but disable it by default and when enabling warn loudly. NCQ just doesn't enough for its cost when the cost includes erratic behaviors. Only very small fraction of error cases actually make to bugzilla or this mailing list. Nvidia gents, is there anyway (be it NDA or whatever) to get Robert or any of us technical documentation? 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/
(Try #3) [Patch 3/8] S390: Remove 'TOPDIR' from Makefile
>If the output file does not exist then kbuild does not care about the >dependencies and will just build the target. >On the second invocation when the target exists then kbuild has >created a file named ..cmd that list the dependencies >and this includes any included .c file. >So there is just no pint in defining this dependency explicit >in the MAkefile - kbuild will figure it out automatically. > >The right fix is just to kill the explicit listed dependency. If I understand you correctly, then the fix should be the below one. > This patch removes TOPDIR from arch/s390/kernel/Makefile. Cc: Martin Schwidefsky <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Signed-off-by: WANG Cong <[EMAIL PROTECTED]> --- diff --git a/arch/s390/kernel/Makefile b/arch/s390/kernel/Makefile index 56cb710..b3b650a 100644 --- a/arch/s390/kernel/Makefile +++ b/arch/s390/kernel/Makefile @@ -31,7 +31,3 @@ S390_KEXEC_OBJS := machine_kexec.o crash.o S390_KEXEC_OBJS += $(if $(CONFIG_64BIT),relocate_kernel64.o,relocate_kernel.o) obj-$(CONFIG_KEXEC) += $(S390_KEXEC_OBJS) -# -# This is just to get the dependencies... -# -binfmt_elf32.o:$(TOPDIR)/fs/binfmt_elf.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_nv + ADMA + Samsung disk problem
Jeff Garzik wrote: Tejun Heo wrote: Thanks a lot for the detailed explanation. Nvidia ppl, any ideas? FLUSH is used regularly. We really need to fix this. I reiterate my opinion :) ... We should remove ADMA support from sata_nv. It's only in a few chips, it's not appearing in any new chips, and nasty problems have lingered since ADMA support was introduced. Definitely sounds like we should disable ADMA by default for 2.6.24-rc, too. I wouldn't agree.. It's only in a few chips (CK804/MCP04), but those chips are very common in desktop, workstation, even some server machines. Given the huge number of these chips out there, problem reports have been quite rare. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(Try #3) [Patch 4/8] CRIS: Remove 'TOPDIR' from Makefiles
Refine it as suggested by Andreas. > This patch removes TOPDIR from Cris Makefiles. Cc: Mikael Starvik <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Cc: Andreas Schwab <[EMAIL PROTECTED]> Signed-off-by: WANG Cong <[EMAIL PROTECTED]> --- diff --git a/arch/cris/arch-v32/boot/compressed/Makefile b/arch/cris/arch-v32/boot/compressed/Makefile index 9f77eda..609692f 100644 --- a/arch/cris/arch-v32/boot/compressed/Makefile +++ b/arch/cris/arch-v32/boot/compressed/Makefile @@ -7,7 +7,7 @@ target = $(target_compressed_dir) src= $(src_compressed_dir) -CC = gcc-cris -mlinux -march=v32 -I $(TOPDIR)/include +CC = gcc-cris -mlinux -march=v32 $(LINUXINCLUDE) CFLAGS = -O2 LD = gcc-cris -mlinux -march=v32 -nostdlib OBJCOPY = objcopy-cris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(Try #3) [Patch 2/8] MIPS: Remove 'TOPDIR' from Makefiles
>> >> Shouldn't that use $(LINUXINCLUDE), or $(KBUILD_CPPFLAGS)? >It would be better to use $(LINUXINCLUDE) as we then pull in all config >symbols too and do not have to hardcode kbuild internal names (include2). OK. Refine this patch. ---> Since TOPDIR is obsolete, this patch removes TOPDIR from the Mips Makefiles. Cc: Ralf Baechle <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Signed-off-by: WANG Cong <[EMAIL PROTECTED]> --- diff --git a/arch/mips/lasat/image/Makefile b/arch/mips/lasat/image/Makefile index 5332449..17f5266 100644 --- a/arch/mips/lasat/image/Makefile +++ b/arch/mips/lasat/image/Makefile @@ -12,7 +12,7 @@ endif MKLASATIMG = mklasatimg MKLASATIMG_ARCH = mq2,mqpro,sp100,sp200 -KERNEL_IMAGE = $(TOPDIR)/vmlinux +KERNEL_IMAGE = vmlinux KERNEL_START = $(shell $(NM) $(KERNEL_IMAGE) | grep " _text" | cut -f1 -d\ ) KERNEL_ENTRY = $(shell $(NM) $(KERNEL_IMAGE) | grep kernel_entry | cut -f1 -d\ ) @@ -24,7 +24,7 @@ HEAD_DEFINES := -D_kernel_start=0x$(KERNEL_START) \ -D TIMESTAMP=$(shell date +%s) $(obj)/head.o: $(obj)/head.S $(KERNEL_IMAGE) - $(CC) -fno-pic $(HEAD_DEFINES) -I$(TOPDIR)/include -c -o $@ $< + $(CC) -fno-pic $(HEAD_DEFINES) $(LINUXINCLUDE) -c -o $@ $< OBJECTS = head.o kImage.o -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_nv + ADMA + Samsung disk problem
Tejun Heo wrote: Thanks a lot for the detailed explanation. Nvidia ppl, any ideas? FLUSH is used regularly. We really need to fix this. I reiterate my opinion :) ... We should remove ADMA support from sata_nv. It's only in a few chips, it's not appearing in any new chips, and nasty problems have lingered since ADMA support was introduced. Definitely sounds like we should disable ADMA by default for 2.6.24-rc, too. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
Hi, On Tue, Jan 01, 2008 at 10:00:06PM -0800, Greg KH wrote: > Ok, no, I didn't write that patch, I'm getting very confused here. > > In 2.6.24-rc6 there is no usage of debugfs in the ohci driver. > > In the -mm tree there is a patch, from Tony Jones, that moves some debug > code out of sysfs and into debugfs where it belongs. It does it for > both the ehci and ohci USB host controller drivers, and this is the code > that is incorrect if CONFIG_DEBUGFS is not enabled. > > So, for the 2.6.24 release, nothing needs to be changed, all is good, > and there is no regression. > > Right? Or am I still confused about this whole thing? Probably, since I also wasn't sure about this getting added to the post-2.6.23 regressions. I'd expect this problem to be -mm only myself, but then I didn't actively verify it in code (and I haven't tried -rc6 proper on that machine yet either, build takes ages ;). OK, since I cannot really offer anything other than positive feelings about this being non-rc6 breakage, should I try -rc6 proper, too? > Hm, I wonder if this means I can go back to drinking more holiday > wine... :) .even more confusion? :) Thanks for your help, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
Hi, On Sun, Dec 30, 2007 at 03:34:45PM -0500, Alan Stern wrote: > It looks like Greg misused the debugfs API -- which is ironic, because > he wrote debugfs in the first place! :-) > > Let me know if this patch fixes the problem. If it does, I'll submit > it to Greg with all the proper accoutrements. Finally a 2.6.24-rc6-mm1 with working USB WLAN. :) IOW I can confirm that this was the cause of the USB problem I was having. Thanks! Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Only print SCSI data direction warning once for a command
When I use cdparanoia my logs get spammed a lot by
printk: 464 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
program cdparanoia not setting count and/or reply_len properly
printk: 1078 messages suppressed.
and many more of those. With this patch the message is only printed once
for a command in a row.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
drivers/scsi/sg.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: linux/drivers/scsi/sg.c
===
--- linux.orig/drivers/scsi/sg.c
+++ linux/drivers/scsi/sg.c
@@ -602,8 +602,9 @@ sg_write(struct file *filp, const char _
* but is is possible that the app intended SG_DXFER_TO_DEV, because
there
* is a non-zero input_size, so emit a warning.
*/
- if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV)
- if (printk_ratelimit())
+ if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV) {
+ static char cmd[TASK_COMM_LEN];
+ if (printk_ratelimit() && strcmp(current->comm, cmd)) {
printk(KERN_WARNING
"sg_write: data in/out %d/%d bytes for SCSI
command 0x%x--"
"guessing data in;\n" KERN_WARNING " "
@@ -611,6 +612,9 @@ sg_write(struct file *filp, const char _
old_hdr.reply_len - (int)SZ_SG_HEADER,
input_size, (unsigned int) cmnd[0],
current->comm);
+ strcpy(cmd, current->comm);
+ }
+ }
k = sg_common_write(sfp, srp, cmnd, sfp->timeout, blocking);
return (k < 0) ? k : count;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
On Mon, Dec 31, 2007 at 11:26:43AM -0800, Greg KH wrote: > On Mon, Dec 31, 2007 at 12:49:52PM -0500, Alan Stern wrote: > > On Sun, 30 Dec 2007, Greg KH wrote: > > > > > > It looks like Greg misused the debugfs API -- which is ironic, because > > > > he wrote debugfs in the first place! :-) > > > > > > Oh crap, sorry, I did mess that up :( Ok, no, I didn't write that patch, I'm getting very confused here. In 2.6.24-rc6 there is no usage of debugfs in the ohci driver. In the -mm tree there is a patch, from Tony Jones, that moves some debug code out of sysfs and into debugfs where it belongs. It does it for both the ehci and ohci USB host controller drivers, and this is the code that is incorrect if CONFIG_DEBUGFS is not enabled. So, for the 2.6.24 release, nothing needs to be changed, all is good, and there is no regression. Right? Or am I still confused about this whole thing? I will go fix up Tony's patches in the -mm tree that do not handle the error return values from debugfs properly, but that is not such a rush, as Tony is on vacation for a few weeks, and those patches are going to be going in only after 2.6.24 is out. Hm, I wonder if this means I can go back to drinking more holiday wine... :) 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/
(Try #3) [Patch 7/8] FS: Remove dead code
On Tue, Jan 01, 2008 at 06:37:29PM +0100, Sam Ravnborg wrote: >On Tue, Jan 01, 2008 at 11:27:37AM -0600, Eric Sandeen wrote: >> WANG Cong wrote: >> > TOPDIR is obsolete, use objtree instead. >> > This patch removes TOPDIR from all fs/ Makefiles. >> >> > diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile >> > index 49e3e7e..d1d3d49 100644 >> > --- a/fs/xfs/Makefile >> > +++ b/fs/xfs/Makefile >> > @@ -1 +1 @@ >> > -include $(TOPDIR)/fs/xfs/Makefile-linux-$(VERSION).$(PATCHLEVEL) >> > +include $(objtree)/fs/xfs/Makefile-linux-$(VERSION).$(PATCHLEVEL) >> >> FWIW $(TOPDIR) is already banished from the latest xfs build code: >> >Good - I will ignore the xfs bits. Thanks. I will drop the xfs part. ---> Remove dead code in smbfs makefile. Cc: Alexander Viro <[EMAIL PROTECTED]> Cc: Tim Shimmin <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Signed-off-by: WANG Cong <[EMAIL PROTECTED]> --- diff --git a/fs/smbfs/Makefile b/fs/smbfs/Makefile index 6673ee8..4faf8c4 100644 --- a/fs/smbfs/Makefile +++ b/fs/smbfs/Makefile @@ -16,23 +16,3 @@ EXTRA_CFLAGS += -DSMBFS_PARANOIA #EXTRA_CFLAGS += -DDEBUG_SMB_TIMESTAMP #EXTRA_CFLAGS += -Werror -# -# Maintainer rules -# - -# getopt.c not included. It is intentionally separate -SRC = proc.c dir.c cache.c sock.c inode.c file.c ioctl.c smbiod.c request.c \ - symlink.c - -proto: - -rm -f proto.h - @echo > proto2.h "/*" - @echo >> proto2.h " * Autogenerated with cproto on: " `date` - @echo >> proto2.h " */" - @echo >> proto2.h "" - @echo >> proto2.h "struct smb_request;" - @echo >> proto2.h "struct sock;" - @echo >> proto2.h "struct statfs;" - @echo >> proto2.h "" - cproto -E "gcc -E" -e -v -I $(TOPDIR)/include -DMAKING_PROTO -D__KERNEL__ $(SRC) >> proto2.h - mv proto2.h proto.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ide: use MODULE_VERSION()
On Tue, 2008-01-01 at 22:46 -0600, Matt Domsch wrote: > On Tue, Jan 01, 2008 at 09:32:36PM -0500, Jon Masters wrote: > > On Tue, 2008-01-01 at 19:33 +0100, Bartlomiej Zolnierkiewicz wrote: > > > > > On the second thought: maybe we will be better off with limiting > > > MODULE_VERSION() to the device drivers and the IDE core module for now, > > > and just removing all these private version numbers from host drivers > > > (with one or two exceptions they are not printed or exported currently, > > > moreover exceptions are the cases like stale version numbers from 199x)? > > > > Things like checkpatch could help advise people to bump the version > > number, but it's a bit iffy. Matt D. actually uses the special source > > version modinfo for DKMS - which is different - but it makes me wonder > > whether dynamically generating a version based on source SHA1 wouldn't > > be a better idea in most cases than an outdated hard-coded one. > > We've got that already, it's called 'srcversion', and it's a CRC32 > IIRC after some limited parsing to let it ignore whitspace changes and > comment changes only. > > $ modinfo dell_rbu | grep version > version:3.2 > srcversion: 1D4815D7D6FBEE6612F3C18 Right. And I was referring to the is above (I forgot it's a CRC32 and not a SHA1). But my point is why not codify some "policy" here with respect to module versioning, rather than have the latter exist to workaround the case that module versions aren't bumped manually. (I'm not arguing to remove srcversion, just asking whether that might be a better approach in general - perhaps allow a module to print this version string at init time also, rather than just be in modinfo?) Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 01/12] Use mutex instead of semaphore in driver core
On Jan 2, 2008 1:18 PM, Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Jan 02, 2008 at 08:54:53AM +0800, Dave Young wrote: > > On Dec 30, 2007 1:07 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > On Sat, Dec 29, 2007 at 03:07:30PM +0800, Dave Young wrote: > > > > On Dec 29, 2007 1:06 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > > > > > > > > > On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > > > > > > > > > > > The full boot dmesg with lockdep output is out, there's one > > > > > > > warnings in it : > > > > > > > > > > > > Please fix that warning before the next repost of these patches > > > > > > (along > > > > > > with fixing the problem of them not being able to be applied and > > > > > > successfully built at every point in the series...) > > > > > > > > > > > > > > > > Ok, thanks, I will fix them and repost. > > > > > > > > > > > > > Hi, > > > > After digging the code, I feel hard to fix the lockdep warning due to > > > > some misterious relationship with usb. > > > > > > > > Could someone help on this? thanks. > > > > > > My question back to you is why are you doing this conversion? Have you > > > found that it is needed for something? Are there problems in the -rt > > > kernels that this conversion helps with? Or is it just a janitorial > > > "convert semaphore to mutex" type thing. > > > > Sorry for delay-reply because recently I have little free time. > > > > Mutex is lightweighter than semaphore, the device/class is used > > heavily in kernel, so I think the convert would be worth. > > But is the usage of this semaphore in the class code really a problem? > Has it been seen to cause issues anywhere? Does it show up on any > benchmarks as being something that really needs to be replaced? > > All of the places this is used should be on a "slow" code-path, and the > semaphores themselves should very rarely ever have to block anyone under > normal usages. > > Without any real problems being reported for this, I wouldn't worry > about this, the effort involved is non-trivial as you are quickly > finding out :) > Maybe not a big problem, but AFAIK convertion is better. For Benchmarks, not yet. OTOH, as you said the effort to do this is indeed a problem. Regards 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: 2.6.24-rc6-git7: Reported regressions from 2.6.23
On Tue, Jan 01, 2008 at 02:26:06PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 1 Jan 2008, Rafael J. Wysocki wrote:
> >
> > Subject : Could not set non-blocking flag with 2.6.24-rc5
> > Submitter : Tino Keitel <[EMAIL PROTECTED]>
> > Date: 2007-12-13 16:27
> > References : http://lkml.org/lkml/2007/12/13/392
> > http://bugzilla.kernel.org/show_bug.cgi?id=9557
> > Handled-By :
> > Patch :
>
> That strace shows that trying to open /dev/null fails with ENXIO:
>
> [pid 6050] open("/dev/null", O_RDONLY
> [pid 6050] <... open resumed> )= -1 ENXIO (No such device or
> address)
>
> and everything goes downhill from there.
>
> It would be worth looking at your /dev/null to see what kind of (broken)
> device node it is, and get a clue about *why* it is broken.
>
> Greg, any udev breakage that could affect /dev/null?
I do not know of any such breakage.
But, as this is in a chroot, hopefully udev has properly populated the
chrooted /dev tree for the process to provide the /dev/null device node?
Tino, did you provide a /dev/ for your chroot? Did you use udev to
create it, or did you use a static /dev tree?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux 0.01 released
On Tue, Jan 01, 2008 at 09:56:59PM +0100, Abdel wrote: >Hello everybody and happy new year, > > >I have ported linux 0.01 to gcc-4.x, and bach-3.2 (and few others >programs) can run on it. > >so you will find binary Image of linux 0.01 floppy and qemu hdd here: >http://draconux.free.fr/download/os-dev/linux0.01/Image/ > >to run it on qemu : >> qemu -hdb hd_oldlinux.img -fda linux-0.01-3.3.omg -boot a >nb : also work with bochs, and I have not tested it (yet) on real computer. > Excellent work! Thank you! I think this work is useful for teaching OS newbies. So I will forward this mail to the professors of our CS dept.. Thanks again and happy new year! 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: [BUG] crash - module radio-sf16fmr2 and esp interfere
On Wed, 02 Jan 2008 01:19:33 +0100 [EMAIL PROTECTED] wrote: > same with radio-sf16fmr2 and esp > > after repeatedly modrpobe/modprobe -r radio-sf16fmr2, i can hang my system > when loading esp afterwards > > before loading esp, doing a "cat /proc/ioport" segfaults > > this is with 2.6.24rc6 and also with 2.6.22 > > i have found these issues by running some (probably sick :D ) module > load/unload test across all modules > Hi, Please provide more kernel crash info, as listed in the REPORTING-BUGS file in the top-level directory of the kernel source tree. Thanks. > > -Ursprüngliche Nachricht- > > Von: [EMAIL PROTECTED] > > Gesendet: 01.01.08 21:46:30 > > An: linux-kernel@vger.kernel.org > > Betreff: Re: [BUG] crash - module l440gx buggy ? interfere > > > > > same/similar behaviour with > > > > l440gx and container > > l440gx and acpiphp > > > > after load of l440gx, container and acpiphp modules do also hang my system > > on load/unload. > > > > maybe l440gx leaving the system in some weird state after probe ? > > > > > > > -Ursprüngliche Nachricht- > > > Von: <[EMAIL PROTECTED]> > > > Gesendet: 01.01.08 20:57:08 > > > An: linux-kernel@vger.kernel.org > > > Betreff: [BUG] crash - modules l440gx and parport_pc interfere > > > > > > > > > > there seems some weird interference between l440gx and parport_pc modules > > > > > > i can reproduceable crash my box by either: > > > > > > modprobe parport_pc;modprobe l440gx;rmmod parport_pc > > > > > > or > > > > > > modprobe l440gx; modprobe parport_pc;rmmod parport_pc > > > > > > this happens on 2.6.24rc6 and also older kernel (2.6.22) > > > > > > nothing in dmesg - just > > > >JEDEC: Found no L440GX BIOS device at location zero > > > >JEDEC probe on BIOS chip failed. Using ROM > > > > > > because i haven`t appropriate hardware. > > > > > > don`t know if this is a bug in parport_pc or l440gx but maybe its worth > > > reporting. > > > > > > regards > > > roland --- ~Randy desserts: http://www.xenotime.net/linux/recipes/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.23.12] consistent "invalid opcode: 0000"
Hi all, And Happy New Year! May 2008 bring us less bugs :-) Please Cc me, as I am not subscribed anymore. I recently upgraded the kernel of one of my servers to a vanilla* 2.6.23.12 and had it running for a few days (vanilla*, 'cause I change the Makefile to use distcc). After some time I got "invalid opcode: " MSG and as this was just in time for some AC maintenance, I rebooted the machine, ignoring it. Now I got exactly the same error again, so I decided to post here. tr2 ~ # uname -a Linux tr2 2.6.23.12-K01_AthlonXP_server #1 Sun Dec 23 15:00:54 JST 2007 i686 AMD Athlon(TM) XP 1700+ AuthenticAMD GNU/Linux tr2 ~ # uprecords |head -n5 # Uptime | System Boot up +--- 1 5 days, 20:51:50 | Linux 2.6.23.12-K01_Athl Wed Dec 26 23:03:58 2007 2 3 days, 01:01:31 | Linux 2.6.23.12-K01_Athl Sun Dec 23 22:01:53 2007 -> 3 0 days, 17:53:10 | Linux 2.6.23.12-K01_Athl Tue Jan 1 19:56:22 2008 tr2 ~ # grep "invalid opcode:" -A19 /var/log/syslog-ng/misc/kernel+debug [393854.538495] invalid opcode: [#1] [393854.538541] Modules linked in: w83l785ts asb100 hwmon_vid hwmon i2c_nforce2 pppoe pppox ipt_REJECT xt_state ipt_LOG xt_limit xt_tcpudp iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle ip_tables x_tables ppp_generic slhc ipv6 via_rhine tulip bitrev crc32 uhci_hcd usbcore 8250_pnp 8250 serial_core i2c_viapro ide_cd floppy pcspkr [393854.538783] CPU:0 [393854.538785] EIP:0060:[]Not tainted VLI [393854.538787] EFLAGS: 00010282 (2.6.23.12-K01_AthlonXP_server #1) [393854.538902] EIP is at __d_path+0x27/0x14a [393854.538938] eax: df13508c ebx: 0fff ecx: dfe23d30 edx: 1000 [393854.538978] esi: d1831590 edi: dfe23d30 ebp: d1831590 esp: c3ee3f68 [393854.539019] ds: 007b es: 007b fs: gs: 0033 ss: 0068 [393854.539059] Process sh (pid: 4834, ti=c3ee2000 task=def5faa0 task.ti=c3ee2000) [393854.539100] Stack: dfe23d30 dffef920 000200d0 080ee1e0 d1831590 dfe23d30 dffef220 [393854.539188]c0159965 dffef220 df134000 1000 df134000 fffe dffef920 080ee1e0 [393854.539275] 1000 c3ee2000 c010237e 080ee1e0 1000 b7e9fff4 [393854.539360] Call Trace: [393854.539426] [] sys_getcwd+0xc2/0x159 [393854.539473] [] sysenter_past_esp+0x5f/0x85 [393854.539523] === [393854.539559] Code: 5e 5f 5d c3 55 89 c5 57 56 53 83 ec 10 89 54 24 04 8b 54 24 2c 8b 44 24 28 89 0c 24 8d 5a ff 01 d0 c6 40 ff 00 89 5c 24 0c 8d 48 3b 6d 14 74 21 f6 45 04 10 74 1b 83 ea 0b 89 54 24 0c 0f 88 [393854.539762] EIP: [] __d_path+0x27/0x14a SS:ESP 0068:c3ee3f68 [0.00] Linux version 2.6.23.12-K01_AthlonXP_server ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #1 Sun Dec 23 15:00:54 JST 2007 -- [17929.575016] invalid opcode: [#1] [17929.575056] Modules linked in: w83l785ts asb100 hwmon_vid hwmon i2c_nforce2 pppoe pppox ipt_REJECT xt_state ipt_LOG xt_limit xt_tcpudp iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle ip_tables x_tables ppp_generic slhc ipv6 via_rhine tulip bitrev crc32 uhci_hcd 8250_pnp ehci_hcd 8250 serial_core usbcore floppy pcspkr ide_cd i2c_viapro [17929.575289] CPU:0 [17929.575290] EIP:0060:[]Not tainted VLI [17929.575292] EFLAGS: 00010282 (2.6.23.12-K01_AthlonXP_server #1) [17929.575395] EIP is at __d_path+0x27/0x14a [17929.575429] eax: c8dc808c ebx: 0fff ecx: dfe23d30 edx: 1000 [17929.575468] esi: d4284114 edi: dfe23d30 ebp: d4284114 esp: c1f5df68 [17929.575512] ds: 007b es: 007b fs: gs: 0033 ss: 0068 [17929.575554] Process sh (pid: 21675, ti=c1f5c000 task=dba13550 task.ti=c1f5c000) [17929.575597] Stack: dfe23d30 dffef920 000200d0 080ee1c0 d4284114 dfe23d30 dffef220 [17929.575683]c0159965 dffef220 c8dc7000 1000 c8dc7000 fffe dffef920 080ee1c0 [17929.575770] 1000 c1f5c000 c010237e 080ee1c0 1000 b7e9fff4 [17929.575856] Call Trace: [17929.575923] [] sys_getcwd+0xc2/0x159 [17929.575970] [] sysenter_past_esp+0x5f/0x85 [17929.576018] === [17929.576056] Code: 5e 5f 5d c3 55 89 c5 57 56 53 83 ec 10 89 54 24 04 8b 54 24 2c 8b 44 24 28 89 0c 24 8d 5a ff 01 d0 c6 40 ff 00 89 5c 24 0c 8d 48 3b 6d 14 74 21 f6 45 04 10 74 1b 83 ea 0b 89 54 24 0c 0f 88 [17929.576259] EIP: [] __d_path+0x27/0x14a SS:ESP 0068:c1f5df68 tr2 ~ # ps -A | grep 21675 :-( there are lots of sh processes, so I have no idea how to trace it. I grepped through all the logs in that window, but nothing unusual popped up. Can anyone suggest a good way to trace that? I had a look at the code [1], but that was beyond my asm skills :-| [1] http://lxr.linux.no/linux/arch/i386/kernel/entry.S#L291 Cheers, Kalin. -- |[ ~~ ]| +-> http://ThinRope.net/ <-+ |[ ___
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
From: Greg KH <[EMAIL PROTECTED]> Date: Tue, 1 Jan 2008 21:18:28 -0800 > But is the usage of this semaphore in the class code really a problem? > Has it been seen to cause issues anywhere? Does it show up on any > benchmarks as being something that really needs to be replaced? It's a question of maintainability and simplicity also Greg. I actually have no idea why you're making any sort of fuss about this. To me it's so clear cut that we should do that. Mutexes provide a much simpler locking technology. The things that semaphores can do that mutexes can't are rarely if ever used. Therefore it's better to convert all of those cases only using the simpler semantic set of mutexes from semaphores. And we've been converting the entire tree this way for about 2 years, I'm sorry that you've only just noticed that this is happening and that there is general agreement that in general all such conversions should be made. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 01/12] Use mutex instead of semaphore in driver core
On Wed, Jan 02, 2008 at 08:54:53AM +0800, Dave Young wrote: > On Dec 30, 2007 1:07 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Sat, Dec 29, 2007 at 03:07:30PM +0800, Dave Young wrote: > > > On Dec 29, 2007 1:06 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > > > > > > > On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > > > > > > > > > The full boot dmesg with lockdep output is out, there's one > > > > > > warnings in it : > > > > > > > > > > Please fix that warning before the next repost of these patches (along > > > > > with fixing the problem of them not being able to be applied and > > > > > successfully built at every point in the series...) > > > > > > > > > > > > > Ok, thanks, I will fix them and repost. > > > > > > > > > > Hi, > > > After digging the code, I feel hard to fix the lockdep warning due to > > > some misterious relationship with usb. > > > > > > Could someone help on this? thanks. > > > > My question back to you is why are you doing this conversion? Have you > > found that it is needed for something? Are there problems in the -rt > > kernels that this conversion helps with? Or is it just a janitorial > > "convert semaphore to mutex" type thing. > > Sorry for delay-reply because recently I have little free time. > > Mutex is lightweighter than semaphore, the device/class is used > heavily in kernel, so I think the convert would be worth. But is the usage of this semaphore in the class code really a problem? Has it been seen to cause issues anywhere? Does it show up on any benchmarks as being something that really needs to be replaced? All of the places this is used should be on a "slow" code-path, and the semaphores themselves should very rarely ever have to block anyone under normal usages. Without any real problems being reported for this, I wouldn't worry about this, the effort involved is non-trivial as you are quickly finding out :) good luck, 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: [2.6 patch] #if 0 dma_async_memcpy_buf_to_buf()
>From: Alan Cox [mailto:[EMAIL PROTECTED] >Sent: Tuesday, January 01, 2008 6:26 AM >To: Adrian Bunk >Cc: Nelson, Shannon; Williams, Dan J; linux-kernel@vger.kernel.org >Subject: Re: [2.6 patch] #if 0 dma_async_memcpy_buf_to_buf() > >On Tue, 1 Jan 2008 15:49:24 +0200 >Adrian Bunk <[EMAIL PROTECTED]> wrote: > >> This patch #if 0's the unused dma_async_memcpy_buf_to_buf(). >> >> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > >NAK. Yet again you are trying to remove bits of APIs in ways that make >no sense. > Yes, this should be a NAK. Thank you Alan. sln -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Get physical MAC address
On Mon, Dec 31, 2007 at 12:39:11PM +0700, Theewara Vorakosit wrote: > Hello, > > I get MAC address from ioctl. However, ifconfig can change this MAC > address. Can I get a real physical MAC address of the NIC? yes. It's ETHTOOL_GPERMADDR to the ethtool ioctl. case ETHTOOL_GPERMADDR: rc = ethtool_get_perm_addr(dev, useraddr); break; When the driver is first loaded, before ifconfig can change the MAC address, the existing (permanent) MAC address is stored away, able to be retrieved via this ioctl. Jon Wetzel, a Dell intern of a few summers ago, wrote the code and was able to have it included. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] ide: use MODULE_VERSION()
On Tue, Jan 01, 2008 at 09:32:36PM -0500, Jon Masters wrote: > On Tue, 2008-01-01 at 19:33 +0100, Bartlomiej Zolnierkiewicz wrote: > > > On the second thought: maybe we will be better off with limiting > > MODULE_VERSION() to the device drivers and the IDE core module for now, > > and just removing all these private version numbers from host drivers > > (with one or two exceptions they are not printed or exported currently, > > moreover exceptions are the cases like stale version numbers from 199x)? > > Things like checkpatch could help advise people to bump the version > number, but it's a bit iffy. Matt D. actually uses the special source > version modinfo for DKMS - which is different - but it makes me wonder > whether dynamically generating a version based on source SHA1 wouldn't > be a better idea in most cases than an outdated hard-coded one. We've got that already, it's called 'srcversion', and it's a CRC32 IIRC after some limited parsing to let it ignore whitspace changes and comment changes only. $ modinfo dell_rbu | grep version version:3.2 srcversion: 1D4815D7D6FBEE6612F3C18 DKMS uses the srcversion if present recognize an exact match. srcversions can't be tested for anything <> though, only =. DKMS also uses the version field as supplied by MODULE_VERSION() to try to determine older-vs-newer modules. On occasion we've had to release updated "fixed" kernel modules, in which case we bump the value in MODULE_VERSION() slightly (typically append .1 or something similar) so the "fixed" module version compares higher. Such version fields aren't generally used with stock kernel.org kernels (where users can be expected to upgrade to a later stock kernel), but for users of a distro kernel where we need to fix a module without forcing the user to upgrade the whole kernel. -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [CFT] Code clarification patch to Kprobes arch code
On Tue, Jan 01, 2008 at 04:19:43PM +0100, Ingo Molnar wrote: > > * Quentin Barnes <[EMAIL PROTECTED]> wrote: > > > Since people are discussing some x86 Kprobes code cleanup, I thought I > > would contribute a small change as well. When developing the Kprobes > > arch code for ARM, I ran across some code found in x86 and s390 > > Kprobes arch code which I didn't consider as good as it could be. > > > > Once I figured out what the code was doing, I changed the code for ARM > > Kprobes to work the way I felt was more appropriate. I've tested the > > code this way in ARM for about a year and would like to push the same > > change to the other affected architectures. > > thanks Quentin, it looks good to me and i've applied the x86 bit to > x86.git. (find the merged patch attached below) > > small note: > > > @@ -654,12 +655,12 @@ int __kprobes kprobe_exceptions_notify(struct > > notifier_block *self, > > ret = NOTIFY_STOP; > > your email client apparently line-wrapped this portion of the patch - i > fixed it up manually (wasnt a big issue). Please see > Documentation/email-clients.txt about how to set up your email client. > > Ingo > > > > Subject: Code clarification patch to Kprobes arch code > From: "Quentin Barnes" <[EMAIL PROTECTED]> > > When developing the Kprobes arch code for ARM, I ran across some code > found in x86 and s390 Kprobes arch code which I didn't consider as > good as it could be. > > Once I figured out what the code was doing, I changed the code > for ARM Kprobes to work the way I felt was more appropriate. > I've tested the code this way in ARM for about a year and would > like to push the same change to the other affected architectures. > > The code in question is in kprobe_exceptions_notify() which > does: > > /* kprobe_running() needs smp_processor_id() */ > preempt_disable(); > if (kprobe_running() && > kprobe_fault_handler(args->regs, args->trapnr)) > ret = NOTIFY_STOP; > preempt_enable(); > > > For the moment, ignore the code having the preempt_disable()/ > preempt_enable() pair in it. > > The problem is that kprobe_running() needs to call smp_processor_id() > which will assert if preemption is enabled. That sanity check by > smp_processor_id() makes perfect sense since calling it with preemption > enabled would return an unreliable result. > > But the function kprobe_exceptions_notify() can be called from a > context where preemption could be enabled. If that happens, the > assertion in smp_processor_id() happens and we're dead. So what > the original author did (speculation on my part!) is put in the > preempt_disable()/preempt_enable() pair to simply defeat the check. > > Once I figured out what was going on, I considered this an > inappropriate approach. If kprobe_exceptions_notify() is called > from a preemptible context, we can't be in a kprobe processing > context at that time anyways since kprobes requires preemption to > already be disabled, so just check for preemption enabled, and if > so, blow out before ever calling kprobe_running(). I wrote the ARM > kprobe code like this: > > /* To be potentially processing a kprobe fault and to >* trust the result from kprobe_running(), we have >* be non-preemptible. */ > if (!preemptible() && kprobe_running() && > kprobe_fault_handler(args->regs, args->trapnr)) > ret = NOTIFY_STOP; > > > The above code has been working fine for ARM Kprobes for a year. > So I changed the x86 code (2.6.24-rc6) to be the same way and ran > the Systemtap tests on that kernel. As on ARM, Systemtap on x86 > comes up with the same test results either way, so it's a neutral > external functional change (as expected). > > This issue has been discussed previously on linux-arm-kernel and the > Systemtap mailing lists. Pointers to the by base for the two > discussions: > http://lists.arm.linux.org.uk/lurker/message/20071219.223225.1f5c2a5e.en.html > http://sourceware.org/ml/systemtap/2007-q1/msg00251.html > > Signed-off-by: Quentin Barnes <[EMAIL PROTECTED]> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Tested on x86. Acked-by: Ananth N Mavinakayahanalli <[EMAIL PROTECTED]> > --- > arch/x86/kernel/kprobes.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > Index: linux-x86.q/arch/x86/kernel/kprobes.c > === > --- linux-x86.q.orig/arch/x86/kernel/kprobes.c > +++ linux-x86.q/arch/x86/kernel/kprobes.c > @@ -44,6 +44,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -951,12 +952,14 @@ int __kprobes kprobe_exceptions_notify(s > ret = NOTIFY_STOP; > break; > case DIE_GPF: > -
Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
Ingo Molnar <[EMAIL PROTECTED]> writes:
> [...] Firstly, why on earth does a full format string have to be
> passed in for something as simple as a CPU id? This way we basically
> codify it forever that tracing _has_ to be expensive when
> enabled. [...]
FWIW, I'm not keen about the format strings either, but they don't
constitute a performance hit beyond an additional parameter. It does
not need to actually get parsed at run time.
>[...]
> Secondly, the inlined overhead of trace_mark() is still WAY too large:
>
> if (unlikely(__mark_##name.state)) {\
> [...]
> } \
Note that this is for the unoptimized case. The immediate-value code
is better. I have still yet to see some good measurements of how much
the overheads of the various variants are, however. It's only fair to
gather these numbers and continue the debate with them in hand.
> Whatever became of the obvious suggestion that i outlined years ago,
> to have a _single_ trace call instruction and to _patch out_ the
> damn marker calls by default? [...] only leaving a ~5-byte NOP
> sequence behind them (and some minimal disturbance to the variables
> the tracepoint accesses). [...]
This has been answered several times before. It's because the marker
parameters have to be (conditionally) evaluated and pushed onto a call
frame. It's not just a call that would need being nop'd, but a whole
function call setup/teardown sequence, which itself can be interleaved
with adjacent code.
- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata_nv + ADMA + Samsung disk problem
Robert Hancock wrote: >> This is kind of a longstanding problem which has been partially worked >> around, but it seems not entirely. This is what I had diagnosed some >> time ago: >> >> "recently, some issues cropped up with command timeouts when a cache >> flush command was immediately followed by an NCQ write. In this case, >> sometimes when the NCQ write was issued, the status register changed >> from 0x500 (Stopped and Idle) to 0x400 (Stopped) as it normally >> appears to, however it seems like the controller would get hung in >> that state, and we would time out with no notifiers set, the gen_ctl >> register not indicating interrupt status, and the CPB response flags >> still 0 as we left them, seemingly indicating the controller hasn't >> done anything with it. Then, when the error handler kicks in we clear >> the GO bit to put it back into register mode, but the Legacy flag in >> the status register doesn't get set (or at least it takes longer than >> 1 microsecond). Finally when we do an ADMA channel reset that seems to >> get it responding again, until this happens the next time. >> >> From some experimentation, I found that when we are issuing a NCQ >> command when the last command was non-NCQ, or vice versa, if I added in >> a delay of 20 microseconds between setting up the CPB and writing to the >> append register, the problem appeared to go away. Problem is I don't >> know if that's because it actually needs this delay, or because it >> changes the timing so that it happens to work even though we're doing >> something wrong, there's some event we're not waiting for, etc. >> >> I've now verified that no switches between ADMA and register mode >> occur near the time of these timeouts. Neither are we reading or >> writing any of the ATA shadow registers while we're in ADMA mode." >> >> It seems likely that this is what is happening here (a switch from an >> NCQ command to a non-NCQ command, then the non-NCQ times out). It >> could be in some cases the 20 microsecond delay is not enough. But it >> seems bogus that we should need such an arbitrary delay in the first >> place. >> >> The question I had for NVIDIA regarding this that I never got answered >> was, is there any reason why we would need a delay when switching >> between NCQ and non-NCQ commands on ADMA, and if not, is there any >> known cause that could cause the controller to get into this seemingly >> locked-up state? > > Well, I guess I did sort of get an answer, but the only theory was that > the flush and the NCQ commands were being overlapped, which shouldn't be > possible (the libata core guarantees that, and if it didn't work it > would affect all controllers). > > I'm kind of wondering if there's something funny going on with the > notifier register stuff, which is supposed to tell us what commands have > completed. We don't really use it at all (we had some problems with > missed completions, etc. when I tried using it, also it doesn't work if > ATAPI is enabled on the other port on the controller, apparently). I > know these controllers will do strange things like not signalling > interrupts for later events if you don't clear the notifiers in just the > right way (that being mostly determined by trial and error). > > Or, maybe somehow the flush is getting issued before the controller is > really "ready" for it somehow (it's not finished cleaning up after > preceding NCQ command). > > It's pretty hard for me to figure out which of the above might be the > case, especially without access to the detailed controller documentation.. Thanks a lot for the detailed explanation. Nvidia ppl, any ideas? FLUSH is used regularly. We really need to fix this. -- 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: sata_nv + ADMA + Samsung disk problem
Robert Hancock wrote: Tejun Heo wrote: [cc'ing Robert Hancock and NVidia people] Whole thread can be read from the following URL. http://thread.gmane.org/gmane.linux.ide/21710 In a nutshell, with ADMA enabled, FLUSH_EXT occasionally times out. I first suspected faulty disk (reallocation failure on flush) but SMART reports nothing suspicious and w/ ADMA disabled, the drive works just fine. On a side note, on 2.6.22.1, SMART fails from time to time but the problem went away on 2.6.24-rc6. This was apparently fixed during that period. I guess we can ignore this for now. Thanks. This is kind of a longstanding problem which has been partially worked around, but it seems not entirely. This is what I had diagnosed some time ago: "recently, some issues cropped up with command timeouts when a cache flush command was immediately followed by an NCQ write. In this case, sometimes when the NCQ write was issued, the status register changed from 0x500 (Stopped and Idle) to 0x400 (Stopped) as it normally appears to, however it seems like the controller would get hung in that state, and we would time out with no notifiers set, the gen_ctl register not indicating interrupt status, and the CPB response flags still 0 as we left them, seemingly indicating the controller hasn't done anything with it. Then, when the error handler kicks in we clear the GO bit to put it back into register mode, but the Legacy flag in the status register doesn't get set (or at least it takes longer than 1 microsecond). Finally when we do an ADMA channel reset that seems to get it responding again, until this happens the next time. From some experimentation, I found that when we are issuing a NCQ command when the last command was non-NCQ, or vice versa, if I added in a delay of 20 microseconds between setting up the CPB and writing to the append register, the problem appeared to go away. Problem is I don't know if that's because it actually needs this delay, or because it changes the timing so that it happens to work even though we're doing something wrong, there's some event we're not waiting for, etc. I've now verified that no switches between ADMA and register mode occur near the time of these timeouts. Neither are we reading or writing any of the ATA shadow registers while we're in ADMA mode." It seems likely that this is what is happening here (a switch from an NCQ command to a non-NCQ command, then the non-NCQ times out). It could be in some cases the 20 microsecond delay is not enough. But it seems bogus that we should need such an arbitrary delay in the first place. The question I had for NVIDIA regarding this that I never got answered was, is there any reason why we would need a delay when switching between NCQ and non-NCQ commands on ADMA, and if not, is there any known cause that could cause the controller to get into this seemingly locked-up state? Well, I guess I did sort of get an answer, but the only theory was that the flush and the NCQ commands were being overlapped, which shouldn't be possible (the libata core guarantees that, and if it didn't work it would affect all controllers). I'm kind of wondering if there's something funny going on with the notifier register stuff, which is supposed to tell us what commands have completed. We don't really use it at all (we had some problems with missed completions, etc. when I tried using it, also it doesn't work if ATAPI is enabled on the other port on the controller, apparently). I know these controllers will do strange things like not signalling interrupts for later events if you don't clear the notifiers in just the right way (that being mostly determined by trial and error). Or, maybe somehow the flush is getting issued before the controller is really "ready" for it somehow (it's not finished cleaning up after preceding NCQ command). It's pretty hard for me to figure out which of the above might be the case, especially without access to the detailed controller documentation.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 errors detected by checkpatch.pl on nmi_int.c
On Tue 1.Jan'08 at 17:05:49 -0800, Carlos R. Mafra wrote: > This patch fixes most errors detected by checkpatch.pl. > [...] As pointed out by Jesper Juhl, my patch was not inlined :-( I did set up mutt especially to send this patch (instead of thunderbird), and I did test it before sending (and it applied correctly). However I did not notice that it was not inlined because mutt automatically displays attachments inline. Do you want me to send it again (inlined) and with the Reviewed-by: line? Thanks in advance, Carlos PS: The version I sent to lkml was a new version, containing also the two-empty-lines -> one-empty-line cleanup suggested by you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_nv + ADMA + Samsung disk problem
Tejun Heo wrote: [cc'ing Robert Hancock and NVidia people] Whole thread can be read from the following URL. http://thread.gmane.org/gmane.linux.ide/21710 In a nutshell, with ADMA enabled, FLUSH_EXT occasionally times out. I first suspected faulty disk (reallocation failure on flush) but SMART reports nothing suspicious and w/ ADMA disabled, the drive works just fine. On a side note, on 2.6.22.1, SMART fails from time to time but the problem went away on 2.6.24-rc6. This was apparently fixed during that period. I guess we can ignore this for now. Thanks. This is kind of a longstanding problem which has been partially worked around, but it seems not entirely. This is what I had diagnosed some time ago: "recently, some issues cropped up with command timeouts when a cache flush command was immediately followed by an NCQ write. In this case, sometimes when the NCQ write was issued, the status register changed from 0x500 (Stopped and Idle) to 0x400 (Stopped) as it normally appears to, however it seems like the controller would get hung in that state, and we would time out with no notifiers set, the gen_ctl register not indicating interrupt status, and the CPB response flags still 0 as we left them, seemingly indicating the controller hasn't done anything with it. Then, when the error handler kicks in we clear the GO bit to put it back into register mode, but the Legacy flag in the status register doesn't get set (or at least it takes longer than 1 microsecond). Finally when we do an ADMA channel reset that seems to get it responding again, until this happens the next time. From some experimentation, I found that when we are issuing a NCQ command when the last command was non-NCQ, or vice versa, if I added in a delay of 20 microseconds between setting up the CPB and writing to the append register, the problem appeared to go away. Problem is I don't know if that's because it actually needs this delay, or because it changes the timing so that it happens to work even though we're doing something wrong, there's some event we're not waiting for, etc. I've now verified that no switches between ADMA and register mode occur near the time of these timeouts. Neither are we reading or writing any of the ATA shadow registers while we're in ADMA mode." It seems likely that this is what is happening here (a switch from an NCQ command to a non-NCQ command, then the non-NCQ times out). It could be in some cases the 20 microsecond delay is not enough. But it seems bogus that we should need such an arbitrary delay in the first place. The question I had for NVIDIA regarding this that I never got answered was, is there any reason why we would need a delay when switching between NCQ and non-NCQ commands on ADMA, and if not, is there any known cause that could cause the controller to get into this seemingly locked-up state? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: gitignore arch/x86/vdso files
I'd make those *.lds or at least vdso*.lds, since it is more likely there will be other variants than that there will be any .lds source files (since they are .lds.S instead). Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc6-git7: Reported regressions from 2.6.23
On Tue, 2008-01-01 at 14:26 -0800, Linus Torvalds wrote: > > Subject : Problems on booting > > Submitter : "werner" <[EMAIL PROTECTED]> > > Date: 2007-12-22 14:29 > > References : http://lkml.org/lkml/2007/12/22/110 > > http://bugzilla.kernel.org/show_bug.cgi?id=9621 > > Handled-By : > > Patch : > > Hmm. I assume the "-git6" and "-git7" are 2.6.24-rc4-gitX, ie commits > > - 2.6.24-rc5-git6: 3e3b3916a9c5c28a16528585478de19fea59816b > - 2.6.24-rc5-git7: fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 > > and doing a > > gitk 3e3b3916a9..fbdcf18df7 > > does show a SCSI merge, and two commits that touch drivers/scsi/initio.*. > > James, Alan and Boaz, ideas? Initio has been suspected broken even after all the bug fixes (I actually said that in the last pull request). We just couldn't get a tester to confirm the suspicion. The commits were for known issues but it proved impossible to get any of the reporters to verify. Could you direct this poster to linux-scsi and we'll see if we can finger the root cause (which will be difficult to do without getting a boot trace). James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] net/x25: Add missing x25_neigh_put
From: Julia Lawall <[EMAIL PROTECTED]> Date: Tue, 1 Jan 2008 22:07:04 +0100 (CET) > The function x25_get_neigh increments a reference count. At the point of > the second goto out, the result of calling x25_get_neigh is only stored in > a local variable, and thus no one outside the function will be able to > decrease the reference count. Thus, x25_neigh_put should be called before > the return in this case. Patch applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] the scheduled shaper removal
From: Alan Cox <[EMAIL PROTECTED]> Date: Tue, 1 Jan 2008 14:24:30 + > On Tue, 1 Jan 2008 15:47:35 +0200 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > This patch contains the scheduled removal of the shaper driver. > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > Acked-by: Alan Cox <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_nv + ADMA + Samsung disk problem
[cc'ing Robert Hancock and NVidia people]
Whole thread can be read from the following URL.
http://thread.gmane.org/gmane.linux.ide/21710
In a nutshell, with ADMA enabled, FLUSH_EXT occasionally times out. I
first suspected faulty disk (reallocation failure on flush) but SMART
reports nothing suspicious and w/ ADMA disabled, the drive works just fine.
On a side note, on 2.6.22.1, SMART fails from time to time but the
problem went away on 2.6.24-rc6. This was apparently fixed during that
period. I guess we can ignore this for now.
Thanks.
Gabor Gombas wrote:
> Hi,
>
> Just FYI I've tried to enable ADMA again (now running 2.6.24-rc6) but
> the bug is still present:
>
> Jan 1 16:11:21 host kernel: ata7: EH in ADMA mode, notifier 0x0
> notifier_error 0x0 gen_ctl 0x1501000 status 0x400 next cpb count 0x0 next cpb
> idx 0x0
> Jan 1 16:11:21 host kernel: ata7: CPB 0: ctl_flags 0x9, resp_flags 0x0
> Jan 1 16:11:21 host kernel: ata7: timeout waiting for ADMA IDLE, stat=0x400
> Jan 1 16:11:21 host kernel: ata7: timeout waiting for ADMA LEGACY, stat=0x400
> Jan 1 16:11:21 host kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0
> action 0x2 frozen
> Jan 1 16:11:21 host kernel: ata7.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0
> tag 0
> Jan 1 16:11:21 host kernel: res 40/00:00:00:4f:c2/00:00:00:00:00/00
> Emask 0x4 (timeout)
> Jan 1 16:11:21 host kernel: ata7.00: status: { DRDY }
> Jan 1 16:11:21 host kernel: ata7: soft resetting link
> Jan 1 16:11:22 host kernel: ata7: SATA link up 3.0 Gbps (SStatus 123
> SControl 300)
> Jan 1 16:11:22 host kernel: ata7.00: configured for UDMA/133
> Jan 1 16:11:22 host kernel: ata7: EH complete
> Jan 1 16:11:22 host kernel: sd 6:0:0:0: [sdc] 488397168 512-byte hardware
> sectors (250059 MB)
> Jan 1 16:11:22 host kernel: sd 6:0:0:0: [sdc] Write Protect is off
> Jan 1 16:11:22 host kernel: sd 6:0:0:0: [sdc] Mode Sense: 00 3a 00 00
> Jan 1 16:11:22 host kernel: sd 6:0:0:0: [sdc] Write cache: enabled, read
> cache: enabled, doesn't support DPO or FUA
>
> Although this time the above happened more than 3 hours after boot
> which is much better than 2.6.22 was. In the past ~4 months ADMA was
> disabled and I never had any libata-related error messages.
>
> SMART does not show anything interesting:
>
> smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce
> Allen
> Home page is http://smartmontools.sourceforge.net/
>
> === START OF INFORMATION SECTION ===
> Model Family: SAMSUNG SpinPoint P120 series
> Device Model: SAMSUNG SP2504C
> Serial Number:XX
> Firmware Version: VT100-33
> User Capacity:250,059,350,016 bytes
> Device is:In smartctl database [for details use: -P show]
> ATA Version is: 7
> ATA Standard is: ATA/ATAPI-7 T13 1532D revision 4a
> Local Time is:Tue Jan 1 17:38:21 2008 CET
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
>
> === START OF READ SMART DATA SECTION ===
> SMART overall-health self-assessment test result: PASSED
>
> General SMART Values:
> Offline data collection status: (0x82) Offline data collection activity
> was completed without error.
> Auto Offline Data Collection: Enabled.
> Self-test execution status: ( 0) The previous self-test routine
> completed
> without error or no self-test has ever
> been run.
> Total time to complete Offline
> data collection: (4867) seconds.
> Offline data collection
> capabilities: (0x5b) SMART execute Offline immediate.
> Auto Offline data collection on/off
> support.
> Suspend Offline collection upon new
> command.
> Offline surface scan supported.
> Self-test supported.
> No Conveyance Self-test supported.
> Selective Self-test supported.
> SMART capabilities:(0x0003) Saves SMART data before entering
> power-saving mode.
> Supports SMART auto save timer.
> Error logging capability:(0x01) Error logging supported.
> General Purpose Logging supported.
> Short self-test routine
> recommended polling time: ( 1) minutes.
> Extended self-test routine
> recommended polling time: ( 81) minutes.
>
> SMART Attributes Data Structure revision number: 16
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
> WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x000f 100 10
Re: 2.6.24-rc6-git7: Reported regressions from 2.6.23
On 2008.01.01 22:02:57 +, Rafael J. Wysocki wrote: > Subject : linux-2.6.24-rcX regression / > xserver-xorg-video-intel / Q35 > Submitter : Harald Welte <[EMAIL PROTECTED]> > Date : 2007-12-22 04:37 > References: http://lkml.org/lkml/2007/12/21/269 > http://bugzilla.kernel.org/show_bug.cgi?id=9618 > Handled-By: Zhenyu Wang <[EMAIL PROTECTED]> > Patch : This is resolved by turning on CONFIG_DMAR_GFX_WA. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Get physical MAC address
On Jan 01, 2008, at 21:42:18, Jon Masters wrote: On Mon, 2007-12-31 at 12:39 +0700, Theewara Vorakosit wrote: I get MAC address from ioctl. However, ifconfig can change this MAC address. Can I get a real physical MAC address of the NIC? Forgive me reading into your mail...this smells a bit like some kind of licensing/compliance thing. Just bear in mind that using the MAC to verify the identity of a machine is utterly useless and pointless - anyone can trivially fool your software[0] to see what it "wants". Not necessarily; I can easily see distros wanting to have a "Restore defaults" button in their network config windows which also includes restoring the default MAC address to the NIC. It should also be pointed out that anybody with one of a selection of re-flashable NICS (or NICS with removable EEPROMS) can easily change the MAC address on their NIC. Other alternatives includes renaming eth0 to mynet0 and creating a downed dummy interface called "eth0" with the desired MAC addr. [0] We used to have to do far worse kludgery in college, in order to prevent the silly powers that be who "banned" network cards other than those made by one manufacturer from being used on their little network. Well for basically any userspace-level check, all it takes is somebody who knows ASM and has about 5 minutes to track down the problematic branch instructions. Then they just have to write a 10- line GDB script which starts the program, traps the appropriate instructions, and then changes a "0" to a "1" (or vice versa) before the conditional branch. On Windows it's vaguely practical (albeit crash-prone) to load a kernel hack which prevents your program from being debugged, but under Linux it's effectively impossible Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 25/26] [REVISED] atl1: add NAPI support
From: "Joonwoo Park" <[EMAIL PROTECTED]> Date: Wed, 2 Jan 2008 11:56:36 +0900 > Since we had reached a consensus on fixing it without each drivers > modifications, there is no best solution for that problem for > now. I'm expecting Dave or others work for net-core. > (http://lkml.org/lkml/2007/12/20/600) Indeed, I really hope to try and close this out very soon. Sorry for taking so long. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: provide a DMI based port 0x80 I/O delay override
On 31-12-07 16:56, Alan Cox wrote: Okay. Am about to go stuff my face with new years celebrations but will definitely try to make that old WD8003 hickup. Have fun. Is it an 8390 or an 83905 ? A DP8390BN. And I have a DP8390CN on a 3Com Etherlink II. The NE1000 has a DP83901AV, my new-fangled Networth combo WD/NE cards DP83905s. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 25/26] [REVISED] atl1: add NAPI support
Hi Jay,
+ if ((work_done < budget) || !netif_running(poll_dev)) {
+quit_polling:
+ netif_rx_complete(poll_dev, napi);
+
+ if (!test_bit(__ATL1_DOWN, &adapter->flags))
+ atlx_irq_enable(adapter);
+ }
Not enough :)
If netif_running() is false, it can make problem.
The problem occurs calling netif_rx_complete with work_done == budget.
If do that, net_rx_action would do poll list double deletion.
Since we had reached a consensus on fixing it without each drivers
modifications, there is no best solution for that problem for
now. I'm expecting Dave or others work for net-core.
(http://lkml.org/lkml/2007/12/20/600)
IMHO, atl1_clean should wait for work_done != budget even though netif_running
is false at this time.
At least, It would not make oops.
Thanks,
Joonwoo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] Nuke duplicate header from sysctl.c
From: Jesper Juhl <[EMAIL PROTECTED]> Don't include linux/security.h twice in kernel/sysctl.c Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- sysctl.c |1 - 1 file changed, 1 deletion(-) diff --git a/kernel/sysctl.c b/kernel/sysctl.c index c68f68d..01b12c3 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -37,7 +37,6 @@ #include #include #include -#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Nuke a duplicate include from profile.c
From: Jesper Juhl <[EMAIL PROTECTED]> Remove duplicate inclusion of linux/profile.h from kernel/profile.c Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- profile.c |1 - 1 file changed, 1 deletion(-) diff --git a/kernel/profile.c b/kernel/profile.c index 5e95330..ffaebea 100644 --- a/kernel/profile.c +++ b/kernel/profile.c @@ -20,7 +20,6 @@ #include #include #include -#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Nuke duplicate include from printk.c
From: Jesper Juhl <[EMAIL PROTECTED]> Remove the duplicate inclusion of linux/jiffies.h from kernel/printk.c Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- printk.c |1 - 1 file changed, 1 deletion(-) diff --git a/kernel/printk.c b/kernel/printk.c index 89011bf..b4bca0d 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -32,7 +32,6 @@ #include #include #include -#include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Nuke a few duplicate includes
Including the same header twice (or more) in a .c file, outside any #ifdef's and whatnot, serves no purpose except generating more work for the compiler, so here are 3 patches that get rid of some pointless duplicate includes. Kind regards, Jesper Juhl <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Get physical MAC address
On Mon, 2007-12-31 at 12:39 +0700, Theewara Vorakosit wrote: > I get MAC address from ioctl. However, ifconfig can change this MAC > address. Can I get a real physical MAC address of the NIC? Forgive me reading into your mail...this smells a bit like some kind of licensing/compliance thing. Just bear in mind that using the MAC to verify the identity of a machine is utterly useless and pointless - anyone can trivially fool your software[0] to see what it "wants". Jon. [0] We used to have to do far worse kludgery in college, in order to prevent the silly powers that be who "banned" network cards other than those made by one manufacturer from being used on their little network. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] crash - modules l440gx and parport_pc interfere
On Tue, 2008-01-01 at 20:57 +0100, [EMAIL PROTECTED] wrote: > there seems some weird interference between l440gx and parport_pc modules > > i can reproduceable crash my box by either: > > modprobe parport_pc;modprobe l440gx;rmmod parport_pc > > or > > modprobe l440gx; modprobe parport_pc;rmmod parport_pc Stinks of a locking problem. Have you compiled in any of the kernel debugging features? Did you build the kernel, or is it a vendor one? Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] ide: use MODULE_VERSION()
On Tue, 2008-01-01 at 19:33 +0100, Bartlomiej Zolnierkiewicz wrote: > On the second thought: maybe we will be better off with limiting > MODULE_VERSION() to the device drivers and the IDE core module for now, > and just removing all these private version numbers from host drivers > (with one or two exceptions they are not printed or exported currently, > moreover exceptions are the cases like stale version numbers from 199x)? Things like checkpatch could help advise people to bump the version number, but it's a bit iffy. Matt D. actually uses the special source version modinfo for DKMS - which is different - but it makes me wonder whether dynamically generating a version based on source SHA1 wouldn't be a better idea in most cases than an outdated hard-coded one. Comments? Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 06/12] pci : Use mutex instead of semaphore in driver core
On Dec 29, 2007 7:42 PM, Stefan Richter <[EMAIL PROTECTED]> wrote: > Matthew Wilcox wrote: > > Patches should be self-contained for ease of bisecting. I can't tell > > whether this patch is correct or not because you haven't included all > > the other places that need to change at the same time as this. > > I think a broken-up patch series isn't totally wrong to do for a first > look at these RFC patches. Of course the series needs to become a > single patch before it is committed to a tree whose history needs to > support bijection, e.g. -mm. > > However, Dave's postings lack a References: header which refer to his > 00/12 posting. Thanks. I agree with you, for bitsection it should be a single one. > > (Also, a bonus in the 00/12 posting would be a listing of all patch > titles in the series and the total diffstat of the series, but nearly > nobody does this.) Your sugestion is better. And, andrew recommends not to use 00/xx introduction email in series in his "The perfect patch": http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt > -- > Stefan Richter > -=-=-=== ==-- ===-= > http://arcgraph.de/sr/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: provide a DMI based port 0x80 I/O delay override.
Christer Weinigel wrote: Both 0xed and 0xf0 are mapped to internal functions on the AMD Elan SC400 processor. It is an AMD 486 based system on a chip and since AMD just knew that it would never have a math coprocessor, they reused the 0xf0-0xf2 range for the PCMCIA controller. I guess the AMD Elan SC500 will have similar problems. I seem to recall that back when I was working with the Elan SC400 (sometime around 1998?) there were discussions about finding an alternate delay port because outb to 0x80 messed up the debug port. I think the Elan stopped those discussions because just about every port on the Elan was reused for some alternate purpose. Yeah, the Elan is not supportable anyway without a CONFIG option (it's broken in so many ways), so it doesn't really apply. It's a fuckwit design. -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: asm-x86/byteorder.h: clean up for userspace
Adrian Bunk wrote: Userspace either has to #define CONFIG_X86_BSWAP or it'll get the slow versions of these functions... Leaking CONFIG_ variables to userspace is not really funny - I remember e.g. what tricks MySQL does (did?) for (ab)using asm-i386/atomic.h in userspace. True. CONFIG_X86_BSWAP isn't appropriate for userspace anyway, userspace needs to use the appropriate gcc intrinsics for 486+. -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: Get physical MAC address
On Wed, 02 Jan 2008 00:07:28 +0100 Bernd Petrovitsch <[EMAIL PROTECTED]> wrote: > On Mon, 2007-12-31 at 12:39 +0700, Theewara Vorakosit wrote: > [...] > > I get MAC address from ioctl. However, ifconfig can change this MAC > > address. Can I get a real physical MAC address of the NIC? > > - You can get the initial MAC address right after bootup before anyone > changes it. > - Some (if not many if not all) of the drivers output it on > driver initialization time so you could read it from `dmesg` or > some /var/log/messages or . > There is no "get initial MAC address" ioctl (but it's not that > complicated to implement it). > > Bernd There is already ethtool interface to get what you want (ETHTOOL_GPERMADDR) -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] the scheduled 'time' option removal
On Tue, 1 Jan 2008 15:46:56 +0200 Adrian Bunk wrote:
> This patch contains the scheduled removal of the 'time' option.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Thanks. Looks good except that Documentation/kernel-parameters.txt
needs a patch also: delete these 3 lines:
timeShow timing data prefixed to each printk message line
[deprecated, see 'printk.time']
then I will Ack it.
> ---
>
> Documentation/feature-removal-schedule.txt |8
> kernel/printk.c| 13 -
> 2 files changed, 21 deletions(-)
>
> c0ea16c447460698c0e85963310c38fa051f0e23
> diff --git a/Documentation/feature-removal-schedule.txt
> b/Documentation/feature-removal-schedule.txt
> index 20c4c8b..93aac19 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -233,10 +233,2 @@ Who: Jean Delvare <[EMAIL PROTECTED]>
> ---
> -
> -What:'time' kernel boot parameter
> -When:January 2008
> -Why: replaced by 'printk.time=' so that printk timestamps can be
> - enabled or disabled as needed
> -Who: Randy Dunlap <[EMAIL PROTECTED]>
> -
>
>
> diff --git a/kernel/printk.c b/kernel/printk.c
> index a30fe33..296c4ea 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -560,15 +560,2 @@ static int printk_time = 0;
> module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
> -
> -static int __init printk_time_setup(char *str)
> -{
> - if (*str)
> - return 0;
> - printk_time = 1;
> - printk(KERN_NOTICE "The 'time' option is deprecated and "
> - "is scheduled for removal in early 2008\n");
> - printk(KERN_NOTICE "Use 'printk.time=' instead\n");
> - return 1;
> -}
> -
> -__setup("time", printk_time_setup);
---
~Randy
desserts: http://www.xenotime.net/linux/recipes/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 linux-acpi] Correct wakeup set error and append a new column PCI ID
On Wed, 2008-01-02 at 00:20 +0100, Pavel Machek wrote: > Hi! > > > /proc/acpi/wakeup is also case-sensitive, case-insensitive is better. > > Why? A user uses device bus id like 'C093' to enable or disable wakeup of the device, for example echo "C093" > /proc/acpi/wakeup but i think "c093" should also be ok. i.e. "echo 'c093' > /proc/acpi/wakeup" should have the same result as "echo 'C093' > /proc/acpi/wakeup". That is to say, it should be case-insensitive. > > > In addtion, this patch appends a new column 'PCI ID' to /proc/acpi/wakeup > > , the user can use it to get the corresponding device name very > > conveniently because PCI ID is a unique identifier and platform-independent. > > Userland interface change...? Not at all, i didn't find any userland application assumes /proc/acpi/wakeup must be that kind of format. In fact, /proc output is always changing. :-) > > Maybe this file should be left for compatibility and we should present > something reasonable in /sys? Can't you already get PCI ID from sysfs > node? PCI ID can be gotten from sysfs, but it is a unique identifier for a device, a user can get device name from /usr/share/hwdata/pci.ids in any dstribution by PCI ID, he/she is unnecessary to use bus number to get device name, bus number is platform-specific, but PCI ID is platform-independent. > Pavel > > > [EMAIL PROTECTED] ~]# cat /proc/acpi/wakeup > > Device S-state Status Sysfs node > > C093 S5 disabled pci::00:1e.0 > > C0E8 S3 disabled pci::00:1d.0 > > C0EF S3 disabled pci::00:1d.1 > > C0F0 S3 disabled pci::00:1d.2 > > C0F1 S3 disabled pci::00:1d.3 > > C0F2 S3 disabled pci::00:1d.7 > > C0F9 S0 disabled pci::00:1c.0 > > C21D S0 disabled pci::08:00.0 > > C109 S5 disabled pci::00:1c.1 > > C228 S5 disabled pci::10:00.0 > > C10F S5 disabled pci::00:1c.3 > > C229 S5 disabled > > [EMAIL PROTECTED] ~]# > > > > After applying this patch, the output is: > > > > [EMAIL PROTECTED] ~]# cat /proc/acpi/wakeup > > Device S-state Status Sysfs node PCI ID > > C093 S5 disabled pci::00:1e.0 0x2448 > > C0E8 S3 disabled pci::00:1d.0 0x27c8 > > C0EF S3 disabled pci::00:1d.1 0x27c9 > > C0F0 S3 disabled pci::00:1d.2 0x27ca > > C0F1 S3 disabled pci::00:1d.3 0x27cb > > C0F2 S3 disabled pci::00:1d.7 0x27cc > > C0F9 S0 disabled pci::00:1c.0 0x27d0 > > C21D S0 disabled pci::08:00.0 0x16fd > > C109 S5 disabled pci::00:1c.1 0x27d2 > > C228 S5 disabled pci::10:00.0 0x4222 > > C10F S5 disabled pci::00:1c.3 0x27d6 > > C229 S5 disabled > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] linux/ufs_fs.h: use __u64 for userspace
On Tue, Jan 01, 2008 at 08:51:40PM -0500, Mike Frysinger wrote: > Fix the ufs_inotofsba macro to use __u64 rather than u64 since this is > exported to userspace. > > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> > --- > diff --git a/include/linux/ufs_fs.h b/include/linux/ufs_fs.h > index 10b854d..35b6e59 100644 > --- a/include/linux/ufs_fs.h > +++ b/include/linux/ufs_fs.h > @@ -225,7 +225,7 @@ typedef __u16 __bitwise __fs16; > */ > #define ufs_inotocg(x) ((x) / uspi->s_ipg) > #define ufs_inotocgoff(x) ((x) % uspi->s_ipg) > -#define ufs_inotofsba(x)(((u64)ufs_cgimin(ufs_inotocg(x))) + > ufs_inotocgoff(x) / uspi->s_inopf) > +#define ufs_inotofsba(x)(((__u64)ufs_cgimin(ufs_inotocg(x))) + > ufs_inotocgoff(x) / uspi->s_inopf) > #define ufs_inotofsbo(x)((x) % uspi->s_inopf) But userspace anyway can't use them since it doesn't know what "uspi" is, so you should better reduce the userspace visibility of this header. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix errors detected by checkpatch.pl on nmi_int.c
On 02/01/2008, Carlos R. Mafra <[EMAIL PROTECTED]> wrote: > This patch fixes most errors detected by checkpatch.pl. > > errors lines of code errors/KLOC > arch/x86/oprofile/nmi_int.c (after) 1 461 2.1 > arch/x86/oprofile/nmi_int.c (before) 60 477 125.7 > > No code changed. > > size: >textdata bss dec hex filename >2675 264 4723411 d53 nmi_int.o.after >2675 264 4723411 d53 nmi_int.o.before > > md5sum: > 847aea0cc68fe1a2b5e7019439f3b4dd nmi_int.o.after > 847aea0cc68fe1a2b5e7019439f3b4dd nmi_int.o.before > > Signed-off-by: Carlos R. Mafra <[EMAIL PROTECTED]> > Looks good to me (except that an inline patch instead of an attached one would have been nice ;-) Kills some trailing whitespace, does some CodingStyle cleanups, is nicely confined to one file, doesn't (as far as I can tell) change the way the code works, makes checkpatch less noisy. All good. Feel free to add Reviewed-by: Jesper Juhl <[EMAIL PROTECTED]> if you like. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] linux/ufs_fs.h: use __u64 for userspace
Fix the ufs_inotofsba macro to use __u64 rather than u64 since this is exported to userspace. Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> --- diff --git a/include/linux/ufs_fs.h b/include/linux/ufs_fs.h index 10b854d..35b6e59 100644 --- a/include/linux/ufs_fs.h +++ b/include/linux/ufs_fs.h @@ -225,7 +225,7 @@ typedef __u16 __bitwise __fs16; */ #defineufs_inotocg(x) ((x) / uspi->s_ipg) #defineufs_inotocgoff(x) ((x) % uspi->s_ipg) -#defineufs_inotofsba(x)(((u64)ufs_cgimin(ufs_inotocg(x))) + ufs_inotocgoff(x) / uspi->s_inopf) +#defineufs_inotofsba(x)(((__u64)ufs_cgimin(ufs_inotocg(x))) + ufs_inotocgoff(x) / uspi->s_inopf) #defineufs_inotofsbo(x)((x) % uspi->s_inopf) /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.24 patch] let EXT4DEV_FS depend on BROKEN
It might make sense to offer ext4 in -mm and even in early -rc kernels, but I've already seen people using ext4 simply because a stable kernel offered it - and that's definitely not intended. Anyone who _really_ wants to test ext4 should anyway be able to do the trivial change of removing the "depends on BROKEN" line. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- f778e1d046a3554ca15b8637afd0ffbf4790801c diff --git a/fs/Kconfig b/fs/Kconfig index 487236c..d850725 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -138,7 +138,7 @@ config EXT3_FS_SECURITY config EXT4DEV_FS tristate "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)" - depends on EXPERIMENTAL + depends on BROKEN select JBD2 select CRC16 help -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: asm-x86/byteorder.h: clean up for userspace
On Tue, Jan 01, 2008 at 01:19:42PM -0800, H. Peter Anvin wrote: > Christoph Hellwig wrote: >> On Mon, Dec 31, 2007 at 01:12:45PM -0500, Mike Frysinger wrote: >>> Since asm-x86/byteorder.h is exported to userspace, use __asm__ rather than >>> asm in its code. >> >> The correct fix is to not export it to userspace. > > Unfortunately, it's historically been provided, for over 15 years. It's > also trivial to export, without funnies, and it's *useful* to userspace, as > it provides an interface sorely lacking from the stock libc interfaces. >... Userspace either has to #define CONFIG_X86_BSWAP or it'll get the slow versions of these functions... Leaking CONFIG_ variables to userspace is not really funny - I remember e.g. what tricks MySQL does (did?) for (ab)using asm-i386/atomic.h in userspace. > -hpa cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suspend2-devel] Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi Ted. Theodore Tso wrote: > On Wed, Jan 02, 2008 at 10:54:18AM +1100, Nigel Cunningham wrote: >>> I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go >>> to >>> one of the kernel-related lists, but I think linux-pm may be better for that >>> due to the much lower traffic. >> I guess that makes sense. I guess people can always be referred to LKML >> for the issues where the appropriate person isn't on linux-pm. > > Hi Nigel, > > I'd really recommend pushing the TuxOnIce discussions to LKML. That > way people can see the size of the user community and Andrew and Linus > can see how many people are using TuxOnIce. They can also see how > well the TuxOnIce community helps address user problems, which is a > big consideration when Linus decides whether or not to merge a > particular technology. > > If the goal is eventual merger of TuxOnIce, LKML is really the best > place to have the discussions. Examples such as Realtime, CFS, and > others have shown that you really want to keep the discussion front > and center. When one developer says, "not my problem; my code is > perfect", and the other developer is working with users who report > problems, guess which technology generally ends up getting merged by > Linus? Yes. The goal is eventual merger. That's what I was thinking too. Thanks for the input! Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: asm-x86/msr.h for sanitized headers: clean it or punt it
On Mon, Dec 31, 2007 at 01:49:27PM -0500, Mike Frysinger wrote:
> Use __asm__ and __volatile__ in code that is exported to userspace. Wrap
> kernel functions with __KERNEL__ so they get scrubbed.
>
> Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
> ---
> diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h
> index ba4b314..664a2fa 100644
> --- a/include/asm-x86/msr.h
> +++ b/include/asm-x86/msr.h
>...
> #define rdtscp(low,high,aux) \
> - asm volatile (".byte 0x0f,0x01,0xf9" : "=a" (low), "=d" (high), "=c"
> (aux))
> + __asm__ __volatile__ (".byte 0x0f,0x01,0xf9" : "=a" (low), "=d" (high),
> "=c" (aux))
>
> #define rdtscll(val) do { \
> unsigned int __a,__d; \
> - asm volatile("rdtsc" : "=a" (__a), "=d" (__d)); \
> + __asm__ __volatile__("rdtsc" : "=a" (__a), "=d" (__d)); \
> (val) = ((unsigned long)__a) | (((unsigned long)__d)<<32); \
> } while(0)
>
> #define rdtscpll(val, aux) do { \
> unsigned long __a, __d; \
> - asm volatile (".byte 0x0f,0x01,0xf9" : "=a" (__a), "=d" (__d), "=c"
> (aux)); \
> + __asm__ __volatile__ (".byte 0x0f,0x01,0xf9" : "=a" (__a), "=d" (__d),
> "=c" (aux)); \
> (val) = (__d << 32) | __a; \
> } while (0)
>...
How is this part of the kernel<->userspace interface?
Unless I miss anything this sounds more like userspace abusing kernel
headers as a utility library?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] asm-x86/msr.h: pull in linux/types.h
Forgot to mention this before, but since the msr.h header uses types like __u32, it should pull in linux/types.h. Signed-Off-By: Mike Frysinger <[EMAIL PROTECTED]> --- diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h index ba4b314..beea1bf 100644 --- a/include/asm-x86/msr.h +++ b/include/asm-x86/msr.h @@ -2,6 +2,7 @@ #define __ASM_X86_MSR_H_ #include +#include #ifdef __i386__ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 04/12] i2c : Use mutex instead of semaphore in driver core
On Dec 29, 2007 7:49 PM, Stefan Richter <[EMAIL PROTECTED]> wrote: > Dave Young wrote: > > --- linux/drivers/i2c/i2c-core.c 2007-12-28 10:06:58.0 +0800 > > +++ linux.new/drivers/i2c/i2c-core.c 2007-12-28 10:08:58.0 +0800 > > @@ -33,8 +33,8 @@ > > #include > > #include > > #include > > +#include > > #include > > -#include > > 2x #include Thanks, my fault ;) This patch series need more lockdep works to be done. After that I will repost it. > -- > Stefan Richter > -=-=-=== ==-- ===-= > http://arcgraph.de/sr/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: provide a DMI based port 0x80 I/O delay override.
On 02-01-08 01:55, Christer Weinigel wrote: On Wed, 02 Jan 2008 00:11:54 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: Well, on the PIIX it is and I guess on anything where it's _not_ fully internal an 0xf0 write wouldn't have any effect on IRQ13... When you earlier mentioned this it seemed 0xed switched on DMI would be good enough, but well. Alan, do you have an opinion on the port 0xf0 write? It should probably still be combined with a replacement/deletion for new machines due to the bus-locking "bad for real-time" thing you mentioned earlier but in the short run it could be a fairly low-impact replacement on anything except a 386+387 Both 0xed and 0xf0 are mapped to internal functions on the AMD Elan SC400 processor. It is an AMD 486 based system on a chip and since AMD just knew that it would never have a math coprocessor, they reused the 0xf0-0xf2 range for the PCMCIA controller. I guess the AMD Elan SC500 will have similar problems. I seem to recall that back when I was working with the Elan SC400 (sometime around 1998?) there were discussions about finding an alternate delay port because outb to 0x80 messed up the debug port. I think the Elan stopped those discussions because just about every port on the Elan was reused for some alternate purpose. Okay, thanks much. So 0xf0 would be unuseable on 386+387 and AMD Elan SC400 and could possibly change timing on an unknown number of systems due to not being put on the bus. 0x80 only fails for some recent HP laptops instead so it seems there would be not enough cause to go with 0xf0 onstead of 0x80 as the default choice; if we're quirking around machines anyway it might as well be the DMI based quirking currently suggested. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix errors detected by checkpatch.pl on nmi_int.c
This patch fixes most errors detected by checkpatch.pl.
errors lines of code errors/KLOC
arch/x86/oprofile/nmi_int.c (after) 1 461 2.1
arch/x86/oprofile/nmi_int.c (before) 60 477 125.7
No code changed.
size:
textdata bss dec hex filename
2675 264 4723411 d53 nmi_int.o.after
2675 264 4723411 d53 nmi_int.o.before
md5sum:
847aea0cc68fe1a2b5e7019439f3b4dd nmi_int.o.after
847aea0cc68fe1a2b5e7019439f3b4dd nmi_int.o.before
Signed-off-by: Carlos R. Mafra <[EMAIL PROTECTED]>
diff --git a/arch/x86/oprofile/nmi_int.c b/arch/x86/oprofile/nmi_int.c
index 2d0eeac..9510b08 100644
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -18,11 +18,11 @@
#include
#include
#include
-
+
#include "op_counter.h"
#include "op_x86_model.h"
-static struct op_x86_model_spec const * model;
+static struct op_x86_model_spec const *model;
static struct op_msrs cpu_msrs[NR_CPUS];
static unsigned long saved_lvtpc[NR_CPUS];
@@ -41,7 +41,6 @@ static int nmi_suspend(struct sys_device *dev, pm_message_t
state)
return 0;
}
-
static int nmi_resume(struct sys_device *dev)
{
if (nmi_enabled == 1)
@@ -49,29 +48,27 @@ static int nmi_resume(struct sys_device *dev)
return 0;
}
-
static struct sysdev_class oprofile_sysclass = {
set_kset_name("oprofile"),
.resume = nmi_resume,
.suspend= nmi_suspend,
};
-
static struct sys_device device_oprofile = {
.id = 0,
.cls= &oprofile_sysclass,
};
-
static int __init init_sysfs(void)
{
int error;
- if (!(error = sysdev_class_register(&oprofile_sysclass)))
+
+ error = sysdev_class_register(&oprofile_sysclass);
+ if (!error)
error = sysdev_register(&device_oprofile);
return error;
}
-
static void exit_sysfs(void)
{
sysdev_unregister(&device_oprofile);
@@ -90,7 +87,7 @@ static int profile_exceptions_notify(struct notifier_block
*self,
int ret = NOTIFY_DONE;
int cpu = smp_processor_id();
- switch(val) {
+ switch (val) {
case DIE_NMI:
if (model->check_ctrs(args->regs, &cpu_msrs[cpu]))
ret = NOTIFY_STOP;
@@ -101,24 +98,24 @@ static int profile_exceptions_notify(struct notifier_block
*self,
return ret;
}
-static void nmi_cpu_save_registers(struct op_msrs * msrs)
+static void nmi_cpu_save_registers(struct op_msrs *msrs)
{
unsigned int const nr_ctrs = model->num_counters;
- unsigned int const nr_ctrls = model->num_controls;
- struct op_msr * counters = msrs->counters;
- struct op_msr * controls = msrs->controls;
+ unsigned int const nr_ctrls = model->num_controls;
+ struct op_msr *counters = msrs->counters;
+ struct op_msr *controls = msrs->controls;
unsigned int i;
for (i = 0; i < nr_ctrs; ++i) {
- if (counters[i].addr){
+ if (counters[i].addr) {
rdmsr(counters[i].addr,
counters[i].saved.low,
counters[i].saved.high);
}
}
-
+
for (i = 0; i < nr_ctrls; ++i) {
- if (controls[i].addr){
+ if (controls[i].addr) {
rdmsr(controls[i].addr,
controls[i].saved.low,
controls[i].saved.high);
@@ -126,15 +123,13 @@ static void nmi_cpu_save_registers(struct op_msrs * msrs)
}
}
-
-static void nmi_save_registers(void * dummy)
+static void nmi_save_registers(void *dummy)
{
int cpu = smp_processor_id();
- struct op_msrs * msrs = &cpu_msrs[cpu];
+ struct op_msrs *msrs = &cpu_msrs[cpu];
nmi_cpu_save_registers(msrs);
}
-
static void free_msrs(void)
{
int i;
@@ -146,7 +141,6 @@ static void free_msrs(void)
}
}
-
static int allocate_msrs(void)
{
int success = 1;
@@ -173,11 +167,10 @@ static int allocate_msrs(void)
return success;
}
-
-static void nmi_cpu_setup(void * dummy)
+static void nmi_cpu_setup(void *dummy)
{
int cpu = smp_processor_id();
- struct op_msrs * msrs = &cpu_msrs[cpu];
+ struct op_msrs *msrs = &cpu_msrs[cpu];
spin_lock(&oprofilefs_lock);
model->setup_ctrs(msrs);
spin_unlock(&oprofilefs_lock);
@@ -193,13 +186,14 @@ static struct notifier_block profile_exceptions_nb = {
static int nmi_setup(void)
{
- int err=0;
+ int err = 0;
int cpu;
if (!allocate_msrs())
return -ENOMEM;
- if ((err = register_die_notifier(&profile_exceptions_nb))){
+ err = register_die_notifier(&profile_exceptions_nb);
+ if (err) {
free_msrs();
return err;
}
[RFC PATCH] Add input event to APM event bridge for embedded devices
This patch adds a very simple input power event to APM user suspend
event bridge. Its currently only works for the systems using the
emulated APM driver but could easily be extended to work with anything
with a true APM BIOS too.
This covers a standard embedded system need which is to suspend when the
user presses a suspend button. It leaves options open to system
integrators to ignore (or unload) this code and implement their own more
complex event handling system.
Its hidden behind the EMBEDDED Kconfig option since its only likely to
be of use to embedded style systems. It can be built as a module so the
"hardcoded" policy can easily be removed from the kernel at runtime if
desired too.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
drivers/input/Kconfig | 12
drivers/input/Makefile|1
drivers/input/apm-power.c | 125 ++
3 files changed, 138 insertions(+)
Index: kernel-hacking/drivers/input/Kconfig
===
--- kernel-hacking.orig/drivers/input/Kconfig 2008-01-01 23:50:13.0
+
+++ kernel-hacking/drivers/input/Kconfig2008-01-02 00:45:33.0
+
@@ -137,6 +137,18 @@ config INPUT_EVBUG
To compile this driver as a module, choose M here: the
module will be called evbug.
+config INPUT_APMPOWER
+ tristate "Input Power Event -> APM Bridge" if EMBEDDED
+ depends on INPUT && APM_EMULATION
+ ---help---
+ Say Y here if you want suspend key events to trigger a user
+ requested suspend through APM. This is useful on embedded
+ systems where such behviour is desired without userspace
+ interaction. If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called apm-power.
+
comment "Input Device Drivers"
source "drivers/input/keyboard/Kconfig"
Index: kernel-hacking/drivers/input/Makefile
===
--- kernel-hacking.orig/drivers/input/Makefile 2008-01-01 23:50:13.0
+
+++ kernel-hacking/drivers/input/Makefile 2008-01-02 00:39:03.0
+
@@ -22,3 +22,4 @@ obj-$(CONFIG_INPUT_TABLET)+= tablet/
obj-$(CONFIG_INPUT_TOUCHSCREEN)+= touchscreen/
obj-$(CONFIG_INPUT_MISC) += misc/
+obj-$(CONFIG_INPUT_APMPOWER) += apm-power.o
Index: kernel-hacking/drivers/input/apm-power.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ kernel-hacking/drivers/input/apm-power.c2008-01-02 00:43:42.0
+
@@ -0,0 +1,125 @@
+/*
+ * Input Power Event -> APM Bridge
+ *
+ * Copyright (c) 2007 Richard Purdie
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void system_power_event(unsigned int keycode)
+{
+ switch (keycode) {
+ case KEY_SUSPEND:
+ apm_queue_event(APM_USER_SUSPEND);
+
+ printk(KERN_INFO "apm-power: Requesting system
suspend...\n");
+ break;
+ default:
+ break;
+ }
+}
+
+static void apmpower_event(struct input_handle *handle, unsigned int type,
+ unsigned int code, int value)
+{
+ /* only react on key down events */
+ if (value != 1)
+ return;
+
+ switch (type) {
+ case EV_PWR:
+ system_power_event(code);
+ break;
+
+ default:
+ break;
+ }
+}
+
+static int apmpower_connect(struct input_handler *handler,
+ struct input_dev *dev,
+ const struct input_device_id *id)
+{
+ struct input_handle *handle;
+ int err;
+
+ if (!(handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL)))
+ return -ENOMEM;
+
+ handle->dev = dev;
+ handle->handler = handler;
+ handle->name = "apm-power";
+
+ handler->private = handle;
+ err = input_register_handle(handle);
+ if (err < 0) {
+ printk(KERN_ERR "apm-power.c: Failed to register input power
handler\n");
+ kfree(handle);
+ return err;
+ }
+
+ err = input_open_device(handle);
+ if (err < 0) {
+ printk(KERN_ERR "apm-power.c: Failed to open input power
device\n");
+ input_unregister_handle(handle);
+ kfree(handle);
+ return err;
+ }
+
+ return 0;
+}
+
+static void apmpower_disconnect(struct input_handle *handler)
+{
+
Re: [BUG][PATCH] bluetooth: put_device before device_del fix
On Dec 30, 2007 11:18 AM, David Miller <[EMAIL PROTECTED]> wrote: > From: Dave Young <[EMAIL PROTECTED]> > Date: Thu, 27 Dec 2007 13:27:50 +0800 > > > Because of workqueue delay, the put_device could be called before > > device_del, so move it to del_conn. > > > > Signed-off-by: Dave Young <[EMAIL PROTECTED]> > > Applied, thanks Dave. > > Please post bluetooth patches, just like any other networking patches, > to [EMAIL PROTECTED] (CC:'ing me) so that other networking > developers can process them during times like these when most > maintainers aren't around and thus not looking at bug fixes like > your's. > Ok, thanks for pointing out, I didn't know this before. Regards 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: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Dec 30, 2007 6:01 AM, Alan Stern <[EMAIL PROTECTED]> wrote: > > On Sat, 29 Dec 2007, Dave Young wrote: > > > On Dec 29, 2007 1:06 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > > > > > On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > > > > > > > The full boot dmesg with lockdep output is out, there's one warnings > > > > > in it : > > > > > > > > Please fix that warning before the next repost of these patches (along > > > > with fixing the problem of them not being able to be applied and > > > > successfully built at every point in the series...) > > > > > > > > > > Ok, thanks, I will fix them and repost. > > > > > > > Hi, > > After digging the code, I feel hard to fix the lockdep warning due to > > some misterious relationship with usb. > > > > Could someone help on this? thanks. > > Add usb-devel list as cc > > The problem isn't specific to USB. And you will not be able to fix it > unless you make drastic changes to the lockdep checker. > > lockdep warns whenever a task acquires a mutex while holding another > mutex of the same kind (that is, the same member in another structure > of the same type). But there are lots of places where the kernel needs > to acquire dev->sem for one device while already holding > dev->parent->sem. There's no way to remove these, which means there's > no way to prevent lockdep from issuing a warning. > > Around a month ago I had a discussion with Peter Zijlstra about the > problems in converting the device semaphores to mutexes; you may be > able to find it in the LKML archives. Doing the conversion while > keeping lockdep happy is a very hard problem and we were not able to > solve it. > It's unfortunate to know this, I will search and read your thread. > It's possible that you may be able to convert the semaphores in struct > class or other structures. But you won't succeed with struct device. > > Alan Stern > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: provide a DMI based port 0x80 I/O delay override.
On Wed, 02 Jan 2008 00:11:54 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > Well, on the PIIX it is and I guess on anything where it's _not_ > fully internal an 0xf0 write wouldn't have any effect on IRQ13... > > When you earlier mentioned this it seemed 0xed switched on DMI would > be good enough, but well. > > Alan, do you have an opinion on the port 0xf0 write? It should > probably still be combined with a replacement/deletion for new > machines due to the bus-locking "bad for real-time" thing you > mentioned earlier but in the short run it could be a fairly > low-impact replacement on anything except a 386+387 Both 0xed and 0xf0 are mapped to internal functions on the AMD Elan SC400 processor. It is an AMD 486 based system on a chip and since AMD just knew that it would never have a math coprocessor, they reused the 0xf0-0xf2 range for the PCMCIA controller. I guess the AMD Elan SC500 will have similar problems. I seem to recall that back when I was working with the Elan SC400 (sometime around 1998?) there were discussions about finding an alternate delay port because outb to 0x80 messed up the debug port. I think the Elan stopped those discussions because just about every port on the Elan was reused for some alternate purpose. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 01/12] Use mutex instead of semaphore in driver core
On Dec 30, 2007 1:07 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > On Sat, Dec 29, 2007 at 03:07:30PM +0800, Dave Young wrote: > > On Dec 29, 2007 1:06 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > > > > > On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > > > > > > > The full boot dmesg with lockdep output is out, there's one warnings > > > > > in it : > > > > > > > > Please fix that warning before the next repost of these patches (along > > > > with fixing the problem of them not being able to be applied and > > > > successfully built at every point in the series...) > > > > > > > > > > Ok, thanks, I will fix them and repost. > > > > > > > Hi, > > After digging the code, I feel hard to fix the lockdep warning due to > > some misterious relationship with usb. > > > > Could someone help on this? thanks. > > My question back to you is why are you doing this conversion? Have you > found that it is needed for something? Are there problems in the -rt > kernels that this conversion helps with? Or is it just a janitorial > "convert semaphore to mutex" type thing. Sorry for delay-reply because recently I have little free time. Mutex is lightweighter than semaphore, the device/class is used heavily in kernel, so I think the convert would be worth. > > If the latter, I would suggest dropping it, as this area is quite > complex and I think the locking chain too deep at times for a simple > conversion. I admit that I did not realize the complex in the lockdep fixing when writing the patches. > good luck, > > 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: [2.6 patch] remove broken MTD drivers
On Wed, Jan 02, 2008 at 01:28:26AM +0100, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > > > > The header of ppchameleonevb.c claims it comes from [EMAIL PROTECTED] > > Argh. That's indeed ancient code. > > So what should I do to fix this? Wait for Thomas' response, or port > patches here? I'd say post patches, and I'd expect David to actually be the one who reviews and incorporates them. > Best regards, > > Wolfgang Denk cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [2.6.24] Add PPC nvram ioctls to compat_ioctl
On Monday 31 December 2007, Olof Johansson wrote:
> Fix the following console warning when running 'nvsetenv', and makes
> setting of new variables work again:
>
> ioctl32(nvsetenv:4022): Unknown cmd fd(3) cmd(20007043){t:'p';sz:0}
> arg(0003) on /dev/nvram
>
> That's the IOC_NVRAM_SYNC call.
>
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
>
> diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
> index e8b7c3a..7be6765 100644
> --- a/fs/compat_ioctl.c
> +++ b/fs/compat_ioctl.c
Please don't. I have this long-term plan of getting rid of fs/compat_ioctl.c,
the better answer is to convert arch/powerpc/kernel/nvram_64.c and
drivers/char/generic_nvram.c from the .ioctl file_operation to
.unlocked_ioctl/.compat_ioctl.
Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove broken MTD drivers
In message <[EMAIL PROTECTED]> you wrote: > > The header of ppchameleonevb.c claims it comes from [EMAIL PROTECTED] Argh. That's indeed ancient code. So what should I do to fix this? Wait for Thomas' response, or port patches here? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] A Chairman was as necessary to a Board planet as the zero was in mathematics, but being a zero had big disadvantages... - Terry Pratchett, _The Dark Side of the Sun_ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: provide a DMI based port 0x80 I/O delay override.
On 02-01-08 00:11, Rene Herman wrote: On 01-01-08 23:39, H. Peter Anvin wrote: Yes, we do. It's exactly this side effect which makes this safer than either 0x80 or 0xED -- it's a port that *guaranteed* can't be reclaimed for other purposes without breaking MS-DOS compatibility. I see that with CR0.NE set (*) we indeed don't care about IGNNE#... However, I'm worried about this comment in arch/x86/kernel/i8259_32.c === /* * New motherboards sometimes make IRQ 13 be a PCI interrupt, * so allow interrupt sharing. */ === Is it really safe to just blindly negate IRQ13 on everything out there, from regular PC through funky embedded thingies? It's not any IRQ 13, it's IRQ 13 from the FPU. Well, on the PIIX it is and I guess on anything where it's _not_ fully internal an 0xf0 write wouldn't have any effect on IRQ13... When you earlier mentioned this it seemed 0xed switched on DMI would be good enough, but well. Alan, do you have an opinion on the port 0xf0 write? It should probably still be combined with a replacement/deletion for new machines due to the bus-locking "bad for real-time" thing you mentioned earlier but in the short run it could be a fairly low-impact replacement on anything except a 386+387 We should do a another timing measurement survey and it makes for sligtly worse code if we indeed feel it's not safe enough to write anything other than 0, but otherwise it's quite minimal. Thinking about this, my main worry about 0xf0 as a 0x80 replacement would be systems that have elected to _not_ let port 0xf0 writes flow through to ISA changing the timing-characteristics. Given that it's a known port, someone may have elected to just keep it fully internal. Upto now the datasheets I've read do put it on ISA... Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suspend2-devel] Reboot problem
On Wednesday 02 January 2008, Nigel Cunningham wrote: > Hi Christian. > > Christian Hesse wrote: > > On Tuesday 01 January 2008, Nigel Cunningham wrote: > >> Third, regarding the patch itself, I'm taking my time in working towards > >> the 3.0 release. We don't have any major bugs with 3.0-rc3 reported > >> [...]. > > > > Well, I think I still have a bug, though it is possibly a mainline > > problem and it's not a showstopper. After a suspend/resume cycle the > > reboot does not work. The system hangs with "Rebooting system" (or > > similar). After that you have to hard reset the system, which is not > > really a problem as filesystems have been unmounted before. Reboot > > without a suspend cycle before and halt with and without suspend cycle > > work without problems. > > Just to clarify, do you mean rebooting after writing an image, or > shutting down and rebooting? It could be that there's some change to the > semantics in 2.6.24 that I haven't noticed yet. I speak about shutting down and rebooting. I have not used reboot after writing an image for a long time now. Will test what happens in this case. I had the issue before 2.6.24(-rc) already, thought I don't know whether there were times it worked. I use it way too seldom. -- Regards, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 1 Jan 2008 23:12:50 + Alan Cox <[EMAIL PROTECTED]> wrote: > > Besides the above there are only a handful of _p uses outside of > > real ISA device drivers, and those should not be relevant for a > > modern PC unless somebody wants to use an 8390 based PCMCIA card, > > but we could tell them "don't do that then". > > We need to build 8390.c twice anyway - once for PCI once for ISA with > the _p changes whichever way it gets done. PCMCIA can use whichever > we decide is right. Anyone know if PCMCIA is guaranteed to be 8MHz ? It's not. It's perfectly ok to drive a PCMCIA bus slower than that, IIRC we used a much slower clock speed than that on a StrongARM platform I worked a couple of years ago. The PCMCIA CIS (Card information services) allows the following device speeds: 100, 150, 200 and 250 ns. The memory card spec also allows 600 and 300 ns. The standard I/O card cycle speed is 255 ns. I believe that is "the shortest access time for a read/write cycle", and I can't tell if that is comparable to one ISA clock cycles or if it's comparable to 8 ISA bus cycles. On the other hand, there is no clock line in a PCMCIA connector, so for PCMCIA devices any delays should be absolute times, or based on some clock that is internal to the card. How that fits with the 8390 data sheet talking about bus clocks, I don't know. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] crash - module radio-sf16fmr2 and esp interfere
same with radio-sf16fmr2 and esp after repeatedly modrpobe/modprobe -r radio-sf16fmr2, i can hang my system when loading esp afterwards before loading esp, doing a "cat /proc/ioport" segfaults this is with 2.6.24rc6 and also with 2.6.22 i have found these issues by running some (probably sick :D ) module load/unload test across all modules > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > Gesendet: 01.01.08 21:46:30 > An: linux-kernel@vger.kernel.org > Betreff: Re: [BUG] crash - module l440gx buggy ? interfere > > same/similar behaviour with > > l440gx and container > l440gx and acpiphp > > after load of l440gx, container and acpiphp modules do also hang my system on > load/unload. > > maybe l440gx leaving the system in some weird state after probe ? > > > > -Ursprüngliche Nachricht- > > Von: <[EMAIL PROTECTED]> > > Gesendet: 01.01.08 20:57:08 > > An: linux-kernel@vger.kernel.org > > Betreff: [BUG] crash - modules l440gx and parport_pc interfere > > > > > > there seems some weird interference between l440gx and parport_pc modules > > > > i can reproduceable crash my box by either: > > > > modprobe parport_pc;modprobe l440gx;rmmod parport_pc > > > > or > > > > modprobe l440gx; modprobe parport_pc;rmmod parport_pc > > > > this happens on 2.6.24rc6 and also older kernel (2.6.22) > > > > nothing in dmesg - just > > >JEDEC: Found no L440GX BIOS device at location zero > > >JEDEC probe on BIOS chip failed. Using ROM > > > > because i haven`t appropriate hardware. > > > > don`t know if this is a bug in parport_pc or l440gx but maybe its worth > > reporting. > > > > regards > > roland > > ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] arch/powerpc/platforms/pseries: Add missing of_node_put
On Tue, 1 Jan 2008 22:02:49 +0100 (CET) Julia Lawall <[EMAIL PROTECTED]> wrote: > > From: Julia Lawall <[EMAIL PROTECTED]> > > Of_get_parent and of_find_compatible_node do an of_node_get, and thus a > corresponding of_code_put is needed in the error case. Thanks for these. In the future, any patch that touches arch/powerpc (or include/asm-powerpc) should be (at least) cc'd to [EMAIL PROTECTED] (where the PowerPC developers lurk). That way they will also be saved in Patchwork (http://patchwork.ozlabs.org/) and not lost. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpZvKCWRzs5W.pgp Description: PGP signature
Re: [2.6 patch] remove CONFIG_EXPERIMENTAL
On Tue, Jan 01, 2008 at 05:35:32PM +, Alan Cox wrote: > > So smbfs is still considered rock solid while no serious distribution > > would be crazy enough to ship the EXPERIMENTAL NFSv4 support to their > > customers? > > Thats a different problem. The kernel as I've said many times has no > proper process for > > - removing expired/missing maintainers > - handling stuff that decays > - removing dead documentation > - removing dead drivers and ports > > Although you've certainly started on fixing much of that. > > > I'm not claiming that all EXPERIMENTAL tags were wrong [1], but many > > were wrong. > > So why not fix the wrong tags, and mark smbfs obsolete ? It's also the other way around: Is e.g. NFSv4 support really still experimental? There are only few parts of the kernel where the EXPERIMENTAL tags are actually maintained, but most of them were simply added once and stayed forever. If my "remove all EXPERIMENTAL tags" approach is not considered the best solution I have no problem with starting with "convert EXPERIMENTAL to FOO_EXPERIMENTAL in all areas where the subsystem maintainer wants to do so" and remove the remaining EXPERIMENTAL tags later. > > Plus the fact that CONFIG_EXPERIMENTAL controlled so many different > > things with one switch that CONFIG_EXPERIMENTAL=n .config's are really > > rare. > > Agreed cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suspend2-devel] Reboot problem
Hi Christian. Christian Hesse wrote: > On Tuesday 01 January 2008, Nigel Cunningham wrote: >> Third, regarding the patch itself, I'm taking my time in working towards >> the 3.0 release. We don't have any major bugs with 3.0-rc3 reported [...]. > > Well, I think I still have a bug, though it is possibly a mainline problem > and > it's not a showstopper. After a suspend/resume cycle the reboot does not > work. The system hangs with "Rebooting system" (or similar). After that you > have to hard reset the system, which is not really a problem as filesystems > have been unmounted before. Reboot without a suspend cycle before and halt > with and without suspend cycle work without problems. Just to clarify, do you mean rebooting after writing an image, or shutting down and rebooting? It could be that there's some change to the semantics in 2.6.24 that I haven't noticed yet. > I'm using toi 3.0-rc3 with kernel 2.6.24-rc6 and beside the problem described > above I'm really happy with toi. > > Happy new your to everybody! And to you too! Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] the scheduled 'time' option removal
On Tue, Jan 01, 2008 at 06:53:54PM +0100, Jan Engelhardt wrote: > > On Jan 1 2008 15:46, Adrian Bunk wrote: > >index 20c4c8b..93aac19 100644 > >--- a/Documentation/feature-removal-schedule.txt > >+++ b/Documentation/feature-removal-schedule.txt > >@@ -233,10 +233,2 @@ Who:Jean Delvare <[EMAIL PROTECTED]> > > --- > >- > >-What: 'time' kernel boot parameter > >-When: January 2008 > >-Why:replaced by 'printk.time=' so that printk timestamps can > >be > >-enabled or disabled as needed > >-Who:Randy Dunlap <[EMAIL PROTECTED]> > >- > > I am sure the people who added themselves in the Who: line would have > taken care of this soon enough, I mean, it's just 19 hours into the > first day :-) If Randy decides he wants to submit his own patch for this that wouldn't be a problem for me. :-) cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Freezing filesystems (Was Re: What's in store for 2008 for TuxOnIce?)
Hi.
Rafael J. Wysocki wrote:
> On Tuesday, 1 of January 2008, Nigel Cunningham wrote:
>> Hi all.
>
> Hi Nigel,
Gidday :)
>> With the start of a new year, I suppose it's a good time to think about
>> what I'd like to do with TuxOnIce this year and see what feedback I get.
>>
>> First up, I'm thinking about closing the mailing lists and asking people
>> to use LKML instead for reporting issues and so on. I'm thinking about
>> this because it will help with allowing people who work on mainline to
>> see how stable (or otherwise!) TuxOnIce is now. It should also help when
>> (as often happens) bug reports aren't actually issues with the patch,
>> but with vanilla (ie drivers).
>
> I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to
> one of the kernel-related lists, but I think linux-pm may be better for that
> due to the much lower traffic.
I guess that makes sense. I guess people can always be referred to LKML
for the issues where the appropriate person isn't on linux-pm.
>> Perhaps it will also help with whatever effort I find time to make towards
>> convincing Andrew that it really does have significant advantages over
>> [u]swsusp and kexec based hibernation.
>>
>> Secondly, I'm planning on moving the website soonish. It's taken longer
>> than I planned because it will be sharing with another server I'm
>> maintaining, and it has taken longer than expected to find good hosting
>> for the other server (which was done first). Now that I'm happy with the
>> other server's state, I'm hoping to start shifting
>> suspend2.net/tuxonice.net soon.
>>
>> For those who might be looking for hosting themselves, I'm using
>> slicehost. I initially tried GoDaddy, but had terrible service, problems
>> with draconian limits on the volume of outgoing email (1000/day by
>> default - useless if you're doing mailing lists) and unexpected,
>> unexplained delays in mail delivery through the SMTP delay they force
>> you to use. Slicehost, on the other hand, are terrific to deal with in
>> everyway. If you sign up with them because of this email, please
>> consider putting my email (nigel at suspend2.net) as the referrer - I
>> then get a discount on the cost of the hosting.
>>
>> Third, regarding the patch itself, I'm taking my time in working towards
>> the 3.0 release. We don't have any major bugs with 3.0-rc3 reported, but
>> I have some things I want to complete before the final release:
>> * see it well tested;
>> * get a finished initial version of the cluster support;
>> * finish completing support for the new resume-from-other kernels
>> functionality that Rafael has added in 2.6.24. (We can resume from the
>> same kernel at the moment, but I need to convince myself that nosave
>> data is properly handled).
>
> Have you finished the support for freezing filesystems before freezing tasks
> that we talked about some time ago?
Hmm. I've had too many things going through my little brain since then.
What I currently have is support for freezing fuse filesystems
separately. It looks like:
int freeze_processes(void)
{
int error;
printk("Stopping fuse filesystems.\n");
freeze_filesystems(FS_FREEZER_FUSE);
freezer_state = FREEZER_FILESYSTEMS_FROZEN;
printk("Freezing user space processes ... ");
error = try_to_freeze_tasks(FREEZER_USER_SPACE);
if (error)
goto Exit;
printk("done.\n");
sys_sync();
printk("Stopping normal filesystems.\n");
freeze_filesystems(FS_FREEZER_NORMAL);
freezer_state = FREEZER_USERSPACE_FROZEN;
printk("Freezing remaining freezable tasks ... ");
error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
if (error)
goto Exit;
printk("done.");
freezer_state = FREEZER_FULLY_ON;
Exit:
BUG_ON(in_atomic());
printk("\n");
return error;
}
(I'm not yet worrying about ext3 on fuse or such like, but it shouldn't
be hard to extend the model to do that).
Nigel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reboot problem (was: Re: [Suspend2-devel] What's in store for 2008 for TuxOnIce?)
On Tuesday 01 January 2008, Nigel Cunningham wrote: > Third, regarding the patch itself, I'm taking my time in working towards > the 3.0 release. We don't have any major bugs with 3.0-rc3 reported [...]. Well, I think I still have a bug, though it is possibly a mainline problem and it's not a showstopper. After a suspend/resume cycle the reboot does not work. The system hangs with "Rebooting system" (or similar). After that you have to hard reset the system, which is not really a problem as filesystems have been unmounted before. Reboot without a suspend cycle before and halt with and without suspend cycle work without problems. I'm using toi 3.0-rc3 with kernel 2.6.24-rc6 and beside the problem described above I'm really happy with toi. Happy new your to everybody! -- Regards, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] CIFS: #if 0 mode_to_access_flags()
The cifsacl code which uses that function was not ready in time for 2.6.24 but is in the cifs development tree now.. On Jan 1, 2008 12:10 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Tue, Jan 01, 2008 at 03:46:44PM +0200, Adrian Bunk wrote: > > This patch #if 0's the unused mode_to_access_flags(), fixing the > > following compile warning: > > Please remove it completely instead. > -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] PM: Introduce destroy_suspended_device()
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
It sometimes is necessary to destroy a device object during a suspend or
hibernation, but the PM core is supposed to control all device objects in that
cases. For this reason, it is necessary to introduce a mechanism allowing one
to ask the PM core to remove a device object corresponding to a suspended
device on one's behalf.
Define function destroy_suspended_device() that will schedule the removal of
a device object corresponding to a suspended device by the PM core during the
subsequent resume.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/base/core.c| 44 +++-
drivers/base/power/main.c | 36 +++-
drivers/base/power/power.h |1 +
include/linux/device.h |8
4 files changed, 75 insertions(+), 14 deletions(-)
Index: linux-2.6/drivers/base/core.c
===
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -1156,14 +1156,11 @@ error:
EXPORT_SYMBOL_GPL(device_create);
/**
- * device_destroy - removes a device that was created with device_create()
+ * find_device - finds a device that was created with device_create()
* @class: pointer to the struct class that this device was registered with
* @devt: the dev_t of the device that was previously registered
- *
- * This call unregisters and cleans up a device that was created with a
- * call to device_create().
*/
-void device_destroy(struct class *class, dev_t devt)
+static struct device *find_device(struct class *class, dev_t devt)
{
struct device *dev = NULL;
struct device *dev_tmp;
@@ -1176,12 +1173,49 @@ void device_destroy(struct class *class,
}
}
up(&class->sem);
+ return dev;
+}
+/**
+ * device_destroy - removes a device that was created with device_create()
+ * @class: pointer to the struct class that this device was registered with
+ * @devt: the dev_t of the device that was previously registered
+ *
+ * This call unregisters and cleans up a device that was created with a
+ * call to device_create().
+ */
+void device_destroy(struct class *class, dev_t devt)
+{
+ struct device *dev;
+
+ dev = find_device(class, devt);
if (dev)
device_unregister(dev);
}
EXPORT_SYMBOL_GPL(device_destroy);
+#ifdef CONFIG_PM_SLEEP
+/**
+ * destroy_suspended_device - schedules the removal of a suspended device
+ * @class: pointer to the struct class that this device was registered with
+ * @devt: the dev_t of the device that was previously registered
+ *
+ * This call notifies the PM core of the necessity to unregister a suspended
+ * device created with a call to device_create() (devices cannot be
+ * unregistered directly while suspended, since the PM core controls them in
+ * that cases).
+ */
+void destroy_suspended_device(struct class *class, dev_t devt)
+{
+ struct device *dev;
+
+ dev = find_device(class, devt);
+ if (dev)
+ device_pm_schedule_removal(dev);
+}
+EXPORT_SYMBOL_GPL(destroy_suspended_device);
+#endif /* CONFIG_PM_SLEEP */
+
/**
* device_rename - renames a device
* @dev: the pointer to the struct device to be renamed
Index: linux-2.6/include/linux/device.h
===
--- linux-2.6.orig/include/linux/device.h
+++ linux-2.6/include/linux/device.h
@@ -521,6 +521,14 @@ extern struct device *device_create(stru
dev_t devt, const char *fmt, ...)
__attribute__((format(printf,4,5)));
extern void device_destroy(struct class *cls, dev_t devt);
+#ifdef CONFIG_PM_SLEEP
+extern void destroy_suspended_device(struct class *cls, dev_t devt);
+#else /* !CONFIG_PM_SLEEP */
+static inline void destroy_suspended_device(struct class *cls, dev_t devt)
+{
+ device_destroy(cls, devt);
+}
+#endif /* !CONFIG_PM_SLEEP */
/*
* Platform "fixup" functions - allow the platform to have their say
Index: linux-2.6/drivers/base/power/power.h
===
--- linux-2.6.orig/drivers/base/power/power.h
+++ linux-2.6/drivers/base/power/power.h
@@ -20,6 +20,7 @@ static inline struct device *to_device(s
extern void device_pm_add(struct device *);
extern void device_pm_remove(struct device *);
+extern void device_pm_schedule_removal(struct device *);
#else /* CONFIG_PM_SLEEP */
Index: linux-2.6/drivers/base/power/main.c
===
--- linux-2.6.orig/drivers/base/power/main.c
+++ linux-2.6/drivers/base/power/main.c
@@ -31,6 +31,7 @@
LIST_HEAD(dpm_active);
static LIST_HEAD(dpm_off);
static LIST_HEAD(dpm_off_irq);
+static LIST_HEAD(dpm_destroy);
static DEFINE_MUTEX(dpm_mtx);
static DEFINE_MUTEX(dpm_list_mtx);
@@ -59,6 +60,17 @@ void device_pm_r
[PATCH 2/4] PM: Do not destroy/create devices while suspended in msr.c (rev. 2)
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The MSR driver should not attempt to destroy/create a device while
suspended, unless this device corresponds to a nonboot CPU that
failed to go online during a resume, in which case the PM core should
be asked to remove it.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/x86/kernel/msr.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/arch/x86/kernel/msr.c
===
--- linux-2.6.orig/arch/x86/kernel/msr.c
+++ linux-2.6/arch/x86/kernel/msr.c
@@ -155,15 +155,15 @@ static int __cpuinit msr_class_cpu_callb
switch (action) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
err = msr_device_create(cpu);
break;
case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
msr_device_destroy(cpu);
break;
+ case CPU_UP_CANCELED_FROZEN:
+ destroy_suspended_device(msr_class, MKDEV(MSR_MAJOR, cpu));
+ break;
}
return err ? NOTIFY_BAD : NOTIFY_OK;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/4] PM: Do not destroy/create devices while suspended (rev. 2)
Hi, Some device drivers register CPU hotplug notifiers and use them to destroy device objects when removing the corresponding CPUs and to create these objects when adding the CPUs back. Unfortunately, this is not the right thing to do during suspend/hibernation, since in that cases the CPU hotplug notifiers are called after suspending devices and before resuming them, so the operations in question are carried out on the objects representing suspended devices which shouldn't be unregistered behing the PM core's back. Although right now it usually doesn't lead to any practical complications, it will predictably deadlock if gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is applied. The solution is to prevent drivers from removing/adding devices from within CPU hotplug notifiers during suspend/hibernation using the FROZEN bit in the notifier's action argument. However, this has to be done with care, since the devices objects related to the nonboot CPUs that failed to go online during resume should not be present in the system. For this reason, it seems reasonable to introduce a mechanism allowing drivers to ask the PM core to remove device objects corresponding to suspended devices on their behalf. The first patch in the series introduces such a mechanism. The remaining three patches modify the MSR, x86-64 MCE and cpuid drivers in accordance with the above approach. 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/
[PATCH 4/4] PM: Do not destroy/create devices while suspended in cpuid.c
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The cpuid driver should not attempt to destroy/create a device while
suspended, unless this device corresponds to a nonboot CPU that
failed to go online during a resume, in which case the PM core should
be asked to remove it.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpuid.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpuid.c
===
--- linux-2.6.orig/arch/x86/kernel/cpuid.c
+++ linux-2.6/arch/x86/kernel/cpuid.c
@@ -157,15 +157,15 @@ static int __cpuinit cpuid_class_cpu_cal
switch (action) {
case CPU_UP_PREPARE:
- case CPU_UP_PREPARE_FROZEN:
err = cpuid_device_create(cpu);
break;
case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
cpuid_device_destroy(cpu);
break;
+ case CPU_UP_CANCELED_FROZEN:
+ destroy_suspended_device(cpuid_class, MKDEV(CPUID_MAJOR, cpu));
+ break;
}
return err ? NOTIFY_BAD : NOTIFY_OK;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] PM: Do not destroy/create devices while suspended in mce_64.c
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The x86-64 MCE driver should not attempt to destroy/create a suspended
device, unless it corresponds to a nonboot CPU that failed to go online during
a resume.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/mcheck/mce_64.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpu/mcheck/mce_64.c
===
--- linux-2.6.orig/arch/x86/kernel/cpu/mcheck/mce_64.c
+++ linux-2.6/arch/x86/kernel/cpu/mcheck/mce_64.c
@@ -862,11 +862,10 @@ mce_cpu_callback(struct notifier_block *
switch (action) {
case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
mce_create_device(cpu);
break;
case CPU_DEAD:
- case CPU_DEAD_FROZEN:
+ case CPU_UP_CANCELED_FROZEN:
mce_remove_device(cpu);
break;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Hibernation: Document __save_processor_state() on x86-64 (rev. 2)
On Wednesday, 2 of January 2008, Pavel Machek wrote: > On Sun 2007-12-30 23:13:51, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Document the fact that __save_processor_state() has to save all CPU > > registers referred to by the kernel in case a different kernel is > > used to load and restore a hibernation image containing it. > > > > Sigend-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > ACK. Thanks! Ingo, can you please take this patch for 2.6.25 or should I forward it to Len? 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] x86: provide a DMI based port 0x80 I/O delay override.
> Besides the above there are only a handful of _p uses outside of real > ISA device drivers, and those should not be relevant for a modern PC > unless somebody wants to use an 8390 based PCMCIA card, but we could > tell them "don't do that then". We need to build 8390.c twice anyway - once for PCI once for ISA with the _p changes whichever way it gets done. PCMCIA can use whichever we decide is right. Anyone know if PCMCIA is guaranteed to be 8MHz ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 linux-acpi] Correct wakeup set error and append a new column PCI ID
Hi! > /proc/acpi/wakeup is also case-sensitive, case-insensitive is better. Why? > In addtion, this patch appends a new column 'PCI ID' to /proc/acpi/wakeup > , the user can use it to get the corresponding device name very > conveniently because PCI ID is a unique identifier and platform-independent. Userland interface change...? Maybe this file should be left for compatibility and we should present something reasonable in /sys? Can't you already get PCI ID from sysfs node? Pavel > [EMAIL PROTECTED] ~]# cat /proc/acpi/wakeup > Device S-state Status Sysfs node > C093 S5 disabled pci::00:1e.0 > C0E8 S3 disabled pci::00:1d.0 > C0EF S3 disabled pci::00:1d.1 > C0F0 S3 disabled pci::00:1d.2 > C0F1 S3 disabled pci::00:1d.3 > C0F2 S3 disabled pci::00:1d.7 > C0F9 S0 disabled pci::00:1c.0 > C21D S0 disabled pci::08:00.0 > C109 S5 disabled pci::00:1c.1 > C228 S5 disabled pci::10:00.0 > C10F S5 disabled pci::00:1c.3 > C229 S5 disabled > [EMAIL PROTECTED] ~]# > > After applying this patch, the output is: > > [EMAIL PROTECTED] ~]# cat /proc/acpi/wakeup > Device S-state Status Sysfs node PCI ID > C093 S5 disabled pci::00:1e.0 0x2448 > C0E8 S3 disabled pci::00:1d.0 0x27c8 > C0EF S3 disabled pci::00:1d.1 0x27c9 > C0F0 S3 disabled pci::00:1d.2 0x27ca > C0F1 S3 disabled pci::00:1d.3 0x27cb > C0F2 S3 disabled pci::00:1d.7 0x27cc > C0F9 S0 disabled pci::00:1c.0 0x27d0 > C21D S0 disabled pci::08:00.0 0x16fd > C109 S5 disabled pci::00:1c.1 0x27d2 > C228 S5 disabled pci::10:00.0 0x4222 > C10F S5 disabled pci::00:1c.3 0x27d6 > C229 S5 disabled -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What's in store for 2008 for TuxOnIce?
On Tuesday, 1 of January 2008, Nigel Cunningham wrote: > Hi all. Hi Nigel, > With the start of a new year, I suppose it's a good time to think about > what I'd like to do with TuxOnIce this year and see what feedback I get. > > First up, I'm thinking about closing the mailing lists and asking people > to use LKML instead for reporting issues and so on. I'm thinking about > this because it will help with allowing people who work on mainline to > see how stable (or otherwise!) TuxOnIce is now. It should also help when > (as often happens) bug reports aren't actually issues with the patch, > but with vanilla (ie drivers). I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to one of the kernel-related lists, but I think linux-pm may be better for that due to the much lower traffic. > Perhaps it will also help with whatever effort I find time to make towards > convincing Andrew that it really does have significant advantages over > [u]swsusp and kexec based hibernation. > > Secondly, I'm planning on moving the website soonish. It's taken longer > than I planned because it will be sharing with another server I'm > maintaining, and it has taken longer than expected to find good hosting > for the other server (which was done first). Now that I'm happy with the > other server's state, I'm hoping to start shifting > suspend2.net/tuxonice.net soon. > > For those who might be looking for hosting themselves, I'm using > slicehost. I initially tried GoDaddy, but had terrible service, problems > with draconian limits on the volume of outgoing email (1000/day by > default - useless if you're doing mailing lists) and unexpected, > unexplained delays in mail delivery through the SMTP delay they force > you to use. Slicehost, on the other hand, are terrific to deal with in > everyway. If you sign up with them because of this email, please > consider putting my email (nigel at suspend2.net) as the referrer - I > then get a discount on the cost of the hosting. > > Third, regarding the patch itself, I'm taking my time in working towards > the 3.0 release. We don't have any major bugs with 3.0-rc3 reported, but > I have some things I want to complete before the final release: > * see it well tested; > * get a finished initial version of the cluster support; > * finish completing support for the new resume-from-other kernels > functionality that Rafael has added in 2.6.24. (We can resume from the > same kernel at the moment, but I need to convince myself that nosave > data is properly handled). Have you finished the support for freezing filesystems before freezing tasks that we talked about some time ago? 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] x86_64: clear IO_APIC before enabing apic error vector. v2
On Sun, Dec 30, 2007 at 05:03:50PM -0800, Yinghai Lu wrote: > On Dec 30, 2007 4:28 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote: >... > > > the old one is in x86-mm tree > > > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > > >... > > > > Sorry for the dumb question, but what in > > > > + if (!smp_processor_id() && !skip_ioapic_setup && nr_ioapics) > > + enable_IO_APIC(); > > > > guarantees that this call doesn't happen when you hotplug CPU 0 ? > > > > if CPU 0 (BSP) can be hotplug, it will be restarted via smp_callin. > and the delta function call patch will use setup_local_APIC(NULL), > then it will be safe. We are talking about the version without the pointer games. > YH cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Sun, Dec 30, 2007 at 04:56:35PM -0800, Yinghai Lu wrote: > On Dec 30, 2007 4:28 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: >... > > Sorry for the dumb question, but what in > > > > + if (!smp_processor_id() && !skip_ioapic_setup && nr_ioapics) > > + enable_IO_APIC(); > > > > guarantees that this call doesn't happen when you hotplug CPU 0 ? > > so we can hotplug cpu0 or the bsp? Honestly I don't know the amd64 architecture well enough for telling whether the hardware allows it or not. > YH cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] OSS msnd: fix array overflows
On Tue, Jan 01, 2008 at 07:43:23PM +0100, Oliver Pinter (Pintér Olivér) wrote:
> then it is auch to 2.6.22-stable?
That's a very old bug in a driver for ancient hardware, so there's no
need to hurry.
> On 1/1/08, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > This patch fixes array overflows in the OSS msnd driver spotted by the
> > Coverity checker.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> >
> > This patch has been sent on:
> > - 27 Oct 2007
> >
> > 97463a59dfb9ccb915d3b615225c98cb3e310c0a
> > diff --git a/sound/oss/msnd.h b/sound/oss/msnd.h
> > index 05cf786..d0ca582 100644
> > --- a/sound/oss/msnd.h
> > +++ b/sound/oss/msnd.h
> > @@ -233,8 +233,8 @@ typedef struct multisound_dev {
> > spinlock_t lock;
> > int nresets;
> > unsigned long recsrc;
> > - int left_levels[16];
> > - int right_levels[16];
> > + int left_levels[32];
> > + int right_levels[32];
> > int mixer_mod_count;
> > int calibrate_signal;
> > int play_sample_size, play_sample_rate, play_channels;
>
> Thanks,
> Oliver
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On 01-01-08 23:39, H. Peter Anvin wrote: Yes, we do. It's exactly this side effect which makes this safer than either 0x80 or 0xED -- it's a port that *guaranteed* can't be reclaimed for other purposes without breaking MS-DOS compatibility. I see that with CR0.NE set (*) we indeed don't care about IGNNE#... However, I'm worried about this comment in arch/x86/kernel/i8259_32.c === /* * New motherboards sometimes make IRQ 13 be a PCI interrupt, * so allow interrupt sharing. */ === Is it really safe to just blindly negate IRQ13 on everything out there, from regular PC through funky embedded thingies? It's not any IRQ 13, it's IRQ 13 from the FPU. Well, on the PIIX it is and I guess on anything where it's _not_ fully internal an 0xf0 write wouldn't have any effect on IRQ13... When you earlier mentioned this it seemed 0xed switched on DMI would be good enough, but well. Alan, do you have an opinion on the port 0xf0 write? It should probably still be combined with a replacement/deletion for new machines due to the bus-locking "bad for real-time" thing you mentioned earlier but in the short run it could be a fairly low-impact replacement on anything except a 386+387 We should do a another timing measurement survey and it makes for sligtly worse code if we indeed feel it's not safe enough to write anything other than 0, but otherwise it's quite minimal. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove broken MTD drivers
In message <[EMAIL PROTECTED]> you wrote: > This patch removes two MTD drivers that have been marked as > BROKEN 19 months ago due to requiring nonexisting header files. ... > drivers/mtd/nand/Kconfig | 12 > drivers/mtd/nand/Makefile |2 > drivers/mtd/nand/ppchameleonevb.c | 439 -- It would have been nice if you had put the autors of the files on Cc: Regarding the PPChameleon NAND support: I discussed this issue with tglx on 23 June 2006. Thomas promised to fix the driver if I send him the missing file and eventually needed patches. I did so on Fri, 23 Jun 2006 23:23:42 +0200. Thomas, can you please have a look at this? If you don't have time / resources please let me know so we can submit the stuff here on the list... Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] "More software projects have gone awry for lack of calendar time than for all other causes combined." - Fred Brooks, Jr., _The Mythical Man Month_ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove broken MTD drivers
On Tue, Jan 01, 2008 at 04:30:57PM +, David Woodhouse wrote: > On Tue, 2008-01-01 at 15:48 +0200, Adrian Bunk wrote: > > This patch removes two MTD drivers that have been marked as > > BROKEN 19 months ago due to requiring nonexisting header files. > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > Any particular reason you didn't Cc the authors identified in the > drivers you're removing? The header of ppchameleonevb.c claims it comes from [EMAIL PROTECTED] which bounces and the header of toto.c contains as only address Thomas' address (I took the wrong one from the commit, but bounced the email to him). > dwmw2 cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
