Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid
On 03/28/2016 02:39 PM, Joseph Salisbury wrote: > On 03/02/2016 04:58 PM, Joseph Salisbury wrote: >> On 02/29/2016 04:33 AM, Jani Nikula wrote: >>> On Wed, 24 Feb 2016, Joseph Salisbury >>> wrote: >>>> Hi Sonika, >>>> >>>> A kernel bug report was opened against Ubuntu [0]. After a kernel >>>> bisect, it was found that reverting the following commit resolved this bug: >>>> >>>> commit 237ed86c693d8a8e4db476976aeb30df4deac74b >>>> Author: Sonika Jindal >>>> Date: Tue Sep 15 09:44:20 2015 +0530 >>>> >>>> drm/i915: Check live status before reading edid >>>> >>>> >>>> >>>> The regression was introduced as of v4.4-rc1. >>>> >>>> I was hoping to get your feedback, since you are the patch author. Do >>>> think increasing the number of tries in intel_hdmi_detect() is worth >>>> trying? Do you think gathering any additional data will help diagnose >>>> this issue, or would it be best to submit a revert request? >> Thanks for the info. I will have all of these commits tested. >> >> >>> There are at least the following commits claiming to fix issues in the >>> above commit. Please make sure you have them. >>> >>> BR, >>> Jani. >>> >>> >>> commit 8d409cb3e8a24196be7271defafd4638f3e0b514 >>> Author: Ville Syrjälä >>> Date: Wed Feb 10 19:59:05 2016 +0200 >>> >>> drm/i915: Fix hpd live status bits for g4x >>> >>> commit 3d8acd1f667b45c531401c8f0c2033072e32a05d >>> Author: Gary Wang >>> Date: Wed Dec 23 16:11:35 2015 +0800 >>> >>> drm/i915: increase the tries for HDMI hotplug live status checking >>> >>> commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715 >>> Author: Daniel Vetter >>> Date: Fri Dec 11 19:44:15 2015 +0100 >>> >>> drm/i915: mdelay(10) considered harmful >>> >>> commit 0f5a9be15797f78c9a34e432f26c796165b6e49a >>> Author: Imre Deak >>> Date: Fri Nov 27 18:55:29 2015 +0200 >>> >>> drm/i915: take a power domain reference while checking the HDMI live >>> status >>> >>> >>> >>> > Hi Jani, > > Applying the following commit did indeed fix the original bug[0]: > > commit 8d409cb3e8a24196be7271defafd4638f3e0b514 > Author: Ville Syrjälä > Date: Wed Feb 10 19:59:05 2016 +0200 > > drm/i915: Fix hpd live status bits for g4x > > > > However, it also introduced a new bug, which is covered in that bug > report. The new bug is that after locking/unlocking the screen, all the > windows get shuffled around in a manner that is consistent with X > deciding that it's single-headed again, and then back to double headed. > This only happens when I build a kernel with both commit 237ed86c AND > commit 8d409cb3e. If I revert 237ed86c and keep only 8d409cb3e both the > original bug and the new bug go away. Do you think commit 237ed86c is > still even needed now that 8d409cb3e has landed? Maybe the new bug is > due to the interaction between 237ed86c and 8d409cb3e. > > Thanks, > > Joe > > [0] http://pad.lv/1543683 > > > > > Hello, Is there any addition debug data we can collect to debug the new bug that commit 8d409cb3e introduced? Thanks, Joe ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid
On 03/02/2016 04:58 PM, Joseph Salisbury wrote: > On 02/29/2016 04:33 AM, Jani Nikula wrote: >> On Wed, 24 Feb 2016, Joseph Salisbury wrote: >>> Hi Sonika, >>> >>> A kernel bug report was opened against Ubuntu [0]. After a kernel >>> bisect, it was found that reverting the following commit resolved this bug: >>> >>> commit 237ed86c693d8a8e4db476976aeb30df4deac74b >>> Author: Sonika Jindal >>> Date: Tue Sep 15 09:44:20 2015 +0530 >>> >>> drm/i915: Check live status before reading edid >>> >>> >>> >>> The regression was introduced as of v4.4-rc1. >>> >>> I was hoping to get your feedback, since you are the patch author. Do >>> think increasing the number of tries in intel_hdmi_detect() is worth >>> trying? Do you think gathering any additional data will help diagnose >>> this issue, or would it be best to submit a revert request? > Thanks for the info. I will have all of these commits tested. > > >> There are at least the following commits claiming to fix issues in the >> above commit. Please make sure you have them. >> >> BR, >> Jani. >> >> >> commit 8d409cb3e8a24196be7271defafd4638f3e0b514 >> Author: Ville Syrjälä >> Date: Wed Feb 10 19:59:05 2016 +0200 >> >> drm/i915: Fix hpd live status bits for g4x >> >> commit 3d8acd1f667b45c531401c8f0c2033072e32a05d >> Author: Gary Wang >> Date: Wed Dec 23 16:11:35 2015 +0800 >> >> drm/i915: increase the tries for HDMI hotplug live status checking >> >> commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715 >> Author: Daniel Vetter >> Date: Fri Dec 11 19:44:15 2015 +0100 >> >> drm/i915: mdelay(10) considered harmful >> >> commit 0f5a9be15797f78c9a34e432f26c796165b6e49a >> Author: Imre Deak >> Date: Fri Nov 27 18:55:29 2015 +0200 >> >> drm/i915: take a power domain reference while checking the HDMI live >> status >> >> >> >> Hi Jani, Applying the following commit did indeed fix the original bug[0]: commit 8d409cb3e8a24196be7271defafd4638f3e0b514 Author: Ville Syrjälä Date: Wed Feb 10 19:59:05 2016 +0200 drm/i915: Fix hpd live status bits for g4x However, it also introduced a new bug, which is covered in that bug report. The new bug is that after locking/unlocking the screen, all the windows get shuffled around in a manner that is consistent with X deciding that it's single-headed again, and then back to double headed. This only happens when I build a kernel with both commit 237ed86c AND commit 8d409cb3e. If I revert 237ed86c and keep only 8d409cb3e both the original bug and the new bug go away. Do you think commit 237ed86c is still even needed now that 8d409cb3e has landed? Maybe the new bug is due to the interaction between 237ed86c and 8d409cb3e. Thanks, Joe [0] http://pad.lv/1543683 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid
On 02/29/2016 04:33 AM, Jani Nikula wrote: > On Wed, 24 Feb 2016, Joseph Salisbury wrote: >> Hi Sonika, >> >> A kernel bug report was opened against Ubuntu [0]. After a kernel >> bisect, it was found that reverting the following commit resolved this bug: >> >> commit 237ed86c693d8a8e4db476976aeb30df4deac74b >> Author: Sonika Jindal >> Date: Tue Sep 15 09:44:20 2015 +0530 >> >> drm/i915: Check live status before reading edid >> >> >> >> The regression was introduced as of v4.4-rc1. >> >> I was hoping to get your feedback, since you are the patch author. Do >> think increasing the number of tries in intel_hdmi_detect() is worth >> trying? Do you think gathering any additional data will help diagnose >> this issue, or would it be best to submit a revert request? Thanks for the info. I will have all of these commits tested. > There are at least the following commits claiming to fix issues in the > above commit. Please make sure you have them. > > BR, > Jani. > > > commit 8d409cb3e8a24196be7271defafd4638f3e0b514 > Author: Ville Syrjälä > Date: Wed Feb 10 19:59:05 2016 +0200 > > drm/i915: Fix hpd live status bits for g4x > > commit 3d8acd1f667b45c531401c8f0c2033072e32a05d > Author: Gary Wang > Date: Wed Dec 23 16:11:35 2015 +0800 > > drm/i915: increase the tries for HDMI hotplug live status checking > > commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715 > Author: Daniel Vetter > Date: Fri Dec 11 19:44:15 2015 +0100 > > drm/i915: mdelay(10) considered harmful > > commit 0f5a9be15797f78c9a34e432f26c796165b6e49a > Author: Imre Deak > Date: Fri Nov 27 18:55:29 2015 +0200 > > drm/i915: take a power domain reference while checking the HDMI live > status > > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid
On 02/24/2016 10:53 PM, Jindal, Sonika wrote: > Hi Joe, > > Yes, first thing to try is to increase the tries. We testing with 300 retries, but the second monitor still did not show up. However, it did show up in lspci. > Can you please point me to the bug and provide more details like platform, > monitor, cable. The bug is at: http://pad.lv/1543683 . All the hardware details should be in the bug report. The cable is a single link dvi-d cable. Unfortunately the bug reporter does not have a dual link cable to test. If you need any additional info, we can ask the bug reporter. > Are you referring to the same issue as Oleksandr reported where a single link > dvi/hdmi cable didn’t work and dual link worked? I'm not sure if this is the exact issue or not. I'll review the other thread and compare. > > Regards, > Sonika > > -Original Message- > From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] > Sent: Thursday, February 25, 2016 3:09 AM > To: Jindal, Sonika > Cc: Sharma, Shashank ; Vivi, Rodrigo > ; Daniel Vetter ; Jani Nikula > ; David Airlie ; intel-gfx > ; dri-devel > ; LKML > Subject: [4.4-rc1][Regression] drm/i915: Check live status before reading edid > > Hi Sonika, > > A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it > was found that reverting the following commit resolved this bug: > > commit 237ed86c693d8a8e4db476976aeb30df4deac74b > Author: Sonika Jindal > Date: Tue Sep 15 09:44:20 2015 +0530 > > drm/i915: Check live status before reading edid > > > > The regression was introduced as of v4.4-rc1. > > I was hoping to get your feedback, since you are the patch author. Do think > increasing the number of tries in intel_hdmi_detect() is worth trying? Do > you think gathering any additional data will help diagnose this issue, or > would it be best to submit a revert request? > > > Thanks, > > Joe > > [0] http://pad.lv/lp1543683 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid
Hi Sonika, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit 237ed86c693d8a8e4db476976aeb30df4deac74b Author: Sonika Jindal Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid The regression was introduced as of v4.4-rc1. I was hoping to get your feedback, since you are the patch author. Do think increasing the number of tries in intel_hdmi_detect() is worth trying? Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? Thanks, Joe [0] http://pad.lv/lp1543683 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""
On 10/31/2013 10:58 AM, Jani Nikula wrote: > On Fri, 25 Oct 2013, Joseph Salisbury wrote: >> On 10/16/2013 05:02 PM, Daniel Vetter wrote: >>> It's by far not that simple. Jani is working on both the underlying bug >>> and a better w/a. See >>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=59841 >>> >>> for the full story in its entire glory. >>> >>> Cheers, Daniel >> Thanks for the feedback, Daniel. Is there an estimate on what mainline >> release might contain Jani's work? > commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf > Author: Jani Nikula > Date: Mon Oct 21 10:52:07 2013 +0300 > > drm/i915/dp: workaround BIOS eDP bpp clamping issue > > and a couple of dependencies are now in Linus' tree, i.e. should be > released in 3.12. The commits are also CC: stable. > > BR, > Jani. > > Great news! Thanks, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""
On 10/16/2013 05:02 PM, Daniel Vetter wrote: > On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote: >> BugLink: http://bugs.launchpad.net/bugs/1195483 >> >> This reverts commit 657445fe8660100ad174600ebfa61536392b7624. >> >> Signed-off-by: Joseph Salisbury >> Cc: Daniel Vetter >> Cc: Paulo Zanoni >> Cc: David Airlie >> Cc: sta...@vger.kernel.org > It's by far not that simple. Jani is working on both the underlying bug > and a better w/a. See > > https://bugzilla.kernel.org/show_bug.cgi?id=59841 > > for the full story in its entire glory. > > Cheers, Daniel Thanks for the feedback, Daniel. Is there an estimate on what mainline release might contain Jani's work? Thanks again, Joe ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 0/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""
Hi Daniel, A bug was opened against the Ubuntu kernel[0]. It was found that reverting the following commit resolved this bug: commit 657445fe8660100ad174600ebfa61536392b7624 Author: Daniel Vetter Date: Sat May 4 10:09:18 2013 +0200 Revert "drm/i915: revert eDP bpp clamping code changes" The regression was introduced as of v3.10-rc2 and affects a large number of end users. I see this code has gone back and forth a few times, so I was wondering if we could get some feedback. The revert of commit 657445f was tested aginst 3.11 stable and could not be done cleanly, so I had to make some modifications. The modifications I made for 3.11 are in [PATCH 1/1]. The revert can't be done cleanly against 3.12 neither. The modifications I made for 3.11 will not work cleanly on 3.12 due to recent changes in 3.12, such as commit 7984211. However, I can create a patch specific for 3.12 if you think this is the best way to go. Thanks, Joe http://pad.lv/1195483 Joseph Salisbury (1): Revert "Revert "drm/i915: revert eDP bpp clamping code changes"" drivers/gpu/drm/i915/intel_dp.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""
BugLink: http://bugs.launchpad.net/bugs/1195483 This reverts commit 657445fe8660100ad174600ebfa61536392b7624. Signed-off-by: Joseph Salisbury Cc: Daniel Vetter Cc: Paulo Zanoni Cc: David Airlie Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/intel_dp.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 26e162b..ce933ad 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -709,10 +709,7 @@ intel_dp_compute_config(struct intel_encoder *encoder, /* Walk through all bpp values. Luckily they're all nicely spaced with 2 * bpc in between. */ - bpp = pipe_config->pipe_bpp; - if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) - bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); - + bpp = min_t(int, 8*3, pipe_config->pipe_bpp); for (; bpp >= 6*3; bpp -= 2*3) { mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp); @@ -763,6 +760,19 @@ found: &pipe_config->dp_m_n); intel_dp_set_clock(encoder, pipe_config, intel_dp->link_bw); + /* +* XXX: We have a strange regression where using the vbt edp bpp value +* for the link bw computation results in black screens, the panel only +* works when we do the computation at the usual 24bpp (but still +* requires us to use 18bpp). Until that's fully debugged, stay +* bug-for-bug compatible with the old code. +*/ + if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) { + DRM_DEBUG_KMS("clamping display bpc (was %d) to eDP (%d)\n", + bpp, dev_priv->vbt.edp_bpp); + bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp); + } + pipe_config->pipe_bpp = bpp; return true; } -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued
On 04/03/2013 03:16 PM, Daniel Vetter wrote: On Wed, Apr 3, 2013 at 9:08 PM, Joseph Salisbury <mailto:joseph.salisb...@canonical.com>> wrote: Hi Daniel, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found the following was the first bad commit: commit c2fb7916927e989ea424e61ce5fe617e54878827 Merge: 29de6ce 6f0c058 Author: Daniel Vetter mailto:daniel.vet...@ffwll.ch>> Date: Mon Oct 22 14:34:51 2012 +0200 Merge tag 'v3.7-rc2' into drm-intel-next-queued The regression was introduced as of v3.8-rc1. However, further testing also shows this bug is now fixed in v3.9-rc4. I see that you are the author of this patch, so I wanted see if I can get your feedback. Do you happen to have an idea what may have fixed this in v3.9-rc4, so we can send a request to stable, if not already done? Otherwise, I can perform a reverse bisect to see which commit fixed this. So apparently it's an oops somewhere in the nouveau setup code, which bisected to a backmerge which has _only_ conflicts in drm/i915 driver code. I have no idea what blew up here, sorry. -Daniel Thanks for the info, Daniel. I'll go the reverse bisect route. Thanks, Joe [0] http://pad.lv/1109309 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued
Hi Daniel, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found the following was the first bad commit: commit c2fb7916927e989ea424e61ce5fe617e54878827 Merge: 29de6ce 6f0c058 Author: Daniel Vetter Date: Mon Oct 22 14:34:51 2012 +0200 Merge tag 'v3.7-rc2' into drm-intel-next-queued The regression was introduced as of v3.8-rc1. However, further testing also shows this bug is now fixed in v3.9-rc4. I see that you are the author of this patch, so I wanted see if I can get your feedback. Do you happen to have an idea what may have fixed this in v3.9-rc4, so we can send a request to stable, if not already done? Otherwise, I can perform a reverse bisect to see which commit fixed this. Thanks, Joe [0] http://pad.lv/1109309 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Regression due to: drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13
On 01/07/2013 04:36 AM, Daniel Vetter wrote: On Mon, Jan 07, 2013 at 10:12:12AM +0100, Sjoerd Simons wrote: On Sun, 2013-01-06 at 22:13 +0100, Daniel Vetter wrote: Now with the intel-gfx m-l address fixed ... -Daniel On Sun, Jan 6, 2013 at 10:13 PM, Daniel Vetter wrote: Hi all, Looks ugly, and the original commit doesn't have any link to the dmidecode information. Sjoerd&John, can you both please attach the output of dmidecode? If we're lucky, we can differentiate the two models somehow, if not we need to revert this patch, since regressions win over simple bugs. Mine is attached, unfortunately the only interesting difference seems to be the Base board serial number: - Serial Number: /sku + Serial Number: But given we both have an ID12 that's most likely not very relevant (or maybe different bios versions do different amounts of setup on the hdmi bridge). Even though i did some attempts i've never seen the hdmi output work in linux (and didn't know it was attached to LVDS). John did mention it only works up to 720p, so it could very well be i simply never send it a mode it actually supports. Reverting this patch will cause a regression in that the higher levels, e.g. X, always thinks there is an output on the LVDS port so it comes up in a very odd mode (but at least one can work around that with configuration), so i guess the patch should be reverted :/ Ideally we'd find a way to do hotplug detection on the lvds-to-hdmi bridge (any ideas where to look for that would be much appreciated). Unfortunately I have no clue (nor docs) how lvds->hdmi chains are supposed to work. For real hdmi support we'd need a few things at least: - some way to set up infoframes - some way to switch between single-link and dual-link lvds modes (for the higher resolutions) - some way to do hotplug detection (I guess we could use polling on the i2c pins as a fallback) All this needs a new hdmi_on_lvds encoder/connector with relevant code, plus a way to figure out whether we need this (either with a quirk table or by looking at some magic vbt value I'm not aware of). In short: Tons of work to make this work, and very unlikely that we'll get around to it. If you're bored though I could give you some ideas though on the #intel-gfx irc channel. I've reverted the quirk entry to fix the regression. Cheers, Daniel Yours, Daniel On Tue, Dec 25, 2012 at 12:39 PM, John Tapsell wrote: I have a Zotac ZDBOX SD ID12 and the following commit means that I no longer have HDMI output. I've been told that I have a lvds-to-hdmi bridge, so this commit broke that. Commit: drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13 BugLink: https://bugs.launchpad.net/bugs/1064924 This box claims to have an LVDS interface but doesn't actually have one. Signed-off-by: Sjoerd Simons Signed-off-by: Daniel Vetter (cherry picked from commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364) Signed-off-by: Joseph Salisbury Signed-off-by: Tim Gardner -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch # dmidecode 2.11 SMBIOS 2.6 present. 22 structures occupying 1065 bytes. Table at 0x000FB9E0. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 080016 Release Date: 12/23/2010 Address: 0xF Runtime Size: 64 kB ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.16 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: ZOTAC Product Name: ZBOXSD-ID12/ID13 Version: XX Serial Number: G160X UUID: 03000200-0400-0500-0006-0007000800