Le Tue, 3 Oct 2017 13:34:37 +0300,
Adrian Hunter <adrian.hun...@intel.com> a écrit :
> On 03/10/17 13:19, Matthieu CASTET wrote:
> > Hi,
> >
> > while using perf on x86_64, I saw strange output for symoff.
> >
> > $ perf record -g -- sleep 1
> >
Le Tue, 3 Oct 2017 13:34:37 +0300,
Adrian Hunter a écrit :
> On 03/10/17 13:19, Matthieu CASTET wrote:
> > Hi,
> >
> > while using perf on x86_64, I saw strange output for symoff.
> >
> > $ perf record -g -- sleep 1
> > $ perf script
Hi,
while using perf on x86_64, I saw strange output for symoff.
$ perf record -g -- sleep 1
$ perf script -F comm,tid,pid,time,ip,sym,dso,symoff
[...]
sleep 11656/11656 1045318.546436:
7fff9542e5b5 __d_lookup_rcu+0x80006ae02035 ([kernel.kallsyms])
7fff9541e132
Hi,
while using perf on x86_64, I saw strange output for symoff.
$ perf record -g -- sleep 1
$ perf script -F comm,tid,pid,time,ip,sym,dso,symoff
[...]
sleep 11656/11656 1045318.546436:
7fff9542e5b5 __d_lookup_rcu+0x80006ae02035 ([kernel.kallsyms])
7fff9541e132
consistent with others entries
(ioremap, vmalloc, ...) that already provide caller.
Signed-off-by: Matthieu CASTET <matthieu.cas...@parrot.com>
---
arch/arm64/mm/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma
consistent with others entries
(ioremap, vmalloc, ...) that already provide caller.
Signed-off-by: Matthieu CASTET
---
arch/arm64/mm/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 614af886b7ef..11
Hi,
the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
change to syscall to an equivalent to FUTEX_WAIT_BITSET |
FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY.
It seems wrong to me, because in case of FUTEX_WAIT, in
"SYSCALL_DEFINE6(futex", we convert relative
Hi,
the commit 337f13046ff03717a9e99675284a817527440a49 is saying that it
change to syscall to an equivalent to FUTEX_WAIT_BITSET |
FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY.
It seems wrong to me, because in case of FUTEX_WAIT, in
"SYSCALL_DEFINE6(futex", we convert relative
Le Wed, 27 Aug 2014 10:54:53 -0400,
Alan Stern a écrit :
> On Wed, 27 Aug 2014, Matthieu CASTET wrote:
>
> > Ping
> >
> > I have got also a problem with a usb sdcard reader (without power cut
> > during suspend)
>
> > > > The usb storage driver
Le Wed, 27 Aug 2014 10:54:53 -0400,
Alan Stern st...@rowland.harvard.edu a écrit :
On Wed, 27 Aug 2014, Matthieu CASTET wrote:
Ping
I have got also a problem with a usb sdcard reader (without power cut
during suspend)
The usb storage driver call scsi_report_bus_reset after
:0: [sdb]
[ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed
[ 1204.141514] sd 8:0:0:0: [sdb] CDB:
[ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00
[ 1204.141526] end_request: I/O error, dev sdb, sector 685560
Le Mon, 28 Apr 2014 15:01:39 +0200,
Matthieu CASTET
:0: [sdb]
[ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed
[ 1204.141514] sd 8:0:0:0: [sdb] CDB:
[ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00
[ 1204.141526] end_request: I/O error, dev sdb, sector 685560
Le Mon, 28 Apr 2014 15:01:39 +0200,
Matthieu CASTET
Le Fri, 8 Aug 2014 13:50:52 -0600,
David Ahern a écrit :
> On 8/8/14, 10:40 AM, Matthieu CASTET wrote:
> > Hi,
> >
> > I have a 64 bits kernel running with 32 bits binaries.
> > If I run 32 bits perf on this 64 bits kernel 3.14, I got weird result :
> >
> &g
Le Fri, 8 Aug 2014 13:50:52 -0600,
David Ahern dsah...@gmail.com a écrit :
On 8/8/14, 10:40 AM, Matthieu CASTET wrote:
Hi,
I have a 64 bits kernel running with 32 bits binaries.
If I run 32 bits perf on this 64 bits kernel 3.14, I got weird result :
- perf trace doesn't work [1]
I
Hi,
I have a 64 bits kernel running with 32 bits binaries.
If I run 32 bits perf on this 64 bits kernel 3.14, I got weird result :
- perf trace doesn't work [1]
- perf record with dwarf call-graph doesn't work [2]
Matthieu
[1]
$ sudo perf trace ls
0.009 ( 0.000 ms): ... [continued]:
Hi,
I have a 64 bits kernel running with 32 bits binaries.
If I run 32 bits perf on this 64 bits kernel 3.14, I got weird result :
- perf trace doesn't work [1]
- perf record with dwarf call-graph doesn't work [2]
Matthieu
[1]
$ sudo perf trace ls
0.009 ( 0.000 ms): ... [continued]:
Hi Boris,
Le Tue, 22 Jul 2014 14:12:19 +0200,
Boris BREZILLON a écrit :
> Hi Matthieu
>
> On Tue, 22 Jul 2014 12:03:46 +0200
> Matthieu CASTET wrote:
>
> > Hi,
> >
> >
> >
> > I did a similar patch [1] (that wasn't merged :( ), and I used redu
Hi Boris,
Le Tue, 22 Jul 2014 14:12:19 +0200,
Boris BREZILLON boris.brezil...@free-electrons.com a écrit :
Hi Matthieu
On Tue, 22 Jul 2014 12:03:46 +0200
Matthieu CASTET matthieu.cas...@parrot.com wrote:
Hi,
I did a similar patch [1] (that wasn't merged :( ), and I used
chip (not upstream).
Matthieu
[1]
[PATCH 2/3] mtd nand : get timings from onfi
We get from onfi param the max speed supported by the chip.
A precomputed table for ONFI timings is generated.
Signed-off-by: Matthieu CASTET
---
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand
chip (not upstream).
Matthieu
[1]
[PATCH 2/3] mtd nand : get timings from onfi
We get from onfi param the max speed supported by the chip.
A precomputed table for ONFI timings is generated.
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
---
drivers/mtd/nand/Makefile |2
Hi,
any news on this.
Matthieu CASTET
Le Tue, 22 Apr 2014 16:01:15 +0200,
Matthieu CASTET a écrit :
> Hi,
>
> while playing with suspend to ram I found a strange behavior with usb
> key.
>
> This can be easily reproduced by doing :
> - plug a usb key
> - start to
Hi,
any news on this.
Matthieu CASTET
Le Tue, 22 Apr 2014 16:01:15 +0200,
Matthieu CASTET matthieu.cas...@parrot.com a écrit :
Hi,
while playing with suspend to ram I found a strange behavior with usb
key.
This can be easily reproduced by doing :
- plug a usb key
- start to read
Le Mon, 24 Feb 2014 16:03:10 +0800,
Neil Zhang a écrit :
> This patch set is mainly for bug fix.
>
> Neil Zhang (6):
> usb: gadget: mv_udc: remove redundant pull up in udc_start
> usb: gadget: mv_udc: disable HW zlt for ep0
> usb: gadget: mv_udc: clear corresponding interrupt when flush
Le Mon, 24 Feb 2014 16:03:10 +0800,
Neil Zhang zhan...@marvell.com a écrit :
This patch set is mainly for bug fix.
Neil Zhang (6):
usb: gadget: mv_udc: remove redundant pull up in udc_start
usb: gadget: mv_udc: disable HW zlt for ep0
usb: gadget: mv_udc: clear corresponding interrupt
http://marc.info/?l=linux-usb=133701342028213=2
They may apply to your commit.
>
> Inspired-by: Matthieu CASTET
> Signed-off-by: Tuomas Tynkkynen
> ---
> drivers/usb/chipidea/host.c | 1 +
> drivers/usb/host/ehci-hub.c | 14 +++---
> drivers/usb/host/ehci.h | 1 +
.
Inspired-by: Matthieu CASTET matthieu.cas...@parrot.com
Signed-off-by: Tuomas Tynkkynen ttynkky...@nvidia.com
---
drivers/usb/chipidea/host.c | 1 +
drivers/usb/host/ehci-hub.c | 14 +++---
drivers/usb/host/ehci.h | 1 +
3 files changed, 9 insertions(+), 7 deletions(-)
diff
Hello,
> Hi all,
>
> I am a new comer to this mailing list ,
> I am happy to join this community .
>
You should send this to arm ML.
Also I believe most of people don't enable CONFIG_OABI_COMPAT, that's why they
don't hit the bug.
Matthieu
> I have a bug reported from our android phones
Hello,
Hi all,
I am a new comer to this mailing list ,
I am happy to join this community .
You should send this to arm ML.
Also I believe most of people don't enable CONFIG_OABI_COMPAT, that's why they
don't hit the bug.
Matthieu
I have a bug reported from our android phones which
Hi Andrew,
thanks for your quick review.
Andrew Morton a écrit :
> On Thu, 11 Apr 2013 15:53:09 +0200 Matthieu CASTET
> wrote:
>
>> The current code return the address instead of using PTR_ERR.
>
> I don't understand what you mean here - please describe this error
Hi Andrew,
thanks for your quick review.
Andrew Morton a écrit :
On Thu, 11 Apr 2013 15:53:09 +0200 Matthieu CASTET
matthieu.cas...@parrot.com wrote:
The current code return the address instead of using PTR_ERR.
I don't understand what you mean here - please describe this error in
much
end SIGKILL instead of SIGSEGV to match what is done when loading binary.
Signed-off-by: Matthieu CASTET
Cc: Al Viro
Cc: Andrew Morton
---
fs/binfmt_elf.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3939
SIGKILL instead of SIGSEGV to match what is done when loading binary.
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: Andrew Morton a...@linux-foundation.org
---
fs/binfmt_elf.c | 21 -
1 file changed, 12 insertions(+), 9
Will Deacon a écrit :
> Hi Andre,
>
> On Tue, Feb 12, 2013 at 02:02:59PM +, André Hentschel wrote:
>> Am 08.02.2013 16:48, schrieb Will Deacon:
>>> On Wed, Feb 06, 2013 at 11:01:23PM +, André Hentschel wrote:
No, i'm not sure how to improve this. How does the process can continue,
Will Deacon a écrit :
Hi Andre,
On Tue, Feb 12, 2013 at 02:02:59PM +, André Hentschel wrote:
Am 08.02.2013 16:48, schrieb Will Deacon:
On Wed, Feb 06, 2013 at 11:01:23PM +, André Hentschel wrote:
No, i'm not sure how to improve this. How does the process can continue,
can you or
it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
>
+ */
+
+#ifndef __MTD_FLASH_JEDEC
+#define __MTD_FLASH_JEDEC
+
+struct flash_device_info {
+ const char *name;
+ u32 jedec_id;
+ u32 size_kb;
+};
+
+extern struct flash_device_info *jedec_match_device(u32 jedec_id);
+
+#endif
--
Matthieu Castet
Ingénieur
Could you explain why the old code was wrong ?
With HZ=100
timeo = jiffies + 2 and it should be working.
Huang Shijie a écrit :
> In nand_wait(), the timeo for panic_nand_wait() is assigned with
> wrong value(jiffies + some delay).
>
> This patch fixes it, and also uses the msecs_to_jiffies()
e - 1* BYTES_PER_WORD: last caller address
* [BYTES_PER_WORD long]
*/
Signed-off-by: Matthieu Castet
CC: Russell King
CC: Pekka Enberg
---
mm/slab.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index e7667a3..d2380d9 10064
.. cachep-obj_offset - 1:
* redzone word.
* cachep-obj_offset: The real object.
* cachep-buffer_size - 2* BYTES_PER_WORD: redzone word [BYTES_PER_WORD long]
* cachep-buffer_size - 1* BYTES_PER_WORD: last caller address
* [BYTES_PER_WORD long]
*/
Signed-off-by: Matthieu
Could you explain why the old code was wrong ?
With HZ=100
timeo = jiffies + 2 and it should be working.
Huang Shijie a écrit :
In nand_wait(), the timeo for panic_nand_wait() is assigned with
wrong value(jiffies + some delay).
This patch fixes it, and also uses the msecs_to_jiffies() to
Huang Shijie a écrit :
> With some latest Micron's onfi nand(such as MT29F64G08CBABAWP),
> I find that if we do not apply the tPROG delay as the datasheet tells us,
> the page program may fails. You will read out the all 0xff from this page
> in this case.
>
> This patch adds the tPROG delay for
Huang Shijie a écrit :
With some latest Micron's onfi nand(such as MT29F64G08CBABAWP),
I find that if we do not apply the tPROG delay as the datasheet tells us,
the page program may fails. You will read out the all 0xff from this page
in this case.
This patch adds the tPROG delay for page
m.
>
> Replace mutex with rwsem for codec->shutdown protection so that
> concurrent accesses are allowed.
>
> Also add the protection to snd_usb_autosuspend() and
> snd_usb_autoresume(), too.
>
> Reported-by: Matthieu CASTET
> Signed-off-by: Takashi Iwai
> S
mutex with rwsem for codec-shutdown protection so that
concurrent accesses are allowed.
Also add the protection to snd_usb_autosuspend() and
snd_usb_autoresume(), too.
Reported-by: Matthieu CASTET matthieu.cas...@parrot.com
Signed-off-by: Takashi Iwai ti...@suse.de
Signed-off-by: Ben Hutchings
Note memtester is also a great userspace tool for testing memory :
http://pyropus.ca/software/memtester/
It works fine on arm and other arch (but work on malloc or /dev/mem memory)--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Note memtester is also a great userspace tool for testing memory :
http://pyropus.ca/software/memtester/
It works fine on arm and other arch (but work on malloc or /dev/mem memory)--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
This can help to catch case where hardware is writting after dma free.
Signed-off-by: Matthieu Castet
---
mm/dmapool.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..e10898a 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
This can help to catch case where hardware is writting after dma free.
Signed-off-by: Matthieu Castet matthieu.cas...@parrot.com
---
mm/dmapool.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..e10898a 100644
--- a/mm
Pekka Enberg a écrit :
> Hi,
>
> (Adding more people to CC.)
>
> On Tue, Oct 16, 2012 at 2:17 PM, Matthieu CASTET
> wrote:
>> From: Matthieu CASTET
>>
>> on cortexA8 (omap3) ralign is 64 and __alignof__(unsigned long long) is 8.
>> So we alway
Pekka Enberg a écrit :
Hi,
(Adding more people to CC.)
On Tue, Oct 16, 2012 at 2:17 PM, Matthieu CASTET
matthieu.cas...@parrot.com wrote:
From: Matthieu CASTET castet.matth...@free.fr
on cortexA8 (omap3) ralign is 64 and __alignof__(unsigned long long) is 8.
So we always disable debug
From: Matthieu CASTET
on cortexA8 (omap3) ralign is 64 and __alignof__(unsigned long long) is 8.
So we always disable debug.
This patch is based on 5c5e3b33b7cb959a401f823707bee006caadd76e, but fix
case were align < sizeof(unsigned long long).
Signed-off-by: Matthieu Castet
CC: Russell K
From: Matthieu CASTET castet.matth...@free.fr
on cortexA8 (omap3) ralign is 64 and __alignof__(unsigned long long) is 8.
So we always disable debug.
This patch is based on 5c5e3b33b7cb959a401f823707bee006caadd76e, but fix
case were align sizeof(unsigned long long).
Signed-off-by: Matthieu
Le Tue, 25 Sep 2012 15:44:57 +,
Arnd Bergmann a écrit :
>
> It's not possible to build a kernel that runs on ARMv5 (or below) and
> also on ARMv6 (or above), so the effect would be exactly the same.
> While we are putting a lot of effort into making all sorts of ARMv6
> and ARMv7 based
Stephen Boyd a écrit :
> On 8/31/2012 4:47 AM, Matthieu CASTET wrote:
>> Signed-off-by: Matthieu Castet
>
> Please consider adding some sort of commit text. Does this add some new
> feature I may want on some downstream distro kernel?
>
ok
>
> It's unfortunate that t
Arnd Bergmann a écrit :
> On Friday 31 August 2012, Stephen Boyd wrote:
>>> +static int hvc_dcc_put_chars_v6(uint32_t vt, const char *buf, int count)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < count; i++) {
>>> + while (__dcc_getstatus_v6() & DCC_STATUS_TX_V6)
>>> +
Arnd Bergmann a écrit :
On Friday 31 August 2012, Stephen Boyd wrote:
+static int hvc_dcc_put_chars_v6(uint32_t vt, const char *buf, int count)
+{
+ int i;
+
+ for (i = 0; i count; i++) {
+ while (__dcc_getstatus_v6() DCC_STATUS_TX_V6)
+
Stephen Boyd a écrit :
On 8/31/2012 4:47 AM, Matthieu CASTET wrote:
Signed-off-by: Matthieu Castet matthieu.cas...@parrot.com
Please consider adding some sort of commit text. Does this add some new
feature I may want on some downstream distro kernel?
ok
It's unfortunate that the main
Le Tue, 25 Sep 2012 15:44:57 +,
Arnd Bergmann a...@arndb.de a écrit :
It's not possible to build a kernel that runs on ARMv5 (or below) and
also on ARMv6 (or above), so the effect would be exactly the same.
While we are putting a lot of effort into making all sorts of ARMv6
and ARMv7
Alan Cox a écrit :
> On Fri, 31 Aug 2012 11:33:51 +0100
> Russell King - ARM Linux wrote:
>
>> On Fri, Aug 31, 2012 at 12:29:04PM +0200, Matthieu CASTET wrote:
>>> Alan Cox a écrit :
>>>> On Fri, 31 Aug 2012 11:21:56 +0200
>>>> Matthieu CASTET
Signed-off-by: Matthieu Castet
---
drivers/tty/hvc/hvc_dcc.c | 83 +
1 file changed, 76 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..5f8827f 100644
--- a/drivers/tty/hvc/hvc_dcc.c
Alan Cox a écrit :
> On Fri, 31 Aug 2012 11:21:56 +0200
> Matthieu CASTET wrote:
>
>> Signed-off-by: Matthieu Castet
>> ---
>> drivers/tty/hvc/hvc_dcc.c | 34 ++
>> 1 file changed, 34 insertions(+)
>
> This is a step
Signed-off-by: Matthieu Castet
---
drivers/tty/hvc/hvc_dcc.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..489e9e5 100644
--- a/drivers/tty/hvc/hvc_dcc.c
+++ b/drivers/tty/hvc
Signed-off-by: Matthieu Castet matthieu.cas...@parrot.com
---
drivers/tty/hvc/hvc_dcc.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..489e9e5 100644
--- a/drivers/tty/hvc/hvc_dcc.c
Alan Cox a écrit :
On Fri, 31 Aug 2012 11:21:56 +0200
Matthieu CASTET castet.matth...@free.fr wrote:
Signed-off-by: Matthieu Castet matthieu.cas...@parrot.com
---
drivers/tty/hvc/hvc_dcc.c | 34 ++
1 file changed, 34 insertions(+)
This is a step
Signed-off-by: Matthieu Castet matthieu.cas...@parrot.com
---
drivers/tty/hvc/hvc_dcc.c | 83 +
1 file changed, 76 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..5f8827f 100644
Alan Cox a écrit :
On Fri, 31 Aug 2012 11:33:51 +0100
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Fri, Aug 31, 2012 at 12:29:04PM +0200, Matthieu CASTET wrote:
Alan Cox a écrit :
On Fri, 31 Aug 2012 11:21:56 +0200
Matthieu CASTET castet.matth...@free.fr wrote:
Signed-off
Ack-by: matthieu castet
Le Wed, 25 Jul 2012 14:32:50 -0600,
Tim Gardner a écrit :
> Cc: Matthieu CASTET
> Cc: Stanislaw Gruszka
> Cc: Greg Kroah-Hartman
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Tim Gardner
> ---
> drivers/usb/at
Ack-by: matthieu castet castet.matth...@free.fr
Le Wed, 25 Jul 2012 14:32:50 -0600,
Tim Gardner tim.gard...@canonical.com a écrit :
Cc: Matthieu CASTET castet.matth...@free.fr
Cc: Stanislaw Gruszka stf...@wp.pl
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-...@vger.kernel.org
Sam Ravnborg ravnborg.org> writes:
>
> In at least 99% of the cases this is OK and the check has found
> several bugs where things would not have worked due to different
> alignmnet between kernel and userland. Just think about the
> issues in a mixed 32/64 bit world.
>
I don't see how this
Sam Ravnborg sam at ravnborg.org writes:
In at least 99% of the cases this is OK and the check has found
several bugs where things would not have worked due to different
alignmnet between kernel and userland. Just think about the
issues in a mixed 32/64 bit world.
I don't see how this
Hi,
David P. Reed reed.com> writes:
> And actually, if I had looked at the /sys/bus/pnp definitions, rather
> than /proc/ioports, I would have noticed that port 80 was part of a
> PNP0C02 resource set. That means exactly one thing: ACPI says that
> port 80 is NOT free to be used, for
Hi,
David P. Reed dpreed at reed.com writes:
And actually, if I had looked at the /sys/bus/pnp definitions, rather
than /proc/ioports, I would have noticed that port 80 was part of a
PNP0C02 resource set. That means exactly one thing: ACPI says that
port 80 is NOT free to be used, for
Hi,
I am on a 2.6.23.11 on a AMD Athlon(tm) XP 1800+.
When I do a sysrq-t, after the dump of task state (that is quite slow
because of the vesa console framebuffer), I got the message
"Clocksource tsc unstable (delta = 28115415756 ns)
Time: acpi_pm clocksource has been installed."
Is that
Hi,
I am on a 2.6.23.11 on a AMD Athlon(tm) XP 1800+.
When I do a sysrq-t, after the dump of task state (that is quite slow
because of the vesa console framebuffer), I got the message
Clocksource tsc unstable (delta = 28115415756 ns)
Time: acpi_pm clocksource has been installed.
Is that
Anton Salikhmetov gmail.com> writes:
>
> From: Anton Salikhmetov gmail.com>
>
> According to the POSIX standard, multiple real-time signals
> pending to a process should be delivered in a strict order.
> Specifically, the lowest-numbered signal should be delivered
> first and multiple
Anton Salikhmetov salikhmetov at gmail.com writes:
From: Anton Salikhmetov salikhmetov at gmail.com
According to the POSIX standard, multiple real-time signals
pending to a process should be delivered in a strict order.
Specifically, the lowest-numbered signal should be delivered
first
Ingo Molnar elte.hu> writes:
> A year ago the -rt kernel defaulted to the SLOB for a few releases, and
> barring some initial scalability issues (which were solved in -rt) it
> worked pretty well on generic PCs, so i dont buy the 'it doesnt work'
> argument either.
>
Last time I tried it, I
Ingo Molnar mingo at elte.hu writes:
A year ago the -rt kernel defaulted to the SLOB for a few releases, and
barring some initial scalability issues (which were solved in -rt) it
worked pretty well on generic PCs, so i dont buy the 'it doesnt work'
argument either.
Last time I tried it,
Hi,
On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote:
> OTOH, you also didn't supply a patch. If you do this, I'll be glad to
> consider it. If I can read it, that is.
"s|/bin/sh|/bin/bash" is so hard to do ?
Matthieu
PS : this remind me http://www.landley.net/code/firmware/ . Is it
Hi,
Pavel Machek wrote:
Hi!
Sujet : airo suspend problem
? : [EMAIL PROTECTED]
Hi,
the airo driver (drivers/net/wireless/airo.c) does in its suspend routine [1].
But not all the pci cards support power management and cause
pci_enable_wake/pci_set_power_state to return errors.
On
Hi,
Pavel Machek wrote:
Hi!
Sujet : airo suspend problem
? : [EMAIL PROTECTED]
Hi,
the airo driver (drivers/net/wireless/airo.c) does in its suspend routine [1].
But not all the pci cards support power management and cause
pci_enable_wake/pci_set_power_state to return errors.
On
Hi,
On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote:
OTOH, you also didn't supply a patch. If you do this, I'll be glad to
consider it. If I can read it, that is.
s|/bin/sh|/bin/bash is so hard to do ?
Matthieu
PS : this remind me http://www.landley.net/code/firmware/ . Is it so
Hi,
On Mon, 11 Jun 2007 12:00:34 -0700, Andrew Morton wrote:
> On Sat, 9 Jun 2007 15:08:17 +0200
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
>
> How does the beep get turned off again?
May be it is turn off by the speaker driver.
BTW can't we do something with led ? This way it can be
Hi Sam,
Sam Ravnborg wrote:
Hi Matthieu.
Can you please try to tell what your patch actually does.
As for the part added in the MAkefile you pass -lintl for Cygwin -
but I fail to see _why_ -lintl is needed.
If I don't do it, I got [1] or [2].
Matthieu
[1]
Hi Sam,
Sam Ravnborg wrote:
Hi Matthieu.
Can you please try to tell what your patch actually does.
As for the part added in the MAkefile you pass -lintl for Cygwin -
but I fail to see _why_ -lintl is needed.
If I don't do it, I got [1] or [2].
Matthieu
[1]
Hi,
On Mon, 11 Jun 2007 12:00:34 -0700, Andrew Morton wrote:
On Sat, 9 Jun 2007 15:08:17 +0200
Pavel Machek [EMAIL PROTECTED] wrote:
How does the beep get turned off again?
May be it is turn off by the speaker driver.
BTW can't we do something with led ? This way it can be always
Hi,
On Sat, 09 Jun 2007 16:53:32 +0200, Mikael Pettersson wrote:
> On Fri, 08 Jun 2007 10:14:03 +0200, Gerard H. Pille wrote:
>> [1.] One line summary of the problem: Since I switched from 2.6.20 to
>> 2.6.21 on my Athlon AMD64 laptop, the system time is slow - about 1' on
>> 15'.
>
> According
Hi,
On Sat, 09 Jun 2007 16:53:32 +0200, Mikael Pettersson wrote:
On Fri, 08 Jun 2007 10:14:03 +0200, Gerard H. Pille wrote:
[1.] One line summary of the problem: Since I switched from 2.6.20 to
2.6.21 on my Athlon AMD64 laptop, the system time is slow - about 1' on
15'.
According to your
Hi,
Sam Ravnborg a écrit :
On Mon, Jun 04, 2007 at 11:45:29AM -0700, Tom wrote:
Hi Sam
enclosed is the 'k_smf.patch' which modifies three files to enable the
kernel 2.6.21.3 to be built under cygwin:
host: cygwin 1.5.24, hostcc= gcc 3.4.4
cross: arm-linux-uclibcgnueabi-gcc (GCC) 4.1.2
Hi,
Sam Ravnborg a écrit :
On Mon, Jun 04, 2007 at 11:45:29AM -0700, Tom wrote:
Hi Sam
enclosed is the 'k_smf.patch' which modifies three files to enable the
kernel 2.6.21.3 to be built under cygwin:
host: cygwin 1.5.24, hostcc= gcc 3.4.4
cross: arm-linux-uclibcgnueabi-gcc (GCC) 4.1.2
Hi,
On Mon, 28 May 2007 18:24:18 +0100, Matthew Garrett wrote:
> From: Matthew Garrett <[EMAIL PROTECTED]>
>
> Intel Macs (and possibly other machines) provide a PNP entry for the
> RTC, but provide no IRQ. As a result the rtc-cmos driver doesn't allow
> wakeup alarms. If the RTC is located at
Hi,
On Mon, 28 May 2007 18:24:18 +0100, Matthew Garrett wrote:
From: Matthew Garrett [EMAIL PROTECTED]
Intel Macs (and possibly other machines) provide a PNP entry for the
RTC, but provide no IRQ. As a result the rtc-cmos driver doesn't allow
wakeup alarms. If the RTC is located at the
Hi,
Paa Paa hotmail.com> writes:
>
> But are you saying that with most desktop mobos one doesn't usually have the
> different power states available at all? So basically the only means to
> conserve power is to scale the frequency?
>
Even frequency is very limited on core 2 duo. Because of
Hi,
Paa Paa paapaa125 at hotmail.com writes:
But are you saying that with most desktop mobos one doesn't usually have the
different power states available at all? So basically the only means to
conserve power is to scale the frequency?
Even frequency is very limited on core 2 duo.
Hi,
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On arch that don't support aligned access, packed struct access will be
done byte per byte (but it could be the expected behavior if there
unaligned access).
When I tested this on ARM, the output
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
When I tested this on ARM, the output for je32_to_cpu et al was fine.
For _other_ structures where I'd
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
When I tested this on ARM, the output for je32_to_cpu et al was fine.
For _other_ structures where I'd
Hi,
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On arch that don't support aligned access, packed struct access will be
done byte per byte (but it could be the expected behavior if there
unaligned access).
When I tested this on ARM, the output
On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
> On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> <[EMAIL PROTECTED]> wrote:
>
> umm.. I'd say what you've done in there is an improvement to the
> exiting stuff: getting gcc to check it is better than having to use
> sparse.
>
>
On Thu, 17 May 2007 16:32:01 +0200, Christoph Hellwig wrote:
> Kill ubis homegrown endianess handling crap and replace it with the
> normal kernel endianess handling.
>
Hum, you should check about alignment stuff.
Jffs2 use a similar mechanism and the packed struct also take care of
some
1 - 100 of 166 matches
Mail list logo
