On Sun, Apr 21, 2013 at 01:03:16AM +, Jake wrote:
> ACPI BIOS Bug: Warning: Optional FADT field Pm2CintrolBlock has no address or
> length: 0x/0x1 (20121018/tbfadt-589)
I have the same one:
[0.00] ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has
zero a
Borislav Petkov alien8.de> writes:
>
> On Sun, Jan 20, 2013 at 12:57:55PM +0100, Jörg Rödel wrote:
> > BorisO is no longer with AMD afaik.
>
> Why am I not surprised...
>
> > I wrote an email to Sherry and Suravee and asked them to either send
> > me hardware to write the fix on my own or to s
On 2013-01-22 15:36, Boris Ostrovsky wrote:
>
>
> On 01/22/2013 09:13 AM, Udo van den Heuvel wrote:
>> Gigabyte demonstrate that using ESX 5i IOMMU works fine.
I forwarded the malinglist links with the patch(es) to Gigabyte support
and they forwarded the info to the BIOS_team.
(to be continued
On 1/23/2013 8:23 AM, Udo van den Heuvel wrote:
On 2013-01-23 00:29, Suravee Suthikulanit wrote:
message in "dmesg".
"AMD-Vi: Applying erratum 746 for IOMMU at :00:00.2"
This is expected.
Regards,
Suravee
[1.091733] AMD-Vi: Found IOMMU at :00:00.2 cap 0x40
I assume that is c
On 1/23/2013 8:19 AM, Udo van den Heuvel wrote:
On 2013-01-23 00:29, Suravee Suthikulanit wrote:
I sent out a patch
(http://marc.info/?l=linux-kernel&m=135889686523524&w=2) which should
implement
the workaround for AMD processor family15h model 10-1Fh erratum 746 in
the IOMMU driver.
In your cas
On 2013-01-23 00:29, Suravee Suthikulanit wrote:
> message in "dmesg".
>
> "AMD-Vi: Applying erratum 746 for IOMMU at :00:00.2"
[1.091733] AMD-Vi: Found IOMMU at :00:00.2 cap 0x40
I assume that is correct.
Kind regards,
Udo
--
To unsubscribe from this list: send the line "unsubscrib
On 2013-01-23 00:29, Suravee Suthikulanit wrote:
> I sent out a patch
> (http://marc.info/?l=linux-kernel&m=135889686523524&w=2) which should
> implement
> the workaround for AMD processor family15h model 10-1Fh erratum 746 in
> the IOMMU driver.
> In your case, the output from "setpci -s 00:00.02
On 1/22/2013 10:29 AM, Udo van den Heuvel wrote:
On 2013-01-22 17:12, Boris Ostrovsky wrote:
Your BIOS does not have the required erratum workaround. We will provide
a patch to close that hole but since the problem is not easily
reproducible (and the erratum is also not easy to trigger) it may
On 2013-01-22 17:12, Boris Ostrovsky wrote:
>> Seen once over here. Correlated with raid-check.
>
> Then the answer from Gigabyte doesn't prove anything. You can also boot
> Linux without seeing this problem in most cases.
That was my situation until the first time it hit.
> Your BIOS does not h
On 01/22/2013 10:27 AM, Udo van den Heuvel wrote:
On 2013-01-22 15:36, Boris Ostrovsky wrote:
Gigabyte demonstrate that using ESX 5i IOMMU works fine. (with pictures
attached).
There are no attachments to your message.
Correct, gigabyte did send them via their support web-interface.
Do yo
On 2013-01-22 15:36, Boris Ostrovsky wrote:
>> Gigabyte demonstrate that using ESX 5i IOMMU works fine. (with pictures
>> attached).
>
> There are no attachments to your message.
Correct, gigabyte did send them via their support web-interface.
Do yo uneed to see them? They just show IOMMU enabled
On Tue, Jan 22, 2013 at 09:36:34AM -0500, Boris Ostrovsky wrote:
>
>
> On 01/22/2013 09:13 AM, Udo van den Heuvel wrote:
> >Gigabyte demonstrate that using ESX 5i IOMMU works fine. (with pictures
> >attached).
>
> There are no attachments to your message.
>
> I am not sure that 5i supports IOMM
On 01/22/2013 09:13 AM, Udo van den Heuvel wrote:
Gigabyte demonstrate that using ESX 5i IOMMU works fine. (with pictures
attached).
There are no attachments to your message.
I am not sure that 5i supports IOMMU (but I may well be wrong).
What can we bring against that?
How reproducible
Gigabyte demonstrate that using ESX 5i IOMMU works fine. (with pictures
attached).
What can we bring against that?
Udo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
On 2013-01-21 23:35, Suravee Suthikulpanit wrote:
> Would you please try the following and check the output value
> on your system?
>
> # setpci -s 00:00.02 F0.w=90
> # setpci -s 00:00.02 F4.w
# setpci -s 00:00.02 F0.w=90
# setpci -s 00:00.02 F4.w
0050
#
Udo
--
To unsubscribe from this list: s
Udo,
I am trying to debug the issue but need to check one thing on your
system. Would you please try the following and check the output value
on your system?
# setpci -s 00:00.02 F0.w=90
# setpci -s 00:00.02 F4.w
Thank you,
Suravee
On Mon, 2013-01-21 at 10:04 -0600, Jacob Shin wrote:
> On
On Sun, Jan 20, 2013 at 12:48:28PM +0100, Borislav Petkov wrote:
> On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
> > Yes, the BIOS vendor can fix this issue. They need to disable NB clock
> > gating for the IOMMU.
>
> Right, Udo, you can try Gigabyte first.
>
> Btw, can't we add a q
On 2013-01-21 16:32, Borislav Petkov wrote:
>>> [0.220187] AMD-Vi: Disabling interrupt remapping due to BIOS Bug(s)
>>
>> Yes, that are BIOS bugs too that prevent interrupt remapping to function
>> reliably. But the good thing is that these bugs can be detected easily
>> to enable a workaround
On Mon, Jan 21, 2013 at 04:10:00PM +0100, Jörg Rödel wrote:
> On Mon, Jan 21, 2013 at 02:09:42PM +0100, Borislav Petkov wrote:
> > [0.220022] [Firmware Bug]: AMD-Vi: IOAPIC[9] not in IVRS table
> > [0.220078] [Firmware Bug]: AMD-Vi: IOAPIC[10] not in IVRS table
> > [0.220132] [Firmware
On Mon, Jan 21, 2013 at 02:09:42PM +0100, Borislav Petkov wrote:
> [0.220022] [Firmware Bug]: AMD-Vi: IOAPIC[9] not in IVRS table
> [0.220078] [Firmware Bug]: AMD-Vi: IOAPIC[10] not in IVRS table
> [0.220132] [Firmware Bug]: AMD-Vi: No southbridge IOAPIC found in IVRS
> table
> [0.
On Mon, Jan 21, 2013 at 03:10:19PM +0100, Udo van den Heuvel wrote:
> On 2013-01-21 14:09, Borislav Petkov wrote:
> >> Let's see what happens...
> >
> > Btw, while we're at it, here's some more h0rkage from my PD box:
> >
> > [0.220022] [Firmware Bug]: AMD-Vi: IOAPIC[9] not in IVRS table
> >
Hi Boris,
On Mon, Jan 21, 2013 at 09:37:31AM -0500, Boris Ostrovsky wrote:
> Are you talking about erratum 746?
The problems seen here are not about PPR failures, so it is not
particularily this erratum, but the workaround looks similar.
Joerg
--
To unsubscribe from this list: send th
On 2013-01-21 15:37, Boris Ostrovsky wrote:
>>> Btw, can't we add a quirk to disable NB clock gating? Maybe Boris and
>>> Jacob could help. CCed.
>
>
> Are you talking about erratum 746?
Link please?
If we have a link I could add that to the Gigabyte case.
Udo
--
To unsubscribe from this list:
On 01/20/2013 06:57 AM, Jörg Rödel wrote:
On Sun, Jan 20, 2013 at 12:48:28PM +0100, Borislav Petkov wrote:
On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
Yes, the BIOS vendor can fix this issue. They need to disable NB clock
gating for the IOMMU.
Right, Udo, you can try Gigabyt
On 2013-01-21 14:09, Borislav Petkov wrote:
>> Let's see what happens...
>
> Btw, while we're at it, here's some more h0rkage from my PD box:
>
> [0.220022] [Firmware Bug]: AMD-Vi: IOAPIC[9] not in IVRS table
> [0.220078] [Firmware Bug]: AMD-Vi: IOAPIC[10] not in IVRS table
> [0.22013
On Sun, Jan 20, 2013 at 12:57:55PM +0100, Jörg Rödel wrote:
> BorisO is no longer with AMD afaik.
Why am I not surprised...
> I wrote an email to Sherry and Suravee and asked them to either send
> me hardware to write the fix on my own or to send a fix for the issue.
> Let's see what happens...
On Sun, Jan 20, 2013 at 12:59:59PM +0100, Udo van den Heuvel wrote:
> On 2013-01-20 12:50, Borislav Petkov wrote:
> >> Right, Udo, you can try Gigabyte first.
> >
> > Btw, you're running the latest BIOS from them, I assume?
>
> Nope. But I am beyond their first released BIOS, I am running one of
On 2013-01-20 12:50, Borislav Petkov wrote:
>> Right, Udo, you can try Gigabyte first.
>
> Btw, you're running the latest BIOS from them, I assume?
Nope. But I am beyond their first released BIOS, I am running one of
their beta BIOSes. I am two beta updates behind current with F3g.
They list as d
On Sun, Jan 20, 2013 at 12:48:28PM +0100, Borislav Petkov wrote:
> On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
> > Yes, the BIOS vendor can fix this issue. They need to disable NB clock
> > gating for the IOMMU.
>
> Right, Udo, you can try Gigabyte first.
>
> Btw, can't we add a q
On 2013-01-20 12:48, Borislav Petkov wrote:
> On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
>> Yes, the BIOS vendor can fix this issue. They need to disable NB clock
>> gating for the IOMMU.
>
> Right, Udo, you can try Gigabyte first.
I just did so and referred to the kernel.org bug
On Sun, Jan 20, 2013 at 12:48:28PM +0100, Borislav Petkov wrote:
> On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
> > Yes, the BIOS vendor can fix this issue. They need to disable NB clock
> > gating for the IOMMU.
>
> Right, Udo, you can try Gigabyte first.
Btw, you're running the l
On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
> Yes, the BIOS vendor can fix this issue. They need to disable NB clock
> gating for the IOMMU.
Right, Udo, you can try Gigabyte first.
Btw, can't we add a quirk to disable NB clock gating? Maybe Boris and
Jacob could help. CCed.
Guys,
On Sun, Jan 20, 2013 at 12:25:07PM +0100, Udo van den Heuvel wrote:
> Hello Jörg,
>
> Hardware issue? What is wrong c.q. happening?
I think it falls under Erratum 455 (which does not mention IOMMU
specifically). Point is, there is a hardware workaround for this to make
the IOMMU work, but your BI
Hello Jörg,
On 2013-01-20 12:19, Jörg Rödel wrote:
> On Sun, Jan 20, 2013 at 11:40:20AM +0100, Udo van den Heuvel wrote:
>> Hello,
>>
>> On 2013-01-20 11:36, Borislav Petkov wrote:
>>> I know just the guy, CCed. :-)
>>
>> Thanks for the quick response!
>> I found this similar case:
>> https://bugs
On Sun, Jan 20, 2013 at 11:40:20AM +0100, Udo van den Heuvel wrote:
> Hello,
>
> On 2013-01-20 11:36, Borislav Petkov wrote:
> > I know just the guy, CCed. :-)
>
> Thanks for the quick response!
> I found this similar case:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1073384
Yes, this
Hello,
On 2013-01-20 11:36, Borislav Petkov wrote:
> I know just the guy, CCed. :-)
Thanks for the quick response!
I found this similar case:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1073384
Kind regards,
Udo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
I know just the guy, CCed. :-)
On Sun, Jan 20, 2013 at 11:33:19AM +0100, Udo van den Heuvel wrote:
>
> Hello,
>
> See below for a part of the logging on this F2A85X-UP4 with AMD
> a10-5800k. Box was raid checking I guess.
>
>
> Jan 20 03:42:08 s3 rsyslogd: [origin software="rsyslogd"
> swVersi
Hello,
See below for a part of the logging on this F2A85X-UP4 with AMD
a10-5800k. Box was raid checking I guess.
Jan 20 03:42:08 s3 rsyslogd: [origin software="rsyslogd"
swVersion="5.8.10" x-pid="3031" x-info="http://www.rsyslog.com";]
rsyslogd was HUPed
Jan 20 04:11:17 s3 kernel: AMD-Vi: Compl
38 matches
Mail list logo