[tip: core/rcu] torture: Provide bare-metal modprobe-based advice

Committer: Paul E. McKenney CommitterDate: Mon, 08 Mar 2021 14:23:01 -08:00 torture: Provide bare-metal modprobe-based advice In some environments, the torture-testing use of virtualization is inconvenient. In such cases, the modprobe and rmmod commands may be used to do torture testing

[PATCH tip/core/rcu 03/28] torture: Provide bare-metal modprobe-based advice

args="`configfrag_boot_params "$boot_args_in" "$config_template"`" # Generate kernel-version-specific boot parameters boot_args="`per_version_boot_params "$boot_args" $resdir/.config $seconds`" if test -n "$TORTURE_BOOT_GDB_ARG" t

Re: [PATCH] EDAC, {skx, i10nm}: Advice mcelog that the error were handled

otifier_block *nb, > unsigned long val, > > skx_mce_output_error(mci, mce, ); > > - return NOTIFY_DONE; > + /* Advice mcelog that the error were handled */ ... error was ... And make a sentence out of it, so close with a dot. > + return NOTIFY_STOP; This change a

Re: [PATCH] EDAC, {skx,i10nm}: Advice mcelog that the error were handled

++ b/drivers/edac/skx_common.c > > @@ -615,7 +615,8 @@ int skx_mce_check_error(struct notifier_block *nb, > > unsigned long val, > > > > skx_mce_output_error(mci, mce, ); > > > > - return NOTIFY_DONE; > > + /* Advice mcelog that the er

Re: [PATCH] EDAC, {skx,i10nm}: Advice mcelog that the error were handled

long val, > > skx_mce_output_error(mci, mce, ); > > - return NOTIFY_DONE; > + /* Advice mcelog that the error were handled */ > + return NOTIFY_STOP; > } > > void skx_remove(void) > -- No, we won't be doing that anymore. See here: https://git.k

[PATCH] EDAC, {skx,i10nm}: Advice mcelog that the error were handled

