[AMD Public Use]
> -Original Message-
> From: Thomas “illwieckz“ Debesse
> Sent: Monday, November 9, 2020 6:41 AM
> To: LKML
> Cc: Koenig, Christian ; Deucher, Alexander
>
> Subject: On disabling AGP without working alternative (PCI fallback is
> broken for years)
>
> Hi, on May 12 2
Hi Thomas,
Am 09.11.20 um 12:40 schrieb Thomas “illwieckz“ Debesse:
Hi, on May 12 2020, a commit (ba806f9) was merged disabling AGP
in default build.
It was signed-off by Christian König and Reviewed by Alex Deucher.
Distributions started to backport this commit, and it seems to have
happened w
On Thu, Jul 11, 2019 at 5:01 PM Carlo Wood wrote:
>
> I believe that the only safe solution is to let the Event Loop
> Thread do the deleting. So, if all else fails I'll have to add
> objects that a Worker Thread thinks need to be deleted to a
> FIFO that is processed by the Event Loop Thread befo
On Tue, Apr 02, 2019 at 04:43:03PM -0700, Alexander Duyck wrote:
> Yes, but hopefully it should be a small enough amount that nobody will
> notice. In many cases devices such as NICs can consume much more than
> this regularly for just their Rx buffers and it is not an issue. There
> has to be a ce
On 03.04.19 01:43, Alexander Duyck wrote:
> On Tue, Apr 2, 2019 at 11:53 AM David Hildenbrand wrote:
>>
> Why do we need them running in parallel for a single guest? I don't
> think we need the hints so quickly that we would need to have multiple
> VCPUs running in parallel to provide
On Tue, Apr 2, 2019 at 11:53 AM David Hildenbrand wrote:
>
> >>> Why do we need them running in parallel for a single guest? I don't
> >>> think we need the hints so quickly that we would need to have multiple
> >>> VCPUs running in parallel to provide hints. In addition as it
> >>> currently stan
On 02.04.19 21:49, Michael S. Tsirkin wrote:
> On Tue, Apr 02, 2019 at 08:21:30PM +0200, David Hildenbrand wrote:
>> The other extreme is a system that barely frees (MAX_ORDER - X) pages,
>> however your thread will waste cycles scanning for such.
>
> I don't think we need to scan as such. An arch
On Tue, Apr 2, 2019 at 10:53 AM Michael S. Tsirkin wrote:
>
> On Tue, Apr 02, 2019 at 10:45:43AM -0700, Alexander Duyck wrote:
> > We went through this back in the day with
> > networking. Adding more buffers is not the solution. The solution is
> > to have a way to gracefully recover and keep our
On Tue, Apr 02, 2019 at 08:21:30PM +0200, David Hildenbrand wrote:
> The other extreme is a system that barely frees (MAX_ORDER - X) pages,
> however your thread will waste cycles scanning for such.
I don't think we need to scan as such. An arch hook
that queues a job to a wq only when there's wor
>>> Why do we need them running in parallel for a single guest? I don't
>>> think we need the hints so quickly that we would need to have multiple
>>> VCPUs running in parallel to provide hints. In addition as it
>>> currently stands in order to get pages into and out of the buddy
>>> allocator we
On 02.04.19 19:45, Alexander Duyck wrote:
> On Tue, Apr 2, 2019 at 10:09 AM David Hildenbrand wrote:
>>
>> On 02.04.19 18:18, Alexander Duyck wrote:
>>> n Tue, Apr 2, 2019 at 8:57 AM David Hildenbrand wrote:
On 02.04.19 17:25, Michael S. Tsirkin wrote:
> On Tue, Apr 02, 2019 at 08:0
On Tue, Apr 02, 2019 at 10:45:43AM -0700, Alexander Duyck wrote:
> We went through this back in the day with
> networking. Adding more buffers is not the solution. The solution is
> to have a way to gracefully recover and keep our hinting latency and
> buffer bloat to a minimum.
That's an interest
On Tue, Apr 2, 2019 at 10:09 AM David Hildenbrand wrote:
>
> On 02.04.19 18:18, Alexander Duyck wrote:
> > n Tue, Apr 2, 2019 at 8:57 AM David Hildenbrand wrote:
> >>
> >> On 02.04.19 17:25, Michael S. Tsirkin wrote:
> >>> On Tue, Apr 02, 2019 at 08:04:00AM -0700, Alexander Duyck wrote:
> Ba
On Tue, Apr 2, 2019 at 8:56 AM David Hildenbrand wrote:
>
> On 02.04.19 17:04, Alexander Duyck wrote:
> > On Tue, Apr 2, 2019 at 12:42 AM David Hildenbrand wrote:
> >>
> >> On 01.04.19 22:56, Alexander Duyck wrote:
> >>> On Mon, Apr 1, 2019 at 7:47 AM Michael S. Tsirkin wrote:
>
> On M
On 02.04.19 18:18, Alexander Duyck wrote:
> n Tue, Apr 2, 2019 at 8:57 AM David Hildenbrand wrote:
>>
>> On 02.04.19 17:25, Michael S. Tsirkin wrote:
>>> On Tue, Apr 02, 2019 at 08:04:00AM -0700, Alexander Duyck wrote:
Basically what we would be doing is providing a means for
incremental
On 02.04.19 17:04, Alexander Duyck wrote:
> On Tue, Apr 2, 2019 at 12:42 AM David Hildenbrand wrote:
>>
>> On 01.04.19 22:56, Alexander Duyck wrote:
>>> On Mon, Apr 1, 2019 at 7:47 AM Michael S. Tsirkin wrote:
On Mon, Apr 01, 2019 at 04:11:42PM +0200, David Hildenbrand wrote:
>> The
n Tue, Apr 2, 2019 at 8:57 AM David Hildenbrand wrote:
>
> On 02.04.19 17:25, Michael S. Tsirkin wrote:
> > On Tue, Apr 02, 2019 at 08:04:00AM -0700, Alexander Duyck wrote:
> >> Basically what we would be doing is providing a means for
> >> incrementally transitioning the buddy memory into the idl
On 02.04.19 17:25, Michael S. Tsirkin wrote:
> On Tue, Apr 02, 2019 at 08:04:00AM -0700, Alexander Duyck wrote:
>> Basically what we would be doing is providing a means for
>> incrementally transitioning the buddy memory into the idle/offline
>> state to reduce guest memory overhead. It would requi
On 02.04.19 17:04, Alexander Duyck wrote:
> On Tue, Apr 2, 2019 at 12:42 AM David Hildenbrand wrote:
>>
>> On 01.04.19 22:56, Alexander Duyck wrote:
>>> On Mon, Apr 1, 2019 at 7:47 AM Michael S. Tsirkin wrote:
On Mon, Apr 01, 2019 at 04:11:42PM +0200, David Hildenbrand wrote:
>> The
On Tue, Apr 02, 2019 at 08:04:00AM -0700, Alexander Duyck wrote:
> Basically what we would be doing is providing a means for
> incrementally transitioning the buddy memory into the idle/offline
> state to reduce guest memory overhead. It would require one function
> that would walk the free page li
On Tue, Apr 2, 2019 at 12:42 AM David Hildenbrand wrote:
>
> On 01.04.19 22:56, Alexander Duyck wrote:
> > On Mon, Apr 1, 2019 at 7:47 AM Michael S. Tsirkin wrote:
> >>
> >> On Mon, Apr 01, 2019 at 04:11:42PM +0200, David Hildenbrand wrote:
> The interesting thing is most probably: Will the
On 01.04.19 22:56, Alexander Duyck wrote:
> On Mon, Apr 1, 2019 at 7:47 AM Michael S. Tsirkin wrote:
>>
>> On Mon, Apr 01, 2019 at 04:11:42PM +0200, David Hildenbrand wrote:
The interesting thing is most probably: Will the hinting size usually be
reasonable small? At least I guess a gues
On Mon, Apr 1, 2019 at 7:47 AM Michael S. Tsirkin wrote:
>
> On Mon, Apr 01, 2019 at 04:11:42PM +0200, David Hildenbrand wrote:
> > > The interesting thing is most probably: Will the hinting size usually be
> > > reasonable small? At least I guess a guest with 4TB of RAM will not
> > > suddenly ge
On 01.04.19 16:47, Michael S. Tsirkin wrote:
> On Mon, Apr 01, 2019 at 04:11:42PM +0200, David Hildenbrand wrote:
>>> The interesting thing is most probably: Will the hinting size usually be
>>> reasonable small? At least I guess a guest with 4TB of RAM will not
>>> suddenly get a hinting size of h
On Mon, Apr 01, 2019 at 04:11:42PM +0200, David Hildenbrand wrote:
> > The interesting thing is most probably: Will the hinting size usually be
> > reasonable small? At least I guess a guest with 4TB of RAM will not
> > suddenly get a hinting size of hundreds of GB. Most probably also only
> > some
On Mon, Apr 01, 2019 at 04:09:32PM +0200, David Hildenbrand wrote:
> >
> > When you say yield, I would guess that would involve config space access
> > to the balloon to flush out outstanding hints?
>
> I rather meant yield your CPU to the hypervisor, so it can process
> hinting requests faster (
On 01.04.19 16:09, David Hildenbrand wrote:
>>> Thinking about your approach, there is one elementary thing to notice:
>>>
>>> Giving the guest pages from the buffer while hinting requests are being
>>> processed means that the guest can and will temporarily make use of more
>>> memory than desired
>> Thinking about your approach, there is one elementary thing to notice:
>>
>> Giving the guest pages from the buffer while hinting requests are being
>> processed means that the guest can and will temporarily make use of more
>> memory than desired. Essentially up to the point where MADV_FREE is
On Mon, Apr 01, 2019 at 10:17:51AM +0200, David Hildenbrand wrote:
> On 29.03.19 17:51, Michael S. Tsirkin wrote:
> > On Fri, Mar 29, 2019 at 04:45:58PM +0100, David Hildenbrand wrote:
> >> On 29.03.19 16:37, David Hildenbrand wrote:
> >>> On 29.03.19 16:08, Michael S. Tsirkin wrote:
> On Fri,
On 29.03.19 17:51, Michael S. Tsirkin wrote:
> On Fri, Mar 29, 2019 at 04:45:58PM +0100, David Hildenbrand wrote:
>> On 29.03.19 16:37, David Hildenbrand wrote:
>>> On 29.03.19 16:08, Michael S. Tsirkin wrote:
On Fri, Mar 29, 2019 at 03:24:24PM +0100, David Hildenbrand wrote:
>
> We ha
On Fri, Mar 29, 2019 at 04:45:58PM +0100, David Hildenbrand wrote:
> On 29.03.19 16:37, David Hildenbrand wrote:
> > On 29.03.19 16:08, Michael S. Tsirkin wrote:
> >> On Fri, Mar 29, 2019 at 03:24:24PM +0100, David Hildenbrand wrote:
> >>>
> >>> We had a very simple idea in mind: As long as a hinti
On Fri, Mar 29, 2019 at 04:37:46PM +0100, David Hildenbrand wrote:
> Just so we understand each other. What you mean with "appended to guest
> memory" is "append to the guest memory size", not actually "append
> memory via virtio-balloon", like adding memory regions and stuff.
>
> Instead of "-m 4
On 29.03.19 16:37, David Hildenbrand wrote:
> On 29.03.19 16:08, Michael S. Tsirkin wrote:
>> On Fri, Mar 29, 2019 at 03:24:24PM +0100, David Hildenbrand wrote:
>>>
>>> We had a very simple idea in mind: As long as a hinting request is
>>> pending, don't actually trigger any OOM activity, but wait
On 29.03.19 16:08, Michael S. Tsirkin wrote:
> On Fri, Mar 29, 2019 at 03:24:24PM +0100, David Hildenbrand wrote:
>>
>> We had a very simple idea in mind: As long as a hinting request is
>> pending, don't actually trigger any OOM activity, but wait for it to be
>> processed. Can be done using simpl
On Fri, Mar 29, 2019 at 03:24:24PM +0100, David Hildenbrand wrote:
>
> We had a very simple idea in mind: As long as a hinting request is
> pending, don't actually trigger any OOM activity, but wait for it to be
> processed. Can be done using simple atomic variable.
>
> This is a scenario that wi
On 29.03.19 14:26, Michael S. Tsirkin wrote:
> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>> The following patch-set proposes an efficient mechanism for handing freed
>> memory between the guest and the host. It enables the guests with no page
>> cache to rapidly free and
On Tue, 5 Mar 2019, Andy Shevchenko wrote:
CC+ PeterZ
> I have an Intel Merrifield platform where from time to time (don't
> know how to reproduce reliably) I have got a warning on reboot.
>
> Requesting system reboot
> [ 64.945973] reboot: Restarting system
> [ 64.950770] reboot: machine re
On Thu, Feb 07, 2019 at 01:37:16AM +, Artem S. Tashkinov wrote:
> Hello LKML,
>
> Is there a serious reason why CPU MSR is write protected in UEFI secure boot
> mode in Linux?
> * In order to even use MSR you have to be root to `modprobe msr`.
> * In order to read/write from/to MSR you have
You hijacked Eric's thread and forgot to CC him?
On Thu, Oct 11, 2018 at 12:49 AM wrote:
>
> Three avenues to rescind GPLv2 property. RAP strategy added.
>
>
> Here's a case in NY where a Software distributor agreement violated New
> York's Rule Against Perpetuities
> McAllister Software Systems,
Three avenues to rescind GPLv2 property. RAP strategy added.
Here's a case in NY where a Software distributor agreement violated New
York's Rule Against Perpetuities
McAllister Software Systems, Inc. v. Henry Schein, Inc., No. 06-0093,
2008 WL 922328 (E.D. Mo. April 2, 2008)
So we see that a
On 4/16/2018 5:55 PM, \0xDynamite wrote:
> > The current kernel numbering scheme makes no sense at all because the
>> first two numbers don't represent anything at all. They had some meaning
>> back in the 1.x 2.x 3.x days but then with the introduction of the new
>> rolling development model, the
> The current kernel numbering scheme makes no sense at all because the
> first two numbers don't represent anything at all. They had some meaning
> back in the 1.x 2.x 3.x days but then with the introduction of the new
> rolling development model, they became worthless.
>
> I'd love to change the
On 06/09/17 10:05, Corcodel Marian wrote:
> Hi
>
> I compiled kernel with ZONE_DEVICE undefined , but on expect line "#
> CONFIG_ZONE_DEVICE is not set " , instead of nothing.
>
That looks normal (correct) to me.
Are you experiencing a particular problem? If so, please describe it.
--
~Rand
On Wed, Apr 12, 2017 at 10:28:08PM +0200, luca abeni wrote:
> On Wed, 12 Apr 2017 16:28:02 +0100
> Juri Lelli wrote:
>
> > Hi Paul,
> >
> > On 12/04/17 08:15, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > On the unlikely off-chance that this is new news...
> > >
> >
> > It is actually ne
On Wed, 12 Apr 2017 16:28:02 +0100
Juri Lelli wrote:
> Hi Paul,
>
> On 12/04/17 08:15, Paul E. McKenney wrote:
> > Hello!
> >
> > On the unlikely off-chance that this is new news...
> >
>
> It is actually new news for me (it might be still unlikely for Peter,
> Luca and Tommaso, that I Cc-e
On Wed, Apr 12, 2017 at 04:28:02PM +0100, Juri Lelli wrote:
> Hi Paul,
>
> On 12/04/17 08:15, Paul E. McKenney wrote:
> > Hello!
> >
> > On the unlikely off-chance that this is new news...
>
> It is actually new news for me (it might be still unlikely for Peter,
> Luca and Tommaso, that I Cc-ed)
Hi Paul,
On 12/04/17 08:15, Paul E. McKenney wrote:
> Hello!
>
> On the unlikely off-chance that this is new news...
>
It is actually new news for me (it might be still unlikely for Peter,
Luca and Tommaso, that I Cc-ed).
> A Hannes Weisbach of TU Dresden published this masters thesis on
> qua
On Tue, 29 Dec 2015, Andrey Utkin wrote:
> On Tue, Dec 29, 2015 at 9:32 AM, Mauro Carvalho Chehab
> wrote:
> > IMHO, there are two problems by letting indent breaking long
> > lines:
> >
> > 1) indent would break strings on printks. This is something that we don't
> > want to break strings on m
On Tue, Dec 29, 2015 at 9:32 AM, Mauro Carvalho Chehab
wrote:
> IMHO, there are two problems by letting indent breaking long
> lines:
>
> 1) indent would break strings on printks. This is something that we don't
> want to break strings on multiple lines in the Kernel;
Yeah, GNU indent does its wo
Em Mon, 28 Dec 2015 07:33:32 -0800
Greg KH escreveu:
> On Mon, Dec 28, 2015 at 04:33:27PM +0200, Andrey Utkin wrote:
> > After some iterations of checkpatch.pl, on a new developed driver
> > (tw5864), now I have the following:
> >
> > $ grep 'WARNING\|ERROR' /src/checkpatch.tw5864 | sort | uniq
On Mon, Dec 28, 2015 at 04:33:27PM +0200, Andrey Utkin wrote:
> After some iterations of checkpatch.pl, on a new developed driver
> (tw5864), now I have the following:
>
> $ grep 'WARNING\|ERROR' /src/checkpatch.tw5864 | sort | uniq -c
> 31 ERROR: do not use C99 // comments
> 147 WARNING
On 14/05/15 23:12, Doug Smythies wrote:
> On 2015.05.14 10:48 Ingo Molnar wrote:
>
>> * Juri Lelli wrote:
On 14/05/15 15:41, Doug Smythies wrote:
As of, or about, Kernel 4.1RC1 on resume from suspend only CPU 0 comes
back on-line.
The issue persists through Kernel 4.1RC3.
>>>
* Doug Smythies wrote:
> On 2015.05.14 10:48 Ingo Molnar wrote:
>
> > * Juri Lelli wrote:
> >>> On 14/05/15 15:41, Doug Smythies wrote:
> >>> As of, or about, Kernel 4.1RC1 on resume from suspend only CPU 0 comes
> >>> back on-line.
> >>> The issue persists through Kernel 4.1RC3.
> >>> This i
On 2015.05.14 10:48 Ingo Molnar wrote:
> * Juri Lelli wrote:
>>> On 14/05/15 15:41, Doug Smythies wrote:
>>> As of, or about, Kernel 4.1RC1 on resume from suspend only CPU 0 comes back
>>> on-line.
>>> The issue persists through Kernel 4.1RC3.
>>> This is on my test computer with an i7-2600K.
>>
* Juri Lelli wrote:
> Hi Doug,
>
> On 14/05/15 15:41, Doug Smythies wrote:
> > As of, or about, Kernel 4.1RC1 on resume from suspend only CPU 0 comes back
> > on-line.
> > The issue persists through Kernel 4.1RC3.
> > This is on my test computer with an i7-2600K.
> > I do not normally use susp
Hi Doug,
On 14/05/15 15:41, Doug Smythies wrote:
> As of, or about, Kernel 4.1RC1 on resume from suspend only CPU 0 comes back
> on-line.
> The issue persists through Kernel 4.1RC3.
> This is on my test computer with an i7-2600K.
> I do not normally use suspend on this computer, but was doing so
On Mon, Apr 20, 2015 at 3:45 PM, Krzysztof Hałasa wrote:
> Andrey Utkin writes:
>
>> Please check first digit. I mean _5_864, in your post there's 6869.
>
> Ok, I just thought it may be a typo. I can now see 5864 is a H.264
> encoder, while 686x are simpler frame-grabbers only.
>
> Sorry for the
Andrey Utkin writes:
> Please check first digit. I mean _5_864, in your post there's 6869.
Ok, I just thought it may be a typo. I can now see 5864 is a H.264
encoder, while 686x are simpler frame-grabbers only.
Sorry for the noise.
--
Krzysztof Halasa
Research Institute for Automation and Mea
Andrey Utkin writes:
> I am starting a work on driver for techwell tw5864 media grabber&encoder.
If this is tw6864 then I have a driver mostly completed.
Actually I'm using tw6869 but I think this is very similar (4 channels
instead of 8 and PCI instead of PCIe). I have 6864s but haven't yet
tri
On Mon, Apr 20, 2015 at 2:18 PM, Krzysztof Hałasa wrote:
> Andrey Utkin writes:
>
>> I am starting a work on driver for techwell tw5864 media grabber&encoder.
>
> If this is tw6864 then I have a driver mostly completed.
> Actually I'm using tw6869 but I think this is very similar (4 channels
> in
On Sun, Apr 19, 2015 at 11:28 AM, Hans Verkuil wrote:
> Check the types of llmio and bbmio:
>
> u32 __iomem *lmmio;
> u8 __iomem *bmmio;
>
> So the values of the pointers are the same, but the types are not.
>
> So 'lmmio + 1' == 'bmmio + si
On 04/19/2015 09:36 AM, Andrey Utkin wrote:
> I am starting a work on driver for techwell tw5864 media grabber&encoder.
> I am basing on tw68 driver (mentorship, advising and testing by board
> owners are appreciated). And here (and in some other
> drivers/media/pci/ drivers) I see what confuses me
On Wed, Jun 25, 2014 at 10:18:36AM -0400, Tejun Heo wrote:
> Hello, Dave.
>
> On Wed, Jun 25, 2014 at 03:56:41PM +1000, Dave Chinner wrote:
> > Hmmm - that's different from my understanding of what the original
> > behaviour WQ_MEM_RECLAIM gave us. i.e. that WQ_MEM_RECLAIM
> > workqueues had a res
On Wed, Jun 25, 2014 at 7:00 AM, Tejun Heo wrote:
>
> Hello,
>
> On Tue, Jun 24, 2014 at 08:05:07PM -0700, Austin Schuh wrote:
> > > I can see no reason why manual completion would behave differently
> > > from flush_work() in this case.
> >
> > I went looking for a short trace in my original log
Hello, Dave.
On Wed, Jun 25, 2014 at 03:56:41PM +1000, Dave Chinner wrote:
> Hmmm - that's different from my understanding of what the original
> behaviour WQ_MEM_RECLAIM gave us. i.e. that WQ_MEM_RECLAIM
> workqueues had a rescuer thread created to guarantee that the
> *workqueue* could make forw
Hello,
On Tue, Jun 24, 2014 at 08:05:07PM -0700, Austin Schuh wrote:
> > I can see no reason why manual completion would behave differently
> > from flush_work() in this case.
>
> I went looking for a short trace in my original log to show the problem,
> and instead found evidence of the second p
On Mon, Jun 23, 2014 at 11:25:21PM -0400, Tejun Heo wrote:
> Hello,
>
> On Tue, Jun 24, 2014 at 01:02:40PM +1000, Dave Chinner wrote:
> > As I understand it, what then happens is that the workqueue code
> > grabs another kworker thread and runs the next work item in it's
> > queue. IOWs, work item
[Adding tglx to the cc. Sorry for any double sends]
On Mon, Jun 23, 2014 at 8:25 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Jun 24, 2014 at 01:02:40PM +1000, Dave Chinner wrote:
>> start_flush_work() is effectively a special queue_work()
>> implementation, so if if it's not safe to call complete(
Hello,
On Tue, Jun 24, 2014 at 01:02:40PM +1000, Dave Chinner wrote:
> start_flush_work() is effectively a special queue_work()
> implementation, so if if it's not safe to call complete() from the
> workqueue as the above patch implies then this code has the same
> problem.
>
> Tejun - is this "d
The previous time I've seen it was on 3.13.6, 3 weeks ago,
I'm now on 3.14.1.
Setting /proc/sys/vm/dirty_bytes to very high number (around
18446744073709550284) but still smaller than (uint64)-1 gets
things running shortly/partially though.
System is single-CPU, CONFIG_SMP=n, which might be impor
On Thu, Apr 03, 2014 at 06:15:25PM +0800, zhuyj wrote:
> Hi, Willy
>
> I made a new patch. In long commit message, I inserted the equivalent
> mainline commit
> about this feature. Maybe it is better. Now this patch is in the
> attachment. Please check
> and merge it into kernel 2.6.32.62.
Sure
On 04/03/2014 06:01 PM, Willy Tarreau wrote:
Hi Zhu,
On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
I reference the following 2 mainline commits. These 2 commits are based
on the current kernel 3.x and ethtool.
If we only backport these 2 commits on kernel 2.6.x, this problem will
not b
On 04/03/2014 05:27 PM, Willy Tarreau wrote:
Hi Zhu,
On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
Hi, Claudiu
Please help to review this patch. This patch is for kernel 2.6.x. Thanks
a lot.
Hi, Willy
Please help to merge this patch to longterm: 2.6.32.61 since this
problem also occ
Hi Zhu,
On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
> I reference the following 2 mainline commits. These 2 commits are based
> on the current kernel 3.x and ethtool.
> If we only backport these 2 commits on kernel 2.6.x, this problem will
> not be fixed yet.
OK fine, I just wanted t
On 04/03/2014 05:27 PM, Willy Tarreau wrote:
Hi Zhu,
On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
Hi, Claudiu
Please help to review this patch. This patch is for kernel 2.6.x. Thanks
a lot.
Hi, Willy
Please help to merge this patch to longterm: 2.6.32.61 since this
problem also occ
Hi Zhu,
On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
> Hi, Claudiu
>
> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
> a lot.
>
> Hi, Willy
>
> Please help to merge this patch to longterm: 2.6.32.61 since this
> problem also occurs on this kernel. Thanks a
Hi, Claudiu
Please help to review this patch. This patch is for kernel 2.6.x. Thanks
a lot.
Hi, Willy
Please help to merge this patch to longterm: 2.6.32.61 since this
problem also occurs on this kernel. Thanks a lot.
Based on kernel 2.6.x, gianfar nic driver can not work well. The root
c
> (Although honestly, that whole thing is so long ago that my "dim
> memory" is very suspect, and it's possible the workaround actually
> came independently of that from Alan Cox. This all happened in
> v2.4.13-rc2 - late 2001 - and the PPro workaround came in together
> with the X86 OOSTORE code,
On Sun, Nov 24, 2013 at 3:35 AM, Yuhong Bao wrote:
> I read this: http://hardware.slashdot.org/comments.pl?sid=3102545&cid=41270883
> Makes me wonder what would happen if something similar was tried with EFI or
> ACPI?
the EOMA68 project is unique in that it is a mass-volume *modular*
architect
On 09/01/2013 09:12 AM, Linus Torvalds wrote:
> On Sun, Sep 1, 2013 at 9:00 AM, H. Peter Anvin wrote:
>> On 09/01/2013 08:58 AM, Linus Torvalds wrote:
>>>
>>> Not necessarily. Don't we basically do exactly that for the F00F bug
>>> workaround, for example?
>>
>> We do, but only after matching on a
On Sun, Sep 1, 2013 at 9:00 AM, H. Peter Anvin wrote:
> On 09/01/2013 08:58 AM, Linus Torvalds wrote:
>>
>> Not necessarily. Don't we basically do exactly that for the F00F bug
>> workaround, for example?
>
> We do, but only after matching on an exact address (is_f00f_bug()).
> Note also that is_f
On 09/01/2013 08:58 AM, Linus Torvalds wrote:
> On Sun, Sep 1, 2013 at 5:20 AM, H. Peter Anvin wrote:
>>
>> This has the end result that we treat a user space instruction which
>> touches a privileged data structure that then page faults (e.g. a
>> segment load which causes #PF on the GDT) as a us
On 09/01/2013 08:58 AM, Linus Torvalds wrote:
> On Sun, Sep 1, 2013 at 5:20 AM, H. Peter Anvin wrote:
>>
>> This has the end result that we treat a user space instruction which
>> touches a privileged data structure that then page faults (e.g. a
>> segment load which causes #PF on the GDT) as a us
On Sun, Sep 1, 2013 at 5:20 AM, H. Peter Anvin wrote:
>
> This has the end result that we treat a user space instruction which
> touches a privileged data structure that then page faults (e.g. a
> segment load which causes #PF on the GDT) as a user-space fault.
>
> This seems very wrong to me, sin
Quoting David Daney :
On 08/16/2012 02:20 PM, Kasatkin, Dmitry wrote:
Hello,
Some places in the code uses variable-size allocation on stack..
For example from hmac_setkey():
struct {
struct shash_desc shash;
char ctx[crypto_shash_descsize(hash)];
On 08/16/2012 02:20 PM, Kasatkin, Dmitry wrote:
Hello,
Some places in the code uses variable-size allocation on stack..
For example from hmac_setkey():
struct {
struct shash_desc shash;
char ctx[crypto_shash_descsize(hash)];
} desc;
sparse compl
On Oct 7 2007 00:28, Oleg Verych wrote:
>
>I thought, i was talking about *write() functions, that got one
>additional unrelated, non config removable API change in face of
>`unsigned int loglevel'.
Documentation/stable_api_nonsense.txt ;-)
>Idea. Extend those macro defines before format string
On Sat, Oct 06, 2007 at 11:27:54PM +0200, Jan Engelhardt wrote:
[]
> _call_console_drivers() skips the substring and passes on the rest of the
> message:
>
> if (msg_level < 0 && ((end - cur_index) > 2) &&
> LOG_BUF(cur_index + 0) == '<' &&
>
Maarten Bressers wrote:
Randy Dunlap <[EMAIL PROTECTED]> wrote:
On Fri, 28 Sep 2007 20:56:30 + (UTC) Maarten Bressers wrote:
This (trivial) patch fixes two compiler warnings for 2.6.23-rc8 on x86_64,
use of deprecated function pci_find_device() and a section mismatch.
Build log and .confi
On Sep 14, 2007, at 18:40:00, Heikki Orsila wrote:
Consider a simple embedded system:
void interrupt_handler(void)
int main(void)
I would like to "emulate" this system with a workstation to make
development faster. I would create two threads, one executing the
main() function, and the other
On 9/14/07, Heikki Orsila <[EMAIL PROTECTED]> wrote:
> Consider a simple embedded system:
>
> void interrupt_handler(void)
> int main(void)
>
> I would like to "emulate" this system with a workstation to make
> development faster. I would create two threads, one executing the
> main() function, and
El Sat, Sep 15, 2007 at 01:40:00AM +0300 Heikki Orsila ha dit:
> Consider a simple embedded system:
>
> void interrupt_handler(void)
> {
> ...
> }
>
> int main(void)
> {
> ...
> }
>
> I would like to "emulate" this system with a workstation to make
> development faster. I would cre
On Fri, Jul 13 2007, Jens Axboe wrote:
> On Fri, Jul 13 2007, Linus Torvalds wrote:
> >
> >
> > On Fri, 13 Jul 2007, Jens Axboe wrote:
> > >
> > > Does this work?
> >
> > Ok, so it apparently works, but:
> >
> > > diff --git a/fs/splice.c b/fs/splice.c
> > > index ed2ce99..92646aa 100644
> > >
On Fri, Jul 13 2007, Linus Torvalds wrote:
>
>
> On Fri, 13 Jul 2007, Jens Axboe wrote:
> >
> > Does this work?
>
> Ok, so it apparently works, but:
>
> > diff --git a/fs/splice.c b/fs/splice.c
> > index ed2ce99..92646aa 100644
> > --- a/fs/splice.c
> > +++ b/fs/splice.c
> > @@ -491,7 +491,7 @
On Fri, 13 Jul 2007, Jens Axboe wrote:
>
> Does this work?
Ok, so it apparently works, but:
> diff --git a/fs/splice.c b/fs/splice.c
> index ed2ce99..92646aa 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -491,7 +491,7 @@ ssize_t generic_file_splice_read(struct file *in, loff_t
> *ppos,
Jens Axboe wrote:
On Fri, Jul 13 2007, Gabriel C wrote:
Hello ,
While doing some tests with 2.6.22-git2 ( at the time head
4eb6bf6bfb580afaf1e1a1d30cba17a078530cf4 ) all my webservers stopped
working.
I can't get any file using wget or whatever else , everything hangs
after 1% forever.
I bisec
On Fri, Jul 13 2007, Gabriel C wrote:
> Jens Axboe wrote:
> > On Fri, Jul 13 2007, Gabriel C wrote:
> >
> >> Jens Axboe wrote:
> >>
> >>> On Fri, Jul 13 2007, Gabriel C wrote:
> >>>
> >>>
> Hello ,
>
> While doing some tests with 2.6.22-git2 ( at the time head
> >>>
On Fri, Jul 13 2007, Christoph Hellwig wrote:
> On Fri, Jul 13, 2007 at 12:00:58PM +0200, Jens Axboe wrote:
> > On Fri, Jul 13 2007, Gabriel C wrote:
> > > Jens Axboe wrote:
> > > > On Fri, Jul 13 2007, Gabriel C wrote:
> > > >
> > > >> Hello ,
> > > >>
> > > >> While doing some tests with 2.6.2
Jens Axboe wrote:
> On Fri, Jul 13 2007, Gabriel C wrote:
>
>> Jens Axboe wrote:
>>
>>> On Fri, Jul 13 2007, Gabriel C wrote:
>>>
>>>
Hello ,
While doing some tests with 2.6.22-git2 ( at the time head
4eb6bf6bfb580afaf1e1a1d30cba17a078530cf4 ) all my webservers
On Fri, Jul 13, 2007 at 12:00:58PM +0200, Jens Axboe wrote:
> On Fri, Jul 13 2007, Gabriel C wrote:
> > Jens Axboe wrote:
> > > On Fri, Jul 13 2007, Gabriel C wrote:
> > >
> > >> Hello ,
> > >>
> > >> While doing some tests with 2.6.22-git2 ( at the time head
> > >> 4eb6bf6bfb580afaf1e1a1d30cba1
1 - 100 of 136 matches
Mail list logo
