On Tue, Jan 24, 2017 at 10:58 AM, Sylvain Munaut
wrote:
> Previously the order described in the comment wasn't the actual
> order that was considered. And the result also depended on the orders
> of the various ID in the pg83 data.
>
> Signed-off-by: Sylvain Munaut
&
Previously the order described in the comment wasn't the actual
order that was considered. And the result also depended on the orders
of the various ID in the pg83 data.
Signed-off-by: Sylvain Munaut
---
drivers/scsi/scsi_lib.c | 25 ++---
1 file changed, 10 inser
t didn't want to loose my time if I
misunderstood).
Cheers,
Sylvain Munaut
Hi Jan,
> See https://patchwork.kernel.org/patch/9281193/.
Thanks for the pointer !
I had checked the kernel git tree for a potential fix, but didn't
think of patchwork.
Cheers,
Sylvain Munaut
= 0x1905000
rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7fe4dd98e0e0},
{SIG_DFL, [], 0}, 8) = 0
write(3, "\1\0\0\0\0\0\0\0\0\0\0\0\2\0\0\0", 16) = 16
write(3, "/\0", 2) = -1 ESRCH (No such process)
So either what xenstore-ls does is invalid, or that condition
requiring a transaction is too strict.
Or am I missing something here ?
Cheers,
Sylvain Munaut
Hi,
>> Can you verify that reverting this patch (on top of 4.4?) fixes it?
>>
>> If so, is it time to revert it?
>>
>> Thanks,
>> Pavel
>
> It's highly unlikely you'll be able to revert this on top of 4.4.
> Unfortunately,
> th
Hi,
> I then ran a git bissect between v4.0 and v4.1 from Linus's tree and
> found the "guilty" commit was
>
> commit 317b4e903636305cfe702ab3e5b3d68547a69e72
> Author: Ben Widawsky
> Date: Mon Mar 16 16:00:55 2015 +
>
> drm/i915: Extract context switch skip and add pd load logic
Damni
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
RTS5227 PCI Express Card Reader (rev 01)
03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83)
04:00.0 VGA compatible controller: NVIDIA Corporation GK208M [GeForce
GT 730M] (rev a1)
Cheers,
Sylvain Munaut
--
Hi,
>> Sylvan Munaut did something similar
>> https://lkml.org/lkml/2012/12/5/168
>
> Missed that and duplicated the debugging :(
> Sorry Sylvain.
I should have followed up on the patch sooner, but I basically
finished testing it fixed all the issues and posted it just before
leaving for vacation
onger
segfaulted and also by checking that before this patch the
buffer was overrun by exactly the number of char corresponding to
extra digits in the timestamps.
Cc: Kay Sievers
Cc: sta...@kernel.org
Signed-off-by: Sylvain Munaut
---
kernel/printk.c | 13 +++--
1 file changed, 11 i
The "%5lu" part of the sprintf only guarantees a minimum length,
not a maximum one. This patch should make it correct for any
possible timestamp.
Signed-off-by: Sylvain Munaut
---
kernel/printk.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --gi
Hi,
> It happens on several machines and this only seem to happen if there
> was a wrap around in the log buffer (it's a first observation on a
> limited number of sample so it might be a coincidence)
I think the culprit is print_time and has nothing to do with wrap
around, just the uptime.
stat
Hi,
I was debugging a segfault in the 'dmesg' utility that I finally
traced to the syslog syscall overflowing the buffer.
I'm under a 3.6.8 kernel and it has commit
e3756477aec028427fec767957c0d4b6cfb87208 present which apparently
fixed a similar issue, but I still have some occurence.
strace dme
Hoang-Nam Nguyen wrote:
> This patch replaces ibmebus_uevent() by Sylvain's generic function.
>
> struct bus_type ibmebus_bus_type = {
> - .name = "ibmebus",
> - .uevent = ibmebus_uevent,
> - .match = ibmebus_bus_match,
> + .name = "ibmebus",
> + .uevent = of_device_uevent,
>
Hoang-Nam Nguyen wrote:
> Additionally, the uevent interface is now implemented in the driver.
>
Mmmh, I posted a patch that added a common uevent interface for all
of_device based
bus. And that kinda clash with this one.
I think it's a much cleaner approach to make it as common as possible.
Bu
Benjamin Herrenschmidt wrote:
> On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote:
>> On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote:
>>> On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote:
>>>> Don't build ohci as module for now
David Woodhouse wrote:
> On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote:
>
>> Sylvain fixes are. My endian patches are for ps3 and toshiba celleb,
>> none of which is fully merged in 2.6.20 so they are fine to wait. It's
>> mostly a matter of being a PITA to rebase Sylvain stuff
ndler is installed.
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>
Acked-by: Sylvain Munaut <[EMAIL PROTECTED]>
Definitly fixed the spurious warning.
Sylvain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
Hello,
I'd like to obtain some minor device number and I'm not sure how to do
so. I've seen that a request must be sent to [EMAIL PROTECTED], and I've
done it, following the instructions (I think). I've sent it twice, a
first time two month ago, then again a little less than a month ago.
Each time
Kumar Gala wrote:
diff -Nru a/arch/ppc/syslib/mpc52xx_pic.c
b/arch/ppc/syslib/mpc52xx_pic.c
--- a/arch/ppc/syslib/mpc52xx_pic.c 2005-03-11 20:41:36 +01:00
+++ b/arch/ppc/syslib/mpc52xx_pic.c 2005-03-11 20:41:36 +01:00
@@ -33,8 +33,8 @@
#include
-static struct mpc52xx_intr *intr;
ed to be due to hardware issues.
#
# Signed-off-by: Sylvain Munaut <[EMAIL PROTECTED]>
#
# arch/ppc/syslib/mpc52xx_pci.h
# 2005/03/11 19:57:56+01:00 [EMAIL PROTECTED] +139 -0
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# include/linux/pci_ids.h
# 2005/03/11 19:57:56+01:00 [E
Hi Tom & all
Here's some updates related to the Freescale MPC52xx. First some
clean-ups for sparse warnings and then PCI support. I'd like to get
theses approved & merged before I submit conversion to platform bus
model.
As usual, the patches can also be pulled of a bk repository :
bk://tnt.bkbits.
Benjamin Herrenschmidt wrote:
On Sun, 2005-01-23 at 11:43 +1100, Benjamin Herrenschmidt wrote:
I know about this problem, I'm working on a proper fix. Thanks for your
report.
Can you send me the PVR value for both of these CPUs
(cat /proc/cpuinfo) ? I can't find right now why they would loc
23 matches
Mail list logo