46be1a7..8c0165b 100644 --- a/drivers/edac/skx_common.c +++ b/drivers/edac/skx_common.c @@ -615,7 +615,8 @@ int skx_mce_check_error(struct notifier_block *nb, unsigned long val, skx_mce_output_error(mci, mce, ); - return NOTIFY_DONE; + /* Advice mcelog that the error were handled

[tip:perf/core] perf trace: Wire up the fadvise 'advice' table generator

perf trace: Wire up the fadvise 'advice' table generator That ends up generating this: $ cat /tmp/build/perf/trace/beauty/generated/fadvise_advice_array.c static const char *fadvise_advices[] = { [0] = "NORMAL", [1] = "RANDOM", [2] = &quo

[tip:perf/core] perf beauty: Add generator for fadvise64's 'advice' arg constants

perf beauty: Add generator for fadvise64's 'advice' arg constants $ tools/perf/trace/beauty/fadvise.sh static const char *fadvise_advices[] = { [0] = "NORMAL", [1] = "RANDOM", [2] = "SEQUENTIAL", [3] = "WILLNEED",

[PATCH 60/63] perf beauty: Add generator for fadvise64's 'advice' arg constants

From: Arnaldo Carvalho de Melo $ tools/perf/trace/beauty/fadvise.sh static const char *fadvise_advices[] = { [0] = "NORMAL", [1] = "RANDOM", [2] = "SEQUENTIAL", [3] = "WILLNEED", [4] = "DONTNEED", [5] = "NOREUSE", }; $ This has a hack wrt

[PATCH 61/63] perf trace: Wire up the fadvise 'advice' table generator

From: Arnaldo Carvalho de Melo That ends up generating this: $ cat /tmp/build/perf/trace/beauty/generated/fadvise_advice_array.c static const char *fadvise_advices[] = { [0] = "NORMAL", [1] = "RANDOM", [2] = "SEQUENTIAL", [3] = "WILLNEED", [4] =

[PATCH tip/core/rcu 8/9] rcu: Add extended-quiescent-state testing advice

If you add or remove calls to rcu_idle_enter(), rcu_user_enter(), rcu_irq_exit(), rcu_irq_exit_irqson(), rcu_idle_exit(), rcu_user_exit(), rcu_irq_enter(), rcu_irq_enter_irqson(), rcu_nmi_enter(), or rcu_nmi_exit(), you should run a full set of tests on a kernel built with CONFIG_RCU_EQS_DEBUG=y.

[PATCH tip/core/rcu 8/9] rcu: Add extended-quiescent-state testing advice

If you add or remove calls to rcu_idle_enter(), rcu_user_enter(), rcu_irq_exit(), rcu_irq_exit_irqson(), rcu_idle_exit(), rcu_user_exit(), rcu_irq_enter(), rcu_irq_enter_irqson(), rcu_nmi_enter(), or rcu_nmi_exit(), you should run a full set of tests on a kernel built with CONFIG_RCU_EQS_DEBUG=y.

Re: CLK_OF_DECLARE advice required

On 06/06, Geert Uytterhoeven wrote: > Hi Stephen, > > On Mon, Jun 5, 2017 at 10:13 PM, Stephen Boyd wrote: > > On 06/05, Phil Elwell wrote: > >> That sounds great, but it doesn't match my experience. Let me restate my > >> observations with a bit more detail. > >> > >> In

Re: CLK_OF_DECLARE advice required

On 06/06, Geert Uytterhoeven wrote: > Hi Stephen, > > On Mon, Jun 5, 2017 at 10:13 PM, Stephen Boyd wrote: > > On 06/05, Phil Elwell wrote: > >> That sounds great, but it doesn't match my experience. Let me restate my > >> observations with a bit more detail. > >> > >> In this scenario there

Re: CLK_OF_DECLARE advice required

On 05/06/2017 21:13, Stephen Boyd wrote: > On 06/05, Phil Elwell wrote: >> That sounds great, but it doesn't match my experience. Let me restate my >> observations with a bit more detail. >> >> In this scenario there three devices in a dependency chain: >> >> clock -> fixed-factor->clock ->

Re: CLK_OF_DECLARE advice required

On 05/06/2017 21:13, Stephen Boyd wrote: > On 06/05, Phil Elwell wrote: >> That sounds great, but it doesn't match my experience. Let me restate my >> observations with a bit more detail. >> >> In this scenario there three devices in a dependency chain: >> >> clock -> fixed-factor->clock ->

Re: CLK_OF_DECLARE advice required

Hi Stephen, On Mon, Jun 5, 2017 at 10:13 PM, Stephen Boyd wrote: > On 06/05, Phil Elwell wrote: >> That sounds great, but it doesn't match my experience. Let me restate my >> observations with a bit more detail. >> >> In this scenario there three devices in a dependency

Re: CLK_OF_DECLARE advice required

Hi Stephen, On Mon, Jun 5, 2017 at 10:13 PM, Stephen Boyd wrote: > On 06/05, Phil Elwell wrote: >> That sounds great, but it doesn't match my experience. Let me restate my >> observations with a bit more detail. >> >> In this scenario there three devices in a dependency chain: >> >> clock ->

Re: CLK_OF_DECLARE advice required

On 06/05, Phil Elwell wrote: > That sounds great, but it doesn't match my experience. Let me restate my > observations with a bit more detail. > > In this scenario there three devices in a dependency chain: > > clock -> fixed-factor->clock -> uart. > > The Fixed Factor Clock is declared with

Re: CLK_OF_DECLARE advice required

On 06/05, Phil Elwell wrote: > That sounds great, but it doesn't match my experience. Let me restate my > observations with a bit more detail. > > In this scenario there three devices in a dependency chain: > > clock -> fixed-factor->clock -> uart. > > The Fixed Factor Clock is declared with

Re: CLK_OF_DECLARE advice required

On 02/06/2017 23:34, Stephen Boyd wrote:> On 06/01, Phil Elwell wrote: >> On 01/06/2017 07:39, Stephen Boyd wrote: >>> On 05/31, Phil Elwell wrote: For my edification, can you pretend for a moment that the application was a valid one and answer any of my original questions?:

Re: CLK_OF_DECLARE advice required

On 02/06/2017 23:34, Stephen Boyd wrote:> On 06/01, Phil Elwell wrote: >> On 01/06/2017 07:39, Stephen Boyd wrote: >>> On 05/31, Phil Elwell wrote: For my edification, can you pretend for a moment that the application was a valid one and answer any of my original questions?:

Re: CLK_OF_DECLARE advice required

On 06/01, Phil Elwell wrote: > On 01/06/2017 07:39, Stephen Boyd wrote: > > On 05/31, Phil Elwell wrote: > >> For my edification, can you pretend for a moment that the application was > >> a valid one and > >> answer any of my original questions?: > >> > >> 1. Should all system clock drivers use

Re: CLK_OF_DECLARE advice required

On 06/01, Phil Elwell wrote: > On 01/06/2017 07:39, Stephen Boyd wrote: > > On 05/31, Phil Elwell wrote: > >> For my edification, can you pretend for a moment that the application was > >> a valid one and > >> answer any of my original questions?: > >> > >> 1. Should all system clock drivers use

Re: CLK_OF_DECLARE advice required

; >>>>> I've run into a problem using the fixed-factor clock on Raspberry Pi >>>>> and I'd >>>>> like some advice before I submit a patch. >>>>> >>>>> Some context: the aim is to use a standard UART and some external >>

Re: CLK_OF_DECLARE advice required

; >>>>> I've run into a problem using the fixed-factor clock on Raspberry Pi >>>>> and I'd >>>>> like some advice before I submit a patch. >>>>> >>>>> Some context: the aim is to use a standard UART and some external >>

Re: CLK_OF_DECLARE advice required

or clock on Raspberry Pi > >>> and I'd > >>> like some advice before I submit a patch. > >>> > >>> Some context: the aim is to use a standard UART and some external > >>> circuitry > >>> as a MIDI interface. This would be straigh

Re: CLK_OF_DECLARE advice required

or clock on Raspberry Pi > >>> and I'd > >>> like some advice before I submit a patch. > >>> > >>> Some context: the aim is to use a standard UART and some external > >>> circuitry > >>> as a MIDI interface. This would be straigh

Re: CLK_OF_DECLARE advice required

On 05/31/2017 10:28 AM, Phil Elwell wrote: On 31/05/2017 16:58, Stefan Wahren wrote: Am 31.05.2017 um 17:27 schrieb Stephen Warren: On 05/30/2017 06:23 AM, Phil Elwell wrote: Hi, I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd like some advice before I submit

Re: CLK_OF_DECLARE advice required

On 05/31/2017 10:28 AM, Phil Elwell wrote: On 31/05/2017 16:58, Stefan Wahren wrote: Am 31.05.2017 um 17:27 schrieb Stephen Warren: On 05/30/2017 06:23 AM, Phil Elwell wrote: Hi, I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd like some advice before I submit

Re: CLK_OF_DECLARE advice required

On 31/05/2017 16:58, Stefan Wahren wrote: > Am 31.05.2017 um 17:27 schrieb Stephen Warren: >> On 05/30/2017 06:23 AM, Phil Elwell wrote: >>> Hi, >>> >>> I've run into a problem using the fixed-factor clock on Raspberry Pi >>> and I'd >>>

Re: CLK_OF_DECLARE advice required

On 31/05/2017 16:58, Stefan Wahren wrote: > Am 31.05.2017 um 17:27 schrieb Stephen Warren: >> On 05/30/2017 06:23 AM, Phil Elwell wrote: >>> Hi, >>> >>> I've run into a problem using the fixed-factor clock on Raspberry Pi >>> and I'd >>>

Re: CLK_OF_DECLARE advice required

Am 31.05.2017 um 17:27 schrieb Stephen Warren: > On 05/30/2017 06:23 AM, Phil Elwell wrote: >> Hi, >> >> I've run into a problem using the fixed-factor clock on Raspberry Pi >> and I'd >> like some advice before I submit a patch. >> >> Some contex

Re: CLK_OF_DECLARE advice required

Am 31.05.2017 um 17:27 schrieb Stephen Warren: > On 05/30/2017 06:23 AM, Phil Elwell wrote: >> Hi, >> >> I've run into a problem using the fixed-factor clock on Raspberry Pi >> and I'd >> like some advice before I submit a patch. >> >> Some contex

Re: CLK_OF_DECLARE advice required

On 05/30/2017 06:23 AM, Phil Elwell wrote: Hi, I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd like some advice before I submit a patch. Some context: the aim is to use a standard UART and some external circuitry as a MIDI interface. This would be straightforward

Re: CLK_OF_DECLARE advice required

On 05/30/2017 06:23 AM, Phil Elwell wrote: Hi, I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd like some advice before I submit a patch. Some context: the aim is to use a standard UART and some external circuitry as a MIDI interface. This would be straightforward

CLK_OF_DECLARE advice required

Hi, I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd like some advice before I submit a patch. Some context: the aim is to use a standard UART and some external circuitry as a MIDI interface. This would be straightforward except that Linux doesn't recognise

CLK_OF_DECLARE advice required

Hi, I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd like some advice before I submit a patch. Some context: the aim is to use a standard UART and some external circuitry as a MIDI interface. This would be straightforward except that Linux doesn't recognise

Re: [PATCH v3] virtio-net: Add initial MTU advice feature

; @@ -55,6 +55,7 @@ > #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow >* Steering */ > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23/* Set MAC address */ > +#define VIRTIO_NET_F_MTU 25 /* Initial MTU advice */ > > #if

Re: [PATCH v3] virtio-net: Add initial MTU advice feature

efine VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow >* Steering */ > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23/* Set MAC address */ > +#define VIRTIO_NET_F_MTU 25 /* Initial MTU advice */ > > #ifndef VIRTIO_NET_NO_LEGAC

Re: [PATCH v3] virtio-net: Add initial MTU advice feature

From: Aaron Conole Date: Fri, 3 Jun 2016 16:57:12 -0400 > This commit adds the feature bit and associated mtu device entry for the > virtio network device. When a virtio device comes up, it checks the > feature bit for the VIRTIO_NET_F_MTU feature. If such feature bit is >

Re: [PATCH v3] virtio-net: Add initial MTU advice feature

From: Aaron Conole Date: Fri, 3 Jun 2016 16:57:12 -0400 > This commit adds the feature bit and associated mtu device entry for the > virtio network device. When a virtio device comes up, it checks the > feature bit for the VIRTIO_NET_F_MTU feature. If such feature bit is > enabled, the driver

[PATCH v3] virtio-net: Add initial MTU advice feature

/virtio_net.h @@ -55,6 +55,7 @@ #define VIRTIO_NET_F_MQ22 /* Device supports Receive Flow * Steering */ #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ +#define VIRTIO_NET_F_MTU 25/* Initial MTU advice */ #ifndef VIRTIO_NET_NO_

[PATCH v3] virtio-net: Add initial MTU advice feature

#define VIRTIO_NET_F_MQ22 /* Device supports Receive Flow * Steering */ #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ +#define VIRTIO_NET_F_MTU 25/* Initial MTU advice */ #ifndef VIRTIO_NET_NO_LEGACY #define VIRTIO_NET_F_GSO

Re: [PATCH v2 -next] virtio-net: Add initial MTU advice feature

et.h > @@ -55,6 +55,7 @@ > #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow > * Steering */ > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23/* Set MAC address */ > +#define VIRTIO_NET_F_MTU 25 /* Initial MTU advice */ > > #ifndef VI

Re: [PATCH v2 -next] virtio-net: Add initial MTU advice feature

efine VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow > * Steering */ > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23/* Set MAC address */ > +#define VIRTIO_NET_F_MTU 25 /* Initial MTU advice */ > > #ifndef VIRTIO_NET_NO_LEGAC

[PATCH v2 -next] virtio-net: Add initial MTU advice feature

ce supports Receive Flow * Steering */ #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ +#define VIRTIO_NET_F_MTU 25 /* Initial MTU advice */ #ifndef VIRTIO_NET_NO_LEGACY #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */

[PATCH v2 -next] virtio-net: Add initial MTU advice feature

ports Receive Flow * Steering */ #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ +#define VIRTIO_NET_F_MTU 25 /* Initial MTU advice */ #ifndef VIRTIO_NET_NO_LEGACY #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */ @@ -73,6 +74,8 @@ struct

Seeking advice for first driver

f (req && (timeout || RX_BUF_LEVEL >= req)) { req = 0; DISABLE_TIMEOUT; complete(); } } AFAICT, there are no problematic races... Anyway, if anyone's read this far, well thanks first of all ;-) If you have advice, comments, suggestions, I'd love to hear them. Regards. -- To

