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
Sorry for the extra noise on the recent DT patch series posts. It seems
my patch posting scripts malfunctioned.
- Paul
Hi! Just to let everyone know: I won't do regression tracking this
development cycle. I have some travel and some "away from keyboard"
vacation days coming up; that combination doesn't leave enough spare
time in the next few weeks to do regression tracking properly. Sorry. :-/
Sorry about that; I accidentally did a git send-email with some older
patches leftover in my patch folder. Just ignore this thread
On Fri, 2016-06-24 at 17:45 -0400, Lyude wrote:
> Latest version of:
>
> https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.htm
> l
&
From: Sergey Popov < popov_ser...@ukr.net >
Prevent increase of console_loglevel by 'quiet'
'quiet' kernel option that follows the 'loglevel=N' should
not blindly overwrite console_loglevel, instead it should
respect and keep lower 'loglevel'.
Signed-off-by: Sergey Popov < popov_ser...@ukr.net >
ect line is wrong, you need to add the subsystem "crypto:" and the
subject must be simplier; but you could keep the actual subject as a commit
message
[PATCH] crypto: Fix a typo in ahash.c
"its" == "something belong to it". "it's" == "it is"
From: edent
Signed-off-by: edent
---
crypto/ahash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/ahash.c b/crypto/ahash.c
index f6a36a5..ffbcda3 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -271,7 +271,7 @@ static int ahash_save_req(struct ahash_request *req
On 11/26/2012 06:54 AM, Kinney, Steven wrote:
> Hi Andreas,
>
> This is your quirk, from AMD, and if you need to
> sign the patch please let me know how to facilitate this. I will add Joerg
> using his Email.
>
Please maintain the proper patch authorship. This is
; linux-kernel@vger.kernel.org;
io...@lists.linux-foundation.org
Subject: Re: Re-send the AMD IOMMUv2 performance counter patched and PCI quirk.
Sorry for the noise.
Hi Steven,
Hmm, the quirk looks quite familiar to me.
IMHO you should (re-?)read Documentation/SubmittingPatches.
(esp. no
Hi Steven,
Hmm, the quirk looks quite familiar to me.
IMHO you should (re-?)read Documentation/SubmittingPatches.
(esp. no attachements, and btw one patch per mail)
Do you mind adding Joerg with his current (non-AMD) mail address on
CC? Otherwise it's impossible to get any comment from him.
An
Resending previous AMD IOMMUv2 patches due to improper extension on second
patch.
>From 760e18a02c0bb7eb5f5e3ebc192d43931f4c753b Mon Sep 17 00:00:00 2001
From: "Steven L. Kinney"
Date: Fri, 16 Nov 2012 15:27:47 -0600
Subject: [PATCH] iommuv2/amd: Add quirk for AMD 15H_M10 IOMMUv2 Performance
Coun
Hi all.
Sorry for all of the copies.
I was holding the message in the outbox, and double clicking on it, trying to
get the encoding right in kmail. Needless to say now, it lied to me about
whether it was keeping the previous copy of email in the outbox or not.
Nigel
pgpSf0dckH1fV.pgp
i'll refrain from any more posting until i *know* it's fixed.
rday
-
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.or
I'm sorry with the lkml users for the unwanted noise. I did a mistake
with my mail client.
Francesco
2007/3/2, Francesco Pretto <[EMAIL PROTECTED]>:
I'll send you a message of the thread. You only have to answer it
(with reply-to function of your browser) changing the TO: ad
I finally re-ran memtest86 on the machine since it began to have too
many different kind of errors (GPF, invalid instruction...). It turned
out that one of the memory modules was bad. I guess my brand new
list_debug race condition debugger will be useful in the future, but not
now. :)
I'll reme
* Martin J. Bligh ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >Hi,
> >
> >Trying to build cross-compilers (or kernels) on a 2-way x86_64 (amd64) with
> >make -j3 triggers the following OOPS after about 30 minutes on
> >2.6.19.2. Due to the amount of time and the heavy load it takes befo
Dear all,
I want to get socket information by the sockfd while accetping,
so I write a module to test sockfd_lookup(),
but I got some problems when I test it.
kernel version: 2.4.20-8smp(RedHat9) and 2.4.26 are tried
ftp server: vsftp 1.1.3-8 and wuftp 2.6.1-20 are tried
I hope someone c
-
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.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sorry about that, that last email had an old address on it, this address should work
for replies/cc's:
[EMAIL PROTECTED]
-
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://
I'm sure this isn't the address to send this to, but I
don't know where to send this.
I just upgraded from 2.4.0-test12 to 2.4.0, and I got a
kernel panac after about 6 hours. Then updated to 2.4.0-ac4
and got a massive amount of scsi errors. The server was again
up for about 6 hours. This w
3, but I don't believe that that is the problem.
THE QUESTION:
-
How do I fix this, or is it a (un)known problem in the newer development
versions? If you have the answer, could you please CC me as well for I don't
subscribe to this mailing list (sorry!). Thanks a bunch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Hello All , on a compaq proliant 6000, 4 ppro 200Mhz 512k cpu's,
4.3Gb seagate system drive attached to onboard 53c875 ctrlr,
Smart Array 2/P, 392Mb, 4 18.Gb seagate st118273 raid 5,
Digital DE500(tulip), 3.5 Floppy, ide cdrom .
since I have upgraded from
I'm sorry 4 posting the article in italian and abusing of the kernel mailng
list.
Good work!
--
Have a nice day,
Guido Trentalancia
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at htt
Sorry to send the letter to the wrong place.Specially thanks to
R.B.Johnson,B.Halley,S.Vandevender,M.Kreen,dave,E.Mouw.I'll never do this
stupid thing.
BTW:Could you read this message correctly?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
hi,
i'm working on this
On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
>
> Well,
> I thought the problems with the eepro driver from 2.2.16 were fixed in
> 2.2.17. Apparently the problems really weren't fixed - it did seem to get
> more stable though.
>
> I was copying some large over a
Well,
I thought the problems with the eepro driver from 2.2.16 were fixed in
2.2.17. Apparently the problems really weren't fixed - it did seem to get
more stable though.
I was copying some large over a NFS mount and when it got to about 6 megs,
the NFS mount hung with symptoms similar to the 2
32 matches
Mail list logo
