gt;nr_running == 1) {
> + /* Avoid tasks exiting pulling parents to new nodes */
Semi-confusing wording (WTH are "pulling parents"? :) - possibly better
variant?:
Avoid having exiting tasks pull their parents to new nodes
Good catch, it seems.
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
On Thu, Jun 29, 2017 at 08:26:20AM +0200, Andreas Mohr wrote:
> On Wed, Jun 28, 2017 at 02:19:25PM +0200, Petr Mladek wrote:
> > On Wed 2017-05-31 16:22:33, Sergey Senozhatsky wrote:
> > > so I try to minimize the negative impact of RT prio here. printk_kthread
> > > is
ecks on a *global*/*shared* printk queue payload
(insertion submission of further elements into this queue
must still be possible at any time
without (excessive) blocking, though, of course).
while (can_continue_dumping)
{
payload_mutex_begin();
element = grab_element();
payload_mutex_end();
dump_element(element);
}
payload_mutex_begin();
queue_element(element);
payload_mutex_end();
HTH,
Andreas Mohr
printk kthread (i.e., that "more special" thread worker context)
should merely be *one* user of these printk queue servicing APIs.
And those servicing APIs should simply be invocable by anyone
who would want to take part in
getting the printk queue load properly serviced,
without any special handwaving.
[I can easily make all those "easy" wishlist requests -
I did not have to painfully design all that stuff ;-)]
Andreas Mohr
rge huge of small
> + * bios in case of mkfs.
"huge of small bios in case" - -ENOPARSE.
"huge numbers of"?
"huge or small"?
HTH,
Andreas Mohr
"implementation aspects" necessity which is currently poisoning user
code implementation).
Put differently,
handling preferrably ought to get consistently adapted (i.e., switched)
*centrally*,
rather than
requiring weird helpers (printk_emergency_X()) at all user code sites.
...or so goes the theory.
(quite possibly such thoughts may hit roadblocks e.g. due to locking/atomicity
issues)
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
imprecision here
again simply is due to
the very frequently observable case of
saying "thou shan't do this" without then also
giving some tried-and-true *reason(s)* for such advice.
("ERROR: Macros with complex values should be enclosed in parentheses")
HTH,
Andreas Mohr
On Tue, Oct 11, 2016 at 01:02:10PM -0700, Doug Anderson wrote:
> Andreas,
>
> On Tue, Oct 11, 2016 at 12:30 PM, Andreas Mohr wrote:
> > This loop implementation relies on negative kmin (result of ktime_sub())
> > getting internally handled by schedule_hrtimeout_range() as a
e could simply say that
the annoyingly extra calculation via ktime_before() call
should simply be removed completely.
Which would be a good step since it would centralize protocol behaviour
within the inner handling of the helper
rather than bloating user-side instruction cache footprint.
?
Thanks,
Andreas Mohr
g
and be done with it).
And those users then surely wouldn't want to experience a behaviour
where the delay may be ended at any time,
however short that may end up being.
A related topic probably is
premature wakeups (e.g. signal-induced) of select() etc. protocol.
Greetings,
Andreas Mohr
tion/type of input data is rather irrelevant -
all that matters is how you want to treat things in your *inner handling* -
and if that happens to be ktime-based
(as is usually - if not pretty much always - the case within kernel code),
then it ought to be that way,
*consistently* (to avoid conversion transition overhead).
Andreas Mohr
uot;current" time,
thereby bogusly accumulating scheduling-based delays
with each new loop iteration etc.
(i.e., things should still be based on hard, precise termination according to
an *initially* calculated, *absolute*, *minimum* expiry time).
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
it's exactly hitting the non-likely cases
which will contribute towards
non-predictable, non-deterministic latency behaviour of
a code path
(think RT requirements)
Thanks,
Andreas Mohr
On Tue, Sep 06, 2016 at 10:23:28AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 03:58:00AM +0200, Andreas Mohr wrote:
> > Hi,
> >
> > [no properly binding reference via In-Reply-To: available thus manually
> > re-creating, sorry]
> >
>
follow,
thus I'm not fully sure)
Thanks for working in this important area!
HTH,
Andreas Mohr
On Tue, Sep 06, 2016 at 02:26:06PM +0800, Baolin Wang wrote:
> On 6 September 2016 at 12:34, Andreas Mohr wrote:
> >> - to = from + nr;
> >> -
> >> - if (to <= from)
> >> - return -EINVAL;
> >
> > Hmm, this is swallow
are inclusive */
> + to -= 1;
> }
>
> - if (nr == 0)
> - return 0;
> -
> - to = from + nr;
> -
> - if (to <= from)
> - return -EINVAL;
Hmm, this is swallowing -EINVAL behaviour
i.e., now possibly violating protocol?
(this may easily be ok - haven't done an extensive review -
but since the commit has that characteristic change,
the commit message should contain that detail)
Thanks for the cleanup work & HTH,
Andreas Mohr
u get some symmetry/consistency malus points
for having provided
a relatively large amount of LOC extensions
which put certain amounts of stress on
code implementation quality/maintainability ;)]
HTH,
Andreas Mohr
On Mon, Sep 05, 2016 at 08:41:39AM -0400, Tejun Heo wrote:
> On Sun, Sep 04, 2016 at 03:29:39AM +0200, Andreas Mohr wrote:
> > Reason: any other [early-boot] invoker of cancel_delayed_work_sync()
> > would hit the same issue,
> > without any fix then available locally each.
quot;disable irq"
is the *pre-requisite* for being able to
reliably (atomically) steal work items from work list.
[[hmm, and let's hope that NMIs are (known to be?) not involved]]
HTH,
Andreas Mohr
ue to users being
hard-pressed to report this rather than
silently ignoring / not even knowing this issue
(in those cases where we already know that
no further development fixes will be determinable,
carrying on with a dire warning probably still is preferable to
making the machine completely unusable, eternally,
though).
Thus, think robustness.
Andreas Mohr
et properly determined
that in fact they *are* RT-type tasks
(the wording of "tg_has_rt_tasks" clearly suggests
that this API does *not* know yet
which task type it currently deals with,
so it does need to figure the type out, reliably,
by *not* directly calling into a fully RT-specific API).
ly do not have it, thus *we* *RELIABLY* are and will be "not the
owner"
[but note that in that case
this mutex API implementation code would have
a potentially unholy dependency on task stuff such as "current",
but which it probably already has anyway]
HTH,
Andreas Mohr
t_info() (etc.?) seem to be
*users* of a successful printk() *implementation* and thus
most certainly should not have any business whatsoever
also sitting within
the (already sufficiently complex / unreviewable - 3.3k lines!!)
printk() *implementation mechanics* file
HTH & HAND,
Andreas Mohr
Hello,
On Sun, Mar 20, 2016 at 05:51:23PM -0400, Theodore Ts'o wrote:
> On Sun, Mar 20, 2016 at 06:10:53PM +0100, Andreas Mohr wrote:
> > [ 18.164828] EXT4-fs (sda2): mounting ext3 file system using the ext4
> > subsyste
> > [ 248.211176] EXT4-fs (sda2): recovery
r than "standard" mount activity
would be sufficient,
both for text boot *and* GUI boot with some sufficiently accessible
"boot details" window.
Thanks,
Andreas Mohr
tion
> -by Intel and Microsoft which can be found at
> -
> - http://www.intel.com/hardwaredesign/hpetspec_1.pdf
> +by Intel and Microsoft, revision 1.
Oh, and I noticed as a curiosity (or so I thought)
that this cleanup-style work is (to be made?) part of "x86/urgent",
which I didn't expect to be defined as topically related.
Thanks,
Andreas Mohr
nishing that this issue is hitting the streets in 2015 -
if we aren't missing something here, that is...
HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
Hi,
[lkml.org info remains broken --> "special" reply rather than proper chain :(]
On Tue, Jun 02, 2015 at 09:07:02PM +0200, Andreas Mohr wrote:
> Hi,
>
> I'm wondering whether we're actually recording / retaining
> any info about the precise reason for the ma
queried immediately *without* any prior delay,
in which case the first (AND LAST!) PSMOUSE_CMD_GETID query
after the (your) delay
would now already fail for those devices...
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe fro
n by Andreas
> * Rename debug_kbd to unmask_kbd_data
> * Improve description in Documentation/kernel-parameters.txt
Patch in its entirety seems fine to me, thanks!
Reviewed-by: Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
_lsusb/
HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ault-disabled*,
i8042.debug_kbd will be implicitly enabled once i8042.debug=1 is available,
which is wrong).
Perhaps write it as something like
"and as pre-condition requires i8042.debug=1 to be enabled too".
Definitely very good to see this (quote) "big problem" corrected
storage types which simply do not need spinup)
- finally, it might be questionable *why* (whether) at certain points
we currently need (decide) to do spinup requests -
I guess it's in order to ensure in advance
that the disk will be ready once it actually will be needed, or so
Thank y
t;rtl_eriar_cond = 1 loop 100"
Yup, that seems to be
rtl_eri_read() in ethernet/realtek/r8169.c
waiting on low condition of
RTL_R32(ERIAR) & ERIAR_FLAG;
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
issue, see
https://bugzilla.kernel.org/show_bug.cgi?id=99421
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
oposed by Kay Sievers)
While we're quite firmly on the non-kernel side here,
I'll still scribble my
Reviewed-by: Andreas Mohr
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
puts(PACKAGE " version " VERSION);
> + puts(KMOD_FEATURES);
> return EXIT_SUCCESS;
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
Hi,
On Thu, Jun 04, 2015 at 01:19:46PM +1000, Stephen Rothwell wrote:
> Hi Rusty,
> > But disappointing that Debian doesn't configure with it, and there's no
> > easy way to check it. Looks like Ubuntu vivid is the same.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772628
Crap, that UR
On Wed, Jun 03, 2015 at 11:31:20PM -0300, Lucas De Marchi wrote:
> On Wed, Jun 3, 2015 at 10:30 PM, Rusty Russell wrote:
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 968a001790af..5422c44be5f0 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -1948,26 +1948,22 @@ config MODULE_
implementation got created,
it should be documented,
since currently grepping of Documentation/ for wakeup|grep -i reason
does not show any hints.
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
having to resort to clumsy hacks
such as ldd or even strings.
While this is a minor but useful addition
rather than a severe fix,
having a CC to stable@ added subsequently might be useful.
Thanks!
Signed-off-by: Andreas Mohr
---
init/Kconfig | 18 +-
1 file changed, 13 insert
Hi,
> Submitting the following information for kernel bug review.
> [1.] Lenovo SL510 will not resume from suspend
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/basic-pm-debugging.txt
might turn out to be quite helpful here.
HTH,
Andreas Mohr
nger requiring bitops.h
- bitops.h no longer including linux/compiler.h
IMHO explicitly #include:ing parts
which certain code does actively depend on after all
is both a "code honesty"
and a documentation issue ("Hmm, which interfaces does this implementation
depend on? Ah, yeah...&quo
space's
very limited 2GB/3GB total per Win32 process.
http://blogs.microsoft.co.il/sasha/2014/07/22/tracking-unusable-virtual-memory-vmmap/
"Why is address space allocation granularity 64K?"
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/08/55239.aspx
One thing less left to
On Tue, Jan 06, 2015 at 09:33:15AM -0600, Christoph Lameter wrote:
> On Tue, 6 Jan 2015, Andreas Mohr wrote:
> > by merely queuing them into a simple submission queue
> > which then will be delay-applied by main-context
> > either once main-context enters a certain "
On Tue, Jan 06, 2015 at 10:31:22AM +0900, Joonsoo Kim wrote:
> Hello,
>
> On Mon, Jan 05, 2015 at 06:21:39PM +0100, Andreas Mohr wrote:
> > Hi,
> >
> > Joonsoo Kim wrote:
> > > + ac->tid = next_tid(ac->tid);
> > (and all others)
> >
>
Hi,
> + if (size == 1)
> + *val = readb(addr);
> + else if (size == 2)
> + *val = readw(addr);
> + else
> + *val = readl(addr);
(pci_generic_config_read() and pci_generic_config_write())
switch()
default: WARN_ON(1);
?
Thanks,
[CC related ppl]
On Mon, Jan 05, 2015 at 12:10:54PM -0600, Scott Wood wrote:
> On Mon, 2015-01-05 at 18:46 +0100, Andreas Mohr wrote:
> > Hi,
> >
> > > I was curious why the mpic_cpu_read(MPIC_INFO(CPU_WHOAMI)) was there in
> > > the first place and if it'
alking out of my *ss without any MPIC specifics here
(and especially not why the readback there actually is needed -
if that doesn't happen to be the case for PCI Posting reasons or some such),
but it's just intended as food for thought :)
*) Real Silicon (rather than RL - Real Life)
HTH,
;m unsure (difficult to determine)
of whether this change is good (i.e. a clean step in the right direction),
or whether instead the implementation could easily directly be made
fully independent from IRQ constraints.
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubs
be cleanly optional/dynamic,
and then in case missing CONFIG_ACPI_SBS happens to be requested
try to give hints that it is missing
a) may easily be fully acceptable, but if b) is deemed better,
then perhaps there are ways
(such as failing calls --> generate log error message, ...)
to nicely determine
ications can, however, expect the format and contents of
the attribute files to remain consistent in the absence of a version
attribute change in the context of a given attribute.
This would be fulfilled by both the current and my suggested variant
of this interface, AFAICS.
Thanks,
Andreas
ly handled management parts,
which might be able to cause less runtime overhead).
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
d devices: 1.0 * diffstat_penalty
- for 25 year old devices: 1.5 * diffstat_penalty
- for 30 year old devices: whaaa?
Hmm?
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
cted
> - reworked sysex messages to use structs
> - ktime instead of jiffies for timeout
> ---
Nice!
Reviewed-by: Andreas Mohr
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
activated gcc non-const cast warnings)
> + end_time = ktime_add_ms(ktime_get(), 100);
Yay! One driver less which is advertising
less precise deprecated implementation style :)
> + /* check if the reply is our and has SYSEX_END at the end */
"ours"
Thanks,
Andreas
return ret;
> + }
I've been told the Fashionable Logger API Of The Week is dev_warn(),
since it's providing proper implicitly dev context decorated logging,
thus changing all affected code might be useful.
OTOH prior code happens to be making use of snd_printk currently,
so
it locally)
So much for a quick status update
(I'll be rebooting into 3.16 now - my last kernel build was as low as 3.11.x
even, WOW).
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
ME(x);
> + return x;
> + }
> +}
It might be useful to have a first commit to introduce these helpers,
and a second commit to then add ktime support (to keep review code size
down).
Thanks,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's
014 22:18:15 -0700,
> Dmitry Torokhov wrote:
> >
> > Hi Andreas,
> >
> > On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote:
> > > drivers (where the ones I'm owning hardware of are intended to be in
> > > active maintenance)
> >
On Tue, Aug 19, 2014 at 10:18:15PM -0700, Dmitry Torokhov wrote:
> Hi Andreas,
>
> On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote:
>
> > Hi,
> >
> > > Gameport support hasn't been working well ever since cpufreq became
> > > main
his again?) a huge favour...
We already have an IMHO dangerous state in support of somewhat less mainstream
hardware, so do we want to keep furthering that?
Could we have more details/discussion prior to activities to remove
whole subsystems?
Thanks,
Andreas Mohr
--
GNU/Linux. It's not the so
Hi,
late reply due to fatal environment failure, sorry.
On Mon, Aug 04, 2014 at 09:31:43PM -0700, Greg KH wrote:
> On Tue, Aug 05, 2014 at 06:13:25AM +0200, Andreas Mohr wrote:
> > Oh well, yet another driver where it became more difficult rather than
> > easier to make forward pr
r driver where it became more difficult rather than easier
to make forward progress.
But I guess that change was done very intentionally, likely to induce pain
in non-cooperative areas ;-P
(which may or may not be a good thing...)
Andreas Mohr
--
To unsubscribe from this list: send the line &qu
function pointers to spriv->type struct def,
to be able to do != NULL ptr checks and in such cases
call such chip-specific setup functions (i.e., call the HX type helper
which internally knows that it needs to do GPIO setup).
Such a change might be able to get rid of several #ifdef:s, too...
(pl
convenience
pl2303_gpio_state_update(gpio)
This would also increase GPIO hardware abstraction,
by then simply having to provide an alternative for this single function
if needed.
Also, it may (depending on the number of callers,
which is on the low side here unfortunately)
reduce instruction cac
Hi,
On Sun, Jul 20, 2014 at 12:42:53PM +0200, Peter Feuerer wrote:
> Hi Andreas,
>
> Andreas Mohr writes:
> >On Sun, Jul 20, 2014 at 02:51:15AM +0200, Peter Feuerer wrote:
> >>@@ -127,105 +138,107 @@ struct bios_settings_t {
> >>unsigned char fanr
on PL2303HX currently.
quite likely a
depends on GPIOLIB && ...
is missing here (as is done with several other GPIO support drivers
in the same Kconfig)
Thanks for this nicely functionality-enhancing serial driver addition,
Andreas Mohr
--
To unsubscribe from this list: s
Hi,
On Sun, Jul 20, 2014 at 02:51:15AM +0200, Peter Feuerer wrote:
> @@ -127,105 +138,107 @@ struct bios_settings_t {
> unsigned char fanreg;
> unsigned char tempreg;
> struct fancmd cmd;
> + int mcmd_enable;
> };
>
> +
> /* Register addresses and values for different BIO
esystems may be modiyfing multiple blocks
^^^
> +within a single transaction, so keeping the buffer heads in
> +CPU-local cache speeds up modifations significantly.
^^
Thanks for this nice optimization,
On Sun, Jun 29, 2014 at 12:59:41PM +0400, Kirill Tkhai wrote:
> On 29.06.2014 12:36, Andreas Mohr wrote:
> > I just noticed that there is a part touching rq->idle,
> > and ISTR that idle task handling is "special"
> > (after all that's the power managemen
king here
(unless this cleanup happens to unify handling here anyway).
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
when calling resched_task()
could prompt a rethinking of relationship of task vs. rq,
since by clearing up (and focussing on) design intentions,
one could "automatically" end up
with more elegant and thus better function implementations.
Thank you for your activities in the scheduler are
valuation yet though.
Thanks again,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
hunk of the small but quite likely useful change
that you currently intend to have here.
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
Hi,
On Mon, Apr 28, 2014 at 01:13:19AM +0200, Peter Feuerer wrote:
> Hi,
>
> Andreas Mohr writes:
>
> > { "Acer", "AOA1", &aao_reg_map_AOAxxx_Acer_orig_version },
> >
> > Of course you then have the indirection of device name <->
"didn't get bang-bang,
since perhaps not compiled into thermal subsystem").
> Please test/review the patches and send me your comments.
-ENODATA (my crappy JMicron JMF601 SSD had managed to break again,
this time with fatal firmware corruption, so I had to reflash
sers and some others might be sharing my thoughts).
IOW, my r128 driver is somewhat of a "still used driver", thank you very much.
Thanks for having managed to survive my posting in an asbestos-lined
garment (apologies if it came across in harsh terms :),
Andreas Mohr
(not necessarily
ure that that modified scheduler implementation
gets chosen.
HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr wrote:
> >
> > which did end up flawless on 3.12.0-rc2+, too
> > (but failed to improve the issue on 3.14.0-rc7+).
> >
> > So, for all intents and p
Hi,
On Sun, Mar 23, 2014 at 12:43:17AM +0100, Andreas Mohr wrote:
> Hi,
>
> now testing 3.14-rc7 here (r128 hardware rather than MGA),
> and I seem to still be experiencing the same or very similar crash as you
> here:
I decided to do some more experimentation:
I added a
n1:i386 2.4.45-3 i386
Userspace interface to radeon-specific kernel DRM services -- runtime
ii libdrm2:i386 2.4.45-3 i386
Userspace interface to kernel DRM services -- runtime
So, &q
ingers? ;)
While that was slightly disheartening, thanks for the very fast clarification,
Dave et al.!
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
ig or even fully runtime-detectable boot switching to
(non-)PAE, similar to or exceeding what XP offers with its static
boot-time flag?
Last time I checked PAE support config defines were spread over ~ 40
kernel source files though :-((()
Andreas Mohr
--
To unsubscribe from this list: sen
non-mainline
kernel version - mainly submitting this as a "data item"
for other people to research and possibly extend
(and not even sure whether this is a kernel issue,
or rather a hardware mishap instead).
keywords: kernel i8042 apic irq lockup keyboard optiplex dell
Thanks,
Andreas Mo
certain other devices producing activity (FTDI RS232, X10 lirc remote).
H (any interesting thoughts?),
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
ou can see above as well, LIB80211_DEBUG decided to be
a law-abiding citizen, by caring to announce a proper dependency on LIB80211.
Happened on OpenWrt's 3.10.24, and verified Kconfig status to still be
identical on linux trunk.
Thanks,
Andreas Mohr
--
GNU/Linux. It's not the software
n in recent times the kernel did not manage to achieve that goal,
for several use cases. But I'm quite certain we're getting closer :)
BTW, a quite likely related and possibly helpful topic is
"[patch 7/9] mm: thrash detection-based file cache sizing"
https://lkml.org/lkml/2013/
me benchmarking activities might be able to provide more details
(e.g. hdparm -tT, bonnie++ results, memory performance tests, etc.).
cat /proc/slabinfo
ought to provide an initial overview of which cache elements
manage to keep the largest memory areas in service.
HTH,
Andreas Mohr
--
To unsu
nally get that f***in' thing to boot properly).
Also, you should make sure to be using the EDD BIOS service (see modinfo edd),
for the kernel to be able to forward actual BIOS-side drive geometry
information.
Another way to be gathering a geometry is by parsing geometry output
of fdisk / cfdisk
?
Try
make M=sound/pci modules
(and perhaps followed by modules_install, too)
or perhaps even simply
make drivers/char/rtc.ko
I'm working on extending some relevant docs, too, but don't hold your breath...
(slowly but surely extending my local git data store)
Andreas Mohr
--
To unsubscr
On Mon, Nov 04, 2013 at 06:34:23PM +0100, Frederic Weisbecker wrote:
> On Sun, Oct 20, 2013 at 01:10:06PM +0200, Andreas Mohr wrote:
> > In case of high update traffic of parts guarded by rq->iowait_lock
> > (is that a relevant case?),
> >
> > it might be useful to m
Hi,
> May I can use the ''double" as a basic variables?
[see other replies]
Look into terminus technicus "scaling math" as a replacement technique
(in-kernel this is being used e.g. by clocksources/clockevents).
HTH,
Andreas Mohr
--
To unsubscribe from this list
e update less
than is already available.
Thank you very much for working on improving this important infrastructure code!
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
uent 3/5 patch, within the series?
Unless I missed some other restrictions which cause us to need to cling
to that manual from-us conversion, for now or forever...
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
lly I do favour u8, since "char" seems so unsuitably stringy -
but the prototype currently doesn't offer it typed that way...
(Almost-)Reviewed-By: Andreas Mohr
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On Sun, Sep 15, 2013 at 11:04:26PM +0200, Ondrej Zary wrote:
> On Sunday 15 September 2013 22:35:20 Andreas Mohr wrote:
> > What!?!? I didn't quite expect any kernel dev to have that one, too ;)
>
> Don't remember where I got it from but it looked nice so I bought it :)
Hi,
On Sun, Sep 15, 2013 at 10:25:45PM +0200, Ondrej Zary wrote:
> On Sunday 15 September 2013 20:49:02 Andreas Mohr wrote:
> BTW. I've got an AZT3328 card and it works fine with your driver. Thanks for
> it.
What!?!? I didn't quite expect any kernel dev to have that one, t
ssor found!"?)
((or "Detected ..."))
> + /* try to read a register to detect chip presence */
> + if (snd_es938_read_reg(chip, ES938_REG_MISC, NULL) < 0)
> + return -ENODEV;
Perhaps that check is not specific enough, i.e. it might be useful
to figure
1 - 100 of 228 matches
Mail list logo