Seeking advice for first driver

; DISABLE_TIMEOUT; complete(done); } } AFAICT, there are no problematic races... Anyway, if anyone's read this far, well thanks first of all ;-) If you have advice, comments, suggestions, I'd love to hear them. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-kernel

I Need Your Advice To Invest In your Country.

Hello my dear Please this is a personal message for you,I need some directives from you to invest some capital in your country. And see how we can partnership into the business. Just reply me to explain better. Mrs.Anera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

I Need Your Advice To Invest In your Country.

Hello my dear Please this is a personal message for you,I need some directives from you to invest some capital in your country. And see how we can partnership into the business. Just reply me to explain better. Mrs.Anera -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

On Mon, 2014-12-15 at 14:59 +0300, Dan Carpenter wrote: > I prefer !foo because it is more common in the kernel and I think it's > easier to read but I don't feel strongly about this. Me too. But I do prefer consistency. fyi: for variants of: "if (!foo)" vs "if (foo == NULL)"

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

Dan, On Mon, Dec 15, 2014 at 04:43:34PM +0300, Dan Carpenter wrote: > On Mon, Dec 15, 2014 at 05:03:46AM -0800, Jeremiah Mahler wrote: > > > > Or another way mentioned in K that produces a compile error > > > > if (NULL = x) > > > > Yes. People used to write Yoda code back in

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

