Re: [x86] is checkpatch.pl broken
[H. Peter Anvin - Sun, Dec 30, 2007 at 12:27:15PM -0800] > Cyrill Gorcunov wrote: >> >> Thanks Ingo, you're quite right! Next time i'll appear in list with real >> (and hope usefull) patch ;) >> > > Wonderful! I also *really* have to apologize for my short fuse earlier, it > was uncalled for. > > -hpa > ok ;) but any comment is *worth* for me. Thanks. - Cyrill - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] qgit-2.1 and qgit-1.5.8
Hi all, new versions of Qt4 based qgit-2.1 and stable Qt3 based qgit-1.5.8 have been released. Download tarballs from http://sourceforge.net/project/showfiles.php?group_id=139897 Or directly from git repositories git://git.kernel.org/pub/scm/qgit/qgit.git (qgit-1.5.8) git://git.kernel.org/pub/scm/qgit/qgit4.git (qgit-2.1) Stable qgit-1.5.8 has only maintenance fixes, not a lot indeed, it happens to be already very stable. New stuff is in qgit-2.1, you can find a detailed changelog at http://git.kernel.org/?p=qgit/qgit.git;a=shortlog After popular request, this time I have packaged qgit-2.1 in a nice Windows installer (Inno Setup based) downloadable from the above sourceforge link, so that our Window's friends can try qgit without worrying about compilers, Qt libraries and other geeky things ;-) Window installer will ask you to locate the msysgit directory. Indeed msysgit is the only supported git distribution under Windows, because Cygwin has some issues and is also muuuch slower. So the only prerequisite is to have already installed msysgit (http://code.google.com/p/msysgit/) Happy new year 2008 ! Marco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RAID timeout parameter accessibility request
on 12/31/2007 12:42 AM Jose de la Mancha wrote the following: > > Of course there are "RAID edition" hard drives with a feature called TLER > (Time Limited Error Recovery) which stops the hard drive from entering into > a deep recovery cycle. The hard drive will only spend 7 seconds to attempt > to recover. This means that the hard drive will not be dropped from a RAID > array. But these "special" hard drives are way too expensive IMHO just for a > small firmware-based feature. WD 2500YS price same as an IDE or SATA -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Get physical MAC address
Hello, I get MAC address from ioctl. However, ifconfig can change this MAC address. Can I get a real physical MAC address of the NIC? Thanks, Theewara -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
This patch converts the tracing mechanism of Preempt RCU boosting into
markers. The handler functions for these markers are included inside
rcupreempt_trace.c and will be included only when PREEMPT_RCU_BOOST is
chosen.
Signed-off-by: K.Prasad <[EMAIL PROTECTED]>
---
include/linux/rcupreempt_trace.h | 46
kernel/rcupreempt-boost.c| 211 ---
kernel/rcupreempt_trace.c| 183 +
3 files changed, 251 insertions(+), 189 deletions(-)
Index: linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW/include/linux/rcupreempt_trace.h
===
---
linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW.orig/include/linux/rcupreempt_trace.h
+++ linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW/include/linux/rcupreempt_trace.h
@@ -102,5 +102,51 @@ extern int rcupreempt_flip_flag(int cpu)
extern int rcupreempt_mb_flag(int cpu);
extern char *rcupreempt_try_flip_state_name(void);
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+struct preempt_rcu_boost_trace {
+ unsigned long rbs_stat_task_boost_called;
+ unsigned long rbs_stat_task_boosted;
+ unsigned long rbs_stat_boost_called;
+ unsigned long rbs_stat_try_boost;
+ unsigned long rbs_stat_boosted;
+ unsigned long rbs_stat_unboost_called;
+ unsigned long rbs_stat_unboosted;
+ unsigned long rbs_stat_try_boost_readers;
+ unsigned long rbs_stat_boost_readers;
+ unsigned long rbs_stat_try_unboost_readers;
+ unsigned long rbs_stat_unboost_readers;
+ unsigned long rbs_stat_over_taken;
+};
+
+#define DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(preempt_rcu_boost_var) \
+void preempt_rcu_boost_var##_callback(const struct marker *mdata, \
+ void *private_data, const char *format, ...) \
+{ \
+ va_list ap; \
+ int cpu; \
+ struct preempt_rcu_boost_trace *boost_trace; \
+ va_start(ap, format); \
+ cpu = va_arg(ap, typeof(unsigned int)); \
+ boost_trace = (_cpu(boost_trace_data, cpu)); \
+ boost_trace->rbs_stat_##preempt_rcu_boost_var++; \
+ va_end(ap); \
+}
+
+struct preempt_rcu_boost_probe {
+ const char *name;
+ const char *format;
+ marker_probe_func *probe_func;
+};
+
+#define INIT_PREEMPT_RCU_BOOST_PROBE(preempt_rcu_boost_probe_worker) \
+{ \
+ .name = __stringify(preempt_rcu_boost_probe_worker), \
+ .format = "%u", \
+ .probe_func = preempt_rcu_boost_probe_worker##_callback \
+}
+
+extern int read_rcu_boost_prio(void);
+#endif /* CONFIG_PREEMPT_RCU_BOOST */
+
#endif /* __KERNEL__ */
#endif /* __LINUX_RCUPREEMPT_TRACE_H */
Index: linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW/kernel/rcupreempt_trace.c
===
--- linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW.orig/kernel/rcupreempt_trace.c
+++ linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW/kernel/rcupreempt_trace.c
@@ -51,6 +51,163 @@ static char *rcupreempt_trace_buf;
static DEFINE_PER_CPU(struct rcupreempt_trace, trace_data);
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+#define RCUPREEMPT_BOOST_TRACE_BUF_SIZE 4096
+static char rcupreempt_boost_trace_buf[RCUPREEMPT_BOOST_TRACE_BUF_SIZE];
+static DEFINE_PER_CPU(struct preempt_rcu_boost_trace, boost_trace_data);
+
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(task_boost_called);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(task_boosted);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(boost_called);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(try_boost);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(boosted);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(unboost_called);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(unboosted);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(try_boost_readers);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(boost_readers);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(try_unboost_readers);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(unboost_readers);
+DEFINE_PREEMPT_RCU_BOOST_MARKER_HANDLER(over_taken);
+
+static struct preempt_rcu_boost_probe preempt_rcu_boost_probe_array[] =
+{
+ INIT_PREEMPT_RCU_BOOST_PROBE(task_boost_called),
+ INIT_PREEMPT_RCU_BOOST_PROBE(task_boosted),
+ INIT_PREEMPT_RCU_BOOST_PROBE(boost_called),
+ INIT_PREEMPT_RCU_BOOST_PROBE(try_boost),
+ INIT_PREEMPT_RCU_BOOST_PROBE(boosted),
+ INIT_PREEMPT_RCU_BOOST_PROBE(unboost_called),
+ INIT_PREEMPT_RCU_BOOST_PROBE(unboosted),
+ INIT_PREEMPT_RCU_BOOST_PROBE(try_boost_readers),
+ INIT_PREEMPT_RCU_BOOST_PROBE(boost_readers),
+ INIT_PREEMPT_RCU_BOOST_PROBE(try_unboost_readers),
+ INIT_PREEMPT_RCU_BOOST_PROBE(unboost_readers),
+ INIT_PREEMPT_RCU_BOOST_PROBE(over_taken)
+};
+
+static ssize_t rcuboost_read(struct file *filp, char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+ static DEFINE_MUTEX(mutex);
+ int cnt = 0;
+ int cpu;
+ struct preempt_rcu_boost_trace *prbt;
+ ssize_t bcount;
+
[PATCH 1/2] Markers Implementation for RCU Preempt Tracing
This patch converts Preempt RCU Tracing code infrastructure to implement
markers.
- The rcupreempt_trace structure has been moved to the tracing
infrastructure and de-linked from the rcupreempt.c code. A per-cpu
instance of rcupreempt_trace structure will be maintained in
rcupreempt_trace.c
- The above change also renders a few macro definitions unused (such as
RCU_TRACE_CPU, RCU_TRACE_ME and RCU_TRACE_RDP) which have been
removed.
- Some of the helper functions in rcupreempt.c which were exported only
when CONFIG_RCU_TRACE was set are now exported unconditionally. These
functions operate on per-cpu variables that are used both by the RCU
and RCU Tracing code. The changes help in making RCU Tracing code
operate as a kernel module also.
- The references to rcupreempt-boost tracing in the module
initialisation and cleanup have been removed here to enable kernel
build, but will be brought in after enclosing them inside a #ifdef
CONFIG_PREEMPT_RCU_BOOST.
Signed-off-by: K.Prasad <[EMAIL PROTECTED]>
---
include/linux/rcupreempt.h | 10
include/linux/rcupreempt_trace.h | 56 +---
kernel/Kconfig.preempt |7 +--
kernel/rcupreempt.c | 90 +--
kernel/rcupreempt_trace.c| 79 --
5 files changed, 140 insertions(+), 102 deletions(-)
Index: linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW/include/linux/rcupreempt.h
===
--- linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW.orig/include/linux/rcupreempt.h
+++ linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW/include/linux/rcupreempt.h
@@ -96,16 +96,6 @@ extern int rcu_pending_rt(int cpu);
struct softirq_action;
extern void rcu_process_callbacks_rt(struct softirq_action *unused);
-#ifdef CONFIG_RCU_TRACE
-struct rcupreempt_trace;
-extern int *rcupreempt_flipctr(int cpu);
-extern long rcupreempt_data_completed(void);
-extern int rcupreempt_flip_flag(int cpu);
-extern int rcupreempt_mb_flag(int cpu);
-extern char *rcupreempt_try_flip_state_name(void);
-extern struct rcupreempt_trace *rcupreempt_trace_cpu(int cpu);
-#endif
-
struct softirq_action;
#ifdef CONFIG_NO_HZ
Index: linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW/include/linux/rcupreempt_trace.h
===
---
linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW.orig/include/linux/rcupreempt_trace.h
+++ linux-2.6.24-rc2-rt1.MARKER_PATCHES_NEW/include/linux/rcupreempt_trace.h
@@ -69,32 +69,38 @@ struct rcupreempt_trace {
longrcu_try_flip_m2;
};
-#ifdef CONFIG_RCU_TRACE
-#define RCU_TRACE(fn, arg) fn(arg);
-#else
-#define RCU_TRACE(fn, arg)
-#endif
+struct rcupreempt_probe_data {
+ const char *name;
+ const char *format;
+ marker_probe_func *probe_func;
+};
+
+#define DEFINE_RCUPREEMPT_MARKER_HANDLER(rcupreempt_trace_worker) \
+void rcupreempt_trace_worker##_callback(const struct marker *mdata, \
+ void *private_data, const char *format, ...) \
+{ \
+ va_list ap; \
+ int cpu; \
+ struct rcupreempt_trace *trace; \
+ va_start(ap, format); \
+ cpu = va_arg(ap, typeof(unsigned int)); \
+ trace = (_cpu(trace_data, cpu)); \
+ rcupreempt_trace_worker(trace); \
+ va_end(ap); \
+}
+
+#define INIT_RCUPREEMPT_PROBE(rcupreempt_trace_worker, format_specifier) \
+{ \
+ .name = __stringify(rcupreempt_trace_worker), \
+ .format = __stringify(format_specifier), \
+ .probe_func = rcupreempt_trace_worker##_callback \
+}
-extern void rcupreempt_trace_move2done(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_move2wait(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_e1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_i1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_ie1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_g1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_a1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_ae1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_a2(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_z1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_ze1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_z2(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_m1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_me1(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_try_flip_m2(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_check_callbacks(struct rcupreempt_trace *trace);
-extern void rcupreempt_trace_done_remove(struct rcupreempt_trace
[PATCH 0/2] Markers Implementation for RCU Tracing
Hi Ingo, Please accept these patches into the rt tree which convert the existing RCU tracing mechanism for Preempt RCU and RCU Boost into markers. These patches are based upon the 2.6.24-rc5-rt1 kernel tree. Along with marker transition, the RCU Tracing infrastructure has also been modularised to be built as a kernel module, thereby enabling runtime changes to the RCU Tracing infrastructure. Patch [1/2] - Patch that converts the Preempt RCU tracing in rcupreempt.c into markers. Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in rcupreempt-boost.c into markers. Thanks, K.Prasad ([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: asm-x86/msr.h for sanitized headers: clean it or punt it
Mike Frysinger wrote: The current asm-x86/msr.h does not actually define anything for (!__KERNEL__ && __i386__). For x86_64, it fails to build due to u32/u64 types being used. Simply not installing the header seems easiest to me. Otherwise, x86_64 will need sanitizing and i386 should have things added back, otherwise it's just a pointless empty header. Signed-Off-By: Mike Frysinger <[EMAIL PROTECTED]> is usable from userspace, includes it for backwards compatibility. Nothing else is wanted or needed. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
asm-x86/msr.h for sanitized headers: clean it or punt it
The current asm-x86/msr.h does not actually define anything for (!__KERNEL__ && __i386__). For x86_64, it fails to build due to u32/u64 types being used. Simply not installing the header seems easiest to me. Otherwise, x86_64 will need sanitizing and i386 should have things added back, otherwise it's just a pointless empty header. Signed-Off-By: Mike Frysinger <[EMAIL PROTECTED]> --- diff --git a/include/asm-x86/Kbuild b/include/asm-x86/Kbuild index 12db5a1..6453804 100644 --- a/include/asm-x86/Kbuild +++ b/include/asm-x86/Kbuild @@ -4,7 +4,6 @@ header-y += boot.h header-y += bootparam.h header-y += debugreg.h header-y += ldt.h -header-y += msr-index.h header-y += prctl.h header-y += ptrace-abi.h header-y += sigcontext32.h @@ -14,7 +13,6 @@ header-y += vsyscall32.h unifdef-y += e820.h unifdef-y += ist.h unifdef-y += mce.h -unifdef-y += msr.h unifdef-y += mtrr.h unifdef-y += page_32.h unifdef-y += page_64.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: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
On Sun, Dec 30, 2007 at 03:34:45PM -0500, Alan Stern wrote:
> On Sun, 30 Dec 2007, Ingo Molnar wrote:
>
> > * Andreas Mohr <[EMAIL PROTECTED]> wrote:
> >
> > > (yes, that's all there is, despite CONFIG_USB_DEBUG being set)
> > >
> > > The LED of a usb stick isn't active either, for obvious reasons.
> > >
> > > And keep in mind that this is a (relatively old) OHCI-only machine...
> > > (which had the 2.6.19 lsmod showing ohci-hcd just fine and working
> > > fine with WLAN USB)
> > >
> > > Now pondering whether to try -rc6 proper or whether to revert specific
> > > guilty-looking USB changes... And wondering how to properly elevate
> > > this issue (prompt Greg about it, new thread, bug #, ...?)
>
> It looks like Greg misused the debugfs API -- which is ironic, because
> he wrote debugfs in the first place! :-)
Oh crap, sorry, I did mess that up :(
> Let me know if this patch fixes the problem. If it does, I'll submit
> it to Greg with all the proper accoutrements.
This isn't going to work if CONFIG_DEBUGFS is not enabled either :(
> Index: 2.6.24-rc6-mm1/drivers/usb/host/ohci-hcd.c
> ===
> --- 2.6.24-rc6-mm1.orig/drivers/usb/host/ohci-hcd.c
> +++ 2.6.24-rc6-mm1/drivers/usb/host/ohci-hcd.c
> @@ -1067,14 +1067,8 @@ static int __init ohci_hcd_mod_init(void
>
> #ifdef DEBUG
> ohci_debug_root = debugfs_create_dir("ohci", NULL);
> - if (!ohci_debug_root || IS_ERR(ohci_debug_root)) {
> - if (!ohci_debug_root)
> - retval = -ENOENT;
> - else
> - retval = PTR_ERR(ohci_debug_root);
> -
> - goto error_debug;
> - }
> + if (!ohci_debug_root)
> + return -ENOENT;
It needs to check for ERR_PTR(-ENODEV) which is the return value if
debugfs is not enabled, and if so, just ignore things.
If NULL is returned, or anything else, it's a real error.
So, try something like:
if (!ohci_debug_root) {
retval = -ENOENT;
goto error_debug;
}
if (IS_ERR(ohci_debug_root) && PTR_ERR(ohci_debug_root) != -ENODEV) {
retval = PTR_ERR(ohci_debug_root);
goto error_debug;
}
and let me know of that works for you.
Although the combination of CONFIG_USB_DEBUG and not CONFIG_DEBUGFS is
strange, we could just enable CONFIG_DEBUGFS is USB_DEBUG is enabled and
then simplify this logic a bunch at the same time.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SH/Dreamcast - add support for GD-Rom device
On Sun, Dec 30, 2007 at 01:38:24PM +, Adrian McMenamin wrote: > On Thu, 2007-12-27 at 14:58 -0800, Joe Perches wrote: > > On Thu, 2007-12-27 at 16:52 +, Adrian McMenamin wrote: > > > This patch adds support for the CD-Rom drive on the SEGA Dreamcast. > > > > Because it was already so close, might as well make it checkpatch clean. > > > > I also added a function gdrom_is_busy() to make a couple of tests > > fit on a single line and perhaps easier to read. > > > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > > Not really for me to decide if this gets applied - I'll leave that to > Paul as the maintainer. But I have no objection to them :) Both patches are fine with me, but it is ultimately Jens (as the drivers/cdrom authority) that will have to decide whether to sign off on the GDROM patches or not, and through which tree the patches will end up being merged. I can certainly merge them through my tree with his Acked-by if that's deemed the most convenient. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Carlos Corbacho <[EMAIL PROTECTED]> wrote: > > So do we require changes to the userspace udev rules here, or just some use > of > modalias in the drivers? > It was handled by whoever manages the distro's udev rules until now. Here's the example: https://lists.ubuntu.com/archives/ubuntu-patches/2007-September/012537.html Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [05/06] [typo fix] Documentation/scsi/ChangeLog.lpfc
On Sun, 30 Dec 2007 14:20:20 +0100 Oliver Pinter (Pintér Olivér) wrote: > -- [patch is attachment] Please send SCSI patches to [EMAIL PROTECTED] and cc the appropriate (LPFC) maintainer, as listed in the MAINTAINERS file. --- ~Randy desserts: http://www.xenotime.net/linux/recipes/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Kernel Hacker's guide to git
On Dec 23 2007 06:13, Jeff Garzik wrote: > Another year, another update! :) > > The kernel hacker's guide to git has received some updates: > > http://linux.yyz.us/git-howto.html > It says """Don't forget to download tags from time to time. git pull only downloads sha1-indexed object data, and the requested remote head. This misses updates to the .git/refs/tags/ and .git/refs/heads/ directories. For tags, run git fetch --tags $URL.""" But when I do git pull on a simple tracking tree (e.g. git-clone torvalds/linux-2.6.git; git pull;) it automatically grabs new tags. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: numa_default_policy()
"Yinghai Lu" <[EMAIL PROTECTED]> writes: > it seems in numa_default_policy() > > are called two times: > > one is in rest_init(), and another is init_post() > > another reason for that? They run in different threads. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)
> As far as I can see, the kernel doesn't behave as it would be, IMO, > normal. I do have HPETs and Linux detects them without any > need for hpet=force (HPET is registered for clockevents), but keeps > LAPIC as the only option for dynticks. It looks like timing devices are > rated and then only one of them is selected for dynticks. But when that LAPIC is preferred because it is cheaper to reprogram, but if LAPIC doesn't work (e.g. due to AMD C1E) it should fall back to HPET. > Linux does not fallback to the next best timer, as dynticks is provided > with only one such device, hence the message "lapic is not functional" > is shown. In fact, this selection process should be fixed. Yes it should. Something must be indeed wrong. > approach wasn't correct, but please tell me: is HPET-driven dynticks > code working? (I'm quite confused, as HPET should wake the CPUs even AFAIK it should work, but I haven't tested it myself. Thomas G. should know details. > With my patch (the one that disables C1E), powertop shows at most 10-11 > wakeups per second when idle (no X server running). Isn't it > reasonable to expect a significant improvement over HZ=100? Did you measure the actual power? Minimal wakeups is not the ultimate goal, the ultimate goal is to save power. Minimal wakeups is just a measure to that -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/
numa_default_policy()
it seems in numa_default_policy() are called two times: one is in rest_init(), and another is init_post() another reason for that? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
David P. Reed wrote: H. Peter Anvin wrote: Now, I think there is a specific reason to believe that EGA/VGA (but perhaps not CGA/MDA) didn't need these kinds of hacks: the video cards of the day was touched, directly, by an interminable number of DOS applications. CGA/MDA generally *were not*, due to the unsynchronized memory of the original versions (writing could cause snow), so most applications tended to fall back to using the BIOS access methods for CGA and MDA. A little history... not that it really matters, but some might be interested in a 55-year-old hacker's sentimental recollections...As someone who actually wrote drivers for CGA and MDA on the original IBM PC, I can tell you that back to back I/O *port* writes and reads were perfectly fine. The "snow" problem had nothing to do with I/O ports. It had to do with the memory on the CGA adapter card not being dual ported, and in high-res (80x25) character mode (only!) a CPU read or write access caused a read of the adapter memory by the character-generator to fail, causing one character-position of the current scanline being output to get all random bits, which was then put through the character-generator and generated whatever the character generator did with 8 random bits of character or attributes as an index into the character generator's font table. [Additional history snipped] This is all true of course (and a useful history lesson to those not familiar with it) but what I wrote above is still true: due to the lack of synchronized memory (it doesn't have to be dual-ported, just synchronized, if it has enough bandwidth), most DOS applications *in the i386+ timeframe* just invoked the BIOS rather than dealing with the synchronization needs themselves (anything compiled with a Borland compiler using their conio library, for example.) Hence the variety of software that poked directly at CGA/MDA as opposed to EGA/VGA was smaller, but I never claimed it was uncommon. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] USB driver for talking to the Microchip PIC18 boot loader
On Dec 30, 2007 12:46 PM, Xiaofan Chen <[EMAIL PROTECTED]> wrote: > If you do not like the existing fsusb application, you can rewrite > it in python with pyusb (which is based on libusb) but you do not > need a kernel driver. > > pyusb: http://pyusb.berlios.de/ > > Hex file parsing in pyk by Mark Rages. He is using the Bitpim > libusb wrapper which IMHO is not as good as pyusb. > http://groups.google.com/group/pickit-devel/msg/35e850832256e890 The pyk code is for PICkit 2 and include the PICKit 2 bootloader. it is an HID device so it is different from PICDEM FS-USB but you might be able to reuse part of the codes. By the way, there is another perl based code for the bootloader. Just in case you are interested. Again I do not know perl and I am not so sure if it is good enough for you. http://www.nabble.com/HID-keyboard-code-for-gpasm-and-the-fs-picdem-board-td860144.html http://www.nabble.com/attachment/878980/0/picdem.pl.bz2 Thinking about it, if the Linux USB maintainers agree to include your driver, I have no objections. It should not affect the existing libusb based applications and the users have one more choices. Xiaofan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 01:01:08 Alex Dubov wrote: > This is exactly the same as with tifm_sd module if you noticed. Unfortunately not, I've really never used tifm_sd as I don't have any MMC/ SD cards. > Second, it is impossible to guess in advance, which type of card is put > into slot (Pro, legacy or IO of either sort). I imagined this to be the case. > Same as mmc_block, actually. > The only way to get it autoloaded, is, again, with appropriate udev rule > (uevent is emitted when card type is detected). So do we require changes to the userspace udev rules here, or just some use of modalias in the drivers? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Dec 30, 2007 4:28 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote: > > On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote: > > > > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote: > > > > > > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > please check if you can replace the one in the x86-mm > > > > > > > > > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > > > > > > > > > > > > > > > > the updated one avoid one link warning. > > > > > > > > > > > > > > please send delta patches instead - so that we can review the > > > > > > > changes. > > > > > > > > > > > > will do that in another patch. > > > > > > > > > > > > > > > > > > > > > this is the updated verison that take enable_IO_APIC as extra > > > > > > > > call for > > > > > > > > setup_local_APIC to avoid linking warning. > > > > > > > > > > > > > > hm, what link warning did you get? Perhaps the following > > > > > > > __cpuinit: > > > > > > > > > > > > WARNING: vmlinux.o(.text+0x163d5): Section mismatch: reference to > > > > > > .init.text:enable_IO_APIC (between 'setup_local_APIC' and > > > > > > 'apic_is_clustered_box') > > > > > > > > > > So you are doing complicated things for silencing the warning (there > > > > > is > > > > > an easier ways for achieving it), but the real bug that you will get > > > > > an > > > > > Oops when calling enable_IO_APIC() after bootup since it already got > > > > > freed stays? > > > > > > > > the enable_IO_APIC is actually doing clear_IO_APIC. and it is only > > > > called by BSP via setup_local_APIC > > > > and it is not called again after bootup > > > > > > OK, this was a bit hidden inside your pointer games. > > > > > > Please send a patch that ignores the warning (and therefore doesn't do > > > these pointer games), and I'll fix the warning in a followup patch. > > > > the old one is in x86-mm tree > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > >... > > Sorry for the dumb question, but what in > > + if (!smp_processor_id() && !skip_ioapic_setup && nr_ioapics) > + enable_IO_APIC(); > > guarantees that this call doesn't happen when you hotplug CPU 0 ? > if CPU 0 (BSP) can be hotplug, it will be restarted via smp_callin. and the delta function call patch will use setup_local_APIC(NULL), then it will be safe. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
H. Peter Anvin wrote: Now, I think there is a specific reason to believe that EGA/VGA (but perhaps not CGA/MDA) didn't need these kinds of hacks: the video cards of the day was touched, directly, by an interminable number of DOS applications. CGA/MDA generally *were not*, due to the unsynchronized memory of the original versions (writing could cause snow), so most applications tended to fall back to using the BIOS access methods for CGA and MDA. A little history... not that it really matters, but some might be interested in a 55-year-old hacker's sentimental recollections...As someone who actually wrote drivers for CGA and MDA on the original IBM PC, I can tell you that back to back I/O *port* writes and reads were perfectly fine. The "snow" problem had nothing to do with I/O ports. It had to do with the memory on the CGA adapter card not being dual ported, and in high-res (80x25) character mode (only!) a CPU read or write access caused a read of the adapter memory by the character-generator to fail, causing one character-position of the current scanline being output to get all random bits, which was then put through the character-generator and generated whatever the character generator did with 8 random bits of character or attributes as an index into the character generator's font table. In particular, the solution in both the BIOS and in Visicalc, 1-2-3, and other products that did NOT use the BIOS or DOS for I/O to the CGA or MDA because they were Dog Slow, was to detect the CGA, and do a *very* tight loop doing "inb" instructions from one of the CGA status registers, looking for a 0-1 transition on the horizontal retrace flag. It would then do a write to display memory with all interrupts locked out, because that was all it could do during the horizontal retrace, given the speed of the processor. One of the hacks I did in those days (I wrote the CGA driver for Visicalc Advanced Version and several other Software Arts programs, some of which were sold to Lotus when they bought our assets, and hired me, in 1985) was to measure the "horizontal retrace time" and the "vertical blanking interval" when the program started, and compile screen-writing code that squeezed as many writes as possible into both horizontal retraces and vertical retraces. That was actually a "selling point" for spreadsheets - the reviewers actually measured whether you could use the down-arrow key in auto-repeat mode and keep the screen scrolling at the relevant rate! That was hard on an 8088 or 80286 processor, with a CGA card. It was great when EGA and VGA came out, but we still had to support the CGA long after. Which is why I fully understand the need not to break old machines. We had to run on every machine that was claimed to be "PC compatible" - many of which were hardly so compatible (the PS/2 model 50 had a completely erroneous serial chip that claimed to emulate the original 8250, but had an immense pile of bugs, for example, that IBM begged ISVs to call a software problem and fix so they didn't get sued). The IBM PC bus (predecessor of the current ISA bus, which came from the PC-AT's 16-bit bus), did just fine electrically - any I/O port-specific timing problems had to do with the timing of the chips attached to the bus. For example, if a bus write to a port was routed into a particular chip, the timing of that chip's subsequent processing might be such that it was not ready to respond to another read or write.) That's not a "signalling" problem - it has nothing to do with capacitance on the bus, e.g., but a functional speed problem in the chip (if on the motherboard) or the adapter card. Rant off. This has nothing, of course, to do with present 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: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Dec 31 2007 00:01, Carlos Corbacho wrote: > >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: > >> From: Alex Dubov <[EMAIL PROTECTED]> > >> > >> Sony MemoryStick cards are used in many products manufactured by Sony. They > >> are available both as storage and as IO expansion cards. Currently, only > >> MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > >> interface. > > Actually... my MS slot on PCG-U3 is recognized through usb_storage. > USB storage type controllers have firmware that translates native MS protocol into USB storage (scsi-like) one. We are talking here about native protocol support, needed for dumb controllers. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [MEMSTICK] Initial commit for Sony MemoryStick support
> However, my only concerns are that: > > 1) tifm_ms was not autoloaded > 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not. > > Although, whether this is an issue with userspace (ie. udev) not dealing with > the modules properly, I don't know. > This is exactly the same as with tifm_sd module if you noticed. First, there are no modaliases for tifm (I was thinking to add them later, when at least two card types are supported, if at all), so the appropriate udev rule should be added (similar to the sd one). Second, it is impossible to guess in advance, which type of card is put into slot (Pro, legacy or IO of either sort). Same as mmc_block, actually. The only way to get it autoloaded, is, again, with appropriate udev rule (uevent is emitted when card type is detected). Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 00:31:12 Jan Engelhardt wrote: > On Dec 31 2007 00:01, Carlos Corbacho wrote: > >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: > >> From: Alex Dubov <[EMAIL PROTECTED]> > >> > >> Sony MemoryStick cards are used in many products manufactured by Sony. > >> They are available both as storage and as IO expansion cards. Currently, > >> only MemoryStick Pro storage cards are supported via TI FlashMedia > >> MemoryStick interface. > > Actually... my MS slot on PCG-U3 is recognized through usb_storage. Then consider yourself very lucky - some laptop manufacturers play nice and the card reader identifies itself, and works as, a USB mass storage device; so it works out of the box with no extra drivers needed for either the card reader, or the flash memory card. The Texas Instruments chip/ card reader that Alex's work here is currently aimed at does not - it has a completely proprietary, so called "FlashMedia" chip/ interface that talks to MMC/ SD, MemoryStick (/ Pro), and SmartMedia/ xD cards, of which TI have refused to release any specs. Yes, this chip doesn't even use sdhci for communicating with MMC/ SD cards - tifm_sd (Alex's previous work on the MMC/ SD front for this TI chip) handles that. MemoryStick support is more complicated in this case than MMC/ SD, given that on top of TI refusing to release specs for their own FlashMedia chips, Sony will also not release any specs on MemoryStick cards; the same is also true of xD with Olympus and Fuji. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Dec 30, 2007 4:28 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote: > > On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote: > > > > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote: > > > > > > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > please check if you can replace the one in the x86-mm > > > > > > > > > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > > > > > > > > > > > > > > > > the updated one avoid one link warning. > > > > > > > > > > > > > > please send delta patches instead - so that we can review the > > > > > > > changes. > > > > > > > > > > > > will do that in another patch. > > > > > > > > > > > > > > > > > > > > > this is the updated verison that take enable_IO_APIC as extra > > > > > > > > call for > > > > > > > > setup_local_APIC to avoid linking warning. > > > > > > > > > > > > > > hm, what link warning did you get? Perhaps the following > > > > > > > __cpuinit: > > > > > > > > > > > > WARNING: vmlinux.o(.text+0x163d5): Section mismatch: reference to > > > > > > .init.text:enable_IO_APIC (between 'setup_local_APIC' and > > > > > > 'apic_is_clustered_box') > > > > > > > > > > So you are doing complicated things for silencing the warning (there > > > > > is > > > > > an easier ways for achieving it), but the real bug that you will get > > > > > an > > > > > Oops when calling enable_IO_APIC() after bootup since it already got > > > > > freed stays? > > > > > > > > the enable_IO_APIC is actually doing clear_IO_APIC. and it is only > > > > called by BSP via setup_local_APIC > > > > and it is not called again after bootup > > > > > > OK, this was a bit hidden inside your pointer games. > > > > > > Please send a patch that ignores the warning (and therefore doesn't do > > > these pointer games), and I'll fix the warning in a followup patch. > > > > the old one is in x86-mm tree > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > >... > > Sorry for the dumb question, but what in > > + if (!smp_processor_id() && !skip_ioapic_setup && nr_ioapics) > + enable_IO_APIC(); > > guarantees that this call doesn't happen when you hotplug CPU 0 ? so we can hotplug cpu0 or the bsp? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 1/3] sched: high-res preemption tick
Use HR-timers (when available) to deliver an accurate preemption tick.
The regular scheduler tick that runs at 1/HZ can be too coarse when nice
level are used. The fairness system will still keep the cpu utilisation 'fair'
by then delaying the task that got an excessive amount of CPU time but try to
minimize this by delivering preemption points spot-on.
The average frequency of this extra interrupt is sched_latency / nr_latency.
Which need not be higher than 1/HZ, its just that the distribution within the
sched_latency period is important.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
arch/x86/kernel/entry_64.S |6 -
arch/x86/kernel/signal_32.c |3
arch/x86/kernel/signal_64.c |3
include/asm-x86/thread_info_32.h |2
include/asm-x86/thread_info_64.h |5
include/linux/hrtimer.h |9 +
include/linux/sched.h|3
kernel/Kconfig.hz|2
kernel/sched.c | 210 ---
kernel/sched_fair.c | 69
kernel/sched_idletask.c |2
kernel/sched_rt.c|2
12 files changed, 295 insertions(+), 21 deletions(-)
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -65,6 +65,7 @@
#include
#include
#include
+#include
#include
#include
@@ -451,6 +452,12 @@ struct rq {
struct list_head migration_queue;
#endif
+#ifdef CONFIG_SCHED_HRTICK
+ unsigned long hrtick_flags;
+ ktime_t hrtick_expire;
+ struct hrtimer hrtick_timer;
+#endif
+
#ifdef CONFIG_SCHEDSTATS
/* latency stats */
struct sched_info rq_sched_info;
@@ -572,6 +579,8 @@ enum {
SCHED_FEAT_START_DEBIT = 4,
SCHED_FEAT_TREE_AVG = 8,
SCHED_FEAT_APPROX_AVG = 16,
+ SCHED_FEAT_HRTICK = 32,
+ SCHED_FEAT_DOUBLE_TICK = 64,
};
const_debug unsigned int sysctl_sched_features =
@@ -579,7 +588,9 @@ const_debug unsigned int sysctl_sched_fe
SCHED_FEAT_WAKEUP_PREEMPT * 1 |
SCHED_FEAT_START_DEBIT * 1 |
SCHED_FEAT_TREE_AVG * 0 |
- SCHED_FEAT_APPROX_AVG * 0;
+ SCHED_FEAT_APPROX_AVG * 0 |
+ SCHED_FEAT_HRTICK * 1 |
+ SCHED_FEAT_DOUBLE_TICK * 0;
#define sched_feat(x) (sysctl_sched_features & SCHED_FEAT_##x)
@@ -796,6 +807,173 @@ void sched_clock_idle_wakeup_event(u64 d
}
EXPORT_SYMBOL_GPL(sched_clock_idle_wakeup_event);
+static void __resched_task(struct task_struct *p, int tif_bit);
+
+static inline void resched_task(struct task_struct *p)
+{
+ __resched_task(p, TIF_NEED_RESCHED);
+}
+
+#ifdef CONFIG_SCHED_HRTICK
+/*
+ * Use HR-timers to deliver accurate preemption points.
+ *
+ * Its all a bit involved since we cannot program an hrt while holding the
+ * rq->lock. So what we do is store a state in in rq->hrtick_* and ask for a
+ * reschedule event.
+ *
+ * When we get rescheduled we reprogram the hrtick_timer outside of the
+ * rq->lock.
+ */
+static inline void resched_hrt(struct task_struct *p)
+{
+ __resched_task(p, TIF_HRTICK_RESCHED);
+}
+
+static inline void resched_rq(struct rq *rq)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ resched_task(rq->curr);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+enum {
+ HRTICK_SET, /* re-programm hrtick_timer */
+ HRTICK_RESET, /* not a new slice */
+};
+
+/*
+ * Use hrtick when:
+ * - enabled by features
+ * - hrtimer is actually high res
+ */
+static inline int hrtick_enabled(struct rq *rq)
+{
+ if (!sched_feat(HRTICK))
+ return 0;
+ return hrtimer_is_hres_active(>hrtick_timer);
+}
+
+/*
+ * Called to set the hrtick timer state.
+ *
+ * called with rq->lock held and irqs disabled
+ */
+static void hrtick_start(struct rq *rq, u64 delay, int reset)
+{
+ assert_spin_locked(>lock);
+
+ /*
+* preempt at: now + delay
+*/
+ rq->hrtick_expire =
+ ktime_add_ns(rq->hrtick_timer.base->get_time(), delay);
+ /*
+* indicate we need to program the timer
+*/
+ __set_bit(HRTICK_SET, >hrtick_flags);
+ if (reset)
+ __set_bit(HRTICK_RESET, >hrtick_flags);
+
+ /*
+* New slices are called from the schedule path and don't need a
+* forced reschedule.
+*/
+ if (reset)
+ resched_hrt(rq->curr);
+}
+
+static void hrtick_clear(struct rq *rq)
+{
+ if (hrtimer_active(>hrtick_timer))
+ hrtimer_cancel(>hrtick_timer);
+}
+
+/*
+ * Update the timer from the possible pending state.
+ */
+static void hrtick_set(struct rq *rq)
+{
+ ktime_t time;
+ int
[RFC/PATCH 3/3] sched: rt group scheduling
Extend group scheduling to also cover the realtime classes. It uses the time
limiting introduced by the previous patch to allow multiple realtime groups.
The hard time limit is required to keep behaviour deterministic.
The algorithms used make the realtime scheduler O(tg), linear scaling wrt the
number of task groups. This is the worst case behaviour I can't seem to get out
of, the avg. case of the algorithms can be improved, I focused on correctness
and worst case.
TODO:
- interface and rt_ratio defaults
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/init_task.h |5
include/linux/sched.h | 10
kernel/fork.c |2
kernel/sched.c| 228 -
kernel/sched_rt.c | 495 ++
5 files changed, 556 insertions(+), 184 deletions(-)
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -963,6 +963,15 @@ struct sched_rt_entity {
struct list_head run_list;
unsigned int time_slice;
unsigned long timeout;
+ int nr_cpus_allowed;
+
+#ifdef CONFIG_FAIR_GROUP_SCHED
+ struct sched_rt_entity *parent;
+ /* rq on which this entity is (to be) queued: */
+ struct rt_rq*rt_rq;
+ /* rq "owned" by this entity/group: */
+ struct rt_rq*my_q;
+#endif
};
struct task_struct {
@@ -1007,7 +1016,6 @@ struct task_struct {
unsigned int policy;
cpumask_t cpus_allowed;
- int nr_cpus_allowed;
#ifdef CONFIG_PREEMPT_RCU
int rcu_read_lock_nesting;
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -171,6 +171,11 @@ struct task_group {
/* runqueue "owned" by this group on each cpu */
struct cfs_rq **cfs_rq;
+ struct sched_rt_entity **rt_se;
+ struct rt_rq **rt_rq;
+
+ unsigned int rt_ratio;
+
/*
* shares assigned to a task group governs how much of cpu bandwidth
* is allocated to the group. The more shares a group has, the more is
@@ -215,9 +220,15 @@ static DEFINE_PER_CPU(struct sched_entit
/* Default task group's cfs_rq on each cpu */
static DEFINE_PER_CPU(struct cfs_rq, init_cfs_rq) cacheline_aligned_in_smp;
+static DEFINE_PER_CPU(struct sched_rt_entity, init_sched_rt_entity);
+static DEFINE_PER_CPU(struct rt_rq, init_rt_rq) cacheline_aligned_in_smp;
+
static struct sched_entity *init_sched_entity_p[NR_CPUS];
static struct cfs_rq *init_cfs_rq_p[NR_CPUS];
+static struct sched_rt_entity *init_sched_rt_entity_p[NR_CPUS];
+static struct rt_rq *init_rt_rq_p[NR_CPUS];
+
/* task_group_mutex serializes add/remove of task groups and also changes to
* a task group's cpu shares.
*/
@@ -240,6 +251,9 @@ static void set_se_shares(struct sched_e
struct task_group init_task_group = {
.se = init_sched_entity_p,
.cfs_rq = init_cfs_rq_p,
+
+ .rt_se = init_sched_rt_entity_p,
+ .rt_rq = init_rt_rq_p,
};
#ifdef CONFIG_FAIR_USER_SCHED
@@ -269,10 +283,13 @@ static inline struct task_group *task_gr
}
/* Change a task's cfs_rq and parent entity if it moves across CPUs/groups */
-static inline void set_task_cfs_rq(struct task_struct *p, unsigned int cpu)
+static inline void set_task_rq(struct task_struct *p, unsigned int cpu)
{
p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
p->se.parent = task_group(p)->se[cpu];
+
+ p->rt.rt_rq = task_group(p)->rt_rq[cpu];
+ p->rt.parent = task_group(p)->rt_se[cpu];
}
static inline void lock_task_group_list(void)
@@ -297,7 +314,7 @@ static inline void unlock_doms_cur(void)
#else
-static inline void set_task_cfs_rq(struct task_struct *p, unsigned int cpu) { }
+static inline void set_task_rq(struct task_struct *p, unsigned int cpu) { }
static inline void lock_task_group_list(void) { }
static inline void unlock_task_group_list(void) { }
static inline void lock_doms_cur(void) { }
@@ -343,13 +360,22 @@ struct cfs_rq {
struct rt_rq {
struct rt_prio_array active;
unsigned long rt_nr_running;
+#if defined CONFIG_SMP || defined CONFIG_FAIR_GROUP_SCHED
+ int highest_prio; /* highest queued rt task prio */
+#endif
#ifdef CONFIG_SMP
unsigned long rt_nr_migratory;
- int highest_prio; /* highest queued rt task prio */
int overloaded;
#endif
u64 rt_time;
u64 rt_throttled;
+
+#ifdef CONFIG_FAIR_GROUP_SCHED
+ struct rq *rq;
+ struct list_head leaf_rt_rq_list;
+ struct task_group *tg;
+ struct sched_rt_entity *rt_se;
+#endif
};
#ifdef CONFIG_SMP
@@ -411,12 +437,14 @@ struct rq {
u64 nr_switches;
struct cfs_rq cfs;
+ struct rt_rq rt;
+ u64 rt_period_expire;
+
#ifdef
[RFC/PATCH 2/3] sched: rt time limit
Very simple time limit on the realtime scheduling classes.
Allow the rq's realtime class to consume sched_rt_ratio of every
sched_rt_period slice. If the class exceeds this quota the fair class
will preempt the realtime class.
TODO:
- rt limit vs load-balance
- proper interface
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/sched.h |2 +
kernel/sched.c| 70 +++---
kernel/sched_rt.c | 53 +
kernel/sysctl.c | 18
4 files changed, 122 insertions(+), 21 deletions(-)
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -1531,6 +1531,8 @@ extern unsigned int sysctl_sched_child_r
extern unsigned int sysctl_sched_features;
extern unsigned int sysctl_sched_migration_cost;
extern unsigned int sysctl_sched_nr_migrate;
+extern unsigned int sysctl_sched_rt_period;
+extern unsigned int sysctl_sched_rt_ratio;
#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
extern unsigned int sysctl_sched_min_bal_int_shares;
extern unsigned int sysctl_sched_max_bal_int_shares;
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -342,13 +342,14 @@ struct cfs_rq {
/* Real-Time classes' related field in a runqueue: */
struct rt_rq {
struct rt_prio_array active;
- int rt_load_balance_idx;
- struct list_head *rt_load_balance_head, *rt_load_balance_curr;
unsigned long rt_nr_running;
+#ifdef CONFIG_SMP
unsigned long rt_nr_migratory;
- /* highest queued rt task prio */
- int highest_prio;
+ int highest_prio; /* highest queued rt task prio */
int overloaded;
+#endif
+ u64 rt_time;
+ u64 rt_throttled;
};
#ifdef CONFIG_SMP
@@ -415,6 +416,7 @@ struct rq {
struct list_head leaf_cfs_rq_list;
#endif
struct rt_rq rt;
+ u64 rt_period_expire;
/*
* This is part of a global counter where only the total sum
@@ -601,6 +603,21 @@ const_debug unsigned int sysctl_sched_fe
const_debug unsigned int sysctl_sched_nr_migrate = 32;
/*
+ * period over which we measure -rt task cpu usage in ms.
+ * default: 1s
+ */
+const_debug unsigned int sysctl_sched_rt_period = 1000;
+
+#define SCHED_RT_FRAC_SHIFT16
+#define SCHED_RT_FRAC (1UL << SCHED_RT_FRAC_SHIFT)
+
+/*
+ * ratio of time -rt tasks may consume.
+ * default: 100%
+ */
+const_debug unsigned int sysctl_sched_rt_ratio = SCHED_RT_FRAC;
+
+/*
* For kernel-internal use: high-speed (but slightly incorrect) per-cpu
* clock constructed from sched_clock():
*/
@@ -3673,8 +3690,8 @@ void scheduler_tick(void)
rq->clock = next_tick;
rq->tick_timestamp = rq->clock;
update_cpu_load(rq);
- if (curr != rq->idle) /* FIXME: needed? */
- curr->sched_class->task_tick(rq, curr, 0);
+ curr->sched_class->task_tick(rq, curr, 0);
+ update_sched_rt_period(rq);
spin_unlock(>lock);
#ifdef CONFIG_SMP
@@ -7029,6 +7046,29 @@ static void init_cfs_rq(struct cfs_rq *c
cfs_rq->min_vruntime = (u64)(-(1LL << 20));
}
+static void init_rt_rq(struct rt_rq *rt_rq, struct rq *rq)
+{
+ struct rt_prio_array *array;
+ int i;
+
+ array = _rq->active;
+ for (i = 0; i < MAX_RT_PRIO; i++) {
+ INIT_LIST_HEAD(array->queue + i);
+ __clear_bit(i, array->bitmap);
+ }
+ /* delimiter for bitsearch: */
+ __set_bit(MAX_RT_PRIO, array->bitmap);
+
+#ifdef CONFIG_SMP
+ rt_rq->rt_nr_migratory = 0;
+ rt_rq->highest_prio = MAX_RT_PRIO;
+ rt_rq->overloaded = 0;
+#endif
+
+ rt_rq->rt_time = 0;
+ rt_rq->rt_throttled = 0;
+}
+
void __init sched_init(void)
{
int highest_cpu = 0;
@@ -7039,7 +7079,6 @@ void __init sched_init(void)
#endif
for_each_possible_cpu(i) {
- struct rt_prio_array *array;
struct rq *rq;
rq = cpu_rq(i);
@@ -7071,6 +7110,8 @@ void __init sched_init(void)
}
init_task_group.shares = init_task_group_load;
#endif
+ init_rt_rq(>rt, rq);
+ rq->rt_period_expire = 0;
for (j = 0; j < CPU_LOAD_IDX_MAX; j++)
rq->cpu_load[j] = 0;
@@ -7083,22 +7124,11 @@ void __init sched_init(void)
rq->cpu = i;
rq->migration_thread = NULL;
INIT_LIST_HEAD(>migration_queue);
- rq->rt.highest_prio = MAX_RT_PRIO;
- rq->rt.overloaded = 0;
rq_attach_root(rq, _root_domain);
#endif
init_rq_hrtick(rq);
-
atomic_set(>nr_iowait, 0);
-
- array = >rt.active;
-
[RFC/PATCH 0/3] sched: hrtick and rt group scheduling
I spend xmas implementing group scheduling for the realtime scheduling classes. Its a tad raw, but seems to work for the trivial test cases I threw at it. The hrtick stuff is unrelated but was still stuck in my sched queue. Patches against .26-rc6-mm1 -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [MEMSTICK] Initial commit for Sony MemoryStick support
On Dec 31 2007 00:01, Carlos Corbacho wrote: >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: >> From: Alex Dubov <[EMAIL PROTECTED]> >> >> Sony MemoryStick cards are used in many products manufactured by Sony. They >> are available both as storage and as IO expansion cards. Currently, only >> MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick >> interface. Actually... my MS slot on PCG-U3 is recognized through usb_storage. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Option to disable AMD C1E (allows dynticks to work)
Richard Harman wrote: I think I may have a monkey wrench to throw into this, I finally got around to testing the C1E patch, and the port80 patch. End result: port80 patch has zero effect on this laptop, and the C1E patch makes it stable. Stating that your system is "stable" is not very definitive. Does hwclock work when full Fedora 8 is running without the port80 patch, or have you disabled the uses of hwclock in your init and shutdown code? Have you set the hwclock setting to use the extremely dangerous "-directisa" option - which hides the problem because it avoids the port 80 i/o? Try compiling and running the test program port80.c a few times. If your machine doesn't hang, it would be interesting to see the results it gives. The C1E patch alone does not fix the port 80 problem several of us have observed. what does dmidecode say for your motherboard vendor and model? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Sun, Dec 30, 2007 at 04:01:39PM -0800, Yinghai Lu wrote: > On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote: > > > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote: > > > > > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > please check if you can replace the one in the x86-mm > > > > > > > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > > > > > > > > > > > > > > the updated one avoid one link warning. > > > > > > > > > > > > please send delta patches instead - so that we can review the > > > > > > changes. > > > > > > > > > > will do that in another patch. > > > > > > > > > > > > > > > > > > this is the updated verison that take enable_IO_APIC as extra > > > > > > > call for > > > > > > > setup_local_APIC to avoid linking warning. > > > > > > > > > > > > hm, what link warning did you get? Perhaps the following __cpuinit: > > > > > > > > > > WARNING: vmlinux.o(.text+0x163d5): Section mismatch: reference to > > > > > .init.text:enable_IO_APIC (between 'setup_local_APIC' and > > > > > 'apic_is_clustered_box') > > > > > > > > So you are doing complicated things for silencing the warning (there is > > > > an easier ways for achieving it), but the real bug that you will get an > > > > Oops when calling enable_IO_APIC() after bootup since it already got > > > > freed stays? > > > > > > the enable_IO_APIC is actually doing clear_IO_APIC. and it is only > > > called by BSP via setup_local_APIC > > > and it is not called again after bootup > > > > OK, this was a bit hidden inside your pointer games. > > > > Please send a patch that ignores the warning (and therefore doesn't do > > these pointer games), and I'll fix the warning in a followup patch. > > the old one is in x86-mm tree > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 >... Sorry for the dumb question, but what in + if (!smp_processor_id() && !skip_ioapic_setup && nr_ioapics) + enable_IO_APIC(); guarantees that this call doesn't happen when you hotplug CPU 0 ? > thanks > > YH cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
David P. Reed wrote: Alan Cox wrote: Now what's interesting is that the outb to port 80 is *faster* than an outb to an unused port, on my machine. So there's something there - actually accepting the bus transaction. In the ancient 5150 PC, 80 was Yes and I even told you a while back how to verify where it is. From the timing you get its not on the LPC bus but chipset core so pretty certainly an SMM trap as other systems with the same chipset don't have the bug. Probably all that is needed is a BIOS upgrade Actually, I could see whether it was SMM trapping due to AMD MSR's that would allow such trapping, performance or debug registers. Nothing was set to trap with SMI or other traps on any port outputs. But I'm continuing to investigate for a cause. It would be nice if it were a BIOS-fixable problem. It would be even nicer if the BIOS were GPL... If it was an SMM trap, I would expect it to be trapped in the SuperIO chip. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LINUX kernel 2.6.23: bug in CIFSSMBSetEA
> In fs/cifs/cifssmb.c, in CIFSSMBSetEA (...) function wrong counting of
> var exists.
>
> EXISTING CODE:
> pSMB->DataCount = sizeof(*parm_data) + ea_value_len + name_len + 1;
>
> MUST BE:
> pSMB->DataCount = sizeof(*parm_data) + ea_value_len + name_len;
>
> REASON:
> "sizeof(*parm_data)" counts 1 byte from "char name[1];"
>
> So, for example in Samba server (sources/smbd/trans2.c), we can see
> wrong processing of EA, cause data sent to server is bigger on 1 byte
> then it must be.
>
> See Extra info for details
>
> - Extra info
>
> struct fealist *parm_data;
>
> 1707 struct fea {
> 1708 unsigned char EA_flags;
> 1709 __u8 name_len;
> 1710 __u16 value_len;
> 1711 char name
[1];
> 1712 /* optionally followed by value */
> 1713 };
> 1714 /* flags for _FEA.fEA */
> 1715 #define FEA_NEEDEA 0x80 /* need EA bit */
> 1716
> 1717 struct fealist {
> 1718 __u32 list_len;
> 1719 struct fea list[1];
> 1720 };
Yes - you are correct (note that Windows is less strict with the extra
pad byte than current Samba, and I don't remember seeing this with
older Samba server versions perhaps the length check ).
I have checked in a fix to the cifs development tree. Thanks.
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Remove unused dependency
On Sun, 2007-12-30 at 23:00 +0100, Sam Ravnborg wrote:
> Can you please remind me what problem you are actually trying to solve here.
> Your current approach it not good - we do not want .c code in include/*
> And what is wrong with the current include path?
It's not a bit deal.
inflate.c is #include'd with different depth "../" prefixes.
Currently, depths 1, 3, 4 and 5 are used.
It seemed neater to take this inflate.c file, which can not
be stand-alone compiled, and move it to somewhere on the
include path so that it may be included via #include
I was originally trying to make each file in a directory via
for file in $(ls lib/*.c) ; do file=${file%.c}.o ; make $file ; done
and I noticed that inflate.o wasn't made.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [MEMSTICK] Initial commit for Sony MemoryStick support
Mostly just stylistic comments from me here. On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: > From: Alex Dubov <[EMAIL PROTECTED]> > > Sony MemoryStick cards are used in many products manufactured by Sony. They > are available both as storage and as IO expansion cards. Currently, only > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > interface. > > Signed-off-by: Alex Dubov <[EMAIL PROTECTED]> For MemoryStick Pro on my TI7421 card reader (since my old MemoryStick card and camera have disappeared somewhere, so I cannot currently test that): Tested-by: Carlos Corbacho <[EMAIL PROTECTED]> However, my only concerns are that: 1) tifm_ms was not autoloaded 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not. Although, whether this is an issue with userspace (ie. udev) not dealing with the modules properly, I don't know. > --- /dev/null > +++ b/drivers/memstick/core/memstick.c > @@ -0,0 +1,557 @@ > +/* > + * memstick.c - Sony MemoryStick support File names in comments are now frowned upon - there was a thread on this in October on LKML: http://lkml.org/lkml/2007/10/12/524 Also, before Andrew gets in with this - you should run this through checkpatch, as there are a few errors it throws up (mostly foo* and C99 comments). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Dec 30, 2007 3:23 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote: > > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote: > > > > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > > > > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > please check if you can replace the one in the x86-mm > > > > > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > > > > > > > > > > > > the updated one avoid one link warning. > > > > > > > > > > please send delta patches instead - so that we can review the changes. > > > > > > > > will do that in another patch. > > > > > > > > > > > > > > > this is the updated verison that take enable_IO_APIC as extra call > > > > > > for > > > > > > setup_local_APIC to avoid linking warning. > > > > > > > > > > hm, what link warning did you get? Perhaps the following __cpuinit: > > > > > > > > WARNING: vmlinux.o(.text+0x163d5): Section mismatch: reference to > > > > .init.text:enable_IO_APIC (between 'setup_local_APIC' and > > > > 'apic_is_clustered_box') > > > > > > So you are doing complicated things for silencing the warning (there is > > > an easier ways for achieving it), but the real bug that you will get an > > > Oops when calling enable_IO_APIC() after bootup since it already got > > > freed stays? > > > > the enable_IO_APIC is actually doing clear_IO_APIC. and it is only > > called by BSP via setup_local_APIC > > and it is not called again after bootup > > OK, this was a bit hidden inside your pointer games. > > Please send a patch that ignores the warning (and therefore doesn't do > these pointer games), and I'll fix the warning in a followup patch. the old one is in x86-mm tree http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 function call delta http://lkml.org/lkml/2007/12/30/211 thanks YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Option to disable AMD C1E (allows dynticks to work)
On Sun, 30 Dec 2007 08:36:26 -0500 Richard Harman <[EMAIL PROTECTED]> wrote: > The C1E patch, which permits the lapic to function *does* make my > system stable. My previous method of testing (using USB peripherals) > and checking /proc/interrupts for ERRor interrupts so far hasn't > caused the system to lock up. Let me put it another way: have you actually experienced any lockups with a vanilla (that is, with no patches applied) 2.6.24-rc6 kernel? Try first with "force_amd_c1e". So far, all I see is that you're getting nohz/dynticks working with my patch, and that's okay, it's the expected behavior. But I seriously doubt that it's my patch that keeps your system from locking up. I'm not bugging you just to clarify this matter, but if your system locked up iff (as in both necessary and sufficient) the patch was _not_ applied, that would be a really serious issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Sun, Dec 30, 2007 at 02:42:41PM -0800, Yinghai Lu wrote: > On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote: > > > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > > > > > > please check if you can replace the one in the x86-mm > > > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > > > > > > > > > > the updated one avoid one link warning. > > > > > > > > please send delta patches instead - so that we can review the changes. > > > > > > will do that in another patch. > > > > > > > > > > > > this is the updated verison that take enable_IO_APIC as extra call for > > > > > setup_local_APIC to avoid linking warning. > > > > > > > > hm, what link warning did you get? Perhaps the following __cpuinit: > > > > > > WARNING: vmlinux.o(.text+0x163d5): Section mismatch: reference to > > > .init.text:enable_IO_APIC (between 'setup_local_APIC' and > > > 'apic_is_clustered_box') > > > > So you are doing complicated things for silencing the warning (there is > > an easier ways for achieving it), but the real bug that you will get an > > Oops when calling enable_IO_APIC() after bootup since it already got > > freed stays? > > the enable_IO_APIC is actually doing clear_IO_APIC. and it is only > called by BSP via setup_local_APIC > and it is not called again after bootup OK, this was a bit hidden inside your pointer games. Please send a patch that ignores the warning (and therefore doesn't do these pointer games), and I'll fix the warning in a followup patch. > YH cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RAID timeout parameter accessibility request
On Dec 30 2007 23:42, Jose de la Mancha wrote: >SHORT QUESTION : >In a Debian-controlled RAID array, is there a parameter that handles the >timeout before a non-responding drive is dropped from the array ? Can this >timeout become user-adjustable in a future build ? Not sure about Debian, but perhaps /sys/block/md0/md/safe_mode_delay does something? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
Alan Cox wrote: Now what's interesting is that the outb to port 80 is *faster* than an outb to an unused port, on my machine. So there's something there - actually accepting the bus transaction. In the ancient 5150 PC, 80 was Yes and I even told you a while back how to verify where it is. From the timing you get its not on the LPC bus but chipset core so pretty certainly an SMM trap as other systems with the same chipset don't have the bug. Probably all that is needed is a BIOS upgrade Actually, I could see whether it was SMM trapping due to AMD MSR's that would allow such trapping, performance or debug registers. Nothing was set to trap with SMI or other traps on any port outputs. But I'm continuing to investigate for a cause. It would be nice if it were a BIOS-fixable problem. It would be even nicer if the BIOS were GPL... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RAID timeout parameter accessibility request
Jose de la Mancha wrote: Hi everyone. I'm sorry but I'm not currently subscribed to this list (I've been sent here by the listmaster), so please CC me all your answers/comments. Thanks in advance. SHORT QUESTION : In a Debian-controlled RAID array, is there a parameter that handles the timeout before a non-responding drive is dropped from the array ? Can this timeout become user-adjustable in a future build ? EXPLANATIONS : As you might know, if you install and use a "desktop edition" hard drive in a RAID array, the drive may not work correctly. This is caused by the normal error recovery procedure that a desktop edition hard drive uses : when an error is found on a desktop edition hard drive, the drive will enter into a deep recovery cycle to attempt to repair the error, recover the data from the problematic area, and then reallocate a dedicated area to replace the problematic area. This process can take up to 120 seconds depending on the severity of the issue. The problem is that most RAID controllers allow a very short amount of time (7-15 seconds) for a hard drive to recover from an error. If a hard drive takes too long to complete this process, the drive will be dropped from the RAID array ! This always seemed a strange use case to me. If the drive is getting read errors, either it's dying and needs to be replaced, or it has a sporadic bad sector as a result of a power failure during write, etc. in which case the drive should be resynchronized. In either case the drive should be dropped from the array and require manual intervention. It doesn't seem logical to me to just read the data from another drive and carry on in our merry way without any warning. Of course there are "RAID edition" hard drives with a feature called TLER (Time Limited Error Recovery) which stops the hard drive from entering into a deep recovery cycle. The hard drive will only spend 7 seconds to attempt to recover. This means that the hard drive will not be dropped from a RAID array. But these "special" hard drives are way too expensive IMHO just for a small firmware-based feature. There would be an easy way to allow users to use "ordinary" hard drives in a Debian software-controlled RAID array. So here's my request : I suppose there is a parameter that handles the default timeout before a drive is dropped from the RAID array. I don't know if this parameter is hardcoded, but it would be nice if it was user-adjustable. This way, we could simply set up this parameter to 120 seconds or more (instead of 7-15) and we wouldn't have any more problems with using desktop "edition hard" drives in a RAID array. What do you think ? Can it be done in a future build ? I really hope that you'll be able to help, because I guess a lot of people can be concerned by this issue. Many thanks in advance & Best regards. I don't know the md internals very well, but I wouldn't imagine there's a timeout in its code, the timeout would be based on the block layer and driver timeouts for the consitituent devices. For libata disks, the timeout is normally 30 seconds. After that expires, the disk will get a soft or hard reset and the command is typically retried by the block layer. If all retries fail the upper layers will get a failure report, and I believe at that point the md layer decides to disable the device. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RAID timeout parameter accessibility request
Hi everyone. I'm sorry but I'm not currently subscribed to this list (I've been sent here by the listmaster), so please CC me all your answers/comments. Thanks in advance. SHORT QUESTION : In a Debian-controlled RAID array, is there a parameter that handles the timeout before a non-responding drive is dropped from the array ? Can this timeout become user-adjustable in a future build ? EXPLANATIONS : As you might know, if you install and use a "desktop edition" hard drive in a RAID array, the drive may not work correctly. This is caused by the normal error recovery procedure that a desktop edition hard drive uses : when an error is found on a desktop edition hard drive, the drive will enter into a deep recovery cycle to attempt to repair the error, recover the data from the problematic area, and then reallocate a dedicated area to replace the problematic area. This process can take up to 120 seconds depending on the severity of the issue. The problem is that most RAID controllers allow a very short amount of time (7-15 seconds) for a hard drive to recover from an error. If a hard drive takes too long to complete this process, the drive will be dropped from the RAID array ! Of course there are "RAID edition" hard drives with a feature called TLER (Time Limited Error Recovery) which stops the hard drive from entering into a deep recovery cycle. The hard drive will only spend 7 seconds to attempt to recover. This means that the hard drive will not be dropped from a RAID array. But these "special" hard drives are way too expensive IMHO just for a small firmware-based feature. There would be an easy way to allow users to use "ordinary" hard drives in a Debian software-controlled RAID array. So here's my request : I suppose there is a parameter that handles the default timeout before a drive is dropped from the RAID array. I don't know if this parameter is hardcoded, but it would be nice if it was user-adjustable. This way, we could simply set up this parameter to 120 seconds or more (instead of 7-15) and we wouldn't have any more problems with using desktop "edition hard" drives in a RAID array. What do you think ? Can it be done in a future build ? I really hope that you'll be able to help, because I guess a lot of people can be concerned by this issue. Many thanks in advance & Best regards. Jose -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Dec 30, 2007 2:06 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote: > > On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > > > > please check if you can replace the one in the x86-mm > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > > > > > > > > the updated one avoid one link warning. > > > > > > please send delta patches instead - so that we can review the changes. > > > > will do that in another patch. > > > > > > > > > this is the updated verison that take enable_IO_APIC as extra call for > > > > setup_local_APIC to avoid linking warning. > > > > > > hm, what link warning did you get? Perhaps the following __cpuinit: > > > > WARNING: vmlinux.o(.text+0x163d5): Section mismatch: reference to > > .init.text:enable_IO_APIC (between 'setup_local_APIC' and > > 'apic_is_clustered_box') > > So you are doing complicated things for silencing the warning (there is > an easier ways for achieving it), but the real bug that you will get an > Oops when calling enable_IO_APIC() after bootup since it already got > freed stays? the enable_IO_APIC is actually doing clear_IO_APIC. and it is only called by BSP via setup_local_APIC and it is not called again after bootup YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 2.6.22.2 ] : drivers/net/via-rhine.c: Offload checksum handling to VT6105M
Hi Kim,
On Fri, Aug 17, 2007 at 11:34:37AM -0700, K Naru wrote:
> From: Kim Naru ([EMAIL PROTECTED])
>
> Added support to offload TCP/UDP/IP checksum to the
> VIA Technologies VT6105M chip.
> Firstly, let the stack know this chip is capable of
> doing its own checksum(IPV4 only).
> Secondly offload checksum to VT6105M, if necessary.
>
>
> Verbose Mode:
>
> #1. Define 3 bits(18,19,20) in Transmit Descriptor 1
> of chip, which affect checksum processing.
> The prefix(TDES1) for the 3 variables is the short
> name for Transmit Descriptior 1.
> #2. In rhine_init_one(), if pci_rev >= VT6105M then
> set NETIF_F_IP_CSUM(see skbuff.h for details).
> #3. In rhine_start_tx() if NETIF_F_IP_CSUM is set AND
> the stack requires a checksum then
> set either bit 19(UDP),20(TCP) AND bit 18(IP).
>
> Note : The numbered items above(i.e.#1,#2,#3) denote
> pseudo code.
>
> This patch was developed and tested on Imedia
> linux-2.6.20 under a PC-Engines Alix System board
> (www.pcengines.ch/alix.htm). It was tested(compilation
> only) on linux-2.6.22.2. The minor code change between
> 2.6.20 and 2.6.22 is the use of ip_hdr() in 2.26.22.
>
> In 2.6.20 :
> struct iphdr *ip = skb->nh.iph;
> In 2.6.22 :
> const struct iphdr *ip = ip_hdr(skb);
>
> Testing:
>
>
> ttcp,netperf ftp and top where used. There appears to
> be a small CPU utilization gain. Throughput results
> where more inconclusive.
>
> The data sheet used to get information is 'VT6105M
> Data Sheet, Revision 1.63 June21,2006'.
>
> Signed-off-by: Kim Naru ([EMAIL PROTECTED])
>
> ---
Well, I've reformated your patch so that it can be applied, and very
slightly arranged it in order to save 13 bytes of code and a few CPU
cycles.
Also, I moved the if block before the spinlock as there is no reason
for this code to be run with the lock held.
I have run some performance measurements on an ALIX 3C2 motherboard
with a 2.6.22-stable kernel. What I see is a reduction of CPU usage
by about 20% when the network is saturated, but also a reduction of
the network speed by 8%!
Without the patch, I can produce a continuous traffic of about 99 Mbps with
about 11% CPU (system only, 89% idle).
With the patch, the traffic drops to 91 Mbps but CPU usage decreases to 9%.
Now, if I reduce the MTU to exactly 1000, then the traffic increases to about
98 Mbps, but it progressively reduces when the MTU moves away from 1000.
So I have run some deeper tests consisting in leaving NETIF_F_IP_CSUM unset
and still asking the NIC to compute the checksums. The conclusion is very
clear: as soon as *any* checksum bit is set (IP, TCP, UDP), the traffic
immediately drops.
I think that what happens is that the NIC is not pipelined at all and that
no data is transferred while a checksum is being computed. This would also
explain why reducing the MTU increases performance, since it reduces the
time required to compute a checksum, reducing the off time. And the more I
think about it, the more I think this is the problem, because the VT6105M
has a 2kB transmit buffer, so it cannot checksum a 1.5kB frame while sending
another one if it does it inside the buffer.
And I'm pretty sure that the checksum is computed in the buffer and that the
data is not transferred twice on the bus, because playing with PCI latency
timer and other parameters does not change anything.
So basically, we're there with a chip which can offload the CPU by performing
the checksums itself, but it reduces performance for packets larger than 1kB
(or possibly 500 bytes if there's a 1.5kB packet being transferred).
The driver should be adjusted to permit the user to enable and disable this
feature with ethtool. Right now, its status can only be consulted, and I'm
using dd on /dev/mem and /dev/kmem to change the values on the fly.
Given the fact that a 20% reduction on CPU usage which was already 10% only
leaves a net gain of about 2% more CPU available, I'm not convinced that there
is any advantage in enabling this feature by default with this NIC.
Here's the updated patch for reference (maybe you'd want to enhance it).
--- linux-2.6.22-wt3/drivers/net/via-rhine.c2007-11-22 17:48:34 +0100
+++ linux-2.6.22-wt3.via-cksum/drivers/net/via-rhine.c 2007-12-30 20:53:30
+0100
@@ -95,6 +95,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -343,6 +345,9 @@
/* Initial value for tx_desc.desc_length, Buffer size goes to bits 0-10 */
#define TXDESC 0x00e08000
+#define TDES1_TCPCK0x0010 /* Bit 20, Transmit Desc 1 */
+#define TDES1_UDPCK0x0008 /* Bit 19, Transmit Desc 1 */
+#define TDES1_IPCK 0x0004 /* Bit 18, Transmit Desc 1 */
enum rx_status_bits {
RxOK=0x8000, RxWholePkt=0x0300, RxErr=0x008F
@@ -788,6 +793,9 @@
if (rp->quirks & rqRhineI)
dev->features |= NETIF_F_SG|NETIF_F_HW_CSUM;
+ if (pci_rev >= VT6105M)
+ dev->features |= NETIF_F_IP_CSUM;
Re: [PATCH] Hibernation: Document __save_processor_state() on x86-64
On Sunday, 30 of December 2007, Ingo Molnar wrote: > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > what's exactly in the hibernation image? Dirty data i suppose > > > > No, everything, including the kernel code, page tables etc. :-) > > > > > - but what about kernel-internal pages. What if we go from SLAB to > > > SLUB? What if the size of a structure changes? Etc. > > > > We can go from SLAB to SLUB just fine, it doesn't matter. The only > > thing that matters is we have to jump to the right address at the end > > of core_restore_code() (defined in arch/x86/kernel/suspend_asm_64.S). > > ok, just to make sure we are talking about the same thing. Do you mean > we can restore an image saved by v2.6.12 into v2.6.24? I.e. a 2.6.24 > kernel will be able to run a 2.6.12 kernel's hibernation image, with all > the kernel internal data from v2.6.12, etc? No way can that work. Well, not exactly. The support for different boot and image kernels has only been merged recently, but we can use the current git to restore 2.6.24-rc6-mm1, for example. The trick is to pass a little additional information in the image header that can be used by the boot kernel to locate the entry point to the image kernel and the image kernel's page tables. 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/
[BUG] 2.6.24rc6 allmodconfig - unload capidrv fails
rmmod capidrv never returns this is 2.6.24-rc6 with allmodconfig gcc version 4.2.1 (SUSE Linux) also see https://bugzilla.novell.com/show_bug.cgi?id=350850 [ 1807.666763] capidrv: Rev 1.1.2.2: loaded [ 1810.803450] capidrv: Rev 1.1.2.2 : unloaded [ 1810.808417] BUG: unable to handle kernel NULL pointer dereference at virtual address 0009 [ 1810.808446] printing eip: c020afca *pde = [ 1810.809301] Oops: [#1] SMP [ 1810.810225] Modules linked in: capidrv kernelcapi isdn slhc iptable_filter ip_tables edd ip6table_filter ip6_tables x_tables ipv6 af_packet microcode firmware_class fuse loop dm_mod 8250_pnp ide_cd cdrom pata_acpi ata_piix ahci parport_pc floppy pcnet32 8250 parport serial_core ata_generic rtc_cmos rtc_core mii rtc_lib libata pcspkr i2c_piix4 i2c_core piix generic container ac ide_core intel_agp power_supply agpgart button thermal shpchp processor pci_hotplug mousedev evdev sg ext3 jbd mbcache sd_mod mptspi mptscsih mptbase scsi_transport_spi scsi_mod [ 1810.810402] [ 1810.810471] Pid: 4500, comm: kstopmachine Not tainted (2.6.24-rc6allmodconfig #3) [ 1810.810488] EIP: 0060:[] EFLAGS: 00010092 CPU: 0 [ 1810.810609] EIP is at list_del+0xa/0x61 [ 1810.810716] EAX: e0ae8704 EBX: 0009 ECX: EDX: df686e10 [ 1810.810808] ESI: de8f4ef0 EDI: EBP: deb57fb4 ESP: deb57fa4 [ 1810.810890] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 1810.812131] Process kstopmachine (pid: 4500, ti=deb57000 task=df686e10 task.ti=deb57000) [ 1810.812156] Stack: c03f50ac 0046 0008 deb57fbc c0153506 deb57fd0 c015fb58 [ 1810.812412]de8f4ef0 c015fa9c deb57fe0 c013fe7e c013fe43 [ 1810.812424]c0108d77 de8f4e6c [ 1810.812444] Call Trace: [ 1810.812485] [] show_trace_log_lvl+0x1a/0x2f [ 1810.812569] [] show_stack_log_lvl+0x9b/0xa3 [ 1810.812577] [] show_registers+0xa7/0x179 [ 1810.812584] [] die+0x13a/0x225 [ 1810.812589] [] do_page_fault+0x554/0x632 [ 1810.812616] [] error_code+0x72/0x78 [ 1810.812624] [] __unlink_module+0xb/0xf [ 1810.812635] [] do_stop+0xbc/0x110 [ 1810.812643] [] kthread+0x3b/0x61 [ 1810.812649] [] kernel_thread_helper+0x7/0x10 [ 1810.812669] === [ 1810.812680] Code: 00 00 8b 53 10 8d 4b 0c 8d 46 0c e8 72 00 00 00 89 f8 e8 87 fe ff ff 83 c4 10 5b 5e 5f 5d c3 90 90 55 89 e5 53 83 ec 0c 8b 58 04 <8b> 0b 39 c1 74 18 89 4c 24 08 89 44 24 04 c7 04 24 1a 1d 39 c0 [ 1810.812691] EIP: [] list_del+0xa/0x61 SS:ESP 0068:deb57fa4 [ 1810.812700] ---[ end trace 25d0c1bb6d183e81 ]--- __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
* Alan Cox <[EMAIL PROTECTED]> wrote:
> > ok. Like the patch below?
>
> Not quite - you still need the loop in case you NMI and then run off
> into oblivion
yes indeed. Updated patch below.
Ingo
-->
Subject: x86: hlt on early crash
From: Ingo Molnar <[EMAIL PROTECTED]>
H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> It probably should actually HLT, to avoid sucking power, and stressing
> the thermal system. We're dead at this point, and the early 486's
> which had problems with HLT will lock up - we don't care.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/boot/compressed/misc_32.c |3 ++-
arch/x86/boot/compressed/misc_64.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -339,7 +339,8 @@ static void error(char *x)
putstr(x);
putstr("\n\n -- System halted");
- while(1); /* Halt */
+ while (1)
+ asm("hlt");
}
asmlinkage void decompress_kernel(void *rmode, unsigned long end,
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -338,7 +338,8 @@ static void error(char *x)
putstr(x);
putstr("\n\n -- System halted");
- while(1); /* Halt */
+ while (1)
+ asm("hlt");
}
asmlinkage void decompress_kernel(void *rmode, unsigned long heap,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Sun, Dec 30, 2007 at 12:48:48PM -0800, Yinghai Lu wrote:
> On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Yinghai Lu <[EMAIL PROTECTED]> wrote:
> >
> > > please check if you can replace the one in the x86-mm
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76
> > >
> > > the updated one avoid one link warning.
> >
> > please send delta patches instead - so that we can review the changes.
>
> will do that in another patch.
>
> >
> > > this is the updated verison that take enable_IO_APIC as extra call for
> > > setup_local_APIC to avoid linking warning.
> >
> > hm, what link warning did you get? Perhaps the following __cpuinit:
>
> WARNING: vmlinux.o(.text+0x163d5): Section mismatch: reference to
> .init.text:enable_IO_APIC (between 'setup_local_APIC' and
> 'apic_is_clustered_box')
So you are doing complicated things for silencing the warning (there is
an easier ways for achieving it), but the real bug that you will get an
Oops when calling enable_IO_APIC() after bootup since it already got
freed stays?
> > > -void __cpuinit setup_local_APIC (void)
> >
> > does not mix well with an __init call:
> >
> > > +void __init enable_IO_APIC(void)
> >
> > and you hack it around by using a function pointer. Nasty and still
> > buggy. The proper solution would be to mark enable_IO_APIC as __cpuinit
> > too (or something like that).
>
> after change that to __cpuinit, i got
>
> WARNING: vmlinux.o(.text+0x17f84): Section mismatch: reference to
> .init.text: (between 'enable_IO_APIC' and 'ioapic_resume')
> WARNING: vmlinux.o(.text+0x17f92): Section mismatch: reference to
> .init.text: (between 'enable_IO_APIC' and 'ioapic_resume')
find_isa_irq_{apic,pin} are called by enable_IO_APIC() and therefore
also have to be changed from __init to __cpuinit.
> YH
cu
Adrian
BTW: Is there a reason why your patch doesn't touch the 32bit code?
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: gitignore arch/x86/vdso files
* Sam Ravnborg <[EMAIL PROTECTED]> wrote: > Teach git to ignore generated files in > arch/x86/vdso/* thanks Sam, applied. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Changing high kernel keycodes
Greetings! Some of the keys on my USB-HID keyboard generate scancodes which are bound to big keycodes in `drivers/hid/hid-input.c` and `include/linux/input.h`, like 418, 419 or 432. Is there any possibility to change it (in runtime, without editing `input.h` and recompiling the kernel)? Should `setkeycodes(1)` work today? I'm using 2.6.24-rc6-git4 kernel snapshot. I've found several postings on lkml considering KDSETKEYCODE ioctl functioning in kernel, but I'm not sure about how it is in recent versions. (Sorry if this is an offtopic here, point me to an appropriate newsgroup/ml in that case.) -- Happy Hacking. http://sphinx.net.ru む -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
* Alan Cox <[EMAIL PROTECTED]> wrote: > On Sun, 30 Dec 2007 21:46:50 +0100 > Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > well, using io_delay=udelay is not 'blindly disabling'. io_delay=none > > would be the end goal, once all _p() API uses are eliminated by > > transformation. > > io_delay = none is not the end goal. Correctness is the end goal. the end goal will be for io_delay=none to be a NOP, because nothing will use the _p() ops anymore. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hibernation: Document __save_processor_state() on x86-64
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > what's exactly in the hibernation image? Dirty data i suppose > > No, everything, including the kernel code, page tables etc. :-) > > > - but what about kernel-internal pages. What if we go from SLAB to > > SLUB? What if the size of a structure changes? Etc. > > We can go from SLAB to SLUB just fine, it doesn't matter. The only > thing that matters is we have to jump to the right address at the end > of core_restore_code() (defined in arch/x86/kernel/suspend_asm_64.S). ok, just to make sure we are talking about the same thing. Do you mean we can restore an image saved by v2.6.12 into v2.6.24? I.e. a 2.6.24 kernel will be able to run a 2.6.12 kernel's hibernation image, with all the kernel internal data from v2.6.12, etc? No way can that work. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
* Alan Cox <[EMAIL PROTECTED]> wrote: > You won't bisect obscure timing triggered problems, and the _p users > are almost all for hardware where performance doesn't matter one iota > (eg CMOS). actually, people have, and i have too. But i agree that io_delay=none would be stupid now, and would probably be stupid in v2.6.26 too. i also have a debug patch that counts the number of _p() API uses and prints a stacktrace (once per bootup) if it occurs [wrote it 2 weeks ago] - so i agree with you that we can do this more gradually and more intelligently. As long as it does not turn into a BKL situation. It's 2008 in a day and we've still got the NFS client code running under the BKL - quite ridiculous IMO. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On 30-12-07 22:44, H. Peter Anvin wrote:
Ingo Molnar wrote:
It probably should actually HLT, to avoid sucking power, and
stressing the thermal system. We're dead at this point, and the
early 486's which had problems with HLT will lock up - we don't care.
ok. Like the patch below?
Don't need the cli; we're already running with interrupts disabled.
I'd do:
while (1)
asm volatile("hlt");
... mostly on general principles.
At least with current GCC the volatile isn't strictly needed as its implied
without output operands but I was only certain after checking that. Do you
remember if that used to be different for previous GCC versions? I tend to
also stick volatiles on them still...
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 1/3] Remove unused dependency
On Sat, Dec 22, 2007 at 11:28:11AM -0800, Joe Perches wrote: > On Sat, 2007-12-22 at 15:31 +0100, Sam Ravnborg wrote: > > I looked at how inflate was used: > > > > $ grep inflate */boot/Makefile > > alpha/boot/Makefile:$(obj)/misc.o: lib/inflate.c > > => redundandt dependency, can be deleted > > A cleanup of all this is needed. > > Perhaps it's better to move lib/inflate.c to the > include path (include/lib ?) and convert the files that > #include "(../)*lib/inflate.c" to > #include ? Hi Joe. Can you please remind me what problem you are actually trying to solve here. Your current approach it not good - we do not want .c code in include/* And what is wrong with the current include path? Thanks, Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Hibernation: Document __save_processor_state() on x86-64 (rev. 2)
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Document the fact that __save_processor_state() has to save all CPU
registers referred to by the kernel in case a different kernel is
used to load and restore a hibernation image containing it.
Sigend-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/x86/kernel/suspend_64.c | 20
include/asm-x86/suspend_64.h |9 -
2 files changed, 28 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/x86/kernel/suspend_64.c
===
--- linux-2.6.orig/arch/x86/kernel/suspend_64.c
+++ linux-2.6/arch/x86/kernel/suspend_64.c
@@ -19,6 +19,21 @@ extern const void __nosave_begin, __nosa
struct saved_context saved_context;
+/**
+ * __save_processor_state - save CPU registers before creating a
+ * hibernation image and before restoring the memory state from it
+ * @ctxt - structure to store the registers contents in
+ *
+ * NOTE: If there is a CPU register the modification of which by the
+ * boot kernel (ie. the kernel used for loading the hibernation image)
+ * might affect the operations of the restored target kernel (ie. the one
+ * saved in the hibernation image), then its contents must be saved by this
+ * function. In other words, if kernel A is hibernated and different
+ * kernel B is used for loading the hibernation image into memory, the
+ * kernel A's __save_processor_state() function must save all registers
+ * needed by kernel A, so that it can operate correctly after the resume
+ * regardless of what kernel B does in the meantime.
+ */
void __save_processor_state(struct saved_context *ctxt)
{
kernel_fpu_begin();
@@ -69,6 +84,11 @@ static void do_fpu_end(void)
kernel_fpu_end();
}
+/**
+ * __restore_processor_state - restore the contents of CPU registers saved
+ * by __save_processor_state()
+ * @ctxt - structure to load the registers contents from
+ */
void __restore_processor_state(struct saved_context *ctxt)
{
/*
Index: linux-2.6/include/asm-x86/suspend_64.h
===
--- linux-2.6.orig/include/asm-x86/suspend_64.h
+++ linux-2.6/include/asm-x86/suspend_64.h
@@ -15,7 +15,14 @@ arch_prepare_suspend(void)
return 0;
}
-/* Image of the saved processor state. If you touch this, fix acpi/wakeup.S. */
+/*
+ * Image of the saved processor state, used by the low level ACPI suspend to
+ * RAM code and by the low level hibernation code.
+ *
+ * If you modify it, fix arch/x86/kernel/acpi/wakeup_64.S and make sure that
+ * __save/__restore_processor_state(), defined in arch/x86/kernel/suspend_64.c,
+ * still work as required.
+ */
struct saved_context {
struct pt_regs regs;
u16 ds, es, fs, gs, ss;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: fix section warning about enable_IO_APIC and setup_local_APIC
On Dec 30, 2007 1:29 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > [PATCH] x86_64: fix section warning about enable_IO_APIC and > > setup_local_APIC > > > > clear IO_APIC before enabing apic error vector cause link warning > > > > use function call in setup_local_APIC to avoid that. > > as i said, this just works around the link warning - now we've traded > the link warning for a runtime crash. you got one runtime crash by this fix? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hibernation: Document __save_processor_state() on x86-64
On Sunday, 30 of December 2007, Ingo Molnar wrote: > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > how different can it be, for resume to work? I mean, we'll have > > > deeply kernel version dependent variables in RAM. Am i missing > > > something obvious? > > > > On x86-64 it can be almost totally different (by restoring a > > hibernation image we replace the entire contents of RAM with almost no > > constraints). > > > > [Well, using a relocatable kernel for restoring an image with > > nonrelocatable one or vice versa is rather not the best idea, but > > everything else should work in theory.] > > > > On i386 the boot kernel is still required to be the same as the one in > > the image. > > what's exactly in the hibernation image? Dirty data i suppose No, everything, including the kernel code, page tables etc. :-) > - but what about kernel-internal pages. What if we go from SLAB to SLUB? > What if the size of a structure changes? Etc. We can go from SLAB to SLUB just fine, it doesn't matter. The only thing that matters is we have to jump to the right address at the end of core_restore_code() (defined in arch/x86/kernel/suspend_asm_64.S). 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: [RFC][PATCH] byteorder: introduce le32_add_cpu & friends to core
On Sun, Dec 30, 2007 at 07:18:25PM +, Christoph Hellwig wrote: > On Sun, Dec 30, 2007 at 08:06:34PM +0100, Marcin Slusarz wrote: > > There are many places where these functions would be useful. > > (just look at: grep -r 'cpu_to_[ble12346]*([ble12346]*_to_cpu.*[-+]' > > linux-src/) > > What do you think? > > > > ps: this patch depends on http://lkml.org/lkml/2007/12/25/35 > > -- > > > > add inline functions which add native byte order variable to > > little/big endian variable to core header and as an example > > convert ext3 to use them > > Various places already have this as be*_add / le*_add, so it might be > more useful to keep those names already in use. I found it in XFS only. Did I miss something? be32_add is shorter than be32_add_cpu but I think it's not clear whether second parameter is in native byte order or not. 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] x86: provide a DMI based port 0x80 I/O delay override
Ingo Molnar wrote:
It probably should actually HLT, to avoid sucking power, and stressing
the thermal system. We're dead at this point, and the early 486's
which had problems with HLT will lock up - we don't care.
ok. Like the patch below?
Don't need the cli; we're already running with interrupts disabled.
I'd do:
while (1)
asm volatile("hlt");
... mostly on general principles.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
> Now what's interesting is that the outb to port 80 is *faster* than an > outb to an unused port, on my machine. So there's something there - > actually accepting the bus transaction. In the ancient 5150 PC, 80 was Yes and I even told you a while back how to verify where it is. From the timing you get its not on the LPC bus but chipset core so pretty certainly an SMM trap as other systems with the same chipset don't have the bug. Probably all that is needed is a BIOS upgrade Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: gitignore arch/x86/vdso files
Teach git to ignore generated files in arch/x86/vdso/* Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> Cc: Roland McGrath <[EMAIL PROTECTED]> Cc: "H. Peter Anvin" <[EMAIL PROTECTED]> Cc: Ingo Molnar <[EMAIL PROTECTED]> Cc: Thomas Gleixner <[EMAIL PROTECTED]> --- arch/x86/vdso/.gitignore|4 arch/x86/vdso/vdso32/.gitignore |1 + 2 files changed, 5 insertions(+), 0 deletions(-) create mode 100644 arch/x86/vdso/vdso32/.gitignore diff --git a/arch/x86/vdso/.gitignore b/arch/x86/vdso/.gitignore index f8b69d8..b9030e5 100644 --- a/arch/x86/vdso/.gitignore +++ b/arch/x86/vdso/.gitignore @@ -1 +1,5 @@ vdso.lds +vdso-syms.lds +vdso32-syms.lds +vdso32-syscall-syms.lds +vdso32-sysenter-syms.lds diff --git a/arch/x86/vdso/vdso32/.gitignore b/arch/x86/vdso/vdso32/.gitignore new file mode 100644 index 000..e45fba9 --- /dev/null +++ b/arch/x86/vdso/vdso32/.gitignore @@ -0,0 +1 @@ +vdso32.lds -- 1.5.3.7.1112.g9758e -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
> ok. Like the patch below? Not quite - you still need the loop in case you NMI and then run off into oblivion -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] is checkpatch.pl broken
Cyrill Gorcunov wrote: Thanks Ingo, you're quite right! Next time i'll appear in list with real (and hope usefull) patch ;) Wonderful! I also *really* have to apologize for my short fuse earlier, it was uncalled for. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007 12:53:02 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > Bodo Eggert wrote: > > > > I've never seen code which would do that, and it was not suggested by any > > tutorial I ever saw. I'd expect any machine to break on all kinds of > > software > > if it required this. The only thing I remember being warned about is writing > > the index and the data register at the same time using outw, because that > > would write both registers at the same time on 16-bit-cards. > > > > And we use that, and have been for 15 years. I haven't seen any screams > of pain about it. Actually there were, and I sent numerous people patches for that back in ISA days. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007 21:46:50 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > well, using io_delay=udelay is not 'blindly disabling'. io_delay=none > would be the end goal, once all _p() API uses are eliminated by > transformation. io_delay = none is not the end goal. Correctness is the end goal. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
> fact even io_delay=udelay would be wrong because any problem will be > less clearly triggerable and thus less bisectable/debuggable. And if this eats someones disk because you drive the hardware out of spec you are going to sit there and tell them to bisect it ? Lovely. Ingo - put the christmas wine away and have a coffee. Now think first. You won't bisect obscure timing triggered problems, and the _p users are almost all for hardware where performance doesn't matter one iota (eg CMOS). This isn't even all down to the chipset internal logic - several of my boxes have external CMOS NVRAM/RTC chips which are probably the same design (if a little smaller) as ten years ago. io_delay = none is exactly the same thing as CPU overclocking. Hard to debug, unpredictable and stupid. 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: 2.6.24-rc6-mm1
On Dec 30, 2007 10:24 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
>
> On Fri, Dec 28, 2007 at 03:07:46PM -0800, Andrew Morton wrote:
> > On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > > > On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
> > > > I have finally given up on using 2.6.24-rc3-mm2 with slub_debug=FZP to
> > > > get more information out of the random crashes I had seen with that
> > > > version. (Did not crash once with slub_debug, so no new information on
> > > > what the cause was)
> > >
> > > Murphy: Just after sending that mail the system crashed two times with
> > > slub_debug=FZP, but did not show any new informations.
> > > No debug output from slub, only this stacktrace: (Its the same I
> > > already reported in the 2.6.24-rc3-mm2 thread)
> > >
[snip]
> > > [ 7620.708561] Pid: 5698, comm: nfsv4-svc Not tainted 2.6.24-rc3-mm2 #2
[snip]
> >
> > That looks like a sunrpc bug. git-nfsd has bene mucking around in there a
> > bit.
>
> Can you still reproduce this? Tom thought there was a chance the
> following could fix it.
Please see also http://lkml.org/lkml/2007/12/29/76
Just wanted to say that slub_debug did not help to get more infos.
I will try to reproduce this with rc3-mm2 and the below patch tomorrow.
Without slub_debug this seemed to trigger rather reliable when trying
to update/upgrade packages on my system.
> From: Tom Tucker <[EMAIL PROTECTED]>
> Date: Sun, 30 Dec 2007 10:07:17 -0600
>
> Bruce/Aime:
>
> Here is what I believe to be the fix for the crashes/svc_xprt BUG_ON
> that people are seeing. It would be great if those who have seen this
> problem could apply this patch and see if it resolves their problem.
>
> The common code calls svc_xprt_received on behalf of the transport.
> Since the provider was calling it as well, this resulted in clearing the
> busy bit/resetting xpt_pool when the BUSY bit wasn't held.
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 4628881..4d39db1 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -1272,7 +1272,6 @@ static struct svc_xprt *svc_create_socket(struct
> svc_serv *serv,
>
> if ((svsk = svc_setup_socket(serv, sock, , flags)) != NULL) {
> svc_xprt_set_local(>sk_xprt, newsin, newlen);
> - svc_xprt_received(>sk_xprt);
> return (struct svc_xprt *)svsk;
> }
I will send a mail, when I'm done with testing this...
Thanks for the patch.
Torsten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)
Eduard-Gabriel Munteanu wrote: On Sun, 30 Dec 2007 15:57:59 -0500 Richard Harman <[EMAIL PROTECTED]> wrote: I think I may have a monkey wrench to throw into this, I finally got around to testing the C1E patch, and the port80 patch. End result: port80 patch has zero effect on this laptop, and the C1E patch makes it stable. AMD C1E patch 'force_amd_c1e' (disabling the workaround): hpet0: at MMIO 0xfed0, IRQs 2, 8, 31 hpet0: 3 32-bit timers, 2500 Hz Time: hpet clocksource has been installed. Clockevents: could not switch to one-shot mode: lapic is not functional. Could not switch to high resolution mode on CPU 0 Clockevents: could not switch to one-shot mode: lapic is not functional. Could not switch to high resolution mode on CPU 1 And with the C1E workaround enabled, the kernel doesn't whine that the lapic isn't functional. Those were the kernel messages I was trying to paste in my earlier message, saying that the lapic works. Do I have a DV6000 laptop that is a strange beast all in itself? These two patches are not related in any way, they address two different problems. My patch enables dynticks (and those messages don't show up anymore), but it doesn't prevent your computer from locking up as you said before. The C1E patch, which permits the lapic to function *does* make my system stable. My previous method of testing (using USB peripherals) and checking /proc/interrupts for ERRor interrupts so far hasn't caused the system to lock up. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Ingo Molnar wrote:
> >> * Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >>> BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c
> >>> uses while(1) without cpu_relax() in order to halt the machine. Is this
> >>> fixed? Should it be fixed?
> >>
> >> this is early bootup so there's no need to be "nice" to other cores or
> >> sockets - none of them are really running.
> >>
> >
> > It probably should actually HLT, to avoid sucking power, and stressing
> > the thermal system. We're dead at this point, and the early 486's
> > which had problems with HLT will lock up - we don't care.
>
> ok. Like the patch below?
>
> - while(1); /* Halt */
> + asm("cli; hlt");/* Halt */
The other users would loop around the hlt. Cargo Cult?
--
Top 100 things you don't want the sysadmin to say:
97. Go get your backup tape. (You _do_ have a backup tape?)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
* Rene Herman <[EMAIL PROTECTED]> wrote: > On 30-12-07 21:46, Ingo Molnar wrote: >> * Alan Cox <[EMAIL PROTECTED]> wrote: >> So the current plan is to go with an io_delay=udelay default in v2.6.25, to give this a migration window, and io_delay=none in v2.6.26 [and a complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are fixed up. This is gradual enough to notice any regressions we care about and also makes it nicely bisectable and gradual. >>> You will break systems if you blindly go around disabling _p delays for >>> ISA and LPC bus devices. The DEC Hinote laptops for example are well >>> known for requiring the correct ISA and other keyboard controller delays. >>> I don't expect anyone to test with a hinote or see it until it hits >>> Debian or similar 'low resource' friendly devices. >> >> well, using io_delay=udelay is not 'blindly disabling'. > > On the other hand, the patch you just posted that makes io_delay=none > the default _is_ blindly disabling. So that wasn't for consumption? if you want to see the current x86.git intention then do: git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git cd linux-2.6.git git-branch x86 git-checkout x86 git-pull git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git mm right now the default is io_delay=udelay. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hibernation: Document __save_processor_state() on x86-64
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > how different can it be, for resume to work? I mean, we'll have > > deeply kernel version dependent variables in RAM. Am i missing > > something obvious? > > On x86-64 it can be almost totally different (by restoring a > hibernation image we replace the entire contents of RAM with almost no > constraints). > > [Well, using a relocatable kernel for restoring an image with > nonrelocatable one or vice versa is rather not the best idea, but > everything else should work in theory.] > > On i386 the boot kernel is still required to be the same as the one in > the image. what's exactly in the hibernation image? Dirty data i suppose - but what about kernel-internal pages. What if we go from SLAB to SLUB? What if the size of a structure changes? Etc. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix section warning about enable_IO_APIC and setup_local_APIC
* Yinghai Lu <[EMAIL PROTECTED]> wrote: > [PATCH] x86_64: fix section warning about enable_IO_APIC and setup_local_APIC > > clear IO_APIC before enabing apic error vector cause link warning > > use function call in setup_local_APIC to avoid that. as i said, this just works around the link warning - now we've traded the link warning for a runtime crash. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hibernation: Document __save_processor_state() on x86-64
On Sunday, 30 of December 2007, Ingo Molnar wrote: > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > But i'm wondering - are we really ever resuming to a different > > > kernel version, for this to be an issue? > > > > The boot kernel may be different from the kernel within the image, if > > that's what you're asking for. > > how different can it be, for resume to work? I mean, we'll have deeply > kernel version dependent variables in RAM. Am i missing something > obvious? On x86-64 it can be almost totally different (by restoring a hibernation image we replace the entire contents of RAM with almost no constraints). [Well, using a relocatable kernel for restoring an image with nonrelocatable one or vice versa is rather not the best idea, but everything else should work in theory.] On i386 the boot kernel is still required to be the same as the one in the image. Greetings, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86_64: fix section warning about enable_IO_APIC and setup_local_APIC
[PATCH] x86_64: fix section warning about enable_IO_APIC and setup_local_APIC
clear IO_APIC before enabing apic error vector cause link warning
use function call in setup_local_APIC to avoid that.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/smpboot_64.c
===
--- linux-2.6.orig/arch/x86/kernel/smpboot_64.c
+++ linux-2.6/arch/x86/kernel/smpboot_64.c
@@ -211,7 +211,7 @@ void __cpuinit smp_callin(void)
*/
Dprintk("CALLIN, before setup_local_APIC().\n");
- setup_local_APIC();
+ setup_local_APIC(NULL);
/*
* Get our bogomips.
@@ -867,6 +867,8 @@ void __init smp_set_apicids(void)
*/
void __init smp_prepare_cpus(unsigned int max_cpus)
{
+ void (*extra_call)(void) = NULL;
+
nmi_watchdog_default();
current_cpu_data = boot_cpu_data;
current_thread_info()->cpu = 0; /* needed? */
@@ -883,7 +885,10 @@ void __init smp_prepare_cpus(unsigned in
/*
* Switch from PIC to APIC mode.
*/
- setup_local_APIC();
+ if (!skip_ioapic_setup && nr_ioapics)
+ extra_call = enable_IO_APIC;
+
+ setup_local_APIC(extra_call);
if (GET_APIC_ID(apic_read(APIC_ID)) != boot_cpu_id) {
panic("Boot APIC ID in local APIC unexpected (%d vs %d)",
Index: linux-2.6/include/asm-x86/apic_64.h
===
--- linux-2.6.orig/include/asm-x86/apic_64.h
+++ linux-2.6/include/asm-x86/apic_64.h
@@ -74,7 +74,7 @@ extern int verify_local_APIC (void);
extern void cache_APIC_registers (void);
extern void sync_Arb_IDs (void);
extern void init_bsp_APIC (void);
-extern void setup_local_APIC (void);
+extern void setup_local_APIC (void (*extra_call)(void));
extern void init_apic_mappings (void);
extern void smp_local_timer_interrupt (void);
extern void setup_boot_APIC_clock (void);
Index: linux-2.6/arch/x86/kernel/apic_64.c
===
--- linux-2.6.orig/arch/x86/kernel/apic_64.c
+++ linux-2.6/arch/x86/kernel/apic_64.c
@@ -418,7 +418,7 @@ void __init init_bsp_APIC(void)
apic_write(APIC_LVT1, value);
}
-void __cpuinit setup_local_APIC (void)
+void __cpuinit setup_local_APIC (void (*extra_call)(void))
{
unsigned int value, maxlvt;
int i, j;
@@ -521,9 +521,8 @@ void __cpuinit setup_local_APIC (void)
* Now enable IO-APICs, actually call clear_IO_APIC
* We need clear_IO_APIC before enabling vector on BP
*/
- if (!smp_processor_id())
- if (!skip_ioapic_setup && nr_ioapics)
- enable_IO_APIC();
+ if (extra_call)
+ (*extra_call)();
{
unsigned oldvalue;
@@ -1206,6 +1205,8 @@ int disable_apic;
*/
int __init APIC_init_uniprocessor (void)
{
+ void (*extra_call)(void) = NULL;
+
if (disable_apic) {
printk(KERN_INFO "Apic disabled\n");
return -1;
@@ -1221,7 +1222,10 @@ int __init APIC_init_uniprocessor (void)
phys_cpu_present_map = physid_mask_of_physid(boot_cpu_id);
apic_write(APIC_ID, SET_APIC_ID(boot_cpu_id));
- setup_local_APIC();
+ if (!skip_ioapic_setup && nr_ioapics)
+ extra_call = enable_IO_APIC;
+
+ setup_local_APIC(extra_call);
if (smp_found_config && !skip_ioapic_setup && nr_ioapics)
setup_IO_APIC();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1
On Fri, Dec 28, 2007 at 03:07:46PM -0800, Andrew Morton wrote:
> On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > > On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
> > > I have finally given up on using 2.6.24-rc3-mm2 with slub_debug=FZP to
> > > get more information out of the random crashes I had seen with that
> > > version. (Did not crash once with slub_debug, so no new information on
> > > what the cause was)
> >
> > Murphy: Just after sending that mail the system crashed two times with
> > slub_debug=FZP, but did not show any new informations.
> > No debug output from slub, only this stacktrace: (Its the same I
> > already reported in the 2.6.24-rc3-mm2 thread)
> >
> > [ 7620.673012] [ cut here ]
> > [ 7620.676291] kernel BUG at lib/list_debug.c:33!
> > [ 7620.679440] invalid opcode: [1] SMP
> > [ 7620.682319] last sysfs file:
> > /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
> > [ 7620.687845] CPU 0
> > [ 7620.689300] Modules linked in: radeon drm nfsd exportfs w83792d
> > ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
> > tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
> > videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common
> > v4l1_compat hid i2c_nforce2 sg pata_amd
> > [ 7620.708561] Pid: 5698, comm: nfsv4-svc Not tainted 2.6.24-rc3-mm2 #2
> > [ 7620.713080] RIP: 0010:[] []
> > __list_add+0x54/0x60
> > [ 7620.718667] RSP: 0018:81011bca1dc0 EFLAGS: 00010282
> > [ 7620.722439] RAX: 0088 RBX: 81011c862c48 RCX:
> > 0002
> > [ 7620.727504] RDX: 81011bc82ef0 RSI: 0001 RDI:
> > 807590c0
> > [ 7620.732581] RBP: 81011bca1dc0 R08: 0001 R09:
> >
> > [ 7620.737658] R10: 810080058d48 R11: 0001 R12:
> > 81011ed8d1c8
> > [ 7620.742711] R13: 81011ed8d200 R14: 81011ed8d200 R15:
> > 81011cc0e578
> > [ 7620.747806] FS: 7ffe400116f0() GS:807d4000()
> > knlGS:f73558e0
> > [ 7620.753535] CS: 0010 DS: ES: CR0: 8005003b
> > [ 7620.757607] CR2: 017071dc CR3: 0001188b5000 CR4:
> > 06e0
> > [ 7620.762677] DR0: DR1: DR2:
> >
> > [ 7620.767748] DR3: DR6: 0ff0 DR7:
> > 0400
> > [ 7620.772808] Process nfsv4-svc (pid: 5698, threadinfo
> > 81011BCA, task 81011BC82EF0)
> > [ 7620.778872] Stack: 81011bca1e00 805be26e
> > 81011ed8d1d0 81011cc0e578
> > [ 7620.784626] 81011c862c48 81011c8be000 810054a8b060
> > 81011cc0e588
> > [ 7620.789913] 81011bca1e10 805be367 81011bca1ee0
> > 805bf0ac
> > [ 7620.795062] Call Trace:
> > [ 7620.796941] [] svc_xprt_enqueue+0x1ae/0x250
> > [ 7620.801087] [] svc_xprt_received+0x17/0x20
> > [ 7620.805199] [] svc_recv+0x39c/0x840
> > [ 7620.808851] [] svc_send+0xaf/0xd0
> > [ 7620.812374] [] default_wake_function+0x0/0x10
> > [ 7620.816637] [] nfs_callback_svc+0x7a/0x130
> > [ 7620.820712] [] trace_hardirqs_on_thunk+0x35/0x3a
> > [ 7620.825174] [] trace_hardirqs_on+0xbf/0x160
> > [ 7620.829335] [] child_rip+0xa/0x12
> > [ 7620.832842] [] restore_args+0x0/0x30
> > [ 7620.836554] [] nfs_callback_svc+0x0/0x130
> > [ 7620.840564] [] child_rip+0x0/0x12
> > [ 7620.844102]
> > [ 7620.845168] INFO: lockdep is turned off.
> > [ 7620.847964]
> > [ 7620.847965] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16
> > 48 89 e5 e8
> > [ 7620.854334] RIP [] __list_add+0x54/0x60
> > [ 7620.858255] RSP
> > [ 7620.860724] Kernel panic - not syncing: Aiee, killing interrupt handler!
> >
>
> That looks like a sunrpc bug. git-nfsd has bene mucking around in there a
> bit.
Can you still reproduce this? Tom thought there was a chance the
following could fix it.
--b.
From: Tom Tucker <[EMAIL PROTECTED]>
Date: Sun, 30 Dec 2007 10:07:17 -0600
Bruce/Aime:
Here is what I believe to be the fix for the crashes/svc_xprt BUG_ON
that people are seeing. It would be great if those who have seen this
problem could apply this patch and see if it resolves their problem.
The common code calls svc_xprt_received on behalf of the transport.
Since the provider was calling it as well, this resulted in clearing the
busy bit/resetting xpt_pool when the BUSY bit wasn't held.
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 4628881..4d39db1 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -1272,7 +1272,6 @@ static struct svc_xprt *svc_create_socket(struct svc_serv
*serv,
if ((svsk = svc_setup_socket(serv, sock, , flags)) != NULL) {
svc_xprt_set_local(>sk_xprt, newsin, newlen);
-
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
I am so happy that there will be a way for people who don't build their own kernels to run Linux on their HP and Compaq laptops that have problems with gazillions of writes to port 80, and I'm also happy that some of the strange driver code will be cleaned up over time. Thank you all. Some thoughts you all might consider, take or leave, in this process, from an old engineering manager who once had to worry about QA for software on nearly every personal computer model in the 1980-1992 period: You know, there is a class of devices that are defined to use port 0x80... it's that historically useful class of devices that show/record the POST diagnostics. It certainly was not designed for "delay" purposes. In fact, some of those same silly devices are still used in industry during manufacturing test. I wonder what would happen if Windows were not part of manufacturing test, and instead Linux were the "standard" for some category of machines... When I was still working at Lotus in the late '80's, when we still supported machines like 286's, there were lots of problems with timing loops in drivers in applications (even Win 3.0 had some in hard disk drivers, as did some of our printer drivers, ...), as clock speeds continued to ramp. There were major news stories of machines that "crashed when xyz application or zyx peripheral were added". It was Intel, as I recall, that started "publicly" berating companies in the PC industry for using the "two short jumps" solutions, and suggesting that they measure the processor speed at bootup, using the BIOS standard for doing that with the int 15 BIOS elapsed time calls, and always use "calibrated" timing loops. Which all of us who supported device drivers started to do (remember, apps had device drivers in those days for many devices that talked directly with the registers). I was impressed when I dug into Linux eventually, that this operating system "got it right" by measuring the timing during boot and creating a udelay function that really worked! So I have to say, that when I was tracing down the problem that originally kicked off this thread, which was that just accessing the RTC using the standard CMOS_READ macros in a loop caused a hang, that these "outb al,80h" things were there. And I noticed your skeptical comment in the code, Linus. Knowing that there was never in any of the documented RTC chipsets a need for a pause between accesses (going back to my days at Software Arts working on just about every old machine there was...) I changed it on a lark to do no pause at all. And my machine never hung... Now what's interesting is that the outb to port 80 is *faster* than an outb to an unused port, on my machine. So there's something there - actually accepting the bus transaction. In the ancient 5150 PC, 80 was unused because it was the DMA controller port that drove memory refresh, and had no meaning. Now my current hypothesis (not having access to quanta's design specs for a board they designed and have shipped in quantity, or having taken the laptop apart recently) is that there is logic there on port 80, doing something. Perhaps even "POST diagnostic recording" as every PC since the XT has supported... perhaps supporting post-crash dignostics... And that that something has a buffer, perhaps even in the "Embedded Controller" that may need emptying periodically. It takes several tens of thousands of "outb" to port 80 to hang the hardware solid - so something is either rare or overflowing. In any case, if this hypothesis is correct - the hardware may have an erratum, but the hardware is doing a very desirable thing - standardizing on an error mechanism that was already in the "standard" as an option... It's Linux that is using a "standard" in a wrong way (a diagnostic port as a delay). So I say all this, mainly to point out that Linux has done timing loops right (udelay and ndelay) - except one place where there was some skepticism expressed, right there in the code. Linus may have some idea why it was thought important to do an essential delay with a bus transaction that had uncertain timing. My hypothesis is that "community" projects have the danger of "magical theories" and "coolness" overriding careful engineering design practices. Cleaning up that "clever hack" that seemed so good at the time is hugely difficult, especially when the driver writer didn't write down why he used it. Thus I would suggest that the _p functions be deprecated, and if there needs to be a timing-delay after in/out instructions, define in_pause(port, nsec_delay) with an explicit delay. And if the delay is dependent on bus speeds, define a bus-speed ratio calibration. Thus in future driver writing, people will be forced to think clearly about what the timing characteristics of their device on its bus must be. That presupposes that driver writers understand the timing
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
> But that does't mean that other ports won't have the same timings. Also, > it doesn't mean that we really need to have exactly *those* timings. For ISA bus you want "at least" those timings. That is an easy case anyway - ISA bus boxes, old processors and generally no TSC so we can fall back to 0x80 - we know from 15 years experience the problem only occurs with recent non ISA systems that have borked firmware. Lots of ISA hardware does really need the delays and most of it will be on old processors as well naturally enough. > I also think that the worries about PCI write posting are unnecessary. IO > port accesses (ie a regular "inb()" and "outb()" even _without_ the "_p()" > format slowdown) are already synchronous not only by the CPU but by all Ok then the SCSI examples should be fine (although as I said I think they are possibly bogus anyway) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)
On Sun, 30 Dec 2007 15:57:59 -0500 Richard Harman <[EMAIL PROTECTED]> wrote: > I think I may have a monkey wrench to throw into this, I finally got > around to testing the C1E patch, and the port80 patch. End result: > port80 patch has zero effect on this laptop, and the C1E patch makes > it stable. > > AMD C1E patch 'force_amd_c1e' (disabling the workaround): > > hpet0: at MMIO 0xfed0, IRQs 2, 8, 31 > hpet0: 3 32-bit timers, 2500 Hz > Time: hpet clocksource has been installed. > Clockevents: could not switch to one-shot mode: lapic is not > functional. Could not switch to high resolution mode on CPU 0 > Clockevents: could not switch to one-shot mode: lapic is not > functional. Could not switch to high resolution mode on CPU 1 > > And with the C1E workaround enabled, the kernel doesn't whine that > the lapic isn't functional. > > Those were the kernel messages I was trying to paste in my earlier > message, saying that the lapic works. Do I have a DV6000 laptop that > is a strange beast all in itself? These two patches are not related in any way, they address two different problems. My patch enables dynticks (and those messages don't show up anymore), but it doesn't prevent your computer from locking up as you said before. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> * Bodo Eggert <[EMAIL PROTECTED]> wrote:
>>
>>> BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c
>>> uses while(1) without cpu_relax() in order to halt the machine. Is this
>>> fixed? Should it be fixed?
>>
>> this is early bootup so there's no need to be "nice" to other cores or
>> sockets - none of them are really running.
>>
>
> It probably should actually HLT, to avoid sucking power, and stressing
> the thermal system. We're dead at this point, and the early 486's
> which had problems with HLT will lock up - we don't care.
ok. Like the patch below?
Ingo
-->
Subject: x86: hlt on early crash
From: Ingo Molnar <[EMAIL PROTECTED]>
H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> It probably should actually HLT, to avoid sucking power, and stressing
> the thermal system. We're dead at this point, and the early 486's
> which had problems with HLT will lock up - we don't care.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/boot/compressed/misc_32.c |2 +-
arch/x86/boot/compressed/misc_64.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -339,7 +339,7 @@ static void error(char *x)
putstr(x);
putstr("\n\n -- System halted");
- while(1); /* Halt */
+ asm("cli; hlt");/* Halt */
}
asmlinkage void decompress_kernel(void *rmode, unsigned long end,
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -338,7 +338,7 @@ static void error(char *x)
putstr(x);
putstr("\n\n -- System halted");
- while(1); /* Halt */
+ asm("cli; hlt");/* Halt */
}
asmlinkage void decompress_kernel(void *rmode, unsigned long heap,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: unify arch/x86/kernel/Makefile(s)
On Sun, Dec 30, 2007 at 05:10:41PM +0100, Ingo Molnar wrote: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > i've added your full patch meanwhile - maybe we can get away with it. > > i needed the trivial fix below. You did not test-build it on 32-bit it > appears :-) Had CONFIG_X86_GENERICARCH defined so I did not hit this one - sorry. Thanks for fixing it up. 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] Option to disable AMD C1E (allows dynticks to work)
On Sun, 30 Dec 2007 15:42:17 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> writes: > > > > Other kernel developers, as discussed previously in this thread, are > > working on a HPET-driven dynticks (as opposed to the current > > LAPIC-driven one), but the change isn't that easy to make. > > No, actually HPET based dyntick has been implemented for a long time > (as long as APIC based dyntick). APIC based dyntick is preferred > because it is a little cheaper, but both are there. > > The problem is just that many BIOSes don't tell the kernel about the > HPET location (even when the chipset supports it) because that wasn't > needed for older Windows versions. And without the BIOS telling the > kernel HPET it doesn't know where it is and can't use it when > the APIC timer is not usable. > > The ongoing work is to implement hpet=force code that knows > about various chipsets and reads their hardware registers directly > and then uses the HPET timer without BIOS support. As far as I can see, the kernel doesn't behave as it would be, IMO, normal. I do have HPETs and Linux detects them without any need for hpet=force (HPET is registered for clockevents), but keeps LAPIC as the only option for dynticks. It looks like timing devices are rated and then only one of them is selected for dynticks. But when that one (here LAPIC) fails to provide the required functionality for nohz, Linux does not fallback to the next best timer, as dynticks is provided with only one such device, hence the message "lapic is not functional" is shown. In fact, this selection process should be fixed. Before coding my patch, I tried fiddling with that rating algorithm, but Linux kept locking up during boot. I'll try again, maybe my approach wasn't correct, but please tell me: is HPET-driven dynticks code working? (I'm quite confused, as HPET should wake the CPUs even when in C1E.) > > This way, > > dynticks and C1E could be both enabled and thus save more power. > > I would not expect too much over a HZ=100 kernel on current AMD. With my patch (the one that disables C1E), powertop shows at most 10-11 wakeups per second when idle (no X server running). Isn't it reasonable to expect a significant improvement over HZ=100? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] is checkpatch.pl broken
* Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> This patch eliminates checkpatch.pl complains on bootflag.c
thanks, applied this to x86.git, to the v2.6.25 queue. See the finalized
patch below. (I added two more small cleanups that checkpatch did not
warn about but which were obvious)
Ingo
--->
Subject: x86: coding style cleanup for kernel/bootflag.c
From: Cyrill Gorcunov <[EMAIL PROTECTED]>
This patch eliminates checkpatch.pl complaints on bootflag.c
No code changed:
textdata bss dec hex filename
321 8 0 329 149 bootflag.o.before
321 8 0 329 149 bootflag.o.after
md5:
9c1b474bcf25ddc1724a29c19880043f bootflag.o.before.asm
9c1b474bcf25ddc1724a29c19880043f bootflag.o.after.asm
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/kernel/bootflag.c | 50 -
1 file changed, 27 insertions(+), 23 deletions(-)
Index: linux-x86.q/arch/x86/kernel/bootflag.c
===
--- linux-x86.q.orig/arch/x86/kernel/bootflag.c
+++ linux-x86.q/arch/x86/kernel/bootflag.c
@@ -1,8 +1,6 @@
/*
* Implement 'Simple Boot Flag Specification 2.0'
*/
-
-
#include
#include
#include
@@ -14,40 +12,38 @@
#include
-
#define SBF_RESERVED (0x78)
#define SBF_PNPOS(1<<0)
#define SBF_BOOTING (1<<1)
#define SBF_DIAG (1<<2)
#define SBF_PARITY (1<<7)
-
int sbf_port __initdata = -1; /* set via acpi_boot_init() */
-
static int __init parity(u8 v)
{
int x = 0;
int i;
-
- for(i=0;i<8;i++)
- {
- x^=(v&1);
- v>>=1;
+
+ for (i = 0; i < 8; i++) {
+ x ^= (v & 1);
+ v >>= 1;
}
+
return x;
}
static void __init sbf_write(u8 v)
{
unsigned long flags;
- if(sbf_port != -1)
- {
+
+ if (sbf_port != -1) {
v &= ~SBF_PARITY;
- if(!parity(v))
- v|=SBF_PARITY;
+ if (!parity(v))
+ v |= SBF_PARITY;
- printk(KERN_INFO "Simple Boot Flag at 0x%x set to 0x%x\n",
sbf_port, v);
+ printk(KERN_INFO "Simple Boot Flag at 0x%x set to 0x%x\n",
+ sbf_port, v);
spin_lock_irqsave(_lock, flags);
CMOS_WRITE(v, sbf_port);
@@ -57,33 +53,41 @@ static void __init sbf_write(u8 v)
static u8 __init sbf_read(void)
{
- u8 v;
unsigned long flags;
- if(sbf_port == -1)
+ u8 v;
+
+ if (sbf_port == -1)
return 0;
+
spin_lock_irqsave(_lock, flags);
v = CMOS_READ(sbf_port);
spin_unlock_irqrestore(_lock, flags);
+
return v;
}
static int __init sbf_value_valid(u8 v)
{
- if(v_RESERVED) /* Reserved bits */
+ if (v & SBF_RESERVED) /* Reserved bits */
return 0;
- if(!parity(v))
+ if (!parity(v))
return 0;
+
return 1;
}
static int __init sbf_init(void)
{
u8 v;
- if(sbf_port == -1)
+
+ if (sbf_port == -1)
return 0;
+
v = sbf_read();
- if(!sbf_value_valid(v))
- printk(KERN_WARNING "Simple Boot Flag value 0x%x read from CMOS
RAM was invalid\n",v);
+ if (!sbf_value_valid(v)) {
+ printk(KERN_WARNING "Simple Boot Flag value 0x%x read from "
+ "CMOS RAM was invalid\n", v);
+ }
v &= ~SBF_RESERVED;
v &= ~SBF_BOOTING;
@@ -92,7 +96,7 @@ static int __init sbf_init(void)
v |= SBF_PNPOS;
#endif
sbf_write(v);
+
return 0;
}
-
module_init(sbf_init);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: unify arch/x86/kernel/Makefile(s)
On Sun, Dec 30, 2007 at 04:06:02PM +0100, Ingo Molnar wrote: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > Combine the 32 and 64 bit specific Makefiles in one file. While > > > doing so link order was (almost) preserved on 32 bit but on 64 bit > > > link order changed a lot. > > > > > > Patch was checked with defconfig + allyesconfig builds. The same .o > > > files were linked in these configurations. > > > > > > To keep readability of the Makefiles a few Kconfig symbols was > > > added/modified and it was checked that they were not used anywhere > > > else. > > > > hm, i agree with this change, but would it be possible to split this > > up into gradual steps, to change the rules on 64-bit one by one? That > > would make it much more bisectable. In our experience changes to the > > link order have a high likelyhood of breaking stuff, as we've got so > > many implicit initcall dependencies that are not explicitly spelled > > out. > > i've added your full patch meanwhile - maybe we can get away with it. > > Still, if you see any easy way to do a straightforward series of ~40 > patches that changes one link rule per patch then that would be great > and we could add them as an easier-to-bisect replacement for this one > large-scope patch. If it turns out to cause troubles I will redo it in a few smaller steps. But I will have to do it by hand so most likely less than 10 steps. 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] x86: provide a DMI based port 0x80 I/O delay override
On 30-12-07 21:46, Ingo Molnar wrote: * Alan Cox <[EMAIL PROTECTED]> wrote: So the current plan is to go with an io_delay=udelay default in v2.6.25, to give this a migration window, and io_delay=none in v2.6.26 [and a complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are fixed up. This is gradual enough to notice any regressions we care about and also makes it nicely bisectable and gradual. You will break systems if you blindly go around disabling _p delays for ISA and LPC bus devices. The DEC Hinote laptops for example are well known for requiring the correct ISA and other keyboard controller delays. I don't expect anyone to test with a hinote or see it until it hits Debian or similar 'low resource' friendly devices. well, using io_delay=udelay is not 'blindly disabling'. On the other hand, the patch you just posted that makes io_delay=none the default _is_ blindly disabling. So that wasn't for consumption? io_delay=udelay additionally blindly disables the race-hiding effect the outb has on SMP and that Alan is seeing so many of. Should also wait for more driver review. 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] Option to disable AMD C1E (allows dynticks to work)
Eduard-Gabriel Munteanu wrote: On Sun, 30 Dec 2007 03:49:21 +0200 Note that this problem is only related to AMD64 multi-core laptops. As far as I can see, devs might not invest much coding effort into this and instead say "Go buy an Intel laptop!", as this really is a hardware quirk. And if Andi Kleen is correct, this is not just a laptop vendors' problem, but AMD itself doesn't offer support for higher C-states. I think I may have a monkey wrench to throw into this, I finally got around to testing the C1E patch, and the port80 patch. End result: port80 patch has zero effect on this laptop, and the C1E patch makes it stable. AMD C1E patch 'force_amd_c1e' (disabling the workaround): hpet0: at MMIO 0xfed0, IRQs 2, 8, 31 hpet0: 3 32-bit timers, 2500 Hz Time: hpet clocksource has been installed. Clockevents: could not switch to one-shot mode: lapic is not functional. Could not switch to high resolution mode on CPU 0 Clockevents: could not switch to one-shot mode: lapic is not functional. Could not switch to high resolution mode on CPU 1 And with the C1E workaround enabled, the kernel doesn't whine that the lapic isn't functional. Those were the kernel messages I was trying to paste in my earlier message, saying that the lapic works. Do I have a DV6000 laptop that is a strange beast all in itself? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] is checkpatch.pl broken
[Ingo Molnar - Sun, Dec 30, 2007 at 06:22:50PM +0100]
|
| * Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
|
| > orig:
| > mbr_base = (buf_base+sector_size-1) & ~(sector_size-1);
| > new (could be):
| > mbr_base = (buf_base + sector_size - 1) & ~(sector_size - 1);
| >
| > Is a new version that bad?
|
| it's certainly acceptable as newly introduced code but only borderline
| better than the original code. I'd suggest to stick to the problem areas
| that checkpatch.pl complains about at the moment - we have really
| obvious bad looking pieces of code that checkpatch.pl reports, and going
| after the borderline cases will only result in coding-style lawyering
| and flamewars, not any genuine increase in code quality ;-)
|
| for example:
|
| arch/x86/kernel/bootflag.c:
|
| total: 19 errors, 2 warnings, 98 lines checked
|
| or:
|
| arch/x86/kernel/apm_32.c:
|
| total: 56 errors, 31 warnings, 2402 lines checked
|
| and once we have nothing but the borderline cases and if we get really
| bored we can start coding style flamewars ;-)
|
| Ingo
|
Hi Ingo,
here is a first for x86 tree
- Cyrill -
---
From: Cyrill Gorcunov <[EMAIL PROTECTED]>
Subject: [x86] coding style cleanup for kernel/bootflag.c
This patch eliminates checkpatch.pl complains
on bootflag.c
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
arch/x86/kernel/bootflag.c | 40 +++-
1 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/bootflag.c b/arch/x86/kernel/bootflag.c
index 0b98605..1697e49 100644
--- a/arch/x86/kernel/bootflag.c
+++ b/arch/x86/kernel/bootflag.c
@@ -24,30 +24,29 @@
int sbf_port __initdata = -1; /* set via acpi_boot_init() */
-
static int __init parity(u8 v)
{
int x = 0;
int i;
-
- for(i=0;i<8;i++)
- {
- x^=(v&1);
- v>>=1;
+
+ for (i = 0; i < 8; i++) {
+ x ^= (v & 1);
+ v >>= 1;
}
+
return x;
}
static void __init sbf_write(u8 v)
{
unsigned long flags;
- if(sbf_port != -1)
- {
+ if (sbf_port != -1) {
v &= ~SBF_PARITY;
- if(!parity(v))
- v|=SBF_PARITY;
+ if (!parity(v))
+ v |= SBF_PARITY;
- printk(KERN_INFO "Simple Boot Flag at 0x%x set to 0x%x\n",
sbf_port, v);
+ printk(KERN_INFO "Simple Boot Flag at 0x%x set to 0x%x\n",
+ sbf_port, v);
spin_lock_irqsave(_lock, flags);
CMOS_WRITE(v, sbf_port);
@@ -59,31 +58,38 @@ static u8 __init sbf_read(void)
{
u8 v;
unsigned long flags;
- if(sbf_port == -1)
+
+ if (sbf_port == -1)
return 0;
+
spin_lock_irqsave(_lock, flags);
v = CMOS_READ(sbf_port);
spin_unlock_irqrestore(_lock, flags);
+
return v;
}
static int __init sbf_value_valid(u8 v)
{
- if(v_RESERVED) /* Reserved bits */
+ if (v & SBF_RESERVED) /* Reserved bits */
return 0;
- if(!parity(v))
+ if (!parity(v))
return 0;
+
return 1;
}
static int __init sbf_init(void)
{
u8 v;
- if(sbf_port == -1)
+
+ if (sbf_port == -1)
return 0;
+
v = sbf_read();
- if(!sbf_value_valid(v))
- printk(KERN_WARNING "Simple Boot Flag value 0x%x read from CMOS
RAM was invalid\n",v);
+ if (!sbf_value_valid(v))
+ printk(KERN_WARNING "Simple Boot Flag value 0x%x read from "
+ "CMOS RAM was invalid\n", v);
v &= ~SBF_RESERVED;
v &= ~SBF_BOOTING;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
Ingo Molnar wrote: * Bodo Eggert <[EMAIL PROTECTED]> wrote: BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c uses while(1) without cpu_relax() in order to halt the machine. Is this fixed? Should it be fixed? this is early bootup so there's no need to be "nice" to other cores or sockets - none of them are really running. It probably should actually HLT, to avoid sucking power, and stressing the thermal system. We're dead at this point, and the early 486's which had problems with HLT will lock up - we don't care. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
Juergen Beisert wrote: On Sunday 30 December 2007 16:38, Alan Cox wrote: do you have any memories about the outb_p() use of misc_32.c: pos = (x + cols * y) * 2; /* Update cursor position */ outb_p(14, vidport); outb_p(0xff & (pos >> 9), vidport+1); outb_p(15, vidport); outb_p(0xff & (pos >> 1), vidport+1); was this ever needed? This is so early in the bootup that can we cannot None - but we don't care. Was this embedded outb to 0x80 for delay only? Maybe I'm wrong. But in the case above it forces the chipselect signal to deselect the hardware between the access to vidport and vidport+1. Some devices need this to latch the values correctly. Otherwise the chipselect signal would be active for all four accesses in the example above (and only data and addresses are changing from device's view). Presumably you're talking about an actual ISA bus here. On those, you don't really have a chip select; but you'd expect the latch to happen on the rising edge of IOW#, not on an internally generated chip select. Now, I think there is a specific reason to believe that EGA/VGA (but perhaps not CGA/MDA) didn't need these kinds of hacks: the video cards of the day was touched, directly, by an interminable number of DOS applications. CGA/MDA generally *were not*, due to the unsynchronized memory of the original versions (writing could cause snow), so most applications tended to fall back to using the BIOS access methods for CGA and MDA. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
Bodo Eggert wrote: I've never seen code which would do that, and it was not suggested by any tutorial I ever saw. I'd expect any machine to break on all kinds of software if it required this. The only thing I remember being warned about is writing the index and the data register at the same time using outw, because that would write both registers at the same time on 16-bit-cards. And we use that, and have been for 15 years. I haven't seen any screams of pain about it. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
* Alan Cox <[EMAIL PROTECTED]> wrote: > > So the current plan is to go with an io_delay=udelay default in v2.6.25, > > to give this a migration window, and io_delay=none in v2.6.26 [and a > > complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are > > fixed up. This is gradual enough to notice any regressions we care about > > and also makes it nicely bisectable and gradual. > > You will break systems if you blindly go around disabling _p delays > for ISA and LPC bus devices. The DEC Hinote laptops for example are > well known for requiring the correct ISA and other keyboard controller > delays. I don't expect anyone to test with a hinote or see it until it > hits Debian or similar 'low resource' friendly devices. well, using io_delay=udelay is not 'blindly disabling'. io_delay=none would be the end goal, once all _p() API uses are eliminated by transformation. In drivers/ alone that's more than 1000 callsites, so it's quite frequently used, and wont go away overnight. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hibernation: Document __save_processor_state() on x86-64
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > But i'm wondering - are we really ever resuming to a different > > kernel version, for this to be an issue? > > The boot kernel may be different from the kernel within the image, if > that's what you're asking for. how different can it be, for resume to work? I mean, we'll have deeply kernel version dependent variables in RAM. Am i missing something obvious? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: clear IO_APIC before enabing apic error vector. v2
On Dec 30, 2007 6:51 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > please check if you can replace the one in the x86-mm > > > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commitdiff;h=ffcbdc220a1520d006a837f33589c7c19ffbeb76 > > > > the updated one avoid one link warning. > > please send delta patches instead - so that we can review the changes. will do that in another patch. > > > this is the updated verison that take enable_IO_APIC as extra call for > > setup_local_APIC to avoid linking warning. > > hm, what link warning did you get? Perhaps the following __cpuinit: WARNING: vmlinux.o(.text+0x163d5): Section mismatch: reference to .init.text:enable_IO_APIC (between 'setup_local_APIC' and 'apic_is_clustered_box') > > > -void __cpuinit setup_local_APIC (void) > > does not mix well with an __init call: > > > +void __init enable_IO_APIC(void) > > and you hack it around by using a function pointer. Nasty and still > buggy. The proper solution would be to mark enable_IO_APIC as __cpuinit > too (or something like that). after change that to __cpuinit, i got WARNING: vmlinux.o(.text+0x17f84): Section mismatch: reference to .init.text: (between 'enable_IO_APIC' and 'ioapic_resume') WARNING: vmlinux.o(.text+0x17f92): Section mismatch: reference to .init.text: (between 'enable_IO_APIC' and 'ioapic_resume') YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Option to disable AMD C1E (allows dynticks to work)
On 29-12-07 10:09, Richard Harman wrote: Anyway, I'm extremely open to getting to the bottom of working around the quirks on this hardware. If I havn't mentioned it previously, this laptop is an HP dv6408nr, with an amd turion tl-56 cpu and nVidia MCP51 chipset. What can I do to help? It has been pulling teeth trying to get to the bottom of this. This thread-branch appears to be broken on lkml.org so I couldn't look back through it but was this what you tried? http://lkml.org/lkml/2007/12/29/65 Updated patch with Islam's values added at: http://lkml.org/lkml/2007/12/29/141 You'd plug in your values similarly and test... 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] Hibernation: Document __save_processor_state() on x86-64
On Sunday, 30 of December 2007, Ingo Molnar wrote: > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Document the fact that __save_processor_state() has to save all CPU > > registers referred to by the kernel in case a different kernel is used > > to load and restore a hibernation image containing it. > > ok - so i guess i should drop this from x86.git: > > @@ -53,7 +53,6 @@ void __save_processor_state(struct saved > ctxt->cr2 = read_cr2(); > ctxt->cr3 = read_cr3(); > ctxt->cr4 = read_cr4(); > - ctxt->cr8 = read_cr8(); > } > > right? Well, if cr8 is used for anything that matters, then yes. > But i'm wondering - are we really ever resuming to a different > kernel version, for this to be an issue? The boot kernel may be different from the kernel within the image, if that's what you're asking for. 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: allmodconfig: udev won`t start due to CONFIG_UNIX=m
On Sun, Dec 30, 2007 at 09:18:38PM +0100, Jan Engelhardt wrote: > > On Dec 30 2007 21:11, [EMAIL PROTECTED] wrote: > > > >i build a kernel with allmodconfig and didn`t get my system to boot with > >that. > > > >after some investigation i found that it was due to udev: > > > >udevd[1226]: init_udev_socket: error getting socket: Address family not > >supported by protocol > > > >this was missing support UNIX DOMAIN SOCKETS at boot time. > >easy - so i added unix.ko to my initrd. > > > >but that didn`t make a difference. Still same error with udev. > > > >seems, there are others who stepped into this trap and someone telling, unix > >domain sockets cannot be modular > >https://forums.gentoo.org/viewtopic-t-476363-highlight-.html > >https://forums.gentoo.org/viewtopic-t-463793-highlight-.html > > > > > >since we have 1206 options set to "Y" anyway, would it make sense to remove > >module support for Unix Domain Sockets ? > >opensuse103:/home/kernel/linux-2.6.23 # cat .config.allmodconfig |grep "=y" > >|wc -l > >1206 > >opensuse103:/home/kernel/linux-2.6.23 # cat .config.allmodconfig |grep "=m" > >|wc -l > >2098 > > > >i also came across this one: > > > >http://readlist.com/lists/vger.kernel.org/linux-kernel/41/205717.html > > > > I'd rather much do in the Kconfig: > > config UNIX > tristate "UNIX domain sockets" if I_KNOW_WHAT_I_AM_DOING # currently > called CONFIG_EMBEDDED > bool "UNIX domain sockets" CONFIG_EMBEDDED is _not_ a generic "advanced user" option, it's only for options that allow additional space savings. What you could actually do would be config UNIX bool "Unix domain sockets" if EMBEDDED default y since as the help text already says everything other than Y is expected to cause problems - and if people know they are in a space limited environment and really don't need it they'll still be able to disable it. As a bonus, making it a bool would allow to make the kernel image slightly smaller for everyone. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > So even if that "port 80" access will also cause PCI postings to be > flushed, so would the actual IO access that accompanies it, so I don't > think that is a very strong argument. > > With all that said: it is certainly possible that the 1us timing makes > a difference on some machine, and it is certainly *also* theoretically > possible that there is a buggy chipset that posts too much, and the > port 80 access might make a difference, but it's not all that likely, > and I suspect we'd be better off handling those devices/drivers on a > one-by-one basis as we find them. yeah, wholeheartedly agreed, and this is what x86.git is heading towards. All test feedback so far is positive. With strong tools like bisection there's no reason why we couldnt approach it this way. If this change breaks anything, it will be bisected down to the patch below. In fact even io_delay=udelay would be wrong because any problem will be less clearly triggerable and thus less bisectable/debuggable. Ingo ---> Subject: x86: make io_delay=none the default From: Ingo Molnar <[EMAIL PROTECTED]> make io_delay=none the default. This is the first step towards removing all the legacy io-delay API uses. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> --- arch/x86/Kconfig.debug |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-x86.q/arch/x86/Kconfig.debug === --- linux-x86.q.orig/arch/x86/Kconfig.debug +++ linux-x86.q/arch/x86/Kconfig.debug @@ -133,7 +133,7 @@ config IO_DELAY_TYPE_NONE choice prompt "IO delay type" - default IO_DELAY_0X80 + default IO_DELAY_NONE config IO_DELAY_0X80 bool "port 0x80 based port-IO delay [recommended]" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
On Sun, 30 Dec 2007, Ingo Molnar wrote:
> * Andreas Mohr <[EMAIL PROTECTED]> wrote:
>
> > (yes, that's all there is, despite CONFIG_USB_DEBUG being set)
> >
> > The LED of a usb stick isn't active either, for obvious reasons.
> >
> > And keep in mind that this is a (relatively old) OHCI-only machine...
> > (which had the 2.6.19 lsmod showing ohci-hcd just fine and working
> > fine with WLAN USB)
> >
> > Now pondering whether to try -rc6 proper or whether to revert specific
> > guilty-looking USB changes... And wondering how to properly elevate
> > this issue (prompt Greg about it, new thread, bug #, ...?)
It looks like Greg misused the debugfs API -- which is ironic, because
he wrote debugfs in the first place! :-)
Let me know if this patch fixes the problem. If it does, I'll submit
it to Greg with all the proper accoutrements.
Alan Stern
Index: 2.6.24-rc6-mm1/drivers/usb/host/ohci-hcd.c
===
--- 2.6.24-rc6-mm1.orig/drivers/usb/host/ohci-hcd.c
+++ 2.6.24-rc6-mm1/drivers/usb/host/ohci-hcd.c
@@ -1067,14 +1067,8 @@ static int __init ohci_hcd_mod_init(void
#ifdef DEBUG
ohci_debug_root = debugfs_create_dir("ohci", NULL);
- if (!ohci_debug_root || IS_ERR(ohci_debug_root)) {
- if (!ohci_debug_root)
- retval = -ENOENT;
- else
- retval = PTR_ERR(ohci_debug_root);
-
- goto error_debug;
- }
+ if (!ohci_debug_root)
+ return -ENOENT;
#endif
#ifdef PS3_SYSTEM_BUS_DRIVER
@@ -1142,7 +1136,6 @@ static int __init ohci_hcd_mod_init(void
#ifdef DEBUG
debugfs_remove(ohci_debug_root);
ohci_debug_root = NULL;
- error_debug:
#endif
return retval;
Index: 2.6.24-rc6-mm1/drivers/usb/host/ohci-dbg.c
===
--- 2.6.24-rc6-mm1.orig/drivers/usb/host/ohci-dbg.c
+++ 2.6.24-rc6-mm1/drivers/usb/host/ohci-dbg.c
@@ -813,30 +813,29 @@ static inline void create_debug_files (s
struct device *dev = bus->dev;
ohci->debug_dir = debugfs_create_dir(bus->bus_name, ohci_debug_root);
- if (!ohci->debug_dir || IS_ERR(ohci->debug_dir)) {
- ohci->debug_dir = NULL;
- goto done;
- }
+ if (!ohci->debug_dir)
+ return;
ohci->debug_async = debugfs_create_file("async", S_IRUGO,
ohci->debug_dir, dev,
_async_fops);
- if (!ohci->debug_async || IS_ERR(ohci->debug_async))
+ if (!ohci->debug_async)
goto async_error;
ohci->debug_periodic = debugfs_create_file("periodic", S_IRUGO,
ohci->debug_dir, dev,
_periodic_fops);
- if (!ohci->debug_periodic || IS_ERR(ohci->debug_periodic))
+ if (!ohci->debug_periodic)
goto periodic_error;
ohci->debug_registers = debugfs_create_file("registers", S_IRUGO,
ohci->debug_dir, dev,
_registers_fops);
- if (!ohci->debug_registers || IS_ERR(ohci->debug_registers))
+ if (!ohci->debug_registers)
goto registers_error;
- goto done;
+ ohci_dbg(ohci, "created debug files\n");
+ return;
registers_error:
debugfs_remove(ohci->debug_periodic);
@@ -847,10 +846,6 @@ periodic_error:
async_error:
debugfs_remove(ohci->debug_dir);
ohci->debug_dir = NULL;
-done:
- return;
-
- ohci_dbg (ohci, "created debug files\n");
}
static inline void remove_debug_files (struct ohci_hcd *ohci)
Index: 2.6.24-rc6-mm1/drivers/usb/host/ehci-hcd.c
===
--- 2.6.24-rc6-mm1.orig/drivers/usb/host/ehci-hcd.c
+++ 2.6.24-rc6-mm1/drivers/usb/host/ehci-hcd.c
@@ -1019,14 +1019,8 @@ static int __init ehci_hcd_init(void)
#ifdef DEBUG
ehci_debug_root = debugfs_create_dir("ehci", NULL);
- if (!ehci_debug_root || IS_ERR(ehci_debug_root)) {
- if (!ehci_debug_root)
- retval = -ENOENT;
- else
- retval = PTR_ERR(ehci_debug_root);
-
- return retval;
- }
+ if (!ehci_debug_root)
+ return -ENOENT;
#endif
#ifdef PLATFORM_DRIVER
Index: 2.6.24-rc6-mm1/drivers/usb/host/ehci-dbg.c
===
--- 2.6.24-rc6-mm1.orig/drivers/usb/host/ehci-dbg.c
+++ 2.6.24-rc6-mm1/drivers/usb/host/ehci-dbg.c
@@ -914,30 +914,28 @@ static inline void create_debug_files (s
struct usb_bus *bus = _to_hcd(ehci)->self;
ehci->debug_dir = debugfs_create_dir(bus->bus_name, ehci_debug_root);
- if (!ehci->debug_dir ||
