Date: Tue, 6 Oct 2015 13:20:37 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= <dumbbell@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Andriy Voskoboinyk <s3erios@gmail.com>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r288653 - in head/sys/dev/drm2: . i915 Message-ID: <CAJ-VmomsX3%2B_0R8bc8qM-EO=5Cd0fKJyygCx94pQkCzcT-OWxg@mail.gmail.com> In-Reply-To: <56142CCC.7000807@FreeBSD.org> References: <201510040745.t947jbp7082807@repo.freebsd.org> <20151004094649.GG11284@kib.kiev.ua> <56142CCC.7000807@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
ok, so what should we rip out? That '3' case? -a On 6 October 2015 at 13:19, Jean-S=C3=A9bastien P=C3=A9dron <dumbbell@freeb= sd.org> wrote: > On 04.10.2015 11:46, Konstantin Belousov wrote: >> On Sun, Oct 04, 2015 at 07:45:37AM +0000, Adrian Chadd wrote: >>> * Add missing case statement (gen =3D=3D 3) in intel_gpu_reset(). >> This seems to be wrong. The i915 and G33 chipsets do not have registers >> declared in the 8xx chipset documentation. More, i915 and G33 have diff= erent >> reset procedures. >> >> The absence of '3' case was copied from the corresponding Linux kernel. >> Was this change tested, or is there a reference to upstream where the >> handling was added in this manner ? > > You're right, even in Linux 3.8, the switch does not have a case for > generation 3. > >>> * Replace M_WAITOK with M_NOWAIT when the return value of malloc is c= hecked (may be incorrect). >> This is also incorrect. At least the modesetting pathes are executed in >> the syscall context, and sleeping is allowed; the modesetting locks were >> selected to make sleeping possible. Using nowait causes random syscalls >> failure where the requests would succeed otherwise. > > My reasoning was that M_WAITOK could make the display hang/unresponsive > while the memory is under pressure. The caller should be responsible for > handling the error instead. > > In Linux, *alloc() calls may fail so application should already be > responsible for that. > > -- > Jean-S=C3=A9bastien P=C3=A9dron >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomsX3%2B_0R8bc8qM-EO=5Cd0fKJyygCx94pQkCzcT-OWxg>