On Mon, Dec 15, 2014 at 05:03:46AM -0800, Jeremiah Mahler wrote: > > Or another way mentioned in K that produces a compile error > > if (NULL = x) > Yes. People used to write Yoda code back in the day. Don't ever do this in the kernel. 1) It looks stupid. 2) GCC will catch most

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

On Mon, Dec 15, 2014 at 11:44:21AM +, One Thousand Gnomes wrote: > On Sat, 13 Dec 2014 11:46:47 -0800 > Jeremiah Mahler wrote: > > > Loïc, > > > > On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote: > > > > Whose convention is this? I can't find any mention in > > > >

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

I haven't seen any bugs caused by lack of type safety with "!foo"... I prefer !foo because it is more common in the kernel and I think it's easier to read but I don't feel strongly about this. I kind of hate "if (foo != NULL) though, because it's a double negative. But I really hate when people

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

On Sat, 13 Dec 2014 11:46:47 -0800 Jeremiah Mahler wrote: > Loïc, > > On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote: > > > Whose convention is this? I can't find any mention in > > > Documention/CodingStyle. checkpatch.pl doesn't complain about them. > > > And there are

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

On Sat, 13 Dec 2014 11:46:47 -0800 Jeremiah Mahler jmmah...@gmail.com wrote: Loïc, On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote: Whose convention is this? I can't find any mention in Documention/CodingStyle. checkpatch.pl doesn't complain about them. And there are

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

