1. 07 1月, 2012 1 次提交
  2. 15 10月, 2011 1 次提交
  3. 22 7月, 2011 1 次提交
  4. 15 1月, 2011 1 次提交
  5. 18 10月, 2010 1 次提交
  6. 31 7月, 2010 1 次提交
    • M
      x86/PCI: Add option to not assign BAR's if not already assigned · 7bd1c365
      Mike Habeck 提交于
      The Linux kernel assigns BARs that a BIOS did not assign, most likely
      to handle broken BIOSes that didn't enumerate the devices correctly.
      On UV the BIOS purposely doesn't assign I/O BARs for certain devices/
      drivers we know don't use them (examples, LSI SAS, Qlogic FC, ...).
      We purposely don't assign these I/O BARs because I/O Space is a very
      limited resource.  There is only 64k of I/O Space, and in a PCIe
      topology that space gets divided up into 4k chucks (this is due to
      the fact that a pci-to-pci bridge's I/O decoder is aligned at 4k)...
      Thus a system can have at most 16 cards with I/O BARs: (64k / 4k = 16)
      
      SGI needs to scale to >16 devices with I/O BARs.  So by not assigning
      I/O BARs on devices we know don't use them, we can do that (iff the
      kernel doesn't go and assign these BARs that the BIOS purposely didn't
      assign).
      
      This patch will not assign a resource to a device BAR if that BAR was
      not assigned by the BIOS, and the kernel cmdline option 'pci=nobar'
      was specified.   This patch is closely modeled after the 'pci=norom'
      option that currently exists in the tree.
      Signed-off-by: NMike Habeck <habeck@sgi.com>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      7bd1c365
  7. 12 5月, 2010 1 次提交
  8. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  9. 24 2月, 2010 1 次提交
  10. 20 2月, 2010 1 次提交
    • T
      x86: Move pci init function to x86_init · b72d0db9
      Thomas Gleixner 提交于
      The PCI initialization in pci_subsys_init() is a mess. pci_numaq_init,
      pci_acpi_init, pci_visws_init and pci_legacy_init are called and each
      implementation checks and eventually modifies the global variable
      pcibios_scanned.
      
      x86_init functions allow us to do this more elegant. The pci.init
      function pointer is preset to pci_legacy_init. numaq, acpi and visws
      can modify the pointer in their early setup functions. The functions
      return 0 when they did the full initialization including bus scan. A
      non zero return value indicates that pci_legacy_init needs to be
      called either because the selected function failed or wants the
      generic bus scan in pci_legacy_init to happen (e.g. visws).
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <43F901BD926A4E43B106BF17856F07559FB80CFE@orsmsx508.amr.corp.intel.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      b72d0db9
  11. 05 11月, 2009 2 次提交
    • D
      x86/PCI: Use generic cacheline sizing instead of per-vendor tests. · 76b1a87b
      Dave Jones 提交于
      Instead of the PCI code needing to have code to determine the
      cacheline size of each processor, use the data the cpu identification
      code should have already determined during early boot.
      
      (The vendor checks are also incomplete, and don't take into account
       modern CPUs)
      
      I've been carrying a variant of this code in Fedora for a while,
      that prints debug information.  There are a number of cases where we
      are currently setting the PCI cacheline size to 32 bytes, when the CPU
      cacheline size is 64 bytes.  With this patch, we set them both the same.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      76b1a87b
    • J
      PCI: determine CLS more intelligently · ac1aa47b
      Jesse Barnes 提交于
      Till now, CLS has been determined either by arch code or as
      L1_CACHE_BYTES.  Only x86 and ia64 set CLS explicitly and x86 doesn't
      always get it right.  On most configurations, the chance is that
      firmware configures the correct value during boot.
      
      This patch makes pci_init() determine CLS by looking at what firmware
      has configured.  It scans all devices and if all non-zero values
      agree, the value is used.  If none is configured or there is a
      disagreement, pci_dfl_cache_line_size is used.  arch can set the dfl
      value (via PCI_CACHE_LINE_BYTES or pci_dfl_cache_line_size) or
      override the actual one.
      
      ia64, x86 and sparc64 updated to set the default cls instead of the
      actual one.
      
      While at it, declare pci_cache_line_size and pci_dfl_cache_line_size
      in pci.h and drop private declarations from arch code.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NDavid Miller <davem@davemloft.net>
      Acked-by: NGreg KH <gregkh@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      ac1aa47b
  12. 19 9月, 2009 1 次提交
    • J
      x86/PCI: make 32 bit NUMA node array int, not unsigned char · 76baeebf
      Jesse Barnes 提交于
      We use -1 to indicate no node affinity, so we need a signed type here or
      all sorts of bad things happen, like crashes in dev_attr_show as
      reported by Ingo:
      
      [  158.058140] warning: `dbus-daemon' uses 32-bit capabilities (legacy support in use)
      [  159.370562] BUG: unable to handle kernel NULL pointer dereference at (null)
      [  159.372694] IP: [<ffffffff8143b722>] bitmap_scnprintf+0x72/0xd0
      [  159.372694] PGD 71d3e067 PUD 7052e067 PMD 0
      [  159.372694] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [  159.372694] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/local_cpus
      [  159.372694] CPU 0
      [  159.372694] Pid: 7364, comm: irqbalance Not tainted 2.6.31-tip #8043 System Product Name
      [  159.372694] RIP: 0010:[<ffffffff8143b722>]  [<ffffffff8143b722>] bitmap_scnprintf+0x72/0xd0
      [  159.372694] RSP: 0018:ffff8800712a1e38  EFLAGS: 00010246
      [  159.372694] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [  159.372694] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff880077dc5000
      [  159.372694] RBP: ffff8800712a1e68 R08: 0000000000000001 R09: 0000000000000001
      [  159.372694] R10: ffffffff8215c47c R11: 0000000000000000 R12: 0000000000000000
      [  159.372694] R13: 0000000000000000 R14: 0000000000000ffe R15: ffff880077dc5000
      [  159.372694] FS:  00007f5f578f76f0(0000) GS:ffff880007000000(0000) knlGS:0000000000000000
      [  159.372694] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  159.372694] CR2: 0000000000000000 CR3: 0000000071a77000 CR4: 00000000000006f0
      [  159.372694] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  159.372694] DR3: ffffffff835109dc DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  159.372694] Process irqbalance (pid: 7364, threadinfo ffff8800712a0000, task ffff880070773000)
      [  159.372694] Stack:
      [  159.372694]  2222222222222222 ffff880077dc5000 fffffffffffffffb ffff88007d366b40
      [  159.372694] <0> ffff8800712a1f48 ffff88007d3840a0 ffff8800712a1e88 ffffffff8146332b
      [  159.372694] <0> fffffffffffffff4 ffffffff82450718 ffff8800712a1ea8 ffffffff815a9a1f
      [  159.372694] Call Trace:
      [  159.372694]  [<ffffffff8146332b>] local_cpus_show+0x3b/0x60
      [  159.372694]  [<ffffffff815a9a1f>] dev_attr_show+0x2f/0x60
      [  159.372694]  [<ffffffff8118ee6f>] sysfs_read_file+0xbf/0x1d0
      [  159.372694]  [<ffffffff8112afe9>] vfs_read+0xc9/0x180
      [  159.372694]  [<ffffffff8112c365>] sys_read+0x55/0x90
      [  159.372694]  [<ffffffff810114f2>] system_call_fastpath+0x16/0x1b
      [  159.372694] Code: 41 b9 01 00 00 00 44 8d 46 03 49 63 fc 0f 49 d3 c1 f8 1f 4c 01 ff c1 e8 1a c1 fa 06 41 c1 e8 02 8d 0c 03 48 63 d2 83 e1 3f 29 c1 <49> 8b 44 d5 00 48 c7 c2 8c 37 16 82 48 d3 e8 89 f1 44 89 f6 49
      [  159.372694] RIP  [<ffffffff8143b722>] bitmap_scnprintf+0x72/0xd0
      [  159.372694]  RSP <ffff8800712a1e38>
      [  159.372694] CR2: 0000000000000000
      [  159.600828] ---[ end trace 35550c356e84e60c ]---
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      76baeebf
  13. 10 9月, 2009 1 次提交
    • J
      x86/PCI: initialize PCI bus node numbers early · 2547089c
      Jesse Barnes 提交于
      The current mp_bus_to_node array is initialized only by AMD specific
      code, since AMD platforms have registers that can be used for
      determining mode numbers.  On new Intel platforms it's necessary to
      initialize this array as well though, otherwise all PCI node numbers
      will be 0, when in fact they should be -1 (indicating that I/O isn't
      tied to any particular node).
      
      So move the mp_bus_to_node code into the common PCI code, and
      initialize it early with a default value of -1.  This may be overridden
      later by arch code (e.g. the AMD code).
      
      With this change, PCI consistent memory and other node specific
      allocations (e.g. skbuff allocs) should occur on the "current" node.
      If, for performance reasons, applications want to be bound to specific
      nodes, they should open their devices only after being pinned to the
      CPU where they'll run, for maximum locality.
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Tested-by: NJesse Brandeburg <jesse.brandeburg@gmail.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2547089c
  14. 25 6月, 2009 1 次提交
  15. 12 6月, 2009 1 次提交
  16. 23 4月, 2009 2 次提交
  17. 12 3月, 2009 1 次提交
  18. 08 1月, 2009 2 次提交
  19. 30 12月, 2008 1 次提交
  20. 19 7月, 2008 1 次提交
    • S
      x86, pci: introduce config option for pci reroute quirks (was: [PATCH 0/3]... · 41b9eb26
      Stefan Assmann 提交于
      x86, pci: introduce config option for pci reroute quirks (was: [PATCH 0/3] Boot IRQ quirks for Broadcom and AMD/ATI)
      
      This is against linux-2.6-tip, branch pci-ioapic-boot-irq-quirks.
      
      From: Stefan Assmann <sassmann@suse.de>
      Subject: Introduce config option for pci reroute quirks
      
      The config option X86_REROUTE_FOR_BROKEN_BOOT_IRQS is introduced to
      enable (or disable) the redirection of the interrupt handler to the boot
      interrupt line by default. Depending on the existence of interrupt
      masking / threaded interrupt handling in the kernel (vanilla, rt, ...)
      and the maturity of the rerouting patch, users can enable or disable the
      redirection by default.
      
      This means that the reroute quirk can be applied to any kernel without
      changing it.
      
      Interrupt sharing could be increased if this option is enabled. However this
      option is vital for threaded interrupt handling, as done by the RT kernel.
      It should simplify the consolidation with the RT kernel.
      
      The option can be overridden by either pci=ioapicreroute or
      pci=noioapicreroute.
      Signed-off-by: NStefan Assmann <sassmann@suse.de>
      Signed-off-by: NOlaf Dabrunz <od@suse.de>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Jon Masters <jonathan@jonmasters.org>
      Cc: Ihno Krumreich <ihno@suse.de>
      Cc: Sven Dietrich <sdietrich@suse.de>
      Cc: Daniel Gollub <dgollub@suse.de>
      Cc: Felix Foerster <ffoerster@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      41b9eb26
  21. 15 7月, 2008 1 次提交
  22. 09 7月, 2008 1 次提交
    • R
      x86/pci: removing subsys_initcall ordering dependencies · 8dd779b1
      Robert Richter 提交于
      So far subsys_initcalls has been executed in this order depending on
      the object order in the Makefile:
      
      arch/x86/pci/visws.c:subsys_initcall(pcibios_init);
      arch/x86/pci/numa.c:subsys_initcall(pci_numa_init);
      arch/x86/pci/acpi.c:subsys_initcall(pci_acpi_init);
      arch/x86/pci/legacy.c:subsys_initcall(pci_legacy_init);
      arch/x86/pci/irq.c:subsys_initcall(pcibios_irq_init);
      arch/x86/pci/common.c:subsys_initcall(pcibios_init);
      
      This patch removes the ordering dependency. There is now only one
      subsys_initcall function that contains subsystem initialization code
      with a defined order.
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8dd779b1
  23. 08 7月, 2008 3 次提交
  24. 11 6月, 2008 2 次提交
    • Y
      PCI/x86: early dump pci conf space v2 · e3f2baeb
      Yinghai Lu 提交于
      Allows us to dump PCI space before any kernel changes have been made.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      e3f2baeb
    • G
      PCI: boot parameter to avoid expansion ROM memory allocation · bb71ad88
      Gary Hade 提交于
      Contention for scarce PCI memory resources has been growing
      due to an increasing number of PCI slots in large multi-node
      systems.  The kernel currently attempts by default to
      allocate memory for all PCI expansion ROMs so there has
      also been an increasing number of PCI memory allocation
      failures seen on these systems.  This occurs because the
      BIOS either (1) provides insufficient PCI memory resource
      for all the expansion ROMs or (2) provides adequate PCI
      memory resource for expansion ROMs but provides the
      space in kernel unexpected BIOS assigned P2P non-prefetch
      windows.
      
      The resulting PCI memory allocation failures may be benign
      when related to memory requests for expansion ROMs themselves
      but in some cases they can occur when attempting to allocate
      space for more critical BARs.  This can happen when a successful
      expansion ROM allocation request consumes memory resource
      that was intended for a non-ROM BAR.  We have seen this
      happen during PCI hotplug of an adapter that contains a
      P2P bridge where successful memory allocation for an
      expansion ROM BAR on device behind the bridge consumed
      memory that was intended for a non-ROM BAR on the P2P bridge.
      In all cases the allocation failure messages can be very
      confusing for users.
      
      This patch provides a new 'pci=norom' kernel boot parameter
      that can be used to disable the default PCI expansion ROM memory
      resource allocation.  This provides a way to avoid the above
      described issues on systems that do not contain PCI devices
      for which drivers or user-level applications depend on the
      default PCI expansion ROM memory resource allocation behavior.
      Signed-off-by: NGary Hade <garyhade@us.ibm.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      bb71ad88
  25. 23 5月, 2008 1 次提交
    • T
      PCI: Correct last two HP entries in the bfsort whitelist · a1676072
      Tony Camuso 提交于
      Greetings.
      
      There is a code flaw in the bfsort whitelist, where there are redundant
      entries for the same two HP systems, DL385 G2 and DL585 G2. This patch
      replaces those redundant entries with the correct ones. The correct
      entries are for large-volume systems, the DL360 and DL380.
      
      -----------------------------------------------------------------------
      
      commit ec69f0374c3b0ad7ea991b0e9ac00377acfe5b1a
      Author: Tony Camuso <tony.camuso@hp.com>
      Date:   Wed May 14 07:09:28 2008 -0400
      
           Replace Redundant Whitelist Entries with the Correct Ones
      
           The ProLiant DL585 G2 and the DL585 G2 are entered reundantly
           in the dmi_system_id table. What should have been there are the
           DL360 and DL380. This patch simply replaces the redundant
           entries with the correct entries.
      
       arch/x86/pci/common.c |    8 ++++----
       1 file changed, 4 insertions(+), 4 deletions(-)
      Signed-off-by: NTony Camuso <tony.camuso@hp.com>
      Signed-off-by: NPat Schoeller <patrick.schoeller@hp.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      a1676072
  26. 20 5月, 2008 1 次提交
  27. 09 5月, 2008 1 次提交
  28. 06 5月, 2008 2 次提交
  29. 30 4月, 2008 1 次提交
    • S
      x86: fix section mismatch in pci_scan_bus · 98db6f19
      Sam Ravnborg 提交于
      Fix following section mismatch warning:
      WARNING: vmlinux.o(.text+0x275616): Section mismatch in reference from the function pci_scan_bus() to the function .devinit.text:pci_scan_bus_parented()
      
      The warning was seen with a CONFIG_DEBUG_SECTION_MISMATCH=y build.
      The inline function pci_scan_bus refer to functions annotated
      __devinit - so annotate it __devinit too.
      This revealed a few x86 specific functions that were only
      used from __init or __devinit context.
      So annotate these __devinit and the warning was killed.
      
      The added include in pci.h was not strictly required but
      added to avoid being dependent on indirect includes.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NJesse Barnes <jbarnes@hobbes.lan>
      98db6f19
  30. 27 4月, 2008 2 次提交
    • Y
      x86: add pci=check_enable_amd_mmconf and dmi check · 5f0b2976
      Yinghai Lu 提交于
      so will disable that feature by default, and only enable that via
      pci=check_enable_amd_mmconf or for system match with dmi table.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5f0b2976
    • Y
      x86: get mp_bus_to_node early · 871d5f8d
      Yinghai Lu 提交于
      Currently, on an amd k8 system with multi ht chains, the numa_node of
      pci devices under /sys/devices/pci0000:80/* is always 0, even if that
      chain is on node 1 or 2 or 3.
      
      Workaround: pcibus_to_node(bus) is used when we want to get the node that
      pci_device is on.
      
      In struct device, we already have numa_node member, and we could use
      dev_to_node()/set_dev_node() to get and set numa_node in the device.
      set_dev_node is called in pci_device_add() with pcibus_to_node(bus),
      and pcibus_to_node uses bus->sysdata for nodeid.
      
      The problem is when pci_add_device is called, bus->sysdata is not assigned
      correct nodeid yet. The result is that numa_node will always be 0.
      
      pcibios_scan_root and pci_scan_root could take sysdata. So we need to get
      mp_bus_to_node mapping before these two are called, and thus
      get_mp_bus_to_node could get correct node for sysdata in root bus.
      
      In scanning of the root bus, all child busses will take parent bus sysdata.
      So all pci_device->dev.numa_node will be assigned correctly and automatically.
      
      Later we could use dev_to_node(&pci_dev->dev) to get numa_node, and we
      could also could make other bus specific device get the correct numa_node
      too.
      
      This is an updated version of pci_sysdata and Jeff's pci_domain patch.
      
      [ mingo@elte.hu: build fix ]
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      871d5f8d
  31. 21 4月, 2008 2 次提交
新手
引导
客服 返回
顶部