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, but
;`"
+boot_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_G
uct notifier_block *nb,
> unsigned long val,
>
> skx_mce_output_error(mci, mce, &res);
>
> - 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
gt; +++ 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, &res);
> >
> > - return NOTIFY_DONE;
> > + /* Advice mcelog that th
gned long val,
>
> skx_mce_output_error(mci, mce, &res);
>
> - 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
index 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, &res);
- return NOTIFY_DONE;
+ /* Advice mcelog that the e
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",
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&
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 t
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] = "DONTN
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.
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 thre
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 -> uart.
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 -> fi
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 O
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?:
>>
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 O
gt;>>>> 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
&g
-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
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
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
>
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.
>>
>> S
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 strai
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'
+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 VIRTIO_NE
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
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_LEGACY
#define VIRTIO_N
; #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 VIRTIO_NET_NO_
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
= readl_relaxed(RX_BYTE);
head = WRAP(head+1);
}
if (req && (timeout || RX_BUF_LEVEL >= req)) {
req = 0;
DISABLE_TIMEOUT;
complete(&done);
}
}
AFAICT, there are no problematic races...
Anyway, if anyone's read this far, well thanks first of all ;-)
If y
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"
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
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&R that produces a compile error
> >
> > if (NULL = x)
> >
>
> Yes. People used to write Yoda code back in t
On Mon, Dec 15, 2014 at 05:03:46AM -0800, Jeremiah Mahler wrote:
>
> Or another way mentioned in K&R 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 mos
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
> > > > Documenti
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 st
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 almost
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 to the
&
"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
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
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
anyti
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 Nic
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 Linu
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
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 p
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 those
ade we did last week
from 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 inevitabl
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
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 Zij
or
> 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.
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 w
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
>
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 uses
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
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 underst
>> case of different 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�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
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
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 ha
additional debugging advice when we hit lockdep BUGs
We occasionally get reports of these BUGs being hit, and the
stack trace doesn't necessarily always tell us what we need to
know about why we are hitting those limits.
If users start attaching /proc/lock_stats to reports we may have
more of a clue w
* Dave Jones wrote:
> On Wed, Apr 24, 2013 at 08:48:13AM +0200, Ingo Molnar wrote:
>
> > These patterns repeated in 4 places really call for a common helper
> > defined as print_lockdep_off(fmt...) or so?
> >
> > (Can be a followup patch if that's easier for you.)
>
> Given there was onl
On Wed, Apr 24, 2013 at 08:48:13AM +0200, Ingo Molnar wrote:
> These patterns repeated in 4 places really call for a common helper
> defined as print_lockdep_off(fmt...) or so?
>
> (Can be a followup patch if that's easier for you.)
Given there was only one case which was really different,
* Dave Jones wrote:
> We occasionally get reports of these BUGs being hit, and the stack trace
> doesn't necessarily always tell us what we need to know about why we are
> hitting those limits.
>
> If users start attaching /proc/lock_stats to reports we may have more of
> a clue what's going on
We occasionally get reports of these BUGs being hit, and the stack trace
doesn't necessarily always tell us what we need to know about why we are
hitting those limits.
If users start attaching /proc/lock_stats to reports we may have more of
a clue what's going on.
Signed-off-by: Dave Jones
--
> (a) Since all the mappings have been removed, so why don't the fd's get
> released ?
Because your code is buggy.
Firstly its files it keeps a reference to not file handles, so your close
closes the file handle. You do however end up with lots of file structs
pinned and that's because you've go
On 16/09/12 21:52, richard -rw- weinberger wrote:
> On Sun, Sep 16, 2012 at 9:21 PM, Mark Jackson wrote:
>> // now remove the mapping
>> if (m_pFram)
>> munmap(m_pFram, FRAM_SIZE);
>
> You unmap less memory than you map...
>
I hang my head in shame ... what a stupid mist
On Sun, Sep 16, 2012 at 9:21 PM, Mark Jackson wrote:
> Apologies if this is the wrong place to post this query. Please feel free
> to redirect me to the correct place.
>
> I have come across a weird (but documented [1]) "feature" of mmap(), which
> is:-
>
> "The mmap()function adds an extra refer
Apologies if this is the wrong place to post this query. Please feel
free to redirect me to the correct place.
I have come across a weird (but documented [1]) "feature" of mmap(),
which is:-
"The mmap()function adds an extra reference to the file associated with
the file descriptor fildeswh
nt fd, loff_t offset, loff_t len, int advice);
My test case calls fadvise64_64 with invalid advice value and
checks errno is set to EINVAL.
About the advice parameter man page says:
...
Permissible values for advice include:
POSIX_FADV_N
Leon Woestenberg wrote:
Hello,
I'm converting an out-of-tree (*1) driver from binary semaphore to mutex.
Userspace updates a look-up-table using write(). The driver tries to
write this LUT to the FPGA in the (video frame) interrupt handler. It
is important that the LUT is consistent and thus c
On Thu, 22 Nov 2007 17:02:44 +0100
"Leon Woestenberg" <[EMAIL PROTECTED]> wrote:
> Hello,
>
>
> I'm converting an out-of-tree (*1) driver from binary semaphore to
> mutex.
>
> Userspace updates a look-up-table using write(). The driver tries to
> write this LUT to the FPGA in the (video frame)
On Thu, 22 Nov 2007 17:19:44 +0100
"Leon Woestenberg" <[EMAIL PROTECTED]> wrote:
> I forgot to mention that I would like to be prepared for, and use the
> -rt patch soon. I understand (maybe wrongly?) that semaphores are not
> real-time pre-emptible, mutexes and spinlocks are.
Semaphores are pree
Hello,
On Nov 22, 2007 5:11 PM, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag 22 November 2007 schrieb Leon Woestenberg:
> > I would like to know why this is not so, and if someone has a cleaner
> > proposal than the "try spinlock" approach?
>
> Keep the semaphore.
>
I forgot to mention
Am Donnerstag 22 November 2007 schrieb Leon Woestenberg:
> I would like to know why this is not so, and if someone has a cleaner
> proposal than the "try spinlock" approach?
Keep the semaphore.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe lin
Hello,
I'm converting an out-of-tree (*1) driver from binary semaphore to mutex.
Userspace updates a look-up-table using write(). The driver tries to
write this LUT to the FPGA in the (video frame) interrupt handler. It
is important that the LUT is consistent and thus changed atomically.
Note th
tions and how
> > > best to write them.
> > >
> > > I have written a support for suspend/resume for saa7134 v4l driver.
> > > Now looking at code again and again, I found few problems, and I am
> > > seeking your advice how to fix them.
> > >
> >
r suspend/resume for saa7134 v4l driver.
> > Now looking at code again and again, I found few problems, and I am seeking
> > your advice how to fix them.
> >
> > First of all the .suspend() function:
> >
> > Looking at various drivers (including v4l ones) it s
Maxim Levitsky wrote:
> Hi,
>
> I have few questions about .suspend()/.resume() driver functions and how best
> to write them.
>
> I have written a support for suspend/resume for saa7134 v4l driver.
> Now looking at code again and again, I found few problems, and I am seeking
>
Hi,
I have few questions about .suspend()/.resume() driver functions and how best
to write them.
I have written a support for suspend/resume for saa7134 v4l driver.
Now looking at code again and again, I found few problems, and I am seeking
your advice how to fix them.
First of all the
Em Mon, Aug 13, 2007 at 04:55:23PM -0400, Lennart Sorensen escreveu:
> On Fri, Aug 10, 2007 at 04:28:19PM +0400, Brad Campbell wrote:
> > I'm building a bit of hardware. It's basically a serial multiplexer that
> > communicates to the PC using a single usb-serial port. It has the ability
> > to r
> I don't think you can do any serial specific stuff, like parity and stop
> bits and the like across a pty. You might have to actually write a
They will let you do that. Any options you set one side become visible
the other.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux
On Fri, Aug 10, 2007 at 04:28:19PM +0400, Brad Campbell wrote:
> I'm building a bit of hardware. It's basically a serial multiplexer that
> communicates to the PC using a single usb-serial port. It has the ability
> to run between 2 and 8 standard async ports over this single interface.
>
> I'd
G'day all,
I'm building a bit of hardware. It's basically a serial multiplexer that communicates to the PC
using a single usb-serial port. It has the ability to run between 2 and 8 standard async ports over
this single interface.
I'd rather not write a kernel driverif possible as I figure thi
On Sat, May 12, 2007 at 01:15:30PM +0100, Alan Cox wrote:
> > > I'd prefer not. I get reports from people about drivers that got "lost"
> > > by vendors, regularly. Nor am I pointing fingers at specific vendors here,
> > > last month I sorted out a two year old "lost in Red Hat Bugzilla" kernel
> >
> > I'd prefer not. I get reports from people about drivers that got "lost"
> > by vendors, regularly. Nor am I pointing fingers at specific vendors here,
> > last month I sorted out a two year old "lost in Red Hat Bugzilla" kernel
> > bug for example.
>
> How many maintainers want to get bug repo
On Fri, May 11, 2007 at 10:35:00PM +0100, Alan Cox wrote:
> > This still wouldn't solve the following problems:
> > - I doubt it will be kept up to date for all > 2800 modules in the kernel
> > - the 3 year old kernel of your distribution would contain 3 year old
> > maintainership information
>
Rene Herman <[EMAIL PROTECTED]> writes:
> /* Author, ideally of form NAME [, NAME ]*[ and NAME ]
>
> After my trivial patch, it says:
>
> /* Author, ideally of form NAME[, NAME]*[ and NAME] */
I think I would put something like this:
/* Author, of form NAME[, NAME]*[ and NAME]
* If you have a p
> This still wouldn't solve the following problems:
> - I doubt it will be kept up to date for all > 2800 modules in the kernel
> - the 3 year old kernel of your distribution would contain 3 year old
> maintainership information
> - maintainers sometimes disappear
Maintainers sometimes DON'T dis
On Fri, May 11, 2007 at 07:42:38AM -0400, John Anthony Kazos Jr. wrote:
> > > The email address is the problem I was trying to fix; with multiple
> > > current
> > > and non-current authors and maintainers who might not even be authors the
> > > address(es) available from the tag confuse the iss
On 05/11/2007 01:42 PM, John Anthony Kazos Jr. wrote:
Can't we just subtitle it somehow? Add tags: " (current maintainer)", "
(original author, inactive)", " (bug and defect reports)", or whatever
you like after the names.
Yes, that's close to Rusty's version of the original MODULE_MAINTAINER
which happens for multiple reasons; owner graduating, ISP mergers, dog
eating owner's foo, owner dying, dog dying and owner getting so depressed he
just can't handle it all anymore, what have you) and as such putting them
into the binary is not something to generally advise.
Fina
s outlined above would just live
> on for everything else though and we happily continue to frustrate bug
> reporters and maintainers.
You can also solve the problem of bugs in drivers by deleting the driver.
Both are equivalent neither are very smart.
If you find a bogus maintainer entry em
e would just live
on for everything else though and we happily continue to frustrate bug
reporters and maintainers.
Finally, at the very, very least the advice to add more future problems
should be killed and that's the only thing _this_ particular patch does.
Rene.
-
To unsubscribe from
> > The email address is the problem I was trying to fix; with multiple current
> > and non-current authors and maintainers who might not even be authors the
> > address(es) available from the tag confuse the issue of whom to contact.
> > It's moreover also information that easily outdated.
> >
> The email address is the problem I was trying to fix; with multiple current
> and non-current authors and maintainers who might not even be authors the
> address(es) available from the tag confuse the issue of whom to contact.
> It's moreover also information that easily outdated.
>
> A bit m
Hi Rusty.
Following up the recent MODULE_MAINTAINER discussion:
http://lkml.org/lkml/2007/4/4/170
that concluded with MODULE_MAINTAINER not being a good idea, here's a small
patch that just deletes the advice of including an email address in the
MODULE_AUTHOR tag as suggested (an
On 4/25/07, Miguel Freitas <[EMAIL PROTECTED]> wrote:
hey, could it be that this -513 is actually -ERESTARTNOINTR?
if so, that would be a good explanation why it hangs.
- copy_process() checks for pending signals, then set retval =
-ERESTARTNOINTR and returns.
- handle_signal has the followin
On 4/25/07, Miguel Freitas <[EMAIL PROTECTED]> wrote:
(...)
0x2b2e77d6d5b6 : mov$0x38,%eax
0x2b2e77d6d5bb : syscall
0x2b2e77d6d5bd : cmp$0xf000,%rax
(...)
(gdb) info reg
rax0xfdff -513
hey, could it be that this -513 is actually
hi,
making a long story short: i'm trying to debug a problem with the fork
syscall as called from glibc's popen() function. it seems that a given
process (in case Xorg) get stuck inside a syscall that never returns.
while stuck it keeps using 100% of cpu.
I can confirm the problem with kernel 2.
Hi!
> I'd like to add backlight support for input devices since my custom
> board has a backlighted mini keyboard.
>
> It could be acceptable to move the code from drivers/video/backlight/
> to drivers/backlight/ renaming the "Backlight & LCD" name into
> "Backlight" and adding two new entries "L
Hello Rodolfo,
Wednesday, February 21, 2007, 6:02:13 PM, you wrote:
> Hello,
> I'd like to add backlight support for input devices since my custom
> board has a backlighted mini keyboard.
There's already generic indicator API, currently mostly known as
"[new] LED [classdev] API", even though
1 - 100 of 141 matches
Mail list logo
