Dear Miklos
Hi ，I read the fuse code in linux kernel，and I have some question about the
code blow：
static int fuse_read_interrupt(struct fuse_iqueue *fiq,
struct fuse_copy_state *cs,
size_t nbytes, struct fuse_req *req)
__releases
Hi, Thomas
I canceled that patch. In my testing, that will not fix the problem.
Why the IRQ is unexpectedly masked, that is not an easy bug for me.
More time need to hacking the driver/kernel code.
Thanks for your reply.
Thomas Gleixner 于2019年10月14日周一 下午8:34写道：
>
> On Tue, 8 Oct 2019, Yi Zheng
On Tue, 8 Oct 2019, Yi Zheng wrote:
> There is some defects on IRQ processing:
>
> (1) At the beginning of handle_level_irq(), the IRQ-28 is masked, and ACK
> action is executed: On my machine, it runs the 'else' branch:
>
> static inline void mask_ack_irq(struct ir
* Yi Zheng [191010 06:22]:
> Hi
>
>My patch is canceled. I have tested that simple adjustment, the
> device IRQ masked unexpectedly. It seems that it is more easily to
> occur with that patch.
>
> So, the root cause is not found yet.
OK. Based on your description, it could be a missing flus
Hi
My patch is canceled. I have tested that simple adjustment, the
device IRQ masked unexpectedly. It seems that it is more easily to
occur with that patch.
So, the root cause is not found yet.
Hi,
* Yi Zheng [191008 13:06]:
> NOTE: (1) My SoC is a single core ARM chip: TI-AM3352, so the raw
> spin-lock irq_desc->lock will be optimized to
> nothing. handle_level_irq() has no spin-lock protection, right?
Well not always, With CONFIG_SMP we modify only some of the
Hi,
I found something wrong on my AM3352 SoC machine, the GPIO triggered IRQ is
masked unexpectedly. That bug cause the devices using that GPIO-IRQ can
not work. Even the latest kernel version (v5.4-rc2-20-geda57a0e4299)!
After a long time hacking, I guess the bug is in kerne
Hi,
I found something wrong on my AM3352 SoC machine, the GPIO
triggered IRQ is masked
unexpectedly. That bug cause the devices using that GPIO-IRQ can
not work. Even the
latest kernel version (v5.4-rc2-20-geda57a0e4299)!
After a long time hacking, I guess the bug is in
kerne
Hi, Bill
For below SELinux behavior, do you know why.
BR.
Ning.
在 2018-02-28三的 14:47 +0800，Zhang Ning写道：
> Hi,
>
> Before SELinux is initialized, get scontext by secid by using:
>
> security_secctx_to_secid() may return wrong numbe
>
> eg:
> security_secctx_to_secid("devnull", strlen("devnul
Hi,
Before SELinux is initialized, get scontext by secid by using:
security_secctx_to_secid() may return wrong numbe
eg:
security_secctx_to_secid("devnull", strlen("devnull"), &sid);
sid here will be 1
because:
in security_context_to_sid_core:
...
if (!ss_initialized) {
On Tue, 6 Nov 2014 21:01:00
"Jesper" wrote:
>There is several issues with your submission. I'll take care of
resubmitting a patch in your name (so you will get credit in the git log).
>
>If you care to know, issues are:
>1. you are not sending to the appropriate mailing lists, 2. patch is as a
On Tue, 4 Nov 2014 09:48:32 +0800
"billbonaparte" wrote:
> (sorry to send this e-mail again, last mail is rejected by server due to
> non-acceptable content)
There is several issues with your submission. I'll take care of
resubmitting a patch in your name (so you will get credit in the git
log)
(sorry to send this e-mail again, last mail is rejected by server due to
non-acceptable content)
Florian Westphal [mailto:f...@strlen.de] wrote:
>Correct. This is broken since the central spin lock removal, since
>nf_conntrack_lock no longer protects both get_next_corpse and
>conntrack_confirm.
On Tue, 28 Oct 2014 11:37:31 +0800 "billbonaparte"
wrote:
> Hi, all:
> sorry for sending this mail again, the last mail doesn't show text
> clearly.
This one also mangles the text, so I cannot follow the race you are
describing. I'll try to reconstruct...
> In function __nf_conntrack_confirm
billbonaparte wrote:
> In function __nf_conntrack_confirm, we check the conntrack if it was
> alreay dead, before insert it into hash-table.
> we do this because if we insert an already 'dead' hash, it will
> block further use of that particular connection.
> but we don't do th
Hi, all:
sorry for sending this mail again, the last mail doesn't show text
clearly.
In function __nf_conntrack_confirm, we check the conntrack if it was
alreay dead, before insert it into hash-table.
we do this because if we insert an already 'dead' hash, it will
block fu
Hi, all:
In function __nf_conntrack_confirm, we check the conntrack if it was
alreay dead, before insert it into hash-table.
we do this because if we insert an already 'dead' hash, it will
block further use of that particular connection.
but we don't do that right.
let
Just to alert potential readers, that the bug is now discussed there :
http://bugzilla.kernel.org/show_bug.cgi?id=8143
Eric Lacombe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ke
Hello,
I've just triggered the bug again but _now_ without the nvidia proprietary
module. Unfortunately, I hadn't enable the DEBUG options yet.
Nevertheless, It seems that the bug was triggered when the NAS was going to
awake and that 2 user applications wanted to access it during his awakening
Eric Lacombe <[EMAIL PROTECTED]> :
[...]
> Also, if you have some new ideas about the problem or what I could try to
> trigger it more frequently (I already wake up the NAS as more as I can, but
> maybe I could write a script to do that), I would be thankful.
You can add more DEBUG options for s
Hello,
Sorry for the long time without giving new information about the problem/bug,
but I wasn't able to trigger it since now.
Well, this time, my system freeze on a 2.6.20.1.
I try to use the magic sysrq (which works fine when my system is running), but
nothing happen (unraw, reboot, etc.).
On Tuesday 13 February 2007 21:30:47 Francois Romieu wrote:
> Eric Lacombe <[EMAIL PROTECTED]> :
> [...]
>
> > That problem also remind me that when I compiled this driver without
> > the "CONFIG_NET_ETHERNET" (in the section "Ethernet (10 or 100Mbit)"), I
> > have really poor performance with the
Eric Lacombe <[EMAIL PROTECTED]> :
[...]
> That problem also remind me that when I compiled this driver without
> the "CONFIG_NET_ETHERNET" (in the section "Ethernet (10 or 100Mbit)"), I have
> really poor performance with the net device. Maybe it is related, or not ;)
>
> If it gives you more i
Maciej W. Rozycki wrote:
> Hmm, you state the watchdog works from time to time and the log you
> provided confirms the statement -- it reports:
> > ..TIMER: vector=49 pin1=2 pin2=0
> > activating NMI Watchdog ... done.
Yes, but I reach this message only once of 10 trials to boot. The other nin
On Mon, 19 Feb 2001, Matthias Kleine wrote:
> The problem appears on a machine using the pretty new ASUS CUVX-D Dual Socket
> 370 Motherboard, so there may be a chance for an unknown bug ;-). With NMI
> watchdog activated, a 2.4.x Kernel is not willing to boot on this machine, it
> just stops
>
> Feb 19 19:37:17 delphin kernel: testing the IO APIC...
> Feb 19 19:37:17 delphin kernel:
> Feb 19 19:37:17 delphin kernel: WARNING: unexpected IO-APIC, please mail
> Feb 19 19:37:17 delphin kernel: to [EMAIL PROTECTED]
> Feb 19 19:37:17 delphin kernel: ..
Dear kernel-developers,
I do not have any experience in kernel programming, but I do have a message
in my /var/log/messages file which advices me to post to this list. This is
the first time for me to visit this list, so don't be too hard too me if this
posting doesn't fit into the common list
27 matches
Mail list logo