I haven't seen any bugs caused by lack of type safety with !foo... I prefer !foo because it is more common in the kernel and I think it's easier to read but I don't feel strongly about this. I kind of hate if (foo != NULL) though, because it's a double negative. But I really hate when people

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

On Mon, Dec 15, 2014 at 11:44:21AM +, One Thousand Gnomes wrote: On Sat, 13 Dec 2014 11:46:47 -0800 Jeremiah Mahler jmmah...@gmail.com wrote: Loïc, On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote: Whose convention is this? I can't find any mention in

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

On Mon, Dec 15, 2014 at 05:03:46AM -0800, Jeremiah Mahler wrote: Or another way mentioned in KR that produces a compile error if (NULL = x) Yes. People used to write Yoda code back in the day. Don't ever do this in the kernel. 1) It looks stupid. 2) GCC will catch most ==

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

Dan, On Mon, Dec 15, 2014 at 04:43:34PM +0300, Dan Carpenter wrote: On Mon, Dec 15, 2014 at 05:03:46AM -0800, Jeremiah Mahler wrote: Or another way mentioned in KR that produces a compile error if (NULL = x) Yes. People used to write Yoda code back in the day.

Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)

On Mon, 2014-12-15 at 14:59 +0300, Dan Carpenter wrote: I prefer !foo because it is more common in the kernel and I think it's easier to read but I don't feel strongly about this. Me too. But I do prefer consistency. fyi: for variants of: if (!foo) vs if (foo == NULL) a

