Re: Not getting interrupts from PCI express slot
Hi, On Wed, Aug 4, 2010 at 12:29 PM, Hans Petter Selasky wrote: > On Wednesday 04 August 2010 21:13:55 Neel Natu wrote: >> Hi, >> >> On Wed, Aug 4, 2010 at 10:18 AM, Hans Petter Selasky > wrote: >> > Hi, >> > >> > I'm not getting any interrupts from a PCI express slot. When I insert a >> > device, no attach event is generated. If the device is present during >> > boot the device is fully detected, but still no IRQ's. Is there anything >> > I can do or test? >> >> Is the driver using legacy INT-A style interrupt or MSI/MSI-X? >> > > I don't know. How can I find out. It is a PCI driver like EHCI. > I looked at the ehci_pci.c driver and it looks like it only requests legacy interrupt. It may be that the legacy interrupt routing is screwed up by the BIOS. You can try a few things to narrow this down a bit: % devinfo -ru: this will tell you which irq is being assigned to the ehci device % vmstat -i: this will tell you the number of interrupts received on that irq. It would be especially telling if you saw any stray interrupts as it may indicate bad interrupt routing. Hope this helps. best Neel > --HPS > ___ 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: Not getting interrupts from PCI express slot
On Wednesday, August 04, 2010 1:18:53 pm Hans Petter Selasky wrote: > Hi, > > I'm not getting any interrupts from a PCI express slot. When I insert a > device, no attach event is generated. If the device is present during boot the > device is fully detected, but still no IRQ's. Is there anything I can do or > test? > > I'm running 8-stable on amd64. In general FreeBSD doesn't support hotplug PCI currently. Likely you'd need some sort of hotplug bridge driver similar to cbb(4) for Cardbus slots that would catch whatever interrupt is generated when a card is inserted and add the device, etc. -- 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: Not getting interrupts from PCI express slot
On Wednesday 04 August 2010 21:13:55 Neel Natu wrote: > Hi, > > On Wed, Aug 4, 2010 at 10:18 AM, Hans Petter Selasky wrote: > > Hi, > > > > I'm not getting any interrupts from a PCI express slot. When I insert a > > device, no attach event is generated. If the device is present during > > boot the device is fully detected, but still no IRQ's. Is there anything > > I can do or test? > > Is the driver using legacy INT-A style interrupt or MSI/MSI-X? > I don't know. How can I find out. It is a PCI driver like EHCI. --HPS ___ 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: Not getting interrupts from PCI express slot
Hi, On Wed, Aug 4, 2010 at 10:18 AM, Hans Petter Selasky wrote: > Hi, > > I'm not getting any interrupts from a PCI express slot. When I insert a > device, no attach event is generated. If the device is present during boot the > device is fully detected, but still no IRQ's. Is there anything I can do or > test? > Is the driver using legacy INT-A style interrupt or MSI/MSI-X? best Neel > I'm running 8-stable on amd64. > > --HPS > ___ > 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" > ___ 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 Wednesday, August 04, 2010 12:20:31 pm m...@freebsd.org wrote:
> On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote:
> > On Tuesday, August 03, 2010 9:46:16 pm m...@freebsd.org wrote:
> >> 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 00mov%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 00mov%gs:0x48,%rax
> >> >> > 802db226: 00 00
> >> >> > if (lock_list != NULL && lock_list->ll_count != 0) {
> >> >> > 802db228: 48 85 c0test %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 ffmov%rax,-0x110(%rbp)
> >> >> > 802db232: 48 89 85 f8 fe ff ffmov%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 mov0x50(%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
Not getting interrupts from PCI express slot
Hi, I'm not getting any interrupts from a PCI express slot. When I insert a device, no attach event is generated. If the device is present during boot the device is fully detected, but still no IRQ's. Is there anything I can do or test? I'm running 8-stable on amd64. --HPS ___ 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 Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote:
> On Tuesday, August 03, 2010 9:46:16 pm m...@freebsd.org wrote:
>> 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
Re: behaviour changes in mdconfig? or something related?
Indeed, it works using ${dev} instead of ${dev}c
Thanks!
Samuel Martín Moro
{EPITECH.} tek4
CamTrace S.A.S
(+033) 1 41 38 37 60
1 Allée de la Venelle
92150 Suresnes
FRANCE
"Nobody wants to say how this works.
Maybe nobody knows ..."
Xorg.conf(5)
On Wed, Aug 4, 2010 at 3:31 PM, Garrett Cooper wrote:
> On Wed, Aug 4, 2010 at 5:40 AM, Samuel Martín Moro
> wrote:
> > Hi,
>
> ...
>
> > So, is it possible to / how could I make ${dev}c appear on 8.1, like it
> was
> > in previous releases?
>
> It's a geom(4) change. Try ${dev} instead of ${dev}c (this should work
> on all releases, but I could be wrong).
> HTH,
> -Garrett
>
___
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 Wednesday, August 04, 2010 3:13:04 am Oleg Sharoyko wrote:
> On 3 August 2010 20:25, Oleg Sharoyko 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.
>
> Indeed this was the problem of PCI-PIC bridges' registers not being
> restored upon resume.
> Thanks for your advise! I'm including the patch, which uses exiting
> methods from dev/pic/pic_pci.c
> to save/restore bridges' registers on suspend/resume. With it my
> macbook pro no longer
> looses devices after resume.
Cool, I actually think that the ACPI PCI-PCI driver can just use the
stock PCI-PCI bridge driver's suspend and resume methods. Can you try
out this alternate patch instead?
> Unfortunately it doesn't help with videocard problem. Though I no
> longer see 'failed to reload state'
> message, display still stays blank and dark after resume. Would
> freebsd-acpi be the right list
> to ask for help or can you recommend anything else I can do to solve
> this problem?
This sounds like the display just needs to be powered on via DPMS.
You might be able to make this work via acpi_video and toggling the
LCD status that way. You could also try dpms.ko.
Index: dev/acpica/acpi_pcib.c
===
--- dev/acpica/acpi_pcib.c (revision 210796)
+++ dev/acpica/acpi_pcib.c (working copy)
@@ -171,13 +171,6 @@
return_VALUE (bus_generic_attach(dev));
}
-int
-acpi_pcib_resume(device_t dev)
-{
-
-return (bus_generic_resume(dev));
-}
-
static void
prt_lookup_device(ACPI_PCI_ROUTING_TABLE *entry, void *arg)
{
Index: dev/acpica/acpi_pcib_pci.c
===
--- dev/acpica/acpi_pcib_pci.c (revision 210796)
+++ dev/acpica/acpi_pcib_pci.c (working copy)
@@ -65,7 +65,6 @@
static int acpi_pcib_pci_probe(device_t bus);
static int acpi_pcib_pci_attach(device_t bus);
-static int acpi_pcib_pci_resume(device_t bus);
static int acpi_pcib_read_ivar(device_t dev, device_t child,
int which, uintptr_t *result);
static int acpi_pcib_pci_route_interrupt(device_t pcib,
@@ -75,39 +74,20 @@
/* Device interface */
DEVMETHOD(device_probe,acpi_pcib_pci_probe),
DEVMETHOD(device_attach, acpi_pcib_pci_attach),
-DEVMETHOD(device_shutdown, bus_generic_shutdown),
-DEVMETHOD(device_suspend, bus_generic_suspend),
-DEVMETHOD(device_resume, acpi_pcib_pci_resume),
/* Bus interface */
-DEVMETHOD(bus_print_child, bus_generic_print_child),
DEVMETHOD(bus_read_ivar, acpi_pcib_read_ivar),
-DEVMETHOD(bus_write_ivar, pcib_write_ivar),
-DEVMETHOD(bus_alloc_resource, pcib_alloc_resource),
-DEVMETHOD(bus_release_resource,bus_generic_release_resource),
-DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
-DEVMETHOD(bus_deactivate_resource,
bus_generic_deactivate_resource),
-DEVMETHOD(bus_setup_intr, bus_generic_setup_intr),
-DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr),
/* pcib interface */
-DEVMETHOD(pcib_maxslots, pcib_maxslots),
-DEVMETHOD(pcib_read_config,pcib_read_config),
-DEVMETHOD(pcib_write_config, pcib_write_config),
DEVMETHOD(pcib_route_interrupt,acpi_pcib_pci_route_interrupt),
-DEVMETHOD(pcib_alloc_msi, pcib_alloc_msi),
-DEVMETHOD(pcib_release_msi,pcib_release_msi),
-DEVMETHOD(pcib_alloc_msix, pcib_alloc_msix),
-DEVMETHOD(pcib_release_msix, pcib_release_msix),
-DEVMETHOD(pcib_map_msi,pcib_map_msi),
{0, 0}
};
static devclass_t pcib_devclass;
-DEFINE_CLASS_0(pcib, acpi_pcib_pci_driver, acpi_pcib_pci_methods,
-sizeof(struct acpi_pcib_softc));
+DEFINE_CLASS_1(pcib, acpi_pcib_pci_driver, acpi_pcib_pci_methods,
+sizeof(struct acpi_pcib_softc), pcib_driver);
DRIVER_MODULE(acpi_pcib, pci, acpi_pcib_pci_driver, pcib_devclass, 0, 0);
MODULE_DEPEND(acpi_pcib, acpi, 1, 1, 1);
@@ -142,13 +123,6 @@
}
static int
-acpi_pcib_pci_resume(device_t dev)
-{
-
-return (acpi_pcib_resume(dev));
-}
-
-static int
acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct acpi_pcib_softc *sc = device_get_softc(dev);
Index: dev/acpica/acpi_pcib_acpi.c
===
--- dev/acpica/acpi_pcib_acpi.c (revision 210796)
+++ dev/acpica/acpi_pcib_acpi.c (working copy)
@@ -65,7 +65,6 @@
static int acpi_pcib_acpi_probe(device_t bus);
static int
Re: sched_pin() versus PCPU_GET
On Tuesday, August 03, 2010 9:46:16 pm m...@freebsd.org wrote:
> 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 00mov%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 00mov%gs:0x48,%rax
> >> > 802db226: 00 00
> >> > if (lock_list != NULL && lock_list->ll_count != 0) {
> >> > 802db228: 48 85 c0test %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 ffmov%rax,-0x110(%rbp)
> >> > 802db232: 48 89 85 f8 fe ff ffmov%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 mov0x50(%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
Re: behaviour changes in mdconfig? or something related?
On Wed, 4 Aug 2010 14:40:27 +0200
Samuel Martín Moro wrote:
> Since 8.1 (8.0?), after calling bsdlabel, I still have /dev/${dev}a,
> but/dev/${dev}c doesn't show up anymore.
The 'c' partition is no longer created on FreeBSD 8 - you should
use /dev/${dev} instead of /dev/${dev}c :
http://www.freebsddiary.org/upgrade8.php .
--
Bruce
___
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: behaviour changes in mdconfig? or something related?
On Wed, Aug 4, 2010 at 5:40 AM, Samuel Martín Moro wrote:
> Hi,
...
> So, is it possible to / how could I make ${dev}c appear on 8.1, like it was
> in previous releases?
It's a geom(4) change. Try ${dev} instead of ${dev}c (this should work
on all releases, but I could be wrong).
HTH,
-Garrett
___
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"
behaviour changes in mdconfig? or something related?
Hi,
I started this thread in the freebsd-questions mailing list.
But since I'm quite sure it's not a bsdlabel problem, I might find better
answers here.
We have a script that buids custom FreeBSD releases.
This code works on 4.7, 5.4, 5.5, 6.2, 7.1 and 7.2.
I want to make it work with FreeBSD-8.1.
Brievly, it works like that:
having minimum4, the following disktab layout:
minimum4:ty=mfs:se#512:nt#1:rm#300:\
:ns#11520:nc#1:\
:pa#11520:oa#0:ba#4096:fa#512:\
:pc#11520:oc#0:bc#4096:fc#512:
dd if=/dev/zero of=bootfile.img bs=18k count=4096
dev=`mdconfig -a -t vnode -f bootfile.img`
bsdlabel -w -B -b $GENPATH/boot/boot /dev/$dev minimum4
newfs -O1 -i 4096 -o space -m 1 /dev/${dev}c
mount /dev/${dev}c /mnt
(cd cdroot ; find . | cpio -dump /mnt)
[...]
When bsdlabelling, I got these warnings:
bsdlabel: partition c doesn't cover the whole unit!
bsdlabel: An incorrect partition c may cause problems for standard system
utilities
But it never was a problem for older releases.
Since 8.1 (8.0?), after calling bsdlabel, I still have /dev/${dev}a,
but/dev/${dev}c doesn't show up anymore.
I tried mounting a 7.2-generated image (where I had both md0a and md0c) on a
8.1 host, and only had md0a listed in devs.
I tried mounting a 8.1-generated image (where I had only /dev/md0a) on a 7.2
host, and /dev/md0c finally appeard.
So, is it possible to / how could I make ${dev}c appear on 8.1, like it was
in previous releases?
Thanks!
Samuel Martín Moro
{EPITECH.} tek4
CamTrace S.A.S
(+033) 1 41 38 37 60
1 Allée de la Venelle
92150 Suresnes
FRANCE
"Nobody wants to say how this works.
Maybe nobody knows ..."
Xorg.conf(5)
___
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: Driver tpm(4) and third party packages for trusted platform modules
In message <201008040347.o743leer046...@sana.init-main.com>, wrote:
>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.
Update my patch. Split bus attachment from main driver file
(need to update sys/conf/files), add detach method for convinience,
and attach softc to cdev.si_drv1 .
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 19:32:44.0 +0900
@@ -49,6 +49,7 @@
#include
#include
#endif
+#include "tpmvar.h"
#ifndef __FreeBSD__
/* XXX horrible hack for tcsd (-lpthread) workaround on OpenBSD */
@@ -142,43 +143,10 @@
/* Set when enabling legacy interface in host bridge. */
int tpm_enabled;
-struct tpm_softc {
-#ifndef __FreeBSD__
- struct device sc_dev;
-#endif
- void *sc_ih;
-
- int (*sc_init)(struct tpm_softc *, int, const char *);
- int (*sc_start)(struct tpm_softc *, int);
- int (*sc_read)(struct tpm_softc *, void *, int, size_t *, int);
- int (*sc_write)(struct tpm_softc *, void *, int);
- int (*sc_end)(struct tpm_softc *, int, int);
-
- bus_space_tag_t sc_bt, sc_batm;
- bus_space_handle_t sc_bh, sc_bahm;
-
- u_int32_t sc_devid;
- u_int32_t sc_rev;
- u_int32_t sc_stat;
- u_int32_t sc_capabilities;
-
- int sc_flags;
-#defineTPM_OPEN0x0001
-
- int sc_vector;
-#ifdef __FreeBSD__
- void*intr_cookie;
-#endif
-
-#ifndef __FreeBSD__
- void*sc_powerhook;
-#endif
- int sc_suspend;
-};
#ifdef __FreeBSD__
#defineTPMSOFTC(dev) \
-((struct tpm_softc *)devclass_get_softc(tpm_devclass, dev2unit(dev)))
+ ((struct tpm_softc *)dev->si_drv1)
d_open_t tpmopen;
d_close_t tpmclose;
@@ -229,7 +197,6 @@
{ 0, "", TPM_DEV_NOINTS },
};
-int tpm_tis12_probe(bus_space_tag_t, bus_space_handle_t);
int tpm_tis12_irqinit(struct tpm_softc *, int, int);
int tpm_tis12_init(struct tpm_softc *, int, const char *);
int tpm_tis12_start(struct tpm_softc *, int);
@@ -239,8 +206,6 @@
#ifdef __FreeBSD__
void tpm_intr(void *);
-int tpm_suspend(device_t);
-int tpm_resume(device_t);
#else
int tpm_intr(void *);
void tpm_powerhook(int, void *);
@@ -264,67 +229,45 @@
int tpm_legacy_end(struct tpm_softc *, int, int);
#ifdef __FreeBSD__
+
/*
* 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)
-{
- struct tpm_softc *sc = device_get_softc(dev);
- bus_space_tag_t iot;
- bus_space_handle_t ioh;
- struct resource *mem_res;
- int rv, mem_rid;
-
- bzero(sc, sizeof(struct tpm_softc));
-
- mem_rid = 0;
- mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &mem_rid,
- RF_ACTIVE);
- if (mem_res == NULL)
- return (ENXIO);
- iot = rman_get_bustag(mem_res);
- ioh = rman_get_bushandle(mem_res);
-
- if ((rv = tpm_tis12_probe(iot, ioh)))
- device_set_desc(dev, "Trusted Platform Module");
-
- bus_release_resource(dev, SYS_RES_MEMORY, mem_rid, mem_res);
- return rv ? 0 : ENXIO;
-}
-static int
+int
tpm_attach(device_t dev)
{
struct tpm_softc *sc = device_get_softc(dev);
- struct resource *mem_res;
- int mem_rid;
- int irq_rid, irq;
- struct resource *irq_res;
+ int irq;
- mem_rid = 0;
- mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &mem_rid,
+ sc->mem_rid = 0;
+ sc->mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &sc->mem_rid,
RF_ACTIVE);
- if (mem_res == NULL)
+ if (sc->mem_res == NULL)
return ENXIO;
- sc->sc_bt = rman_get_bustag(mem_res);
- sc->sc_bh = rman_get_bushandle(mem_res);
+ sc->sc_bt = rman_get_bustag(sc->mem_res);
+ sc->sc_bh = rman_get_bushandle(sc->mem_res);
- irq_rid = 0;
- irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &irq_rid,
+ sc->irq_rid = 0;
+ sc->irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &sc->irq_rid,
RF_ACTIVE | RF_SHAREABLE);
- if (irq_res != NULL)
- irq = rman_get_start(irq_res);
+ if (sc->irq_res != NULL)
+ irq = rman_get_start(sc->irq_res);
else
irq = IRQUNK;
+ /*In case PnP probe this may contain some initialization.*/
+ tpm_tis12_probe(sc->sc_bt, sc->sc_bh);
+
Re: PCI config space is not restored upon resume (macbook pro)
On 3 August 2010 20:25, Oleg Sharoyko 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.
Indeed this was the problem of PCI-PIC bridges' registers not being
restored upon resume.
Thanks for your advise! I'm including the patch, which uses exiting
methods from dev/pic/pic_pci.c
to save/restore bridges' registers on suspend/resume. With it my
macbook pro no longer
looses devices after resume.
Unfortunately it doesn't help with videocard problem. Though I no
longer see 'failed to reload state'
message, display still stays blank and dark after resume. Would
freebsd-acpi be the right list
to ask for help or can you recommend anything else I can do to solve
this problem?
Index: dev/acpica/acpi_pcib_pci.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib_pci.c,v
retrieving revision 1.18
diff -u -r1.18 acpi_pcib_pci.c
--- dev/acpica/acpi_pcib_pci.c 5 Jun 2009 18:44:36 - 1.18
+++ dev/acpica/acpi_pcib_pci.c 4 Aug 2010 06:54:36 -
@@ -65,6 +65,7 @@
static int acpi_pcib_pci_probe(device_t bus);
static int acpi_pcib_pci_attach(device_t bus);
+static int acpi_pcib_pci_suspend(device_t bus);
static int acpi_pcib_pci_resume(device_t bus);
static int acpi_pcib_read_ivar(device_t dev, device_t child,
int which, uintptr_t *result);
@@ -76,7 +77,7 @@
DEVMETHOD(device_probe,acpi_pcib_pci_probe),
DEVMETHOD(device_attach, acpi_pcib_pci_attach),
DEVMETHOD(device_shutdown, bus_generic_shutdown),
-DEVMETHOD(device_suspend, bus_generic_suspend),
+DEVMETHOD(device_suspend, acpi_pcib_pci_suspend),
DEVMETHOD(device_resume, acpi_pcib_pci_resume),
/* Bus interface */
@@ -142,9 +143,20 @@
}
static int
-acpi_pcib_pci_resume(device_t dev)
+acpi_pcib_pci_suspend(device_t dev)
{
+struct acpi_pcib_softc *sc;
+sc = device_get_softc(dev);
+pcib_cfg_save(&sc->ap_pcibsc);
+return (bus_generic_suspend(dev));
+}
+static int
+acpi_pcib_pci_resume(device_t dev)
+{
+struct acpi_pcib_softc *sc;
+sc = device_get_softc(dev);
+pcib_cfg_restore(&sc->ap_pcibsc);
return (acpi_pcib_resume(dev));
}
Index: dev/pci/pci_pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v
retrieving revision 1.61
diff -u -r1.61 pci_pci.c
--- dev/pci/pci_pci.c 10 Dec 2009 01:01:53 - 1.61
+++ dev/pci/pci_pci.c 4 Aug 2010 06:54:36 -
@@ -238,7 +238,7 @@
/*
* Get current bridge configuration.
*/
-static void
+void
pcib_cfg_save(struct pcib_softc *sc)
{
device_tdev;
@@ -260,7 +260,7 @@
/*
* Restore previous bridge configuration.
*/
-static void
+void
pcib_cfg_restore(struct pcib_softc *sc)
{
device_tdev;
Index: dev/pci/pcib_private.h
===
RCS file: /home/ncvs/src/sys/dev/pci/pcib_private.h,v
retrieving revision 1.15
diff -u -r1.15 pcib_private.h
--- dev/pci/pcib_private.h 14 Mar 2009 14:08:53 - 1.15
+++ dev/pci/pcib_private.h 4 Aug 2010 06:54:36 -
@@ -82,5 +82,7 @@
intpcib_alloc_msix(device_t pcib, device_t dev, int *irq);
intpcib_release_msix(device_t pcib, device_t dev, int irq);
intpcib_map_msi(device_t pcib, device_t dev, int irq, uint64_t
*addr, uint32_t *data);
+void pcib_cfg_save(struct pcib_softc *sc);
+void pcib_cfg_restore(struct pcib_softc *sc);
#endif
--
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"
