Re: Driver tpm(4) and third party packages for trusted platform modules
In message <20100802120236.gb29...@modermoor.genua.de>, Hans-Joerg Hoexer wrote:
>Hi,
>
>we have developed a driver tpm(4) for various TPMs for OpenBSD 4.7 and
>FreeBSD 8.0 and have ported and updated several third party packages to
>enable use of TPMs on Open- and FreeBSD. This enables applications like
>OpenSSH to generate and store private keys inside a TPM.
>
>The supported TPMs are:
>
>- Atmel 97SC3203
>- Broadcom BCM0102
>- Infineon SLB 9635 TT 1.2
>- Intel INTC0102
>- Sinosun SNS SSX35
>- STM ST19WP18
>- Winbond WEC WPCT200
>
>The supported third party packages are:
>
>- openCryptoki 2.3.1: An PKCS#11 implementation, including support
> for TPMs. OpenSSH can use this library to generate and store private
> RSA keys inside a TPM.
>- openssl_tpm_engine 0.4.1: An openssl engine supporting TPMs.
>- tpm-emulator 0.7.0: An emulator providing the functionality of a TPM.
> Used for development purposes.
>- tpm-tools 1.3.5: Various tools for managing a TPM, including key
> generation.
>- trousers 0.3.5: An implementation of the Trusted Software Stack.
> This is the backend libary for the afore mentioned packages.
>- trousers testsuite 0.2: A testsuite for trousers.
>- TrustedGRUB 1.1.4: An TPM enabled version of grub, including support
> for natively booting OpenBSD.
>
>A patch including the driver tpm(4) is attached, more information,
>full source code and patches for third party packages can be found at
>http://bsssd.sourceforge.net.
Nice!
Quick review and hack:
1.How about attaching it as acpi child driver?
In some case, TPM may appear in ACPI namespace (with _HID) and
TPM spec defines ACPI method to handle TPM specific request.
2. Is identify method needed?
Writing device hint will attach isa child driver, I think.
3.Module build
I don't know it is proper in TPM nature.
===
diff -ruN src/sys/dev/tpm/tpm.c src.new/sys/dev/tpm/tpm.c
--- src/sys/dev/tpm/tpm.c 2010-08-04 12:39:05.0 +0900
+++ src.new/sys/dev/tpm/tpm.c 2010-08-04 12:27:41.0 +0900
@@ -264,15 +264,22 @@
int tpm_legacy_end(struct tpm_softc *, int, int);
#ifdef __FreeBSD__
+static struct isa_pnp_id tpm_ids[] = {
+ {0x32021114, "Trusted Platform Module"},
+
+ {0}
+};
+
/*
* FreeBSD specific code for probing and attaching TPM to device tree.
*/
+#if 0
static void
tpm_identify(driver_t *driver, device_t parent)
{
BUS_ADD_CHILD(parent, ISA_ORDER_SPECULATIVE, "tpm", 0);
}
-
+#endif
static int
tpm_probe(device_t dev)
{
@@ -281,8 +288,14 @@
bus_space_handle_t ioh;
struct resource *mem_res;
int rv, mem_rid;
+ int ret;
bzero(sc, sizeof(struct tpm_softc));
+
+ if((ret = ISA_PNP_PROBE(device_get_parent(dev), dev, tpm_ids))
+ <= 0){
+ return ret;
+ }
mem_rid = 0;
mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &mem_rid,
@@ -362,7 +375,9 @@
}
static device_method_t tpm_methods[] = {
+#if 0
DEVMETHOD(device_identify, tpm_identify),
+#endif
DEVMETHOD(device_probe, tpm_probe),
DEVMETHOD(device_attach,tpm_attach),
DEVMETHOD(device_suspend, tpm_suspend),
@@ -377,6 +392,7 @@
static devclass_t tpm_devclass;
DRIVER_MODULE(tpm, isa, tpm_driver, tpm_devclass, 0, 0);
+DRIVER_MODULE(tpm, acpi, tpm_driver, tpm_devclass, 0, 0);
#else
/*
* OpenBSD specific code for probing and attaching TPM to device tree.
diff -ruN src/sys/modules/tpm/Makefile src.new/sys/modules/tpm/Makefile
--- src/sys/modules/tpm/Makefile1970-01-01 09:00:00.0 +0900
+++ src.new/sys/modules/tpm/Makefile2010-08-04 12:43:59.0 +0900
@@ -0,0 +1,8 @@
+# $FreeBSD$
+
+.PATH: ${.CURDIR}/../../dev/tpm
+
+KMOD= tpm
+SRCS= tpm.c isa_if.h opt_acpi.h acpi_if.h bus_if.h device_if.h
+
+.include
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sched_pin() versus PCPU_GET
On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin wrote:
> On Friday, July 30, 2010 10:08:22 am John Baldwin wrote:
>> On Thursday, July 29, 2010 7:39:02 pm m...@freebsd.org wrote:
>> > We've seen a few instances at work where witness_warn() in ast()
>> > indicates the sched lock is still held, but the place it claims it was
>> > held by is in fact sometimes not possible to keep the lock, like:
>> >
>> > thread_lock(td);
>> > td->td_flags &= ~TDF_SELECT;
>> > thread_unlock(td);
>> >
>> > What I was wondering is, even though the assembly I see in objdump -S
>> > for witness_warn has the increment of td_pinned before the PCPU_GET:
>> >
>> > 802db210: 65 48 8b 1c 25 00 00 mov %gs:0x0,%rbx
>> > 802db217: 00 00
>> > 802db219: ff 83 04 01 00 00 incl 0x104(%rbx)
>> > * Pin the thread in order to avoid problems with thread migration.
>> > * Once that all verifies are passed about spinlocks ownership,
>> > * the thread is in a safe path and it can be unpinned.
>> > */
>> > sched_pin();
>> > lock_list = PCPU_GET(spinlocks);
>> > 802db21f: 65 48 8b 04 25 48 00 mov %gs:0x48,%rax
>> > 802db226: 00 00
>> > if (lock_list != NULL && lock_list->ll_count != 0) {
>> > 802db228: 48 85 c0 test %rax,%rax
>> > * Pin the thread in order to avoid problems with thread migration.
>> > * Once that all verifies are passed about spinlocks ownership,
>> > * the thread is in a safe path and it can be unpinned.
>> > */
>> > sched_pin();
>> > lock_list = PCPU_GET(spinlocks);
>> > 802db22b: 48 89 85 f0 fe ff ff mov %rax,-0x110(%rbp)
>> > 802db232: 48 89 85 f8 fe ff ff mov %rax,-0x108(%rbp)
>> > if (lock_list != NULL && lock_list->ll_count != 0) {
>> > 802db239: 0f 84 ff 00 00 00 je 802db33e
>> >
>> > 802db23f: 44 8b 60 50 mov 0x50(%rax),%r12d
>> >
>> > is it possible for the hardware to do any re-ordering here?
>> >
>> > The reason I'm suspicious is not just that the code doesn't have a
>> > lock leak at the indicated point, but in one instance I can see in the
>> > dump that the lock_list local from witness_warn is from the pcpu
>> > structure for CPU 0 (and I was warned about sched lock 0), but the
>> > thread id in panic_cpu is 2. So clearly the thread was being migrated
>> > right around panic time.
>> >
>> > This is the amd64 kernel on stable/7. I'm not sure exactly what kind
>> > of hardware; it's a 4-way Intel chip from about 3 or 4 years ago IIRC.
>> >
>> > So... do we need some kind of barrier in the code for sched_pin() for
>> > it to really do what it claims? Could the hardware have re-ordered
>> > the "mov %gs:0x48,%rax" PCPU_GET to before the sched_pin()
>> > increment?
>>
>> Hmmm, I think it might be able to because they refer to different locations.
>>
>> Note this rule in section 8.2.2 of Volume 3A:
>>
>> • Reads may be reordered with older writes to different locations but not
>> with older writes to the same location.
>>
>> It is certainly true that sparc64 could reorder with RMO. I believe ia64
>> could reorder as well. Since sched_pin/unpin are frequently used to provide
>> this sort of synchronization, we could use memory barriers in pin/unpin
>> like so:
>>
>> sched_pin()
>> {
>> td->td_pinned = atomic_load_acq_int(&td->td_pinned) + 1;
>> }
>>
>> sched_unpin()
>> {
>> atomic_store_rel_int(&td->td_pinned, td->td_pinned - 1);
>> }
>>
>> We could also just use atomic_add_acq_int() and atomic_sub_rel_int(), but
>> they
>> are slightly more heavyweight, though it would be more clear what is
>> happening
>> I think.
>
> However, to actually get a race you'd have to have an interrupt fire and
> migrate you so that the speculative read was from the other CPU. However, I
> don't think the speculative read would be preserved in that case. The CPU
> has to return to a specific PC when it returns from the interrupt and it has
> no way of storing the state for what speculative reordering it might be
> doing, so presumably it is thrown away? I suppose it is possible that it
> actually retires both instructions (but reordered) and then returns to the PC
> value after the read of listlocks after the interrupt. However, in that case
> the scheduler would not migrate as it would see td_pinned != 0. To get the
> race you have to have the interrupt take effect prior to modifying td_pinned,
> so I think the processor would have to discard the reordered read of
> listlocks so it could safely resume execution at the 'incl' instruction.
>
> The other nit there on x86 at least is that the incl instruction is doing
> both a read and a write and another rule in the section 8.2.2 is this:
>
> • Reads are not reordered with other reads.
>
> That would seem to prevent the read of listlocks from passing the read of
> td_pinned in the incl instruction on x86.
I won
Driver tpm(4) and third party packages for trusted platform modules
Hi, we have developed a driver tpm(4) for various TPMs for OpenBSD 4.7 and FreeBSD 8.0 and have ported and updated several third party packages to enable use of TPMs on Open- and FreeBSD. This enables applications like OpenSSH to generate and store private keys inside a TPM. The supported TPMs are: - Atmel 97SC3203 - Broadcom BCM0102 - Infineon SLB 9635 TT 1.2 - Intel INTC0102 - Sinosun SNS SSX35 - STM ST19WP18 - Winbond WEC WPCT200 The supported third party packages are: - openCryptoki 2.3.1: An PKCS#11 implementation, including support for TPMs. OpenSSH can use this library to generate and store private RSA keys inside a TPM. - openssl_tpm_engine 0.4.1: An openssl engine supporting TPMs. - tpm-emulator 0.7.0: An emulator providing the functionality of a TPM. Used for development purposes. - tpm-tools 1.3.5: Various tools for managing a TPM, including key generation. - trousers 0.3.5: An implementation of the Trusted Software Stack. This is the backend libary for the afore mentioned packages. - trousers testsuite 0.2: A testsuite for trousers. - TrustedGRUB 1.1.4: An TPM enabled version of grub, including support for natively booting OpenBSD. A patch including the driver tpm(4) is attached, more information, full source code and patches for third party packages can be found at http://bsssd.sourceforge.net. Regards, HJ. Patch for FreeBSD 8.0 Release It provides - tpm(4) driver - modified acpidump(8) for dumping the TCPA table Applying and building the patch: # cd /usr/src # patch -p1 < /tmp/freebsd-beta.diff # cd /usr/src/usr.sbin/acpi/acpidump/ # make obj && make depend && make && make install # cd /usr/src/sys/i386/conf/ # config GENERIC # cd ../compile/GENERIC # make cleandepend ; make depend && make && make install # cat >> /boot/device.hints hint.tpm.0.at="isa" hint.tpm.0.irq="7" hint.tpm.0.maddr="0xfed4" hint.tpm.0.msize="0x5000" hint.tpm.1.at="isa" hint.tpm.1.irq="7" hint.tpm.1.maddr="0xfed4" hint.tpm.1.msize="0x1000" ^D # reboot Note: The IRQ to be used with tpm(4) was chosen arbitrarily to be 7. If you machine has no free ISA IRQ, you can use the driver without IRQ by just not providing a hint (ie. delete the hint.tpm.?.irq from /boot/device.hints) diff -Nupr src.orig/share/man/man4/tpm.4 src/share/man/man4/tpm.4 --- src.orig/share/man/man4/tpm.4 1970-01-01 01:00:00.0 +0100 +++ src/share/man/man4/tpm.42010-03-10 18:30:36.0 +0100 @@ -0,0 +1,74 @@ +.\" +.\" Copyright (c) 2010 Hans-J +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.\" $FreeBSD:$ +.\" +.Dd March 8, 2010 +.Dt TPM 4 +.Os +.Sh NAME +.Nm tpm +.Nd Trusted Platform Module +.Sh SYNOPSIS +.Cd "device tpm" +.Pp +In +.Pa /boot/device.hints : +.Cd hint.tpm.0.at="isa" +.Cd hint.tpm.0.maddr="0xfed4" +.Cd hint.tpm.0.msize="0x5000" +.Cd hint.tpm.1.at="isa" +.Cd hint.tpm.1.maddr="0xfed4" +.Cd hint.tpm.1.msize="0x1000" +.Sh DESCRIPTION +The +.Nm +driver provides support for various trusted platfrom modules (TPM) that can +store cryptographic keys. +.Pp +Supported modules: +.Pp +.Bl -bullet -compact -offset indent +.It +Atmel 97SC3203 +.It +Broadcom BCM0102 +.It +Infineon IFX SLD 9630 TT 1.1 and IFX SLB 9635 TT 1.2 +.It +Intel INTC0102 +.It +Sinosun SNS SSX35 +.It +STM ST19WP18 +.It +Winbond WEC WPCT200 +.El +.Pp +The driver can be configured to use an IRQ by providing a free ISA +interrupt vector in +.Pa /boot/device.hints . +.Sh SEE ALSO +.Xr intro 4 , +.Xr files.conf 5, +.Xr config 8 +.Sh AUTHORS +.An -nosplit +The +.Nm +driver was written by +.An Michael Shalayeff +and +.An Hans-Joerg Hoexer . diff -Nupr src.orig/sys/conf/files.i386 src/sys/conf/files.i386 --- src.orig/sys/conf/files.i3862010-03-10 17:50:07.0 +0100 +++ src/sys/conf/files.i386 2010-03-10 18:32:08.0 +0100 @@ -221,6 +221,7 @@ dev/syscons/scvesactl.c optional sc vga dev/syscons/scvgarndr.coptional sc vga dev/syscons/scvtb.coptional sc dev/syscons/teken/teken.c optional sc +dev/tpm/tpm.c optional tpm isa dev/uart/uart_cpu_i386.c optional uart dev/acpic
Re: PCI config space is not restored upon resume (macbook pro)
On 3 August 2010 17:44, John Baldwin wrote: > I wonder if the bus numbers for PCI-PCI bridges need to be restored on resume? > If they aren't then config transactions won't be routed properly. You could > add a pcib_resume() method that prints out the various bus register values > after resume to see if they match what we print out during boot. I'll do that tomorrow and report the results. As I can see PCI-PCI bridge (non ACPI) restores bus numbers, while ACPI version - don't. -- Oleg Sharoyko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Add -lssp_nonshared to GCC's LIB_SPEC unconditionally
On Tue, 3 Aug 2010 17:05:46 +0200
Jeremie Le Hen wrote:
> Hi,
>
> Currenty, -lssp_nonshared is appended at the link stage only when
> -fstack-protector is used on the gcc command-line. The problem I
> would like to fix is a library (static or shared) compiled with
> -fstack-protector being linked in without using the same flag:
>
> mygeeto# cc -I /usr/local/include -L /usr/local/lib -lintl
> conftest.c /usr/local/lib/libintl.so: undefined reference to
> `__stack_chk_fail_local'
>
> Since world is now compiled by default with -fstack-protector, this
> may happen to everyone naively compiling a source file like above.
>
> I therefore propose the following change to always link in
> libssp_nonshared.a. I think this change is harmless when the symbol
> is not needed in one of the objects linked together since the linker
> won't pull in the library member "ssp-local.o" in the target object.
>
> Index: freebsd-spec.h
> ===
> RCS
> file: /data/repos/freebsd-cvsroot/src/contrib/gcc/config/freebsd-spec.h,v
> retrieving revision 1.26.2.2 diff -u -r1.26.2.2 freebsd-spec.h
> --- freebsd-spec.h 27 Dec 2009 20:39:58 - 1.26.2.2
> +++ freebsd-spec.h 3 Aug 2010 10:18:08 -
> @@ -168,7 +168,7 @@
> %{pg: %{pthread:-lpthread_p}
> -lc_p}} \
> %{shared:
> \ %{pthread:-lpthread} -lc} \
> -
> %{fstack-protector|fstack-protector-all:-lssp_nonshared} \
> +
> -lssp_nonshared
> \ " #endif
> #endif
>
>
> This change is also important because I've submitted a PR (138228) to
> compile ports with SSP. Of course many of them (although relatively
> few) break. If we eventually want this feature to reach the ports
> tree, it is necessary to fix as much problems as possible. I've
> already provided a few patches in the PR, but sometimes it is
> exaggeratedly difficult to fix the problem. For instance,
> devel/p5-Locale-gettext tests the existence of libintl.so with a
> naively compiled source file which doesn't link because of this
> error. The easiest way after the one proposed above would be to
> apply a patch conditionnaly.
>
> Thank you.
> Regards,
> --
> Jeremie Le Hen
>
> Coluche
I have no objection, but think we should cave in and investigate the
possibility of using linker script wrapping libc.so in FreeBSD-9.0:
Below is Linux' counterpart:
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED
( /lib/ld-linux.so.2 ) )
--
Alexander Kabaev
signature.asc
Description: PGP signature
Add -lssp_nonshared to GCC's LIB_SPEC unconditionally
Hi,
Currenty, -lssp_nonshared is appended at the link stage only when
-fstack-protector is used on the gcc command-line. The problem I would
like to fix is a library (static or shared) compiled with
-fstack-protector being linked in without using the same flag:
mygeeto# cc -I /usr/local/include -L /usr/local/lib -lintl conftest.c
/usr/local/lib/libintl.so: undefined reference to `__stack_chk_fail_local'
Since world is now compiled by default with -fstack-protector, this may
happen to everyone naively compiling a source file like above.
I therefore propose the following change to always link in
libssp_nonshared.a. I think this change is harmless when the symbol is
not needed in one of the objects linked together since the linker won't
pull in the library member "ssp-local.o" in the target object.
Index: freebsd-spec.h
===
RCS file: /data/repos/freebsd-cvsroot/src/contrib/gcc/config/freebsd-spec.h,v
retrieving revision 1.26.2.2
diff -u -r1.26.2.2 freebsd-spec.h
--- freebsd-spec.h 27 Dec 2009 20:39:58 - 1.26.2.2
+++ freebsd-spec.h 3 Aug 2010 10:18:08 -
@@ -168,7 +168,7 @@
%{pg: %{pthread:-lpthread_p} -lc_p}} \
%{shared:\
%{pthread:-lpthread} -lc} \
- %{fstack-protector|fstack-protector-all:-lssp_nonshared} \
+ -lssp_nonshared \
"
#endif
#endif
This change is also important because I've submitted a PR (138228) to
compile ports with SSP. Of course many of them (although relatively
few) break. If we eventually want this feature to reach the ports tree,
it is necessary to fix as much problems as possible. I've already
provided a few patches in the PR, but sometimes it is exaggeratedly
difficult to fix the problem. For instance, devel/p5-Locale-gettext
tests the existence of libintl.so with a naively compiled source file
which doesn't link because of this error. The easiest way after the one
proposed above would be to apply a patch conditionnaly.
Thank you.
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than others.
Coluche
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PCI config space is not restored upon resume (macbook pro)
On Tuesday, August 03, 2010 6:49:07 am Oleg Sharoyko wrote: > Hi! > > I'm trying to make FreeBSD (9-Current, checkout on 2010-08-01) correctly > suspend/resume on macbook pro. As of now I have to issues with resume: > > 1. Display stays blank upon resume. Got 'vga0: failed to reload state' > in dmesg, but I haven't looked into this yet. > > 2. Some hardware is missing upon resume, specifically ath, msk and firewire. > This devices disappear because rather strange values are being > read from pci config space (such as vendor id, device id and others). I wonder if the bus numbers for PCI-PCI bridges need to be restored on resume? If they aren't then config transactions won't be routed properly. You could add a pcib_resume() method that prints out the various bus register values after resume to see if they match what we print out during boot. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Puzzling performance
On Monday, August 02, 2010 6:13:50 pm Guy Helmer wrote: > On a FreeBSD 7.1 SCHED_ULE kernel, I have a large number of files opened and > mmapped (with MAP_NOSYNC option) for shared-memory communication between > processes. Normally, memcpy() copies data into these shared-memory buffers > in a reasonable amount of time closely related to the size of the copy > (roughly 10us per 10KB). However, due to performance issues I've found that > sometimes a memcpy() takes an abnormally long time (10ms for 40KB, and I > suspect longer times occurring when I have not had monitoring enabled). The > system doesn't seem to be in memory overcommit -- there is just a minor > amount of swap in use, and I've not seen page-ins or page-outs while > watching systat or vmstat. > > Since I'm using MAP_NOSYNC, I would not expect the pager to flush dirty > pages to disk and cause add delays. Any ideas where to look? Might it help > to pin threads to CPUs in case a thread is getting moved to a different > core? Pinning might help yes. You might also want to ensure there aren't any interrupts on that CPU. Currently there isn't a good way to figure that out short of kgdb though. :( -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
PCI config space is not restored upon resume (macbook pro)
Hi! I'm trying to make FreeBSD (9-Current, checkout on 2010-08-01) correctly suspend/resume on macbook pro. As of now I have to issues with resume: 1. Display stays blank upon resume. Got 'vga0: failed to reload state' in dmesg, but I haven't looked into this yet. 2. Some hardware is missing upon resume, specifically ath, msk and firewire. This devices disappear because rather strange values are being read from pci config space (such as vendor id, device id and others). This is how it looks when system boots: pci11: on pcib4 pci11: domain=0, physical bus=11 pcib4: pci_read_device: before if pcib4: pci_read_device: in if() pcib4: pci_read_device subvendor: 106b, vendor: 168c, device: 0024 pcib4: pci_read_device: after if() unknown: pci_cfg_save: subvendor: 106b, vendor: 168c, device: 0024 unknown: pci_cfg_restore: subvendor: 106b, vendor: 168c, device: 0024 found-> vendor=0x168c, dev=0x0024, revid=0x01 domain=0, bus=11, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D3 current D0 MSI supports 1 message MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0x9730, size 16, enabled pcib4: requested memory range 0x9730-0x9730: good pcib4: matched entry for 11.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 ath0: mem 0x9730-0x9730 irq 16 at device 0.0 on pci11 everything as usual except for some debugging printfs I have added to the kernel. And here what I have upon resume: pci_resume: before restore pci0:11:0:0: Transition from D3 to D0 unknown: pci_cfg_restore: subvendor: 106b, vendor: 168c, device: 0024 pci_resume: before if pci_resume: in if unknown: pci_cfg_save: subvendor: , vendor: , device: pci_resume: after if [some lines are skipped, please see [1] for a link to complete output of dmesg] pci11: driver added found-> vendor=0x, dev=0x, revid=0xff domain=0, bus=11, slot=0, func=0 class=ff-ff-ff, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0010, cachelnsz=255 (dwords) lattimer=0xff (7650 ns), mingnt=0xff (63750 ns), maxlat=0xff (63750 ns) intpin=_, irq=255 powerspec 2 supports D0 D1 D3 current D3 MSI supports 1 message MSI-X supports 1 message in map 0x10 pci0:11:0:0: reprobing on driver added pci0:11:0:0: Transition from D3 to D0 unknown: pci_cfg_restore: subvendor: , vendor: , device: unknown: pci_cfg_save: subvendor: , vendor: , device: As far as I can see pci_resume() (from dev/pci/pci.c) tries to write saved values of pci config space and calls pci_cfg_restore() to achieve this. pci_cfg_restore() inded writes correct values to pci config space. But the next attempt to read these just written value returns incorrect data. What else can I do to understand and solve this issue? I would appreciate any help. Thank you! 1. Complete output of dmesg http://www.oleg-sharoyko.net/files/freebsd/pci_config.201008/dmesg.20100803.txt -- Oleg Sharoyko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