Re: [RFC PATCH 1/5] block, ioprio: include caching advice via ionice

On Wed, Oct 29, 2014 at 12:02 PM, Jeff Moyer wrote: > "Jason B. Akers" writes: > >> From: Dan Williams >> >> Steal one unused bit from the priority class and two bits from the >> priority data, to implement a 3 bit cache-advice field. Similar

Re: [RFC PATCH 1/5] block, ioprio: include caching advice via ionice

"Jason B. Akers" writes: > From: Dan Williams > > Steal one unused bit from the priority class and two bits from the > priority data, to implement a 3 bit cache-advice field. Similar to the > page cache advice from fadvise() these hints are meant to be consumed > by

[RFC PATCH 1/5] block, ioprio: include caching advice via ionice

From: Dan Williams Steal one unused bit from the priority class and two bits from the priority data, to implement a 3 bit cache-advice field. Similar to the page cache advice from fadvise() these hints are meant to be consumed by hybrid drives. Solid State Hyrbid-Drives, as defined by the SATA

[RFC PATCH 1/5] block, ioprio: include caching advice via ionice

From: Dan Williams dan.j.willi...@intel.com Steal one unused bit from the priority class and two bits from the priority data, to implement a 3 bit cache-advice field. Similar to the page cache advice from fadvise() these hints are meant to be consumed by hybrid drives. Solid State Hyrbid-Drives

Re: [RFC PATCH 1/5] block, ioprio: include caching advice via ionice

Jason B. Akers jason.b.ak...@intel.com writes: From: Dan Williams dan.j.willi...@intel.com Steal one unused bit from the priority class and two bits from the priority data, to implement a 3 bit cache-advice field. Similar to the page cache advice from fadvise() these hints are meant

Re: [RFC PATCH 1/5] block, ioprio: include caching advice via ionice

On Wed, Oct 29, 2014 at 12:02 PM, Jeff Moyer jmo...@redhat.com wrote: Jason B. Akers jason.b.ak...@intel.com writes: From: Dan Williams dan.j.willi...@intel.com Steal one unused bit from the priority class and two bits from the priority data, to implement a 3 bit cache-advice field. Similar

Advice from Kernel Newbies

Hey Guys, I got some great advice from the kernel newbies list and would like to start out fresh and willing to listen to your advice. If anyone in the scheduler subsystem has so basic work for me to start in, I will search around on the list first but this is just in case I don't find anytime. I

Advice from Kernel Newbies

Hey Guys, I got some great advice from the kernel newbies list and would like to start out fresh and willing to listen to your advice. If anyone in the scheduler subsystem has so basic work for me to start in, I will search around on the list first but this is just in case I don't find anytime. I

Build Tests Advice

Hey Steven , I am finding it rather annoying that you aren't replying to my messages about succeeding builds. I am tried repeatedly to ask you to try a new compiler and or build system as all most of the failing builds succeed for me. It would be nice to get a reply in the next few days. Cheers

Build Tests Advice

Hey Steven , I am finding it rather annoying that you aren't replying to my messages about succeeding builds. I am tried repeatedly to ask you to try a new compiler and or build system as all most of the failing builds succeed for me. It would be nice to get a reply in the next few days. Cheers

Re: Crash in rbd, need advice

On Fri, Apr 4, 2014 at 3:10 PM, Ilya Dryomov wrote: > On Fri, Apr 4, 2014 at 4:25 PM, Hannes Landeholm > wrote: >> On Fri, Apr 4, 2014 at 1:08 PM, Ilya Dryomov >> wrote: >>> On Wed, Apr 2, 2014 at 12:18 AM, Hannes Landeholm >>> wrote: Hello, We're running a couple of Arch

Re: Crash in rbd, need advice

On Fri, Apr 4, 2014 at 4:25 PM, Hannes Landeholm wrote: > On Fri, Apr 4, 2014 at 1:08 PM, Ilya Dryomov wrote: >> On Wed, Apr 2, 2014 at 12:18 AM, Hannes Landeholm >> wrote: >>> Hello, >>> >>> We're running a couple of Arch Linux servers of version 3.13.5-1 in >>> production and suddenly one of

Re: Crash in rbd, need advice

