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: Future of ccd(4) and raid(4)?
On Thu, Jun 23, 2011 at 07:44:52PM -0700, Matthew Dempsky wrote: > On Thu, Jun 23, 2011 at 7:29 PM, Kenneth R Westerback > wrote: > > I use neither but know people claim to be using one or the other, > > but mostly raid(4), a.k.a. raidframe. > > Then it sounds like the solution is to subtly break them so we can > smoke out these claimed users! ;) > > > In particular until softraid > > can reliably be booted from, I think raid(4) will be useful to have. > > I don't think you can boot from raid(4) either though? I may be confusing 'boot from' and 'provide root'. Again, never tried it myself that I can recall. The important point being that whatever it can do, softraid must do better. :-) Ken
Re: Future of ccd(4) and raid(4)?
On Thu, Jun 23, 2011 at 7:29 PM, Kenneth R Westerback wrote: > I use neither but know people claim to be using one or the other, > but mostly raid(4), a.k.a. raidframe. Then it sounds like the solution is to subtly break them so we can smoke out these claimed users! ;) > In particular until softraid > can reliably be booted from, I think raid(4) will be useful to have. I don't think you can boot from raid(4) either though?
Re: Future of ccd(4) and raid(4)?
[+misc@, for users not subscribed to tech@] On Thu, Jun 23, 2011 at 4:39 PM, Matthew Dempsky wrote: > What should be done about ccd(4) and raid(4)? They both seem > superseded in functionality by softraid(4), which also has much more > developer interest and active development. > > Are there any users still using ccd(4) and/or raid(4) and unable to > upgrade to softraid(4)? Will anyone be up a creek if ccd(4)/raid(4) > were removed?
Re: Future of ccd(4) and raid(4)?
On Thu, Jun 23, 2011 at 04:39:19PM -0700, Matthew Dempsky wrote: > What should be done about ccd(4) and raid(4)? They both seem > superseded in functionality by softraid(4), which also has much more > developer interest and active development. > > Are there any users still using ccd(4) and/or raid(4) and unable to > upgrade to softraid(4)? Will anyone be up a creek if ccd(4)/raid(4) > were removed? > I use neither but know people claim to be using one or the other, but mostly raid(4), a.k.a. raidframe. In particular until softraid can reliably be booted from, I think raid(4) will be useful to have. Ken
Future of ccd(4) and raid(4)?
What should be done about ccd(4) and raid(4)? They both seem superseded in functionality by softraid(4), which also has much more developer interest and active development. Are there any users still using ccd(4) and/or raid(4) and unable to upgrade to softraid(4)? Will anyone be up a creek if ccd(4)/raid(4) were removed?
Re: Remove and clean up callers of pmap_clear_reference and pmap_page_protect
On Fri, Apr 15, 2011 at 05:15:02PM +0100, Owain Ainsworth wrote:
> audit callers of pmap_clear_reference() and
> pmap_page_protect(,,VM_PROT_NONE) just before uvm_pagedeactivate noting
> the fact that freshly deactivated pages have their reference cleared in
> uvm_pagedeactivate already.
>
> first off, clear_reference:
>
> uvm_anon.c -> only called on swapoff. we don't really require the reference
> cleared if it has been accessed. doesn't matter. and if it was just swapped in
> then the page won't be deactivated and it'll be freshly cleared again. Now I
> come to think about it, though deactivating something we just swapped in is
> wrong, since it isn't swapped out and has no backing store. deactivated pages
> mean we can dump them at will.
>
> uvm_aobj.c exactly the same situation as above.
>
> uvm_fault.c -> deactivating anons due to MADV. so either it is already
> deactivated and will have reference cleared, or is already deactivated and
> has been
> referenced since, so the advice is bullshit anyway, or it is active and will
> be
> cleared. (also only for UBC anyway, so this discussion was somewhat
> redundant)
>
> uvm_map.c -> only for ubc
>
> remove all of those redundant calls. The UBC stuff is useless now
> anyway.
>
> with pmap_page_protect, every caller of uvm_pagedeactivate first calls
> pmap_page_protect. This is techinically incorrect, but done due to pmap
> bugs. move the page protect call into uvm_pagedeactivate itself and
> detail with an XXX comment why this is done.
>
> The page_protect part of this diff was commited by art a few years ago
> and backed out as part of the big uvm backout and never reinstated.
>
> ok?
Here's a version of this diff that applies on top of the vnode.c fix
from last week (so just the uvm_vnode.c chunks changed).
I'm still running this everywhere.
-0-
diff --git uvm/uvm_anon.c uvm/uvm_anon.c
index d0c942b..9f2880f 100644
--- uvm/uvm_anon.c
+++ uvm/uvm_anon.c
@@ -351,8 +351,6 @@ uvm_anon_pagein(struct vm_anon *anon)
* deactivate the page (to put it on a page queue)
*/
- pmap_clear_reference(pg);
- pmap_page_protect(pg, VM_PROT_NONE);
uvm_lock_pageq();
uvm_pagedeactivate(pg);
uvm_unlock_pageq();
diff --git uvm/uvm_aobj.c uvm/uvm_aobj.c
index b2ba563..d53c21a 100644
--- uvm/uvm_aobj.c
+++ uvm/uvm_aobj.c
@@ -787,10 +787,6 @@ uao_flush(struct uvm_object *uobj, voff_t start, voff_t
stop, int flags)
continue;
uvm_lock_pageq();
- /* zap all mappings for the page. */
- pmap_page_protect(pp, VM_PROT_NONE);
-
- /* ...and deactivate the page. */
uvm_pagedeactivate(pp);
uvm_unlock_pageq();
@@ -1369,10 +1365,6 @@ uao_pagein_page(struct uvm_aobj *aobj, int pageidx)
/*
* deactivate the page (to put it on a page queue).
*/
- pmap_clear_reference(pg);
-#ifndef UBC
- pmap_page_protect(pg, VM_PROT_NONE);
-#endif
uvm_lock_pageq();
uvm_pagedeactivate(pg);
uvm_unlock_pageq();
diff --git uvm/uvm_fault.c uvm/uvm_fault.c
index 76f0708..8a11a3f 100644
--- uvm/uvm_fault.c
+++ uvm/uvm_fault.c
@@ -202,14 +202,8 @@ uvmfault_anonflush(struct vm_anon **anons, int n)
pg = anons[lcv]->an_page;
if (pg && (pg->pg_flags & PG_BUSY) == 0 && pg->loan_count == 0)
{
uvm_lock_pageq();
- if (pg->wire_count == 0) {
-#ifdef UBC
- pmap_clear_reference(pg);
-#else
- pmap_page_protect(pg, VM_PROT_NONE);
-#endif
+ if (pg->wire_count == 0)
uvm_pagedeactivate(pg);
- }
uvm_unlock_pageq();
}
simple_unlock(&anons[lcv]->an_lock);
diff --git uvm/uvm_map.c uvm/uvm_map.c
index dee6f73..919b43d 100644
--- uvm/uvm_map.c
+++ uvm/uvm_map.c
@@ -3181,15 +3181,7 @@ uvm_map_clean(struct vm_map *map, vaddr_t start, vaddr_t
end, int flags)
}
KASSERT(pg->uanon == anon);
-#ifdef UBC
/* ...and deactivate the page. */
- pmap_clear_reference(pg);
-#else
- /* zap all mappings for the page. */
- pmap_page_protect(pg, VM_PROT_NONE);
-
- /* ...and deactivate the page. */
-#endif
uvm_pagedeactivate(pg);
uvm_unlock_pageq();
diff --git uvm/uvm_page.c uvm/uvm_page.c
index e0eddfe..b327878 100644
--- uvm/uvm_page.c
+++ uvm/uvm_page.c
@@ -1368,6 +1368,22 @@ uvm_pageunwire(struct vm_page *pg)
void
uvm_pagedeactivate(struct vm_page *pg)
{
+ /*
+* XXX this isn't technically correc
typo in imsg_init.3
Index: imsg_init.3 === RCS file: /srv/radon/data/vcs/cvs/openbsd/src/lib/libutil/imsg_init.3,v retrieving revision 1.4 diff -u -p -r1.4 imsg_init.3 --- imsg_init.3 5 Mar 2011 15:05:39 - 1.4 +++ imsg_init.3 23 Jun 2011 21:51:57 - @@ -161,7 +161,7 @@ imsgbuf. creates a new message with header specified by .Fa type , .Fa peerid -ands +and .Fa pid . A .Fa pid
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: check for correct flag in uvm_page_unbusy
On Thu, Jun 23, 2011 at 07:05:25PM +0100, Owain Ainsworth wrote: > How about this now? > > I've got some more important uvm diffs on the way I but would like to > get the small ones out of my tree. ok. > On Tue, May 31, 2011 at 12:09:35AM +0100, Owain Ainsworth wrote: > > No functional change since aobjs should never hit this path. However, I > > introduced this diff when I reworked the page releasing stuff for > > objects. > > > > ok? > > > > diff --git uvm/uvm_page.c uvm/uvm_page.c > > index 10ef7d1..27e970a 100644 > > --- uvm/uvm_page.c > > +++ uvm/uvm_page.c > > @@ -1099,7 +1099,7 @@ uvm_page_unbusy(struct vm_page **pgs, int npgs) > > uvm_lock_pageq(); > > pmap_page_protect(pg, VM_PROT_NONE); > > /* XXX won't happen right now */ > > - if (pg->pg_flags & PQ_ANON) > > + if (pg->pg_flags & PQ_AOBJ) > > uao_dropswap(uobj, > > pg->offset >> PAGE_SHIFT); > > uvm_pagefree(pg); > > -- > > 1.7.5 > > > > > > -- > > Blood flows down one leg and up the other. > > -- > Campus sidewalks never exist as the straightest line between two > points. > -- M. M. Johnston > -- Ariane
Re: replaced handrolled version of uvmfault_unlockmaps with that function
On Thu, Jun 23, 2011 at 07:04:57PM +0100, Owain Ainsworth wrote:
> How about this now?
>
> On Tue, May 31, 2011 at 12:06:15AM +0100, Owain Ainsworth wrote:
> > ok?
Ok.
> > diff --git uvm/uvm_fault.c uvm/uvm_fault.c
> > index 76f0708..76429dc 100644
> > --- uvm/uvm_fault.c
> > +++ uvm/uvm_fault.c
> > @@ -1936,11 +1936,7 @@ uvmfault_lookup(struct uvm_faultinfo *ufi, boolean_t
> > write_lock)
> > */
> > if (UVM_ET_ISSUBMAP(ufi->entry)) {
> > tmpmap = ufi->entry->object.sub_map;
> > - if (write_lock) {
> > - vm_map_unlock(ufi->map);
> > - } else {
> > - vm_map_unlock_read(ufi->map);
> > - }
> > + uvmfault_unlockmaps(ufi, write_lock);
> > ufi->map = tmpmap;
> > continue;
> > }
> > --
> > 1.7.5
> >
> > --
> > It's easier to fight for one's principles than to live up to them.
>
> --
> I used to be an agnostic, but now I'm not so sure.
>
--
Ariane
Re: Don't bother checking for an empty pageq before freeing the list
On Thu, Jun 23, 2011 at 07:04:39PM +0100, Owain Ainsworth wrote:
> How about this now?
>
> On Tue, May 31, 2011 at 12:03:49AM +0100, Owain Ainsworth wrote:
> > It will handle an empty list just fine (there is a potential small
> > optimisation in there to avoid grabbing the fpageqlock if no pages need
> > freeing but that is another diff)
> >
> > ok?
Ok.
> > diff --git uvm/uvm_km.c uvm/uvm_km.c
> > index 1990adf..818cb18 100644
> > --- uvm/uvm_km.c
> > +++ uvm/uvm_km.c
> > @@ -925,8 +925,7 @@ alloc_va:
> > while (uvm_km_pages.free == 0) {
> > if (kd->kd_waitok == 0) {
> > mtx_leave(&uvm_km_pages.mtx);
> > - if (!TAILQ_EMPTY(&pgl))
> > - uvm_pglistfree(&pgl);
> > + uvm_pglistfree(&pgl);
> > return NULL;
> > }
> > msleep(&uvm_km_pages.free, &uvm_km_pages.mtx, PVM,
> > @@ -959,8 +958,7 @@ try_map:
> > tsleep(map, PVM, "km_allocva", 0);
> > goto try_map;
> > }
> > - if (!TAILQ_EMPTY(&pgl))
> > - uvm_pglistfree(&pgl);
> > + uvm_pglistfree(&pgl);
> > return (NULL);
> > }
> > }
> > --
> > 1.7.5
> >
> > --
> > Banectomy, n.:
> > The removal of bruises on a banana.
> > -- Rich Hall, "Sniglets"
>
> --
> "Matrimony isn't a word, it's a sentence."
>
--
Ariane
Re: Move uvm_pglist* to uvm_page.c
On Thu, Jun 23, 2011 at 07:04:48PM +0100, Owain Ainsworth wrote:
> How about this now?
>
> On Tue, May 31, 2011 at 12:05:04AM +0100, Owain Ainsworth wrote:
> > These functions used to be big and complicated, now they are glorified
> > wrappers around pmemrange and don't really need their own file.
> > Discussed with ariane@ a while ago.
> >
> > ok?
Ok.
> > diff --git conf/files conf/files
> > index 02da860..017e5f9 100644
> > --- conf/files
> > +++ conf/files
> > @@ -1007,7 +1007,6 @@ file uvm/uvm_object.c
> > file uvm/uvm_page.c
> > file uvm/uvm_pager.c
> > file uvm/uvm_pdaemon.c
> > -file uvm/uvm_pglist.c
> > file uvm/uvm_pmemrange.c
> > file uvm/uvm_stat.c
> > file uvm/uvm_swap.c
> > diff --git uvm/uvm_page.c uvm/uvm_page.c
> > index 10ef7d1..ed8e6d4 100644
> > --- uvm/uvm_page.c
> > +++ uvm/uvm_page.c
> > @@ -806,6 +806,81 @@ uvm_pagealloc_pg(struct vm_page *pg, struct uvm_object
> > *obj, voff_t off,
> > }
> >
> > /*
> > + * uvm_pglistalloc: allocate a list of pages
> > + *
> > + * => allocated pages are placed at the tail of rlist. rlist is
> > + *assumed to be properly initialized by caller.
> > + * => returns 0 on success or errno on failure
> > + * => doesn't take into account clean non-busy pages on inactive list
> > + * that could be used(?)
> > + * => params:
> > + * sizethe size of the allocation, rounded to page size.
> > + * low the low address of the allowed allocation range.
> > + * highthe high address of the allowed allocation range.
> > + * alignment memory must be aligned to this power-of-two boundary.
> > + * boundaryno segment in the allocation may cross this
> > + * power-of-two boundary (relative to zero).
> > + * => flags:
> > + * UVM_PLA_NOWAIT fail if allocation fails
> > + * UVM_PLA_WAITOK wait for memory to become avail
> > + * UVM_PLA_ZEROreturn zeroed memory
> > + */
> > +int
> > +uvm_pglistalloc(psize_t size, paddr_t low, paddr_t high, paddr_t alignment,
> > +paddr_t boundary, struct pglist *rlist, int nsegs, int flags)
> > +{
> > + UVMHIST_FUNC("uvm_pglistalloc"); UVMHIST_CALLED(pghist);
> > +
> > + KASSERT((alignment & (alignment - 1)) == 0);
> > + KASSERT((boundary & (boundary - 1)) == 0);
> > + KASSERT(!(flags & UVM_PLA_WAITOK) ^ !(flags & UVM_PLA_NOWAIT));
> > +
> > + if (size == 0)
> > + return (EINVAL);
> > +
> > + if ((high & PAGE_MASK) != PAGE_MASK) {
> > + printf("uvm_pglistalloc: Upper boundary 0x%lx "
> > + "not on pagemask.\n", (unsigned long)high);
> > + }
> > +
> > + /*
> > +* Our allocations are always page granularity, so our alignment
> > +* must be, too.
> > +*/
> > + if (alignment < PAGE_SIZE)
> > + alignment = PAGE_SIZE;
> > +
> > + low = atop(roundup(low, alignment));
> > + /*
> > +* high + 1 may result in overflow, in which case high becomes 0x0,
> > +* which is the 'don't care' value.
> > +* The only requirement in that case is that low is also 0x0, or the
> > +* low > +*/
> > + high = atop(high + 1);
> > + size = atop(round_page(size));
> > + alignment = atop(alignment);
> > + if (boundary < PAGE_SIZE && boundary != 0)
> > + boundary = PAGE_SIZE;
> > + boundary = atop(boundary);
> > +
> > + return uvm_pmr_getpages(size, low, high, alignment, boundary, nsegs,
> > + flags, rlist);
> > +}
> > +
> > +/*
> > + * uvm_pglistfree: free a list of pages
> > + *
> > + * => pages should already be unmapped
> > + */
> > +void
> > +uvm_pglistfree(struct pglist *list)
> > +{
> > + UVMHIST_FUNC("uvm_pglistfree"); UVMHIST_CALLED(pghist);
> > + uvm_pmr_freepageq(list);
> > +}
> > +
> > +/*
> > * interface used by the buffer cache to allocate a buffer at a time.
> > * The pages are allocated wired in DMA accessible memory
> > */
> > diff --git uvm/uvm_pglist.c uvm/uvm_pglist.c
> > deleted file mode 100644
> > index d29fb14..000
> > --- uvm/uvm_pglist.c
> > +++ /dev/null
> > @@ -1,136 +0,0 @@
> > -/* $OpenBSD$ */
> > -/* $NetBSD: uvm_pglist.c,v 1.13 2001/02/18 21:19:08 chs Exp $ */
> > -
> > -/*-
> > - * Copyright (c) 1997 The NetBSD Foundation, Inc.
> > - * All rights reserved.
> > - *
> > - * This code is derived from software contributed to The NetBSD Foundation
> > - * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
> > - * NASA Ames Research Center.
> > - *
> > - * Redistribution and use in source and binary forms, with or without
> > - * modification, are permitted provided that the following conditions
> > - * are met:
> > - * 1. Redistributions of source code must retain the above copyright
> > - *notice, this list of conditions and the following disclaimer.
> > - * 2. Redistributions in binary form must reproduce the above copyright
> > - *notice, this list of conditions and the following disclaimer in the
> > - *documentation and/or other materials provided with the distribution.
remove obsolete mcast routes in ldpd and ripd
We fixed the kernel and now it should be no longer needed to insert
special multicast routes to allow sending of the multicast messages.
So this removes this code from kroute.c
please test (especially ripd)
--
:wq Claudio
Index: usr.sbin/ldpd/kroute.c
===
RCS file: /cvs/src/usr.sbin/ldpd/kroute.c,v
retrieving revision 1.24
diff -u -p -r1.24 kroute.c
--- usr.sbin/ldpd/kroute.c 20 Oct 2010 12:16:41 - 1.24
+++ usr.sbin/ldpd/kroute.c 23 Jun 2011 20:33:42 -
@@ -108,9 +108,7 @@ RB_HEAD(kif_tree, kif_node) kit;
RB_PROTOTYPE(kif_tree, kif_node, entry, kif_compare)
RB_GENERATE(kif_tree, kif_node, entry, kif_compare)
-struct kroute kr_all_routers;
intflag_implicit_null = 0;
-intflag_all_routers = 0;
int
kif_init(void)
@@ -166,17 +164,6 @@ kr_init(int fs)
if (protect_lo() == -1)
return (-1);
- kr_all_routers.prefix.s_addr = inet_addr(AllRouters);
- kr_all_routers.prefixlen = mask2prefixlen(INADDR_BROADCAST);
- kr_all_routers.nexthop.s_addr = htonl(INADDR_LOOPBACK);
- kr_all_routers.remote_label = NO_LABEL;
-
- kr_state.fib_sync = 1; /* force addition of multicast route */
- if (send_rtmsg(kr_state.fd, RTM_ADD, &kr_all_routers, AF_INET) != -1)
- flag_all_routers = 1;
-
- kr_state.fib_sync = fs; /* now set correct sync mode */
-
event_set(&kr_state.ev, kr_state.fd, EV_READ | EV_PERSIST,
kr_dispatch_msg, NULL);
event_add(&kr_state.ev, NULL);
@@ -255,13 +242,6 @@ void
kr_shutdown(void)
{
kr_fib_decouple();
-
- if (flag_all_routers) {
- kr_state.fib_sync = 1; /* force removal of mulitcast route */
- (void)send_rtmsg(kr_state.fd, RTM_DELETE, &kr_all_routers,
- AF_INET);
- kr_state.fib_sync = 0; /* back to decoupled state */
- }
kroute_clear();
kif_clear();
Index: usr.sbin/ripd/kroute.c
===
RCS file: /cvs/src/usr.sbin/ripd/kroute.c,v
retrieving revision 1.22
diff -u -p -r1.22 kroute.c
--- usr.sbin/ripd/kroute.c 12 Jul 2010 14:35:13 - 1.22
+++ usr.sbin/ripd/kroute.c 23 Jun 2011 20:33:05 -
@@ -97,9 +97,6 @@ RB_HEAD(kif_tree, kif_node) kit;
RB_PROTOTYPE(kif_tree, kif_node, entry, kif_compare)
RB_GENERATE(kif_tree, kif_node, entry, kif_compare)
-struct kroute kr_all_rip_routers;
-intflag_all_rip_routers = 0;
-
int
kif_init(void)
{
@@ -151,14 +148,6 @@ kr_init(int fs, u_int rdomain)
if (protect_lo() == -1)
return (-1);
- kr_all_rip_routers.prefix.s_addr = inet_addr(ALL_RIP_ROUTERS);
- kr_all_rip_routers.netmask.s_addr = htonl(INADDR_BROADCAST);
- kr_all_rip_routers.nexthop.s_addr = htonl(INADDR_LOOPBACK);
-
- kr_state.fib_sync = 1; /* force addition of multicast route */
- if (send_rtmsg(kr_state.fd, RTM_ADD, &kr_all_rip_routers) != -1)
- flag_all_rip_routers = 1;
-
kr_state.fib_sync = fs; /* now set correct sync mode */
kr_state.rdomain = rdomain;
@@ -243,11 +232,6 @@ void
kr_shutdown(void)
{
kr_fib_decouple();
-
- if (flag_all_rip_routers) {
- kr_state.fib_sync = 1; /* force removal of mulitcast route */
- (void)send_rtmsg(kr_state.fd, RTM_DELETE, &kr_all_rip_routers);
- }
kroute_clear();
kif_clear();
Re: nc(1), GNU netcat and FIN segments after all data has been sent
On 06/23/11 14:10, Andreas Bartelt wrote: > Hello, > > I've noticed that there's a difference in behavior between nc(1) and GNU > netcat when they talk to some daemon via TCP. > > The commands in the following example are basically the same: > > GNU netcat: > netcat host 1234 < infile > > nc(1): > nc host 1234 < infile > > nc(1) sends a FIN segment after all data has been read from stdin: > shutdown(nfd, SHUT_WR) in netcat.c causes TCP to enter FIN-WAIT-1 state. > GNU netcat doesn't do this. I've noticed that some daemons behave > differently because of this, i.e., they won't return any data although > they are still allowed to send data. Maybe you can force nc(1) not to send a FIN segment by using something like this: cat infile - |nc host 1234 Christopher > I think both variants are allowed in RFC 793. Would it make sense to add > a further option to nc(1) which allows to toggle between both variants? > > Regards > Andreas
Re: check for correct flag in uvm_page_unbusy
How about this now? I've got some more important uvm diffs on the way I but would like to get the small ones out of my tree. -0- On Tue, May 31, 2011 at 12:09:35AM +0100, Owain Ainsworth wrote: > No functional change since aobjs should never hit this path. However, I > introduced this diff when I reworked the page releasing stuff for > objects. > > ok? > > diff --git uvm/uvm_page.c uvm/uvm_page.c > index 10ef7d1..27e970a 100644 > --- uvm/uvm_page.c > +++ uvm/uvm_page.c > @@ -1099,7 +1099,7 @@ uvm_page_unbusy(struct vm_page **pgs, int npgs) > uvm_lock_pageq(); > pmap_page_protect(pg, VM_PROT_NONE); > /* XXX won't happen right now */ > - if (pg->pg_flags & PQ_ANON) > + if (pg->pg_flags & PQ_AOBJ) > uao_dropswap(uobj, > pg->offset >> PAGE_SHIFT); > uvm_pagefree(pg); > -- > 1.7.5 > > > -- > Blood flows down one leg and up the other. -- Campus sidewalks never exist as the straightest line between two points. -- M. M. Johnston
Re: Don't bother checking for an empty pageq before freeing the list
How about this now?
On Tue, May 31, 2011 at 12:03:49AM +0100, Owain Ainsworth wrote:
> It will handle an empty list just fine (there is a potential small
> optimisation in there to avoid grabbing the fpageqlock if no pages need
> freeing but that is another diff)
>
> ok?
>
> diff --git uvm/uvm_km.c uvm/uvm_km.c
> index 1990adf..818cb18 100644
> --- uvm/uvm_km.c
> +++ uvm/uvm_km.c
> @@ -925,8 +925,7 @@ alloc_va:
> while (uvm_km_pages.free == 0) {
> if (kd->kd_waitok == 0) {
> mtx_leave(&uvm_km_pages.mtx);
> - if (!TAILQ_EMPTY(&pgl))
> - uvm_pglistfree(&pgl);
> + uvm_pglistfree(&pgl);
> return NULL;
> }
> msleep(&uvm_km_pages.free, &uvm_km_pages.mtx, PVM,
> @@ -959,8 +958,7 @@ try_map:
> tsleep(map, PVM, "km_allocva", 0);
> goto try_map;
> }
> - if (!TAILQ_EMPTY(&pgl))
> - uvm_pglistfree(&pgl);
> + uvm_pglistfree(&pgl);
> return (NULL);
> }
> }
> --
> 1.7.5
>
> --
> Banectomy, n.:
> The removal of bruises on a banana.
> -- Rich Hall, "Sniglets"
--
"Matrimony isn't a word, it's a sentence."
Re: Move uvm_pglist* to uvm_page.c
How about this now?
On Tue, May 31, 2011 at 12:05:04AM +0100, Owain Ainsworth wrote:
> These functions used to be big and complicated, now they are glorified
> wrappers around pmemrange and don't really need their own file.
> Discussed with ariane@ a while ago.
>
> ok?
>
>
> diff --git conf/files conf/files
> index 02da860..017e5f9 100644
> --- conf/files
> +++ conf/files
> @@ -1007,7 +1007,6 @@ file uvm/uvm_object.c
> file uvm/uvm_page.c
> file uvm/uvm_pager.c
> file uvm/uvm_pdaemon.c
> -file uvm/uvm_pglist.c
> file uvm/uvm_pmemrange.c
> file uvm/uvm_stat.c
> file uvm/uvm_swap.c
> diff --git uvm/uvm_page.c uvm/uvm_page.c
> index 10ef7d1..ed8e6d4 100644
> --- uvm/uvm_page.c
> +++ uvm/uvm_page.c
> @@ -806,6 +806,81 @@ uvm_pagealloc_pg(struct vm_page *pg, struct uvm_object
> *obj, voff_t off,
> }
>
> /*
> + * uvm_pglistalloc: allocate a list of pages
> + *
> + * => allocated pages are placed at the tail of rlist. rlist is
> + *assumed to be properly initialized by caller.
> + * => returns 0 on success or errno on failure
> + * => doesn't take into account clean non-busy pages on inactive list
> + * that could be used(?)
> + * => params:
> + * sizethe size of the allocation, rounded to page size.
> + * low the low address of the allowed allocation range.
> + * highthe high address of the allowed allocation range.
> + * alignment memory must be aligned to this power-of-two boundary.
> + * boundaryno segment in the allocation may cross this
> + * power-of-two boundary (relative to zero).
> + * => flags:
> + * UVM_PLA_NOWAIT fail if allocation fails
> + * UVM_PLA_WAITOK wait for memory to become avail
> + * UVM_PLA_ZEROreturn zeroed memory
> + */
> +int
> +uvm_pglistalloc(psize_t size, paddr_t low, paddr_t high, paddr_t alignment,
> +paddr_t boundary, struct pglist *rlist, int nsegs, int flags)
> +{
> + UVMHIST_FUNC("uvm_pglistalloc"); UVMHIST_CALLED(pghist);
> +
> + KASSERT((alignment & (alignment - 1)) == 0);
> + KASSERT((boundary & (boundary - 1)) == 0);
> + KASSERT(!(flags & UVM_PLA_WAITOK) ^ !(flags & UVM_PLA_NOWAIT));
> +
> + if (size == 0)
> + return (EINVAL);
> +
> + if ((high & PAGE_MASK) != PAGE_MASK) {
> + printf("uvm_pglistalloc: Upper boundary 0x%lx "
> + "not on pagemask.\n", (unsigned long)high);
> + }
> +
> + /*
> + * Our allocations are always page granularity, so our alignment
> + * must be, too.
> + */
> + if (alignment < PAGE_SIZE)
> + alignment = PAGE_SIZE;
> +
> + low = atop(roundup(low, alignment));
> + /*
> + * high + 1 may result in overflow, in which case high becomes 0x0,
> + * which is the 'don't care' value.
> + * The only requirement in that case is that low is also 0x0, or the
> + * low + */
> + high = atop(high + 1);
> + size = atop(round_page(size));
> + alignment = atop(alignment);
> + if (boundary < PAGE_SIZE && boundary != 0)
> + boundary = PAGE_SIZE;
> + boundary = atop(boundary);
> +
> + return uvm_pmr_getpages(size, low, high, alignment, boundary, nsegs,
> + flags, rlist);
> +}
> +
> +/*
> + * uvm_pglistfree: free a list of pages
> + *
> + * => pages should already be unmapped
> + */
> +void
> +uvm_pglistfree(struct pglist *list)
> +{
> + UVMHIST_FUNC("uvm_pglistfree"); UVMHIST_CALLED(pghist);
> + uvm_pmr_freepageq(list);
> +}
> +
> +/*
> * interface used by the buffer cache to allocate a buffer at a time.
> * The pages are allocated wired in DMA accessible memory
> */
> diff --git uvm/uvm_pglist.c uvm/uvm_pglist.c
> deleted file mode 100644
> index d29fb14..000
> --- uvm/uvm_pglist.c
> +++ /dev/null
> @@ -1,136 +0,0 @@
> -/* $OpenBSD$ */
> -/* $NetBSD: uvm_pglist.c,v 1.13 2001/02/18 21:19:08 chs Exp $ */
> -
> -/*-
> - * Copyright (c) 1997 The NetBSD Foundation, Inc.
> - * All rights reserved.
> - *
> - * This code is derived from software contributed to The NetBSD Foundation
> - * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
> - * NASA Ames Research Center.
> - *
> - * Redistribution and use in source and binary forms, with or without
> - * modification, are permitted provided that the following conditions
> - * are met:
> - * 1. Redistributions of source code must retain the above copyright
> - *notice, this list of conditions and the following disclaimer.
> - * 2. Redistributions in binary form must reproduce the above copyright
> - *notice, this list of conditions and the following disclaimer in the
> - *documentation and/or other materials provided with the distribution.
> - *
> - * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
> - * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED
> - * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNE
Re: replaced handrolled version of uvmfault_unlockmaps with that function
How about this now?
On Tue, May 31, 2011 at 12:06:15AM +0100, Owain Ainsworth wrote:
> ok?
>
> diff --git uvm/uvm_fault.c uvm/uvm_fault.c
> index 76f0708..76429dc 100644
> --- uvm/uvm_fault.c
> +++ uvm/uvm_fault.c
> @@ -1936,11 +1936,7 @@ uvmfault_lookup(struct uvm_faultinfo *ufi, boolean_t
> write_lock)
>*/
> if (UVM_ET_ISSUBMAP(ufi->entry)) {
> tmpmap = ufi->entry->object.sub_map;
> - if (write_lock) {
> - vm_map_unlock(ufi->map);
> - } else {
> - vm_map_unlock_read(ufi->map);
> - }
> + uvmfault_unlockmaps(ufi, write_lock);
> ufi->map = tmpmap;
> continue;
> }
> --
> 1.7.5
>
> --
> It's easier to fight for one's principles than to live up to them.
--
I used to be an agnostic, but now I'm not so sure.
Testers needed for ahc(4) diff
Diff below cleans up ahc(4) to use scsi_link::bus instead of (mis)using scsi_link::scsibus. If you have an ahc(4) (particularly a dual-channel one), I'd appreciate test reports + dmesg. (As long as your devices still show up, then it's working.) Index: pci/ahc_pci.c === RCS file: /home/mdempsky/anoncvs/cvs/src/sys/dev/pci/ahc_pci.c,v retrieving revision 1.53 diff -u -p -r1.53 ahc_pci.c --- pci/ahc_pci.c 13 May 2008 02:24:08 - 1.53 +++ pci/ahc_pci.c 23 Jun 2011 18:08:36 - @@ -737,12 +737,6 @@ ahc_pci_attach(parent, self, aux) for (i = 0; i < AHC_NUM_TARGETS; i++) TAILQ_INIT(&ahc->untagged_queues[i]); - /* -* SCSI_IS_SCSIBUS_B() must returns false until sc_channel_b -* has been properly initialized. XXX Breaks if >254 scsi buses. -*/ - ahc->sc_channel_b.scsibus = 0xff; - ahc->dev_softc = pa; ahc_set_name(ahc, ahc->sc_dev.dv_xname); Index: ic/aic7xxx_openbsd.h === RCS file: /home/mdempsky/anoncvs/cvs/src/sys/dev/ic/aic7xxx_openbsd.h,v retrieving revision 1.19 diff -u -p -r1.19 aic7xxx_openbsd.h --- ic/aic7xxx_openbsd.h15 Sep 2007 10:10:37 - 1.19 +++ ic/aic7xxx_openbsd.h23 Jun 2011 18:18:56 - @@ -88,7 +88,7 @@ /** Platform Macros ***/ #defineSCSI_IS_SCSIBUS_B(ahc, sc_link) \ - ((sc_link)->scsibus == (ahc)->sc_channel_b.scsibus) + ((sc_link)->bus->adapter_link == &(ahc)->sc_channel_b) #defineSCSI_SCSI_ID(ahc, sc_link) \ (SCSI_IS_SCSIBUS_B(ahc, sc_link) ? ahc->our_id_b : ahc->our_id) #defineSCSI_CHANNEL(ahc, sc_link) \
Re: nc(1), GNU netcat and FIN segments after all data has been sent
Hi Theo, On 06/23/11 18:30, Theo de Raadt wrote: ... I've noticed that some daemons behave differently because of this, i.e., they won't return any data although they are still allowed to send data. Yes, those daemons are broken. Their select/poll loops are unaware that writeability and readability of a socket is independent. One of the reasons that netcat should do be doing this, is so that such bugs can be triggered. It is a good thing for them to be triggered. The half-open socket semantics are "the real world" and they happen all the time. yes, you're right. I've noticed that the behavior is different while doing some work related stuff with some server software which is proprietary and buggy -- and it probably will never get fixed... The irony is that testing buggy software worked only with buggy software in this particular case. I think both variants are allowed in RFC 793. Would it make sense to add a further option to nc(1) which allows to toggle between both variants? There is no variation. Sockets can be half-closed. Sure, a particular client or server could leave it open until completely, but now you are testing less. You are saying it is a variation when you use less than full functionality of a socket? That's not a variation. It's called a subset. But I think your real problem is that GNU netcat is incompatible. Typical. My "problem" was related to the server side. I needed GNU netcat in order to trigger (possibly even more buggy) responses from the (buggy) server side. My particular use case was not about right or wrong but about triggering some stuff on the server side. I'm aware that the current behavior of nc(1) is the intended way to handle TCP sessions according to RFC 793. I was not sure if the GNU variant is actually non-compliant. Regards Andreas
Re: nc(1), GNU netcat and FIN segments after all data has been sent
> I've noticed that there's a difference in behavior between nc(1) and GNU > netcat when they talk to some daemon via TCP. Note there are 3 netcats. There was the original non-free one by Hobbit; he did not want to free it and the code was quite a mish-mash. Then there was our rewrite, which is now being used by lots of other projects. We made it behave exactly like the original, and then added a few small features. Then there is this new non-free one that some GNU people have written, which is clearly incompatible. One could argue that they can have creative control if they were operating in a vacuum, except they are not. They must follow what the others do, or they are incompatible and broken. If they wrote their own GNU ssh and all the options acted differently from OpenSSH, who do you think would be to blame? They would be. > The commands in the following example are basically the same: > > GNU netcat: > netcat host 1234 < infile > > nc(1): > nc host 1234 < infile > > nc(1) sends a FIN segment after all data has been read from stdin: > shutdown(nfd, SHUT_WR) in netcat.c causes TCP to enter FIN-WAIT-1 state. > GNU netcat doesn't do this. GNU netcat is wrong. The original Hobbit netcat and OpenBSD nc do an early shutdown intentional, to use the full behaviour of sockets. > I've noticed that some daemons behave > differently because of this, i.e., they won't return any data although > they are still allowed to send data. Yes, those daemons are broken. Their select/poll loops are unaware that writeability and readability of a socket is independent. One of the reasons that netcat should do be doing this, is so that such bugs can be triggered. It is a good thing for them to be triggered. The half-open socket semantics are "the real world" and they happen all the time. > I think both variants are allowed in RFC 793. Would it make sense to add > a further option to nc(1) which allows to toggle between both variants? There is no variation. Sockets can be half-closed. Sure, a particular client or server could leave it open until completely, but now you are testing less. You are saying it is a variation when you use less than full functionality of a socket? That's not a variation. It's called a subset. But I think your real problem is that GNU netcat is incompatible. Typical.
Deactivation of Your Email Address
THIS MESSAGE IS FROM OUR TECHNICAL SUPPORT TEAM This message is sent automatically by the computer. If you are receiving this message it means that your email address has been queued for deactivation; this was as a result of a continuous error script (code:505)receiving from this email address. Click here and fill out the required field to resolve this problem Note: Failure to reset your email by ignoring this message or inputting wrong information will result to instant deactivation of this email address
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:
Re: bus_dmamem_map fix (test+ok)
On Wed, Jun 22, 2011 at 09:32:06PM +0200, Ariane van der Steldt wrote:
> On Tue, Jun 21, 2011 at 09:00:49PM +0200, Ariane van der Steldt wrote:
> > Bus_dmamem_map has a bug in its error path, where it frees the wrong
> > memory in the wrong way.
>
> After some discussion on icb, the comments and the pmap_remove can go
> too. The pmap_remove is executed by uvm_km_free() at uvm_unmap_remove()
> and uvm_km_free won't use the pmap but the object to lookup pages (and
> the object has none at these addresses).
>
> Ok?
OK.
> --
> Ariane
>
>
> Index: arch/alpha/dev/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/alpha/dev/bus_dma.c,v
> retrieving revision 1.30
> diff -u -d -p -r1.30 bus_dma.c
> --- arch/alpha/dev/bus_dma.c 26 Dec 2010 15:40:58 - 1.30
> +++ arch/alpha/dev/bus_dma.c 22 Jun 2011 18:59:28 -
> @@ -614,12 +614,8 @@ _bus_dmamem_map(t, segs, nsegs, size, kv
> VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ |
> VM_PROT_WRITE | PMAP_WIRED | PMAP_CANFAIL);
> if (error) {
> - /*
> - * Clean up after ourselves.
> - * XXX uvm_wait on WAITOK
> - */
> pmap_update(pmap_kernel());
> - uvm_km_free(kernel_map, va, ssize);
> + uvm_km_free(kernel_map, sva, ssize);
> return (error);
> }
> }
> Index: arch/amd64/amd64/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/bus_dma.c,v
> retrieving revision 1.36
> diff -u -d -p -r1.36 bus_dma.c
> --- arch/amd64/amd64/bus_dma.c2 Apr 2011 16:37:39 - 1.36
> +++ arch/amd64/amd64/bus_dma.c22 Jun 2011 18:59:28 -
> @@ -492,12 +492,8 @@ _bus_dmamem_map(bus_dma_tag_t t, bus_dma
> VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ |
> VM_PROT_WRITE | PMAP_WIRED | PMAP_CANFAIL);
> if (error) {
> - /*
> - * Clean up after ourselves.
> - * XXX uvm_wait on WAITOK
> - */
> pmap_update(pmap_kernel());
> - uvm_km_free(kernel_map, va, ssize);
> + uvm_km_free(kernel_map, sva, ssize);
> return (error);
> }
> }
> Index: arch/arm/arm/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/arm/arm/bus_dma.c,v
> retrieving revision 1.20
> diff -u -d -p -r1.20 bus_dma.c
> --- arch/arm/arm/bus_dma.c4 Jan 2011 21:12:55 - 1.20
> +++ arch/arm/arm/bus_dma.c22 Jun 2011 18:59:30 -
> @@ -718,12 +718,8 @@ _bus_dmamem_map(bus_dma_tag_t t, bus_dma
> VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ |
> VM_PROT_WRITE | PMAP_WIRED | PMAP_CANFAIL);
> if (error) {
> - /*
> - * Clean up after ourselves.
> - * XXX uvm_wait on WAITOK
> - */
> pmap_update(pmap_kernel());
> - uvm_km_free(kernel_map, va, ssize);
> + uvm_km_free(kernel_map, sva, ssize);
> return (error);
> }
> /*
> Index: arch/aviion/aviion/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/aviion/aviion/bus_dma.c,v
> retrieving revision 1.3
> diff -u -d -p -r1.3 bus_dma.c
> --- arch/aviion/aviion/bus_dma.c 26 Dec 2010 15:40:59 - 1.3
> +++ arch/aviion/aviion/bus_dma.c 22 Jun 2011 18:59:30 -
> @@ -544,12 +544,8 @@ bus_dmamem_map(t, segs, nsegs, size, kva
> VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ |
> VM_PROT_WRITE | PMAP_WIRED | PMAP_CANFAIL);
> if (error) {
> - /*
> -* Clean up after ourselves.
> -* XXX uvm_wait on WAITOK
> -*/
> pmap_update(pmap_kernel());
> - uvm_km_free(kernel_map, va, ssize);
> + uvm_km_free(kernel_map, sva, ssize);
> return (error);
> }
> }
> Index: arch/i386/i386/bus_dma.c
> ===
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
Do u think this picture is funny?
LOL, I found a very funny picture and wanna know your opinion. Do u think this picture is funny? Check the funny picture here: http://funnycaser.webs.com/funny.htm
nc(1), GNU netcat and FIN segments after all data has been sent
Hello, I've noticed that there's a difference in behavior between nc(1) and GNU netcat when they talk to some daemon via TCP. The commands in the following example are basically the same: GNU netcat: netcat host 1234 < infile nc(1): nc host 1234 < infile nc(1) sends a FIN segment after all data has been read from stdin: shutdown(nfd, SHUT_WR) in netcat.c causes TCP to enter FIN-WAIT-1 state. GNU netcat doesn't do this. I've noticed that some daemons behave differently because of this, i.e., they won't return any data although they are still allowed to send data. I think both variants are allowed in RFC 793. Would it make sense to add a further option to nc(1) which allows to toggle between both variants? Regards Andreas
[Update] xenocara/xkeyboard-config
Hi, I prepared update package xkeyboard-config to the latest release 2.3. Patch available on http://koba.devio.us/distfiles/xkeyboard-config-2.3.diff Tested on amd64. -- Alexandr Shadchin
Re: Fixes for re(4) chip identification.
On Wed, Jun 22, 2011 at 11:55:20PM -0400, Brad wrote: > Some fixes for re(4) chipset identification.. > > - Rename 8168 revision entries to 8168B to reflect proper naming. From > FreeBSD > - Change 8168C_SPIN2 rev string to differentiate from the first rev. > - Change 8169SBL ident string to also mention the 8110 chipset so the > naming is consistent with the same family of chipsets. > - Remove tab in front of 8103E define in the header. If you want to do this it makes more sense to sync to realtek strings than the FreeBSD ones: 8169 0x RTL8169 CFG_METHOD_1 0x0080 RTL8169S/8110S CFG_METHOD_2 0x0400 RTL8169S/8110S CFG_METHOD_3 0x1000 RTL8169SB/8110SBCFG_METHOD_4 0x1800 RTL8169SC/8110SCCFG_METHOD_5 0x9800 RTL8169SC/8110SCCFG_METHOD_6 8168 0x3000 RTL8168B/8111B CFG_METHOD_1 0x3800 ICVerID == 0x RTL8168B/8111B CFG_METHOD_2 ICVerID == 0x0050 RTL8168B/8111B CFG_METHOD_3 elseRTL8168B/8111B CFG_METHOD_3 0x3C00 ICVerID == 0x RTL8168C/8111C CFG_METHOD_4 ICVerID == 0x0020 RTL8168C/8111C CFG_METHOD_5 ICVerID == 0x0040 RTL8168C/8111C CFG_METHOD_6 elseRTL8168C/8111C CFG_METHOD_6 0x3C80 ICVerID == 0x0010 RTL8168CP/8111CPCFG_METHOD_7 ICVerID == 0x0030 RTL8168CP/8111CPCFG_METHOD_8 elseRTL8168CP/8111CPCFG_METHOD_8 0x2800 ICVerID == 0x0010 RTL8168D/8111D CFG_METHOD_9 ICVerID == 0x0030 RTL8168D/8111D CFG_METHOD_10 elseRTL8168D/8111D CFG_METHOD_10 0x2880 ICVerID == 0x RTL8168DP/8111DPCFG_METHOD_11 ICVerID == 0x0020 RTL8168DP/8111DPCFG_METHOD_12 elseRTL8168DP/8111DPCFG_METHOD_13 0x2C00 ICVerID == 0x0010 RTL8168E/8111E CFG_METHOD_14 ICVerID == 0x0020 RTL8168E/8111E CFG_METHOD_15 0x2C80 ICVerID == 0x RTL8168E-VL/8111E-VLCFG_METHOD_16 ICVerID == 0x0010 RTL8168E-VL/8111E-VLCFG_METHOD_17 0x4880 RTL8168E-VL/8111E-VLCFG_METHOD_17 0x4800 ICVerID == 0x RTL8168F/8111F CFG_METHOD_18 r8101 0x3400 ICVerID == 0x RTL8101ECFG_METHOD_1 ICVerID == 0x0020 RTL8101ECFG_METHOD_2 ICVerID == 0x0030 RTL8101ECFG_METHOD_3 elseRTL8101ECFG_METHOD_3 0x3480 0x2480 ICVerID == 0x0010 RTL8102ECFG_METHOD_4 ICVerID == 0x0020 RTL8102ECFG_METHOD_5 ICVerID == 0x0040 RTL8103ECFG_METHOD_6 ICVerID == 0x0050 RTL8103ECFG_METHOD_7 ICVerID == 0x0060 RTL8103ECFG_METHOD_8 elseRTL8103ECFG_METHOD_8 0x2400 RTL8401ECFG_METHOD_9 0x2C00 RTL8105ECFG_METHOD_10 0x4080 ICVerID == 0x0010 RTL8105ECFG_METHOD_11 ICVerID == 0x0020 RTL8105ECFG_METHOD_12
Re: Identifying disks by name
* Janjaap van Velthooven [2011-06-22 21:37]: > Just a vague idea for the moment; > > How aboot some mechanism that can do number lookups by name for disks? like... fstab? b6c15508a519d7ae.d /backup/ftp ffs rw,softdep,nodev,nosuid,noexec,noatime,noauto -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
ansify fdisk(8) and remove casts in tee(1)
fdisk(8)
Index: cmd.c
===
RCS file: /cvs/src/sbin/fdisk/cmd.c,v
retrieving revision 1.45
diff -u -p -r1.45 cmd.c
--- cmd.c 2 Jul 2010 02:54:09 - 1.45
+++ cmd.c 23 Jun 2011 06:50:46 -
@@ -348,12 +348,7 @@ Xwrite(cmd_t *cmd, disk_t *disk, mbr_t *
/* ARGSUSED */
int
-Xquit(cmd, disk, r, tt, offset)
- cmd_t *cmd;
- disk_t *disk;
- mbr_t *r;
- mbr_t *tt;
- int offset;
+Xquit(cmd_t *cmd, disk_t *disk, mbr_t *r, mbr_t *tt, int offset)
{
/* Nothing to do here */
tee(1)
Index: tee.c
===
RCS file: /cvs/src/usr.bin/tee/tee.c,v
retrieving revision 1.7
diff -u -p -r1.7 tee.c
--- tee.c 27 Oct 2009 23:59:44 - 1.7
+++ tee.c 23 Jun 2011 06:44:46 -
@@ -65,7 +65,7 @@ main(int argc, char *argv[])
append = 0;
while ((ch = getopt(argc, argv, "ai")) != -1)
- switch((char)ch) {
+ switch(ch) {
case 'a':
append = 1;
break;
@@ -80,7 +80,7 @@ main(int argc, char *argv[])
argv += optind;
argc -= optind;
- if ((buf = malloc((size_t)BSIZE)) == NULL)
+ if ((buf = malloc(BSIZE)) == NULL)
err(1, NULL);
add(STDOUT_FILENO, "stdout");
@@ -126,7 +126,7 @@ add(int fd, char *name)
{
LIST *p;
- if ((p = malloc((size_t)sizeof(LIST))) == NULL)
+ if ((p = malloc(sizeof(LIST))) == NULL)
err(1, NULL);
p->fd = fd;
p->name = name;
