Daniel Drake wrote:
Ed Sweetman wrote:
Like i mentioned off list, the problem here is that cpu freq modules
dont depend (Kconfig) on CONFIG_ACPI_PROCESSOR, yet they do.
Not really. Firstly, some of the cpufreq modules *do* depend on
CONFIG_ACPI_PROCESSOR. Secondly, the ones that don't
Daniel Drake wrote:
Joshua Hoblitt wrote:
I don't think this is quiet right either as Ed Sweetman has reported
that this issue doesn't occur on single socket/multi-core systems.
Where did he write that? In an off-list mail, Ed seemed to agree with
my patch.
Daniel
What i di
Pavel Machek wrote:
Hi!
powernow-k8 uses PSB BIOS tables to read frequency info on UP systems, but
on SMP it requires the acpi-processor driver. Kconfig should be updated
accordingly to avoid the issues that users are running into.
http://bugzilla.kernel.org/show_bug.cgi?id=8075
https://bug
Dave Jones wrote:
On Thu, May 17, 2007 at 02:13:42PM -0400, Len Brown wrote:
> > Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig
> > ===
> > --- linux.orig/arch/i386/kernel/cpu/cpufreq/Kconfig
> > +++ linux/arch/i386/kernel/cp
Ed Sweetman wrote:
Dave Jones wrote:
On Thu, May 17, 2007 at 02:13:42PM -0400, Len Brown wrote:
> > Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig
> > ===
> > --- linux.orig/arch/i386/kernel/c
Dave Jones wrote:
On Thu, May 17, 2007 at 05:40:31PM -0400, Ed Sweetman wrote:
> Here's a patch
(please inline patches so they can be quoted in replies).
having this as a tristate makes no sense, that code can't be modular.
Also, there's a gratuitous whitespace change, and
Joshua Hoblitt wrote:
I think it's pretty clear that Dave and Daniel were both correct and
that ACPI_PROCESSOR is the correct dependency for multi-socket systems.
However, it's worth noting that this dependency seems to be unrelated to
SMP support. Ed Sweetman has reported that
the previous post i keep referring you to has a patch that was mangled
...here is the non-mangled version
--- ./linux-backup/arch/x86_64/kernel/cpufreq/Kconfig 2007-02-04
13:44:54.0 -0500
+++ ./linux-2.6.21-rc5-mm2/arch/x86_64/kernel/cpufreq/Kconfig
2007-05-17 18:13:07.0 -040
ct at all (and doesn't on other people's
> > machines).
> > I suggest trying the latest version which fixes some bugs.
>
> SD just doesn't do nearly as good as the stock scheduler, or CFS, here.
>
> I'm quite likely one of the few single-CPU/non-H
occurs.
Con
Think that Al may have a point. Yes there are cases where it not work well.
How about
reversing the idea? Set the initial timeslice so it will give good latency
with a fairly high
load. Increase the timeslice when the load is lower than the load we attempt
to guarantee
good latency for. Idea being to reduce the number of context switches while
retaining a
fixed latency.
Ed Tomlinson
-
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/
testing is important. We need to understand what needs
to be tweaked and why.
>From my POV 0.30 is better than mainline - it handles my load(s) better.
Thanks
Ed Tomlinson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
how rare, isn't smart. It might
> indicate an underlying problem, and even if it doesn't - you don't want ppl
> complaining the new kernel isn't interactive anymore or something...
Ingo,
The other point to make here is that you only need to nice X if you are heavily
ov
> -Original Message-
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 04, 2007 10:36 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: RE: [PATCH 1/4] [SCSI]stex: fix id mapping issue
>
>
> On Wed, 20
user space could make a good
attempt to keep latency within bounds for a set of tasks just by renicing
Thanks
Ed Tomlinson
PS. Get well soon Con.
On Saturday 07 April 2007 02:50, Con Kolivas wrote:
> On Friday 06 April 2007 20:03, Ingo Molnar wrote:
> > * Con Kolivas <[EMAIL
On Monday 09 April 2007 01:38, Mike Galbraith wrote:
> On Sun, 2007-04-08 at 09:08 -0400, Ed Tomlinson wrote:
> > Hi,
> >
> > I am one of those who have been happily testing Con's patches.
> >
> > They work better than mainline here.
>
> (I tr
ases, so does rotation length. Would you really
> want CPU hogs routinely preempting house-keepers under load?
SD has a schedule batch nice level. This is good for tasks that want lots
of cpu when they can get it. If you overload your cpu I expect the box
to slow down - including kernel thre
ptable kernel eventually
locks up switching between 32 and 64 apps)
Thanks,
Ed Tomlinson
-
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
On Monday 23 April 2007 19:45, Ed Tomlinson wrote:
> On Monday 23 April 2007 17:57, Bill Davidsen wrote:
> > I am not sure a binary attachment will go thru, I will move to the web
> > ste if not.
>
> I did a quick try of this script here.
>
> With SD 0.46 with X
d 0.46 1 line -10 0.8 FPS
sd 0.46 1 line 0 2.3 FPS
sd 0.46 1 line 10 93 FPS
sd 0.46 1 line 19 93 FPS
sd 0.46 jump is basically the same as the 1 line case.
glxgears alone gets about 1500 FPS
So in one case nice -10 gives us the worst performance. In the other case,
where you predic
On Thursday 26 April 2007 18:56, Con Kolivas wrote:
> On Friday 27 April 2007 08:00, Bill Davidsen wrote:
> > Ingo Molnar wrote:
> > > * Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> > >>> SD 0.46 1-2 FPS
> > >>> cfs v5
ence. For instance reading mail with freenet
working
hard (threaded java application) and gentoo's emerge triggering compiles to
update the
box is much smoother.
Think this scheduler needs serious looking at.
Ed Tomlinson
On Monday 05 March 2007 14:19, Gene Heskett wrote:
> On Mo
ber of 128. The RAID console only interfaces to scsi mid layer
and is always mapped at channel:0, id:16, lun:0.
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 69be132..4d68533 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.
During hard bus reset of st_shasta controllers, 1 ms is not enough for
16-port controllers, although it's good for 8-port controllers. Extend the
wait time to 100 ms to allow bus resets finish successfully.
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.
This will make the console to be offlined right
after reset. Add the handling in driver to fix this problem.
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 1e8d7ac..9465f35 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/
Add debug information into abort and host_reset routine.
Change ioremap to ioremap_nocache.
Version updated to 3.6..1.
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 9465f35..5a10cfa 100644
--- a/drivers/scsi/stex.c
+++ b/d
> -Original Message-
> From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 31, 2007 2:27 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; Promise_Linux
> Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue
>
>
&
> -Original Message-
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 31, 2007 7:22 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue
>
>
> On Fri, 2007-0
> -Original Message-
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 31, 2007 11:46 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: Re: [PATCH 3/4] [SCSI]stex: fix reset recovery for
> console device
>
&g
> -Original Message-
> From: Brian King [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 02, 2007 9:05 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; Promise_Linux
> Subject: Re: [PATCH 4/4] [SCSI]stex: minor cleanup and version update
&g
> -Original Message-
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 31, 2007 7:22 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue
>
>
> On Fri, 2007-0
> -Original Message-
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 02, 2007 11:28 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for
> console device
>
&g
> -Original Message-
> From: Ed Lin
> Sent: Monday, April 02, 2007 4:01 PM
> To: 'James Bottomley'
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: RE: [PATCH 1/4] [SCSI]stex: fix id mapping issue
>
>
>
>
> > -Original
> -Original Message-
> From: Ed Lin
> Sent: Monday, April 02, 2007 4:02 PM
> To: James Bottomley
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for
> console device
>
>
>
>
> > ---
el configured with DYNAMIC_DEBUG=y.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index c50637d..c
to know whether any commands are immune to being blocked by
this process. So it seems safest to ignore the chip's reported command
durations, and use a value much higher than any observed duration,
like 180 sec (which is the duration this chip reports for "long"
commands).
Signed-off-b
single callback.
This series
- improves TPM command error reporting
- adds optional logging of TPM command durations
- allows chip-specific override of command durations as well as protocol
timeouts
- overrides ST19NP18 TPM command duration to avoid lockups
Ed Swierk (5):
tpm_tis: Improve
: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 143 +--
drivers/char/tpm/tpm_tis.c | 35 +++---
include/linux/tpm.h | 3 +-
3 files changed, 88 insertions(+), 93 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers
Mysterious TPM behavior can be difficult to track down through all the
layers of software. Add error messages for conditions that should
never happen. Also include the manufacturer ID along with other chip
data printed during init.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant
code. Return all errors to the caller rather than swallowing them
(e.g. when tpm_transmit_cmd() returns nonzero).
Signed-off-by: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 74 +++-
1 file
On Mon, Jun 20, 2016 at 6:54 PM, Ed Swierk wrote:
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -461,9 +461,19 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id,
> cap_t *cap,
> tpm_cmd.params.getcap_in.subcap_size
Mysterious TPM behavior can be difficult to track down through all the
layers of software. Add error messages for conditions that should
never happen. Also include the manufacturer ID along with other chip
data printed during init.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 143 +--
drivers/char/tpm/tpm_tis.c | 35 +++---
include/linux/tpm.h | 3 +-
3 files changed, 88 insertions(+), 93 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers
both timeouts and
durations via a single callback.
This series
- improves TPM command error reporting
- adds optional logging of TPM command durations
- allows chip-specific override of command durations as well as protocol
timeouts
- overrides ST19NP18 TPM command duration to avoid lockups
Ed
el configured with DYNAMIC_DEBUG=y.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index c50637d..c
Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant
code. Return all errors to the caller rather than swallowing them
(e.g. when tpm_transmit_cmd() returns nonzero).
Signed-off-by: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 74 +++-
1 file
to know whether any commands are immune to being blocked by
this process. So it seems safest to ignore the chip's reported command
durations, and use a value much higher than any observed duration,
like 180 sec (which is the duration this chip reports for "long"
commands).
Signed-off-b
counters increasing?
>
> With receive_group_order=4 you should see 16 IRQs.
I see the 16 IRQs, and the first one does increase. But packets don't make
it to the application.
--Ed
On 8/31/16 14:20, Aaro Koskinen wrote:
> On Wed, Aug 31, 2016 at 09:20:07AM -0700, Ed Swierk wrote:
>> Here's my workaround:
>
> [...]
>
>> -static int cvm_oct_poll(struct oct_rx_group *rx_group, int budget)
>> +static int cvm_oct_poll(int group, int budget)
&
t one interrupt (not even a separate one for tx, as far as I can
tell) pegged to CPU 0 (the default smp_affinity). I must be missing some
other major configuration tweak, perhaps specific to 10G.
Can you run a test on the EBB6800 with the interfaces in 10G mode?
--Ed
ardless of whether
it's the cpu task_numa_migrate() is running on.
Is this a plausible theory?
This is the only instance of a hard lockup among a number of identical
systems running the same kernel, so I'm not seeing an easy way to
reproduce this issue, but any suggestions would be welcome.
--Ed
Ping?
On Wed, Oct 25, 2017 at 9:35 PM, Ed Swierk wrote:
>
> Ping?
>
> On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote:
> >
> > Ping for Peter, Ingo and other sched maintainers:
> >
> > I'd appreciate any feedback on this hard lockup issue, whic
Ping?
On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote:
>
> Ping for Peter, Ingo and other sched maintainers:
>
> I'd appreciate any feedback on this hard lockup issue, which occurred
> on a system running kernel 4.4.52-grsec.
>
> To recap: a dual-socket Xeon (E5
problem with
an upstream kernel or any other, yet to my limited understanding of
the evidence it appears there may indeed be a real problem lurking in
there.
I will follow up with the grsec folks.
> On Thu, Nov 2, 2017 at 5:51 PM, Ed Swierk wrote:
>> Ping?
>>
>> On Wed,
and
state machine used for synchronizing timer death. Using del_timer_sync()
will already do the right thing.
Looks OK to me, thanks.
--
Ed
AX + 1;
> + break;
> + }
> +
> + if (rate <= i * max_rate)
> break;
> }
> if (i <= UART_DIV_MAX) {
--
Ed
rs if the
> current one would already mean a rate below min_rate (that it, this is
> the closer).
It terminates the search as soon as the rate returned from
clk_round_rate() is lower than i * min_rate, which is too soon.
> So in fact we also break when the closer divider have been found.
&
On 11/01/18 17:55, Nuno Gonçalves wrote:
> So, for me clk_round_rate() always returns 2400, and only the loop
> variable i changes, so the search is monotonic, from the highest baud
> to the lowest (increasing divider).
>
> I am using a Allwiner H2+, with the serial port configuration from
> su
On 11/01/18 18:03, Ed Blake wrote:
> On 11/01/18 17:55, Nuno Gonçalves wrote:
>> So, for me clk_round_rate() always returns 2400, and only the loop
>> variable i changes, so the search is monotonic, from the highest baud
>> to the lowest (increasing divider).
>>
reaches 67 without finding
an acceptable rate.
Fix this by setting the upper boundary of the loop appropriately to
avoid overflow.
Reported-by: Nuno Goncalves
Signed-off-by: Ed Blake
---
drivers/tty/serial/8250/8250_dw.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a
If the tool cannot tell whether the protected state is manipulated by *another*
piece of code called in atomic context, then it's insufficient.
> On Jan 26, 2018, at 4:37 AM, Jia-Ju Bai wrote:
>
> After checking all possible call chains to aoenet_rcv(),
> my tool finds that aoenet_rcv() is neve
Good luck in your efforts, and thanks for your work on static analysis.
> On Jan 27, 2018, at 9:12 PM, Jia-Ju Bai wrote:
>
>
>
>> On 2018/1/28 1:48, Ed Cashin wrote:
>> If the tool cannot tell whether the protected state is manipulated by
>> *another* piece of
On 01/17/2018 10:41 AM, Jens Axboe wrote:
...
Applied, thanks Arnd/Tina.
Thank you for the CC. Sorry for the lack of response in November.
--
Ed
On 13/01/18 11:59, Nuno Gonçalves wrote:
> Dear Ed,
>
> Thanks.
>
> Tested-by: Nuno Goncalves
>
> I just would like to report a aditional issue I find, which I am not
> sure if it is intend behaviour or not. If I set bauds 1152000,
> 150, 200, 250, 300,
On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai wrote:
>
> +#ifndef O_BENEATH
> +#define O_BENEATH 0004000 /* *Not* the same as capsicum's
> O_BENEATH! */
> +#endif
I had originally followed up privately to Aleksa about this comment (to
suggest that it's outdated and should be removed), but t
> What is the proposed semantic of O_BENEATH with absolute paths -- I
> believe you don't have an openat(2) on FreeBSD (but please feel free to
> correct me)?
openat(2) is necessary for capability mode (since open(2) is not permitted),
but it turns out it was actually added to FreeBSD earlier than
the value used by the e1000 driver, so it seems
like a safe upper limit.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
---
tap-change-mtu.patch
Description: Binary data
erface, ping complains "message
too long" when I send a 65521-byte packet; 65520 works okay, though.)
--Ed
tap-change-mtu.patch
Description: Binary data
Rob,
I gather this was with the complete -ck patchset? It would be interesting to
see if just SD
performed as well. If it does, CFS needs more work. if not there are other
things in -ck
that really do improve performance and should be looked into.
Thanks
Ed Tomlinson
On September 17, 2007
Bring the physical link down when the interface is down, by placing
the PHY in power-down state. This mirrors the behavior of other
drivers including e1000 and tg3.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
forcedeth-phy-power-down.patch
Description: Binary data
Log "no link during initialization" at KERN_INFO as it's not an error,
and occurs every time the interface comes up (when the
forcedeth-phy-power-down patch is applied).
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
forcedeth-open-no-link-printk.patch
Description: Binary data
ming autoneg restart?
This seems to work fine with a BCM5461S phy; it would be worth testing
with other phys to be sure.
--Ed
forcedeth-phy-power-down.patch
Description: Binary data
call the equivalent ethtool_ops functions provided
by network drivers with built-in phy support.
Signed-off-by: Ed Swierk
---
include/linux/phy.h | 9 +
net/core/ethtool.c | 45 ++---
2 files changed, 43 insertions(+), 11 deletions(-)
diff --git a
return -ENOMEM;
> k->task = task;
> wait_for_completion(&k->rendez); /* allow kthread to start */
> - init_completion(&k->rendez);/* for waiting for exit later */
> + reinit_completion(&k->rendez); /* for waiting for exit later
OK. Thanks.
On 06/18/2015 11:23 PM, Vaishali Thakkar wrote:
In little endian cases, the macro htons unfolds to __swab16 which
provides special case for constants. In big endian cases,
__constant_htons and htons expand directly to the same expression.
So, replace __constant_htons with htons with
OK. Thanks.
On 06/18/2015 11:15 PM, Vaishali Thakkar wrote:
In little endian cases, the macros htons and cpu_to_be16 unfolds
to __swab16 which provides special case for constants. In big
endian cases, __constant_htons and htons expand directly to the
same expression. The same applies for __cons
Fix typo in f2fs documentation.
Signed-off-by: Ed Tsai
---
Documentation/filesystems/f2fs.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index dae15c96e659..e1cda214058e 100644
--- a/Documentation
2014 at 12:19:40AM +0100, Ken Moffat wrote:
> >> > On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote:
> >>
> >> > > Ken,
> >> > >
> >> > > You might want to try reverting:
> >> > >
> >> >
On Monday 21 April 2014 17:26:15 Ed Tomlinson wrote:
> On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote:
> > On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote:
> > > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote:
> > > > On 2014.04.19 at
hristian just sent me a -fixes pull with all of these in it and I'll
> send it on to you
> in a few mins.
Hi
Given the fun I had with rc1 I decided to try this pull before rc2 and its
working fine here.
Thanks!
Ed Tomlinson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
uary or unigine-tropics demo/benchmark
programs also produce the above problems and eventually stall.
The problem is reproducible - I am not that familiar with gpu problems though,
what else will help debug this?
TIA
Ed Tomlinson
--
To unsubscribe from this list: send the line "unsubs
:45:05 localhost kernel: [4.743151] Code: c0 f2 23 e1 5b 44 89 e0
41 5c 41 5d 5d c3 66 0f 1f 44 00 00 4c 89 ef 41 bc ed ff ff ff e8 a2 f2 23 e1
eb e0
48 8b 15 c9 21 00 00 <8b> 02 8d 48 01 85 c0 89 0a 75 c6 48 8b 05 37 1f 00 00 48
3d 60
Mar 10 10:45:05 localhost kernel: [4.74315
On Monday 10 March 2014 12:38:42 Alex Deucher wrote:
> On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote:
> > Hi,
> >
> > I recently added a R7 260X to my system. While the card works with 3.13
> > its supposed work much better with 14-rc.
> > This is not
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote:
> On Monday 10 March 2014 12:38:42 Alex Deucher wrote:
> > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote:
> > > Hi,
> > >
> > > I recently added a R7 260X to my system. While the card works with 3.13
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote:
> On Monday 10 March 2014 12:38:42 Alex Deucher wrote:
> > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote:
> > > Hi,
> > >
> > > I recently added a R7 260X to my system. While the card works with 3.13
On Sunday 23 March 2014 16:08:37 Ed Tomlinson wrote:
> On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote:
> > On Monday 10 March 2014 12:38:42 Alex Deucher wrote:
> > > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote:
> > > > Hi,
> > > >
>
timestamp query.
If you are happy with this you can give this patch my tested by.
Thanks
Ed Tomlinson
On Monday 30 June 2014 07:59:55 Chris Wilson wrote:
> On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> > On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
> >
> >
)
when this happened. The distribution is arch at is up to date as of june 26th.
Thanks
Ed Tomlinson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Hi
Third try at getting the attachment with the jpg of the panic onto the lists
(sorry if some recipients get multiple copies).
https://plus.google.com/u/0/photos/108244876431105742323/albums/6029631260384977873/6029631269719723986?pid=6029631269719723986&oid=108244876431105742323
Thank
On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
Resend without html krud which causes list to bounce the message.
> Hi
>
> This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot with
> 3.16-git. Reverting it lets the boot proceed.
>
> I have an i7 wi
urb status: -71
Please fix.
Thanks
Ed Tomlinson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x
(Bus Powered)
Thanks
Ed
On Saturday 05 July 2014 11:02:06 Greg KH wrote:
> On Sat, Jul 05, 2014 at 10:55:57AM -
.
Thanks
Ed Tomlinson
On Saturday 05 July 2014 23:13:27 Dave Airlie wrote:
>
> Hi Linus,
>
> i915, tda998x and vmwgfx fixes, the main one is i915 fix for missing VGA
> connectors, along with some fixes for the tda998x from Russell fixing some
> modesetting problems
>
Daniel,
I am not quite sure I understand what you want me to test?
Do you want me to try it without:
> > + if (ret == 0) {
> > + ret = do_unregister_con_driver(&vga_con);
Thanks
Ed
On Monday 07 July 2014 10:48:26 Daniel Vetter wrote:
> O
Daniel,
Just to be sure. The intel card here should not be claiming the real console.
It does
not have an output device and the bios set set so the radeon is the primary
device.
Ed
On Monday 07 July 2014 10:48:26 Daniel Vetter wrote:
> On Mon, Jun 30, 2014 at 07:59:55AM +0100, Chris Wil
Hi Daniel,
The patch below also works. You can use my Tested By for it.
Thanks
Ed Tomlinson
PS. I _really_ need to get a serial console working on my i7 box.
On Monday 07 July 2014 14:26:54 Daniel Vetter wrote:
> On Mon, Jul 07, 2014 at 06:45:49AM -0400, Ed Tomlinson wrote:
> &g
gt; No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780.
I have the same symptoms with rc2 and a r7 260x using display port. I cannot
seem to get a dmesg of a failure (I _really_ need to figure out how to add
a serial console). I'll try reverting once I figure out how to get
On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote:
> On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote:
> > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote:
> > >
> > > Unfortunately this contains no easter eggs, its a bit larger than I'd
> > &g
On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote:
> On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote:
> > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote:
> > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote:
> > > >
> > > > Unfortu
15.0-rc8-next-20140606-sasha-00021-ga9d3a0b-dirty #597
> >
> > This is 3.15-rc8 + linux-next? I'll try to reproduce here, but the
> > tests were working for me.
>
> Yes, it's the latest -next tree available.
>
> Also note that it doesn't happen every ti
On Monday 10 March 2014 12:07:56 Ed Tomlinson wrote:
This seems fixed by "[PATCH] Input: mousedev - fix race when creating mixed
device" which is in 3.14
Thanks
Ed
> This happens every couple of boots with 3.14-rc kernels have not noticed it
> with 3.13. Not really sure
301 - 400 of 599 matches
Mail list logo