On Fri, Apr 4, 2014 at 1:08 PM, Ilya Dryomov wrote: > On Wed, Apr 2, 2014 at 12:18 AM, Hannes Landeholm > wrote: >> Hello, >> >> We're running a couple of Arch Linux servers of version 3.13.5-1 in >> production and suddenly one of them had a strange problem after >> running for a few days. One

Re: Crash in rbd, need advice

On Wed, Apr 2, 2014 at 12:18 AM, Hannes Landeholm wrote: > Hello, > > We're running a couple of Arch Linux servers of version 3.13.5-1 in > production and suddenly one of them had a strange problem after > running for a few days. One process (pid 319) was running with a few > threads, one of

Re: Crash in rbd, need advice

On Wed, Apr 2, 2014 at 12:18 AM, Hannes Landeholm han...@jumpstarter.io wrote: Hello, We're running a couple of Arch Linux servers of version 3.13.5-1 in production and suddenly one of them had a strange problem after running for a few days. One process (pid 319) was running with a few

Re: Crash in rbd, need advice

On Fri, Apr 4, 2014 at 1:08 PM, Ilya Dryomov ilya.dryo...@inktank.com wrote: On Wed, Apr 2, 2014 at 12:18 AM, Hannes Landeholm han...@jumpstarter.io wrote: Hello, We're running a couple of Arch Linux servers of version 3.13.5-1 in production and suddenly one of them had a strange problem

Re: Crash in rbd, need advice

On Fri, Apr 4, 2014 at 4:25 PM, Hannes Landeholm han...@jumpstarter.io wrote: On Fri, Apr 4, 2014 at 1:08 PM, Ilya Dryomov ilya.dryo...@inktank.com wrote: On Wed, Apr 2, 2014 at 12:18 AM, Hannes Landeholm han...@jumpstarter.io wrote: Hello, We're running a couple of Arch Linux servers of

Re: Crash in rbd, need advice

On Fri, Apr 4, 2014 at 3:10 PM, Ilya Dryomov ilya.dryo...@inktank.com wrote: On Fri, Apr 4, 2014 at 4:25 PM, Hannes Landeholm han...@jumpstarter.io wrote: On Fri, Apr 4, 2014 at 1:08 PM, Ilya Dryomov ilya.dryo...@inktank.com wrote: On Wed, Apr 2, 2014 at 12:18 AM, Hannes Landeholm

Crash in rbd, need advice

running 3.12.9 and 1 core to 3.13.5 and running 4 cores. Unfortunately we have not had time or ability to reproduce the problem, but I would appreciate any advice on how to proceed in any way that allows us to contribute so the problem can be fixed as it will inevitably happen again. Right now

Crash in rbd, need advice

would appreciate any advice on how to proceed in any way that allows us to contribute so the problem can be fixed as it will inevitably happen again. Right now we're considering building the kernel with debug support and configuring it so it can do a kernel dump. It would also be interesting to hear

[tip:perf/core] perf trace: Add beautifier for madvise behaviour/ advice parm

perf trace: Add beautifier for madvise behaviour/advice parm [root@zoo ~]# perf trace -e madvise -a 35299.631 ( 0.019 ms): 19553 madvise(start: 0x7f5b101d4000, len_in: 4063232, behavior: DONTNEED) = 0 Cc: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc

[tip:perf/core] perf trace: Add beautifier for madvise behaviour/ advice parm

, 27 Aug 2013 11:05:50 -0300 perf trace: Add beautifier for madvise behaviour/advice parm [root@zoo ~]# perf trace -e madvise -a 35299.631 ( 0.019 ms): 19553 madvise(start: 0x7f5b101d4000, len_in: 4063232, behavior: DONTNEED) = 0 Cc: Adrian Hunter adrian.hun...@intel.com Cc: David Ahern

[PATCH 19/21] perf trace: Add beautifier for madvise behaviour/advice parm

From: Arnaldo Carvalho de Melo [root@zoo ~]# perf trace -e madvise -a 35299.631 ( 0.019 ms): 19553 madvise(start: 0x7f5b101d4000, len_in: 4063232, behavior: DONTNEED) = 0 Cc: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter

[PATCH 19/21] perf trace: Add beautifier for madvise behaviour/advice parm

