Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
On Fri, Jun 24, 2011 at 9:35 PM, Mark Kettenis wrote: >> From: Jonathan Matthew >> Date: Fri, 24 Jun 2011 16:49:50 +1000 >> >> > Which shows how badly the chosen name for that function really is. >> > >> > I did some digging into the issue. If you look at 3400 docs, you'll >> > see that description of the AHCI_REG_CAP registers says that the BIOS >> > should set the BIOS should set the AHCI_REG_CAP_SPM bit (the port >> > multiplier capability bit) to 0. The documented default value for >> > this register has the bit set to 1 though. Also, the revision history >> > mentions the removal of port multiplier functionality. I guess what's >> > happened here is that Intel tried to support port multipliers, >> > discovered that it didn't work properly and told BIOS developers to >> > disable it. Unsurprisingly some BIOS developers didn't get the memo >> > and left the bit in its default state. So it's obvious that all >> > 3400/5-Series chipset AHCI variants are affected, and we should apply >> > the same fix to all of them. >> > >> > I looked at other chipsets as well, and the documentation strongly >> > suggests that the older (ICH) chipsets have the same issue. The >> > specified default value has the bit turned on, but the bit is either >> > undocumented or is documented as "set to 0 by the BIOS". And even the >> > new 6-series PCH seems to be affected. On the other hand Intel still >> > claims that port multipliers are supported by some of the ICH10 >> > variants. I'm really curious wether there are any machines where port >> > multipliers work on the Intel AHCI controller ports. If not, perhaps >> > we should blacklist all of the Intel chipsets. >> >> The only mentions I can see on Intel's website of port multipliers >> being supported are on overview pages for 3400 and ICH9, and when you >> look at the data sheets for those, the revision history says it was >> removed. For all the other chipsets I looked at, they don't mention it >> on the overview page and say "port multipliers not supported" in the >> data sheet. I'm not sure what to make of the default values for the >> AHCI capabilities register - several of the other bits don't seem to >> match up with the descriptions, even in cases where they haven't >> withdrawn support for a feature. > > But the default value, and the language describing the SPM bit really > is very similar across ICH7, ICH8, ICH10, 3400/5-Series and > C200/6-Series. For all these chipsets the datasheet says that the > BIOS should set the bit to 0. That is no accident. It is the same > piece of VHDL (or whatever Intel uses to design the logic) that's > simply evolving a bit from generation to generation. But the port > multiplier functionality stays non-functional. People have reported > issues with ICH7, ICH9 and 3400. So really, all ICH and PCH variants > are affected and we should quirk them all. Good point, I agree. Easier to list them all now rather than waiting for people to report them one by one. >> > Arguably, the chosen fix (the AHCI_F_IPMS_PROBE quirk) isn't quite >> > right. It is clear that (some) Intel AHCI variants simply don't >> > support port multipliers, so we should just skip the probe. On the >> > other hand, as long as this quirk works, we don't need to introduce >> > another one. >> >> The quirk was introduced for ATI SB600 and SB700 AHCIs where port >> multipliers do actually work, so I don't really like using it to fix >> devices where they don't. I just didn't realise that's what I was >> doing until now. > > Hmm, well, the SB600 databook says that port multipliers are supported > on ASIC revision A13 and above. So I wonder if the workaround is only > necessary for the older revisions whithout port multiplier support. I'll have to check this on Monday when I can get at the machine, but I'm pretty sure I've had a port multiplier working on an SB600 that required this quirk. untested diff follows. Index: ahci.c === RCS file: /cvs/src/sys/dev/pci/ahci.c,v retrieving revision 1.180 diff -u -r1.180 ahci.c --- ahci.c 14 Jun 2011 10:40:14 - 1.180 +++ ahci.c 24 Jun 2011 12:43:53 - @@ -418,6 +418,7 @@ #define AHCI_F_NO_NCQ (1<<0) #define AHCI_F_IGN_FR (1<<1) #define AHCI_F_IPMS_PROBE (1<<2) /* IPMS on failed PMP probe */ +#define AHCI_F_NO_PMP (1<<3) /* ignore PMP capability */ u_int sc_ncmds; @@ -456,7 +457,7 @@ struct pci_attach_args *); intahci_amd_hudson2_attach(struct ahci_softc *, struct pci_attach_args *); -intahci_intel_3400_1_attach(struct ahci_softc *, +intahci_intel_attach(struct ahci_softc *, struct pci_attach_args *); intahci_nvidia_mcp_attach(struct ahci_softc *,
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
> From: Jonathan Matthew > Date: Fri, 24 Jun 2011 16:49:50 +1000 > > > Which shows how badly the chosen name for that function really is. > > > > I did some digging into the issue. If you look at 3400 docs, you'll > > see that description of the AHCI_REG_CAP registers says that the BIOS > > should set the BIOS should set the AHCI_REG_CAP_SPM bit (the port > > multiplier capability bit) to 0. The documented default value for > > this register has the bit set to 1 though. Also, the revision history > > mentions the removal of port multiplier functionality. I guess what's > > happened here is that Intel tried to support port multipliers, > > discovered that it didn't work properly and told BIOS developers to > > disable it. Unsurprisingly some BIOS developers didn't get the memo > > and left the bit in its default state. So it's obvious that all > > 3400/5-Series chipset AHCI variants are affected, and we should apply > > the same fix to all of them. > > > > I looked at other chipsets as well, and the documentation strongly > > suggests that the older (ICH) chipsets have the same issue. The > > specified default value has the bit turned on, but the bit is either > > undocumented or is documented as "set to 0 by the BIOS". And even the > > new 6-series PCH seems to be affected. On the other hand Intel still > > claims that port multipliers are supported by some of the ICH10 > > variants. I'm really curious wether there are any machines where port > > multipliers work on the Intel AHCI controller ports. If not, perhaps > > we should blacklist all of the Intel chipsets. > > The only mentions I can see on Intel's website of port multipliers > being supported are on overview pages for 3400 and ICH9, and when you > look at the data sheets for those, the revision history says it was > removed. For all the other chipsets I looked at, they don't mention it > on the overview page and say "port multipliers not supported" in the > data sheet. I'm not sure what to make of the default values for the > AHCI capabilities register - several of the other bits don't seem to > match up with the descriptions, even in cases where they haven't > withdrawn support for a feature. But the default value, and the language describing the SPM bit really is very similar across ICH7, ICH8, ICH10, 3400/5-Series and C200/6-Series. For all these chipsets the datasheet says that the BIOS should set the bit to 0. That is no accident. It is the same piece of VHDL (or whatever Intel uses to design the logic) that's simply evolving a bit from generation to generation. But the port multiplier functionality stays non-functional. People have reported issues with ICH7, ICH9 and 3400. So really, all ICH and PCH variants are affected and we should quirk them all. > So, I think we should blacklist at least 3400 and ICH9, since that's > where the BIOS is likely to set things up wrong. I'll post a diff that > does this shortly. Blacklisting all Intel devices seems a bit much, > but on the other hand Intel doesn't seem at all interested in > supporting port multipliers. > > Where are you seeing references to port multiplier support in ICH10? I > don't think I've seen anything like that. The following page: http://www.intel.com/design/chipsets/matrixstorage_sb.htm mentions that the ICH10R, ICH9R and ICH9DO have port multiplier support. That's probably just the marketing people being out of touch tough, since at least for the ICH10R the data sheet explicitly says that port multipliers are not supported. > > Arguably, the chosen fix (the AHCI_F_IPMS_PROBE quirk) isn't quite > > right. It is clear that (some) Intel AHCI variants simply don't > > support port multipliers, so we should just skip the probe. On the > > other hand, as long as this quirk works, we don't need to introduce > > another one. > > The quirk was introduced for ATI SB600 and SB700 AHCIs where port > multipliers do actually work, so I don't really like using it to fix > devices where they don't. I just didn't realise that's what I was > doing until now. Hmm, well, the SB600 databook says that port multipliers are supported on ASIC revision A13 and above. So I wonder if the workaround is only necessary for the older revisions whithout port multiplier support.
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
On Fri, Jun 24, 2011 at 12:34 AM, Mark Kettenis wrote: >> From: David Gwynne >> Date: Thu, 23 Jun 2011 23:04:27 +1000 >> >> you dawe, >> >> you could point both chips at the same function... > > Which shows how badly the chosen name for that function really is. > > I did some digging into the issue. If you look at 3400 docs, you'll > see that description of the AHCI_REG_CAP registers says that the BIOS > should set the BIOS should set the AHCI_REG_CAP_SPM bit (the port > multiplier capability bit) to 0. The documented default value for > this register has the bit set to 1 though. Also, the revision history > mentions the removal of port multiplier functionality. I guess what's > happened here is that Intel tried to support port multipliers, > discovered that it didn't work properly and told BIOS developers to > disable it. Unsurprisingly some BIOS developers didn't get the memo > and left the bit in its default state. So it's obvious that all > 3400/5-Series chipset AHCI variants are affected, and we should apply > the same fix to all of them. > > I looked at other chipsets as well, and the documentation strongly > suggests that the older (ICH) chipsets have the same issue. The > specified default value has the bit turned on, but the bit is either > undocumented or is documented as "set to 0 by the BIOS". And even the > new 6-series PCH seems to be affected. On the other hand Intel still > claims that port multipliers are supported by some of the ICH10 > variants. I'm really curious wether there are any machines where port > multipliers work on the Intel AHCI controller ports. If not, perhaps > we should blacklist all of the Intel chipsets. The only mentions I can see on Intel's website of port multipliers being supported are on overview pages for 3400 and ICH9, and when you look at the data sheets for those, the revision history says it was removed. For all the other chipsets I looked at, they don't mention it on the overview page and say "port multipliers not supported" in the data sheet. I'm not sure what to make of the default values for the AHCI capabilities register - several of the other bits don't seem to match up with the descriptions, even in cases where they haven't withdrawn support for a feature. So, I think we should blacklist at least 3400 and ICH9, since that's where the BIOS is likely to set things up wrong. I'll post a diff that does this shortly. Blacklisting all Intel devices seems a bit much, but on the other hand Intel doesn't seem at all interested in supporting port multipliers. Where are you seeing references to port multiplier support in ICH10? I don't think I've seen anything like that. > Arguably, the chosen fix (the AHCI_F_IPMS_PROBE quirk) isn't quite > right. It is clear that (some) Intel AHCI variants simply don't > support port multipliers, so we should just skip the probe. On the > other hand, as long as this quirk works, we don't need to introduce > another one. The quirk was introduced for ATI SB600 and SB700 AHCIs where port multipliers do actually work, so I don't really like using it to fix devices where they don't. I just didn't realise that's what I was doing until now. thanks, -jonathan
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
Hi,
this fix (adapted for PCI_PRODUCT_INTEL_82801I_AHCI_3) works on my Dell Studio
1550:
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: msi, AHCI 1.2
Regards,
Holger
> Hi
>
> A similar patch also prevents the hang on my Toshiba NB200 (with
> PCI_PRODUCT_INTEL_82801GBM_AHCI):
>
> Index: ahci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/ahci.c,v
> retrieving revision 1.180
> diff -u -r1.180 ahci.c
> --- ahci.c 14 Jun 2011 10:40:14 - 1.180
> +++ ahci.c 23 Jun 2011 14:05:54 -
> @@ -482,6 +482,10 @@
>
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_1,
> NULL, ahci_intel_3400_1_attach },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_4,
> + NULL, ahci_intel_3400_1_attach },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GBM_AHCI,
> + NULL, ahci_intel_3400_1_attach },
>
> { PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP65_AHCI_2,
> NULL, ahci_nvidia_mcp_attach },
>
> In the case of PCI_PRODUCT_INTEL_82801GBM_AHCI would it be worth duplicating
> the function or alternatively would making the function name more generic be
> better?
>
> Cheers
> Tom
>
> OpenBSD 4.9-current (GENERIC.MP) #10: Thu Jun 23 15:09:41 BST 2011
> tom@laptop.FIXNETIX:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67
> GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWA
> IT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
> real mem = 1063645184 (1014MB)
> avail mem = 1036029952 (988MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 09/02/09, BIOS32 rev. 0 @ 0xfdbc0,
> SMBIOS rev. 2.4 @ 0xdc010 (22 entries)
> bios0: vendor TOSHIBA version "V1.60" date 09/02/2009
> bios0: TOSHIBA TOSHIBA NB200
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC HPET MCFG TCPA TMOR SLIC APIC BOOT SSDT SSDT
> SSDT SSDT
> acpi0: wakeup devices HDEF(S4) PXS1(S4) PXS2(S4) PXS3(S4) PXS4(S4) PXS5(S4)
> PXS6(S4) USB1(S3) USB2(S3) USB4(S3) USB7(S3) MODM(S
> 4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: apic clock running at 166MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67
> GHz
> cpu1:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWA
> IT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 2, remapped to apid 1
> acpihpet0 at acpi0: 14318179 Hz
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (RP01)
> acpiprt2 at acpi0: bus 3 (RP02)
> acpiprt3 at acpi0: bus 4 (RP03)
> acpiprt4 at acpi0: bus 5 (RP04)
> acpiprt5 at acpi0: bus -1 (RP05)
> acpiprt6 at acpi0: bus -1 (RP06)
> acpiprt7 at acpi0: bus 6 (PCIB)
> acpiec0 at acpi0
> acpicpu0 at acpi0: C3, C2, C1, PSS
> acpicpu1 at acpi0: C3, C2, C1, PSS
> acpibtn0 at acpi0: LID0
> acpibtn1 at acpi0: PWRB
> acpiac0 at acpi0: AC unit online
> acpibat0 at acpi0: BAT1 model "PA3734U-1BRS" serial 41167 type Li-Ion oem
> "TOSHIBA"
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: LCD_
> bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000 0xdc000/0x4000!
> 0xe/0x1800!
> cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
> vga1 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> intagp0 at vga1
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0 at vga1: apic 1 int 16
> drm0 at inteldrm0
> "Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
> azalia0: codecs: Realtek ALC272
> audio0 at azalia0
> ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 17
> pci1 at ppb0 bus 2
> ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 16
> pci2 at ppb1 bus 3
> athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 1 int 17
> athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 00:23:08:db:1c:27
> ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 18
> pci3 at ppb2 bus 4
> re0 at pci3 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL (0x2480),
> apic 1 int 18, address 00:26:22:40:15:51
> rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
> ppb3 at pci0 dev 28 function 3 "Intel
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
> Date: Thu, 23 Jun 2011 15:13:19 +0100 > From: Tom > > Hi > > A similar patch also prevents the hang on my Toshiba NB200 (with > PCI_PRODUCT_INTEL_82801GBM_AHCI): Ok, that's ICH9, where the docs the the port multiplier capability bit is "reserved", confirming my strong suspicion that ICH9 is affected as well. > In the case of PCI_PRODUCT_INTEL_82801GBM_AHCI would it be worth duplicating > the function or alternatively would making the function name more generic be > better? I'd suggest naming the function ahci_intel_ich_attach() and blacklisting all the 82801XX_AHCI variants and the 3400_AHCI variants.
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
> From: David Gwynne
> Date: Thu, 23 Jun 2011 23:04:27 +1000
>
> you dawe,
>
> you could point both chips at the same function...
Which shows how badly the chosen name for that function really is.
I did some digging into the issue. If you look at 3400 docs, you'll
see that description of the AHCI_REG_CAP registers says that the BIOS
should set the BIOS should set the AHCI_REG_CAP_SPM bit (the port
multiplier capability bit) to 0. The documented default value for
this register has the bit set to 1 though. Also, the revision history
mentions the removal of port multiplier functionality. I guess what's
happened here is that Intel tried to support port multipliers,
discovered that it didn't work properly and told BIOS developers to
disable it. Unsurprisingly some BIOS developers didn't get the memo
and left the bit in its default state. So it's obvious that all
3400/5-Series chipset AHCI variants are affected, and we should apply
the same fix to all of them.
I looked at other chipsets as well, and the documentation strongly
suggests that the older (ICH) chipsets have the same issue. The
specified default value has the bit turned on, but the bit is either
undocumented or is documented as "set to 0 by the BIOS". And even the
new 6-series PCH seems to be affected. On the other hand Intel still
claims that port multipliers are supported by some of the ICH10
variants. I'm really curious wether there are any machines where port
multipliers work on the Intel AHCI controller ports. If not, perhaps
we should blacklist all of the Intel chipsets.
Arguably, the chosen fix (the AHCI_F_IPMS_PROBE quirk) isn't quite
right. It is clear that (some) Intel AHCI variants simply don't
support port multipliers, so we should just skip the probe. On the
other hand, as long as this quirk works, we don't need to introduce
another one.
Cheers,
Mark
> On 23/06/2011, at 10:50 PM, Dawe wrote:
>
> > Hi,
> > the intel_3400_4 has the same issue as the intel_3400_1, ahci(4)
> > hangs for 30 seconds on boot and resume. See also PR6630.
> >
> > Index: ahci.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/ahci.c,v
> > retrieving revision 1.180
> > diff -u -p -r1.180 ahci.c
> > --- ahci.c 14 Jun 2011 10:40:14 - 1.180
> > +++ ahci.c 23 Jun 2011 12:34:49 -
> > @@ -458,6 +458,8 @@ int ahci_amd_hudson2_attach(struct
> > ahc
> > struct pci_attach_args *);
> > int ahci_intel_3400_1_attach(struct ahci_softc *,
> > struct pci_attach_args *);
> > +intahci_intel_3400_4_attach(struct ahci_softc *,
> > + struct pci_attach_args *);
> > int ahci_nvidia_mcp_attach(struct ahci_softc *,
> > struct pci_attach_args *);
> >
> > @@ -482,6 +484,8 @@ static const struct ahci_device ahci_dev
> >
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_1,
> > NULL, ahci_intel_3400_1_attach },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_4,
> > + NULL, ahci_intel_3400_4_attach },
> >
> > { PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP65_AHCI_2,
> > NULL, ahci_nvidia_mcp_attach },
> > @@ -717,6 +721,13 @@ ahci_amd_hudson2_attach(struct ahci_soft
> >
> > int
> > ahci_intel_3400_1_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
> > +{
> > + sc->sc_flags |= AHCI_F_IPMS_PROBE;
> > + return (0);
> > +}
> > +
> > +int
> > +ahci_intel_3400_4_attach(struct ahci_softc *sc, struct pci_attach_args
> *pa)
> > {
> > sc->sc_flags |= AHCI_F_IPMS_PROBE;
> > return (0);
> >
> >
> > OpenBSD 4.9-current (GENERIC.MP) #9: Thu Jun 23 13:06:40 CEST 2011
> >d...@padtree.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 1998045184 (1905MB)
> > avail mem = 1930702848 (1841MB)
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
> > bios0: vendor LENOVO version "6IET68WW (1.28 )" date 07/12/2010
> > bios0: LENOVO 25184QG
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA
> SSDT
> > SSDT SSDT
> > acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP1(S4) EXP2(S4)
> > EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpiec0 at acpi0
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.37 MHz
> > cpu0:
> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
> ,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: apic clock running at 133MHz
> > cpu1 at mainbus0: apid 1 (application proc
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
On Jun 23, 2011 23:04, David Gwynne wrote:
> you dawe,
>
> you could point both chips at the same function...
>
> dlg
sure, or would you prefer a name like ahci_intel_3400_1_4_attach?
Because the behaviour of 3400_2 and 3400_3 isn't known.
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.180
diff -u -p -r1.180 ahci.c
--- ahci.c 14 Jun 2011 10:40:14 - 1.180
+++ ahci.c 23 Jun 2011 13:58:33 -
@@ -456,7 +456,7 @@ int ahci_ati_sb700_attach(struct ahci_
struct pci_attach_args *);
intahci_amd_hudson2_attach(struct ahci_softc *,
struct pci_attach_args *);
-intahci_intel_3400_1_attach(struct ahci_softc *,
+intahci_intel_3400_attach(struct ahci_softc *,
struct pci_attach_args *);
intahci_nvidia_mcp_attach(struct ahci_softc *,
struct pci_attach_args *);
@@ -481,7 +481,9 @@ static const struct ahci_device ahci_dev
NULL, ahci_ati_sb700_attach },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_1,
- NULL, ahci_intel_3400_1_attach },
+ NULL, ahci_intel_3400_attach },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_4,
+ NULL, ahci_intel_3400_attach },
{ PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP65_AHCI_2,
NULL, ahci_nvidia_mcp_attach },
@@ -716,7 +718,7 @@ ahci_amd_hudson2_attach(struct ahci_soft
}
int
-ahci_intel_3400_1_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
+ahci_intel_3400_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
{
sc->sc_flags |= AHCI_F_IPMS_PROBE;
return (0);
>
> On 23/06/2011, at 10:50 PM, Dawe wrote:
>
> > Hi,
> > the intel_3400_4 has the same issue as the intel_3400_1, ahci(4)
> > hangs for 30 seconds on boot and resume. See also PR6630.
> >
> > Index: ahci.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/ahci.c,v
> > retrieving revision 1.180
> > diff -u -p -r1.180 ahci.c
> > --- ahci.c 14 Jun 2011 10:40:14 - 1.180
> > +++ ahci.c 23 Jun 2011 12:34:49 -
> > @@ -458,6 +458,8 @@ int ahci_amd_hudson2_attach(struct
> > ahc
> > struct pci_attach_args *);
> > int ahci_intel_3400_1_attach(struct ahci_softc *,
> > struct pci_attach_args *);
> > +intahci_intel_3400_4_attach(struct ahci_softc *,
> > + struct pci_attach_args *);
> > int ahci_nvidia_mcp_attach(struct ahci_softc *,
> > struct pci_attach_args *);
> >
> > @@ -482,6 +484,8 @@ static const struct ahci_device ahci_dev
> >
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_1,
> > NULL, ahci_intel_3400_1_attach },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_4,
> > + NULL, ahci_intel_3400_4_attach },
> >
> > { PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP65_AHCI_2,
> > NULL, ahci_nvidia_mcp_attach },
> > @@ -717,6 +721,13 @@ ahci_amd_hudson2_attach(struct ahci_soft
> >
> > int
> > ahci_intel_3400_1_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
> > +{
> > + sc->sc_flags |= AHCI_F_IPMS_PROBE;
> > + return (0);
> > +}
> > +
> > +int
> > +ahci_intel_3400_4_attach(struct ahci_softc *sc, struct pci_attach_args
> *pa)
> > {
> > sc->sc_flags |= AHCI_F_IPMS_PROBE;
> > return (0);
> >
> >
> > OpenBSD 4.9-current (GENERIC.MP) #9: Thu Jun 23 13:06:40 CEST 2011
> >d...@padtree.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 1998045184 (1905MB)
> > avail mem = 1930702848 (1841MB)
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
> > bios0: vendor LENOVO version "6IET68WW (1.28 )" date 07/12/2010
> > bios0: LENOVO 25184QG
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA
> SSDT
> > SSDT SSDT
> > acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP1(S4) EXP2(S4)
> > EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpiec0 at acpi0
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.37 MHz
> > cpu0:
> >
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
> ,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: apic clock running at 1
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
Hi
A similar patch also prevents the hang on my Toshiba NB200 (with
PCI_PRODUCT_INTEL_82801GBM_AHCI):
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.180
diff -u -r1.180 ahci.c
--- ahci.c 14 Jun 2011 10:40:14 - 1.180
+++ ahci.c 23 Jun 2011 14:05:54 -
@@ -482,6 +482,10 @@
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_1,
NULL, ahci_intel_3400_1_attach },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_4,
+ NULL, ahci_intel_3400_1_attach },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GBM_AHCI,
+ NULL, ahci_intel_3400_1_attach },
{ PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP65_AHCI_2,
NULL, ahci_nvidia_mcp_attach },
In the case of PCI_PRODUCT_INTEL_82801GBM_AHCI would it be worth duplicating
the function or alternatively would making the function name more generic be
better?
Cheers
Tom
OpenBSD 4.9-current (GENERIC.MP) #10: Thu Jun 23 15:09:41 BST 2011
tom@laptop.FIXNETIX:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWA
IT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
real mem = 1063645184 (1014MB)
avail mem = 1036029952 (988MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/02/09, BIOS32 rev. 0 @ 0xfdbc0,
SMBIOS rev. 2.4 @ 0xdc010 (22 entries)
bios0: vendor TOSHIBA version "V1.60" date 09/02/2009
bios0: TOSHIBA TOSHIBA NB200
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG TCPA TMOR SLIC APIC BOOT SSDT SSDT
SSDT SSDT
acpi0: wakeup devices HDEF(S4) PXS1(S4) PXS2(S4) PXS3(S4) PXS4(S4) PXS5(S4)
PXS6(S4) USB1(S3) USB2(S3) USB4(S3) USB7(S3) MODM(S
4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 166MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67
GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWA
IT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus 3 (RP02)
acpiprt3 at acpi0: bus 4 (RP03)
acpiprt4 at acpi0: bus 5 (RP04)
acpiprt5 at acpi0: bus -1 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus 6 (PCIB)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "PA3734U-1BRS" serial 41167 type Li-Ion oem
"TOSHIBA"
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000 0xdc000/0x4000!
0xe/0x1800!
cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
vga1 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1: apic 1 int 16
drm0 at inteldrm0
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Realtek ALC272
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 17
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 16
pci2 at ppb1 bus 3
athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 1 int 17
athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 00:23:08:db:1c:27
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 18
pci3 at ppb2 bus 4
re0 at pci3 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL (0x2480),
apic 1 int 18, address 00:26:22:40:15:51
rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 19
pci4 at ppb3 bus 5
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB US
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
you dawe,
you could point both chips at the same function...
dlg
On 23/06/2011, at 10:50 PM, Dawe wrote:
> Hi,
> the intel_3400_4 has the same issue as the intel_3400_1, ahci(4)
> hangs for 30 seconds on boot and resume. See also PR6630.
>
> Index: ahci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/ahci.c,v
> retrieving revision 1.180
> diff -u -p -r1.180 ahci.c
> --- ahci.c14 Jun 2011 10:40:14 - 1.180
> +++ ahci.c23 Jun 2011 12:34:49 -
> @@ -458,6 +458,8 @@ int ahci_amd_hudson2_attach(struct
> ahc
> struct pci_attach_args *);
> int ahci_intel_3400_1_attach(struct ahci_softc *,
> struct pci_attach_args *);
> +int ahci_intel_3400_4_attach(struct ahci_softc *,
> + struct pci_attach_args *);
> int ahci_nvidia_mcp_attach(struct ahci_softc *,
> struct pci_attach_args *);
>
> @@ -482,6 +484,8 @@ static const struct ahci_device ahci_dev
>
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_1,
> NULL, ahci_intel_3400_1_attach },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_4,
> + NULL, ahci_intel_3400_4_attach },
>
> { PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP65_AHCI_2,
> NULL, ahci_nvidia_mcp_attach },
> @@ -717,6 +721,13 @@ ahci_amd_hudson2_attach(struct ahci_soft
>
> int
> ahci_intel_3400_1_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
> +{
> + sc->sc_flags |= AHCI_F_IPMS_PROBE;
> + return (0);
> +}
> +
> +int
> +ahci_intel_3400_4_attach(struct ahci_softc *sc, struct pci_attach_args
*pa)
> {
> sc->sc_flags |= AHCI_F_IPMS_PROBE;
> return (0);
>
>
> OpenBSD 4.9-current (GENERIC.MP) #9: Thu Jun 23 13:06:40 CEST 2011
>d...@padtree.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1998045184 (1905MB)
> avail mem = 1930702848 (1841MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
> bios0: vendor LENOVO version "6IET68WW (1.28 )" date 07/12/2010
> bios0: LENOVO 25184QG
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA
SSDT
> SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP1(S4) EXP2(S4)
> EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.37 MHz
> cpu0:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: apic clock running at 133MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.00 MHz
> cpu1:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.00 MHz
> cpu2:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu3 at mainbus0: apid 5 (application processor)
> cpu3: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.00 MHz
> cpu3:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu3: 256KB 64b/line 8-way L2 cache
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 2, remapped to apid 1
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG_)
> acpiprt2 at acpi0: bus 2 (EXP1)
> acpiprt3 at acpi0: bus 3 (EXP2)
> acpiprt4 at acpi0: bus -1 (EXP3)
> acpiprt5 at acpi0: bus 5 (EXP4)
> acpiprt6 at acpi0: bus 13 (EXP5)
> acpicpu0 at acpi0: C3, C1, PSS
> acpicpu1 at acpi0: C3, C1, PSS
> acpicpu2 at acpi0: C3, C1, PSS
> acpicpu3 at acpi0: C3, C1, PSS
> acpipwrres0 at acpi0: PUBS
> acpitz0 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpibat0 at acpi0: BAT0 not present
> acpibat1 at acpi0: BAT1 not present
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0
> cpu0: Enhanced SpeedStep 2261 MHz:
ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
Hi,
the intel_3400_4 has the same issue as the intel_3400_1, ahci(4)
hangs for 30 seconds on boot and resume. See also PR6630.
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.180
diff -u -p -r1.180 ahci.c
--- ahci.c 14 Jun 2011 10:40:14 - 1.180
+++ ahci.c 23 Jun 2011 12:34:49 -
@@ -458,6 +458,8 @@ int ahci_amd_hudson2_attach(struct ahc
struct pci_attach_args *);
intahci_intel_3400_1_attach(struct ahci_softc *,
struct pci_attach_args *);
+intahci_intel_3400_4_attach(struct ahci_softc *,
+ struct pci_attach_args *);
intahci_nvidia_mcp_attach(struct ahci_softc *,
struct pci_attach_args *);
@@ -482,6 +484,8 @@ static const struct ahci_device ahci_dev
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_1,
NULL, ahci_intel_3400_1_attach },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_AHCI_4,
+ NULL, ahci_intel_3400_4_attach },
{ PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP65_AHCI_2,
NULL, ahci_nvidia_mcp_attach },
@@ -717,6 +721,13 @@ ahci_amd_hudson2_attach(struct ahci_soft
int
ahci_intel_3400_1_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
+{
+ sc->sc_flags |= AHCI_F_IPMS_PROBE;
+ return (0);
+}
+
+int
+ahci_intel_3400_4_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
{
sc->sc_flags |= AHCI_F_IPMS_PROBE;
return (0);
OpenBSD 4.9-current (GENERIC.MP) #9: Thu Jun 23 13:06:40 CEST 2011
d...@padtree.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1998045184 (1905MB)
avail mem = 1930702848 (1841MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version "6IET68WW (1.28 )" date 07/12/2010
bios0: LENOVO 25184QG
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP1(S4) EXP2(S4)
EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.37 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.00 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz, 2261.00 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 5 (EXP4)
acpiprt6 at acpi0: bus 13 (EXP5)
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpipwrres0 at acpi0: PUBS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
cpu0: Enhanced SpeedStep 2261 MHz: speeds: 2267, 2266, 2133, 1999, 1866, 1733,
1599, 1466, 1333, 1199 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel Mobile HD graphics" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0
