gt; > @@ -1085,7 +1085,7 @@ static void ark_pci_remove(struct pci_dev *dev)
> >
> > pci_iounmap(dev, info->screen_base);
> > pci_release_regions(dev);
> > -/* pci_disable_device(dev); */
> > + pci_disable_device(dev);
> >
> > framebuffer_release(info);
> > }
>
>
--
Ondrej Zary
uan He
> > Cc: Helge Deller
> > Cc: Thomas Zimmermann
> > Cc: Christophe Leroy
> > Cc: linux-fb...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
>
> Reviewed-by: Luis Chamberlain
>
> Is anyone using this driver these days? How often do fbdev driv
sparse complains that using memset() on __iomem pointer is wrong:
incorrect type in argument 1 (different address spaces)
Use memset_io() to clear screen instead.
Tested on real i740 cards.
Signed-off-by: Ondrej Zary
---
drivers/video/fbdev/i740fb.c | 2 +-
1 file changed, 1 insertion(+), 1
round up the pixclock when it's invalid).
> > If not, I will apply this one later.
>
> I'm also looking forward to a more appropriate patch for this driver!
I was not able to reproduce it at first but finally found it: the monitor must
be unplugged. If a valid EDID is present, fb_validate_mode() call in
i740fb_check_var() will refuse zero pixclock.
Haven't found any obvious way to correct zero pixclock value. Most other
drivers simply return -EINVAL.
> Thanks,
> Zheyu Ma
>
--
Ondrej Zary
lue, if possible.
>
> I don't disagree.
> The main problem probably is: what is the next valid value?
> This needs to be analyzed on a per-driver base and ideally tested.
> Right now a division-by-zero is tiggered which is probably more worse.
I still have an i740 card so I can test it.
> That said, currently I'd prefer to apply the zero-checks patches over
> any untested patches. It's easy to revert such checks if a better solution
> becomes available.
>
> Thoughts?
>
> > Commit b36b242d4b8ea178 ("video: fbdev: asiliantfb: Error out if
> > 'pixclock' equals zero") does not do that.
>
> Helge
>
--
Ondrej Zary
It just landed in Linus' tree yesterday, please retest that or -rc3.
> If it's still broken it's something else.
> -Daniel
Thanks, it works!
--
Ondrej Zary
ort_pc 8139cp parport
[ 58.798016] CR2: 017c
[ 58.798147] ---[ end trace 732829d39ed65de9 ]---
d02117f8efaa5fbc37437df1ae955a147a2a424a is the first bad commit
--
Ondrej Zary
On Monday 14 June 2021 13:05:17 Christian König wrote:
> AGP for example doesn't have a dma_address array.
>
> Signed-off-by: Christian König
Fixes NULL pointer dereference in nouveau_bo_sync_for_device on AGP cards.
Tested-by: Ondrej Zary
> ---
> drivers/gpu/drm/nouveau/n
On Friday 11 June 2021 14:38:18 Christian König wrote:
>
> Am 10.06.21 um 19:59 schrieb Christian König:
> > Am 10.06.21 um 19:50 schrieb Ondrej Zary:
> >> [SNIP]
> >>> I can't see how this is called from the nouveau code, only
> >>> possibility I
On Thursday 10 June 2021 08:43:06 Christian König wrote:
>
> Am 09.06.21 um 22:00 schrieb Ondrej Zary:
> > On Wednesday 09 June 2021 11:21:05 Christian König wrote:
> >> Am 09.06.21 um 09:10 schrieb Ondrej Zary:
> >>> On Wednesday 09 June 2021, Christian König w
On Wednesday 09 June 2021 11:21:05 Christian König wrote:
> Am 09.06.21 um 09:10 schrieb Ondrej Zary:
> > On Wednesday 09 June 2021, Christian König wrote:
> >> Am 09.06.21 um 08:57 schrieb Ondrej Zary:
> >>> [SNIP]
> >>>> Thanks for the heads up.
On Wednesday 09 June 2021, Christian König wrote:
> Am 09.06.21 um 08:57 schrieb Ondrej Zary:
> > [SNIP]
> >> Thanks for the heads up. So the problem with my patch is already fixed,
> >> isn't it?
> > The NULL pointer derefere
On Wednesday 09 June 2021, Christian König wrote:
> Am 08.06.21 um 23:59 schrieb Ondrej Zary:
> > On Tuesday 08 June 2021 22:01:56 Ondrej Zary wrote:
> >> On Tuesday 08 June 2021 20:47:42 Ondrej Zary wrote:
> >>> On Monday 07 June 2021 22:58:43 Ondrej Zary wrote:
&g
On Tuesday 08 June 2021 22:01:56 Ondrej Zary wrote:
> On Tuesday 08 June 2021 20:47:42 Ondrej Zary wrote:
> > On Monday 07 June 2021 22:58:43 Ondrej Zary wrote:
> > > On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote:
> > > > On Saturday 05 June 2
On Tuesday 08 June 2021 20:47:42 Ondrej Zary wrote:
> On Monday 07 June 2021 22:58:43 Ondrej Zary wrote:
> > On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote:
> > > On Saturday 05 June 2021 23:34:23 Ondrej Zary wrote:
> > > > On Saturday 05 June 2021 21:43:52 Ondr
On Monday 07 June 2021 22:58:43 Ondrej Zary wrote:
> On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote:
> > On Saturday 05 June 2021 23:34:23 Ondrej Zary wrote:
> > > On Saturday 05 June 2021 21:43:52 Ondrej Zary wrote:
> > > > Hello,
> > > > I'm testin
On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote:
> On Saturday 05 June 2021 23:34:23 Ondrej Zary wrote:
> > On Saturday 05 June 2021 21:43:52 Ondrej Zary wrote:
> > > Hello,
> > > I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer dereference
> >
On Saturday 05 June 2021 23:34:23 Ondrej Zary wrote:
> On Saturday 05 June 2021 21:43:52 Ondrej Zary wrote:
> > Hello,
> > I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer dereference in
> > nouveau_bo_sync_for_device.
> > Found various reports
f0 58 eb ae
[ 21.006476] EAX: EBX: 0010 ECX: 0001 EDX:
[ 21.006485] ESI: c3e90280 EDI: c185a494 EBP: c2ed7c10 ESP: c2ed7bf8
[ 21.006494] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210206
[ 21.006503] CR0: 80050033 CR2: CR3: 02ecb000 CR4: 00000690
--
Ondrej Zary
On Saturday 05 June 2021 21:43:52 Ondrej Zary wrote:
> Hello,
> I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer dereference in
> nouveau_bo_sync_for_device.
> Found various reports like this but that was back in februaryso that should
> be fixed now.
So it is the s
On Saturday 10 October 2020 02:02:42 Karol Herbst wrote:
> On Sat, Oct 10, 2020 at 12:23 AM Ilia Mirkin wrote:
> >
> > On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote:
> > >
> > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote:
> > > >
> >
On Saturday 10 October 2020 00:23:38 Ilia Mirkin wrote:
> On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote:
> >
> > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote:
> > >
> > > Hello,
> > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped w
[ 23.571050] nouveau :01:00.0: fb0: nouveaudrmfb frame buffer device
--
Ondrej Zary
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
chips are known to fail and corrupt BIOS logo suggests that.
--
Ondrej Zary
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
; drivers on Amiga.
> >
> > It could be that I actually have this particular SPARC framebuffer in
> > my hardware collection.
>
> Unless you have a 32-bit sparc laptop, you don't have a machine that
> will use this driver.
There are also some x86 PCI cards using this chip.
--
O
rry. Didn't notice it was merged.
--
Ondrej Zary
the host bridge in nvkm_device_agp_quirks
and add entry for SiS 761 with mode 0 (AGP disabled).
Signed-off-by: Ondrej Zary
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c
b
I_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_27
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_42
Two of them are already supported by sisfb:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
So I think that support for the remaining two (and missing features, if any)
should be added to sisfb.
--
Ondrej Zary
ecause I don't have a desktop gpu" which is just silly - drm has become
> rather flexible. And that's essentially why writing simple drm drivers
> still has a bit too much boilerplate, since no one yet bothered to add a
> bit of helper support needed.
Is there a simple way to convert existing fbdev drivers to DRM? Let's say I
want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect,
copyarea, imageblit) to be usable by the console (and maybe extend it to X11
using some generic 2D driver?)
--
Ondrej Zary
On Monday 14 September 2015 04:31:43 Alex Deucher wrote:
> On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary
> wrote:
> > Hello,
> > I have a PC Chips A31G board with AGPro slot and found that nouveau does
> > not work properly with it. Console works but reverts to soft
On Sunday 13 September 2015 21:12:25 Ilia Mirkin wrote:
> On Sun, Sep 13, 2015 at 2:57 PM, Ondrej Zary
> wrote:
> > Hello,
> > I have a PC Chips A31G board with AGPro slot and found that nouveau does
> > not work properly with it. Console works but reverts to soft
Hello,
I have a PC Chips A31G board with AGPro slot and found that nouveau does not
work properly with it. Console works but reverts to software mode, X11 hangs
with mouse cursor only.
The slot is physically AGP 1.5V but is wired to PCI bus as the chipset (SiS
761) does not support AGP cards. To
On Friday 19 July 2013 23:50:50 Alex Deucher wrote:
> On Fri, Jul 19, 2013 at 3:08 PM, Ondrej Zary
wrote:
> > Hello,
> > got another card with "too bright" problem:
> > Sapphire Radeon VE 7000 DDR (VGA+S-Video)
> >
> > lspci -vnn:
> > 01:00.0
rent types are broken this way.
The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.
drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR
Values from BIOS are wrong, causing too bright colors.
Use default values instead.
Signed
On Friday 19 July 2013 23:50:50 Alex Deucher wrote:
On Fri, Jul 19, 2013 at 3:08 PM, Ondrej Zary li...@rainbow-software.org
wrote:
Hello,
got another card with too bright problem:
Sapphire Radeon VE 7000 DDR (VGA+S-Video)
lspci -vnn:
01:00.0 VGA compatible controller [0300]: Advanced
his is important to me, as the various old drivers I've been hacking
> on won't be accepted upstream without some sort of userspace which can
> work with them. One of the big goals of KMS was a generic
> userspace-facing API, like FB, but without the suck.
--
Ondrej Zary
FB, but without the suck.
--
Ondrej Zary
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
te, everything works to the point where
> > the screen goes off and the box hangs (solid). Normally, it would turn
> > the screen back on and continue with saving the image.
> >
> > But, since that happens with the patch above applied, I think it doesn't
> > really pass the suspend phase (IOW, it probably hangs somewhere in the
> > radeon's suspend routine).
>
> I've just verified that in fact hibernation works on HP nx6325 with
> 2.6.35-rc3, but it takes about 55 sec. to suspend the graphics adapter in
> the "freeze" phase. Surprisingly enough, during suspend to RAM it works
> normally (as well as in the "poweroff" phase of hibernation).
It takes 2 minutes on RV530:
https://bugzilla.redhat.com/show_bug.cgi?id=586522
--
Ondrej Zary
On Sunday 06 June 2010 11:04:44 Dave Airlie wrote:
> On Sun, Jun 6, 2010 at 6:28 AM, Ondrej Zary
wrote:
> > On Saturday 05 June 2010 02:23:27 Eric Anholt wrote:
> >> On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary
wrote:
> >> > Hello,
> >> > I'm t
On Sunday 06 June 2010 11:04:44 Dave Airlie wrote:
On Sun, Jun 6, 2010 at 6:28 AM, Ondrej Zary li...@rainbow-software.org
wrote:
On Saturday 05 June 2010 02:23:27 Eric Anholt wrote:
On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary
li...@rainbow-software.org wrote:
Hello,
I'm testing
On Saturday 05 June 2010 02:23:27 Eric Anholt wrote:
> On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary rainbow-software.org> wrote:
> > Hello,
> > I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After
> > loading i915 module, the screen goes bl
On Saturday 05 June 2010 02:23:27 Eric Anholt wrote:
> On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary rainbow-software.org>
wrote:
> > Hello,
> > I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After
> > loading i915 module, the screen goes bl
On Saturday 05 June 2010 02:23:27 Eric Anholt wrote:
On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary li...@rainbow-software.org
wrote:
Hello,
I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After
loading i915 module, the screen goes blank and the kernel hangs
completely
is a known regression?
--
Ondrej Zary
44 matches
Mail list logo
