Is there anyway to have something easily done about it upstream ? Would the
license be an issue if there's any about it ? Where should i contact to try
to see if they can include it upstream ? Thank you. Regards -HerbalNekoTea
On Sat, Apr 24, 2021 at 1:51 AM Valdis Klētnieks
wrote:
> On Sat, 24
Thank you so much for kindly explaining the problem!
as Wonhyuk Yang and Max Filippov said, I didn't consider the case that
interrupt handler holds same lock.
there can be deadlock as you said.
2021년 4월 23일 (금) 오후 3:45, Max Filippov 님이 작성:
>
> On Thu, Apr 22, 2021 at 11:28 PM Wonhyuk Yang
On Sat, 24 Apr 2021 01:36:13 -0400, HerbalNekoTea said:
> Hi, i have kinda found a method a couple years ago to import the Japanese
> Shift-JIS encoding from Fedora/CentOS/RHEL/OpenSuse to any other
> distribution and i keep forgetting to maintain the sideloading method when
> the kernel update
Hi, i have kinda found a method a couple years ago to import the Japanese
Shift-JIS encoding from Fedora/CentOS/RHEL/OpenSuse to any other
distribution and i keep forgetting to maintain the sideloading method when
the kernel update broke it.
A lot of Japanese content for Windows, who are able to
On Fri, 23 Apr 2021 15:45:54 +0900, JeongHwan Kim said:
> I'm testing packet flooding test with old kernel version 2.6.30.
[/usr/src/linux-next] git show v2.6.30 | grep Date
Date: Tue Jun 9 20:05:37 2009 -0700
[/usr/src/linux-next] git diff --shortstat v2.6.30..HEAD
82911 files changed,
Hi, everyone
I'm testing packet flooding test with old kernel version 2.6.30.
My board experienced process starvation when injecting ICMP flood with hping3
tool.
I modified softirq invocation routine to launch ksoftirqd instead of executing
do_softirq
and I limitted the speed of ethernet phy
On Thu, Apr 22, 2021 at 11:28 PM Wonhyuk Yang wrote:
> > I think the main idea spinlock disables preemption is,
>
> > the other process that's spinning on the lock can acquire lock.
>
> > but in some implementations of spinlock, like qspinlock in x86 (or mcs
> > lock),
> > I think there's no
Hi,
> I think the main idea spinlock disables preemption is,
> the other process that's spinning on the lock can acquire lock.
> but in some implementations of spinlock, like qspinlock in x86 (or mcs
lock),
> I think there's no need to disable preemption. because processes
> waiting for lock