From: Arnaldo Carvalho de Melo a...@redhat.com [root@zoo ~]# perf trace -e madvise -a 35299.631 ( 0.019 ms): 19553 madvise(start: 0x7f5b101d4000, len_in: 4063232, behavior: DONTNEED) = 0 Cc: Adrian Hunter adrian.hun...@intel.com Cc: David Ahern dsah...@gmail.com Cc: Frederic

Re: [I2C] informations + advice about messages handling

gt; http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/smbus-protocol > and if they match then you can use the i2c_smbus_*() calls. I have checked the PIC18F24201 according to your advice and, of what I have seen, it can handle the SMBus protocol.

Re: [I2C] informations + advice about messages handling

and if they match then you can use the i2c_smbus_*() calls. I have checked the PIC18F24201 according to your advice and, of what I have seen, it can handle the SMBus protocol. Thank you for the explanation and trying to keep it simple for me :) -- Mylène JOSSERAND -- To unsubscribe from this list: send

Re: [I2C] informations + advice about messages handling

On Fri, 24 May 2013 11:52:54 +0200, Mylene Josserand wrote: > Right now, my company uses the "i2c_smbus_read/write_byte_data" > functions to talk to devices through an application. On the datasheet of > these devices, I search but did not seem to be SMBus compliant. > As it was a software which

Re: [I2C] informations + advice about messages handling

On Fri, 24 May 2013 16:29:36 +0530, anish singh wrote: > On Fri, May 24, 2013 at 1:14 PM, Jean Delvare wrote: > > On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote: > >> http://thread.gmane.org/gmane.linux.kernel/1410276 > > > > This is for a specific case. The general case is handled by the

Re: [I2C] informations + advice about messages handling

On Fri, May 24, 2013 at 1:14 PM, Jean Delvare wrote: > Hi Anish, Mylène, > > On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote: >> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand >> wrote: >> > I have read that this function "i2c_smbus_write_byte_data" uses >> > "i2c_smbus_xfer" which

Re: [I2C] informations + advice about messages handling

Le 24/05/2013 11:07, Jean Delvare a écrit : > On Fri, 24 May 2013 10:54:11 +0200, Mylene Josserand wrote: >> Ah okay ! And if there are not SMBus compliant, what function I will >> have to use ? > > i2c_transfer() Okay, logic name ;) >> What is it doing if I use this function and that my

Re: [I2C] informations + advice about messages handling

On Fri, 24 May 2013 10:54:11 +0200, Mylene Josserand wrote: > Ah okay ! And if there are not SMBus compliant, what function I will > have to use ? i2c_transfer() > What is it doing if I use this function and that my device is not SMbus > compliant ? This would make no sense. Your device

Re: [I2C] informations + advice about messages handling

ferent devices uses, it will help me a lot ! I will search in >>> the kernel documentation but there is many files about i2c. >>> And if you know a good i2c driver that I can use as an example to design >>> mine, it will be great ! > > Best is to look at a driver for a device which is similar in > functionality to yours. I will search that, thanks for the advice. -- Mylène JOSSERAND N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a��� 0��h���i

Re: [I2C] informations + advice about messages handling

Hi Anish, Mylène, On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote: > On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand > wrote: > > I have read that this function "i2c_smbus_write_byte_data" uses > > "i2c_smbus_xfer" which uses "i2c_lock_adapter". > > In this function, there is a mutex so

Re: [I2C] informations + advice about messages handling

On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand wrote: > Hi all, > > > I am learning how i2c is working and I read that, to write in an i2c > register, I need to use the function "i2c_smbus_write_byte_data". Only in case your device is smbus compliant. > I wanted to know how the message are

Re: [I2C] informations + advice about messages handling

On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand mylene.josser...@navocap.com wrote: Hi all, I am learning how i2c is working and I read that, to write in an i2c register, I need to use the function i2c_smbus_write_byte_data. Only in case your device is smbus compliant. I wanted to know

Re: [I2C] informations + advice about messages handling

Hi Anish, Mylène, On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote: On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand mylene.josser...@navocap.com wrote: I have read that this function i2c_smbus_write_byte_data uses i2c_smbus_xfer which uses i2c_lock_adapter. In this function, there

  1   2   3   >