Re: AMD Ryzen 5 3400G with Radeon Vega Graphics
On 2021-08-05 09:42, Hans Petter Selasky wrote: Hi, I was lucky to get the hands on a mini-ITX containing a "AMD Ryzen 5 3400G with Radeon Vega Graphics". FreeBSD-13 installed just fine and 4K HDMI output works too with AMDGPU. However I noticed some problems with a webcamd DVB-T receiver, that it had lots of dropouts I couldn't understand. When I looked closer at this it turns out that something was blocking the threads for longer amounts of time, up to 100 ms at random. After some debugging I eventually found: sysctl machdep.idle machdep.idle: acpi machdep.idle_available: spin, mwait, hlt, acpi And when I set it to: sysctl machdep.idle=spin The problems I saw vanished. Anyone else having such experiences with Ryzen? I have an Ryzen 5800X-based HP Omen 30L desktop, and don't have any issues, but the Omen has a Nvidia GPU and not a Radeon. I don't do live TV at all, haven't done so in a while. Two other PCs I had, both with Ryzen 3700Xs, my former Omen Obelisk and a homebuilt ASRockRack X470D4U server had no issues either. The server obviously doesn't have a GPU but both the 30L and Obelisk could play Toontown Rewritten under Wine without a hitch. I don't know which brand of PC or motherboard you have, but HP and ASRockRack both have no issues whatsoever. Not sure about regular ASRock (or HPE) though. Intel TigerLake/"Evo" was way more buggy for me than Ryzen ever was (not just drm-kmod). I ended up selling my TGL laptop and am in fact getting an Ryzen-based laptop to replace it. --HPS -Neel (nc@)
Re: CURRENT- and vmd(8): Panic upon bootup with recent HEAD
Hi Warner, On 2021-07-04 15:17, Warner Losh wrote: Have you used 'git bisect' yet? It looks like there's only about 244 commits between last known working and the known broken commit of mine I was about to do just that. I just posted incase I heard from anyone else about the commits. I guess I will do a `git bisect`. The panic is because we're trying to get the pci attributes of a non-pci device and an assertion is failing. Yes, I know. Warner Thanks for responding. -Neel (nc@)
CURRENT- and vmd(8): Panic upon bootup with recent HEAD
Hi freebsd-current@ (CC'd ambrisko@ and imp@), Right now, with a laptop (HP Spectre x360 13t-aw200) which needs the vmd(8) driver for NVMe, I am getting kernel panics upon bootup with a recent kernel. Here's a screenshot of the panic: https://bz-attachments.freebsd.org/attachment.cgi?id=226185 (blurry since I took it on the plane) The bug is here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256915 If I use an older kernel (which I'm doing for now), it works fine. If I use the memstick USB, it crashes with the same panic. I initially thought it was commit ddfc9c4c59e2ea4871100d8c076adffe3af8ff21, but even when I reverted to one before the said commit, it still panicked with the same error. I don't see any changes to vmd(8), so changes to some other PC subsystem (PCI/ACPI/x86/NVMe/etc.) after commit ab6d05336caaa10ae315f81534851e3764a8660c (current kernel commit) must have caused the error. -Neel (nc@)
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
Hi Hans,
Sorry if I have to bother you again.
On 2021-06-20 01:36, Hans Petter Selasky wrote:
sg_dma_address() is zero, because the memory hasn't been loaded.
Makes sense!
You need to handle two cases there:
When r->iobase is -1 and when it is not.
I suspect you should add r->iobase to the sg_dma_address() only and
only when it is non -1.
I have addressed it in my code.
Hans, while your approach is correct (that's also done in Linux), for
some reason it still crashes on vm_page_insert(). I must be doing "pa =
" wrong.
Stacktrace: https://misc.neelc.org/drm-kmod/stacktrace2.txt
I have a separate function for getting the physical address:
https://github.com/neelchauhan/drm-kmod/blob/5.7-wip/drivers/gpu/drm/i915/intel_freebsd.c#L219
This crash happens when "iobase == -1", so we execute Lines 228-231:
-
} else {
struct sgt_iter sgt = __sgt_iter(sgl, 0);
pa = (sgt.pfn + (sgt.curr >> PAGE_SHIFT)) << PAGE_SHIFT;
}
sgt.curr is zero, since (I believe) it's the first iteration.
I have copied the Linux approach and ported what I felt was necessary, I
am worried I am doing this wrong.
Also, there is a superfluous "pa = " in the beginning of the function.
(Hopefully) I have cleaned it up.
--HPS
-Neel (nc@)
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
On 2021-06-18 20:03, Neel Chauhan wrote: Apparently, the vm_start values is for some reason coming as 0 when it is passed into vm_fault_cpu(). That's why it's giving these errors: of course the address at 0 is mapped, it is (probably) used by the kernel. An update: The vm_start 0 seems to be expected. I checked the values with printf()s. I have posted this on Twitter, and am considering hiring a kernel consultant to help if I am unable to do this on my own. So I am guessing this line (Line 231) is incorrect: pa = sg_dma_address(sgl); Source: https://github.com/neelchauhan/drm-kmod/blob/d0eee96973ee0772e977b813678f92c5becf0507/drivers/gpu/drm/i915/intel_freebsd.c#L231 -Neel (nc@)
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
On 2021-06-18 12:19, Neel Chauhan wrote: I'm not sure. I'll just note that the Linux code appears to be trying to map a set of pages belonging to a scatter-gather list. Taking the physical address of the first page and assuming that all subsequent pages are physically contiguous doesn't seem correct, but this is what is happening in that loop, since each iteration simply increments pa by PAGE_SIZE. Good news! While I don't have a fix, I have figured out what the issue is. Apparently, the vm_start values is for some reason coming as 0 when it is passed into vm_fault_cpu(). That's why it's giving these errors: of course the address at 0 is mapped, it is (probably) used by the kernel. I will look more into it tomorrow, but my brother has come over to Seattle from Connecticut so I may not be able to dedicate as much time as I would like to. -Neel (nc@)
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
Hi Mark,
On 2021-06-18 06:57, Mark Johnston wrote:
That seems surprising, since the vm_page_grab() call should return the
page at pidx if one exists.
I believe that's not the case. I did pringfs
Any hints on where the physical address is? Should we have an
FreeBSD-specific "pa" argument for the physical address if it's
needed?
I'm not sure. I'll just note that the Linux code appears to be trying
to map a set of pages belonging to a scatter-gather list. Taking the
physical address of the first page and assuming that all subsequent
pages are physically contiguous doesn't seem correct, but this is what
is happening in that loop, since each iteration simply increments pa by
PAGE_SIZE.
Based on this email and our private one, and prior debugging it seems
this panic comes on the first iteration. Something must be
vm_page_grab() returns NULL, and then we run:
if (!vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL))
goto retry;
if (vm_page_insert(m, vm_obj, pidx)) {
vm_page_xunbusy(m);
VM_OBJECT_WUNLOCK(vm_obj);
vm_wait(NULL);
VM_OBJECT_WLOCK(vm_obj);
goto retry;
}
Source:
https://github.com/neelchauhan/drm-kmod/blob/d0eee96973ee0772e977b813678f92c5becf0507/drivers/gpu/drm/i915/intel_freebsd.c#L245
The first if() doesn't panic, but we panic at the second one, it doesn't
go into or jumo over the statement.
I could use for() or for_each_sg_page() and they both panic.
I am almost feeling I'd have to hire a FreeBSD kernel consultant and/or
sell my TigerLake laptop for an AMD Ryzen-based laptop.
-Neel (nc@)
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
Hi Mark, Thank you so much for your response! On 2021-06-16 14:05, Mark Johnston wrote: The function in question appears to implement a device page fault handler. In FreeBSD, such handlers are responsible only for ensuring that the requested page(s) are present in the VM object backing the mapping that was faulted on. The generic fault handler in sys/vm/vm_fault.c is responsible for actually updating the faulting process' page tables by calling pmap_enter(). In other words, our fault handler interface is quite different from OpenBSD's and their example should not be followed exactly. Adding a vm_object_busy() call in the loop will silence the assertion I guess but the handler is still wrong. Good to hear. No wonder why I still had the "blank screen of death" with the (now previous) code. If you look further down at vm_fault_gtt() (and in earlier versions of the DRM drivers, i915_gem_fault()), the remap_io_mapping() implementation in the LinuxKPI does basically what I'm describing. Something similar is required for vm_fault_cpu(), though I don't quite understand when vm_fault_cpu() is supposed to be used. I have some code to implement remap_io_sg() based on remap_io_mapping(), but it's not complete. I am still trying to figure out how to get the physical address. Right now, I have: https://github.com/neelchauhan/drm-kmod/commit/92a3d9bb585acb55c1dab9c5ed11190f7db73ecf My get_pfn() function (Lines 221-231) attempts to get the physical address, and it is called at Line 248. Note: This code is probably incorrect, since it gives me an "page already inserted" panic. Any hints on where the physical address is? Should we have an FreeBSD-specific "pa" argument for the physical address if it's needed? Sorry for the kernel newbie questions. -Neel (nc@)
Re: Kernel/driver hacking: panic: Assertion vm_object_busied((m->object)) failed at /usr/src/sys/vm/vm_page.c:5455
Hi, On 2021-06-16 00:35, Hans Petter Selasky wrote: Do you have the full backtrace? Yes. I have attached a stack trace in the previous email, but if you didn't get it, I have uploaded it to GitHub: https://gist.github.com/neelchauhan/437bd10239f84c563aafb37ab440029a Doesn't this code work in the current DRM - kmod? What changed? Did you perhaps miss a patch? I think there is new code with Linux 5.6 which changes how this is done. I have been attempting to make a FreeBSD equivalent, but it panics. It is **not** from missing Linux commits since I believe I added them all. The code in my GH repo: https://github.com/neelchauhan/drm-kmod/blob/5.7-wip/drivers/gpu/drm/i915/gem/i915_gem_mman.c#L346 --HPS -Neel (nc@)
Re: Can In-Kernel TLS (kTLS) work with any OpenSSL Application?
Hi Mark, Thank you so much for your response describing how QAT encryption works. I learned that my server (HPE ProLiant ML110 Gen10) does not have QAT, mainly because the chipset (Intel C621) doesn't enable it. For reference, my firewall box (Intel D-1518-based HPE ProLiant EC200a) probably does, but I'm not going to use it for Tor. Tor uses 512-byte sized packets (a.k.a "cells") so even if I had QAT it may not work well, not to mention Tor is singlethreaded. I think I'll stick with kTLS with AESNI when 13.0-RELEASE is out. Worse case scenario I'll buy an AMD Ryzen-based PC and offload my Tor servers to it (assuming latest Ryzen > Skylake Xeon Scalable in single-thread performance). -Neel On 2021-01-27 11:04, Mark Johnston wrote: On Sat, Jan 23, 2021 at 03:25:59PM +, Rick Macklem wrote: Ronald Klop wrote: >On Wed, 20 Jan 2021 21:21:15 +0100, Neel Chauhan wrote: > >> Hi freebsd-current@, >> >> I know that In-Kernel TLS was merged into the FreeBSD HEAD tree a while >> back. >> >> With 13.0-RELEASE around the corner, I'm thinking about upgrading my >> home server, well if I can accelerate any SSL application. >> >> I'm asking because I have a home server on a symmetrical Gigabit >> connection (Google Fiber/Webpass), and that server runs a Tor relay. If >> you're interested in how Tor works, the EFF has a writeup: >> https://www.eff.org/pages/what-tor-relay >> >> But the main point for you all is: more-or-less Tor relays deal with >> 1000s TLS connections going into and out of the server. >> >> Would In-Kernel TLS help with an application like Tor (or even load >> balancers/TLS termination), or is it more for things like web servers >> sending static files via sendfile() (e.g. CDN used by Netflix). >> >> My server could also work with Intel's QuickAssist (since it has an >> Intel Xeon "Scalable" CPU). Would QuickAssist SSL be more helpful here? There is now qat(4), which KTLS should be able to use, but I do not think it has been tested for this. I also have no idea if it can be used effectively for userland encryption? KTLS requires support for separate output buffers and AAD buffers, which I hadn't implemented in the committed driver. I have a working patch which adds that, so when that's committed qat(4) could in principle be used with KTLS. So far I only tested with /dev/crypto and a couple of debug sysctls used to toggle between the different cryptop buffer layouts, not with KTLS proper. qat(4) can be used by userspace via cryptodev(4). This comes with a fair bit of overhead since it involves a round-trip through the kernel and some extra copying. AFAIK we don't have any framework for exposing crypto devices directly to userspace, akin to DPDK's polling mode drivers or netmap. I've seen a few questions about the comparative (dis)advantages of QAT and AES-NI so I'll sidetrack a bit and try to characterize qat(4)'s performance here based on some microbenchmarking I did this week. This was all done in the kernel and so might need some qualification if you're interested in using qat(4) from userspace. Numbers below are gleaned from an Atom C3558 at 2.2GHz with an integrated QAT device. I mostly tested AES-CBC-256 and AES-GCM-256. The high-level tradeoffs are: - qat(4) introduces a lot of latency. For a single synchronous operation it can take between 2x and 100x more time than aesni(4) to complete. aesni takes 1000-2000 cycles to handle a request plus 3-5 cycles per byte depending on the algorithm. qat takes at least ~150,000 cycles between calling crypto_dispatch() and the cryptop completion callback, plus 5-8 cycles per byte. qat dispatch itself is quite cheap, typically 1000-2000 cycles depending on the size of the buffer. Handling a completion interrupt involves a context switch to the driver ithread but this is also a small cost relative to the entire operation. So, for anything where latency is crucial QAT is probably not a great bet. - qat can save a correspondingly large number of CPU cycles. It takes qat roughly twice as long as aesni to complete encryption of a 32KB buffer using AES-CBC-256 (more with GCM), but with qat the CPU is idle much of the time. Dispatching the request to firmware takes less than 1% of the total time elapsed between request dispatch and completion, even with small buffers. OTOH with really small buffers aesni can complete a request in the time that it takes qat just to dispatch the request to the device, so at best qat will give comparable throughput and CPU usage and worse latency. - qat can handle multiple requests in parallel. This can improve throughput dramatically if the producer can keep qat busy. Empirically, the maximum throughput improvement is a function of the request size. For example, counting the numb
Can In-Kernel TLS (kTLS) work with any OpenSSL Application?
Hi freebsd-current@, I know that In-Kernel TLS was merged into the FreeBSD HEAD tree a while back. With 13.0-RELEASE around the corner, I'm thinking about upgrading my home server, well if I can accelerate any SSL application. I'm asking because I have a home server on a symmetrical Gigabit connection (Google Fiber/Webpass), and that server runs a Tor relay. If you're interested in how Tor works, the EFF has a writeup: https://www.eff.org/pages/what-tor-relay But the main point for you all is: more-or-less Tor relays deal with 1000s TLS connections going into and out of the server. Would In-Kernel TLS help with an application like Tor (or even load balancers/TLS termination), or is it more for things like web servers sending static files via sendfile() (e.g. CDN used by Netflix). My server could also work with Intel's QuickAssist (since it has an Intel Xeon "Scalable" CPU). Would QuickAssist SSL be more helpful here? I'm asking since I don't know whether to upgrade my home server to 13.x or leave it at 12.x. Yes, I do know we need a special OpenSSL to use kTLS. -Neel signature.asc Description: OpenPGP digital signature
Re: PCIe Root Port/Bus Not Detected in VMD
For reference, I am attaching the `pciconf -lv` and `acpidump -dt`
dumps.
-Neel
On 2020-12-30 21:42, Neel Chauhan wrote:
Hi freebsd-current@,
My apologies for so many emails from me. I sent another copy of this
email to freebsd-hackers@.
I have the following patch:
diff --git a/sys/dev/vmd/vmd.c b/sys/dev/vmd/vmd.c
index 2cc6f45bed9..7cc0a8a91a7 100644
--- a/sys/dev/vmd/vmd.c
+++ b/sys/dev/vmd/vmd.c
@@ -66,10 +66,12 @@ struct vmd_type {
#define INTEL_VENDOR_ID0x8086
#define INTEL_DEVICE_ID_VMD0x201d
#define INTEL_DEVICE_ID_VMD2 0x28c0
+#define INTEL_DEVICE_ID_VMD3 0x9a0b
static struct vmd_type vmd_devs[] = {
{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume
Management Device" },
{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume
Management Device" },
+{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume
Management Device" },
{ 0, 0, NULL }
};
@@ -425,6 +427,7 @@ vmd_attach(device_t dev)
return (0);
fail:
+ rman_fini(>vmd_bus.rman);
vmd_free(sc);
return (ENXIO);
}
This patch helps me detect the VMD controller, but I am unable to
attach to it.
Therefore, I am not able to attach any PCIe buses that will be used by
a NVMe SSD.
If this patch worked, I would see these devices (as I do in Linux):
1:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI
Express Root Port #9 [8086:a0b0] (rev 20) SI
1:e0:1d.2 PCI bridge [0604]: Intel Corporation Device [8086:a0b2]
(rev 20)
1:e1:00.0 Non-Volatile memory controller [0108]: Intel Corporation
Device [8086:0975] (rev 03)
1:e2:00.0 Non-Volatile memory controller [0108]: Intel Corporation
Device [8086:0975]
And therefore a `nvd*` device.
Could a developer please help me with this?
-Neel
===
https://www.neelc.org/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
/*
RSD PTR: OEM=HPQOEM, ACPI_Rev=2.0x (2)
XSDT=0x54dbb728, length=36, cksum=206
*/
/*
XSDT: Length=276, Revision=1, Checksum=54,
OEMID=HPQOEM, OEM Table ID=SLIC-MPC, OEM Revision=0x1072009,
Creator ID=AMI, Creator Revision=0x113
Entries={ 0x54db6000, 0x54dba000, 0x54db7000,
0x54d61000, 0x54d6, 0x54d5c000, 0x54d55000,
0x54d48000, 0x54d47000, 0x54d45000, 0x54d44000,
0x54d4, 0x54d3f000, 0x54d3e000, 0x54d3d000,
0x54d3c000, 0x54d3b000, 0x54d3a000, 0x54d39000,
0x54d38000, 0x54d37000, 0x54de6000, 0x54de5000,
0x54d36000, 0x54d49000, 0x54d59000, 0x54d35000,
0x54d43000, 0x54d34000, 0x54d33000 }
*/
/*
FACP: Length=276, Revision=6, Checksum=163,
OEMID=HPQOEM, OEM Table ID=SLIC-MPC, OEM Revision=0x1072009,
Creator ID=HP, Creator Revision=0x10013
FACS=0x54e77000, DSDT=0x54d62000
INT_MODEL=PIC
Preferred_PM_Profile=Mobile (2)
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xa0, ACPI_DISABLE=0xa1, S4BIOS_REQ=0x0
PSTATE_CNT=0x0
PM1a_EVT_BLK=0x1800-0x1803
PM1a_CNT_BLK=0x1804-0x1805
PM2_CNT_BLK=0x1850-0x1850
PM_TMR_BLK=0x1808-0x180b
GPE0_BLK=0x1860-0x187f
P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us
FLUSH_SIZE=1024, FLUSH_STRIDE=16
DUTY_OFFSET=1, DUTY_WIDTH=3
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
IAPC_BOOT_ARCH={8042,NO_ASPM}
Flags={WBINVD,C1_SUPPORTED,SLEEP_BUTTON,S4_RTC_WAKE,RESET_REGISTER,PCI_EXPRESS_WAKE,PLATFORM_CLOCK,S4_RTC_VALID,REMOTE_POWER_ON,LOW_POWER_S0}
RESET_REG=0xb2:0[8] (IO), RESET_VALUE=0xeb
*/
/*
FACS: Length=64, HwSig=0xc0f1be2f, Firm_Wake_Vec=0x
Global_Lock=
Flags=
Version=2
*/
/*
DSDT: Length=341924, Revision=2, Checksum=197,
OEMID=HPQOEM, OEM Table ID=8709, OEM Revision=0x1072009,
Creator ID=ACPI, Creator Revision=0x20191018
*/
/*
MCFG: Length=60, Revision=1, Checksum=37,
OEMID=HPQOEM, OEM Table ID=8709, OEM Revision=0x1072009,
Creator ID=HP, Creator Revision=0x97
Base Address=0xc000
Segment Group=0x
Start Bus=0
End Bus=255
*/
/*
SSDT: Length=9679, Revision=2, Checksum=73,
OEMID=HPQOEM, OEM Table ID=8709, OEM Revision=0x3000,
Creator ID=ACPI, Creator Revision=0x20191018
*/
/*
FIDT: Length=156, Revision=1, Checksum=210,
OEMID=HPQOEM, OEM Table ID=8709, OEM Revision=0x1072009,
Creator ID=HP, Creator Revision=0x10013
*/
/*
MSDM: Length=85, Revision=3, Checksum=196,
OEMID=HPQOEM, OEM Table ID=SLIC-MPC, OEM Revision=0x1,
Creator ID
PCIe Root Port/Bus Not Detected in VMD
Hi freebsd-current@,
My apologies for so many emails from me. I sent another copy of this
email to freebsd-hackers@.
I have the following patch:
diff --git a/sys/dev/vmd/vmd.c b/sys/dev/vmd/vmd.c
index 2cc6f45bed9..7cc0a8a91a7 100644
--- a/sys/dev/vmd/vmd.c
+++ b/sys/dev/vmd/vmd.c
@@ -66,10 +66,12 @@ struct vmd_type {
#define INTEL_VENDOR_ID0x8086
#define INTEL_DEVICE_ID_VMD0x201d
#define INTEL_DEVICE_ID_VMD2 0x28c0
+#define INTEL_DEVICE_ID_VMD3 0x9a0b
static struct vmd_type vmd_devs[] = {
{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume
Management Device" },
{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume
Management Device" },
+{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume
Management Device" },
{ 0, 0, NULL }
};
@@ -425,6 +427,7 @@ vmd_attach(device_t dev)
return (0);
fail:
+ rman_fini(>vmd_bus.rman);
vmd_free(sc);
return (ENXIO);
}
This patch helps me detect the VMD controller, but I am unable to attach
to it.
Therefore, I am not able to attach any PCIe buses that will be used by a
NVMe SSD.
If this patch worked, I would see these devices (as I do in Linux):
1:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI
Express Root Port #9 [8086:a0b0] (rev 20) SI
1:e0:1d.2 PCI bridge [0604]: Intel Corporation Device [8086:a0b2]
(rev 20)
1:e1:00.0 Non-Volatile memory controller [0108]: Intel Corporation
Device [8086:0975] (rev 03)
1:e2:00.0 Non-Volatile memory controller [0108]: Intel Corporation
Device [8086:0975]
And therefore a `nvd*` device.
Could a developer please help me with this?
-Neel
===
https://www.neelc.org/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
On 2020-12-30 21:04, Neel Chauhan wrote: It is likely because VMD uses PCI domain above 0x1 but we aren't looking at this. The 0x1 is purely a Linux construct. It seems the PCI domains are virtual. Source: https://lists.x.org/archives/xorg-devel/2016-August/050590.html -Neel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
I think I found the issue: This PCIe controller is not detected: 1:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI Express Root Port #9 [8086:a0b0] (rev 20) SI I believe the above PCIe controller is exposed by VMD (as it is on Linux), but FreeBSD vmd/vmd_bus is unable to attach this controller. It is likely because VMD uses PCI domain above 0x1 but we aren't looking at this. Source: https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L437 Don't yet have a patch though. Sorry for the number of emails earlier. -Neel On 2020-12-30 10:04, Chuck Tuffli wrote: On Tue, Dec 29, 2020 at 6:30 PM Neel Chauhan wrote: Hi freebsd-hackers@, CC'd freebsd-current@, I hope you all had a wonderful holiday season. I recently got a HP Spectre x360 13t-aw200 which is an Intel TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane" SSD which I disabled (so I can get a "second" SSD). On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ I don't know if it is HP or Intel, but the VMD IDs device id is 8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also have this device ID [1]. Sadly, NVMe RAID is forced on this laptop. I wrote a rough patch to add the device IDs, and the patch is below: FWIW, that is the same change I would have made. Peeking at the Linux vmd driver, it doesn't appear to do anything special for 8086:9a0b as compared to the 8086:2a0c device the FreeBSD driver already supports. That said, the Linux driver reads a capability register to determine the bus number start (vmd_bus_number_start()) which I don't see in the FreeBSD driver. This is curious because, looking at the "lspci all" output from the XPS link you provided, the NVMe device shows up in PCI domain 0x1000 (i.e. not 0x). Which (and I have no direct experience with this device or code) only happens if the bus number start function returns 0x0. What is the output from # pciconf -rb pci0:0:14:0 0x40:0x48 --chuck ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
I have attached two files: * pcidump.txt: A dump of `pciconf -lv` * acpidump.txt: A dump of `acpidump` Hope this can help. -Neel On 2020-12-30 17:21, Neel Chauhan wrote: To extend, I am getting an issue with `pci_read_device()` where it returns a `vid` (PCI Vendor ID) of 0x. This ends up returning "Cannot allocate dinfo!" from vmd. Log (via grep): https://imgur.com/a/tAmmY7i -Neel On 2020-12-30 16:38, Neel Chauhan wrote: Hi Chuck, On 2020-12-30 10:04, Chuck Tuffli wrote: What is the output from # pciconf -rb pci0:0:14:0 0x40:0x48 The output is: 01 00 00 00 01 2e 68 02 00 --chuck I was also able to stop kernel panics by adding: rman_fini(>vmd_bus.rman); In the fail: statement in vmd_attach(). But I still cannot detect the SSD. -Neel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" hostb0@pci0:0:0:0: class=0x06 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a14 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = '11th Gen Core Processor Host Bridge/DRAM Registers' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x03 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a49 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'UHD Graphics' class = display subclass = VGA none0@pci0:0:4:0: class=0x118000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a03 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' class = dasp pcib1@pci0:0:7:0: class=0x060400 rev=0x01 hdr=0x01 vendor=0x8086 device=0x9a23 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt PCI Express Root Port' class = bridge subclass = PCI-PCI pcib2@pci0:0:7:1: class=0x060400 rev=0x01 hdr=0x01 vendor=0x8086 device=0x9a25 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt PCI Express Root Port' class = bridge subclass = PCI-PCI none1@pci0:0:8:0: class=0x088000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a11 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' class = base peripheral xhci0@pci0:0:13:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a13 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt USB Controller' class = serial bus subclass = USB none2@pci0:0:13:2: class=0x0c0340 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a1b subvendor=0x subdevice=0x vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt NHI' class = serial bus subclass = USB none3@pci0:0:14:0: class=0x010400 rev=0x00 hdr=0x00 vendor=0x8086 device=0x9a0b subvendor=0x8086 subdevice=0x vendor = 'Intel Corporation' device = 'Volume Management Device NVMe RAID Controller' class = mass storage subclass = RAID none4@pci0:0:18:0: class=0x07 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0fc subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Integrated Sensor Hub' class = simple comms subclass = UART xhci1@pci0:0:20:0: class=0x0c0330 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0ed subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller' class = serial bus subclass = USB none5@pci0:0:20:2: class=0x05 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0ef subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Shared SRAM' class = memory subclass = RAM none6@pci0:0:20:3: class=0x028000 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0f0 subvendor=0x8086 subdevice=0x0074 vendor = 'Intel Corporation' device = 'Wi-Fi 6 AX201' class = network ig4iic0@pci0:0:21:0:class=0x0c8000 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0e8 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Serial IO I2C Controller' class = serial bus ig4iic1@pci0:0:21:1:class=0x0c8000 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0e9 subvendor=0x103c subdevice=0x8709 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Serial IO I2C Controller' class = serial bus none7@pci0:0:22:0: class=
Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
To extend, I am getting an issue with `pci_read_device()` where it returns a `vid` (PCI Vendor ID) of 0x. This ends up returning "Cannot allocate dinfo!" from vmd. Log (via grep): https://imgur.com/a/tAmmY7i -Neel On 2020-12-30 16:38, Neel Chauhan wrote: Hi Chuck, On 2020-12-30 10:04, Chuck Tuffli wrote: What is the output from # pciconf -rb pci0:0:14:0 0x40:0x48 The output is: 01 00 00 00 01 2e 68 02 00 --chuck I was also able to stop kernel panics by adding: rman_fini(>vmd_bus.rman); In the fail: statement in vmd_attach(). But I still cannot detect the SSD. -Neel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
Hi Chuck, On 2020-12-30 10:04, Chuck Tuffli wrote: What is the output from # pciconf -rb pci0:0:14:0 0x40:0x48 The output is: 01 00 00 00 01 2e 68 02 00 --chuck I was also able to stop kernel panics by adding: rman_fini(>vmd_bus.rman); In the fail: statement in vmd_attach(). But I still cannot detect the SSD. -Neel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
Hi freebsd-hackers@, CC'd freebsd-current@,
I hope you all had a wonderful holiday season.
I recently got a HP Spectre x360 13t-aw200 which is an Intel
TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane"
SSD which I disabled (so I can get a "second" SSD).
On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ
I don't know if it is HP or Intel, but the VMD IDs device id is
8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also have
this device ID [1].
Sadly, NVMe RAID is forced on this laptop.
I wrote a rough patch to add the device IDs, and the patch is below:
--- a/sys/dev/vmd/vmd.c
+++ b/sys/dev/vmd/vmd.c
@@ -66,13 +66,20 @@ struct vmd_type {
#define INTEL_VENDOR_ID0x8086
#define INTEL_DEVICE_ID_VMD0x201d
#define INTEL_DEVICE_ID_VMD2 0x28c0
+#define INTEL_DEVICE_ID_VMD3 0x9a0b
static struct vmd_type vmd_devs[] = {
{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume
Management Device" },
{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume
Management Device" },
+{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume
Management Device" },
{ 0, 0, NULL }
However, I get a panic whenever I use this patch:
https://imgur.com/a/XUQksOi
Without this patch, I am able to boot fine but can't see the SSD or any
nvd* devices beyond a "none" device in `pciconf -lv`.
For those who know about PCI/ACPI subsystems, can you please tell me
what's going wrong?
I'm still debugging in the meanwhile, but am no expert on PCI/ACPI
subsystems. I may know more than most PC builders or CS grads, but not
really enough to do it full-time.
The Spectre's SSD works fine with Windows 10 (obviously) and Linux
(Fedora and Debian tested).
Best,
Neel Chauhan
Sources:
[1]: Linux probes:
* Vostro: https://certification.ubuntu.com/hardware/202007-28047
* XPS: https://linux-hardware.org/?probe=ba53f6e513
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r362666 breaking buildworld (don't know how to make nvpair.c) & Fix/Patch
On 2020-06-26 21:20, Matthew Macy wrote: Well - it was from his review. That's true. Thanks for committing! -Neel === https://www.neelc.org/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r362666 breaking buildworld (don't know how to make nvpair.c) & Fix/Patch
Hi, When I attempt to build world in 13-CURRENT, I get this error: ===> lib/libnv (obj,includes,all,install) [Creating objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libnv...] make[3]: make[3]: don't know how to make nvpair.c. Stop make[3]: stopped in /usr/src/lib/libnv *** [legacy] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_legacy] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src root@omen:/usr/src # The build broke with mmacy@'s commit r362666 which renamed nvpair.c to bsd_nvpair.c without renaming the Makefile. Is anyone else having this error? I have a patch to unbreak the build here: https://reviews.freebsd.org/D25481 Does the patch work? Best, Neel Chauhan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nvme on 2019 macbooks
I don't have a MacBook. I don't own one and my work gives me a ThinkPad (but runs Windows). I believe the issue on new Macs is the NVMe queue size or something. You should read the Linux driver, the FreeBSD equivalents, and then build your patch on the differences in how the hardware is handled. This is how I got my 2018 HP Spectre x360 to work (but with different subsystems), and you could do the same on newer Apple NVMe. If you get something working, consider making a patch and submitting it. That's what I done with my Spectre, and it has been in HEAD for a few months now. -Neel === https://www.neelc.org/ On 2020-04-29 10:43, Yuri Pankov wrote: I have tried booting latest -current snapshot on 2019 macbook pro 16, and noticed that nvme driver didn't attach, as class reported is 0x018002 and not 0x010802 that we expect in nvme_pci.c. The following linux changes seem to be related: https://github.com/torvalds/linux/commit/66341331ba0d2de4ff421cdc401a1e34de50502a https://github.com/torvalds/linux/commit/d38e9f04ebf667d9cb8185b45bff747485f1d3e9 I have tried adding the exact PCI IDs, but that also fails as number of msix vectors seems to be 0 in nvme_ctrlr_setup_interrupts() and nvme_ctrlr_configure_intx() fails with "unable to allocate shared IRQ". Any hints on how to proceed here? pciconf excerpt: none7@pci0:4:0:0: class=0x018002 rev=0x01 hdr=0x00 vendor=0x106b device=0x2005 subvendor=0x106b subdevice=0x1800 vendor = "Apple Inc." device = "ANS2 NVMe Controller" class = mass storage bar [10]= type Prefetchable Memory, range 64, base 0xc040, size 419304, enabled bar [18]= type Prefetchable Memory, range 64, base 0xc140, size 524288, enabled bar [20]= type Prefetchable Memory, range 64, base 0xc160, size 65536, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 8 messages, 64 bit cap 10[70] = PCI-Express 2 endpoint max data 256(256) RO NS link x4(x4) speed 8.0(8.0) ASPM L1(L1) ClockPM enabled ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0019[148] = PCIe Sec 1 lane errors 0 ecap 0018[168] = LTR 1 ecap 001e[170] = L1 PM Substated 1 ecap 000b[180] = Vendor [1] ID 0002 Rev 1 Length 256 ecap 0015[280] = Resizable BAR 1 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to enable tcp bbr in FreeBSD???
Not OP, but would BBR work with VNET, or is that a WIP? I'm sorry if none of you are familiar with VNET. -Neel === https://www.neelc.org/ BTW: Not neel@ the committer On 2020-04-24 12:25, Michael Tuexen wrote: On 24. Apr 2020, at 21:06, Rodney W. Grimes wrote: On Fri, Apr 24, 2020 at 01:31:35PM +0200, Kurt Jaeger wrote: Thanks. Is BBR active automatically or is there a sysctl or socket option to activate it ? net.inet.tcp.cc.available: List available congestion control algorithms net.inet.tcp.cc.algorithm: Default congestion control algorithm Start at: man mod_cc BBR is conceptually a CC, but in FreeBSD it is NOT implemented as a CC module. It is a TCP stack. You need to load it using kldload tcp_bbr and then either make it the default by sudo sysctl net.inet.tcp.functions_default=bbr or use the IPPROTO_TCP level socket option TCP_FUNCTION_BLK to set the stack to BBR. The uperf test tool allows to set the TCP stack for measurements. Please note that you need to compile the kernel with makeoptions WITH_EXTRA_TCP_STACKS=1 options TCPHPTS Best regards Michael -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
No battery status on 13-CURRENT?
Hi freebsd-current@ I have a a HP Spectre x360 13-ap0053dx running 13-CURRENT r360134, I get this when running acpiconf -i 0: root@spectre:/home/neel # acpiconf -i 0 Design capacity:0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Design voltage: 0 mV Capacity (warn):0 mWh Capacity (low): 0 mWh Cycle Count:0 Mesurement Accuracy:0 % Max Sampling Time: 0 ms Min Sampling Time: 0 ms Max Average Interval: 0 ms Min Average Interval: 0 ms Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage:unknown root@spectre:/home/neel # Also, hw.acpi.acline appears if my system is plugged in when it isn't: root@spectre:/home/neel # sysctl hw.acpi.acline hw.acpi.acline: 1 root@spectre:/home/neel # However, using my "old" kernel with build r359837 works, and so does Windows 10. I also posted to Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245778 Is anyone else having this issue? -Neel === https://www.neelc.org/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[MFC Request]: snd_hda: Add Intel Cannon Lake support (r352775) isn't in 12-STABLE or 11-STABLE
Hi freebsd-current@, Back in September, I submitted a patch which adds support for the HD Audio codecs in Intel's Cannon Lake PCH as used by the HP Spectre x360 2018/13-ap0053dx (the "13-p0043dx" is a typo). This was committed as r352775 and r352776. However, these two patches are not in 12-STABLE or 11-STABLE, despite having a MFC tag. This means people with newer Cannon Lake-based laptops like the 2018 Spectre x360 (or a ThinkPad with an equivalent PCH) are forced to use CURRENT. Could someone please MFC these patches? -Neel === https://www.neelc.org/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
13-CURRENT r355560: GNOME and KDE crash when logging in
Hi freebsd-current@ mailing list, When I updated my laptop to r355560, I could boot into GDM, but logging into GNOME led to a coredump and brought me back to GDM. I tried KDE, but logging in via SDDM also led to a crash. I noted a lot of changes to the VM subsystem have happened, are they related to the crashes? Not meaning that r355560 specifically caused the issue, but that's the last checked out revision. I don't have coredumps, sorry. Looks like my laptop will be booting into Windows for the time being. Running -STABLE is not an option because of unsupported hardware there. -Neel === https://www.neelc.org/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
13-CURRENT r355560: GNOME and KDE crash when logging in
Hi freebsd-current@, freebsd-ports@ mailing lists, When I updated my laptop to r355560, I could boot into GDM, but logging into GNOME led to a coredump and brought me back to GDM. I tried KDE, but logging in via SDDM also led to a crash. I noted a lot of changes to the VM subsystem have happened, are they related to the crashes? Not meaning that r355560 specifically caused the issue, but that's the last checked out revision. I don't have coredumps, sorry. Looks like my laptop will be booting into Windows for the time being. Running -STABLE is not an option because of unsupported hardware there. -Neel === https://www.neelc.org/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
For me, the following code is still necessary for me (HP Spectre x360
2018), which is the remaining parts of the patches not committed if you
are using a recent kernel. I don't know about you all ThinkPad users, it
should still apply as it's Intel in general not just HP or Lenovo.
Without these patches, I get a kernel panic.
Keep in mind that the patch may render as spaces, but it should be tabs.
Index: amd64/pmap.c
===
--- amd64/pmap.c(revision 353788)
+++ amd64/pmap.c(working copy)
@@ -355,8 +355,9 @@
}\
} while (0)
-#defineCHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m)\
-CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m))
+#defineCHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m) do {\
+CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m)); \
+} while (0)
#defineRELEASE_PV_LIST_LOCK(lockp)do {\
struct rwlock **_lockp = (lockp);\
@@ -951,8 +952,16 @@
static u_long *
pmap_delayed_invl_genp(vm_page_t m)
{
+vm_paddr_t pa;
+u_long *gen;
-return (_to_pmdp(VM_PAGE_TO_PHYS(m))->pv_invl_gen);
+pa = VM_PAGE_TO_PHYS(m);
+if (__predict_false((pa) > pmap_last_pa))
+gen = _dummy_large.pv_invl_gen;
+else
+gen = &(pa_to_pmdp(pa)->pv_invl_gen);
+
+return (gen);
}
#else
static u_long *
-Neel
===
https://www.neelc.org/
On 2019-10-20 02:45, Yuri Pankov wrote:
On 10/18/2019 8:01 AM, Xin Li wrote:
Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
-> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it)
,
the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.
Confirmed that it worked for me too on P51.
Sorry for offtopic, but do you see the console getting "stuck" after
loading i915kms, i.e. for input to show you need to switch to another
console and back?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
This still panicks for me, but with a different error. https://i.postimg.cc/K8nxF57G/IMG-20191018-045338.jpg I really should be sleeping but can't because I have to use an older kernel to have working graphics. Thanks, Netflix for making my life harder. -Neel On 2019-10-18 01:01, Xin Li wrote: Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. On 2019-10-17 18:37, Neel Chauhan wrote: However, the patch to drm-kmod doesn't work for me. I tried both drm-devel-kmod and drm-current-kmod. https://i.imgur.com/81JvaOO.jpg -Neel === https://www.neelc.org/ On 2019-10-17 17:35, Eirik Øverby wrote: On 10/17/19 11:29 PM, Eirik Øverby wrote: On 10/17/19 10:31 PM, Niclas Zeising wrote: On 2019-10-17 21:53, ma...@freebsd.org wrote: On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: .. I believe it was the recent work on the vm page busy state, r353539 specifically. This patch should fix it; we don't yet have a __FreeBSD_version number bump on which to gate the patch. ...>> Hi! Hopefully someone can confirm that this patch to drm-current-kmod or drm-devel-kmod fixes the issue. I won't be able to work on this before the weekend at the earliest, I'm afraid. Mark, is it possible to get a belated version bump for this fix, and what changed to require it? Built, rebooting ... Will hopefully check back in soon. And tada, I'm back. That seemed to do the trick. Thanks! /Eirik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
However, the patch to drm-kmod doesn't work for me. I tried both drm-devel-kmod and drm-current-kmod. https://i.imgur.com/81JvaOO.jpg -Neel === https://www.neelc.org/ On 2019-10-17 17:35, Eirik Øverby wrote: On 10/17/19 11:29 PM, Eirik Øverby wrote: On 10/17/19 10:31 PM, Niclas Zeising wrote: On 2019-10-17 21:53, ma...@freebsd.org wrote: On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: .. I believe it was the recent work on the vm page busy state, r353539 specifically. This patch should fix it; we don't yet have a __FreeBSD_version number bump on which to gate the patch. ...>> Hi! Hopefully someone can confirm that this patch to drm-current-kmod or drm-devel-kmod fixes the issue. I won't be able to work on this before the weekend at the earliest, I'm afraid. Mark, is it possible to get a belated version bump for this fix, and what changed to require it? Built, rebooting ... Will hopefully check back in soon. And tada, I'm back. That seemed to do the trick. Thanks! /Eirik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
While drm-current-kmod worked for a little while, it broke with r353645.
https://i.imgur.com/Q5nYZf2.jpg
I'm using the same HP Spectre that I used earlier (where it worked and
where it panicked).
-Neel
===
https://www.neelc.org/
On 2019-10-13 10:37, Mateusz Guzik wrote:
On 10/13/19, Evilham wrote:
Hello,
I somehow had managed to mess up my build system and only
yesterday got it back to compiling properly.
So to be clear, there is an unrelated bug where it seems the module can
decide to abort loading and then it crashes in pseudofs. This can
happen
if there is a mismatch between the kernel and the module itself.
On ds., oct. 12 2019, Mateusz Guzik wrote:
Try this:
https://people.freebsd.org/~mjg/pmap-fict-invl.diff
I tested this patch on top of r353449 and a panic is still
ocurring when the drm-kmod modules are loaded.
This is on a Lenovo A485 Laptop, which is an AMD Ryzen processor
and a Radeon Vega graphics.
My last known working revision is r352987.
Here are bits of the core dump, I hope they are useful, if more
information is needed, please don't hesitate to ask.
BTW: I usually compile GENERIC-NODEBUG, if that results in the
dump being useless (sadly I can't tell), I can disable all the
performance goodies and compile GENERIC :-).
--
Evilham
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xf8
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80b1be61
stack pointer = 0x28:0xfe00dd81ccc0
frame pointer = 0x28:0xfe00dd81ccf0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 24022 (kldload)
trap number = 12
panic: page fault
cpuid = 2
time = 1570970502
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00dd81c920
vpanic() at vpanic+0x17e/frame 0xfe00dd81c980
panic() at panic+0x43/frame 0xfe00dd81c9e0
trap_pfault() at trap_pfault/frame 0xfe00dd81ca50
trap_pfault() at trap_pfault+0x4f/frame 0xfe00dd81cac0
trap() at trap+0x288/frame 0xfe00dd81cbf0
calltrap() at calltrap+0x8/frame 0xfe00dd81cbf0
--- trap 0xc, rip = 0x80b1be61, rsp = 0xfe00dd81ccc0,
rbp = 0xfe00dd81ccf0 ---
pfs_destroy() at pfs_destroy+0x11/frame 0xfe00dd81ccf0
pfs_uninit() at pfs_uninit+0x16/frame 0xfe00dd81cd10
vfs_modevent() at vfs_modevent+0x474/frame 0xfe00dd81cd50
module_register_init() at module_register_init+0xa4/frame
0xfe00dd81cd80
linker_load_module() at linker_load_module+0xb49/frame
0xfe00dd81d0a0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d0f0
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d1b0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d4d0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d520
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d5e0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d900
kern_kldload() at kern_kldload+0xbd/frame 0xfe00dd81d950
sys_kldload() at sys_kldload+0x5b/frame 0xfe00dd81d980
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe00dd81dab0
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe00dd81dab0
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002d1cda,
rsp = 0x7fffd748, rbp = 0x7fffdcc0 ---
KDB: enter: panic
__curthread () at /freebsd/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at
/freebsd/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=0) at
/freebsd/src/sys/kern/kern_shutdown.c:392
#2 0x80496a7a in db_dump (dummy=,
dummy2=, dummy3=,
dummy4=)
at /freebsd/src/sys/ddb/db_command.c:575
#3 0x8049683c in db_command (last_cmdp=,
cmd_table=, dopager=1)
at /freebsd/src/sys/ddb/db_command.c:482
#4 0x804965ad in db_command_loop ()
at /freebsd/src/sys/ddb/db_command.c:535
#5 0x80499858 in db_trap (type=,
code=)
at /freebsd/src/sys/ddb/db_main.c:252
#6 0x80c322a7 in kdb_trap (type=3, code=0, tf=)
at /freebsd/src/sys/kern/subr_kdb.c:692
#7 0x8105d925 in trap (frame=0xfe00dd81c850)
at /freebsd/src/sys/amd64/amd64/trap.c:585
#8
#9 kdb_enter (why=0x811dee7e "panic", msg=)
at /freebsd/src/sys/kern/subr_kdb.c:479
#10 0x80be377a in vpanic (fmt=,
ap=)
at /freebsd/src/sys/kern/kern_shutdown.c:897
#11 0x80be35d3 in panic (
fmt=0x818e4c18
"\357\327\037\201\377\377\377\377") at
/freebsd/src/sys/kern/kern_shutdown.c:835
#12 0x8105ddb0 in trap_fatal (frame=0xfe00dd81cc00,
eva=248)
at
Re: DRM-current-kmod is still a problem at r353339
The patch doesn't work for me on i915kms on a HP Spectre x360 13-p0043dx. I get a panic Screenshot: https://user-images.githubusercontent.com/5403564/66688014-d1a16700-ec52-11e9-9c3b-902f49e311de.png As of now, I'm using an older kernel. -Neel === https://www.neelc.org/ On 2019-10-11 10:28, Thomas Laus wrote: On 2019-10-10 13:44, Mateusz Guzik wrote: Probably whitespace issues from copypasting. I used dpaste since people.freebsd.org was down. It's up, so: https://people.freebsd.org/~mjg/pmap-fict3.diff That patch worked for me also. The patch applied clean when I used 'wget' to retrieve vs. saving a file from my web browser. Thanks for the quick fix. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
The patch doesn't work for me on i915kms on a HP Spectre x360 13-p0043dx. I get a panic Screenshot: https://user-images.githubusercontent.com/5403564/66688014-d1a16700-ec52-11e9-9c3b-902f49e311de.png As of now, I'm using an older kernel. -Neel === https://www.neelc.org/ On 2019-10-11 10:28, Thomas Laus wrote: On 2019-10-10 13:44, Mateusz Guzik wrote: Probably whitespace issues from copypasting. I used dpaste since people.freebsd.org was down. It's up, so: https://people.freebsd.org/~mjg/pmap-fict3.diff That patch worked for me also. The patch applied clean when I used 'wget' to retrieve vs. saving a file from my web browser. Thanks for the quick fix. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CALL FOR TESTING][PATCH]: Intel Comet Lake and Ice Lake HD Audio Support
Hi freebsd-current@ mailing list, I have a patch which adds support for the HD Audio Codecs for the Intel Comet Lake and Ice Lake PCHs. This is similar to my now-committed Cannon Lake HD Audio patch. Please find below the Bugzilla and Phabricator links (both have the patch): Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240871 Phabricator: https://reviews.freebsd.org/D21818 What I need is for people with systems with Comet Lake and Ice Lake PCHs to test this patch, and for committers to review and commit this once tested. This patch should work with most non-Apple Comet Lake and Ice Lake systems. This is needed as unlike Cannon Lake where I had hardware (HP Spectre x360 2018), I lack hardware running Comet Lake and Ice Lake. -Neel === https://www.neelc.org/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
TSC-low clock slow on WhiskeyLake i7-8565U (HP Spectre x360 13-ap0043dx)
Hi, I recently got a HP Spectre x360 13-ap0043dx as a gift and by default the clock runs slower on FreeBSD than Windows or Linux. Yes, I know the ThinkPad is the best laptop for FreeBSD, but getting an X1 Carbon would increase the price of the gift even more which couldn't be done. The kern.timecounter.hardware by default is set to TSC-low and the clock is slow on the Spectre x360. Setting it to ACPI-slow resolves this issue. The CPU is a Intel WhiskeyLake Core i7-8565U. Is the slow TSC-low an issue with WhiskeyLake in general or specifically HP? Is it something else? I am considering writing a patch but before I write one, do other people with WhiskeyLake laptops (or newer) have slow clocks (where one second on the system is actually more in real life), or not. -Neel === https://www.neelc.org/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Haswell Kernel Mode Setting
On 2013-11-12 03:29, Konstantin Belousov wrote: On Mon, Nov 11, 2013 at 03:39:06PM -0800, Xin Li wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/11/13 14:29, Neel Chauhan wrote: Sorry if I sent a similar patch before. It didn't get accepted so I am sending one now. Enjoy. What does didn't get accepted mean? :) Since this looks like a PCI-ID only change that do not affect other existing hardware, if it's not an explicit objection from a reviewer, I think it's Okay to just go ahead and commit the change after a reasonable timeout instead of waiting indefinitely. I very much doubt that this patch works. More, I believe that it was not tested at all. Talking about the trivially obvious things, the PGTT handling must be updated since page tables have different format comparing with Ivy, there are some changes to ring dispatching, and lot of changes in the display pipeline. All this is missing from the patch. Oh, and the Series 8 chipset PCH detection is missing. I probably should stop now. HSW support is much more than just adding the Ids, I am (slowly) starting the work on importing the Linux updates. Konstantin, Thanks for telling me. The reality is, I don't really know about the insides of the FreeBSD kernel, Linux, or drm. I just looked at a few files. I should really get a book about FreeBSD before trying to send patches again. And anyways, this patch is untested. I was in a rush to send it to the mailing list, hoping it would get accepted. Thanks, Neel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] Haswell Kernel Mode Setting
Hello FreeBSD-CURRENT and FreeBSD-X11 mailing list(s),
I have a patch to add support for kernel mode setting on Intel
Haswell/4th generation Core i(3/5/7) chips. The patch is:
diff -u -r -N head/sys/dev/agp/agp_i810.c tree/sys/dev/agp/agp_i810.c
--- head/sys/dev/agp/agp_i810.c 2013-11-11 16:18:23.0 -0500
+++ tree/sys/dev/agp/agp_i810.c 2013-11-11 17:09:33.0 -0500
@@ -734,6 +734,41 @@
.name = IvyBridge server GT2 IG,
.driver = agp_i810_sb_driver
},
+{
+.devid = 0x04028086,
+.name = Haswell desktop GT1 IG,
+.driver = agp_i810_sb_driver
+},
+{
+.devid = 0x04128086,
+.name = Haswell desktop GT2 IG,
+.driver = agp_i810_sb_driver
+},
+{
+.devid = 0x04068086,
+.name = Haswell mobile GT1 IG,
+.driver = agp_i810_sb_driver
+},
+{
+.devid = 0x04168086,
+.name = Haswell mobile GT2 IG,
+.driver = agp_i810_sb_driver
+},
+{
+.devid = 0x040a8086,
+.name = Haswell server GT1 IG,
+.driver = agp_i810_sb_driver
+},
+{
+.devid = 0x041a8086,
+.name = Haswell server GT2 IG,
+.driver = agp_i810_sb_driver
+},
+{
+.devid = 0x0c168086,
+.name = Haswell SDV,
+.driver = agp_i810_sb_driver
+},
{
.devid = 0,
}
diff -u -r -N head/sys/dev/drm2/drm_pciids.h
tree/sys/dev/drm2/drm_pciids.h
--- head/sys/dev/drm2/drm_pciids.h 2013-11-11 16:17:33.0 -0500
+++ tree/sys/dev/drm2/drm_pciids.h 2013-11-11 17:09:37.0 -0500
@@ -48,6 +48,42 @@
{0x8086, 0x0162, CHIP_I9XX|CHIP_I915, Intel IvyBridge}, \
{0x8086, 0x0166, CHIP_I9XX|CHIP_I915, Intel IvyBridge (M)}, \
{0x8086, 0x016A, CHIP_I9XX|CHIP_I915, Intel IvyBridge (S)}, \
+ {0x8086, 0x0402, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0412, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0422, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0406, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0416, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0426, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x040A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x041A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x042A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0C02, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0C12, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0C22, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0C06, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0C16, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0C26, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0C0A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0C1A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0C2A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0A02, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0A12, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0A22, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0A06, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0A16, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0A26, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0A0A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0A1A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0A2A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0D12, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0D22, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0D32, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0D16, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0D26, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0D36, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0D1A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0D2A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0D3A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
{0x8086, 0x2562, CHIP_I8XX, Intel i845G GMCH}, \
{0x8086, 0x2572, CHIP_I8XX, Intel i865G GMCH}, \
{0x8086, 0x2582, CHIP_I9XX|CHIP_I915, Intel i915G}, \
diff -u -r -N head/sys/dev/drm2/i915/i915_drv.c
tree/sys/dev/drm2/i915/i915_drv.c
--- head/sys/dev/drm2/i915/i915_drv.c 2013-11-11 16:17:24.0
-0500
+++ tree/sys/dev/drm2/i915/i915_drv.c 2013-11-11 17:10:05.0
-0500
@@ -173,6 +173,22 @@
.has_llc = 1,
};
+static const struct intel_device_info
[patch] Add support for kernel mode setting on Intel Haswell
Dear freebsd-current mailing list,
I created a patch to support kernel mode setting on Intel Haswell. The
patch starts below:
diff -u -r -N freebsd.old/sys/dev/drm2/drm_pciids.h
freebsd/sys/dev/drm2/drm_pciids.h
--- freebsd.old/sys/dev/drm2/drm_pciids.h 2013-09-20 14:58:24.0
-0400 +++ freebsd/sys/dev/drm2/drm_pciids.h 2013-09-20 16:58:47.0
-0400 @@ -48,6 +48,42 @@
{0x8086, 0x0162, CHIP_I9XX|CHIP_I915, Intel IvyBridge}, \
{0x8086, 0x0166, CHIP_I9XX|CHIP_I915, Intel IvyBridge (M)}, \
{0x8086, 0x016A, CHIP_I9XX|CHIP_I915, Intel IvyBridge (S)}, \
+ {0x8086, 0x0402, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0412, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0422, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0406, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0416, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0426, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x040A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x041A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x042A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0C02, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0C12, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0C22, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0C06, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0C16, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0C26, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0C0A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0C1A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0C2A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0A02, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0A12, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0A22, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0A06, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0A16, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0A26, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0A0A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0A1A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0A2A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0D12, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0D22, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0D32, CHIP_I9XX|CHIP_I915, Intel Haswell}, \
+ {0x8086, 0x0D16, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0D26, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0D36, CHIP_I9XX|CHIP_I915, Intel Haswell (M)}, \
+ {0x8086, 0x0D1A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0D2A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
+ {0x8086, 0x0D3A, CHIP_I9XX|CHIP_I915, Intel Haswell (S)}, \
{0x8086, 0x2562, CHIP_I8XX, Intel i845G GMCH}, \
{0x8086, 0x2572, CHIP_I8XX, Intel i865G GMCH}, \
{0x8086, 0x2582, CHIP_I9XX|CHIP_I915, Intel i915G}, \
diff -u -r -N freebsd.old/sys/dev/drm2/i915/i915_drv.c
freebsd/sys/dev/drm2/i915/i915_drv.c
--- freebsd.old/sys/dev/drm2/i915/i915_drv.c2013-09-20 14:58:24.0
-0400
+++ freebsd/sys/dev/drm2/i915/i915_drv.c2013-09-20 16:50:57.0
-0400 @@ -173,6 +173,22 @@
.has_llc = 1,
};
+static const struct intel_device_info intel_haswell_d_info = {
+ .is_haswell = 1, .gen = 8,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .has_bsd_ring = 1,
+ .has_blt_ring = 1,
+ .has_llc = 1,
+};
+
+static const struct intel_device_info intel_haswell_m_info = {
+ .is_haswell = 1, .gen = 8, .is_mobile = 1,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .has_bsd_ring = 1,
+ .has_blt_ring = 1,
+ .has_llc = 1,
+};
+
#define INTEL_VGA_DEVICE(id, info_) { \
.device = id, \
.info = info_, \
@@ -226,6 +242,42 @@
INTEL_VGA_DEVICE(0x0162, intel_ivybridge_d_info), /* GT2 desktop */
INTEL_VGA_DEVICE(0x015a, intel_ivybridge_d_info), /* GT1 server */
INTEL_VGA_DEVICE(0x016a, intel_ivybridge_d_info), /* GT2 server */
+ INTEL_VGA_DEVICE(0x0402, intel_haswell_d_info), /* GT1 desktop */
+ INTEL_VGA_DEVICE(0x0412, intel_haswell_d_info), /* GT2 desktop */
+ INTEL_VGA_DEVICE(0x0422, intel_haswell_d_info), /* GT2 desktop */
+ INTEL_VGA_DEVICE(0x040a, intel_haswell_d_info), /* GT1 server */
+ INTEL_VGA_DEVICE(0x041a, intel_haswell_d_info), /* GT2 server */
+ INTEL_VGA_DEVICE(0x042a, intel_haswell_d_info), /* GT2 server */
+ INTEL_VGA_DEVICE(0x0406, intel_haswell_m_info), /* GT1 mobile */
+ INTEL_VGA_DEVICE(0x0416, intel_haswell_m_info), /* GT2 mobile */
+ INTEL_VGA_DEVICE(0x0426, intel_haswell_m_info), /* GT2 mobile */
+
