On Tue, 9 Aug 2005, Bodo Eggert wrote:
> On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote:
> > On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
> > > The wrong values are constant across reboots (see my first mail), and I
> > > have a CRT.
> > >
> > > Can you tell me where the timing values
On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote:
> On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
> > The wrong values are constant across reboots (see my first mail), and I
> > have a CRT.
> >
> > Can you tell me where the timing values are read?
>
> radeon_write_mode() programs the mo
On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
> The wrong values are constant across reboots (see my first mail), and I
> have a CRT.
>
> Can you tell me where the timing values are read?
radeon_write_mode() programs the mode. The monitor timing infos are read
by the various bits of cod
On Aug 7, 2005, at 21:13:54, Kyle Moffett wrote:
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote:
_However_ there is an unrelated problem with some panels,
including some
of the 17": The panel doesn't always "sync" properly. This seem to be
related to some subtle timing issue in the
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote:
I've got an LCD, and on mine
it looks like every third pixel-line gets shifted about 32-64
pixels to
the left, and they move with display refresh. My guess is that
something is interrupting radeonfb during a critical time in display
s
On Sun, 7 Aug 2005, Benjamin Herrenschmidt wrote:
> On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote:
> > On Sun, 7 Aug 2005, Kyle Moffett wrote:
> > > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
> > > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
> > > > t
On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote:
> On Sun, 7 Aug 2005, Kyle Moffett wrote:
> > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
>
> > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
> > > though ... Can you try something like wrapper radeon_write_
On Sun, 7 Aug 2005, Kyle Moffett wrote:
> On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
> > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
> > though ... Can you try something like wrapper radeon_write_mode() with
> > preempt_disable()/preempt_enable() and tell me i
> I'm having a similar issue with my shiny new 17" Powerbook G4. The
> radeon chip works fine with framebuffer in 2.6.12.4 _with_ PREEMPT,
> but not in 2.6.13-rc5 _with_ PREEMPT (configs are virtually identical).
> I'll try your idea this afternoon when I get the chance.
Note that PREEMPT is kno
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote:
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
My CRT is out of sync after radeonfb from 2.6.13-rc5 is
initialized.
2.6.1
On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote:
> On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
> > > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
> > > 2.6.12 does not show this behaviour.
> >
> > I'm
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
> On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
> > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
> > 2.6.12 does not show this behaviour.
>
> I'm out of town at the moment, could you maybe diff radeonfb between
> w
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
> My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
> 2.6.12 does not show this behaviour.
I'm out of town at the moment, could you maybe diff radeonfb between
working & non-working and CC me the diff ? I don't have my work
My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
2.6.12 does not show this behaviour.
dmesg from both systems, trimmed down:
2.6.13-rc5:
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is :01:00.0
PCI: Using IRQ router VIA [1106/0686] at 0
On Tuesday 02 August 2005 12:50, Rafael J. Wysocki wrote:
> Please try to ad the ec_polling parameter to the kernel command line and
> retest.
That helps a lot. Thanks, it's back to the 'old way'.
Jan
--
...Deep Hack Mode -- that mysterious and frightening state of
consciousness where Mortal Use
On Tuesday, 2 of August 2005 08:43, Jan De Luyck wrote:
> On Tuesday 02 August 2005 07:07, Linus Torvalds wrote:
> > Ok, one more in the series towards final 2.6.13.
>
> One thing that seems like a regression: doing
>
> $ cat /proc/acpi/battery/BAT1/info
>
> causes a two-second pause and then gi
On Mon, Aug 01, Linus Torvalds wrote:
> Give it a good testing, I'm hoping this can really turn into 2.6.13.
aic doesnt work anymore, the poweroff thing should also be fixed in some
way.
http://marc.theaimsgroup.com/?l=linux-scsi&m=112180348617932&w=2
(google did not find that posting, but it
On Tuesday 02 August 2005 07:07, Linus Torvalds wrote:
> Ok, one more in the series towards final 2.6.13.
One thing that seems like a regression: doing
$ cat /proc/acpi/battery/BAT1/info
causes a two-second pause and then gives me the information, while in 2.6.12.3
that was near-instant.
$ dat
On Tuesday 02 August 2005 07:07, Linus Torvalds wrote:
> Ok, one more in the series towards final 2.6.13.
>
> This one is small enough that both shortlog and diffstat fit comfortably:
> no big architecture updates or anything like that. Some input, x86-64 and
> ppc updates, and various fairly small
Ok, one more in the series towards final 2.6.13.
This one is small enough that both shortlog and diffstat fit comfortably:
no big architecture updates or anything like that. Some input, x86-64 and
ppc updates, and various fairly small fixes in random places.
Some reverts back to 2.6.12 behavio
20 matches
Mail list logo
