return rc;
> > @@ -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
> > better fix (to 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
> round up the invalid to a valid value, 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/nouv
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
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 derefe
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 2021 23:34:23 O
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 t
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 report
01 5d 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: 0690
--
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
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 stop
60x64
[ 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
se nVidia 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
t; > 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.
--
Ondrej Zary
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
rry. Didn't notice it was merged.
--
Ondrej Zary
t 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
CI_DEVICE_ID_XGI_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
h simple drivers doesn't even consider drm
> "because 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 software
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 software
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 f
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
different 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 instea
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
different 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 instea
2D acceleration.
> This 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
2D acceleration.
> This 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
o, it doesn't. I try to hibernate, 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
o, it doesn't. I try to hibernate, 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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 testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After
> > loading i915 module, the screen goes blank and the kernel hangs
> &
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
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 go
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 go
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 testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After
> > loading i915 module, the screen goes blank and the kernel ha
Is this a known regression?
--
Ondrej Zary
Is this a known regression?
--
Ondrej Zary
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
48 matches
Mail list logo
