Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid

2016-04-18 Thread Joseph Salisbury 
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 <joseph.salisb...@canonical.com> 
>>> 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 <sonika.jin...@intel.com>
>>>> 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ä <ville.syrj...@linux.intel.com>
>>> Date:   Wed Feb 10 19:59:05 2016 +0200
>>>
>>> drm/i915: Fix hpd live status bits for g4x
>>>
>>> commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
>>> Author: Gary Wang <gary.c.w...@intel.com>
>>> 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 <daniel.vet...@ffwll.ch>
>>> Date:   Fri Dec 11 19:44:15 2015 +0100
>>>
>>> drm/i915: mdelay(10) considered harmful
>>>
>>> commit 0f5a9be15797f78c9a34e432f26c796165b6e49a
>>> Author: Imre Deak <imre.d...@intel.com>
>>> 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ä <ville.syrj...@linux.intel.com>
> 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

2016-03-28 Thread Joseph Salisbury 
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 <joseph.salisb...@canonical.com> 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 <sonika.jin...@intel.com>
>>> 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ä <ville.syrj...@linux.intel.com>
>> Date:   Wed Feb 10 19:59:05 2016 +0200
>>
>> drm/i915: Fix hpd live status bits for g4x
>>
>> commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
>> Author: Gary Wang <gary.c.w...@intel.com>
>> 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 <daniel.vet...@ffwll.ch>
>> Date:   Fri Dec 11 19:44:15 2015 +0100
>>
>> drm/i915: mdelay(10) considered harmful
>>
>> commit 0f5a9be15797f78c9a34e432f26c796165b6e49a
>> Author: Imre Deak <imre.d...@intel.com>
>> 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ä <ville.syrj...@linux.intel.com>
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

2016-03-02 Thread Joseph Salisbury 
On 02/29/2016 04:33 AM, Jani Nikula wrote:
> On Wed, 24 Feb 2016, Joseph Salisbury <joseph.salisb...@canonical.com> 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 <sonika.jin...@intel.com>
>> 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ä <ville.syrj...@linux.intel.com>
> Date:   Wed Feb 10 19:59:05 2016 +0200
>
> drm/i915: Fix hpd live status bits for g4x
>
> commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
> Author: Gary Wang <gary.c.w...@intel.com>
> 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 <daniel.vet...@ffwll.ch>
> Date:   Fri Dec 11 19:44:15 2015 +0100
>
> drm/i915: mdelay(10) considered harmful
>
> commit 0f5a9be15797f78c9a34e432f26c796165b6e49a
> Author: Imre Deak <imre.d...@intel.com>
> 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

[Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid

2016-02-24 Thread Joseph Salisbury 
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

2013-10-31 Thread Joseph Salisbury 
On 10/31/2013 10:58 AM, Jani Nikula wrote:
 On Fri, 25 Oct 2013, Joseph Salisbury joseph.salisb...@canonical.com 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 jani.nik...@intel.com
 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

[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert Revert drm/i915: revert eDP bpp clamping code changes

2013-10-16 Thread Joseph Salisbury 
BugLink: http://bugs.launchpad.net/bugs/1195483

This reverts commit 657445fe8660100ad174600ebfa61536392b7624.

Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Paulo Zanoni przan...@gmail.com
Cc: David Airlie airl...@linux.ie
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

[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 0/1] Revert Revert drm/i915: revert eDP bpp clamping code changes

2013-10-16 Thread Joseph Salisbury 
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 daniel.vet...@ffwll.ch
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.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

2013-04-04 Thread Joseph Salisbury 

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 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.



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] [v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

2013-04-04 Thread Joseph Salisbury 

On 04/03/2013 03:16 PM, Daniel Vetter wrote:
On Wed, Apr 3, 2013 at 9:08 PM, Joseph Salisbury 
joseph.salisb...@canonical.com 
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 daniel.vet...@ffwll.ch
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

Re: [Intel-gfx] Regression due to: drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13

2013-01-10 Thread Joseph Salisbury 

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 daniel.vet...@ffwll.ch wrote:

Hi all,

Looks ugly, and the original commit doesn't have any link to the
dmidecode information. SjoerdJohn, 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 johnf...@gmail.com 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 sjoerd.sim...@collabora.co.uk
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 (cherry picked from commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364)

 Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
 Signed-off-by: Tim Gardner tim.gard...@canonical.com



--
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