Re: [PATCH 1/10] kconfig: update-po-config info
On Fri, Jan 11, 2008 at 11:40:00PM +0100, EGRY Gabor wrote: > > This patch adds tracking messages. > > Signed-off-by: Egry Gabor <[EMAIL PROTECTED]> > Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]> To anyone that try out this patch serie just a minor note. "make update-po-config" will fail if applied on top of kbuild.git. This is because cris does some tricks with symlinks to source the correct Kconfig file. The Axis' people already fixed this and the fix is in -mm and so I asked Egry not to workaround this issue in this patchset. The quick workaround is to just delete the cris directory in arch/ if you try it out. When we hit the merge window it will be fixed in a proper way by the patch from Axis. At present menuconfig does not support wide chars which I guess some would like to see. I know Egry has this in the works and I hope to apply that patch soon. The full patch serie posted here will apprear in kbuild.git later today so we hopefully can have it beaten a little in -mm before the merge window. It is late in the cycle but the patches are nicely splitted and easy to review. Sam > --- > > kbuild-szilard/scripts/kconfig/Makefile | 18 +++--- > 1 file changed, 11 insertions(+), 7 deletions(-) > > diff -puN scripts/kconfig/Makefile~kconfig-i18n-02-update-po-fix > scripts/kconfig/Makefile > --- kbuild/scripts/kconfig/Makefile~kconfig-i18n-02-update-po-fix > 2008-01-11 22:16:06.0 +0100 > +++ kbuild-szilard/scripts/kconfig/Makefile 2008-01-11 22:27:38.0 > +0100 > @@ -24,22 +24,25 @@ oldconfig: $(obj)/conf > silentoldconfig: $(obj)/conf > $< -s $(Kconfig) > > -# Create new linux.po file > +# Create new linux.pot file > # Adjust charset to UTF-8 in .po file to accept UTF-8 in Kconfig files > # The symlink is used to repair a deficiency in arch/um > update-po-config: $(obj)/kxgettext > - xgettext --default-domain=linux \ > + $(Q)echo " GEN config" > + $(Q)xgettext --default-domain=linux \ > --add-comments --keyword=_ --keyword=N_ \ > --from-code=UTF-8\ > --files-from=scripts/kconfig/POTFILES.in \ > --output $(obj)/config.pot > $(Q)sed -i s/CHARSET/UTF-8/ $(obj)/config.pot > $(Q)ln -fs Kconfig.i386 arch/um/Kconfig.arch > - (for i in `ls arch/`;\ > - do \ > - $(obj)/kxgettext arch/$$i/Kconfig; \ > - done ) >> $(obj)/config.pot > - msguniq --sort-by-file --to-code=UTF-8 $(obj)/config.pot \ > + $(Q)(for i in `ls arch/`;\ > + do \ > + echo " GEN $$i";\ > + $(obj)/kxgettext arch/$$i/Kconfig\ > + >> $(obj)/config.pot; \ > + done ) > + $(Q)msguniq --sort-by-file --to-code=UTF-8 $(obj)/config.pot \ > --output $(obj)/linux.pot > $(Q)rm -f arch/um/Kconfig.arch > $(Q)rm -f $(obj)/config.pot > @@ -138,6 +141,7 @@ endif > clean-files := lkc_defs.h qconf.moc .tmp_qtcheck \ > .tmp_gtkcheck zconf.tab.c lex.zconf.c zconf.hash.c > clean-files += mconf qconf gconf > +clean-files += config.pot linux.pot > > # Check that we have the required ncurses stuff installed for lxdialog > (menuconfig) > PHONY += $(obj)/dochecklxdialog > _ > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Robert Hancock wrote: > There's this patch which was intended to fix it: > > http://lkml.org/lkml/2007/11/22/148 I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is normaly detected as: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray But I cannot mount it. All my attempts failed with ISOFS: Unable to identify CD-ROM format. With mem<=4098M or sata_nv.adma=0 it still mounts and works 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/
Re: [i2c] [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
Hi Jon,
On Fri, 11 Jan 2008 20:20:15 +0100, Jean Delvare wrote:
> > +{
> > + /* only powerpc drivers implement the id_table,
> > +* it is empty on other platforms */
> > + if (id) {
> > + while (id->name[0]) {
> > + if (strcmp(client->driver_name, id->name) == 0)
>
> This doesn't look right to me. You should be comparing client->name,
> not client->driver_name, with id->name. Where id_table is implemented,
> client->driver_name might not even be set. I see that the next patch in
> the series makes use of client->driver_name as well, so your code
> "works"... but this ain't correct still.
Err, scratch this (and related comments), I just realized what you were
trying to do. That's different from what I had in mind and so I read
your code wrong. I'll read it (and test it) again not making this
incorrect assumption and my comments will likely be different after
that. Well, I still think that it needs to be changed a bit, but
probably not in the direction I suggested at first (which, I realize
now, has its own share of issues - so it's not fair to me to point you
there.)
Sorry for the trouble. I'll post updated comments later today, but I'm
also pretty busy with other issues, some of which need to be solved
before 2.6.24 is released so I can't really delay them.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
On Fri, 11 Jan 2008 15:16:57 -0500, Jon Smirl wrote: > On 1/11/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > Secondly, it promotes OF device names as acceptable aliases. This I > > don't think I agree with. While I see some value in moving the OF name > > -> Linux name translation to the drivers themselves (even though I > > don't see this as a mandatory move either), this doesn't imply that OF > > names should be used as aliases. I don't like the idea that different > > architectures will name the same device differently in a visible way. > > This could easily break user-space code that makes assumptions on the > > device names (libsensors comes to mind.) So, I think that this part > > will need some more discussion. > > They're aliases. On the x86 my e1000 Ethernet driver loads using this > alias name: > "pci:v8086d1010sv*sd*bc*sc*i*" > In fact, the e1000 driver has 63 alias names in addition to "e1000" > > But it's still the e1000 driver after it is loaded. > [EMAIL PROTECTED]:/home/linux/drivers/net/e1000$ lsmod | grep e1000 > e1000 115968 0 > > Loading a I2C driver with an OF alias name is not going to change the > module name after it is loaded. In fact, once the module is in memory > there's no way to tell what name was used to load it. Of course. That's not what I was worried about... what I was worried about is something your patch set doesn't do but I misread the code and I thought it was doing. I'll read it again before I make more comments on this. > OF device names are set by the Open Firmware committee. It is not > reasonable to force the Linux names back into Open Firmware since this > would force the other operating systems using Open Firmware to adopt > the Linux names. I never meant to force the Linux names into Open Firmware. It wouldn't make sense especially when the Linux names are invented by random contributors with no specific rules, and can even change over time. What I meant is that the translation from Open Firmware device name to Linux device name could happen in different ways. Making module aliases out of the is one possibility but this is not the only one. I am curious why the translation could not happen "offline". As I understand it, you're getting the device names from these .dts files. However you're not parsing them in the kernel directly, are you? I presume that you have some tool that converts these files into C code that the kernel can use? This conversion tool could translate the names. > This issue hasn't been visible before since there was a global table > in the PowerPC code mapping all known Open Firmware names into linux > names. Keeping this as a global table doesn't scale. The mapping needs > to be done by each device individually. Looking at your patch set, I see only 11 entries in the table (in arch/powerpc/sysdev/fsl_soc.c) that patch #2 deletes. Are there more in other files? I'm asking because 11 entries hardly qualifies as "doesn't scale". I sure hope that you're not doing all this for the sole purpose of getting rid of this 11-element table. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lenovo ThinkPads need acpi_osi="Linux"
On Friday 11 January 2008 21:23, Henrique de Moraes Holschuh wrote: > While helping a user find out what happened to his mute key, I found out > that the Lenovo BIOSes need the OSI string Linux defined to behave properly > in Linux. > > Lenovo has been attempting to make things a bit easier for Linux on their > ThinkPads, by disabling the more obnoxious behaviours of the firmware (used > by their Windows drivers) when in Linux. It looks like they used the OSI > string for that. > > It is probably worthwhile to give a head's up: regressions involving > thinkpads and 2.6.23+ should probably have a 'please test with > acpi_osi="Linux"' step added if there is any chance ACPI AML code, BIOS or > SMBIOS code, or EC behaviour could be involved. > > The most concrete example I have right now of changed behaviour is the Mute > key on the T61, which just plain disappears if acpi_osi="!Linux" (2.6.23 > default). > > I have also seen some hacked DSDTs around (mostly for older T4x models) > which used the Linux OSI string to fix or work around AML weirdness. Those > would break in 2.6.23 (and 2.6.24?) as well. > > Now, what should we do about it? Add a quirk to always define the Linux OSI > string on ThinkPads (based on DMI information)? All IBM ones (which won't > have BIOS revisions anymore, anyway) deal well with it, and Lenovo ones > seem to benefit from it. > > We could also ask Lenovo to change the BIOS to stop paying attention to that > OSI string, but they will likely want/need a trigger for the AML code to > know it should change behaviour anyway, and the OSI string *does* look like > the proper thing to use IMHO. I don't know if we could get them to arrive > to a behaviour that is acceptable both to us, and also to their Windows > drivers... > I discussed this with Lenovo a few months ago and made it clear that Linux will unlikely default to answer yes to OSI(Linux) in the future -- for all the reasons I stated when I disabled it. However, they told me they wanted to use OSI(Linux) to enable the backlight (via video re-post) on S3 resume, and the problem at hand was a distro kernel which still had OSI(Linux), so that is what they did. I was unaware that they're using it for anything else, and the fact that they are lends further support to the case that as an OS interface string "Linux" is too vague to be meaningful. They seemed open to looking for another string, say "Needs S3 video re-post". However, we didn't agree on such a string, and so it isn't in Linux or the Lenovo BIOS. I think until we have native Linux graphics driver for (fast) backlight restore, we need to add a DMI to enable OSI(Linux) for the offending Lenovo models. We'll need to have some coordination with the graphics guys so that they can turn this off from user-space when they don't need it. The reason it shoudl be turned off is that backlight enabling backlight from a native graphics driver is much faster than running through the video BIOS POST. So if we keep the OSI(Linux) video BIOS POST workaround in place permanently, it would put Linux at a permanent performance disadvantage to Windows. cheers, -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] x86: Fix singlestep handling in reenter_kprobe
Highlight peculiar cases in singles-step kprobe handling.
In reenter_kprobe(), a breakpoint in KPROBE_HIT_SS case can only occur when
single-stepping a breakpoint on which a probe was installed. Since such probes
are single-stepped inline, identifying these cases is unambiguous. All other
cases leading up to KPROBE_HIT_SS are possible bugs. Identify and WARN_ON such
cases.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 93aff49..afb5c96 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -443,17 +443,6 @@ void __kprobes arch_prepare_kretprobe(struct
kretprobe_instance *ri,
*sara = (unsigned long) &kretprobe_trampoline;
}
-static void __kprobes recursive_singlestep(struct kprobe *p,
- struct pt_regs *regs,
- struct kprobe_ctlblk *kcb)
-{
- save_previous_kprobe(kcb);
- set_current_kprobe(p, regs, kcb);
- kprobes_inc_nmissed_count(p);
- prepare_singlestep(p, regs);
- kcb->kprobe_status = KPROBE_REENTER;
-}
-
static void __kprobes setup_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
@@ -492,20 +481,29 @@ static int __kprobes reenter_kprobe(struct kprobe *p,
struct pt_regs *regs,
break;
#endif
case KPROBE_HIT_ACTIVE:
- recursive_singlestep(p, regs, kcb);
+ save_previous_kprobe(kcb);
+ set_current_kprobe(p, regs, kcb);
+ kprobes_inc_nmissed_count(p);
+ prepare_singlestep(p, regs);
+ kcb->kprobe_status = KPROBE_REENTER;
break;
case KPROBE_HIT_SS:
- if (*p->ainsn.insn == BREAKPOINT_INSTRUCTION) {
+ if (p == kprobe_running()) {
regs->flags &= ~TF_MASK;
regs->flags |= kcb->kprobe_saved_flags;
return 0;
} else {
- recursive_singlestep(p, regs, kcb);
+ /* A probe has been hit in the codepath leading up
+* to, or just after, single-stepping of a probed
+* instruction. This entire codepath should strictly
+* reside in .kprobes.text section. Raise a warning
+* to highlight this peculiar case.
+*/
}
- break;
default:
/* impossible cases */
WARN_ON(1);
+ return 0;
}
return 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system
On Fri, 2008-01-11 at 20:26 -0500, Benjamin LaHaise wrote: > Hello folks, > > I'd like to put the patch below out for comments to see if folks think the > approach is a valid fix to reduce the latency of synchronize_rcu(). The > motivation is that an otherwise idle system takes about 3 ticks per network > interface in unregister_netdev() due to multiple calls to synchronize_rcu(), > which adds up to quite a few seconds for tearing down thousands of > interfaces. By flushing pending rcu callbacks in the idle loop, the system > makes progress hundreds of times faster. If this is indeed a sane thing to, > it probably needs to be done for other architectures than x86. And yes, the > network stack shouldn't call synchronize_rcu() quite so much, but fixing that > is a little more involved. So, instead of only relying on the tick to drive the RCU state machine, you add the idle loop to it. This seems to make sense, esp because nohz is held off until rcu is idle too. Even though Andi is right in that its not the proper solution to your problem, I think its worth doing anyway for the general benefit of RCU. But lets ask Paul, he is Mr RCU after all :-) > diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c > index 9663c2a..592f6e4 100644 > --- a/arch/x86/kernel/process_32.c > +++ b/arch/x86/kernel/process_32.c > @@ -188,6 +188,9 @@ void cpu_idle(void) > rmb(); > idle = pm_idle; > > + if (rcu_pending(cpu)) > + rcu_check_callbacks(cpu, 0); > + > if (!idle) > idle = default_idle; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] reimplement nopfn callers with fault
On Fri, Jan 11, 2008 at 03:40:10PM +0100, Jes Sorensen wrote: > Nick Piggin wrote: > >Hi guys, > > > >I'd like to finally remove nopfn from the tree. So I would really like to > >get > >this patch into -mm soon (or broken out patches into appropriate trees). > > > >Anyway, I don't have a good way to compile mspec or cell changes very > >easily. > >Hopefully if there are any silly typos, they will be easier to fix. More > >problematic > >is actually testing the things; I'm not even sure I'm covering all bases > >with > >drm testing. > > > >So, if I could trouble you for a quick review and/or test at some time > >the > >patch is against latest -mm. > > Nick, > > Is this supposed to apply to the latest Linus tree? I applied it here > and the mspec driver lights up in beautiful fireworks :-( I'll give the > -mm tree a try next. Hi Jes, (reply to all this time). It is the BUG_ON(vma->vm_flags & VM_PFNMAP); at the start of __do_fault, by the looks. That should be simply removed. Sorry about that. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/2][RFC][BUG] msync: updating ctime and mtime at syncing
On Fri, 2008-01-11 at 03:44 +0300, Anton Salikhmetov wrote:
> +/*
> + * Update the ctime and mtime stamps after checking if they are to be
> updated.
> + */
> +void mapped_file_update_time(struct file *file)
> +{
> + if (test_and_clear_bit(AS_MCTIME, &file->f_mapping->flags)) {
> + get_file(file);
> + file_update_time(file);
> + fput(file);
> + }
> +}
> +
I don't think you need the get/put file stuff here, because
> @@ -87,6 +87,8 @@ long do_fsync(struct file *file, int datasync)
> goto out;
> }
>
> + mapped_file_update_time(file);
> +
> ret = filemap_fdatawrite(mapping);
>
> /*
at this call-site we already hold an extra reference on the file, and
> @@ -74,14 +79,17 @@ asmlinkage long sys_msync(unsigned long start, size_t
> len, int flags)
> break;
> }
> file = vma->vm_file;
> - if ((flags & MS_SYNC) && file && (vma->vm_flags & VM_SHARED)) {
> - get_file(file);
> - up_read(&mm->mmap_sem);
> - error = do_fsync(file, 0);
> - fput(file);
> - if (error)
> - return error;
> - down_read(&mm->mmap_sem);
> + if (file && (vma->vm_flags & VM_SHARED)) {
> + mapped_file_update_time(file);
> + if (flags & MS_SYNC) {
> + get_file(file);
> + up_read(&mm->mmap_sem);
> + error = do_fsync(file, 0);
> + fput(file);
> + if (error)
> + return error;
> + down_read(&mm->mmap_sem);
> + }
> }
>
> start = vma->vm_end;
here we hold the mmap_sem so the vma reference on the file can't go
away.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/7] Add class iteration api and convert semaphore to mutex
This series do three things:
1.[PATCH 1/7]
Add some class iteration functions in driver core:
class_for_each_device
class_find_device
class_for_each_child
class_find_child
2.[PATCH {2,3,4,5,6}/7]
Make the drivers with class iterating to use class iteration api.
3.[PATCH 7/7]
Convert the class semaphore to mutex.
toc:
---
1-driver-core-add-class-iteration-api.patch
2-ieee1394-use-class-iteration-api.patch
3-power_supply-use-class-iteration-api.patch
4-rtc-use-class-iteration-api.patch
5-scsi-use-class-iteration-api.patch
6-spi-use-class-iteration-api.patch
7-driver-core-class-convert-semaphore-to-mutex.patch
Summary diffstat:
---
drivers/base/class.c | 197 +--
drivers/base/core.c | 18 --
drivers/ieee1394/nodemgr.c| 319 +-
drivers/power/apm_power.c | 116 -
drivers/power/power_supply_core.c | 72
drivers/rtc/interface.c | 22 +-
drivers/scsi/hosts.c | 26 +--
drivers/spi/spi.c | 26 +--
include/linux/device.h| 11 +
9 files changed, 523 insertions(+), 284 deletions(-)
Thanks all your comment and help. If there's some problem in these ones, please
help to point out.
Thanks again.
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 2/2][RFC][BUG] msync: updating ctime and mtime at syncing
On Sat, 2008-01-12 at 10:36 +0100, Peter Zijlstra wrote:
> On Fri, 2008-01-11 at 03:44 +0300, Anton Salikhmetov wrote:
>
> > +/*
> > + * Update the ctime and mtime stamps after checking if they are to be
> > updated.
> > + */
> > +void mapped_file_update_time(struct file *file)
> > +{
> > + if (test_and_clear_bit(AS_MCTIME, &file->f_mapping->flags)) {
> > + get_file(file);
> > + file_update_time(file);
> > + fput(file);
> > + }
> > +}
> > +
>
> I don't think you need the get/put file stuff here, because
BTW, the reason for me noticing this is that if it would be needed there
is a race condition right there, who is to say that the file pointer
you're deref'ing in your test condition isn't a dead one already.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc7, intel audio: alsa doesn't say a beep
Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? "No sound" means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? There is no udelay() in the reverted patch. If I replace "udelay(10)" by "udelay(500)" in the original rc7, then there is still no sound. This is like fishing in the dark. We've got a working version. Why not keep it? Regards Harri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/7] driver-core : add class iteration api
Add the following class iteration functions for driver use:
class_for_each_device
class_find_device
class_for_each_child
class_find_child
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/base/class.c | 159 +
include/linux/device.h |8 ++
2 files changed, 167 insertions(+)
diff -upr linux/drivers/base/class.c linux.new/drivers/base/class.c
--- linux/drivers/base/class.c 2008-01-12 14:42:24.0 +0800
+++ linux.new/drivers/base/class.c 2008-01-12 14:42:24.0 +0800
@@ -798,6 +798,165 @@ void class_device_put(struct class_devic
kobject_put(&class_dev->kobj);
}
+/**
+ * class_for_each_device - device iterator
+ * @class: the class we're iterating
+ * @data: data for the callback
+ * @fn: function to be called for each device
+ *
+ * Iterate over @class's list of devices, and call @fn for each,
+ * passing it @data.
+ *
+ * We check the return of @fn each time. If it returns anything
+ * other than 0, we break out and return that value.
+ */
+int class_for_each_device(struct class *class, void *data,
+ int (*fn)(struct device *, void *))
+{
+ struct device *dev;
+ int error = 0;
+
+ if (!class)
+ return -EINVAL;
+ down(&class->sem);
+ list_for_each_entry(dev, &class->devices, node) {
+ dev = get_device(dev);
+ if (dev) {
+ error = fn(dev, data);
+ put_device(dev);
+ } else
+ error = -ENODEV;
+ if (error)
+ break;
+ }
+ up(&class->sem);
+
+ return error;
+}
+EXPORT_SYMBOL_GPL(class_for_each_device);
+
+/**
+ * class_find_device - device iterator for locating a particular device
+ * @class: the class we're iterating
+ * @data: data for the match function
+ * @match: function to check device
+ *
+ * This is similar to the class_for_each_dev() function above, but it
+ * returns a reference to a device that is 'found' for later use, as
+ * determined by the @match callback.
+ *
+ * The callback should return 0 if the device doesn't match and non-zero
+ * if it does. If the callback returns non-zero, this function will
+ * return to the caller and not iterate over any more devices.
+ */
+struct device *class_find_device(struct class *class, void *data,
+ int (*match)(struct device *, void *))
+{
+ struct device *dev;
+ int error = 1;
+
+ if (!class)
+ return NULL;
+
+ down(&class->sem);
+ list_for_each_entry(dev, &class->devices, node) {
+ dev = get_device(dev);
+ if (dev) {
+ if (match(dev, data)) {
+ error = 0;
+ break;
+ } else
+ put_device(dev);
+ } else
+ break;
+ }
+ up(&class->sem);
+
+ if (error)
+ return NULL;
+ return dev;
+}
+EXPORT_SYMBOL_GPL(class_find_device);
+
+/**
+ * class_for_each_child - class child iterator
+ * @class: the class we're iterating
+ * @data: data for the callback
+ * @fn: function to be called for each child of the class
+ *
+ * Iterate over @class's list of children, and call @fn for each,
+ * passing it @data.
+ *
+ * We check the return of @fn each time. If it returns anything
+ * other than 0, we break out and return that value.
+ */
+int class_for_each_child(struct class *class, void *data,
+ int (*fn)(struct class_device *, void *))
+{
+ struct class_device *dev;
+ int error = 0;
+
+ if (!class)
+ return -EINVAL;
+ down(&class->sem);
+ list_for_each_entry(dev, &class->children, node) {
+ dev = class_device_get(dev);
+ if (dev) {
+ error = fn(dev, data);
+ class_device_put(dev);
+ } else
+ error = -ENODEV;
+ if (error)
+ break;
+ }
+ up(&class->sem);
+
+ return error;
+}
+EXPORT_SYMBOL_GPL(class_for_each_child);
+
+/**
+ * class_find_child - device iterator for locating a particular class_device
+ * @class: the class we're iterating
+ * @data: data for the match function
+ * @match: function to check class_device
+ *
+ * This is similar to the class_for_each_child() function above, but it
+ * returns a reference to a class_device that is 'found' for later use, as
+ * determined by the @match callback.
+ *
+ * The callback should return 0 if the class_device doesn't match and non-zero
+ * if it does. If the callback returns non-zero, this function will
+ * return to the caller and not iterate over any more class_devices.
+ */
+struct class_device *cl
Re: [RFC][PATCH] per-task I/O throttling
On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote: > On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said: > > > The interesting feature is that it allows to set a priority for each > > process container, but AFAIK it doesn't allow to "partition" the > > bandwidth between different containers (that would be a nice feature > > IMHO). For example it would be great to be able to define per-container > > limits, like assign 10MB/s for processes in container A, 30MB/s to > > container B, 20MB/s to container C, etc. > > Has anybody considered allocating based on *seeks* rather than bytes moved, > or counting seeks as "virtual bytes" for the purposes of accounting (if the > disk can do 50mbytes/sec, and a seek takes 5millisecs, then count it as 100K > of data)? I was considering a time scheduler, you can fill your time slot with seeks or data, it might be what CFQ does, but I've never even read the code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/7] ieee1394 : use class iteration api
Convert to use the class iteration api.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/ieee1394/nodemgr.c | 319 +
1 file changed, 178 insertions(+), 141 deletions(-)
diff -upr linux/drivers/ieee1394/nodemgr.c linux.new/drivers/ieee1394/nodemgr.c
--- linux/drivers/ieee1394/nodemgr.c2008-01-12 15:20:27.0 +0800
+++ linux.new/drivers/ieee1394/nodemgr.c2008-01-12 15:20:27.0
+0800
@@ -727,36 +727,35 @@ static int nodemgr_bus_match(struct devi
static DEFINE_MUTEX(nodemgr_serialize_remove_uds);
+static int __match_ne(struct device *dev, void *data)
+{
+ struct unit_directory *ud;
+ struct node_entry *ne = (struct node_entry *)data;
+
+ ud = container_of(dev, struct unit_directory, unit_dev);
+ if (ud->ne == ne)
+ return 1;
+ return 0;
+}
+
static void nodemgr_remove_uds(struct node_entry *ne)
{
struct device *dev;
- struct unit_directory *tmp, *ud;
+ struct unit_directory *ud;
- /* Iteration over nodemgr_ud_class.devices has to be protected by
-* nodemgr_ud_class.sem, but device_unregister() will eventually
-* take nodemgr_ud_class.sem too. Therefore pick out one ud at a time,
-* release the semaphore, and then unregister the ud. Since this code
-* may be called from other contexts besides the knodemgrds, protect the
-* gap after release of the semaphore by nodemgr_serialize_remove_uds.
+ /* Use class_find device to iterate the devices. Since this code
+* may be called from other contexts besides the knodemgrds,
+* protect it by nodemgr_serialize_remove_uds.
*/
mutex_lock(&nodemgr_serialize_remove_uds);
- for (;;) {
- ud = NULL;
- down(&nodemgr_ud_class.sem);
- list_for_each_entry(dev, &nodemgr_ud_class.devices, node) {
- tmp = container_of(dev, struct unit_directory,
- unit_dev);
- if (tmp->ne == ne) {
- ud = tmp;
- break;
- }
- }
- up(&nodemgr_ud_class.sem);
- if (ud == NULL)
- break;
- device_unregister(&ud->unit_dev);
- device_unregister(&ud->device);
+ dev = class_find_device(&nodemgr_ud_class, ne, __match_ne);
+ if (!dev) {
+ mutex_unlock(&nodemgr_serialize_remove_uds);
+ return;
}
+ ud = container_of(dev, struct unit_directory, unit_dev);
+ device_unregister(&ud->unit_dev);
+ device_unregister(&ud->device);
mutex_unlock(&nodemgr_serialize_remove_uds);
}
@@ -882,45 +881,64 @@ fail_alloc:
return NULL;
}
+static int __match_ne_guid(struct device *dev, void *data)
+{
+ struct node_entry *ne;
+ u64 *guid = (u64 *)data;
+
+ ne = container_of(dev, struct node_entry, node_dev);
+ if (ne->guid == *guid)
+ return 1;
+ return 0;
+}
static struct node_entry *find_entry_by_guid(u64 guid)
{
struct device *dev;
- struct node_entry *ne, *ret_ne = NULL;
-
- down(&nodemgr_ne_class.sem);
- list_for_each_entry(dev, &nodemgr_ne_class.devices, node) {
- ne = container_of(dev, struct node_entry, node_dev);
+ struct node_entry *ne;
- if (ne->guid == guid) {
- ret_ne = ne;
- break;
- }
- }
- up(&nodemgr_ne_class.sem);
+ dev = class_find_device(&nodemgr_ne_class, &guid, __match_ne_guid);
+ if (!dev)
+ return NULL;
+ ne = container_of(dev, struct node_entry, node_dev);
- return ret_ne;
+ return ne;
}
+struct match_nodeid_param {
+ struct hpsb_host *host;
+ nodeid_t nodeid;
+};
+
+static int __match_ne_nodeid(struct device *dev, void *data)
+{
+ struct node_entry *ne;
+ struct match_nodeid_param *param = (struct match_nodeid_param *)data;
+
+ if (!dev)
+ return 0;
+ ne = container_of(dev, struct node_entry, node_dev);
+ if (ne->host == param->host && ne->nodeid == param->nodeid)
+ return 1;
+ return 0;
+}
static struct node_entry *find_entry_by_nodeid(struct hpsb_host *host,
nodeid_t nodeid)
{
struct device *dev;
- struct node_entry *ne, *ret_ne = NULL;
+ struct node_entry *ne;
+ struct match_nodeid_param param;
- down(&nodemgr_ne_class.sem);
- list_for_each_entry(dev, &nodemgr_ne_class.devices, node) {
- ne = container_of(dev, struct node_entry, node_dev);
+ param.host = host;
+ param.nodeid = nodeid;
- if (ne->host == host && ne->nodeid == nodeid) {
-
[PATCH 3/7] power supply : use class iteration api
Convert to use the class iteration api.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/power/apm_power.c | 116 ++
drivers/power/power_supply_core.c | 72 ---
2 files changed, 106 insertions(+), 82 deletions(-)
diff -upr linux/drivers/power/apm_power.c linux.new/drivers/power/apm_power.c
--- linux/drivers/power/apm_power.c 2008-01-11 18:06:38.0 +0800
+++ linux.new/drivers/power/apm_power.c 2008-01-11 18:06:38.0 +0800
@@ -13,6 +13,7 @@
#include
#include
+static DEFINE_MUTEX(apm_mutex);
#define PSY_PROP(psy, prop, val) psy->get_property(psy, \
POWER_SUPPLY_PROP_##prop, val)
@@ -23,67 +24,86 @@
static struct power_supply *main_battery;
-static void find_main_battery(void)
-{
- struct device *dev;
- struct power_supply *bat = NULL;
- struct power_supply *max_charge_bat = NULL;
- struct power_supply *max_energy_bat = NULL;
+struct find_bat_param {
+ struct power_supply *main;
+ struct power_supply *bat;
+ struct power_supply *max_charge_bat;
+ struct power_supply *max_energy_bat;
union power_supply_propval full;
- int max_charge = 0;
- int max_energy = 0;
+ int max_charge;
+ int max_energy;
+};
- main_battery = NULL;
+static int __find_main_battery(struct device *dev, void *data)
+{
+ struct find_bat_param *bp = (struct find_bat_param *)data;
- list_for_each_entry(dev, &power_supply_class->devices, node) {
- bat = dev_get_drvdata(dev);
+ bp->bat = dev_get_drvdata(dev);
- if (bat->use_for_apm) {
- /* nice, we explicitly asked to report this battery. */
- main_battery = bat;
- return;
- }
+ if (bp->bat->use_for_apm) {
+ /* nice, we explicitly asked to report this battery. */
+ bp->main = bp->bat;
+ return 1;
+ }
- if (!PSY_PROP(bat, CHARGE_FULL_DESIGN, &full) ||
- !PSY_PROP(bat, CHARGE_FULL, &full)) {
- if (full.intval > max_charge) {
- max_charge_bat = bat;
- max_charge = full.intval;
- }
- } else if (!PSY_PROP(bat, ENERGY_FULL_DESIGN, &full) ||
- !PSY_PROP(bat, ENERGY_FULL, &full)) {
- if (full.intval > max_energy) {
- max_energy_bat = bat;
- max_energy = full.intval;
- }
+ if (!PSY_PROP(bp->bat, CHARGE_FULL_DESIGN, &bp->full) ||
+ !PSY_PROP(bp->bat, CHARGE_FULL, &bp->full)) {
+ if (bp->full.intval > bp->max_charge) {
+ bp->max_charge_bat = bp->bat;
+ bp->max_charge = bp->full.intval;
+ }
+ } else if (!PSY_PROP(bp->bat, ENERGY_FULL_DESIGN, &bp->full) ||
+ !PSY_PROP(bp->bat, ENERGY_FULL, &bp->full)) {
+ if (bp->full.intval > bp->max_energy) {
+ bp->max_energy_bat = bp->bat;
+ bp->max_energy = bp->full.intval;
}
}
+ return 0;
+}
+
+static void find_main_battery(void)
+{
+ struct find_bat_param bp;
+ int error;
+
+ memset(&bp, 0, sizeof(struct find_bat_param));
+ main_battery = NULL;
+ bp.main = main_battery;
+
+ error = class_for_each_device(power_supply_class, &bp,
+ __find_main_battery);
+ if (error) {
+ main_battery = bp.main;
+ return;
+ }
- if ((max_energy_bat && max_charge_bat) &&
- (max_energy_bat != max_charge_bat)) {
+ if ((bp.max_energy_bat && bp.max_charge_bat) &&
+ (bp.max_energy_bat != bp.max_charge_bat)) {
/* try guess battery with more capacity */
- if (!PSY_PROP(max_charge_bat, VOLTAGE_MAX_DESIGN, &full)) {
- if (max_energy > max_charge * full.intval)
- main_battery = max_energy_bat;
+ if (!PSY_PROP(bp.max_charge_bat, VOLTAGE_MAX_DESIGN,
+ &bp.full)) {
+ if (bp.max_energy > bp.max_charge * bp.full.intval)
+ main_battery = bp.max_energy_bat;
else
- main_battery = max_charge_bat;
- } else if (!PSY_PROP(max_energy_bat, VOLTAGE_MAX_DESIGN,
- &full)) {
- if (max_charge > max_energy / full.intval)
- main_battery = max_charge_bat;
+ main_battery
Re: 2.6.24-rc4 hwmon it87 probe fails
Hi Bjorn, Sorry for the late answer. On Wed, 2 Jan 2008 11:30:55 -0700, Bjorn Helgaas wrote: > Even if the BIOS does not declare an IT87xxF as an independent device, > there may be AML that uses the chip internally. For example, the > BIOS could declare a thermal zone with a _TMP method, and the _TMP > method could use the IT87xxF to read the temperature. In that case, > the BIOS would still need to declare the IT87xxF resources so the OS > doesn't place another device on top of it. Thomas Renninger's patch set should handle this case. It's in -mm at the moment and I guess we'll merge most of it in 2.6.25. > (...) An easy way to do this > is with a PNP0C02 "motherboard" device, which just says "these > resources are in use, but the OS needn't attach a driver to this > device." How do I see if a given motherboard does this or not? For example I have a motherboard here that says: 0290-029f : pnp 00:04 How do I know if this is a "PNP0C02 motherboard device" I am supposed not to touch, or a device that I can attach a native hwmon driver to? And more importantly, how does the it87 driver (or any other hwmon driver) know about it? I'm all for updating the hwmon drivers to cooperate better with PNP in order to prevent clashes between the BIOS and the OS, but I just don't know how I am supposed to do that. > > And what "collision" are you talking about? > > I meant the problem where we place two devices at the same address, > causing one to stop working. I wrote "even if it87 isn't present," > which is ambiguous -- I meant that we need something that works even > when the it87 _driver_ isn't present. I agree then. I don't think this has much to do with PNP though. What this is calling for is a Super-I/O subsystem that detects the Super-I/O and instantiate devices out of it. That way the drivers for these devices (in particular hardware monitoring drivers, watchdog drivers, some parport drivers...) would no longer need to instantiate their devices themselves, thus matching the device driver model much better. I've seen patches float around but so far I could never find the time to look into them (and I fear it's unlikely to change anytime soon.) > (...) > Well, it's true that PNP does not need to describe ALL devices in the > system. However, it should describe all devices to which the OS should > bind a driver. The BIOS writer has the discretion to hide devices from > the OS by omitting them from the ACPI namespace. If he does that, his > assumption is that the OS will ignore the device (but of course, he's > thinking about a Plug-and-Play-compliant OS like Windows). Even under Windows, I pretty much doubt that any monitoring application cares about what the BIOS says. Motherboard vendor applications have enough information about each board model to know what they can do or not without asking the BIOS. Third-party applications probably just poke at known I/O locations (pretty much like the Linux hwmon drivers do) and hope for the best. > (...) > I think my patch to request only the ports actually used by the it87 > driver is sufficient to solve the current problem. If we find that > a BIOS neglects to reserve some of the ports decoded by the IT87xxF, > we can add a PNP quirk to handle that. But I'm not aware of any > problems like that yet. I'm not aware of such a problem either. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] rtc : use class iteration api
Convert to use the class iteration api.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/rtc/interface.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff -upr linux/drivers/rtc/interface.c linux.new/drivers/rtc/interface.c
--- linux/drivers/rtc/interface.c 2008-01-11 18:06:38.0 +0800
+++ linux.new/drivers/rtc/interface.c 2008-01-11 18:06:38.0 +0800
@@ -251,20 +251,23 @@ void rtc_update_irq(struct rtc_device *r
}
EXPORT_SYMBOL_GPL(rtc_update_irq);
+static int __rtc_match(struct device *dev, void *data)
+{
+ char *name = (char *)data;
+
+ if (strncmp(dev->bus_id, name, BUS_ID_SIZE) == 0)
+ return 1;
+ return 0;
+}
+
struct rtc_device *rtc_class_open(char *name)
{
struct device *dev;
struct rtc_device *rtc = NULL;
- down(&rtc_class->sem);
- list_for_each_entry(dev, &rtc_class->devices, node) {
- if (strncmp(dev->bus_id, name, BUS_ID_SIZE) == 0) {
- dev = get_device(dev);
- if (dev)
- rtc = to_rtc_device(dev);
- break;
- }
- }
+ dev = class_find_device(rtc_class, name, __rtc_match);
+ if (dev)
+ rtc = to_rtc_device(dev);
if (rtc) {
if (!try_module_get(rtc->owner)) {
@@ -272,7 +275,6 @@ struct rtc_device *rtc_class_open(char *
rtc = NULL;
}
}
- up(&rtc_class->sem);
return rtc;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] scsi : use class iteration api
Convert to use the class iteration api.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/scsi/hosts.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff -upr linux/drivers/scsi/hosts.c linux.new/drivers/scsi/hosts.c
--- linux/drivers/scsi/hosts.c 2008-01-12 15:54:16.0 +0800
+++ linux.new/drivers/scsi/hosts.c 2008-01-12 15:54:16.0 +0800
@@ -429,6 +429,17 @@ void scsi_unregister(struct Scsi_Host *s
}
EXPORT_SYMBOL(scsi_unregister);
+static int __scsi_host_match(struct class_device *cdev, void *data)
+{
+ struct Scsi_Host *p;
+ unsigned short *hostnum = (unsigned short *)data;
+
+ p = class_to_shost(cdev);
+ if (p->host_no == *hostnum)
+ return 1;
+ return 0;
+}
+
/**
* scsi_host_lookup - get a reference to a Scsi_Host by host no
*
@@ -439,19 +450,12 @@ EXPORT_SYMBOL(scsi_unregister);
**/
struct Scsi_Host *scsi_host_lookup(unsigned short hostnum)
{
- struct class *class = &shost_class;
struct class_device *cdev;
- struct Scsi_Host *shost = ERR_PTR(-ENXIO), *p;
+ struct Scsi_Host *shost = ERR_PTR(-ENXIO);
- down(&class->sem);
- list_for_each_entry(cdev, &class->children, node) {
- p = class_to_shost(cdev);
- if (p->host_no == hostnum) {
- shost = scsi_host_get(p);
- break;
- }
- }
- up(&class->sem);
+ cdev = class_find_child(&shost_class, &hostnum, __scsi_host_match);
+ if (cdev)
+ shost = scsi_host_get(class_to_shost(cdev));
return shost;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] spi : use class iteration api
Convert to use the class iteration api.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/spi/spi.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff -upr linux/drivers/spi/spi.c linux.new/drivers/spi/spi.c
--- linux/drivers/spi/spi.c 2008-01-11 18:06:38.0 +0800
+++ linux.new/drivers/spi/spi.c 2008-01-11 18:06:38.0 +0800
@@ -485,6 +485,17 @@ void spi_unregister_master(struct spi_ma
}
EXPORT_SYMBOL_GPL(spi_unregister_master);
+static int __spi_master_match(struct device *dev, void *data)
+{
+ struct spi_master *m;
+ u16 *bus_num = (u16 *)data;
+
+ m = container_of(dev, struct spi_master, dev);
+ if (m->bus_num == *bus_num)
+ return 1;
+ return 0;
+}
+
/**
* spi_busnum_to_master - look up master associated with bus_num
* @bus_num: the master's bus number
@@ -499,17 +510,12 @@ struct spi_master *spi_busnum_to_master(
{
struct device *dev;
struct spi_master *master = NULL;
- struct spi_master *m;
- down(&spi_master_class.sem);
- list_for_each_entry(dev, &spi_master_class.children, node) {
- m = container_of(dev, struct spi_master, dev);
- if (m->bus_num == bus_num) {
- master = spi_master_get(m);
- break;
- }
- }
- up(&spi_master_class.sem);
+ dev = class_find_device(&spi_master_class, &bus_num,
+ __spi_master_match);
+ if (dev)
+ master = container_of(dev, struct spi_master, dev);
+ /* reference got in class_find_device */
return master;
}
EXPORT_SYMBOL_GPL(spi_busnum_to_master);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc4 hwmon it87 probe fails
Hi Robert, On Wed, 19 Dec 2007 19:09:54 -0600, Robert Hancock wrote: > It's quite possible that the BIOS accesses the device either from ACPI > AML or possibly even from SMI. In that case it would be quite reasonable > for the BIOS to reserve that region to prevent another driver from > loading and trying to take conflicting control of the device. One has to > be careful before assuming that any such reservation is bogus. Again I am all for honoring such BIOS requests so as to prevent conflicts between ACPI or SMI and native drivers. The problem is that no two BIOS out there do the same in this respect. I couldn't see any correlation between machines declaring their hwmon device in PNP and machines where ACPI or SMI access the device in question. Many boards declare their device and seemingly never touch it so it's fine for Linux to drive them. Some boards no not declare the devices but still access them in our back. Thomas' patches should deal with the ACPI AML case in most cases, but not with SMI. So either the PNP code in Linux isn't exporting enough details to differentiate, or even the PNP code has no way to tell these cases apart. In the latter case there's not much we can do. In the former case, let's have the PNP code export the information so that hwmon drivers can decide whether they should bind to the devices or not by default. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64: disable the GART early v2
please check the one against x86.git
it will use fix e820 for gart.
YH
[PATCH] x86-64: fix e820 for GART or disable the GART early
For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed.
when try to use kexec second kernel, and the first doesn't include
gart_shutdown.
the second kernel could have different aper position than the first kernel. and
second
kernel could use that hole as RAM that is still used by GART set by the first
kernel.
esp. when try to kexec 2.6.24 with sparse mem enable from previous kernel (from
RHEL 5
or SLES 10). the new kernel will use aper by GART (set by first kernel) for
vmemmap.
and after new kernel setting one new GART. the position will be real RAM. the
_mapcount
set is lost.
Bad page state in process 'swapper'
page:e2000e600020 flags:0x mapping:
mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13
Call Trace:
[] bad_page+0x63/0x8d
[] __free_pages_ok+0x7c/0x2a5
[] free_all_bootmem_core+0xd0/0x198
[] numa_free_all_bootmem+0x3b/0x76
[] mem_init+0x3b/0x152
[] start_kernel+0x236/0x2c2
[] _sinittext+0x11a/0x121
and
[e2000e60-e2000e7f] PMD ->81001c20 on node 0
phys addr is : 0x1c20
RHEL 5.1 kernel -53 said:
PCI-DMA: aperture base @ 1c00 size 65536 KB
new kernel said:
Mapping aperture over 65536 KB of RAM @ 3c00
So could try to disable that GART if possible.
According to Ingo
> hm, i'm wondering, instead of modifying the GART, why dont we simply
> _detect_ whatever GART settings we have inherited, and propagate that
> into our e820 maps? I.e. if there's inconsistency, then punch that out
> from the memory maps and just dont use that memory.
>
> that way it would not matter whether the GART settings came from a [old
> or crashing] Linux kernel that has not called gart_iommu_shutdown(), or
> whether it's a BIOS that has set up an aperture hole inconsistent with
> the memory map it passed. (or the memory map we _think_ i tried to pass
> us)
>
> it would also be more robust to only read and do a memory map quirk
> based on that, than actively trying to change the GART so early in the
> bootup. Later on we have to re-enable the GART _anyway_ and have to
> punch a hole for it.
>
> and as a bonus, we would have shored up our defenses against crappy
> BIOSes as well.
add e820 modification for gart inconsistent setting.
gart_fix_e820=off could be used to disable e820 fix.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/aperture_64.c
===
--- linux-2.6.orig/arch/x86/kernel/aperture_64.c
+++ linux-2.6/arch/x86/kernel/aperture_64.c
@@ -218,6 +218,95 @@ static __u32 __init search_agp_bridge(u3
return 0;
}
+static int gart_fix_e820 __initdata = 1;
+
+static int __init parse_gart_mem(char *p)
+{
+ if (!p)
+ return -EINVAL;
+
+ if (!strncmp(p, "off", 3))
+ gart_fix_e820 = 0;
+ else if (!strncmp(p, "on", 2))
+ gart_fix_e820 = 1;
+
+return 0;
+}
+early_param("gart_fix_e820", parse_gart_mem);
+
+void __init early_gart_iommu_check(void)
+{
+ /*
+* in case it is enabled before, esp for kexec/kdump,
+* previous kernel already enable that. memset called
+* by allocate_aperture/__alloc_bootmem_nopanic cause restart.
+* or second kernel have different position for GART hole. and new
+* kernel could use hole as RAM that is still used by GART set by
+* first kernel
+* or BIOS forget to put that in reserved.
+* try to update e820 to make that region as reserved.
+*/
+ int fix, num;
+ u32 ctl;
+ u32 aper_size = 0, aper_order = 0, last_aper_order = 0;
+ u64 aper_base = 0, last_aper_base = 0;
+ int aper_enabled = 0, last_aper_enabled = 0;
+
+ if (!early_pci_allowed())
+ return;
+
+ fix = 0;
+ for (num = 24; num < 32; num++) {
+ if (!early_is_k8_nb(read_pci_config(0, num, 3, 0x00)))
+ continue;
+
+ ctl = read_pci_config(0, num, 3, 0x90);
+ aper_enabled = ctl & 1;
+ aper_order = (ctl >> 1) & 7;
+ aper_size = (32 * 1024 * 1024) << aper_order;
+ aper_base = read_pci_config(0, num, 3, 0x94) & 0x7fff;
+ aper_base <<= 25;
+
+ if ((last_aper_order && aper_order != last_aper_order) ||
+ (last_aper_base && aper_base != last_aper_base) ||
+ (last_aper_enabled && aper_enabled != last_aper_enabled)) {
+ fix = 1;
+ break;
+ }
+ last_aper_order = aper_order;
+ last_aper_base = aper_base;
+ last_aper_enabled = aper_enabled;
+
[PATCH 7/7] driver-core : convert semaphore to mutex in struct class
Convert the class semaphore to mutex.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/base/class.c | 38 +++---
drivers/base/core.c| 18 --
include/linux/device.h |3 ++-
3 files changed, 29 insertions(+), 30 deletions(-)
diff -upr linux/drivers/base/class.c linux.new/drivers/base/class.c
--- linux/drivers/base/class.c 2008-01-12 16:11:07.0 +0800
+++ linux.new/drivers/base/class.c 2008-01-12 16:11:08.0 +0800
@@ -144,7 +144,7 @@ int class_register(struct class * cls)
INIT_LIST_HEAD(&cls->devices);
INIT_LIST_HEAD(&cls->interfaces);
kset_init(&cls->class_dirs);
- init_MUTEX(&cls->sem);
+ mutex_init(&cls->mutex);
error = kobject_set_name(&cls->subsys.kobj, "%s", cls->name);
if (error)
return error;
@@ -617,13 +617,13 @@ int class_device_add(struct class_device
kobject_uevent(&class_dev->kobj, KOBJ_ADD);
/* notify any interfaces this device is now here */
- down(&parent_class->sem);
+ mutex_lock_nested(&parent_class->mutex, SINGLE_DEPTH_NESTING);
list_add_tail(&class_dev->node, &parent_class->children);
list_for_each_entry(class_intf, &parent_class->interfaces, node) {
if (class_intf->add)
class_intf->add(class_dev, class_intf);
}
- up(&parent_class->sem);
+ mutex_unlock(&parent_class->mutex);
goto out1;
@@ -725,12 +725,12 @@ void class_device_del(struct class_devic
struct class_interface *class_intf;
if (parent_class) {
- down(&parent_class->sem);
+ mutex_lock(&parent_class->mutex);
list_del_init(&class_dev->node);
list_for_each_entry(class_intf, &parent_class->interfaces, node)
if (class_intf->remove)
class_intf->remove(class_dev, class_intf);
- up(&parent_class->sem);
+ mutex_unlock(&parent_class->mutex);
}
if (class_dev->dev) {
@@ -772,14 +772,14 @@ void class_device_destroy(struct class *
struct class_device *class_dev = NULL;
struct class_device *class_dev_tmp;
- down(&cls->sem);
+ mutex_lock(&cls->mutex);
list_for_each_entry(class_dev_tmp, &cls->children, node) {
if (class_dev_tmp->devt == devt) {
class_dev = class_dev_tmp;
break;
}
}
- up(&cls->sem);
+ mutex_unlock(&cls->mutex);
if (class_dev)
class_device_unregister(class_dev);
@@ -818,7 +818,7 @@ int class_for_each_device(struct class *
if (!class)
return -EINVAL;
- down(&class->sem);
+ mutex_lock(&class->mutex);
list_for_each_entry(dev, &class->devices, node) {
dev = get_device(dev);
if (dev) {
@@ -829,7 +829,7 @@ int class_for_each_device(struct class *
if (error)
break;
}
- up(&class->sem);
+ mutex_unlock(&class->mutex);
return error;
}
@@ -858,7 +858,7 @@ struct device *class_find_device(struct
if (!class)
return NULL;
- down(&class->sem);
+ mutex_lock(&class->mutex);
list_for_each_entry(dev, &class->devices, node) {
dev = get_device(dev);
if (dev) {
@@ -870,7 +870,7 @@ struct device *class_find_device(struct
} else
break;
}
- up(&class->sem);
+ mutex_unlock(&class->mutex);
if (error)
return NULL;
@@ -898,7 +898,7 @@ int class_for_each_child(struct class *c
if (!class)
return -EINVAL;
- down(&class->sem);
+ mutex_lock(&class->mutex);
list_for_each_entry(dev, &class->children, node) {
dev = class_device_get(dev);
if (dev) {
@@ -909,7 +909,7 @@ int class_for_each_child(struct class *c
if (error)
break;
}
- up(&class->sem);
+ mutex_unlock(&class->mutex);
return error;
}
@@ -938,7 +938,7 @@ struct class_device *class_find_child(st
if (!class)
return NULL;
- down(&class->sem);
+ mutex_lock(&class->mutex);
list_for_each_entry(dev, &class->children, node) {
dev = class_device_get(dev);
if (dev) {
@@ -950,7 +950,7 @@ struct class_device *class_find_child(st
} else
break;
}
- up(&class->sem);
+ mutex_unlock(&class->mutex);
if (error)
return NULL;
@@ -971,7 +971,7 @@ int class_interface_register(struct clas
if (!parent)
return -EINVAL;
- down(&parent->sem);
+ mutex_lock(&parent->mutex);
Re: The ext3 way of journalling
On 12.01.2008 18:10, TimC wrote: > Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET): > > On Fri, 11 Jan 2008, Lennart Sorensen wrote: > > > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > > > > > > What can happen if someone does tune2fs -Lroot /dev/usbstick > > > > and puts that stick into this system? > > > > > > Don't know. I use UUIDs rather than LABELs. Having duplicated labels > > > just means being careless. Having duplicate UUIDs should require being > > > malicous. > > > > That's exactly what you have to assume for your users. Otherwise, you could > > remove any security feature from the system. > > If they've got physical access to your machine, you've already lost. As a last resort there is always the option to encrypt everything. Of course you loose the LABEL & UUID support with that. But i circumvented that by a custom udev script and marking the MBR in the documented 4 bytes for an ID that is used by said script to create an appropriate symlink. Together with a matching autofs-conf i can still automatically mount all my >50 encrypted HDDs i have stacked on my shelf. :-) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [RFD] Incremental fsck
Bodo Eggert wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > Even after a black-out shutdown, the corruption is pretty minimal, using > > ext3fs at least. So let's take advantage of this fact and do an > > optimistic fsck, to assure integrity per-dir, and assume no external > > corruption. Then we release this checked dir to the wild (optionally > > ro), and check the next. Once we find external inconsistencies we either > > fix it unconditionally, based on some preconfigured actions, or present > > the user with options. > > Maybe we can know the changes that need to be done in order to fix the > filesystem. Let's record this information in - eh - let's call it a > journal! Don't mistake data=journal as an fsck replacement. Thanks! -- Al -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/5] USB Kconfig: Reorganize USB Kconfig Menu
Greg KH wrote: > On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote: > > Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device > > Driver Menu. ?This helps the USB Kconfig Menu to be more logical/usable. > > > > Patchset against 2.6.23 > > So what was the final verdict in this patch set? IMHO, it's a lot better than what we have right now, and it's split up so that you can pick and choose what you think is useful. > Can you rsend this against 2.6.24-rc7 with the requested changes (if > any) in it? The only critical change is in patch 2/5: menuconfig USB_STORAGE tristate "USB Mass Storage support" - depends on USB && SCSI + depends on USB && BLOCK + select SCSI I was hoping you could take care of it, or maybe wait until 2.6.25 is out. Thanks! -- Al -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/7] driver-core : add class iteration api
Dave Young wrote:
> Add the following class iteration functions for driver use:
Thanks Dave. I will check the ieee1394 part in detail later.
...
> +/**
> + * class_find_device - device iterator for locating a particular device
> + * @class: the class we're iterating
> + * @data: data for the match function
> + * @match: function to check device
> + *
> + * This is similar to the class_for_each_dev() function above, but it
> + * returns a reference to a device that is 'found' for later use, as
> + * determined by the @match callback.
Maybe add "Drop the reference with put_device() after use." for the
really slow driver programmers like me?
> + *
> + * The callback should return 0 if the device doesn't match and non-zero
> + * if it does. If the callback returns non-zero, this function will
> + * return to the caller and not iterate over any more devices.
> + */
> +struct device *class_find_device(struct class *class, void *data,
> +int (*match)(struct device *, void *))
> +{
A general comment on the linux/device.h API (not a direct comment on
your patch):
The match argument in bus_find_device(), driver_find_device(),
device_find_child(), class_find_device(), class_find_child() could be
changed to
bool (*match)(struct device *, void *)).
Then the semantics are IMO a little bit clearer. Ditto for the
dr_match_t type and the struct bus_type.match member.
I don't know though whether the churn of doing such a change everywhere
would be justified by the result.
A comment on patch 2/7...6/7:
You can bring most or all of the various __match implementations into a
slightly terser but IMO easy to read form, like this:
static int __match_ne(struct device *dev, void *data)
{
struct unit_directory *ud;
struct node_entry *ne = (struct node_entry *)data;
ud = container_of(dev, struct unit_directory, unit_dev);
- if (ud->ne == ne)
- return 1;
- return 0;
+ return ud->ne == ne;
}
Here it is also easy to see that readability would improve if the return
type was bool rather than int.
--
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: [RFC][PATCH] per-task I/O throttling
* Peter Zijlstra <[EMAIL PROTECTED]> [2008-01-12 10:46:37]: > > On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote: > > On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said: > > > > > The interesting feature is that it allows to set a priority for each > > > process container, but AFAIK it doesn't allow to "partition" the > > > bandwidth between different containers (that would be a nice feature > > > IMHO). For example it would be great to be able to define per-container > > > limits, like assign 10MB/s for processes in container A, 30MB/s to > > > container B, 20MB/s to container C, etc. > > > > Has anybody considered allocating based on *seeks* rather than bytes moved, > > or counting seeks as "virtual bytes" for the purposes of accounting (if the > > disk can do 50mbytes/sec, and a seek takes 5millisecs, then count it as 100K > > of data)? > > I was considering a time scheduler, you can fill your time slot with > seeks or data, it might be what CFQ does, but I've never even read the > code. > So far the definition of I/O bandwidth has been w.r.t time. Not all IO devices have sectors; I'd prefer bytes over a period of time. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] per-task I/O throttling
On Sat, 2008-01-12 at 16:27 +0530, Balbir Singh wrote: > * Peter Zijlstra <[EMAIL PROTECTED]> [2008-01-12 10:46:37]: > > > > > On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote: > > > On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said: > > > > > > > The interesting feature is that it allows to set a priority for each > > > > process container, but AFAIK it doesn't allow to "partition" the > > > > bandwidth between different containers (that would be a nice feature > > > > IMHO). For example it would be great to be able to define per-container > > > > limits, like assign 10MB/s for processes in container A, 30MB/s to > > > > container B, 20MB/s to container C, etc. > > > > > > Has anybody considered allocating based on *seeks* rather than bytes > > > moved, > > > or counting seeks as "virtual bytes" for the purposes of accounting (if > > > the > > > disk can do 50mbytes/sec, and a seek takes 5millisecs, then count it as > > > 100K > > > of data)? > > > > I was considering a time scheduler, you can fill your time slot with > > seeks or data, it might be what CFQ does, but I've never even read the > > code. > > > > So far the definition of I/O bandwidth has been w.r.t time. Not all IO > devices have sectors; I'd prefer bytes over a period of time. Doing a time based one would only require knowing the (avg) delay of seeks, whereas doing a bytes based one would also require knowing the (avg) speed of the device. That is, if you're also interested in providing a latency guarantee. Because that'd force you to convert bytes to time again. I'm not sure thats a good way to go with as long as a majority of devices still have a non-0 seek penalty (SSDs just aren't there yet for most of us). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/7] ieee1394 : use class iteration api
Dave Young wrote:
> +++ linux.new/drivers/ieee1394/nodemgr.c 2008-01-12 15:20:27.0
> +0800
...
> static void nodemgr_remove_uds(struct node_entry *ne)
> {
> struct device *dev;
> - struct unit_directory *tmp, *ud;
> + struct unit_directory *ud;
>
> - /* Iteration over nodemgr_ud_class.devices has to be protected by
> - * nodemgr_ud_class.sem, but device_unregister() will eventually
> - * take nodemgr_ud_class.sem too. Therefore pick out one ud at a time,
> - * release the semaphore, and then unregister the ud. Since this code
> - * may be called from other contexts besides the knodemgrds, protect the
> - * gap after release of the semaphore by nodemgr_serialize_remove_uds.
> + /* Use class_find device to iterate the devices. Since this code
> + * may be called from other contexts besides the knodemgrds,
> + * protect it by nodemgr_serialize_remove_uds.
>*/
> mutex_lock(&nodemgr_serialize_remove_uds);
> - for (;;) {
> - ud = NULL;
> - down(&nodemgr_ud_class.sem);
> - list_for_each_entry(dev, &nodemgr_ud_class.devices, node) {
> - tmp = container_of(dev, struct unit_directory,
> -unit_dev);
> - if (tmp->ne == ne) {
> - ud = tmp;
> - break;
> - }
> - }
> - up(&nodemgr_ud_class.sem);
> - if (ud == NULL)
> - break;
> - device_unregister(&ud->unit_dev);
> - device_unregister(&ud->device);
> + dev = class_find_device(&nodemgr_ud_class, ne, __match_ne);
> + if (!dev) {
> + mutex_unlock(&nodemgr_serialize_remove_uds);
> + return;
> }
> + ud = container_of(dev, struct unit_directory, unit_dev);
> + device_unregister(&ud->unit_dev);
> + device_unregister(&ud->device);
> mutex_unlock(&nodemgr_serialize_remove_uds);
> }
A quick response on this change, without having checked the rest yet:
This doesn't work. Each "ne" may have zero or more "ud". The purpose
of nodemgr_remove_uds is to kill all of the uds of one ne. After your
change, only the first ud of a ne would be gone.
You need to keep the loop which takes care that all of the uds of the ne
are removed.
Furthermore, I usually try to use "goto" or "break" constructs with
single unlock + return path instead of multiple unlock + return paths.
However, if these unlock + return paths are as visually close together
as they are here, it doesn't really matter (to me) which of the styles
is used.
BTW, you don't need to CC <[EMAIL PROTECTED]> on drivers/ieee1394/ patches
(CONFIG_IEEE1394). He only looks after drivers/firewire/
(CONFIG_FIREWIRE). I know, these are details, and everybody confuses
them. :-) I should try to clarify this in MAINTAINERS.
--
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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Sat, 12 Jan 2008 02:23:27 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > > Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for > Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test > triggering in pnp_bus_resume() and keeping the card in a suspended state. > I'm a bit confused here. Bjorn Helgaas wanted to remove the pnp_start/stop_dev() calls completely, and you want them called all the time. :) Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH 2/7] ieee1394 : use class iteration api
> Dave Young wrote:
>> +++ linux.new/drivers/ieee1394/nodemgr.c 2008-01-12 15:20:27.0
>> +0800
> ...
>> static void nodemgr_remove_uds(struct node_entry *ne)
>> {
>> struct device *dev;
>> -struct unit_directory *tmp, *ud;
>> +struct unit_directory *ud;
>>
>> -/* Iteration over nodemgr_ud_class.devices has to be protected by
>> - * nodemgr_ud_class.sem, but device_unregister() will eventually
>> - * take nodemgr_ud_class.sem too. Therefore pick out one ud at a time,
>> - * release the semaphore, and then unregister the ud. Since this code
>> - * may be called from other contexts besides the knodemgrds, protect the
>> - * gap after release of the semaphore by nodemgr_serialize_remove_uds.
>> +/* Use class_find device to iterate the devices. Since this code
>> + * may be called from other contexts besides the knodemgrds,
>> + * protect it by nodemgr_serialize_remove_uds.
>> */
>> mutex_lock(&nodemgr_serialize_remove_uds);
Hmm, maybe we actually don't need that special mutex after all. I shall
check that sometime later, independently of your patch series.
--
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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Saturday, 12 of January 2008, Andrew Morton wrote: > On Fri, 11 Jan 2008 16:46:13 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > These patches are a preresuisite to > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch and its > > later fixed-up versions. > > > > So what I have now is > > > > revert-gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > pm-introduce-destroy_suspended_device.patch > > pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch > > pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch > > pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch > > pm-acquire-device-locks-on-suspend-rev-3.patch > > pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch > > pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch > > > > So what needs to happen in Greg's tree is > > > > a) drop the old > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > > > b) apply these four patches > > > > c) apply the new pm-acquire-device-locks-on-suspend-rev-3.patch (and its > > fixups) > > err, no. pm-introduce-destroy_suspended_device.patch demolishes > pm-acquire-device-locks-on-suspend-rev-3.patch > > Confused, giving up. Sorry, I didn't know you still had pm-introduce-destroy_suspended_device.patch. Please drop: pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch pm-acquire-device-locks-on-suspend-rev-3.patch pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch and I'll resend a new checkpatch.pl-compliant version of the pm-acquire-device-locks-on-suspend patch with appropriate sign-offs to you and Greg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][RFC] security: call security_file_permission from rw_verify_area
Please review.
Tested with SELinux in enforcing mode.
---
All instances of rw_verify_area() are followed by a call to
security_file_permission(), so just call the latter from the former.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
fs/compat.c |4 ---
fs/read_write.c | 63 +--
fs/splice.c |8 ---
3 files changed, 24 insertions(+), 51 deletions(-)
diff --git a/fs/compat.c b/fs/compat.c
index 15078ce..5216c3f 100644
--- a/fs/compat.c
+++ b/fs/compat.c
@@ -1104,10 +1104,6 @@ static ssize_t compat_do_readv_writev(int type, struct
file *file,
if (ret < 0)
goto out;
- ret = security_file_permission(file, type == READ ? MAY_READ:MAY_WRITE);
- if (ret)
- goto out;
-
fnv = NULL;
if (type == READ) {
fn = file->f_op->read;
diff --git a/fs/read_write.c b/fs/read_write.c
index ea1f94c..c4d3d17 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -197,25 +197,27 @@ int rw_verify_area(int read_write, struct file *file,
loff_t *ppos, size_t count
{
struct inode *inode;
loff_t pos;
+ int retval = -EINVAL;
inode = file->f_path.dentry->d_inode;
if (unlikely((ssize_t) count < 0))
- goto Einval;
+ return retval;
pos = *ppos;
if (unlikely((pos < 0) || (loff_t) (pos + count) < 0))
- goto Einval;
+ return retval;
if (unlikely(inode->i_flock && mandatory_lock(inode))) {
- int retval = locks_mandatory_area(
+ retval = locks_mandatory_area(
read_write == READ ? FLOCK_VERIFY_READ :
FLOCK_VERIFY_WRITE,
inode, file, pos, count);
if (retval < 0)
return retval;
}
+ retval = security_file_permission(file,
+ read_write == READ ? MAY_READ : MAY_WRITE);
+ if (retval)
+ return retval;
return count > MAX_RW_COUNT ? MAX_RW_COUNT : count;
-
-Einval:
- return -EINVAL;
}
static void wait_on_retry_sync_kiocb(struct kiocb *iocb)
@@ -267,18 +269,15 @@ ssize_t vfs_read(struct file *file, char __user *buf,
size_t count, loff_t *pos)
ret = rw_verify_area(READ, file, pos, count);
if (ret >= 0) {
count = ret;
- ret = security_file_permission (file, MAY_READ);
- if (!ret) {
- if (file->f_op->read)
- ret = file->f_op->read(file, buf, count, pos);
- else
- ret = do_sync_read(file, buf, count, pos);
- if (ret > 0) {
- fsnotify_access(file->f_path.dentry);
- add_rchar(current, ret);
- }
- inc_syscr(current);
+ if (file->f_op->read)
+ ret = file->f_op->read(file, buf, count, pos);
+ else
+ ret = do_sync_read(file, buf, count, pos);
+ if (ret > 0) {
+ fsnotify_access(file->f_path.dentry);
+ add_rchar(current, ret);
}
+ inc_syscr(current);
}
return ret;
@@ -325,18 +324,15 @@ ssize_t vfs_write(struct file *file, const char __user
*buf, size_t count, loff_
ret = rw_verify_area(WRITE, file, pos, count);
if (ret >= 0) {
count = ret;
- ret = security_file_permission (file, MAY_WRITE);
- if (!ret) {
- if (file->f_op->write)
- ret = file->f_op->write(file, buf, count, pos);
- else
- ret = do_sync_write(file, buf, count, pos);
- if (ret > 0) {
- fsnotify_modify(file->f_path.dentry);
- add_wchar(current, ret);
- }
- inc_syscw(current);
+ if (file->f_op->write)
+ ret = file->f_op->write(file, buf, count, pos);
+ else
+ ret = do_sync_write(file, buf, count, pos);
+ if (ret > 0) {
+ fsnotify_modify(file->f_path.dentry);
+ add_wchar(current, ret);
}
+ inc_syscw(current);
}
return ret;
@@ -603,9 +599,6 @@ static ssize_t do_readv_writev(int type, struct file *file,
ret = rw_verify_area(type, file, pos, tot_len);
if (ret < 0)
goto out;
- ret = security_file_permission(file, type == READ ? MAY_READ :
MAY_WRITE);
- if (ret)
- goto out;
fnv = NULL;
if (type == READ) {
@@ -737,10 +730,6 @@ static ss
Re: [PATCH] x86_64: cleanup setup_node_zones called by paging_init v2
On Wednesday 09 January 2008 11:19:01 am Christoph Lameter wrote:
> On Wed, 9 Jan 2008, Yinghai Lu wrote:
>
Christoph's
x86: 64-bit, make sparsemem vmemmap the only memory model
is in x86.git mm
so we could remove setup_node_zones because it is not needed by SPARSEMEM
please check the following patch.
YH
[PATCH] x86_84: only support sparsemem fix
sparsemem is only one supported, so could remove FLAT_NODE_MEM related code,
that is
only needed !SPARSEMEM
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
index 8482314..4c286b7 100644
--- a/arch/x86/mm/numa_64.c
+++ b/arch/x86/mm/numa_64.c
@@ -233,32 +233,6 @@ void __init setup_node_bootmem(int nodeid, unsigned long
start,
node_set_online(nodeid);
}
-/* Initialize final allocator for a zone */
-void __init setup_node_zones(int nodeid)
-{
- unsigned long start_pfn, end_pfn, memmapsize, limit;
-
- start_pfn = node_start_pfn(nodeid);
- end_pfn = node_end_pfn(nodeid);
-
- Dprintk(KERN_INFO "Setting up memmap for node %d %lx-%lx\n",
- nodeid, start_pfn, end_pfn);
-
- /*
-* Try to allocate mem_map at end to not fill up precious <4GB
-* memory.
-*/
- memmapsize = sizeof(struct page) * (end_pfn-start_pfn);
- limit = end_pfn << PAGE_SHIFT;
-#ifdef CONFIG_FLAT_NODE_MEM_MAP
- NODE_DATA(nodeid)->node_mem_map =
- __alloc_bootmem_core(NODE_DATA(nodeid)->bdata,
-memmapsize, SMP_CACHE_BYTES,
-round_down(limit - memmapsize, PAGE_SIZE),
-limit);
-#endif
-}
-
/*
* There are unfortunately some poorly designed mainboards around that
* only connect memory to a single CPU. This breaks the 1:1 cpu->node
@@ -580,9 +554,6 @@ void __init paging_init(void)
sparse_memory_present_with_active_regions(MAX_NUMNODES);
sparse_init();
- for_each_online_node(i)
- setup_node_zones(i);
-
free_area_init_nodes(max_zone_pfns);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/4] PM: Do not destroy/create devices while suspended (rev. 2)
On Saturday, 12 of January 2008, Greg KH wrote: > On Fri, Jan 11, 2008 at 10:11:52PM -0500, Alan Stern wrote: > > On Fri, 11 Jan 2008, Greg KH wrote: > > > > > On Fri, Jan 11, 2008 at 04:49:04PM -0800, Andrew Morton wrote: > > > > > > err, no. pm-introduce-destroy_suspended_device.patch demolishes > > > > pm-acquire-device-locks-on-suspend-rev-3.patch > > > > > > > > Confused, giving up. > > > > > > I'm confused too, I have no idea what the proper order of things should > > > be either. Anyone want to give me a hint? > > > > Sorry for the confusion. The correct patch to apply is > > pm-acquire-device-locks-on-suspend-rev-3 (plus the attending > > style-fixups). It encompasses those earlier patches. > > Can someone resend this to me? Do I need to drop the patch I currently > have in my tree as well? Or put it before/after that one? > > > The real problem is that our current email workflow patterns don't > > provide a standardized way for maintainers to tell when a new patch > > submission is meant to override or replace an earlier submission (or > > even a set of earlier submissions). Does anybody have some suggestions > > for a good way to do this? > > Yeah, just tell me what you want me to do with it (drop an old one, > replace it, add it, etc.) We usually can handle this pretty well :) I'll repost the new patch along with instructions what to do with it. 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 001/001] ipv4: enable use of 240/4 address space
On Jan 11 2008 17:49, David Miller wrote: >From: Vince Fuller <[EMAIL PROTECTED]> >Date: Fri, 11 Jan 2008 09:29:15 -0800 > >> I leave it up to you, the developers, to decide if you want to use these >> patches. > >Vince, please just ignore these turkeys who are dismissing >your patch and respin it against current sources as I asked >of you. > >I'll apply it, immediately, because it is the only correct >course of action. I strongly agree. Linux should set standards, or at least help them become one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] firewire vs. ieee1394: clarify MAINTAINERS
Maintainers like to receive less mail, and submitters like to have to Cc less recipients. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux/MAINTAINERS === --- linux.orig/MAINTAINERS +++ linux/MAINTAINERS @@ -1571,7 +1571,7 @@ P:Alexander Viro M: [EMAIL PROTECTED] S: Maintained -FIREWIRE SUBSYSTEM +FIREWIRE SUBSYSTEM (drivers/firewire, ) P: Kristian Hoegsberg, Stefan Richter M: [EMAIL PROTECTED], [EMAIL PROTECTED] L: [EMAIL PROTECTED] @@ -1891,7 +1891,7 @@ L:[EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Orphan -IEEE 1394 SUBSYSTEM +IEEE 1394 SUBSYSTEM (drivers/ieee1394) P: Ben Collins M: [EMAIL PROTECTED] P: Stefan Richter -- 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] SH/Dreamcast - add support for GD-Rom CDROM drive on SEGA Dreamcast
On Fri, Jan 11 2008, Adrian McMenamin wrote: > > On Thu, 2008-01-10 at 23:25 +, Adrian McMenamin wrote: > > From: Adrian McMenamin <[EMAIL PROTECTED]> > > > > This patch adds support for the GD-Rom drive, SEGA's proprietary > > implementation of an IDE CD Rom for the SEGA Dreamcast. This driver > > implements Sega's Packet Interface (SPI) - at least partially. It will also > > read disks in SEGA's propreitary GD format. > > > > Unlike previous drivers (which were never in mainline) this uses DMA and > > not PIO to read disks. It is a new driver, not a refactoring of old > > drivers. > > > > Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]> > > > > (Jens - this awaits your ack before going in Paul's queue for the 2.6.25 > > window) > > > > > > > > > > Unfortunately, there was one small mistake (a repeated assignment), in > the patch posted yesterday. Here is a corrected version. > > Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]> The io handling looks ok to me now. Acked-by: Jens Axboe <[EMAIL PROTECTED]> -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/3] block: remove end_{queued|dequeued}_request()
On Fri, Jan 11 2008, Kiyoshi Ueda wrote: > Hi Jens, > > This patch set removes end_queued_request() and end_dequeued_request(), > which became identical by the blk-end-request patch set. > They just calls __blk_end_request() actually, so users of them are > converted to call __blk_end_request() directly. Please just keep them both and call __blk_end_request(), it's nicer as an exported name. Then we can do a cleanup run afterwards. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kconfig: multibyte character support for lxdialog
UTF-8 support for lxdialog with wchar. The installed wide ncurses (ncursesw) is
optional.
Signed-off-by: Egry Gabor <[EMAIL PROTECTED]>
---
kbuild-szilard/scripts/kconfig/lxdialog/check-lxdialog.sh |6
kbuild-szilard/scripts/kconfig/lxdialog/checklist.c | 13 -
kbuild-szilard/scripts/kconfig/lxdialog/dialog.h | 60 ++
kbuild-szilard/scripts/kconfig/lxdialog/inputbox.c| 32 ++-
kbuild-szilard/scripts/kconfig/lxdialog/menubox.c | 25 +-
kbuild-szilard/scripts/kconfig/lxdialog/textbox.c | 31 +--
kbuild-szilard/scripts/kconfig/lxdialog/util.c| 124 +++---
kbuild-szilard/scripts/kconfig/lxdialog/yesno.c |5
8 files changed, 223 insertions(+), 73 deletions(-)
diff -puN
scripts/kconfig/lxdialog/checklist.c~kconfig-i18n-04-lxdialog-multibyte
scripts/kconfig/lxdialog/checklist.c
---
kbuild/scripts/kconfig/lxdialog/checklist.c~kconfig-i18n-04-lxdialog-multibyte
2008-01-12 12:21:03.0 +0100
+++ kbuild-szilard/scripts/kconfig/lxdialog/checklist.c 2008-01-12
12:21:03.0 +0100
@@ -44,9 +44,9 @@ static void print_item(WINDOW * win, int
wprintw(win, "(%c)", item_is_tag('X') ? 'X' : ' ');
wattrset(win, selected ? dlg.tag_selected.atr : dlg.tag.atr);
- mvwaddch(win, choice, item_x, item_str()[0]);
+ LXD_MVWADDCH(win, choice, item_x, item_str()[0]);
wattrset(win, selected ? dlg.item_selected.atr : dlg.item.atr);
- waddstr(win, (char *)item_str() + 1);
+ LXD_WADDSTR(win, &item_str()[1]);
if (selected) {
wmove(win, choice, check_x + 1);
wrefresh(win);
@@ -112,8 +112,9 @@ int dialog_checklist(const char *title,
int width, int list_height)
{
int i, x, y, box_x, box_y;
- int key = 0, button = 0, choice = 0, scroll = 0, max_choice;
+ int button = 0, choice = 0, scroll = 0, max_choice;
WINDOW *dialog, *list;
+ LXD_KEYTYPE key = 0;
/* which item to highlight */
item_foreach() {
@@ -173,7 +174,7 @@ do_resize:
/* Find length of longest item in order to center checklist */
check_x = 0;
item_foreach()
- check_x = MAX(check_x, strlen(item_str()) + 4);
+ check_x = MAX(check_x, MIN(list_width, LXD_STRLEN(item_str()) +
4));
check_x = (list_width - check_x) / 2;
item_x = check_x + 4;
@@ -199,11 +200,11 @@ do_resize:
doupdate();
while (key != KEY_ESC) {
- key = wgetch(dialog);
+ LXD_WGETCH(dialog, key);
for (i = 0; i < max_choice; i++) {
item_set(i + scroll);
- if (toupper(key) == toupper(item_str()[0]))
+ if (LXD_TOUPPER(key) == LXD_TOUPPER(item_str()[0]))
break;
}
diff -puN scripts/kconfig/lxdialog/dialog.h~kconfig-i18n-04-lxdialog-multibyte
scripts/kconfig/lxdialog/dialog.h
--- kbuild/scripts/kconfig/lxdialog/dialog.h~kconfig-i18n-04-lxdialog-multibyte
2008-01-12 12:21:03.0 +0100
+++ kbuild-szilard/scripts/kconfig/lxdialog/dialog.h2008-01-12
12:23:17.0 +0100
@@ -37,6 +37,60 @@
#endif
#include CURSES_LOC
+/* Wide character support for lxdialog */
+#ifdef USE_WIDE_CURSES
+#include
+#include
+#define LXD_CHAR wchar_t
+#define LXD_KEYTYPE wchar_t
+#define LXD_WADDCH(a, b) waddnwstr(a, &b, 1)
+#define LXD_WADDSTR waddwstr
+#define LXD_WADDNSTR waddnwstr
+#define LXD_MVWADDCH(a, b, c, d) mvwaddnwstr(a, b, c, &d, 1)
+#define LXD_MVWADDSTR mvwaddwstr
+#define LXD_MVWADDNSTR mvwaddnwstr
+#define LXD_WGETCH(a, b) wget_wch(a, &b)
+#define LXD_STRLEN wcslen
+#define LXD_STRCPY wcscpy
+#define LXD_STRNCPY wcsncpy
+#define LXD_STRADDWCS(str1, str2, n) stradd2wcs(str1, str2, n)
+#define LXD_WCSADDSTR(str1, str2, n) wcsadd2str(str1, str2, n)
+#define LXD_STRCHR wcschr
+#define LXD_ISALPHA iswalpha
+#define LXD_ISPRINT iswprint
+#define LXD_TOLOWER towlower
+#define LXD_TOUPPER towupper
+#define LXD_STR2WCS(var1, var2) var1 = str2wcs(var2)
+#define LXD_FREE(var) free(var)
+wchar_t* str2wcs (const char *mbs);
+int stradd2wcs (wchar_t* wcs, const char *mbs, size_t n);
+int wcsadd2str (char *mbs, const wchar_t *wcs, size_t n);
+
+#else /* USE_WIDE_CURSES */
+
+#define LXD_CHAR char
+#define LXD_KEYTYPE int
+#define LXD_WADDCH(a, b) waddch(a, b)
+#define LXD_WADDSTR waddstr
+#define LXD_WADDNSTR waddnstr
+#define LXD_MVWADDCH(a, b, c, d) mvwaddch(a, b, c, d)
+#define LXD_MVWADDSTR mvwaddstr
+#define LXD_MVWADDNSTR mvwaddnstr
+#define LXD_WGETCH(a, b) b = wgetch(a)
+#define LXD_STRLEN strlen
+#define LXD_STRCPY strcpy
+#define LXD_STRNCPY strncpy
+#define LXD_WCSADDSTR(str1, str2, n) strncpy(str1, str2, n)
+#define LXD_STRADDWCS(str1, str2, n) strncpy(str1, str2, n)
+#define LXD_STRCHR strchr
+#define LXD_ISALPHA isalpha
+#define LXD_ISPRINT isprint
+#define LXD_TOLOWER tolower
+#define LXD_TOUPPER t
Re: [PATCH] Assign IRQs to HPET Timers
* Balaji Rao <[EMAIL PROTECTED]> [2008-01-12 00:36:11]:
> Assign an IRQ to HPET Timer devices when interrupt enable is requested.
> This now makes the HPET userspace API work.
>
A more detailed changelog will better help understand the nature and
origin of the problem and how to reproduce it.
> drivers/char/hpet.c | 31 +--
> include/linux/hpet.h |2 +-
> 2 files changed, 30 insertions(+), 3 deletions(-)
>
> Signed-off-by: Balaji Rao R <[EMAIL PROTECTED]>
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 4c16778..92bd889 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -390,7 +390,8 @@ static int hpet_ioctl_ieon(struct hpet_dev *devp)
> struct hpets *hpetp;
> int irq;
> unsigned long g, v, t, m;
> - unsigned long flags, isr;
> + unsigned long flags, isr, irq_bitmap;
> + u64 hpet_config;
>
> timer = devp->hd_timer;
> hpet = devp->hd_hpet;
> @@ -412,7 +413,29 @@ static int hpet_ioctl_ieon(struct hpet_dev *devp)
> devp->hd_flags |= HPET_SHARED_IRQ;
> spin_unlock_irq(&hpet_lock);
>
> - irq = devp->hd_hdwirq;
> + /* Assign an IRQ to the timer */
> + hpet_config = readq(&timer->hpet_config);
> + irq_bitmap =
> + (hpet_config & Tn_INT_ROUTE_CAP_MASK) >> Tn_INT_ROUTE_CAP_SHIFT;
Should we check if the interrupts are being delivered via FSB, prior
to doing this?
> + if (!irq_bitmap)
> + irq = 0;/* No IRQ Assignable */
> + else {
> + irq = find_first_bit(&irq_bitmap, 32);
> + do {
> + hpet_config |= irq << Tn_INT_ROUTE_CNF_SHIFT;
> + writeq(hpet_config, &timer->hpet_config);
> +
> + /* Check whether we wrote a valid IRQ
> + * number by reading back the field
> + */
> + hpet_config = readq(&timer->hpet_config);
> + if (irq == (hpet_config & Tn_INT_ROUTE_CNF_MASK)
> + >> Tn_INT_ROUTE_CNF_SHIFT) {
> + devp->hd_hdwirq = irq;
> + break; /* Success */
> + }
> + } while ((irq = (find_next_bit(&irq_bitmap, 32, irq;
> + }
Shouldn't we do this at hpet_alloc() time?
>
> if (irq) {
> unsigned long irq_flags;
> @@ -509,6 +532,10 @@ hpet_ioctl_common(struct hpet_dev *devp, int cmd,
> unsigned long arg, int kernel)
> break;
> v = readq(&timer->hpet_config);
> v &= ~Tn_INT_ENB_CNF_MASK;
> +
> + /* Zero out the IRQ field*/
> + v &= ~Tn_INT_ROUTE_CNF_MASK;
> +
> writeq(v, &timer->hpet_config);
> if (devp->hd_irq) {
> free_irq(devp->hd_irq, devp);
> diff --git a/include/linux/hpet.h b/include/linux/hpet.h
> index 707f7cb..e3c0b2a 100644
> --- a/include/linux/hpet.h
> +++ b/include/linux/hpet.h
> @@ -64,7 +64,7 @@ struct hpet {
> */
>
> #define Tn_INT_ROUTE_CAP_MASK (0xULL)
> -#define Tn_INI_ROUTE_CAP_SHIFT (32UL)
> +#define Tn_INT_ROUTE_CAP_SHIFT (32UL)
> #define Tn_FSB_INT_DELCAP_MASK (0x8000UL)
> #define Tn_FSB_INT_DELCAP_SHIFT (15)
> #define Tn_FSB_EN_CNF_MASK (0x4000UL)
The patch looks good overall!
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2][RFC][BUG] msync: updating ctime and mtime at syncing
2008/1/12, Peter Zijlstra <[EMAIL PROTECTED]>:
>
> On Fri, 2008-01-11 at 03:44 +0300, Anton Salikhmetov wrote:
>
> > +/*
> > + * Update the ctime and mtime stamps after checking if they are to be
> > updated.
> > + */
> > +void mapped_file_update_time(struct file *file)
> > +{
> > + if (test_and_clear_bit(AS_MCTIME, &file->f_mapping->flags)) {
> > + get_file(file);
> > + file_update_time(file);
> > + fput(file);
> > + }
> > +}
> > +
>
> I don't think you need the get/put file stuff here, because
>
> > @@ -87,6 +87,8 @@ long do_fsync(struct file *file, int datasync)
> > goto out;
> > }
> >
> > + mapped_file_update_time(file);
> > +
> > ret = filemap_fdatawrite(mapping);
> >
> > /*
>
> at this call-site we already hold an extra reference on the file, and
>
> > @@ -74,14 +79,17 @@ asmlinkage long sys_msync(unsigned long start, size_t
> > len, int flags)
> > break;
> > }
> > file = vma->vm_file;
> > - if ((flags & MS_SYNC) && file && (vma->vm_flags & VM_SHARED))
> > {
> > - get_file(file);
> > - up_read(&mm->mmap_sem);
> > - error = do_fsync(file, 0);
> > - fput(file);
> > - if (error)
> > - return error;
> > - down_read(&mm->mmap_sem);
> > + if (file && (vma->vm_flags & VM_SHARED)) {
> > + mapped_file_update_time(file);
> > + if (flags & MS_SYNC) {
> > + get_file(file);
> > + up_read(&mm->mmap_sem);
> > + error = do_fsync(file, 0);
> > + fput(file);
> > + if (error)
> > + return error;
> > + down_read(&mm->mmap_sem);
> > + }
> > }
> >
> > start = vma->vm_end;
>
> here we hold the mmap_sem so the vma reference on the file can't go
> away.
These get_file() and fput() calls were in the sys_msync() function form before
all my changes. I did not add them here.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2][RFC][BUG] msync: updating ctime and mtime at syncing
2008/1/12, Peter Zijlstra <[EMAIL PROTECTED]>:
>
> On Sat, 2008-01-12 at 10:36 +0100, Peter Zijlstra wrote:
> > On Fri, 2008-01-11 at 03:44 +0300, Anton Salikhmetov wrote:
> >
> > > +/*
> > > + * Update the ctime and mtime stamps after checking if they are to be
> > > updated.
> > > + */
> > > +void mapped_file_update_time(struct file *file)
> > > +{
> > > + if (test_and_clear_bit(AS_MCTIME, &file->f_mapping->flags)) {
> > > + get_file(file);
> > > + file_update_time(file);
> > > + fput(file);
> > > + }
> > > +}
> > > +
> >
> > I don't think you need the get/put file stuff here, because
>
> BTW, the reason for me noticing this is that if it would be needed there
> is a race condition right there, who is to say that the file pointer
> you're deref'ing in your test condition isn't a dead one already.
So, in your opinion, is it at all needed here to play with the file reference
counter? May I drop the get_file() and fput() calls from the
sys_msync() function?
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] split MMC_CAP_4_BIT_DATA
On Fri 11 Jan 2008 12:52, Robin Getz pondered: > On Fri 11 Jan 2008 04:35, Pierre Ossman pondered: > > On Fri, 11 Jan 2008 04:08:53 -0500 > > "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > > > > > On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote: > > > > So it's far more probable that you've misdiagnosed your error than > > this being the actual problem. > > > > > > the guys who design the silicon are telling us it doesnt work. our > > > tests show it not working. i'm not sure what else you want here. > > > > > > > More information. You have not provided any speculation as to why it > > doesn't work, or what you've done to figure it out. > > I have been trying to get the detailed information from the hardware > (silicon designer) guy about why he believes support for 4-bit MMC is > not there, but I have not heard back yet. > > As soon as I hear from them - and either understand why 4-bit MMC doesn't > work, or if the Blackfin docs are incorrect (either is OK outcome) - I will > let you know. According to the HW folks - it is exactly as Pierre indicated - in theory it should work, 4-bit MMC requires usage of different set of commands as compared to 4-bit SD, so it should be just software - although no one has tested it yet. So I guess this is back on Bryan/Cliff to make work Thanks for pushing back. -Robin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/2][RFC][BUG] msync: updating ctime and mtime at syncing
On Sat, 2008-01-12 at 15:38 +0300, Anton Salikhmetov wrote:
> 2008/1/12, Peter Zijlstra <[EMAIL PROTECTED]>:
> >
> > On Sat, 2008-01-12 at 10:36 +0100, Peter Zijlstra wrote:
> > > On Fri, 2008-01-11 at 03:44 +0300, Anton Salikhmetov wrote:
> > >
> > > > +/*
> > > > + * Update the ctime and mtime stamps after checking if they are to be
> > > > updated.
> > > > + */
> > > > +void mapped_file_update_time(struct file *file)
> > > > +{
> > > > + if (test_and_clear_bit(AS_MCTIME, &file->f_mapping->flags)) {
> > > > + get_file(file);
> > > > + file_update_time(file);
> > > > + fput(file);
> > > > + }
> > > > +}
> > > > +
> > >
> > > I don't think you need the get/put file stuff here, because
> >
> > BTW, the reason for me noticing this is that if it would be needed there
> > is a race condition right there, who is to say that the file pointer
> > you're deref'ing in your test condition isn't a dead one already.
>
> So, in your opinion, is it at all needed here to play with the file reference
> counter? May I drop the get_file() and fput() calls from the
> sys_msync() function?
No, the ones in sys_msync() around calling do_fsync() are most
definately needed because we release mmap_sem there.
What I'm saying is that you can remove the get_file()/fput() calls from
your new mapped_file_update_time() function.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/16] udf: create common function for changing free space counter
On Fri, Jan 11, 2008 at 12:24:49AM +0100, Jan Kara wrote:
> On Thu 10-01-08 23:06:26, [EMAIL PROTECTED] wrote:
> > Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
> > CC: Jan Kara <[EMAIL PROTECTED]>
> > CC: Christoph Hellwig <[EMAIL PROTECTED]>
> Just two minor comment...
>
> > ---
> > fs/udf/balloc.c | 49 -
> > 1 files changed, 20 insertions(+), 29 deletions(-)
> >
> > diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
> > index dc9f8a9..78dbf1d 100644
> > --- a/fs/udf/balloc.c
> > +++ b/fs/udf/balloc.c
> > @@ -140,6 +140,20 @@ static inline int load_block_bitmap(struct super_block
> > *sb,
> > return slot;
> > }
> >
> > +static bool udf_inc_free_space(struct udf_sb_info *sbi,
> Maybe because you use the function for both increasing and decreasing
> free space, you could call is udf_add_free_space?
Ok. Done.
>
> > + u16 partition, u32 cnt)
> > +{
> > + struct logicalVolIntegrityDesc *lvid;
> > +
> > + if (sbi->s_lvid_bh)
> > + return false;
> > +
> > + lvid = (struct logicalVolIntegrityDesc *)sbi->s_lvid_bh->b_data;
> > + lvid->freeSpaceTable[partition] = cpu_to_le32(le32_to_cpu(
> > + lvid->freeSpaceTable[partition]) + cnt);
> I think macro like le32_add_cpu() just went into the kernel so you could
> use that...
I didn't want to rely on too many patches, so I intentionally left it.
I'll convert it together with other le*_add_cpu changes.
Can you ack this patch with udf_inc_free_space rename?
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SH/Dreamcast - add support for GD-Rom CDROM drive on SEGA Dreamcast
On Fri, 11 Jan 2008 21:56:49 + Adrian McMenamin <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-01-10 at 23:25 +, Adrian McMenamin wrote:
> > From: Adrian McMenamin <[EMAIL PROTECTED]>
> >
> > This patch adds support for the GD-Rom drive, SEGA's proprietary
> > implementation of an IDE CD Rom for the SEGA Dreamcast. This driver
> > implements Sega's Packet Interface (SPI) - at least partially. It will also
> > read disks in SEGA's propreitary GD format.
> >
> > Unlike previous drivers (which were never in mainline) this uses DMA and
> > not PIO to read disks. It is a new driver, not a refactoring of old
> > drivers.
> >
>
> ...
>
> +
> +static bool gdrom_is_busy(void)
> +{
> + return (ctrl_inb(GDROM_ALTSTATUS_REG) & 0x80) != 0;
> +}
> +
> +static bool gdrom_data_request(void)
> +{
> + return (ctrl_inb(GDROM_ALTSTATUS_REG) & 0x88) == 8;
> +}
> +
> +static void gdrom_wait_clrbusy(void)
> +{
> + /* long timeouts - typical for a CD Rom */
> + unsigned long timeout = jiffies + HZ * 60;
> + while ((ctrl_inb(GDROM_ALTSTATUS_REG) & 0x80) && (time_before(jiffies,
> timeout)))
> + cpu_relax();
> +}
That's a heck of a long busywait, and no indication is made to either the
calling function or to the system operator that this funtction timed out.
> +static void gdrom_wait_busy_sleeps(void)
> +{
> + unsigned long timeout;
> + /* Wait to get busy first */
> + timeout = jiffies + HZ * 60;
> + while (!gdrom_is_busy() && time_before(jiffies, timeout))
> + cpu_relax();
> + /* Now wait for busy to clear */
> + gdrom_wait_clrbusy();
> +}
Ditto * 2.
> +static void gdrom_identifydevice(void *buf)
> +{
> + int c;
> + short *data = buf;
> + gdrom_wait_clrbusy();
> + ctrl_outb(GDROM_COM_IDDEV, GDROM_STATUSCOMMAND_REG);
> + gdrom_wait_busy_sleeps();
> + /* now read in the data */
> + for (c = 0; c < 40; c++)
> + data[c] = ctrl_inw(GDROM_DATA_REG);
> +}
Most kernel code puts a blank line after the definition of the locals and
before start-of-code. We don't make a big fuss over code which omits the
blanks line but please consider.
> +static void gdrom_spicommand(void *spi_string, int buflen)
> +{
> + short *cmd = spi_string;
> + /* ensure IRQ_WAIT is set */
> + ctrl_outb(0x08, GDROM_ALTSTATUS_REG);
> + /* specify how many bytes we expect back */
> + ctrl_outb(buflen & 0xFF, GDROM_BCL_REG);
> + ctrl_outb((buflen >> 8) & 0xFF, GDROM_BCH_REG);
> + /* other parameters */
> + ctrl_outb(0, GDROM_INTSEC_REG);
> + ctrl_outb(0, GDROM_SECNUM_REG);
> + ctrl_outb(0, GDROM_ERROR_REG);
> + /* Wait until we can go */
> + gdrom_wait_clrbusy();
> + ctrl_outb(GDROM_COM_PACKET, GDROM_STATUSCOMMAND_REG);
> + while (!gdrom_data_request())
> + cpu_relax();
No timeout at all here?
> + outsw(PHYSADDR(GDROM_DATA_REG), cmd, 6);
> +}
> +
> +/* gdrom_command_executediagnostic:
> + * Used to probe for presence of working GDROM
> + * Restarts GDROM device and then applies standard ATA 3
> + * Execute Diagnostic Command: a return of '1' indicates device 0
> + * present and device 1 absent
> + */
> +static char gdrom_execute_diagnostic(void)
> +{
> + gdrom_hardreset(gd.cd_info);
> + gdrom_wait_clrbusy();
> + ctrl_outb(GDROM_COM_EXECDIAG, GDROM_STATUSCOMMAND_REG);
> + gdrom_wait_busy_sleeps();
> + return ctrl_inb(GDROM_ERROR_REG);
> +}
So this function can busywait for three minutes.
> +/*
> + * Prepare disk command
> + * byte 0 = 0x70
> + * byte 1 = 0x1f
> + */
> +static int gdrom_preparedisk_cmd(void)
> +{
> + struct packet_command *spin_command;
> + spin_command = kzalloc(sizeof(struct packet_command), GFP_KERNEL);
> + if (!spin_command)
> + return -ENOMEM;
> + spin_command->cmd[0] = 0x70;
> + spin_command->cmd[2] = 0x1f;
> + spin_command->buflen = 0;
> + gd.pending = 1;
> + gdrom_packetcommand(gd.cd_info, spin_command);
> + /* 60 second timeout */
> + wait_event_interruptible_timeout(command_queue, gd.pending == 0, HZ *
> 60);
> + gd.pending = 0;
> + kfree(spin_command);
> + if (gd.status & 0x01) {
> + /* log an error */
> + gdrom_getsense(NULL);
> + return -EIO;
> + }
> + return 0;
> +}
If the wait_event_interruptible_timeout() indeed times out, we go ahead and
free spin_command. But someone else could potentially be using it.
Suppose gdrom_packetcommand() got stuck for a minute due to bad hardware,
or some SCHED_FIFO task preempting us here and running for 61 seconds without
yielding or something similarly weird.
> +/*
> + * Read TOC command
> + * byte 0 = 0x14
> + * byte 1 = session
> + * byte 3 = sizeof TOC >> 8 ie upper byte
> + * byte 4 = sizeof TOC & 0xff ie lower byte
> + */
> +static int gdrom_readtoc_cmd(struct gdromtoc *toc, int session)
> +{
> + int tocsize;
> + struct packet_command *toc_command;
> + to
Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 12-01-08 12:12, Pierre Ossman wrote: On Sat, 12 Jan 2008 02:23:27 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test triggering in pnp_bus_resume() and keeping the card in a suspended state. I'm a bit confused here. Bjorn Helgaas wanted to remove the pnp_start/stop_dev() calls completely, and you want them called all the time. :) Wanted where? Haven't seen a coment from Bjorn? But -- while removing them both looks (as) sensible from a mirror-image viewpoint, this wouldn't fix the problem. As fas as I understand things, "hibernation" is basically "save state, shut down machine" where the latter step is going to disable the card inevitably. On resume, you're going to need to restore the resources (that were saved in pnp_dev->res) that it was using to the card, which is what pnp_start_dev() does -- it not being called is the current problem of the card not coming back to life. pnp_stop_dev() could go in this specific situation. Not much point in first disabling the thing it seems if a subsequent shutdown is going to take care of that anyway. However, suspend/resume isn't just called in the case of complete hibernation I guess and I know nothing about it all -- hence my request to the hiberhation people for how this is designed to be. But we certainly need the pnp_start_dev() in the current flow of things. It not being called is the problem this fixes... 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 2/2][RFC][BUG] msync: updating ctime and mtime at syncing
2008/1/12, Peter Zijlstra <[EMAIL PROTECTED]>:
>
> On Sat, 2008-01-12 at 15:38 +0300, Anton Salikhmetov wrote:
> > 2008/1/12, Peter Zijlstra <[EMAIL PROTECTED]>:
> > >
> > > On Sat, 2008-01-12 at 10:36 +0100, Peter Zijlstra wrote:
> > > > On Fri, 2008-01-11 at 03:44 +0300, Anton Salikhmetov wrote:
> > > >
> > > > > +/*
> > > > > + * Update the ctime and mtime stamps after checking if they are to
> > > > > be updated.
> > > > > + */
> > > > > +void mapped_file_update_time(struct file *file)
> > > > > +{
> > > > > + if (test_and_clear_bit(AS_MCTIME, &file->f_mapping->flags)) {
> > > > > + get_file(file);
> > > > > + file_update_time(file);
> > > > > + fput(file);
> > > > > + }
> > > > > +}
> > > > > +
> > > >
> > > > I don't think you need the get/put file stuff here, because
> > >
> > > BTW, the reason for me noticing this is that if it would be needed there
> > > is a race condition right there, who is to say that the file pointer
> > > you're deref'ing in your test condition isn't a dead one already.
> >
> > So, in your opinion, is it at all needed here to play with the file
> > reference
> > counter? May I drop the get_file() and fput() calls from the
> > sys_msync() function?
>
> No, the ones in sys_msync() around calling do_fsync() are most
> definately needed because we release mmap_sem there.
>
> What I'm saying is that you can remove the get_file()/fput() calls from
> your new mapped_file_update_time() function.
OK, thank you very much for your answer. I'm planning to submit my
next solution which is going to take your suggestion into account.
But I'm not sure how to process memory-mapped block device files.
Staubach's approach did not work for me after adapting it to my
solution.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kconfig: multibyte character support for lxdialog
On Sat, Jan 12, 2008 at 01:01:55PM +0100, EGRY Gabor wrote: > > UTF-8 support for lxdialog with wchar. The installed wide ncurses (ncursesw) > is optional. Building this on my 64 bit box with ncursesw support I saw several warnings. Adding the following to dialog.h decreased the number: #ifdef USE_WIDE_CURSES #define _XOPEN_SOURCE_EXTENDED #endif But it was not warning free. In addition in your patch below you assume that ncurses wide char support and wide char support follows each other. This assumption makes things overly complicated. Can we assume we have wide char support everywhere today where we will support building Linux? I am mostly concerned about sun, cygwin and MingW here... If we can assume wide char support everywhere your patch will become simplerAnd adding wide char support should be a separate step. I tried to take a look at varous source packages and they do not need this long list of redefinitions of the ncurses functions. Do we do something fundamentally different than for example dialog since this indirection is needed? Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SH/Dreamcast - add support for GD-Rom CDROM drive on SEGA Dreamcast
On Sat, 2008-01-12 at 05:36 -0800, Andrew Morton wrote:
> On Fri, 11 Jan 2008 21:56:49 + Adrian McMenamin <[EMAIL PROTECTED]> wrote:
>
> >
> > On Thu, 2008-01-10 at 23:25 +, Adrian McMenamin wrote:
> > > From: Adrian McMenamin <[EMAIL PROTECTED]>
> > >
> > > This patch adds support for the GD-Rom drive, SEGA's proprietary
> > > implementation of an IDE CD Rom for the SEGA Dreamcast. This driver
> > > implements Sega's Packet Interface (SPI) - at least partially. It will
> > > also read disks in SEGA's propreitary GD format.
> > >
> > > Unlike previous drivers (which were never in mainline) this uses DMA and
> > > not PIO to read disks. It is a new driver, not a refactoring of old
> > > drivers.
> > >
> >
> > ...
> >
> > +
> > +static bool gdrom_is_busy(void)
> > +{
> > + return (ctrl_inb(GDROM_ALTSTATUS_REG) & 0x80) != 0;
> > +}
> > +
> > +static bool gdrom_data_request(void)
> > +{
> > + return (ctrl_inb(GDROM_ALTSTATUS_REG) & 0x88) == 8;
> > +}
> > +
> > +static void gdrom_wait_clrbusy(void)
> > +{
> > + /* long timeouts - typical for a CD Rom */
> > + unsigned long timeout = jiffies + HZ * 60;
> > + while ((ctrl_inb(GDROM_ALTSTATUS_REG) & 0x80) && (time_before(jiffies,
> > timeout)))
> > + cpu_relax();
> > +}
>
> That's a heck of a long busywait, and no indication is made to either the
> calling function or to the system operator that this funtction timed out.
>
There is a 60 second timeout on one of the basic read fuctions in
cdrom.c, which I think is where I got this from. But the default timeout
there is 7 seconds, which I suppose I could use.
> > +static void gdrom_wait_busy_sleeps(void)
> > +{
> > + unsigned long timeout;
> > + /* Wait to get busy first */
> > + timeout = jiffies + HZ * 60;
> > + while (!gdrom_is_busy() && time_before(jiffies, timeout))
> > + cpu_relax();
> > + /* Now wait for busy to clear */
> > + gdrom_wait_clrbusy();
> > +}
>
> Ditto * 2.
>
> > +static void gdrom_identifydevice(void *buf)
> > +{
> > + int c;
> > + short *data = buf;
> > + gdrom_wait_clrbusy();
> > + ctrl_outb(GDROM_COM_IDDEV, GDROM_STATUSCOMMAND_REG);
> > + gdrom_wait_busy_sleeps();
> > + /* now read in the data */
> > + for (c = 0; c < 40; c++)
> > + data[c] = ctrl_inw(GDROM_DATA_REG);
> > +}
>
> Most kernel code puts a blank line after the definition of the locals and
> before start-of-code. We don't make a big fuss over code which omits the
> blanks line but please consider.
>
> > +static void gdrom_spicommand(void *spi_string, int buflen)
> > +{
> > + short *cmd = spi_string;
> > + /* ensure IRQ_WAIT is set */
> > + ctrl_outb(0x08, GDROM_ALTSTATUS_REG);
> > + /* specify how many bytes we expect back */
> > + ctrl_outb(buflen & 0xFF, GDROM_BCL_REG);
> > + ctrl_outb((buflen >> 8) & 0xFF, GDROM_BCH_REG);
> > + /* other parameters */
> > + ctrl_outb(0, GDROM_INTSEC_REG);
> > + ctrl_outb(0, GDROM_SECNUM_REG);
> > + ctrl_outb(0, GDROM_ERROR_REG);
> > + /* Wait until we can go */
> > + gdrom_wait_clrbusy();
> > + ctrl_outb(GDROM_COM_PACKET, GDROM_STATUSCOMMAND_REG);
> > + while (!gdrom_data_request())
> > + cpu_relax();
>
> No timeout at all here?
True enough. If the bits never cleared that would be broken hardware,
but not a reason not to catch it.
>
> > + outsw(PHYSADDR(GDROM_DATA_REG), cmd, 6);
> > +}
> > +
> > +static int gdrom_preparedisk_cmd(void)
> > +{
> > + struct packet_command *spin_command;
> > + spin_command = kzalloc(sizeof(struct packet_command), GFP_KERNEL);
> > + if (!spin_command)
> > + return -ENOMEM;
> > + spin_command->cmd[0] = 0x70;
> > + spin_command->cmd[2] = 0x1f;
> > + spin_command->buflen = 0;
> > + gd.pending = 1;
> > + gdrom_packetcommand(gd.cd_info, spin_command);
> > + /* 60 second timeout */
> > + wait_event_interruptible_timeout(command_queue, gd.pending == 0, HZ *
> > 60);
> > + gd.pending = 0;
> > + kfree(spin_command);
> > + if (gd.status & 0x01) {
> > + /* log an error */
> > + gdrom_getsense(NULL);
> > + return -EIO;
> > + }
> > + return 0;
> > +}
>
> If the wait_event_interruptible_timeout() indeed times out, we go ahead and
> free spin_command. But someone else could potentially be using it.
>
> Suppose gdrom_packetcommand() got stuck for a minute due to bad hardware,
> or some SCHED_FIFO task preempting us here and running for 61 seconds without
> yielding or something similarly weird.
>
Maybe I am being stupid here, but I don't follow this. They'll get a
non-fatal error, that's all. Who else would be using spin_command? It's
just a series of bytes to plug into the GD Rom registers, that's all.
> > ...
> >
> > +/* keep the function looking like the universal CD Rom specification -
> > returning int*/
> > +static int gdrom_packetcommand(struct cdrom_device_info *cd_info, struct
> > packet_command *command)
> > +{
> > + gdrom_spicommand(&comman
Re: [PATCH 04/21] ide-floppy: cleanup and unify debugging macro calls
On Friday 11 January 2008, Borislav Petkov wrote:
> * some debug_log() calls were not using "ide-floppy: " prefix
>
> * a few used printk levels different than KERN_INFO (KERN_NOTICE
> and KERN_ERR, which is the default one if no level is given)
>
> There should be no functional change resulting from this patch.
Hmm, but there are functional changes as noted above, I removed this line
from the patch description.
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> ---
with IDEFLOPPY_DEBUG_LOG set to 1:
drivers/ide/ide-floppy.c: In function ‘idefloppy_pc_intr’:
drivers/ide/ide-floppy.c:704: warning: too many arguments for format
drivers/ide/ide-floppy.c: In function ‘idefloppy_do_request’:
drivers/ide/ide-floppy.c:1126: error: ‘struct request’ has no member named
‘flags’
make[1]: *** [drivers/ide/ide-floppy.o] Error 1
make: *** [drivers/ide/ide-floppy.o] Error 2
which translate to:
[...]
> if ((stat & ERR_STAT) || test_bit(PC_DMA_ERROR, &pc->flags)) {
> /* Error detected */
> - debug_log(KERN_INFO "ide-floppy: %s: I/O error\n",
> - drive->name);
> + debug_log("I/O error\n", drive->name);
"%s: I/O error\n"
[...]
> - debug_log(KERN_INFO "dev: %s, flags: %lx, errors: %d\n",
> + debug_log("dev: %s, flags: %lx, errors: %d\n",
> rq->rq_disk ? rq->rq_disk->disk_name : "?",
> rq->flags, rq->errors);
This was broken before this patch by rq->flags -> rq->cmd_type change
(so your patch is not to blame for breaking IDEFLOPPY_DEBUG_LOG ;).
I fixed the above issues while merging the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/21] ide-floppy: remove struct idefloppy_flexible_disk_page
On Friday 11 January 2008, Borislav Petkov wrote:
> The driver used to test whether the flexible disk page has changed by
> memcmp-ing
> it with a cached copy of a previous version of the page from a different remo-
> vable medium. Since, according to the SFF-8070i spec, the flexible disk page
> "specifies parameters relating to the currently installed medium type," this
> comparison is now done by simply checking whether the medium has changed.
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> ---
> drivers/ide/ide-floppy.c | 89 -
> 1 files changed, 32 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
> index 2b9885f..679d48e 100644
> --- a/drivers/ide/ide-floppy.c
> +++ b/drivers/ide/ide-floppy.c
[...]
> @@ -1188,50 +1159,54 @@ static int idefloppy_queue_pc_tail (ide_drive_t
> *drive,idefloppy_pc_t *pc)
> }
>
> /*
> - * Look at the flexible disk page parameters. We will ignore the CHS
> - * capacity parameters and use the LBA parameters instead.
> + * Look at the flexible disk page parameters. We will ignore the CHS capacity
> + * parameters and use the LBA parameters instead.
> */
> -static int idefloppy_get_flexible_disk_page (ide_drive_t *drive)
> +static int idefloppy_get_flexible_disk_page(ide_drive_t *drive)
Care to rename it to ide_floppy_get_flexible_disk_page() while at it
(it has only one user)?
> {
> idefloppy_floppy_t *floppy = drive->driver_data;
> idefloppy_pc_t pc;
> - idefloppy_mode_parameter_header_t *header;
> - idefloppy_flexible_disk_page_t *page;
> int capacity, lba_capacity;
> + u8 heads, sectors;
> + u16 transfer_rate, sector_size, cyls, rpm;
some CodingStyle nitpicks (not really that important, rather personal taste):
u16 transfer_rate, sector_size, cyls, rpm;
u8 heads, sectors;
> - idefloppy_create_mode_sense_cmd(&pc, IDEFLOPPY_FLEXIBLE_DISK_PAGE,
> MODE_SENSE_CURRENT);
> - if (idefloppy_queue_pc_tail(drive,&pc)) {
> - printk(KERN_ERR "ide-floppy: Can't get flexible disk "
> - "page parameters\n");
> + idefloppy_create_mode_sense_cmd(&pc, IDEFLOPPY_FLEXIBLE_DISK_PAGE,
> + MODE_SENSE_CURRENT);
idefloppy_create_mode_sense_cmd(&pc, IDEFLOPPY_FLEXIBLE_DISK_PAGE,
MODE_SENSE_CURRENT);
> + if (idefloppy_queue_pc_tail(drive, &pc)) {
> + printk(KERN_ERR "ide-floppy: Can't get flexible disk page"
> + " parameters\n");
> return 1;
> }
> - header = (idefloppy_mode_parameter_header_t *) pc.buffer;
> - floppy->wp = header->wp;
> + floppy->wp = pc.buffer[3] & 0x80;
This is not an equivalent transformation:
header->wp is 0 or 1
pc.buffer[3] & 0x80 is 0 or 0x80
It seems to work fine for ->wp (because it is needlessly defined as 'int')
but may seriously confuse set_disk_ro() and thus bdev_read_only() users.
Should be fixed to '(pc.buffer[3] & 0x80) ? 1 : 0' (or something similar).
> set_disk_ro(floppy->disk, floppy->wp);
> - page = (idefloppy_flexible_disk_page_t *) (header + 1);
> -
> - page->transfer_rate = be16_to_cpu(page->transfer_rate);
> - page->sector_size = be16_to_cpu(page->sector_size);
> - page->cyls = be16_to_cpu(page->cyls);
> - page->rpm = be16_to_cpu(page->rpm);
> - capacity = page->cyls * page->heads * page->sectors * page->sector_size;
> - if (memcmp (page, &floppy->flexible_disk_page, sizeof
> (idefloppy_flexible_disk_page_t)))
> +
> + transfer_rate = be16_to_cpu(*(u16 *)&pc.buffer[8 + 2]);
> + sector_size = be16_to_cpu(*(u16 *)&pc.buffer[8 + 6]);
> + cyls = be16_to_cpu(*(u16 *)&pc.buffer[8 + 8]);
> + rpm = be16_to_cpu(*(u16 *)&pc.buffer[8 + 28]);
> + heads = pc.buffer[8 + 4];
> + sectors = pc.buffer[8 + 5];
> +
> + capacity = cyls * heads * sectors * sector_size;
> +
> + if ((1UL << IDEFLOPPY_MEDIA_CHANGED) & floppy->flags)
IDEFLOPPY_MEDIA_CHANGED is set when block device is opened for the first
time (please check idefloppy_open() for details) so I don't think it is
the right change. 'Flexible Disk Page' is only 32 bytes so we are better
off with leaving 'u8 flexible_disk_page[32]' in idefloppy_floppy_t and
doing things the old way.
Besides please do not intermix real changes like the above one with purely
cleanup ones like idefloppy_flexible_disk_page_t removal. This is bad from
maintainability point of view. If some patch causes problems it is easier
to narrow it down by heaving purely cleanup changes separated out + if we
would need to revert the real change we would have to make a separate patch
doing it instead of just reverting the guilty commit (given that we don't
want cleanup changes to be reverted as well).
> printk(KERN_INFO "%s: %dkB, %d/%d/%d CHS, %d kBps, "
>
Re: [PATCH 07/21] ide-floppy: remove struct idefloppy_capacity_descriptor
On Friday 11 January 2008, Borislav Petkov wrote:
> We test here for updated capacity descriptors by checking whether the media
> has changed instead of memcmp-ing with a cached copy of the capacity
> descriptors.
>
> Also:
>
> - remove one of 2 consecutive if (!i)-tests.
> - start loop at 1 in idefloppy_get_format_capacities() since userspace doesn't
> need the current/maximum capacity descriptor. i.e the first one.
> - fix comments formatting
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> ---
> drivers/ide/ide-floppy.c | 132 +
> 1 files changed, 50 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
> index 679d48e..5c85833 100644
> --- a/drivers/ide/ide-floppy.c
> +++ b/drivers/ide/ide-floppy.c
> @@ -119,29 +119,7 @@ typedef struct idefloppy_packet_command_s {
>
> #define PC_SUPPRESS_ERROR 6 /* Suppress error
> reporting */
>
> -/*
> - * Format capacity
> - */
> -typedef struct {
> - u8 reserved[3];
> - u8 length; /* Length of the following
> descriptors in bytes */
> -} idefloppy_capacity_header_t;
minor nitpick:
idefloppy_capacity_header_t removal wasn't mentioned in the patch description
[...]
> @@ -1229,17 +1205,16 @@ static int idefloppy_get_sfrp_bit(ide_drive_t *drive)
> }
>
> /*
> - * Determine if a media is present in the floppy drive, and if so,
> - * its LBA capacity.
> + * Determine if a media is present in the floppy drive, and if so, its LBA
> + * capacity.
> */
> -static int idefloppy_get_capacity (ide_drive_t *drive)
> +static int idefloppy_get_capacity(ide_drive_t *drive)
Care to rename it to ide_floppy_get_capacity() while at it
(it has only two users)?
> {
> idefloppy_floppy_t *floppy = drive->driver_data;
> idefloppy_pc_t pc;
> - idefloppy_capacity_header_t *header;
> - idefloppy_capacity_descriptor_t *descriptor;
> - int i, descriptors, rc = 1, blocks, length;
> -
> + int i, desc_cnt, rc = 1, blocks, length;
> + u8 header_len;
desc_cnt (== header_len / 8) can be u8 as well
> drive->bios_cyl = 0;
> drive->bios_head = drive->bios_sect = 0;
> floppy->blocks = 0;
> @@ -1251,17 +1226,17 @@ static int idefloppy_get_capacity (ide_drive_t *drive)
> printk(KERN_ERR "ide-floppy: Can't get floppy parameters\n");
> return 1;
> }
> - header = (idefloppy_capacity_header_t *) pc.buffer;
> - descriptors = header->length / sizeof(idefloppy_capacity_descriptor_t);
> - descriptor = (idefloppy_capacity_descriptor_t *) (header + 1);
> + header_len = pc.buffer[3];
> + desc_cnt = header_len / 8; /* capacity descriptor of 8 bytes */
>
> - for (i = 0; i < descriptors; i++, descriptor++) {
> - blocks = descriptor->blocks = be32_to_cpu(descriptor->blocks);
> - length = descriptor->length = be16_to_cpu(descriptor->length);
> + for (i = 0; i < desc_cnt; i++) {
> + unsigned int desc_start = 4 + i*8;
missing newline
> + blocks = be32_to_cpu(*(u32 *)&pc.buffer[desc_start]);
> + length = be16_to_cpu(*(u16 *)&pc.buffer[desc_start + 6]);
if the last debug_log() call in the loop will be moved here
> - if (!i)
> + if (!i)
> {
the 'if (!i)' can be replaced with:
if (i)
continue;
> - switch (descriptor->dc) {
> + switch (pc.buffer[desc_start + 4] & 0x03) {
> /* Clik! drive returns this instead of CAPACITY_CURRENT */
> case CAPACITY_UNFORMATTED:
> if (!test_bit(IDEFLOPPY_CLIK_DRIVE, &floppy->flags))
> @@ -1272,11 +1247,11 @@ static int idefloppy_get_capacity (ide_drive_t *drive)
> break;
> case CAPACITY_CURRENT:
> /* Normal Zip/LS-120 disks */
> - if (memcmp(descriptor, &floppy->capacity, sizeof
> (idefloppy_capacity_descriptor_t)))
> + if ((1UL << IDEFLOPPY_MEDIA_CHANGED) & floppy->flags)
Same issue as with similar change in patch #6:
[ Please note that idefloppy_get_capacity() is called from idefloppy_setup()
and IDEFLOPPY_MEDIA_CHANGED flag is first set in idefloppy_open(). ]
IMO it is the best to leave floppy->capacity alone for now.
> printk(KERN_INFO "%s: %dkB, %d blocks, %d "
> "sector size\n", drive->name,
> blocks * length / 1024, blocks, length);
> - floppy->capacity = *descriptor;
> +
> if (!length || length % 512) {
> printk(KERN_NOTICE "%s: %d bytes block size "
> "not supported\n", drive->name, length);
> @@ -1303,9 +1278,8 @@ static int ideflop
Re: [PATCH 00/21] ide-floppy redux v2
On Friday 11 January 2008, Borislav Petkov wrote: > > Hi Bart, > >here's the second version of the ide-floppy refactoring trail. All the > patches are based on the version of your quilt tree from the 05.01. Also, > you've > already applied patch 5 in this series but i'm submitting it still for the > sake > of completeness. > > > drivers/ide/ide-cd.c |2 - > drivers/ide/ide-floppy.c | 1403 > ++ > include/linux/cdrom.h|1 + > include/linux/ide.h |3 + > 4 files changed, 558 insertions(+), 851 deletions(-) applied patches #1-4, #8 (#4 with some changes) #5 was already applied so I just re-ordered it into the right spot I have some comments for #6-7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Fri, Jan 11, 2008 at 04:26:38PM -0800, Greg KH wrote:
> > One typical problem is that on "Intel(r) 3 Series Experss Chipset Family"
> > MMCONFIG probing of the BAR #2 (frame buffer address) of integrated graphics
> > device locks up the machine (depending on BIOS settings, of course).
> > This happens because the frame buffer of IGD has higher decode priority
> > than MMCONFIG range, as stated in Intel docs...
>
> Ok, so what would the proposed patch look like to help resolve this?
Yeah, for sure.
> Ivan, you posted one a while ago, but never seemed to get any
> confirmation if it helped or not. Should I use that and drop Arjan's?
Actually I'm strongly against Arjan's patch. First, it's based on
assumption that the MMCONFIG thing is sort of fundamentally broken
on some systems, but none of the facts we have so far does confirm that.
And second, I really don't like the implementation as it breaks all
non-x86 arches (or forces them to add a set of totally meaningless
PCI functions).
> Or use both? Or something else like the patches proposed by Tony
> Camuso?
Tony's patch is a variation of the same idea, so this patch
supersedes it. The only argument for using conf1 to access only the
first 64 bytes of the config space was some concerns about performance.
But the only driver that extensively uses config space at runtime
is tg3, and only as a work around some broken revisions of the chip.
And even in that case I seriously doubt that mmconf vs. conf1 would
make any measurable difference.
On the other hand, always using conf1 for the whole 256-byte legacy
config space allows us to drop all sorts of black lists, which is
a *huge* advantage.
Here is the same patch, but with an updated commit message -
proper attribution to Loic Prylli, which I somehow missed
the first time, sorry.
Ivan.
---
PCI x86: always use conf1 to access config space below 256 bytes
Thanks to Loic Prylli <[EMAIL PROTECTED]>, who originally proposed
this idea.
Always using legacy configuration mechanism for the legacy config space
and extended mechanism (mmconf) for the extended config space is
a simple and very logical approach. It's supposed to resolve all
known mmconf problems. It still allows per-device quirks (tweaking
dev->cfg_size). It also allows to get rid of mmconf fallback code.
Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]>
---
arch/x86/pci/mmconfig-shared.c | 35 ---
arch/x86/pci/mmconfig_32.c | 22 +-
arch/x86/pci/mmconfig_64.c | 22 ++
arch/x86/pci/pci.h |7 ---
4 files changed, 19 insertions(+), 67 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 4df637e..6b521d3 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -22,42 +22,9 @@
#define MMCONFIG_APER_MIN (2 * 1024*1024)
#define MMCONFIG_APER_MAX (256 * 1024*1024)
-DECLARE_BITMAP(pci_mmcfg_fallback_slots, 32*PCI_MMCFG_MAX_CHECK_BUS);
-
/* Indicate if the mmcfg resources have been placed into the resource table. */
static int __initdata pci_mmcfg_resources_inserted;
-/* K8 systems have some devices (typically in the builtin northbridge)
- that are only accessible using type1
- Normally this can be expressed in the MCFG by not listing them
- and assigning suitable _SEGs, but this isn't implemented in some BIOS.
- Instead try to discover all devices on bus 0 that are unreachable using MM
- and fallback for them. */
-static void __init unreachable_devices(void)
-{
- int i, bus;
- /* Use the max bus number from ACPI here? */
- for (bus = 0; bus < PCI_MMCFG_MAX_CHECK_BUS; bus++) {
- for (i = 0; i < 32; i++) {
- unsigned int devfn = PCI_DEVFN(i, 0);
- u32 val1, val2;
-
- pci_conf1_read(0, bus, devfn, 0, 4, &val1);
- if (val1 == 0x)
- continue;
-
- if (pci_mmcfg_arch_reachable(0, bus, devfn)) {
- raw_pci_ops->read(0, bus, devfn, 0, 4, &val2);
- if (val1 == val2)
- continue;
- }
- set_bit(i + 32 * bus, pci_mmcfg_fallback_slots);
- printk(KERN_NOTICE "PCI: No mmconfig possible on device"
- " %02x:%02x\n", bus, i);
- }
- }
-}
-
static const char __init *pci_mmcfg_e7520(void)
{
u32 win;
@@ -270,8 +237,6 @@ void __init pci_mmcfg_init(int type)
return;
if (pci_mmcfg_arch_init()) {
- if (type == 1)
- unreachable_devices();
if (known_bridge)
pci_mmcfg_insert_resources(IORESOURCE_BUSY);
pci_probe = (pci_probe & ~PCI_PROBE_MASK) | PCI_PROBE_MMCONF;
diff
Re: rtl8187 rate control doesn't work
I have tested kernel 2.6.24-rc7-git4 with the build in rtl8187 module and I have the same problem. I can't ping the AP if the rate is set to auto or to something higher than 11M. I have to set it to something less than 11M to be able to ping the AP. iwconfig shows a successful connection in both cases. I am using Ubuntu 7.10 with vanilla kernel 2.6.24-rc7-git4 on AMD64 system with wpa_supplicant v0.5.8 -- Hauke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [RFD] Incremental fsck
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote: > > Ok, but let's look at this a bit more opportunistic / optimistic. > > Even after a black-out shutdown, the corruption is pretty minimal, using > ext3fs at least. > After a unclean shutdown, assuming you have decent hardware that doesn't lie about when blocks hit iron oxide, you shouldn't have any corruption at all. If you have crappy hardware, then all bets are off > So let's take advantage of this fact and do an optimistic fsck, to > assure integrity per-dir, and assume no external corruption. Then > we release this checked dir to the wild (optionally ro), and check > the next. Once we find external inconsistencies we either fix it > unconditionally, based on some preconfigured actions, or present the > user with options. So what can you check? The *only* thing you can check is whether or not the directory syntax looks sane, whether the inode structure looks sane, and whether or not the blocks reported as belong to an inode looks sane. What is very hard to check is whether or not the link count on the inode is correct. Suppose the link count is 1, but there are actually two directory entries pointing at it. Now when someone unlinks the file through one of the directory hard entries, the link count will go to zero, and the blocks will start to get reused, even though the inode is still accessible via another pathname. Oops. Data Loss. This is why doing incremental, on-line fsck'ing is *hard*. You're not going to find this while doing each directory one at a time, and if the filesystem is changing out from under you, it gets worse. And it's not just the hard link count. There is a similar issue with the block allocation bitmap. Detecting the case where two files are simultaneously can't be done if you are doing it incrementally, and if the filesystem is changing out from under you, it's impossible, unless you also have the filesystem telling you every single change while it is happening, and you keep an insane amount of bookkeeping. One that you *might* be able to do, is to mount a filesystem readonly, check it in the background while you allow users to access it read-only. There are a few caveats, however (1) some filesystem errors may cause the data to be corrupt, or in the worst case, could cause the system to panic (that's would arguably be a filesystem/kernel bug, but we've not necessarily done as much testing here as we should.) (2) if there were any filesystem errors found, you would beed to completely unmount the filesystem to flush the inode cache and remount it before it would be safe to remount the filesystem read/write. You can't just do a "mount -o remount" if the filesystem was modified under the OS's nose. > All this could be per-dir or using some form of on-the-fly file-block-zoning. > > And there probably is a lot more to it, but it should conceptually be > possible, with more thoughts though... Many things are possible, in the NASA sense of "with enough thrust, anything will fly". Whether or not it is *useful* and *worthwhile* are of course different questions! :-) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Issue with arm-devel tree
It might be a good idea if there was some co-ordination with people involved in the duplicate include removal work... [ARM] remove duplicate includes Signed-off-by: Lucas Woods <[EMAIL PROTECTED]> Acked-by: Lennert Buytenhek <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Russell King <[EMAIL PROTECTED]> @@ -20,7 +20,6 @@ #include #include #include -#include #include [ARM] ixp4xx: remove double include Remove double include. Signed-off-by: Andre Haupt <[EMAIL PROTECTED]> Signed-off-by: Alessandro Zummo <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Russell King <[EMAIL PROTECTED]> @@ -18,7 +18,6 @@ */ #include -#include #include #include #include I've dropped the "ixp4xx: remove double include" commit and fixed the resulting breakage of "remove duplicate includes" change to resolve this problem. - Forwarded message from Michael-Luke Jones <[EMAIL PROTECTED]> - To: [EMAIL PROTECTED] From: Michael-Luke Jones <[EMAIL PROTECTED]> Subject: Issue with arm-devel tree Date: Sat, 12 Jan 2008 14:23:44 + http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/arm:devel.mbox contains two patches: "Re: [ARM] remove duplicate includes" from Lucas Woods <[EMAIL PROTECTED]> "Re: [ARM] ixp4xx: remove double include" from Andre Haupt <[EMAIL PROTECTED]> which between the two of them manage to delete *both* instances of #include in nslu2-power.c Given that nslu2-power.c calls machine_power_off() and ctrl_alt_del() this probably isn't a good thing. Michael-Luke Jones - End forwarded message - -- Russell King -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: The ext3 way of journalling
On Thu, Jan 10, 2008 at 03:41:11PM +0200, Tuomo Valkonen wrote: > On 2008-01-10 08:16 -0500, Theodore Tso wrote: > > > It displays just the right time. On boot anyway. (Linux has had some > > > serious problems keeping the time after the switch from 2.6.7 to 2.6.14, > > > advanding even 15 minutes a day -- that ntpd doesn't seem to be able > > > to keep up with -- requiring running adjtimexconfig every now and > > > then for new settings. But the cmos clock displays the right time.) > > > > What do you mean by "on boot"? Which boot message, precisely? Is the > > time printed before or after e2fsck is run, and by which program? > > The time is right as displayed by `date` after boot, i.e. after it has > been loaded from the CMOS clock that does keep the (local, IIRC) time > just allright. But then it often starts advancing very fast. So running the "date" command after the boot sequence is completely finished. That doesn't mean that system clock was correct at the time when fsck is run. See, here's the the problem. You have the CMOS hardware clock, which for people who are dual-booting with Windows, is unfortunately ticking local time, instead of GMT time (or if you want to be pedantic, UTC time; whatever). When the kernel is first loaded and starts executing, it will set the Linux system clock from the CMOS hardware clock. However, it has *no* idea whether the CMOS hardware clock is ticking localtime or UTC time. The Linux system clock (i.e., what is returned via the gettimeofday() or time() functions) is always UTC time. What happens later is that distribution init scripts will adjust the system clock either forward or backwards if the system is set up so that hardware is in Windows bug-compatibility mode where the CMOS hwclock is ticking localtime. If it is 1400 GMT, then in the US/Eastern timezone, the clock will be 9:00am, so the clock will be pushed four hours later. If you are in the Central European Timezone, then the local time will be 3pm, and the clock will be pushed *backwards* by one hour. The question is when does this happen. In some buggy distributions, this happens *after* e2fsck is run. And it is in those distributions e2fsck can sometimes get confused about when the last time the filesystem was checked --- especially if the system is getting rebooted a lot (which tends to be the case with people who are dual-booting). So the cases where this happens a lot are (a) people who are using windows and so the CMOS hwclock is ticking localtime, (b) distributions that don't adjust the Linux system clock before e2fsck runs. Unfortunately Ubuntu users in Europe fit this demographic hugely, and Ubuntu refuses to fix this problem[1], so it's been personally very vexing, because the users complain to *me*, and I can't fix the problem, because it's a distribution init script issue. So what I tell people is to upgrade to the latest e2fsprogs, and then set in /etc/e2fsck.conf: [options] buggy_init_scripts = 1 Maybe someday Ubuntu will get this right --- but I'm not counting on it. [1] Something about installer CD's, and not wanting to ask the users any questions, not even what time zone they are in, or some other crazyness. I never completely understood the argument and their design constraints. - Ted P.S. If there are other scripts which are started, they can also get confused because the time is getting warped backwards early-on. I haven't done an analysis to find out which sort programs might be vulnerable to this, but this is not necessarily an e2fsck-specific problems. After all, it *is* reasonable to expect that the time returned by time(0) or gettimeofday() is correct, and many programs do make that assumption -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCI Failed to allocate mem for PCI ROM
On Sat, Jan 12, 2008 at 12:27:05AM -0700, Grant Grundler wrote: > Looking at setup-bus.c:pci_bridge_check_ranges(), I'm concluding that: > [7] is IO Range. > [8] is MMIO > [9] is Prefetchable MMIO > [10] no clue...maybe used by host PCI bus controllers. #10 is for cardbus bridges, IIRC. > 0x10 is 1MB and would be the minimum MMIO range that can be allocated. > So that looks right too. Probably need to find out what is allocating > 0xe000 instead. I believe that the setup-bus code just tried to allocate 1M ROM of some device using prefetchable window of the bridge :00:00.0. That failed, probably because there is no MEM space left on the root bus, which is perfectly OK. Then, the ROM might be successfully allocated in the non-prefetchable MMIO space. So, I don't see any problem in this situation. The only thing I could suggest is to lower the log level in that message from KERN_ERR to KERN_WARNING... Ivan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Huawei EC321 CDMA PCCARD support broken
在 2008-01-08二的 07:27 +0100，Matthias Urlichs写道： > Hi, > > A lot of google searches reflect that, the latest kernel supporting > > Huawei EC321 CDMA PCCARD is 2.6.17. My version (2.6.22-14 on Ubuntu) > > doesn't work. > > > This is probably because ... > > > [ 3804.14] > > /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: > > USB Serial support registered for pl2303 > > ... the card is in fact recognized by the pl2303 driver instead of the > Option driver. This driver may do something stupid. I am not sure if it's the case. I just managed to compile a kernel in Ubuntu myself, and I used the config file of default Ubuntu kernel, only with a slight twist: # CONFIG_USB_SERIAL_PL2303 is not set Using the new kernel, I got: [ 177.916000] ehci_hcd :16:00.2: irq 20, io mem 0x50002000 [ 178.016000] usb 6-1: new full speed USB device using ohci_hcd and address 2 [ 178.016000] ehci_hcd :16:00.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2 004 [ 178.016000] usb usb8: configuration #1 chosen from 1 choice [ 178.016000] hub 8-0:1.0: USB hub found [ 178.016000] hub 8-0:1.0: 2 ports detected [ 178.888000] usb 6-1: new full speed USB device using ohci_hcd and address 3 [ 180.12] usb 6-1: new full speed USB device using ohci_hcd and address 4 [ 180.388000] usb 6-1: configuration #1 chosen from 1 choice [ 180.392000] option 6-1:1.0: GSM modem (1-port) converter detected [ 180.392000] usb 6-1: GSM modem (1-port) converter now attached to ttyUSB0 [ 180.396000] option 6-1:1.1: GSM modem (1-port) converter detected [ 180.396000] usb 6-1: GSM modem (1-port) converter now attached to ttyUSB1 Also 'lsmod' told me the module 'pl2303' is not loaded. Do the dialing I got the same problem: [snip] WvDial<*1>: Carrier detected. Waiting for prompt. WvDial: Connected, but carrier signal lost! Retrying... Later I will try a Ubuntu 6.04 live CD to see if the same hardware works for 6.04 myself (previous i only read that it worked for 6.04). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Sat, 12 Jan 2008 14:39:47 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > On 12-01-08 12:12, Pierre Ossman wrote: > > > I'm a bit confused here. Bjorn Helgaas wanted to remove the > > pnp_start/stop_dev() calls completely, and you want them called all the > > time. :) > > Wanted where? Haven't seen a coment from Bjorn? But -- while removing them > both looks (as) sensible from a mirror-image viewpoint, this wouldn't fix > the problem. > Ah, sorry. It was a different thread. Look for a mail with the subject "PNP: do not stop/start devices in suspend/resume path" in the LKML och linux-pm archives. > > But we certainly need the pnp_start_dev() in the current flow of things. It > not being called is the problem this fixes... > I think the previous suggestion was that the drivers should call this, not the core, so that it behaved more like other parts of the kernel (e.g. PCI). Rgds Pierre signature.asc Description: PGP signature
Re: [patch] split MMC_CAP_4_BIT_DATA
On Jan 12, 2008 9:02 PM, Robin Getz <[EMAIL PROTECTED]> wrote: > On Fri 11 Jan 2008 12:52, Robin Getz pondered: > > > On Fri 11 Jan 2008 04:35, Pierre Ossman pondered: > > > On Fri, 11 Jan 2008 04:08:53 -0500 > > > "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > > > > > > > On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote: > > > > > So it's far more probable that you've misdiagnosed your error than > > > this being the actual problem. > > > > > > > > the guys who design the silicon are telling us it doesnt work. our > > > > tests show it not working. i'm not sure what else you want here. > > > > > > > > > > More information. You have not provided any speculation as to why it > > > doesn't work, or what you've done to figure it out. > > > > I have been trying to get the detailed information from the hardware > > (silicon designer) guy about why he believes support for 4-bit MMC is > > not there, but I have not heard back yet. > > > > As soon as I hear from them - and either understand why 4-bit MMC doesn't > > work, or if the Blackfin docs are incorrect (either is OK outcome) - I will > > let you know. > > According to the HW folks - it is exactly as Pierre indicated - in theory it > should work, 4-bit MMC requires usage of different set of commands as > compared to 4-bit SD, so it should be just software - although no one has > tested it yet. > Vivi is helping us to do the test again, and she will fire a bug tracker about this issue next week. So we can debug it again. > So I guess this is back on Bryan/Cliff to make work > > Thanks for pushing back. > Yes, Thanks a lot Pierre. -Bryan Wu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: rtl8187 rate control doesn't work
On Sat, 12 Jan 2008 15:44:30 +0100 Hauke Mehrtens <[EMAIL PROTECTED]> wrote: > I have tested kernel 2.6.24-rc7-git4 with the build in rtl8187 module > and I have the same problem. Could you please try the wireless-2.6 kernel tree? I think it's fixed there. Details on how to download that can be found here: http://linuxwireless.org/en/developers/Documentation/git-guide -- Ciao Stefano -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] split MMC_CAP_4_BIT_DATA
On Sat, 12 Jan 2008 08:02:37 -0500 Robin Getz <[EMAIL PROTECTED]> wrote: > > According to the HW folks - it is exactly as Pierre indicated - in theory it > should work, 4-bit MMC requires usage of different set of commands as > compared to 4-bit SD, so it should be just software - although no one has > tested it yet. > > So I guess this is back on Bryan/Cliff to make work > > Thanks for pushing back. > It's what I do ;) If you provide some dumps of your test runs next week, I'm sure I can help with some qualified guesses as to what the problem might be. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Sat, 12 Jan 2008 17:40:30 +0300 Ivan Kokshaysky <[EMAIL PROTECTED]> wrote: e. > > > Ivan, you posted one a while ago, but never seemed to get any > > confirmation if it helped or not. Should I use that and drop > > Arjan's? > > Actually I'm strongly against Arjan's patch. First, it's based on > assumption that the MMCONFIG thing is sort of fundamentally broken > on some systems, but none of the facts we have so far does confirm > that. And second, I really don't like the implementation as it breaks > all non-x86 arches (or forces them to add a set of totally meaningless > PCI functions). no it doesn't! Other arches need no changes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Lenovo ThinkPads need acpi_osi="Linux"
> Now, what should we do about it? Add a quirk to always define the Linux OSI > string on ThinkPads (based on DMI information)? All IBM ones (which won't > have BIOS revisions anymore, anyway) deal well with it, and Lenovo ones > seem to benefit from it. If Lenovo systems do the right thing then I guess submit a patch which checks for a DMI identifier string for Lenovo and if so don't lie to the ACPI interpreter. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
On 1/12/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > On Fri, 11 Jan 2008 15:16:57 -0500, Jon Smirl wrote: > > On 1/11/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > Secondly, it promotes OF device names as acceptable aliases. This I > > > don't think I agree with. While I see some value in moving the OF name > > > -> Linux name translation to the drivers themselves (even though I > > > don't see this as a mandatory move either), this doesn't imply that OF > > > names should be used as aliases. I don't like the idea that different > > > architectures will name the same device differently in a visible way. > > > This could easily break user-space code that makes assumptions on the > > > device names (libsensors comes to mind.) So, I think that this part > > > will need some more discussion. > > > > They're aliases. On the x86 my e1000 Ethernet driver loads using this > > alias name: > > "pci:v8086d1010sv*sd*bc*sc*i*" > > In fact, the e1000 driver has 63 alias names in addition to "e1000" > > > > But it's still the e1000 driver after it is loaded. > > [EMAIL PROTECTED]:/home/linux/drivers/net/e1000$ lsmod | grep e1000 > > e1000 115968 0 > > > > Loading a I2C driver with an OF alias name is not going to change the > > module name after it is loaded. In fact, once the module is in memory > > there's no way to tell what name was used to load it. > > Of course. That's not what I was worried about... what I was worried > about is something your patch set doesn't do but I misread the code and > I thought it was doing. I'll read it again before I make more comments > on this. > > > OF device names are set by the Open Firmware committee. It is not > > reasonable to force the Linux names back into Open Firmware since this > > would force the other operating systems using Open Firmware to adopt > > the Linux names. > > I never meant to force the Linux names into Open Firmware. It wouldn't > make sense especially when the Linux names are invented by random > contributors with no specific rules, and can even change over time. > > What I meant is that the translation from Open Firmware device name to > Linux device name could happen in different ways. Making module aliases > out of the is one possibility but this is not the only one. > > I am curious why the translation could not happen "offline". As I > understand it, you're getting the device names from these .dts files. > However you're not parsing them in the kernel directly, are you? I > presume that you have some tool that converts these files into C code > that the kernel can use? This conversion tool could translate the names. Those dts files are for embedded devices that were specifically developed for Linux. All of the PowerPC Macs in the world have a device tree in ROM that was developed by Apple following the Open Firmware standard. Same thing for Sun boxes, but I'm not working on those. The kernel has an existing mechanism for handling translations like these, the alias scheme. > > This issue hasn't been visible before since there was a global table > > in the PowerPC code mapping all known Open Firmware names into linux > > names. Keeping this as a global table doesn't scale. The mapping needs > > to be done by each device individually. > > Looking at your patch set, I see only 11 entries in the table (in > arch/powerpc/sysdev/fsl_soc.c) that patch #2 deletes. Are there more in > other files? I'm asking because 11 entries hardly qualifies as "doesn't > scale". I sure hope that you're not doing all this for the sole purpose > of getting rid of this 11-element table. Currently developers add entries to the table in their private builds for the i2c devices they are using. Another way to avoid adding a table entry is to create a platform device in the platform code. But this support is being extended to audio codecs too. There are hundreds of audio codecs. The whole purpose of this code is to dynamically load the correct i2c and audio drivers by reading the device tree instead of having static i2s/codec devices for every possible platform combination. -- Jon Smirl [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: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Sat, Jan 12, 2008 at 07:46:32AM -0800, Arjan van de Ven wrote: > Ivan Kokshaysky <[EMAIL PROTECTED]> wrote: > > Actually I'm strongly against Arjan's patch. First, it's based on > > assumption that the MMCONFIG thing is sort of fundamentally broken > > on some systems, but none of the facts we have so far does confirm > > that. And second, I really don't like the implementation as it breaks > > all non-x86 arches (or forces them to add a set of totally meaningless > > PCI functions). > > no it doesn't! > Other arches need no changes. Umm, true. I misread your patch. But it doesn't change anything - that wasn't my main objection anyway. Ivan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [i2c] [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
On 1/12/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Jon,
>
> On Fri, 11 Jan 2008 20:20:15 +0100, Jean Delvare wrote:
> > > +{
> > > + /* only powerpc drivers implement the id_table,
> > > +* it is empty on other platforms */
> > > + if (id) {
> > > + while (id->name[0]) {
> > > + if (strcmp(client->driver_name, id->name) == 0)
> >
> > This doesn't look right to me. You should be comparing client->name,
> > not client->driver_name, with id->name. Where id_table is implemented,
> > client->driver_name might not even be set. I see that the next patch in
> > the series makes use of client->driver_name as well, so your code
> > "works"... but this ain't correct still.
>
> Err, scratch this (and related comments), I just realized what you were
> trying to do. That's different from what I had in mind and so I read
> your code wrong. I'll read it (and test it) again not making this
> incorrect assumption and my comments will likely be different after
> that. Well, I still think that it needs to be changed a bit, but
> probably not in the direction I suggested at first (which, I realize
> now, has its own share of issues - so it's not fair to me to point you
> there.)
The common scheme used elsewhere in the kernel for handling more than
one device in a single driver is aliases. The i2c code's existing
driver_name/type combination is a different way of implementing the
same feature. But there is no real need for driver_name/type on any
platform if aliases are used. Back in version 10 or 11 I had code in
there which replaced the two fields with aliases on all platforms but
too many people objected so I removed it..
IMHO, driver_name/type should be removed in new style drivers and
replaced with aliases on all platforms since aliases are the standard
kernel mechanism.
>
> Sorry for the trouble. I'll post updated comments later today, but I'm
> also pretty busy with other issues, some of which need to be solved
> before 2.6.24 is released so I can't really delay them.
>
> --
> Jean Delvare
>
--
Jon Smirl
[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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Saturday 12 January 2008 16:21:50 Pierre Ossman wrote: > On Sat, 12 Jan 2008 14:39:47 +0100 > > Rene Herman <[EMAIL PROTECTED]> wrote: > > On 12-01-08 12:12, Pierre Ossman wrote: > > > I'm a bit confused here. Bjorn Helgaas wanted to remove the > > > pnp_start/stop_dev() calls completely, and you want them called all the > > > time. :) > > > > Wanted where? Haven't seen a coment from Bjorn? But -- while removing > > them both looks (as) sensible from a mirror-image viewpoint, this > > wouldn't fix the problem. > > Ah, sorry. It was a different thread. Look for a mail with the subject > "PNP: do not stop/start devices in suspend/resume path" in the LKML och > linux-pm archives. > > > But we certainly need the pnp_start_dev() in the current flow of things. > > It not being called is the problem this fixes... > > I think the previous suggestion was that the drivers should call this, not > the core, so that it behaved more like other parts of the kernel (e.g. > PCI). I don't think that drivers should call pnp_start_dev() on resume. All drivers would need to call it as all PnP cards are disabled after boot. No driver does that currently. 3c509 driver doesn't seem to register as pnp_card_driver so that's probably why it's not enable after resume. I guess that more ISA PnP drivers have this problem. I have some other PnP network and sound cards so I'll test them. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system
On Sat, Jan 12, 2008 at 10:23:11AM +0100, Peter Zijlstra wrote: > > On Fri, 2008-01-11 at 20:26 -0500, Benjamin LaHaise wrote: > > Hello folks, > > > > I'd like to put the patch below out for comments to see if folks think the > > approach is a valid fix to reduce the latency of synchronize_rcu(). The > > motivation is that an otherwise idle system takes about 3 ticks per network > > interface in unregister_netdev() due to multiple calls to > > synchronize_rcu(), > > which adds up to quite a few seconds for tearing down thousands of > > interfaces. By flushing pending rcu callbacks in the idle loop, the system > > makes progress hundreds of times faster. If this is indeed a sane thing > > to, > > it probably needs to be done for other architectures than x86. And yes, > > the > > network stack shouldn't call synchronize_rcu() quite so much, but fixing > > that > > is a little more involved. > > So, instead of only relying on the tick to drive the RCU state machine, > you add the idle loop to it. This seems to make sense, esp because nohz > is held off until rcu is idle too. > > Even though Andi is right in that its not the proper solution to your > problem, I think its worth doing anyway for the general benefit of RCU. > > But lets ask Paul, he is Mr RCU after all :-) ;-) At first glance, looks workable! One concern is how often it gets invoked. If rcu_check_callbacks() is invoked too often on lots of idle CPUs, it could degrade system performance due to contention on the RCU internal locks and due to cacheline bouncing. Now, my guess is that the rcu_pending() call should throttle things nicely, but it would be good to test. All the testing ideas thus far have been involved and unlikely to test it well, for example: CPU 0: lots of synchronize_rcu() calls. CPU 1: lots of synchronize_rcu() calls. CPU 2: idle. CPU 3: CPU-bound workload. Compare the rate of progress made by CPU 3 with CPUs 0 and 1 active or not. But this would not test much -- the load that CPUs 0, 1, and 2 might be placing on the bus/cache/RCU-locks would not be visible to CPU 3. One could cache-thrash between CPU 3 and 4, but this requires a >=5-CPU system. Will think on it some more. > > diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c > > index 9663c2a..592f6e4 100644 > > --- a/arch/x86/kernel/process_32.c > > +++ b/arch/x86/kernel/process_32.c > > @@ -188,6 +188,9 @@ void cpu_idle(void) > > rmb(); > > idle = pm_idle; > > > > + if (rcu_pending(cpu)) > > + rcu_check_callbacks(cpu, 0); Given that it is not legal to have RCU read-side critical sections in the idle loop, how about the following? + rcu_check_callbacks(cpu, 1); Perhaps also changing the name of rcu_check_callbacks()'s second parameter from "user" to something like "in_quiescent_state". Might speed up grace-period recognition in some cases -- wouldn't need to wait for the next trip through the scheduler in some cases. Thanx, Paul > > + > > if (!idle) > > idle = default_idle; > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On 12-01-08 16:21, Pierre Ossman wrote: Ah, sorry. It was a different thread. Look for a mail with the subject "PNP: do not stop/start devices in suspend/resume path" in the LKML och linux-pm archives. Right, and I see that the removal of start/stop is already in -mm. That's not going to work. Something (such as removing power) disabled Ondrej's CS4236 and the pnp_start_dev() is needed to re-enable it upon resume. But we certainly need the pnp_start_dev() in the current flow of things. It not being called is the problem this fixes... I think the previous suggestion was that the drivers should call this, not the core, so that it behaved more like other parts of the kernel (e.g. PCI). It seems all PnP drivers would need to stick a pnp_start_dev in their resume method then which means it really belongs in core. One important point where PnP and PCI differ is that PnP allows to change the resources on a protocol level and I don't see how it could ever not be necessary to restore the state a user may have set if power has been removed. Hibernate is just that, isn't it? 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/RFC] synchronize_rcu(): high latency on idle system
On Saturday 12 January 2008 10:23:11 Peter Zijlstra wrote: > > On Fri, 2008-01-11 at 20:26 -0500, Benjamin LaHaise wrote: > > Hello folks, > > > > I'd like to put the patch below out for comments to see if folks think the > > approach is a valid fix to reduce the latency of synchronize_rcu(). The > > motivation is that an otherwise idle system takes about 3 ticks per network > > interface in unregister_netdev() due to multiple calls to > > synchronize_rcu(), > > which adds up to quite a few seconds for tearing down thousands of > > interfaces. By flushing pending rcu callbacks in the idle loop, the system > > makes progress hundreds of times faster. If this is indeed a sane thing > > to, > > it probably needs to be done for other architectures than x86. And yes, > > the > > network stack shouldn't call synchronize_rcu() quite so much, but fixing > > that > > is a little more involved. > > So, instead of only relying on the tick to drive the RCU state machine, > you add the idle loop to it. This seems to make sense, esp because nohz > is held off until rcu is idle too. For NOHZ I agree it would be probably better to just force a quiescent cycle than to schedule a one jiffie tick like it is currently done. For non NOHZ I'm not so sure. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote: > Takashi Iwai wrote: > > At Thu, 10 Jan 2008 23:02:53 +0100, > > > > Harald Dunkel wrote: > >> Takashi Iwai wrote: > >>> Hm... Just to be sure, try the patch below. It's a clean up patch > >>> that I'd like to apply later. > >> > >> Sorry, no sound. > > > > OK, but I'd like to know whether this makes no regression to rc6. > > Could you check? > > > > Also, what exactly did you test? "No sound" means that no sound from > > the headphone / line-out or from the speaker? > > > > One interesting test would be to increase the value of udelay() in the > > reverted patch. What happens if it's set to 500? > > There is no udelay() in the reverted patch. If I replace "udelay(10)" > by "udelay(500)" in the original rc7, then there is still no sound. > > This is like fishing in the dark. We've got a working version. Why not > keep it? > > > Regards > > Harri Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 [7.760336] pnpacpi: exceeded the max number of mem resources: 12 [7.760401] pnpacpi: exceeded the max number of mem resources: 12 [7.760470] pnpacpi: exceeded the max number of mem resources: 12 [7.760536] pnpacpi: exceeded the max number of mem resources: 12 [7.760601] pnpacpi: exceeded the max number of mem resources: 12 [7.760666] pnpacpi: exceeded the max number of mem resources: 12 [7.760984] pnp: PnP ACPI: found 12 devices [7.761048] ACPI: ACPI bus type pnp unregistered [7.761345] PCI: Using ACPI for IRQ routing [7.761409] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report And... [7.784472] system 00:05: ioport range 0xc80-0xcff could not be reserved [7.784546] system 00:08: iomem range 0xfed0-0xfed003ff has been reserved [7.784617] system 00:09: ioport range 0x900-0x97f has been reserved [7.784684] system 00:09: ioport range 0x4d0-0x4d1 has been reserved [7.784750] system 00:09: ioport range 0x1000-0x1005 has been reserved [7.784817] system 00:09: ioport range 0x1008-0x100f has been reserved [7.784887] system 00:0a: ioport range 0xf400-0xf4fe has been reserved [7.784954] system 00:0a: ioport range 0x1006-0x1007 has been reserved [7.785021] system 00:0a: ioport range 0x100a-0x1059 could not be reserved [7.785088] system 00:0a: ioport range 0x1060-0x107f has been reserved [7.785154] system 00:0a: ioport range 0x1080-0x10bf has been reserved [7.785221] system 00:0a: ioport range 0x10c0-0x10df has been reserved [7.785288] system 00:0a: ioport range 0x1010-0x102f has been reserved [7.785354] system 00:0a: ioport range 0x809-0x809 has been reserved [7.785425] system 00:0b: iomem range 0x0-0x9efff could not be reserved [7.785492] system 00:0b: iomem range 0x9f000-0x9 could not be reserved [7.785560] system 00:0b: iomem range 0xc-0xc has been reserved [7.785627] system 00:0b: iomem range 0xe-0xf has been reserved [7.785696] system 00:0b: iomem range 0x10-0x3f6923ff could not be reserved [7.785775] system 00:0b: iomem range 0x3f692400-0x3f6f could not be reserved [7.785854] system 00:0b: iomem range 0x3f70-0x3f7f could not be reserved [7.785932] system 00:0b: iomem range 0x3f70-0x3fef could not be reserved [7.786011] system 00:0b: iomem range 0xfff0-0x could not be reserved [7.786090] system 00:0b: iomem range 0xffa0-0xffaf has been reserved [7.786157] system 00:0b: iomem range 0xfec0-0xfec0 could not be reserved [7.786236] system 00:0b: iomem range 0xfee0-0xfee0 could not be reserved That's almost the entirety of the differences between a dmesg from a 2.6.24-rc7 boot and a 2.6.22 boot. System itself is a Dell Inspiron 1420n laptop running a 64bit kernel and userland - there is a "pop" from the speakers when booting, but no sound at all. I'll pull a new tree from GIT, but I'm thinking that the above changes are probably related to the move from ACPI motherboard drivers to the PNP platform driver. What I don't understand is how, if there are only more mem resources than the new PNP platform driver can handle, why there are also ioport ranges that could not be reserved. Additionally, with the same kernel, the iwlwifi driver appears to cause the new 802.11 code to crash. This doesn't stop the driver or cause any problems with the connection. I've been using the iwlwifi driver with 2.6.22 for a while and haven't seen anything like this. The message seen is: [ 30.504842] eth1: Initial auth_alg=0 [ 30.504848] eth1: authenticate with AP 00:11:50:fa:d4:ba [ 30.506630] eth1: RX authentication from 00:11:50:fa:d4:ba (alg=0 transaction =2 status=0) [ 30.506633] eth1: authenticated [ 30.506636] eth1: associate with AP 00:11:50:fa:d4:ba [ 30.509261] eth1: RX AssocResp
Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> --- a/arch/x86/pci/mmconfig_32.c
> +++ b/arch/x86/pci/mmconfig_32.c
> @@ -30,10 +30,6 @@ static u32 get_base_addr(unsigned int seg, int
> bus, unsigned devfn) struct acpi_mcfg_allocation *cfg;
> int cfg_num;
>
> - if (seg == 0 && bus < PCI_MMCFG_MAX_CHECK_BUS &&
> - test_bit(PCI_SLOT(devfn) + 32*bus,
> pci_mmcfg_fallback_slots))
> - return 0;
> -
> for (cfg_num = 0; cfg_num < pci_mmcfg_config_num; cfg_num++)
> { cfg = &pci_mmcfg_config[cfg_num];
> if (cfg->pci_segment == seg &&
> @@ -68,13 +64,16 @@ static int pci_mmcfg_read(unsigned int seg,
> unsigned int bus, u32 base;
>
> if ((bus > 255) || (devfn > 255) || (reg > 4095)) {
> - *value = -1;
> +err: *value = -1;
> return -EINVAL;
> }
>
> + if (reg < 256)
> + return pci_conf1_read(seg,bus,devfn,reg,len,value);
> +
btw this is my main objection to your patch; it intertwines the conf1 and
mmconfig code even more.
When (and I'm saying "when" not "if") systems arrive that only have MMCONFIG
for some of the devices,
we'll have to detangle this again, and I'm really not looking forward to that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system
On Sat, Jan 12, 2008 at 03:37:59AM +0100, Andi Kleen wrote: > > And yes, the > > network stack shouldn't call synchronize_rcu() quite so much, but fixing > > that > > is a little more involved. > > ... but the correct solution. There has to be at least 1 synchronize_rcu() or equivalent in the unregister_netdev() path. I suspect the easiest way to fix it might be to use call_rcu() to actually free the network device, as anything else will limit performance of single threaded teardown (ie, when an l2tp daemon gets terminated via kill -9). This means an API change that exposes rcu for unregister_netdev(). -ben -- "Time is of no importance, Mr. President, only life is important." Don't Email: <[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: [RFC][PATCH] per-task I/O throttling
Peter Zijlstra wrote: > On Sat, 2008-01-12 at 16:27 +0530, Balbir Singh wrote: >> * Peter Zijlstra <[EMAIL PROTECTED]> [2008-01-12 10:46:37]: >> >>> On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote: On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said: > The interesting feature is that it allows to set a priority for each > process container, but AFAIK it doesn't allow to "partition" the > bandwidth between different containers (that would be a nice feature > IMHO). For example it would be great to be able to define per-container > limits, like assign 10MB/s for processes in container A, 30MB/s to > container B, 20MB/s to container C, etc. Has anybody considered allocating based on *seeks* rather than bytes moved, or counting seeks as "virtual bytes" for the purposes of accounting (if the disk can do 50mbytes/sec, and a seek takes 5millisecs, then count it as 100K of data)? >>> I was considering a time scheduler, you can fill your time slot with >>> seeks or data, it might be what CFQ does, but I've never even read the >>> code. >>> >> So far the definition of I/O bandwidth has been w.r.t time. Not all IO >> devices have sectors; I'd prefer bytes over a period of time. > > Doing a time based one would only require knowing the (avg) delay of > seeks, whereas doing a bytes based one would also require knowing the > (avg) speed of the device. > > That is, if you're also interested in providing a latency guarantee. > Because that'd force you to convert bytes to time again. So, what about considering both bytes/sec and io-operations/sec? In this way we should be able to limit huge streams of data and seek storms (or any mix of them). Regarding CFQ, AFAIK it's only possible to configure an I/O priorty for a process, but there's no way for example to limit the bandwidth (or I/O operations/sec) for a particular user or group. -Andrea -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 PREEMPT_RT] Compilation fix for PPC
Hi, 2.6.24-rc5-rt1 won't compile on PPC if CONFIG_SMP is turned off. CC arch/powerpc/kernel/pmc.o In file included from include/asm/tlb.h:62, from arch/powerpc/mm/mem.c:44: include/asm-generic/tlb.h: In function ‘tlb_gather_mmu’: include/asm-generic/tlb.h:58: error: implicit declaration of function ‘__get_cpu_lock’ include/asm-generic/tlb.h:58: error: ‘mmu_gathers’ undeclared (first use in this function) include/asm-generic/tlb.h:58: error: (Each undeclared identifier is reported only once include/asm-generic/tlb.h:58: error: for each function it appears in.) include/asm-generic/tlb.h:58: error: invalid lvalue in unary ‘&’ include/asm-generic/tlb.h:58: warning: type defaults to ‘int’ in declaration of ‘type name’ include/asm-generic/tlb.h:58: error: invalid lvalue in unary ‘&’ include/asm-generic/tlb.h:58: error: invalid lvalue in unary ‘&’ include/asm-generic/tlb.h:58: warning: type defaults to ‘int’ in declaration of ‘type name’ include/asm-generic/tlb.h:58: error: invalid lvalue in unary ‘&’ include/asm-generic/tlb.h:58: error: implicit declaration of function ‘__get_cpu_var_locked’ include/asm-generic/tlb.h:58: error: invalid lvalue in unary ‘&’ include/asm-generic/tlb.h: In function ‘tlb_finish_mmu’: include/asm-generic/tlb.h:96: error: ‘mmu_gathers’ undeclared (first use in this function) include/asm-generic/tlb.h:96: error: invalid lvalue in unary ‘&’ include/asm-generic/tlb.h:96: warning: type defaults to ‘int’ in declaration of ‘type name’ include/asm-generic/tlb.h:96: error: invalid lvalue in unary ‘&’ include/asm-generic/tlb.h:96: error: invalid lvalue in unary ‘&’ include/asm-generic/tlb.h:96: warning: type defaults to ‘int’ in declaration of ‘type name’ include/asm-generic/tlb.h:96: error: invalid lvalue in unary ‘&’ The patch below fixes it. Thanks, Sripathi. Signed-off-by: Sripathi Kodi <[EMAIL PROTECTED]> diff -uprN linux-2.6.24-rc5-rt1_org/include/asm-powerpc/percpu.h linux-2.6.24-rc5-rt1/include/asm-powerpc/percpu.h --- linux-2.6.24-rc5-rt1_org/include/asm-powerpc/percpu.h 2008-01-12 17:43:03.0 +0530 +++ linux-2.6.24-rc5-rt1/include/asm-powerpc/percpu.h 2008-01-12 17:43:58.0 +0530 @@ -68,6 +68,8 @@ extern void setup_per_cpu_areas(void); #define __get_cpu_var(var) per_cpu__##var #define __raw_get_cpu_var(var) per_cpu__##var +#define __get_cpu_lock(var, cpu) per_cpu_lock__##var##_locked +#define __get_cpu_var_locked(var, cpu) per_cpu__##var##_locked #endif /* SMP */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Updatedb hangs Kernel 2.6.22.9-cfs-v22
Hi, I can't use updatedb in Debian Etch (stable) using customized Kernel 2.6.22.9-cfs-v22. When I ran updatedb, after ~1 minute my system hangs and "caps lock" LED is blinking. No log is registered. .config is attached. Regards, Renato S. Yamane # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.9-cfs-v22 # Sun Sep 30 15:16:21 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_MODEL=4 CONFIG_HPET_TIMER=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y # CONFIG_PREEMPT_BKL is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_VM86=y CONFIG_TOSHIBA=m # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_EFI_VARS is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set C
Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in
On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote: > btw this is my main objection to your patch; it intertwines the conf1 and > mmconfig code even more. > When (and I'm saying "when" not "if") systems arrive that only have MMCONFIG > for some of the devices, > we'll have to detangle this again, and I'm really not looking forward to that. I think this will be OK. We'll end up with three pci_ops, one for mmconfig-only, one for mixed mmconfig-conf1 and one for conf1. We could do with that now actually -- the machines which will definitely go beserk if you try to use mmconfig could have the conf1 ops on those busses. Let's take Ivan's patch for now, and do that patch for 2.6.26. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8187 rate control doesn't work
I have tried wireless-2.6 and I have the same problem. If the rate goes over 11M no TCP/IP traffic goes through the wireless connecting. If rate is set to auto and the rate control algorithm changes it to something less than 11M TCP/IP traffic goes through, but if it is more than 11M no TCP/IP traffic goes through the wireless link. with "iwconfig wlan0 rate 11M" everything works. -- Hauke Mehrtens Stefano Brivio wrote: > On Sat, 12 Jan 2008 15:44:30 +0100 > Hauke Mehrtens <[EMAIL PROTECTED]> wrote: > >> I have tested kernel 2.6.24-rc7-git4 with the build in rtl8187 module >> and I have the same problem. > > Could you please try the wireless-2.6 kernel tree? I think it's fixed > there. Details on how to download that can be found here: > http://linuxwireless.org/en/developers/Documentation/git-guide > > > -- > Ciao > Stefano > - > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/8] Series to improve the x86 backtracing code
On Fri, 11 Jan 2008, Arjan van de Ven wrote: > > this patch series improves the x86 backtracing code in the following ways: I heartily approve of this series. Good jorb. Especially the fact that you also fixed x86-64, which has been a total disaster in this area. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Updatedb hangs Kernel 2.6.22.9-cfs-v22
On Jan 12, 2008 10:03 AM, Renato S. Yamane <[EMAIL PROTECTED]> wrote: > Hi, > I can't use updatedb in Debian Etch (stable) using customized Kernel > 2.6.22.9-cfs-v22. > > When I ran updatedb, after ~1 minute my system hangs and "caps lock" LED > is blinking. No log is registered. Please switch out of X11 to a text mode console (CTRL-ALT-F1), and run updatedb there. Capture the oops with a digital camera, and post a link to the picture (not the picture itself!) to the list. Or, write down the oops carefully, and post the text. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system
On Saturday 12 January 2008 18:51:35 Benjamin LaHaise wrote: > On Sat, Jan 12, 2008 at 03:37:59AM +0100, Andi Kleen wrote: > > > And yes, the > > > network stack shouldn't call synchronize_rcu() quite so much, but fixing > > > that > > > is a little more involved. > > > > ... but the correct solution. > > There has to be at least 1 synchronize_rcu() or equivalent in the > unregister_netdev() path. I suspect the easiest way to fix it might be to > use call_rcu() to actually free the network device, as anything else will > limit performance of single threaded teardown (ie, when an l2tp daemon > gets terminated via kill -9). This means an API change that exposes > rcu for unregister_netdev(). The call_rcu() could be in free_netdev() couldn't it? -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Updatedb hangs Kernel 2.6.22.9-cfs-v22
On Sat, Jan 12, 2008 at 04:03:43PM -0200, Renato S. Yamane wrote: > Hi, > I can't use updatedb in Debian Etch (stable) using customized Kernel > 2.6.22.9-cfs-v22. > Hi, Can you see if it happens with the latest CFS backport. Its been updated quite a bit since then. You can find it at http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22.15-v24.1.patch > When I ran updatedb, after ~1 minute my system hangs and "caps lock" LED is > blinking. No log is registered. > -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Usage semantics of atomic_set ( )
> What operations are you using to implement spinlocks? The cpu provides atomic exchange instruction (atomic Read/write semantics) which forms the back end of spin lock code. __raw_spin_trylock( ) atomically swaps the lock memory with a reg (set to 1) Using a pool of spinlocks rather that original idea of spinlock per atomic_t anyways seems to be a better idea. I really appreciate the responses. Thanks a lot -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Saturday, 12 of January 2008, Rene Herman wrote: > On 12-01-08 16:21, Pierre Ossman wrote: > > > Ah, sorry. It was a different thread. Look for a mail with the subject > > "PNP: do not stop/start devices in suspend/resume path" in the LKML och > > linux-pm archives. > > Right, and I see that the removal of start/stop is already in -mm. That's > not going to work. Something (such as removing power) disabled Ondrej's > CS4236 and the pnp_start_dev() is needed to re-enable it upon resume. > > >> But we certainly need the pnp_start_dev() in the current flow of > >> things. It not being called is the problem this fixes... > > > > I think the previous suggestion was that the drivers should call this, > > not the core, so that it behaved more like other parts of the kernel > > (e.g. PCI). > > It seems all PnP drivers would need to stick a pnp_start_dev in their resume > method Yes. > then which means it really belongs in core. Yes, if practical. > One important point where PnP and PCI differ is that PnP allows to change the > resources on a protocol level and I don't see how it could ever not be > necessary to restore the state a user may have set if power has been > removed. Hibernate is just that, isn't it? Basically, yes, it is. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SH/Dreamcast - add support for GD-Rom CDROM drive on SEGA Dreamcast
On Sat, 12 Jan 2008 14:14:01 + Adrian McMenamin <[EMAIL PROTECTED]> wrote:
>
> > > + spin_command->cmd[0] = 0x70;
> > > + spin_command->cmd[2] = 0x1f;
> > > + spin_command->buflen = 0;
> > > + gd.pending = 1;
> > > + gdrom_packetcommand(gd.cd_info, spin_command);
> > > + /* 60 second timeout */
> > > + wait_event_interruptible_timeout(command_queue, gd.pending == 0, HZ *
> > > 60);
> > > + gd.pending = 0;
> > > + kfree(spin_command);
> > > + if (gd.status & 0x01) {
> > > + /* log an error */
> > > + gdrom_getsense(NULL);
> > > + return -EIO;
> > > + }
> > > + return 0;
> > > +}
> >
> > If the wait_event_interruptible_timeout() indeed times out, we go ahead and
> > free spin_command. But someone else could potentially be using it.
> >
> > Suppose gdrom_packetcommand() got stuck for a minute due to bad hardware,
> > or some SCHED_FIFO task preempting us here and running for 61 seconds
> > without
> > yielding or something similarly weird.
> >
>
>
> Maybe I am being stupid here, but I don't follow this. They'll get a
> non-fatal error, that's all. Who else would be using spin_command? It's
> just a series of bytes to plug into the GD Rom registers, that's all.
>
After programming the registers we need to wait for the interrupt to clear
gd.pending, don't we?
oh, I see. gd is a global singleton and we only support one command at a
time and one device. hrm.
> > > +
> > > +static int __devinit gdrom_set_interrupt_handlers(void)
> > > +{
> > > + int err;
> > > + init_waitqueue_head(&command_queue);
> > > + err = request_irq(HW_EVENT_GDROM_CMD, gdrom_command_interrupt,
> > > IRQF_DISABLED, "gdrom_command", &gd);
> > > + if (err)
> > > + return err;
> > > + init_waitqueue_head(&request_queue);
> >
> > You can initialise command_queue and request_queue at compile-time with
> > DECLARE_WAIT_QUEUE_HEAD().
> >
>
> Are you saying that is better?
Yup. Less source code, less object code, no startup-ordering issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236
On Saturday, 12 of January 2008, Rene Herman wrote: > On 12-01-08 12:12, Pierre Ossman wrote: > > > On Sat, 12 Jan 2008 02:23:27 +0100 > > Rene Herman <[EMAIL PROTECTED]> wrote: > > > >> Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for > >> Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test > >> triggering in pnp_bus_resume() and keeping the card in a suspended state. > >> > > > > I'm a bit confused here. Bjorn Helgaas wanted to remove the > > pnp_start/stop_dev() calls completely, and you want them called all the > > time. :) > > Wanted where? Haven't seen a coment from Bjorn? But -- while removing them > both looks (as) sensible from a mirror-image viewpoint, this wouldn't fix > the problem. > > As fas as I understand things, "hibernation" is basically "save state, shut > down machine" where the latter step is going to disable the card inevitably. Not exactly. In the ACPI (aka platform) mode it's: - pretend we're suspending and put everything into low power states - snapshot memory - power everything up - save image - suspend (ie. enter S4, suspending devices before). > On resume, you're going to need to restore the resources (that were saved in > pnp_dev->res) that it was using to the card, which is what pnp_start_dev() > does -- it not being called is the current problem of the card not coming > back to life. First of all, the card need not be initialized at all before .resume() is called. > pnp_stop_dev() could go in this specific situation. Not much point in first > disabling the thing it seems if a subsequent shutdown is going to take care > of that anyway. However, suspend/resume isn't just called in the case of > complete hibernation I guess and I know nothing about it all -- hence my > request to the hiberhation people for how this is designed to be. .suspend()/.resume() are used during suspend to RAM too. As far as hibernation is concerned, .resume() is used for two different purposes: (a) to bring the device up after it's been put into a low power state for snapshotting memory (b) to bring the device up (or reconfigure it if brought up already) after the hibernation image has been loaded and we're restoring the previous system state. > But we certainly need the pnp_start_dev() in the current flow of things. It > not being called is the problem this fixes... Yes, pnp_start_dev() is generally needed in .resume(). 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/
Top 10 kernel oopses for the week ending January 12th, 2008
The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas as well as with a client users can install to auto-submit oopses. Below is a top 10 list of the oopses collected in the last 7 days. (Reports prior to 2.6.23 have been omitted in collecting the top 10) This week, a total of 136 oopses and warnings have been reported, compared to 46 reports in the previous 7 days. kerneloops.org news: * Based on feedback from last weeks report, the website now tries to also present a disassembled Code: line * the kerneloops collection client is now part of Fedora (rawhide) (yum install kerneloops) * the kerneloops collection client is now included in Debian testing (apt-get install kerneloops) * gentoo has received an updated version of the client Rank 1: implement (hid code) WARN_ON at drivers/hid/hid-core.c:784 Reported 23 times (39 total reports) This appears to be the kernel doing a WARN_ON based on unexpected ioctl() arguments More info: http://www.kerneloops.org/search.php?search=implement Rank 2: __ieee80211_rx WARN_ON at net/mac80211/rx.c:1663 Reported 14 times (25 total reports) This is the recurring problem from the last few weeks The iwl3945 driver is heavily implicated for this one More info: http://www.kerneloops.org/search.php?search=__ieee80211_rx Rank 3: uart_flush_buffer (caused by bluetooth) WARN_ON drivers/serial/serial_core.c:544 Same issue as a few weeks ago; a fix was posted on LKML already Caused by the bluetooth tty layer double closing/freeing the tty Reported 8 times (24 total reports) More info: http://www.kerneloops.org/search.php?search=uart_flush_buffer Rank 4: i2c_transfer (by the cx8802/cx22702 driver) kernel NULL pointer Reported 6 times Only reported on 2.6.23.9 so far DVB related More info: http://www.kerneloops.org/search.php?search=i2c_transfer Rank 5: __ieee80211_rx_handle_packet (iwl3945) WARNING at net/mac80211/rx.c:1693 Reported 5 times Only seen with the iwl3945 driver Not the same warning as #2, but the cause may be related More info: http://www.kerneloops.org/search.php?search=__ieee80211_rx_handle_packet Rank 6: NdisDispatchPnp Kernel page fault Reported 5 times Tainted and in the external ndiswrapper binary driver loader More info: http://www.kerneloops.org/search.php?search=NdisDispatchPnp Rank 7: __lock_acquire Kernel page fault Reported 4 times (14 total reports) Reported in 2.5.24-rc5 and rc7 but previously in 2.6.18 timeframe Appears to be EXT3 related this time around More info: http://bugzilla.kernel.org/show_bug.cgi?id=9718 More info: http://www.kerneloops.org/search.php?search=__lock_acquire Rank 8: evdev_disconnect Same issue as last week Reported 4 times (14 total reports) Only seen upto 2.6.23 Al Viro diagnosed that this got fixed in 2.6.24-rc but the patch wasn't put in 2.6.23-stable More info: http://www.kerneloops.org/search.php?search=evdev_disconnect Rank 9: hfsplus_releasepage Kernel null pointer deref Reported 3 times Only reported for 2.6.24-rc7 More info: http://www.kerneloops.org/search.php?search=hfsplus_releasepage Rank 10: cfq_remove_request Kernel NULL pointer Reported 3 times Only reported for 2.6.23 Reported both from interrupt and process context More info: http://www.kerneloops.org/search.php?search=cfq_remove_request -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: The ext3 way of journalling
On Jan 12, 2008 10:06 AM, Theodore Tso <[EMAIL PROTECTED]> wrote: [snip] > Unfortunately Ubuntu users [snip] fit this demographic hugely, and > Ubuntu refuses to fix this problem[1], so it's been personally very > vexing, because the users complain to *me*, and I can't fix the problem, > because it's a distribution init script issue. Ubuntu refuses to be power user friendly. They've forgotten the True Meaning (tm) of Linux and try to be Windows-friendly, i.e., No Choices (tm). > Maybe someday Ubuntu will get this right --- but I'm not counting on it. The alternative CD installer still looks like a semi-dumbed-down debian installer. Hell, even the command-line base install is severely bloated - it's the exact opposite of LFS or gentoo. Still, it's *usable* in comparison to the livecd. > > [1] Something about installer CD's, and not wanting to ask the users > any questions, not even what time zone they are in, or some other > crazyness. I never completely understood the argument and their > design constraints. Idiot friendliness and no exceptions to power users (e.g.., bloated init scripts, UUID fstab). I switched to debian-unstable ages ago *just* because apt is _really_ easy to use. Which I use secondarily to Gentoo, where things Just Work (tm), once you patch the package ebuilds to process your .patch files anyway and, while the packages have *lots* of patches, it doesn't bloat the code *and* you can disable the patches with the "vanilla" USE flag. -- Andrey Vul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Alexander wrote: Robert Hancock wrote: There's this patch which was intended to fix it: http://lkml.org/lkml/2007/11/22/148 I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is normaly detected as: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray But I cannot mount it. All my attempts failed with ISOFS: Unable to identify CD-ROM format. With mem<=4098M or sata_nv.adma=0 it still mounts and works ok. As I wrote, it would appear that somehow the blk_queue_bounce_limit setting that the driver has made is not being respected and the block layer is still trying to feed it addresses over 4GB. Any ideas anyone? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/5] USB Kconfig: Reorganize USB Kconfig Menu
On Sat, Jan 12, 2008 at 01:20:46PM +0300, Al Boldi wrote: > Greg KH wrote: > > On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote: > > > Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device > > > Driver Menu. ?This helps the USB Kconfig Menu to be more logical/usable. > > > > > > Patchset against 2.6.23 > > > > So what was the final verdict in this patch set? > > IMHO, it's a lot better than what we have right now, and it's split up so > that you can pick and choose what you think is useful. > > > Can you rsend this against 2.6.24-rc7 with the requested changes (if > > any) in it? > > The only critical change is in patch 2/5: > > menuconfig USB_STORAGE > tristate "USB Mass Storage support" > - depends on USB && SCSI > + depends on USB && BLOCK > + select SCSI > > > I was hoping you could take care of it, or maybe wait until 2.6.25 is out. Well, if you want such a change to go into 2.6.25, I need the patches now :) So, can you respin these against 2.6.24-rc7, with the above fix, so that I can apply them and test them out? 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: new runtime scsi warnings in 2.6.24-rc6+git
On Friday, 4 of January 2008, Meelis Roos wrote: > Todays git gives the following warning during bootup on a Intel 845+PATA > PC (using libata to drive PATA): > > Driver 'sd' needs updating - please use bus_type methods > Driver 'sr' needs updating - please use bus_type methods They are due to commit 751bf4d7865e4ced406be93b04c7436d866d3684, AFAICS, and they don't mean anything wrong. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8187 rate control doesn't work
On Sat, 12 Jan 2008 19:23:53 +0100 Hauke Mehrtens <[EMAIL PROTECTED]> wrote: > I have tried wireless-2.6 and I have the same problem. If the rate goes > over 11M no TCP/IP traffic goes through the wireless connecting. If rate > is set to auto and the rate control algorithm changes it to something > less than 11M TCP/IP traffic goes through, but if it is more than 11M no > TCP/IP traffic goes through the wireless link. And this is a problem if the rate control algorithm often sets the rate to more than 11M even if connection is unreliable at that rate. Does this actually happen? Are you currently using 'pid'? Also, it would be fine to have a dump of the PID events. In order to get this, you need to: - build a kernel with debugfs enabled; - mount debugfs (mount -t debugfs foo /mnt/debug) Then, before testing: cat /mnt/debug/ieee80211/phy0/stations/*/rc_pid_events > events_dump You can even make a graph out of that, with a python script which Mattias posted on this list some time ago, but a dump would be just fine. -- Ciao Stefano -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
nosmp/maxcpus=0 or 1 -> TSC unstable
if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it still disables TSC :) Marking TSC unstable due to TSCs unsynchronized this is an opteron 2xx box which does have two cpus and no clock-divide in halt or cpufreq enabled so TSC should be fine with only one cpu. pretty sure this is the culprit is that num_possible_cpus() > 1, which would mean cpu_possible_map contains the second cpu... but i'm not quite sure what the right fix is... or perhaps this is all intended. -dean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Only print SCSI data direction warning once for a command
On Wed, 2008-01-02 at 07:03 +0100, Andi Kleen wrote: > 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. My reaction is that the intent of these warnings is to try to get people to fix broken applications, so I'm not sure any action is appropriate; however, it's Doug's driver, so I'll defer to him. Even if he does say yes, though, your patch looks wrong. It's still going to spew the printk: 1078 messages suppressed. to the log because they come from printk_ratelimit(). So all you've done is halved the volume of flow to the logs and left a dangling printk suppressed message that keeps spewing, so I don't think the patch even does what you describe it as doing ... if you reverse the order of the operands in the if() it will ... 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/
