LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Linux 2.6.20-rc7
@ 2007-01-31  4:28 Linus Torvalds
       [not found] ` <45C05150.6000802@agmk.net>
                   ` (6 more replies)
  0 siblings, 7 replies; 61+ messages in thread
From: Linus Torvalds @ 2007-01-31  4:28 UTC (permalink / raw)
  To: Linux Kernel Mailing List


Yes, I know I said I would only do -rc6 and then the final 2.6.20, but the 
thing is, the known regressions list didn't get whittled down as quickly 
as I hoped, and as a result we now have a -rc7.

It's in good enough shape that I'd probably have been happy to just 
release it as 2.6.20, but since I want 2.6.20 to be a stability release, I 
didn't want to risk any stupid bugs while the regressions got fixed, so 
here's a final -rc7.

In other words, please do give it a good testing. We should have fixed the 
nasty stuff on Adrian's list (and here's another thanks to Adrian for 
keeping me on my toes!) and it's all good. But please give it a quick 
shake-down to make sure that nothing silly happened while fixing the bad 
stuff.

The shortlog really does say most of it - this is just various fixes for a 
number of mostly fairly inconsequential things, but the SG_IO timeout bug 
that hit any NeroLinux user would quite possibly impact other DVD/CD 
reader/writer programs too that used raw commands with timeouts.

The diffstat just looks like line-noise: 244 files changed with an average 
of less than 10 lines per file changed in 179 commits. In other words, 
really no big diffs: it's just a lot of really small stuff.

		Linus

---
Adam Litke (1):
      Don't allow the stack to grow into hugetlb reserved regions

Adrian Bunk (1):
      fs/lockd/clntlock.c: add missing newlines to dprintk's

Ahmed S. Darwish (1):
      [CPUFREQ] check sysfs_create_link return value

Al Viro (9):
      b44: src_desc->addr is little-endian
      missing exports of pm_power_off() on alpha and sparc32
      mtd/nand/cafe.c missing include of dma-mapping.h
      sym53c500_cs: remove bogus call fo free_dma()
      pata_platform: fallout from set_mode() change
      missing dma_sync_single_range_for{cpu,device} on alpha
      dma-mapping.h stubs fix
      b44: src_desc->addr is little-endian
      fix indentation-related breakage in Kconfig.i386

Alan Cox (5):
      ide/generic: Jmicron has its own drivers now
      libata cmd64x: whack into a shape that looks like the documentation
      libata hpt3xn: Hopefully sort out the DPLL logic versus the vendor code
      libata: set_mode, Fix the FIXME
      libata-sff: Don't call bmdma_stop on non DMA capable controllers

Alexey Dobriyan (2):
      Fix NULL ->nsproxy dereference in /proc/*/mounts
      core-dumping unreadable binaries via PT_INTERP

Andrew Morton (5):
      jmicron: fix warning
      pata_platform: set_mode fix
      82596 warning fixes
      m68k: uaccess.h needs sched.h
      ntfs: kmap_atomic() atomicity fix

Andrew Victor (6):
      [ARM] 4084/1: Remove CONFIG_DEBUG_WAITQ
      [ARM] 4085/1: AT91: Header fixes.
      [ARM] 4086/1: AT91: Whitespace cleanup
      [ARM] 4087/1: AT91: CPU reset for SAM9x processors
      [ARM] 4088/1: AT91: Unbalanced IRQ in serial driver suspend/resume
      [ARM] 4089/1: AT91: GPIO wake IRQ cleanup

Andy Gospodarek (1):
      bonding: ARP monitoring broken on x86_64

Atsushi Nemoto (1):
      SPI: alternative fix for spi_busnum_to_master

Auke Kok (1):
      e100: fix irq leak on suspend/resume

Avi Kivity (3):
      KVM: Emulate IA32_MISC_ENABLE msr
      KVM: MMU: Perform access checks in walk_addr()
      KVM: MMU: Report nx faults to the guest

Bartlomiej Zolnierkiewicz (3):
      ide: update MAINTAINERS entry
      ia64: add pci_get_legacy_ide_irq()
      ide: add missing __init tags to IDE PCI host drivers

Baruch Even (1):
      [TCP]: Fix sorting of SACK blocks.

Ben Dooks (4):
      [ARM] 4095/1: S3C24XX: Fix GPIO set for Bank A
      [ARM] 4096/1: S3C24XX: change return code form s3c2410_gpio_getcfg()
      S3C24XX: fix passing spi chipselect to select routine
      [ARM] 4117/1: S3C2412: Fix writel() usage in selection code

Benjamin Herrenschmidt (1):
      [POWERPC] Fix sys_pciconfig_iobase bus matching

Catalin Marinas (2):
      [ARM] 4112/1: Only ioremap to supersections if DOMAIN_IO is zero
      [ARM] 4111/1: Allow VFP to work with thread migration on SMP

Conke Hu (3):
      atiixp.c: remove unused code
      atiixp.c: sb600 ide only has one channel
      atiixp.c: add cable detection support for ATI IDE

Dan Williams (1):
      [ARM] 4100/1: iop3xx: fix cpu mask for iop333

Dave Jones (5):
      [AGPGART] Prevent (unlikely) memory leak in amd_create_gatt_pages()
      [AGPGART] Remove pointless typedef in ati-agp
      [AGPGART] Remove pointless assignment.
      [AGPGART] Add new IDs to VIA AGP.
      [CPUFREQ] Remove unneeded errata workaround from p4-clockmod.

David Barksdale (1):
      IPMI: fix timeout list handling

David Milburn (1):
      libata-scsi: ata_task_ioctl should return ATA registers from sense data

David S. Miller (4):
      [AF_PACKET]: Fix BPF handling.
      [AF_PACKET]: Check device down state before hard header callbacks.
      [TCP]: Restore SKB socket owner setting in tcp_transmit_skb().
      [SPARC64]: Set g4/g5 properly in sun4v dtlb-prot handling.

David Woodhouse (1):
      Fix Maple PATA IRQ assignment.

Dmitriy Monakhov (1):
      Broadcom 4400 resume small fix

Eric Van Hensbergen (5):
      9p: fix bogus return code checks during initialization
      9p: fix rename return code
      9p: update documentation regarding server applications
      9p: fix segfault caused by race condition in meta-data operations
      9p: null terminate error strings for debug print

Eric W. Biederman (3):
      [IPV4]: Fix the fib trie iterator to work with a single entry routing tables
      [DECNET]: Handle a failure in neigh_parms_alloc (take 2)
      i386: In assign_irq_vector look at all vectors before giving up

Evgeniy Dushistov (3):
      ufs: alloc metadata null page fix
      ufs: truncate negative to unsigned fix
      ufs: reallocation fix

Francois Romieu (1):
      netdev: add a MAINTAINERS entry for via-velocity and update my address

Geert Uytterhoeven (3):
      [POWERPC] PS3: Fix uniprocessor kernel build
      [POWERPC] ps3_free_io_irq: Fix inverted error check
      `make help' in build tree doesn't show headers_* targets

Geoff Levand (1):
      [POWERPC] PS3: add not complete comment to kconfig

H. Peter Anvin (1):
      Boot loader ID for Gujin

Haavard Skinnemoen (2):
      [AVR32] Export clear_page symbol
      [AVR32] Update ATSTK1000 defconfig: Enable macb by default

Hugh Dickins (1):
      mm: mremap correct rmap accounting

Ingo Molnar (1):
      ACPI: fix cpufreq regression

Jan Altenberg (1):
      Malta: Fix build if CONFIG_MTD is diabled.

Jan Engelhardt (1):
      cdev.h: forward declarations

Jean Delvare (1):
      Fix VIA quirks

Jeff Dike (2):
      Fix UML on non-standard VM split hosts
      uml: fix signal frame alignment

Jiri Kosina (3):
      HID: fix memleaking of collection
      USB HID: fix hid_blacklist clash for 0x08ca/0x0010
      HID: fix pb_fnmode and move it to generic HID

Joerg Roedel (1):
      KVM: SVM: Propagate cpu shutdown events to userspace

Johannes Stezenbach (1):
      uml: fix mknod

Josepch Chan (1):
      via82cxxx/pata_via: correct PCI_DEVICE_ID_VIA_SATA_EIDE ID and add support for CX700 and 8237S

Jun'ichi Nomura (1):
      dm-multipath: fix stall on noflush suspend/resume

Justin Clacherty (1):
      spi: fix error setting the spi mode in pxa2xx_spi.c

Lennert Buytenhek (1):
      ata_if_xfermask() word 51 fix

Leonard Norrgard (1):
      KVM: SVM: Fix SVM idt confusion

Linus Torvalds (6):
      Resurrect 'try_to_free_buffers()' VM hackery
      Write back inode data pages even when the inode itself is locked
      Fix balance_dirty_page() calculations with CONFIG_HIGHMEM
      Revert "[PATCH] namespaces: fix exit race by splitting exit"
      Revert "net: ifb error path loop fix"
      Linux 2.6.20-rc7

Linus Walleij (1):
      [ARM] 4102/1: Allow for PHYS_OFFSET on any valid 2MiB address

Mariusz Kozlowski (1):
      net: ifb error path loop fix

Mark Fasheh (1):
      ocfs2: fix thinko in ocfs2_backup_super_blkno()

Masami Hiramatsu (1):
      kprobes: replace magic numbers with enum

Matt Domsch (1):
      Fix race in efi variable delete code

Matt Reimer (1):
      [ARM] 4106/1: S3C2410: typo fixes in register definitions

Michael Chan (2):
      [BNX2]: Fix 2nd port's MAC address.
      b44: Fix frequent link changes

Mike Christie (1):
      Fix SG_IO timeout jiffy conversion

Mike Frysinger (4):
      remove __devinit markings from rtc_sysfs_add_device()
      use __u8/__u32 in userspace ioctl defines for I2O
      use __u8 rather than u8 in userspace SIZE defines in hdreg.h
      translate dashes in filenames for headers install

Miklos Szeredi (1):
      fuse: fix bug in control filesystem mount

Neil Brown (1):
      Remove warning: VFS is out of sync with lock manager

NeilBrown (12):
      knfsd: update email address and status for NFSD in MAINTAINERS
      knfsd: fix setting of ACL server versions
      knfsd: fix an NFSD bug with full sized, non-page-aligned reads
      knfsd: replace some warning ins nfsfh.h with BUG_ON or WARN_ON
      md: update email address and status for MD in MAINTAINERS
      md: make 'repair' actually work for raid1
      md: make sure the events count in an md array never returns to zero
      md: avoid reading past the end of a bitmap file
      knfsd: Fix type mismatch with filldir_t used by nfsd
      md: fix potential memalloc deadlock in md
      md: remove unnecessary printk when raid5 gets an unaligned read.
      knfsd: ratelimit some nfsd messages that are triggered by external events

Nick Piggin (1):
      Fix try_to_free_buffer() locking

Patrick McHardy (3):
      [NETFILTER]: nf_nat: fix ICMP translation with statically linked conntrack
      [NETFILTER]: nf_nat_pptp: fix expectation removal
      [NETFILTER]: nf_conntrack_pptp: fix NAT setup of expected GRE connections

Pavel Pisa (1):
      [ARM] 4092/1: i.MX/MX1 CPU Frequency scaling latency definition

Peter Staubach (1):
      knfsd: Don't mess with the 'mode' when storing a exclusive-create cookie

Ralf Baechle (1):
      [MIPS] Ocelot G: Fix a few misspellings of CONFIG_GALILEO_GT64240_ETH

Robert Hancock (1):
      libata: fix translation for START STOP UNIT

Robert Olsson (1):
      [IPV4]: Fix single-entry /proc/net/fib_trie output.

Robert P. J. Day (3):
      fix various kernel-doc in header files
      [MIPS] Fix typo of "CONFIG_MT_SMP".
      Fix "CONFIG_X86_64_" typo in drivers/kvm/svm.c

Roland McGrath (8):
      x86_64: fix put_user for 64-bit constant
      Fix CONFIG_COMPAT_VDSO
      Fix gate_vma.vm_flags
      Add VM_ALWAYSDUMP
      i386 vDSO: use VM_ALWAYSDUMP
      x86_64 ia32 vDSO: use VM_ALWAYSDUMP
      powerpc vDSO: use VM_ALWAYSDUMP
      x86_64 ia32 vDSO: define arch_vma_name

Russell King (3):
      [ARM] Fix show_mem() for discontigmem
      [ARM] Update mach-types
      [ARM] Fix AMBA serial drivers for non-first serial ports

Serge E. Hallyn (2):
      namespaces: fix exit race by splitting exit
      namespaces: fix task exit disaster

Sergei Shtylyov (1):
      pata_sil680: PIO1 taskfile transfers overclocking fix (repost)

Simon Bennett (1):
      HID: fix hid-input mapping for Firefly Mini Remote Control

Stephen Hemminger (1):
      sky2: revert IRQ dance on suspend/resume

Takashi Iwai (1):
      ALSA: Fix sysfs breakage

Tejun Heo (9):
      sata_via: don't diddle with ATA_NIEN in ->freeze
      ahci: improve and limit spurious interrupt messages, take#3
      libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli
      ahci: fix endianness in spurious interrupt message
      sata_via: style clean up, no indirect method call in LLD
      ahci: use 0x80 as wait stat value instead of 0xff
      ahci: port_no should be used when clearing IRQ in ahci_thaw()
      libata: fix ata_eh_suspend() return value
      ide: unregister idepnp driver on unload

Thomas Klein (2):
      ehea: Fixed wrong jumbo frames status query
      ehea: Fixed missing tasklet_kill() call

Tilman Schmidt (1):
      Gigaset ISDN driver error handling fixes

Trond Myklebust (1):
      MM: Remove [PATCH] invalidate_inode_pages2_range() debug

Venkat Yekkirala (1):
      [SELINUX]: Fix 2.6.20-rc6 build when no xfrm

Vitaly Bordug (1):
      FS_ENET: OF-related fixup for FEC and SCC MAC's

Wang Zhenyu (1):
      [AGPGART] intel_agp: restore graphics device's pci space early in resume

ethanhsiao@jmicron.com (1):
      jmicron: 40/80pin primary detection


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
       [not found] ` <45C05150.6000802@agmk.net>
@ 2007-01-31 16:04   ` Linus Torvalds
  2007-01-31 23:13     ` Andrew Morton
                       ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Linus Torvalds @ 2007-01-31 16:04 UTC (permalink / raw)
  To: PaweÅ Sikora
  Cc: Linux Kernel Mailing List, Christoph Hellwig, Pekka Enberg,
	Siddha, Suresh B, Martin Peschke, Andrew Morton, Adrian Bunk

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1078 bytes --]



On Wed, 31 Jan 2007, PaweÅ Sikora wrote:
> 
> The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
> 
> [ an oops inside kmem_get_pages ]
> http://bugzilla.kernel.org/show_bug.cgi?id=7889

Pabel, can you detail more exactly which kernels don't work, and which do?

>From bugzilla:

 - 2.6.18.x does work
 - 2.6.19.2 doesn't work.
 - what about plain 2.6.19?
 - can you please test some of the 2.6.19-rcX kernels? Especially 
   2.6.19-rc1 would be good to test.

Since it apparently already happens in 2.6.19 (but it would be really good 
to know exactly when it starts), and considering _where_ it happens, I'd 
be inclined to blame commit d2e7b7d0: "fix potential stack overflow in 
mm/slab.c" by Suresh. 

When do_tune_cpucache() is called at bootup, I'm not sure how safe it is 
to do the kzalloc() thing.

I've added a number of hopefully appropriate people to the Cc. Guys? 
Apparently it only happens with MEMORY_HOTPLUG (and possibly with just an 
SMP kernel on UP), which probably explains why it's been around without 
people really complaining very loudly. 

		Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* [PATCH] x86_64: Fix preprocessor condition
  2007-01-31  4:28 Linux 2.6.20-rc7 Linus Torvalds
       [not found] ` <45C05150.6000802@agmk.net>
@ 2007-01-31 17:11 ` Josef 'Jeff' Sipek
  2007-01-31 17:16   ` Andi Kleen
  2007-01-31 18:15 ` Linux 2.6.20-rc7 Sunil Naidu
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 61+ messages in thread
From: Josef 'Jeff' Sipek @ 2007-01-31 17:11 UTC (permalink / raw)
  To: linux-kernel; +Cc: torvalds, ak, Josef 'Jeff' Sipek

Signed-off-by: Josef 'Jeff' Sipek <jsipek@cs.sunysb.edu>
---
 include/asm-x86_64/io.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-x86_64/io.h b/include/asm-x86_64/io.h
index 6ee9fad..7d0b568 100644
--- a/include/asm-x86_64/io.h
+++ b/include/asm-x86_64/io.h
@@ -100,7 +100,7 @@ __OUTS(l)
 
 #define IO_SPACE_LIMIT 0xffff
 
-#if defined(__KERNEL__) && __x86_64__
+#if defined(__KERNEL__) && defined(__x86_64__)
 
 #include <linux/vmalloc.h>
 
-- 
1.5.0.rc1.g5355


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] x86_64: Fix preprocessor condition
  2007-01-31 17:11 ` [PATCH] x86_64: Fix preprocessor condition Josef 'Jeff' Sipek
@ 2007-01-31 17:16   ` Andi Kleen
  2007-01-31 17:40     ` Josef Sipek
  0 siblings, 1 reply; 61+ messages in thread
From: Andi Kleen @ 2007-01-31 17:16 UTC (permalink / raw)
  To: Josef 'Jeff' Sipek; +Cc: linux-kernel, torvalds


> -#if defined(__KERNEL__) && __x86_64__
> +#if defined(__KERNEL__) && defined(__x86_64__)

Undefined symbols are replaced with 0, so the old line was already ok.
	
-Andi

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: [PATCH] x86_64: Fix preprocessor condition
  2007-01-31 17:16   ` Andi Kleen
@ 2007-01-31 17:40     ` Josef Sipek
  0 siblings, 0 replies; 61+ messages in thread
From: Josef Sipek @ 2007-01-31 17:40 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Josef 'Jeff' Sipek, linux-kernel, torvalds

On Wed, Jan 31, 2007 at 06:16:02PM +0100, Andi Kleen wrote:
> 
> > -#if defined(__KERNEL__) && __x86_64__
> > +#if defined(__KERNEL__) && defined(__x86_64__)
> 
> Undefined symbols are replaced with 0, so the old line was already ok.

Fair enough, however sparse is not very happy about underfined symbols.

Jeff.

-- 
Reality is merely an illusion, albeit a very persistent one.
		- Albert Einstein

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-01-31  4:28 Linux 2.6.20-rc7 Linus Torvalds
       [not found] ` <45C05150.6000802@agmk.net>
  2007-01-31 17:11 ` [PATCH] x86_64: Fix preprocessor condition Josef 'Jeff' Sipek
@ 2007-01-31 18:15 ` Sunil Naidu
  2007-02-01  2:16 ` S.Çağlar Onur
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 61+ messages in thread
From: Sunil Naidu @ 2007-01-31 18:15 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On 1/31/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> It's in good enough shape that I'd probably have been happy to just
> release it as 2.6.20, but since I want 2.6.20 to be a stability release, I
> didn't want to risk any stupid bugs while the regressions got fixed, so
> here's a final -rc7.

It's a clean boot on my P4/HT with dmesg looks more sense (for me) !
Shall test more...


Linux version 2.6.20-rc7-Akula-II (root@Typhoon) (gcc version 4.1.1
20070105 (Red Hat 4.1.1-51)) #1 SMP Wed Jan 31 23:03:36 IST 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end:
000000000009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end:
00000000000a0000 type: 2
copy_e820_map() start: 00000000000e6000 size: 000000000001a000 end:
0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000001f62f800 end:
000000001f72f800 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000001f72f800 size: 0000000000000800 end:
000000001f730000 type: 4
copy_e820_map() start: 000000001f730000 size: 0000000000010000 end:
000000001f740000 type: 3
copy_e820_map() start: 000000001f740000 size: 00000000000b0000 end:
000000001f7f0000 type: 4
copy_e820_map() start: 000000001f7f0000 size: 0000000000010000 end:
000000001f800000 type: 2
copy_e820_map() start: 00000000e0000000 size: 0000000010000000 end:
00000000f0000000 type: 2
copy_e820_map() start: 00000000fed13000 size: 0000000000007000 end:
00000000fed1a000 type: 2
copy_e820_map() start: 00000000fed1c000 size: 0000000000084000 end:
00000000feda0000 type: 2
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001f72f800 (usable)
 BIOS-e820: 000000001f72f800 - 000000001f730000 (ACPI NVS)
 BIOS-e820: 000000001f730000 - 000000001f740000 (ACPI data)
 BIOS-e820: 000000001f740000 - 000000001f7f0000 (ACPI NVS)
 BIOS-e820: 000000001f7f0000 - 000000001f800000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fed13000 - 00000000fed1a000 (reserved)
 BIOS-e820: 00000000fed1c000 - 00000000feda0000 (reserved)
503MB LOWMEM available.
found SMP MP-table at 000ff780
Entering add_active_range(0, 0, 128815) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   128815
early_node_map[1] active PFN ranges
    0:        0 ->   128815
On node 0 totalpages: 128815
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 974 pages used for memmap
  Normal zone: 123745 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 ACPIAM                                ) @ 0x000f4eb0
ACPI: RSDT (v001 INTEL  D915GAV  0x20060222 MSFT 0x00000097) @ 0x1f730000
ACPI: FADT (v002 INTEL  D915GAV  0x20060222 MSFT 0x00000097) @ 0x1f730200
ACPI: MADT (v001 INTEL  D915GAV  0x20060222 MSFT 0x00000097) @ 0x1f730390
ACPI: MCFG (v001 INTEL  D915GAV  0x20060222 MSFT 0x00000097) @ 0x1f730400
ACPI: ASF! (v016 LEGEND I865PASF 0x00000001 INTL 0x02002026) @ 0x1f736050
ACPI: TCPA (v001 INTEL  TBLOEMID 0x00000001 MSFT 0x00000097) @ 0x1f7360f0
ACPI: WDDT (v001 INTEL  OEMWDDT  0x00000001 INTL 0x02002026) @ 0x1f736122
ACPI: DSDT (v001 INTEL  D915GAV  0x00000001 INTL 0x02002026) @ 0x00000000
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 20000000 (gap: 1f800000:c0800000)
Detected 3000.282 MHz processor.
Built 1 zonelists.  Total pages: 127809
Kernel command line: ro root=LABEL=/1 rhgb quiet
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0454000 soft=c0452000
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 504924k/515260k available (2060k kernel code, 9812k reserved,
1055k data, 244k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
    vmalloc : 0xe0000000 - 0xfffb5000   ( 511 MB)
    lowmem  : 0xc0000000 - 0xdf72f000   ( 503 MB)
      .init : 0xc0410000 - 0xc044d000   ( 244 kB)
      .data : 0xc030320b - 0xc040b0f4   (1055 kB)
      .text : 0xc0100000 - 0xc030320b   (2060 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6003.22 BogoMIPS (lpj=3001611)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 00100000 00000000 00000000
0000441d 00000000 00000000
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00100000 00000000 00003180
0000441d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 11k freed
ACPI: Core revision 20060707
CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01
Booting processor 1/1 eip 2000
CPU 1 irqstacks, hard=c0455000 soft=c0453000
Initializing CPU#1
Calibrating delay using timer specific routine.. 5999.31 BogoMIPS (lpj=2999656)
CPU: After generic identify, caps: bfebfbff 00100000 00000000 00000000
0000441d 00000000 00000000
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00100000 00000000 00003180
0000441d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01
Total of 2 processors activated (12002.53 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
migration_cost=5
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:00:02.0
PCI quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 0500-053f claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEGP._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: Power Resource [URP2] (off)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
pnp: 00:0b: ioport range 0x400-0x47f could not be reserved
pnp: 00:0b: ioport range 0x680-0x6ff has been reserved
pnp: 00:0b: ioport range 0x500-0x53f has been reserved
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: ffa00000-ffafffff
  PREFETCH window: cff00000-cfffffff
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: ff600000-ff6fffff
  PREFETCH window: cfb00000-cfbfffff
PCI: Bridge: 0000:00:1c.1
  IO window: disabled.
  MEM window: ff700000-ff7fffff
  PREFETCH window: cfc00000-cfcfffff
PCI: Bridge: 0000:00:1c.2
  IO window: disabled.
  MEM window: ff800000-ff8fffff
  PREFETCH window: cfd00000-cfdfffff
PCI: Bridge: 0000:00:1c.3
  IO window: disabled.
  MEM window: ff900000-ff9fffff
  PREFETCH window: cfe00000-cfefffff
PCI: Bridge: 0000:00:1e.0
  IO window: b000-bfff
  MEM window: ff500000-ff5fffff
  PREFETCH window: cfa00000-cfafffff
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.1 to 64
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1c.2 to 64
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1c.3 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 6, 327680 bytes)
TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 1484k freed
audit: initializing netlink socket (disabled)
audit(1170285594.730:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux:  Registering netfilter hooks
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:01.0:pcie00]
Allocate Port Service[0000:00:01.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
Allocate Port Service[0000:00:1c.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.1:pcie00]
Allocate Port Service[0000:00:1c.1:pcie02]
Allocate Port Service[0000:00:1c.1:pcie03]
PCI: Setting latency timer of device 0000:00:1c.2 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.2:pcie00]
Allocate Port Service[0000:00:1c.2:pcie02]
Allocate Port Service[0000:00:1c.2:pcie03]
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.3:pcie00]
Allocate Port Service[0000:00:1c.3:pcie02]
Allocate Port Service[0000:00:1c.3:pcie03]
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: Processor [CPU1] (supports 8 throttling states)
ACPI: Processor [CPU2] (supports 8 throttling states)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 915G Chipset.
agpgart: Detected 7932K stolen memory.
agpgart: AGP aperture is 256M @ 0xd0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH6: chipset revision 3
ICH6: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: HL-DT-ST DVDRAM GSA-4163B, ATAPI CD/DVD-ROM drive
hdb: HL-DT-ST GCE-8527B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Probing IDE interface ide1...
usbcore: registered new interface driver libusual
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input0
TCP bic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
Using IPI Shortcut mode
Freeing unused kernel memory: 244k freed
Write protecting the kernel read-only data: 800k
Time: tsc clocksource has been installed.
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 20, io base 0x0000c800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000cc00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000d000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000d400
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
usb 2-1: new low speed USB device using uhci_hcd and address 2
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 20, io mem 0xff43bc00
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
SCSI subsystem initialized
libata version 2.00 loaded.
ata_piix 0000:00:1f.2: version 2.00ac7
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma 0xD800 irq 19
ata2: SATA max UDMA/133 cmd 0xE000 ctl 0xDC02 bmdma 0xD808 irq 19
scsi0 : ata_piix
ATA: abnormal status 0x7F on port 0xE807
scsi1 : ata_piix
ata2.00: ATA-6, max UDMA/133, 312581808 sectors: LBA48 NCQ (depth 0/32)
ata2.00: ata2: dev 0 multi count 16
ata2.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access     ATA      ST3160827AS      3.42 PQ: 0 ANSI: 5
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
 sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8<6>usb 2-1: new low speed
USB device using uhci_hcd and address 3
 sda9 >
 sda2: <solaris: [s0] sda10 [s1] sda11 [s2] sda12 [s3] sda13 [s4]
sda14 [s5] sda15 >
sd 1:0:0:0: Attached scsi disk sda
usb 2-1: configuration #1 chosen from 1 choice
input: Microsoft Basic Optical Mouse as /class/input/input1
input: USB HID v1.10 Mouse [Microsoft Basic Optical Mouse] on usb-0000:00:1d.1-1
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
audit(1170285599.902:2): selinux=0 auid=4294967295
hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdb: ATAPI 52X CD-ROM CD-R/RW drive, 1536kB Cache, UDMA(33)
input: PC Speaker as /class/input/input2
sd 1:0:0:0: Attached scsi generic sg0 type 0
fealnx.c:v2.52 Sep-11-2006
ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 21 (level, low) -> IRQ 21
eth0: 100/10M Ethernet PCI Adapter at 0001b800, 00:a1:b0:10:88:1a, IRQ 21.
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.01 (11-Nov-2006)
iTCO_wdt: Found a ICH6 or ICH6R TCO device (Version=2, TCOBASE=0x0460)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
intel_rng: Firmware space is locked read-only. If you can't or
intel_rng: don't want to disable this in firmware setup, and if
intel_rng: you are certain that your system has a functional
intel_rng: RNG, try using the 'no_fwh_detect' option.
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 19
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1b.0 to 64
floppy0: no floppy controllers found
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
lp0: using parport0 (interrupt-driven).
lp0: console ready
input: Power Button (FF) as /class/input/input3
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input4
ACPI: Power Button (CM) [PWRB]
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
device-mapper: multipath: version 1.0.5 loaded
EXT3 FS on sda6, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
fuse init (API version 7.8)
Adding 1052216k swap on /dev/sda5.  Priority:-1 extents:1 across:1052216k
IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
audit(1170265826.105:3): audit_pid=2038 old=0 by auid=4294967295
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
[drm] Initialized i915 1.6.0 20060119 on minor 0


~Akula2

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-01-31 16:04   ` Linus Torvalds
@ 2007-01-31 23:13     ` Andrew Morton
       [not found]     ` <200702010037.48472.pluto@agmk.net>
  2007-02-01  6:48     ` Pekka Enberg
  2 siblings, 0 replies; 61+ messages in thread
From: Andrew Morton @ 2007-01-31 23:13 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: PaweÅ Sikora, Linux Kernel Mailing List, Christoph Hellwig,
	Pekka Enberg, Siddha, Suresh B, Martin Peschke, Adrian Bunk,
	Andi Kleen

On Wed, 31 Jan 2007 08:04:29 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Wed, 31 Jan 2007, Pawe__ Sikora wrote:
> > 
> > The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
> > 
> > [ an oops inside kmem_get_pages ]
> > http://bugzilla.kernel.org/show_bug.cgi?id=7889
> 
> Pabel, can you detail more exactly which kernels don't work, and which do?
> 
> >From bugzilla:
> 
>  - 2.6.18.x does work
>  - 2.6.19.2 doesn't work.
>  - what about plain 2.6.19?
>  - can you please test some of the 2.6.19-rcX kernels? Especially 
>    2.6.19-rc1 would be good to test.
> 
> Since it apparently already happens in 2.6.19 (but it would be really good 
> to know exactly when it starts), and considering _where_ it happens, I'd 
> be inclined to blame commit d2e7b7d0: "fix potential stack overflow in 
> mm/slab.c" by Suresh. 
> 
> When do_tune_cpucache() is called at bootup, I'm not sure how safe it is 
> to do the kzalloc() thing.
> 
> I've added a number of hopefully appropriate people to the Cc. Guys? 
> Apparently it only happens with MEMORY_HOTPLUG (and possibly with just an 
> SMP kernel on UP), which probably explains why it's been around without 
> people really complaining very loudly. 
> 

I discussed this with Yasunori Goto <y-goto@jp.fujitsu.com> (memory
  hot-add developer):

 "But this config uses CONFIG_MEMORY_HOTPLUG_RESERVE which is made by
  Andi Kleen-san and I don't know very well around here.  And, I couldn't
  reproduce this trouble on my box."

I cannot reproduce it with Pawel's config either.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
       [not found]     ` <200702010037.48472.pluto@agmk.net>
@ 2007-02-01  0:14       ` Andrew Morton
  2007-02-01  0:19       ` Linus Torvalds
  1 sibling, 0 replies; 61+ messages in thread
From: Andrew Morton @ 2007-02-01  0:14 UTC (permalink / raw)
  To: Pawe__ Sikora
  Cc: linux-kernel, Linus Torvalds, Christoph Hellwig, Pekka Enberg,
	Siddha, Suresh B, Martin Peschke, Adrian Bunk, Andi Kleen

On Thu, 1 Feb 2007 00:37:48 +0100
Pawe__ Sikora <pluto@agmk.net> wrote:

> On Wednesday 31 of January 2007 17:04:29 Linus Torvalds wrote:
> > On Wed, 31 Jan 2007, Pawe__ Sikora wrote:
> > > The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
> > >
> > > [ an oops inside kmem_get_pages ]
> > > http://bugzilla.kernel.org/show_bug.cgi?id=7889
> >
> > Pabel, can you detail more exactly which kernels don't work, and which do?
> 
> 2.6.18 works, 2.6.19-rc1 doesn't work.
> git bisect found this bad commit:
> 
> commit e80ee884ae0e3794ef2b65a18a767d502ad712ee
> Author: Nick Piggin <nickpiggin@yahoo.com.au>
> Date:   Wed Oct 4 02:15:23 2006 -0700
> 
>     [PATCH] mm: micro optimise zone_watermark_ok
> 
>     Having min be a signed quantity means gcc can't turn high latency divides
>     into shifts.  There happen to be two such divides for GFP_ATOMIC (ie.
>     networking, ie.  important) allocations, one of which depends on the 
> other.
>      Fixing this makes code smaller as a bonus.
> 
>     Shame on somebody (probably me).
> 
>     Signed-off-by: Nick Piggin <npiggin@suse.de>
>     Signed-off-by: Andrew Morton <akpm@osdl.org>
>     Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> 
> ------------------------- mm/page_alloc.c -----------------------
> @@ -900,7 +900,8 @@ int zone_watermark_ok(struct zone *z, int order, unsigned 
> long mark,
>  		      int classzone_idx, int alloc_flags)
>  {
>  	/* free_pages my go negative - that's OK */
> -	long min = mark, free_pages = z->free_pages - (1 << order) + 1;
> +	unsigned long min = mark;
> +	long free_pages = z->free_pages - (1 << order) + 1;
>  	int o;
> 
>  	if (alloc_flags & ALLOC_HIGH)
> 
> 
> > Apparently it only happens with MEMORY_HOTPLUG (and possibly with just an
> > SMP kernel on UP), which probably explains why it's been around without
> > people really complaining very loudly.
> 
> reverting mentioned commit removes the oops.
> 

urgh.  zone->free_pages is very small - probably zero.  We shouldn't have
got here at all, so something else is wrong.

But local `free_pages' can go negative in normal operation.  I guess
that'll cause us to incorrectly return `true' from zone_watermark_ok, thus
ignoring the watermarks.

The below, I guess.  But we still don't know why this got called against an
empty zone.




Subject: zone_watermark_ok: signedness fix
From: Andrew Morton <akpm@osdl.org>

Local `free_pages' can go negative in normal operation.  I guess that'll cause
us to incorrectly return `true' from zone_watermark_ok, thus ignoring the
watermarks.

Cc: Christoph Lameter <clameter@engr.sgi.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 mm/page_alloc.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN mm/page_alloc.c~zone_watermark_ok-signedness-fix mm/page_alloc.c
--- a/mm/page_alloc.c~zone_watermark_ok-signedness-fix
+++ a/mm/page_alloc.c
@@ -1013,7 +1013,7 @@ int zone_watermark_ok(struct zone *z, in
 		      int classzone_idx, int alloc_flags)
 {
 	/* free_pages my go negative - that's OK */
-	unsigned long min = mark;
+	long min = mark;
 	long free_pages = zone_page_state(z, NR_FREE_PAGES)
 				- (1 << order) + 1;
 	int o;
_


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
       [not found]     ` <200702010037.48472.pluto@agmk.net>
  2007-02-01  0:14       ` Andrew Morton
@ 2007-02-01  0:19       ` Linus Torvalds
  2007-02-01  0:26         ` Andrew Morton
  2007-02-01  0:44         ` Nick Piggin
  1 sibling, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2007-02-01  0:19 UTC (permalink / raw)
  To: PaweÅ Sikora
  Cc: Linux Kernel Mailing List, Christoph Hellwig, Pekka Enberg,
	Siddha, Suresh B, Martin Peschke, Andrew Morton, Adrian Bunk,
	Nick Piggin

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1525 bytes --]



On Thu, 1 Feb 2007, PaweÅ Sikora wrote:
> 
> 2.6.18 works, 2.6.19-rc1 doesn't work.
> git bisect found this bad commit:

Git bisect rocks.

I'll give myself yet abother pat on the back for writing it. You can never 
encourage genius like that too much.

> commit e80ee884ae0e3794ef2b65a18a767d502ad712ee
> Author: Nick Piggin <nickpiggin@yahoo.com.au>
> Date:   Wed Oct 4 02:15:23 2006 -0700
> 
>     [PATCH] mm: micro optimise zone_watermark_ok
>
> reverting mentioned commit removes the oops.

Ok, that commit is just totally broken.

If "free_pages" turns negative (which it can, since it's just doing a

	long free_pages = z->free_pages - (1 << order) + 1;

to initialize it, and for all we know, you have an empty or close-to-empty 
zone or two, the whole test to do

	if (free_pages <= min + z->lowmem_reserve[classzone_idx])
		return 0;

gets broken, because the negative 'free_pages' will look like a huge 
unsigned positive number (and we'll make it unsigned becaue 'min' got 
turned unsigned). There was a reason that thing was signed in the first 
place, and neither me nor Andrew noticed.

Bad Nick. And bad me and Andrew for not noticing.

I should either revert that commit or just check for "free_pages" being 
negative. The latter, in many ways, is probably better, because generally 
we simply should never work with negative numbers in the kernel, so when 
something potentially goes negative, we're probably just better off always 
testing it explicitly anyway.

Nick, Andrew, any preferences? 

			Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  0:19       ` Linus Torvalds
@ 2007-02-01  0:26         ` Andrew Morton
  2007-02-01  0:39           ` Linus Torvalds
  2007-02-01  0:44         ` Nick Piggin
  1 sibling, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2007-02-01  0:26 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: PaweÅ Sikora, Linux Kernel Mailing List, Christoph Hellwig,
	Pekka Enberg, Siddha, Suresh B, Martin Peschke, Adrian Bunk,
	Nick Piggin

On Wed, 31 Jan 2007 16:19:06 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> I should either revert that commit or just check for "free_pages" being 
> negative. The latter, in many ways, is probably better, because generally 
> we simply should never work with negative numbers in the kernel, so when 
> something potentially goes negative, we're probably just better off always 
> testing it explicitly anyway.
> 
> Nick, Andrew, any preferences? 

It would be cleaner to check for negativity, but note that we keep
subtracting stuff from free_pages in the later loop, so we'd need to check
there as well.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  0:26         ` Andrew Morton
@ 2007-02-01  0:39           ` Linus Torvalds
  0 siblings, 0 replies; 61+ messages in thread
From: Linus Torvalds @ 2007-02-01  0:39 UTC (permalink / raw)
  To: Andrew Morton
  Cc: PaweÅ Sikora, Linux Kernel Mailing List, Christoph Hellwig,
	Pekka Enberg, Siddha, Suresh B, Martin Peschke, Adrian Bunk,
	Nick Piggin



On Wed, 31 Jan 2007, Andrew Morton wrote:
> 
> It would be cleaner to check for negativity, but note that we keep
> subtracting stuff from free_pages in the later loop, so we'd need to check
> there as well.

Yeah, not worth it. I'll just revert it.

If we really want to do the micro-optimization that Nick was after, we can 
just do

	// 'min' is always positive
	min = (unsigned long) min >> 1;

or something.

		Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  0:19       ` Linus Torvalds
  2007-02-01  0:26         ` Andrew Morton
@ 2007-02-01  0:44         ` Nick Piggin
  2007-02-01  0:54           ` Linus Torvalds
  1 sibling, 1 reply; 61+ messages in thread
From: Nick Piggin @ 2007-02-01  0:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: PaweÅ Sikora, Linux Kernel Mailing List, Christoph Hellwig,
	Pekka Enberg, Siddha, Suresh B, Martin Peschke, Andrew Morton,
	Adrian Bunk

Linus Torvalds wrote:

> 	if (free_pages <= min + z->lowmem_reserve[classzone_idx])
> 		return 0;
> 
> gets broken, because the negative 'free_pages' will look like a huge 
> unsigned positive number (and we'll make it unsigned becaue 'min' got 
> turned unsigned). There was a reason that thing was signed in the first 
> place, and neither me nor Andrew noticed.
> 
> Bad Nick. And bad me and Andrew for not noticing.

Sorry. I think I even wrote that comment at the top of the function.
And probably the function as well :(

> I should either revert that commit or just check for "free_pages" being 
> negative. The latter, in many ways, is probably better, because generally 
> we simply should never work with negative numbers in the kernel, so when 
> something potentially goes negative, we're probably just better off always 
> testing it explicitly anyway.
> 
> Nick, Andrew, any preferences? 

As Andrew says, it would need to be checked each time, because we have
nothing synchronising against free_pages at the top, or nr_free in the
loop.

We could make them both unsigned, and _add_ everything to min rather than
subtracting from free_pages?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  0:44         ` Nick Piggin
@ 2007-02-01  0:54           ` Linus Torvalds
  0 siblings, 0 replies; 61+ messages in thread
From: Linus Torvalds @ 2007-02-01  0:54 UTC (permalink / raw)
  To: Nick Piggin
  Cc: PaweÅ Sikora, Linux Kernel Mailing List, Christoph Hellwig,
	Pekka Enberg, Siddha, Suresh B, Martin Peschke, Andrew Morton,
	Adrian Bunk



On Thu, 1 Feb 2007, Nick Piggin wrote:
> 
> We could make them both unsigned, and _add_ everything to min rather than
> subtracting from free_pages?

Yeah, that's the right thing to do, probably. However, since we do that 
"min >>=1" thing, we'd have to do that to a separate "correction" factor 
(also unsigned).

No worth it for 2.6.20. I just reverted it. But feel free to send the 
fixed/updated micro-optimization after 2.6.20 has been released..

		Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-01-31  4:28 Linux 2.6.20-rc7 Linus Torvalds
                   ` (2 preceding siblings ...)
  2007-01-31 18:15 ` Linux 2.6.20-rc7 Sunil Naidu
@ 2007-02-01  2:16 ` S.Çağlar Onur
  2007-02-01  2:36   ` Linus Torvalds
  2007-02-02  5:49 ` 2.6.20-rc7: known regressions Adrian Bunk
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 61+ messages in thread
From: S.Çağlar Onur @ 2007-02-01  2:16 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: lkml, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

Hi;

31 Oca 2007 Çar tarihinde şunları yazmıştınız:
> In other words, please do give it a good testing. We should have fixed the
> nasty stuff on Adrian's list (and here's another thanks to Adrian for
> keeping me on my toes!) and it's all good. But please give it a quick
> shake-down to make sure that nothing silly happened while fixing the bad
> stuff.

For me, both 2.6.20-rc6 and 2.6.20-rc7 fails while booting with initramfs 
(initramfs that uses busybox) with "request_module: runaway loop modprobe 
binfmt-0000" error. 

So i modified kmod.c with [1] to get dump_stack, here is the picture taken 
with [2] dump_stack enabled one with description below.

And here is the some observations that i made;

* Booting without an initramfs works,
* Booting with converted initrd from failed initramfs's content works,
* Booting with "Hello world" type initramfs described 
in "Documentation/filesystems/ramfs-rootfs-initramfs.txt" works,

But what is not working is busybox binaries inside the _initramfs_, modifiying 
our init shell script to use staticly linked bash with confirms that, bash 
script interpretted without a problem by staticaly linked bash until 
busybox's mount binary called inside the initramfs.

First i thought somehow busybox is broken but copying initramfs's content into 
initrd works without a problem and also same binaries are working with 2.6.18 
so i think its a regression in kernel but of course im not sure :), if you 
need more information please ask.

[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg109266.html
[2] http://cekirdek.uludag.org.tr/~caglar/error.png

Cheers
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  2:16 ` S.Çağlar Onur
@ 2007-02-01  2:36   ` Linus Torvalds
  2007-02-01  3:01     ` S.Çağlar Onur
  0 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2007-02-01  2:36 UTC (permalink / raw)
  To: S.ÃaÄlar Onur; +Cc: lkml, Andrew Morton

[-- Attachment #1: Type: TEXT/PLAIN, Size: 949 bytes --]



On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
> 
> For me, both 2.6.20-rc6 and 2.6.20-rc7 fails while booting with initramfs 
> (initramfs that uses busybox) with "request_module: runaway loop modprobe 
> binfmt-0000" error. 

That _usually_ just means that /sbin/modprobe is corrupt, or compiled with 
a binfmt that itself needs a module to load.

Are you 100% certain that you didn't just happen to put an /sbin/modprobe 
into your initramfs that happens to be a.out, with a.out being modular? Or 
something similarly silly?

Actually, with that "binfmt-0000", I guess the most likely thing is a 
corrupt /sbin/modprobe that isn't a valid binfmt format at all (but the 
kernel won't know the difference between a missing binfmt thing and an 
invalid one). It has bytes 2/3 being zero, which is neither ELF nor 
a.out, methinks.

BUT! If that's not it, doing a "git bisect" to figure out exactly what 
triggered it would be a wonderful idea..

		Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  2:36   ` Linus Torvalds
@ 2007-02-01  3:01     ` S.Çağlar Onur
  2007-02-01  3:31       ` Linus Torvalds
  0 siblings, 1 reply; 61+ messages in thread
From: S.Çağlar Onur @ 2007-02-01  3:01 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: lkml, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

01 Şub 2007 Per tarihinde, Linus Torvalds şunları yazmıştı: 
> That _usually_ just means that /sbin/modprobe is corrupt, or compiled with
> a binfmt that itself needs a module to load.
>
> Are you 100% certain that you didn't just happen to put an /sbin/modprobe
> into your initramfs that happens to be a.out, with a.out being modular? Or
> something similarly silly?

Yep, i'm sure config and binary is OK.

zangetsu ~ # readelf -h /sbin/busybox
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048130
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1010608 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         5
  Size of section headers:           40 (bytes)
  Number of section headers:         25
  Section header string table index: 24

zangetsu ~ #  zcat /proc/config.gz | grep BINFMT
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

And as i said before same binaries works within initrd image with same kernel

> Actually, with that "binfmt-0000", I guess the most likely thing is a
> corrupt /sbin/modprobe that isn't a valid binfmt format at all (but the
> kernel won't know the difference between a missing binfmt thing and an
> invalid one). It has bytes 2/3 being zero, which is neither ELF nor
> a.out, methinks.
>
> BUT! If that's not it, doing a "git bisect" to figure out exactly what
> triggered it would be a wonderful idea..

I think i found the cause of the problem, initramfs can't handle hardlinks 
anymore (which works with 2.6.18), copying same /sbin/busybox binary with 
different names into initramfs (which ends ups with 50 MB image) or using 
symbolic ones instead of hards seems works.

-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  3:01     ` S.Çağlar Onur
@ 2007-02-01  3:31       ` Linus Torvalds
  2007-02-01  5:44         ` H. Peter Anvin
  2007-02-02 20:52         ` S.Çağlar Onur
  0 siblings, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2007-02-01  3:31 UTC (permalink / raw)
  To: S.ÃaÄlar Onur
  Cc: lkml, Andrew Morton, Peter Anvin, Mark Huang, Al Viro

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1598 bytes --]



On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
> 
> I think i found the cause of the problem, initramfs can't handle hardlinks 
> anymore (which works with 2.6.18), copying same /sbin/busybox binary with 
> different names into initramfs (which ends ups with 50 MB image) or using 
> symbolic ones instead of hards seems works.

Ok, it would still be interesting to hear what triggered this.

There's really only two initramfs-related changes in the whole 2.6.20 
development series that I can see, and neither of them are even _remotely_ 
likely to cause this, afaik. We have:

 - commit 8d610dd52dd1da696e199e4b4545f33a2a5de5c6

   "Make sure we populate the initroot filesystem late enough"

(but "late enough" is still _way_ before we actually mount it, so ..) and

 - commit 2e591bbc0d563e12f5a260fbbca0df7d5810910e

   "Make initramfs printk a warning on incorrect cpio type"

and the latter is just a build-time sanity-check.

Since 2.6.18, there's been a couple more, but none of them look even 
remotely likely either. Which is why it really would be good if you can 
"git bisect" this behaviour.

There _was_ a hardlink-related thing some time ago, but that was back in 
May, and before 2.6.18. So if it worked for you in 2.6.18, I don't see 
that being it.

I've added some initramfs people to the Cc: in case somebody has better 
ideas, but in the absense of that, it really would be good to do that 
bisection. Also, you might want to double-check that your cpio actually 
generates a good initramfs image (it that it's not some user-mode upgrade 
that caused it to stop working).

		Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  3:31       ` Linus Torvalds
@ 2007-02-01  5:44         ` H. Peter Anvin
  2007-02-01  6:00           ` Linus Torvalds
  2007-02-02 20:52         ` S.Çağlar Onur
  1 sibling, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2007-02-01  5:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: "S.ÃaÄlar Onur",
	lkml, Andrew Morton, Mark Huang, Al Viro

Linus Torvalds wrote:
> 
> On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
>> I think i found the cause of the problem, initramfs can't handle hardlinks 
>> anymore (which works with 2.6.18), copying same /sbin/busybox binary with 
>> different names into initramfs (which ends ups with 50 MB image) or using 
>> symbolic ones instead of hards seems works.
> 
> Ok, it would still be interesting to hear what triggered this.
> 

It would be interesting to know what the inode numbers are in the image; 
also, what is the exact behaviour -- do you end up with a missing link, 
or do both entries end up getting hard-linked to an empty file?

	-hpa


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  5:44         ` H. Peter Anvin
@ 2007-02-01  6:00           ` Linus Torvalds
  2007-02-01  6:10             ` H. Peter Anvin
  0 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2007-02-01  6:00 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: S.ÃaÄlar Onur, lkml, Andrew Morton, Mark Huang, Al Viro



On Wed, 31 Jan 2007, H. Peter Anvin wrote:
> 
> It would be interesting to know what the inode numbers are in the image; also,
> what is the exact behaviour -- do you end up with a missing link, or do both
> entries end up getting hard-linked to an empty file?

Judging by the

	request_module: runaway loop modprobe binfmt-0000

one or more of the hardlinked binaries (modprobe being one, but not 
necessarily the one that initially triggers hits) will read all zeroes-

Or at least bytes at offsets 2 and 3 will read as zero, causing it to not 
be recognized as a proper binary, causing that "binfmt-0000" thing.

			Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  6:00           ` Linus Torvalds
@ 2007-02-01  6:10             ` H. Peter Anvin
  2007-02-01  6:38               ` Alexander E. Patrakov
  0 siblings, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2007-02-01  6:10 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: "S.ÃaÄlar Onur",
	lkml, Andrew Morton, Mark Huang, Al Viro

Linus Torvalds wrote:
> 
> On Wed, 31 Jan 2007, H. Peter Anvin wrote:
>> It would be interesting to know what the inode numbers are in the image; also,
>> what is the exact behaviour -- do you end up with a missing link, or do both
>> entries end up getting hard-linked to an empty file?
> 
> Judging by the
> 
> 	request_module: runaway loop modprobe binfmt-0000
> 
> one or more of the hardlinked binaries (modprobe being one, but not 
> necessarily the one that initially triggers hits) will read all zeroes-
> 
> Or at least bytes at offsets 2 and 3 will read as zero, causing it to not 
> be recognized as a proper binary, causing that "binfmt-0000" thing.
> 

Or perhaps not read at all, which would explain the problem.

cpio represents a hard link as who headers with the same type and the 
same file (inode) number and a link count that is > 1.  Only the first 
one contains data; the subsequent ones have length 0.  It's fairly easy 
for a bug in the decoder to truncate the file upon encountering the 
second header, since this is somewhat of a special case (it would have 
been better if the cpio format distinguished "hard link" explicitly, as 
tar does.)

I will look into this as soon as I can, but as I'm currently in the 
middle of job hunting it might take until the weekend.

	-hpa

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  6:10             ` H. Peter Anvin
@ 2007-02-01  6:38               ` Alexander E. Patrakov
  2007-02-01  6:53                 ` H. Peter Anvin
  0 siblings, 1 reply; 61+ messages in thread
From: Alexander E. Patrakov @ 2007-02-01  6:38 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Linus Torvalds, "S.ÃaÄlar Onur",
	lkml, Andrew Morton, Mark Huang, Al Viro

H. Peter Anvin wrote:
> Linus Torvalds wrote:
>>
>> On Wed, 31 Jan 2007, H. Peter Anvin wrote:
>>> It would be interesting to know what the inode numbers are in the 
>>> image; also,
>>> what is the exact behaviour -- do you end up with a missing link, or 
>>> do both
>>> entries end up getting hard-linked to an empty file?
>>
>> Judging by the
>>
>>     request_module: runaway loop modprobe binfmt-0000
>>
>> one or more of the hardlinked binaries (modprobe being one, but not 
>> necessarily the one that initially triggers hits) will read all zeroes-
>>
>> Or at least bytes at offsets 2 and 3 will read as zero, causing it to 
>> not be recognized as a proper binary, causing that "binfmt-0000" thing.
>>
> 
> Or perhaps not read at all, which would explain the problem.
> 
> cpio represents a hard link as who headers with the same type and the 
> same file (inode) number and a link count that is > 1.  Only the first 
> one contains data; the subsequent ones have length 0.  It's fairly easy 
> for a bug in the decoder to truncate the file upon encountering the 
> second header, since this is somewhat of a special case (it would have 
> been better if the cpio format distinguished "hard link" explicitly, as 
> tar does.)
> 
> I will look into this as soon as I can, but as I'm currently in the 
> middle of job hunting it might take until the weekend.

What's the proper way to make sure that the fix, when it appears, ends up in 
my inbox?

-- 
Alexander E. Patrakov

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-01-31 16:04   ` Linus Torvalds
  2007-01-31 23:13     ` Andrew Morton
       [not found]     ` <200702010037.48472.pluto@agmk.net>
@ 2007-02-01  6:48     ` Pekka Enberg
  2 siblings, 0 replies; 61+ messages in thread
From: Pekka Enberg @ 2007-02-01  6:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: PaweÅ Sikora, Linux Kernel Mailing List, Christoph Hellwig,
	Siddha, Suresh B, Martin Peschke, Andrew Morton, Adrian Bunk

On 1/31/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> When do_tune_cpucache() is called at bootup, I'm not sure how safe it is
> to do the kzalloc() thing.

The kzalloc thing is safe as we have already successfully boostrapped
all kmalloc caches at that point. The per-CPU caches that are replaced
by do_tune_cpucache() point to boostrap-time array caches there (see
use of struct arraycache_init in setup_cpu_cache).

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  6:38               ` Alexander E. Patrakov
@ 2007-02-01  6:53                 ` H. Peter Anvin
  0 siblings, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2007-02-01  6:53 UTC (permalink / raw)
  To: Alexander E. Patrakov
  Cc: Linus Torvalds, caglar, lkml, Andrew Morton, Mark Huang, Al Viro

Alexander E. Patrakov wrote:
> 
> What's the proper way to make sure that the fix, when it appears, ends 
> up in my inbox?
> 

Say "please", and give prompt feedback on any test patches that we send you.

	-hpa

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-02 20:52         ` S.Çağlar Onur
@ 2007-02-01 21:06           ` H. Peter Anvin
  0 siblings, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2007-02-01 21:06 UTC (permalink / raw)
  To: caglar; +Cc: Linus Torvalds, lkml, Andrew Morton, Mark Huang, Al Viro

S.Çağlar Onur wrote:
> Hi;
> 
> 01 Şub 2007 Per tarihinde, Linus Torvalds şunları yazmıştı: 
>> I've added some initramfs people to the Cc: in case somebody has better
>> ideas, but in the absense of that, it really would be good to do that
>> bisection. Also, you might want to double-check that your cpio actually
>> generates a good initramfs image (it that it's not some user-mode upgrade
>> that caused it to stop working).
> 
> I started bisect with 2.6.19 and ended up with 2.6.20-rc7 and every step 
> worked without a problem with problematic initramfs script, so i think that 
> was a compilation failure or something else but currently 2.6.20-rc7 works 
> without a problem, so please ignore that one, sorry for noise...
> 

OK, well, if it crops up again, please holler.  It could be a 
nondeterministic bug.

	-hpa


^ permalink raw reply	[flat|nested] 61+ messages in thread

* 2.6.20-rc7: known regressions
  2007-01-31  4:28 Linux 2.6.20-rc7 Linus Torvalds
                   ` (3 preceding siblings ...)
  2007-02-01  2:16 ` S.Çağlar Onur
@ 2007-02-02  5:49 ` Adrian Bunk
  2007-02-03  1:55   ` Andrew Morton
  2007-02-03  0:44 ` 2.6.20-rc7: known regressions (v2) (part 1) Adrian Bunk
  2007-02-03  0:47 ` 2.6.20-rc7: known regressions (v2) (part 2) Adrian Bunk
  6 siblings, 1 reply; 61+ messages in thread
From: Adrian Bunk @ 2007-02-02  5:49 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Andrew Vasquez, Jens Axboe,
	Gerhard Dirschl, Luca Tettamanti, Christoph Hellwig, petero2,
	jgarzik, linux-ide, alan, Livio Soares, Paul Mackerras,
	linuxppc-dev, Berthold Cogel, François Valenduc, Alan Stern,
	greg, linux-usb-devel, Prakash Punnoor, Oliver Neukum,
	Cijoml Cijomlovic Cijomlov, Nick Piggin, ttb, rml,
	Lennart Sorensen, takada, Jordan Crouse

This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : NULL pointer dereference at as_move_to_dispatch()
References : http://lkml.org/lkml/2007/1/22/141
Submitter  : Andrew Vasquez <andrew.vasquez@qlogic.com>
Status     : unknown


Subject    : pktcdvd doesn't work with libata pata drivers
References : http://bugzilla.kernel.org/show_bug.cgi?id=7810
             http://lkml.org/lkml/2007/1/25/128
             http://bugzilla.kernel.org/show_bug.cgi?id=7910
             http://lkml.org/lkml/2007/1/30/289
Submitter  : Gerhard Dirschl <gd@spherenet.de>
             Luca Tettamanti <kronos.it@gmail.com>
Caused-By  : Christoph Hellwig <hch@lst.de>
             commit 3b00315799d78f76531b71435fbc2643cd71ae4c
             commit 406c9b605cbc45151c03ac9a3f95e9acf050808c
Status     : unknown


Subject    : powerpc64: performance monitor exception
References : http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030045.html
Submitter  : Livio Soares <livio@eecg.toronto.edu>
Caused-By  : Paul Mackerras <paulus@samba.org>
             commit d04c56f73c30a5e593202ecfcf25ed43d42363a2
Status     : unknown


Subject    : reboot instead of powerdown  (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2006/12/25/40
             http://bugzilla.kernel.org/show_bug.cgi?id=7828
Submitter  : Berthold Cogel <cogel@rrz.uni-koeln.de>
             François Valenduc <francois.valenduc@skynet.be>
Handled-By : Alan Stern <stern@rowland.harvard.edu>
Status     : problem is being debugged


Subject    : usb somehow broken  (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/1/11/146
Submitter  : Prakash Punnoor <prakash@punnoor.de>
Handled-By : Oliver Neukum <oliver@neukum.org>
             Alan Stern <stern@rowland.harvard.edu>
Status     : problem is being debugged


Subject    : BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter  : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Handled-By : Nick Piggin <nickpiggin@yahoo.com.au>
Status     : problem is being debugged


Subject    : fix geode_configure()
References : http://lkml.org/lkml/2007/1/9/216
Submitter  : Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Caused-By  : takada <takada@mbf.nifty.com>
             commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba
Handled-By : takada <takada@mbf.nifty.com>
             Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Status     : patches are being discussed


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Linux 2.6.20-rc7
  2007-02-01  3:31       ` Linus Torvalds
  2007-02-01  5:44         ` H. Peter Anvin
@ 2007-02-02 20:52         ` S.Çağlar Onur
  2007-02-01 21:06           ` H. Peter Anvin
  1 sibling, 1 reply; 61+ messages in thread
From: S.Çağlar Onur @ 2007-02-02 20:52 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: lkml, Andrew Morton, Peter Anvin, Mark Huang, Al Viro

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

Hi;

01 Şub 2007 Per tarihinde, Linus Torvalds şunları yazmıştı: 
> I've added some initramfs people to the Cc: in case somebody has better
> ideas, but in the absense of that, it really would be good to do that
> bisection. Also, you might want to double-check that your cpio actually
> generates a good initramfs image (it that it's not some user-mode upgrade
> that caused it to stop working).

I started bisect with 2.6.19 and ended up with 2.6.20-rc7 and every step 
worked without a problem with problematic initramfs script, so i think that 
was a compilation failure or something else but currently 2.6.20-rc7 works 
without a problem, so please ignore that one, sorry for noise...

Cheers
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 61+ messages in thread

* 2.6.20-rc7: known regressions (v2) (part 1)
  2007-01-31  4:28 Linux 2.6.20-rc7 Linus Torvalds
                   ` (4 preceding siblings ...)
  2007-02-02  5:49 ` 2.6.20-rc7: known regressions Adrian Bunk
@ 2007-02-03  0:44 ` Adrian Bunk
  2007-02-03  6:06   ` Auke Kok
  2007-02-03  0:47 ` 2.6.20-rc7: known regressions (v2) (part 2) Adrian Bunk
  6 siblings, 1 reply; 61+ messages in thread
From: Adrian Bunk @ 2007-02-03  0:44 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Andrew Vasquez, Jens Axboe,
	Gerhard Dirschl, Luca Tettamanti, Christoph Hellwig, petero2,
	jgarzik, linux-ide, alan, Allen Parker, Adam Kropelin, Auke Kok,
	cramerj, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher,
	gregkh, linux-pci, ebiederm, mingo, netdev, Livio Soares,
	Paul Mackerras, anton, linuxppc-dev

This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : NULL pointer dereference at as_move_to_dispatch()
References : http://lkml.org/lkml/2007/1/22/141
Submitter  : Andrew Vasquez <andrew.vasquez@qlogic.com>
Status     : unknown


Subject    : pktcdvd doesn't work with libata pata drivers
             (caused by scsi_lib and pktcdvd patches)
References : http://bugzilla.kernel.org/show_bug.cgi?id=7810
             http://lkml.org/lkml/2007/1/25/128
             http://bugzilla.kernel.org/show_bug.cgi?id=7910
             http://lkml.org/lkml/2007/1/30/289
Submitter  : Gerhard Dirschl <gd@spherenet.de>
             Luca Tettamanti <kronos.it@gmail.com>
Caused-By  : Christoph Hellwig <hch@lst.de>
             commit 3b00315799d78f76531b71435fbc2643cd71ae4c
             commit 406c9b605cbc45151c03ac9a3f95e9acf050808c
Status     : unknown


Subject    : e1000: 82571EB/82572EI PCI-E cards: link is always down
             (MSI related)
References : http://lkml.org/lkml/2007/1/16/27
             http://lkml.org/lkml/2007/1/17/182
Submitter  : Allen Parker <parker@isohunt.com>
             Adam Kropelin <akropel1@rochester.rr.com>
Handled-By : Auke Kok <auke-jan.h.kok@intel.com>
Status     : problem is being debugged


Subject    : powerpc64: performance monitor exception
References : http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030045.html
Submitter  : Livio Soares <livio@eecg.toronto.edu>
Caused-By  : Paul Mackerras <paulus@samba.org>
             commit d04c56f73c30a5e593202ecfcf25ed43d42363a2
Status     : unknown

^ permalink raw reply	[flat|nested] 61+ messages in thread

* 2.6.20-rc7: known regressions (v2) (part 2)
  2007-01-31  4:28 Linux 2.6.20-rc7 Linus Torvalds
                   ` (5 preceding siblings ...)
  2007-02-03  0:44 ` 2.6.20-rc7: known regressions (v2) (part 1) Adrian Bunk
@ 2007-02-03  0:47 ` Adrian Bunk
  6 siblings, 0 replies; 61+ messages in thread
From: Adrian Bunk @ 2007-02-03  0:47 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Berthold Cogel,
	François Valenduc, Alan Stern, greg, linux-usb-devel,
	Prakash Punnoor, Oliver Neukum, . Cijoml Cijomlovic Cijomlov,
	Nick Piggin, ttb, rml, Mark Fasheh, ocfs2-devel,
	Eric Van Hensbergen, v9fs-developer

This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : reboot instead of powerdown  (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2006/12/25/40
             http://bugzilla.kernel.org/show_bug.cgi?id=7828
Submitter  : Berthold Cogel <cogel@rrz.uni-koeln.de>
             François Valenduc <francois.valenduc@skynet.be>
Handled-By : Alan Stern <stern@rowland.harvard.edu>
Status     : problem is being debugged


Subject    : usb somehow broken  (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/1/11/146
Submitter  : Prakash Punnoor <prakash@punnoor.de>
Handled-By : Oliver Neukum <oliver@neukum.org>
             Alan Stern <stern@rowland.harvard.edu>
Status     : problem is being debugged


Subject    : BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter  : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Handled-By : Nick Piggin <nickpiggin@yahoo.com.au>
Status     : problem is being debugged


Subject    : ocfs2_link() journal credits update
References : http://lkml.org/lkml/2007/2/2/171
Submitter  : Mark Fasheh <mark.fasheh@oracle.com>
Caused-By  : Mark Fasheh <mark.fasheh@oracle.com>
             commit 592282cf2eaa33409c6511ddd3f3ecaa57daeaaa
Handled-By : Mark Fasheh <mark.fasheh@oracle.com>
Patch      : http://lkml.org/lkml/2007/2/2/171
Status     : patch available


Subject    : v9fs_vfs_mkdir(): fix a double free
References : http://lkml.org/lkml/2007/2/2/164
Submitter  : Adrian Bunk <bunk@stusta.de>
Caused-By  : Eric Van Hensbergen <ericvh@gmail.com>
             commit da977b2c7eb4d6312f063a7b486f2aad99809710
Handled-By : Adrian Bunk <bunk@stusta.de>
Patch      : http://lkml.org/lkml/2007/2/2/164
Status     : patch available

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-02  5:49 ` 2.6.20-rc7: known regressions Adrian Bunk
@ 2007-02-03  1:55   ` Andrew Morton
  2007-02-03  2:03     ` Jeff Garzik
  2007-02-03  9:19     ` Frédéric Riss
  0 siblings, 2 replies; 61+ messages in thread
From: Andrew Morton @ 2007-02-03  1:55 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Linux Kernel Mailing List, Eric Van Hensbergen,
	Trond Myklebust, Neil Brown, Stephen Hemminger, Frederic Riss,
	Benjamin Herrenschmidt, Andi Kleen, Jeff Garzik,
	Eric W. Biederman, Francois Romieu

On Fri, 2 Feb 2007 06:49:16 +0100
Adrian Bunk <bunk@stusta.de> wrote:

> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
> that are not yet fixed in Linus' tree.

There are still a few things hanging around.

I have these queued:

aio-fix-buggy-put_ioctx-call-in-aio_complete-v2.patch
kexec-avoid-migration-of-already-disabled-irqs-ia64.patch
net-smc911x-match-up-spin-lock-unlock.patch
rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch
alpha-fix-epoll-syscall-enumerations.patch
revert-blockdev-direct-io-back-to-2619-version.patch
scsi-sd-udev-accessing-an-uninitialized-scsi_disk-results-in-a-crash.patch
altix-more-acpi-prt-support.patch

which I'll get through to Linus later today.  Plus:


- x86_64-irq-simplfy-__assign_irq_vector.patch and
  x86_64-irq-handle-irqs-pending-in-irr-during-irq-migration.patch which
  are big and scary.  Am awaiting feedback from Andi and Eric on what to do
  with these.

- A fix from Trond for http://bugzilla.kernel.org/show_bug.cgi?id=7923. 
  Am awaiting acks to merge that.

- sky2-flow-control-off.patch from shemminger which I assume Linus will
  be merging anyway.

- v9fs_vfs_mkdir-fix-a-double-free.patch which I guess I'll merge unless
  Eric suddenly nacks it.

- I have r8169-fix-a-race-between-pci-probe-and-dev_open.patch floating
  about, but I forget its status.  

- I have efi-x86-pass-firmware-call-parameters-on-the-stack.patch, but
  I'm not sure it's right and unless something really rapid happens, we'll
  ship with that bug unfixed.

- enable-mouse-button-23-emulation-for-x86-macs.patch looks simple
  enough, but I'm waiting for Ben to wake up.

- x86-fix-vdso-mapping-for-aout-executables.patch probably works OK, but
  Andi points out that it'd be better to implement this with
  attribute-weak.  So I guess 2.6.20 will ship with non-functional a.out on
  i386, like 2.6.29.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03  1:55   ` Andrew Morton
@ 2007-02-03  2:03     ` Jeff Garzik
  2007-02-03  2:15       ` Andrew Morton
  2007-02-03  9:19     ` Frédéric Riss
  1 sibling, 1 reply; 61+ messages in thread
From: Jeff Garzik @ 2007-02-03  2:03 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List,
	Eric Van Hensbergen, Trond Myklebust, Neil Brown,
	Stephen Hemminger, Frederic Riss, Benjamin Herrenschmidt,
	Andi Kleen, Eric W. Biederman, Francois Romieu

Andrew Morton wrote:
> On Fri, 2 Feb 2007 06:49:16 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
> 
>> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
>> that are not yet fixed in Linus' tree.
> 
> There are still a few things hanging around.
> 
> I have these queued:
> 
> aio-fix-buggy-put_ioctx-call-in-aio_complete-v2.patch
> kexec-avoid-migration-of-already-disabled-irqs-ia64.patch
> net-smc911x-match-up-spin-lock-unlock.patch
> rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch
> alpha-fix-epoll-syscall-enumerations.patch
> revert-blockdev-direct-io-back-to-2619-version.patch
> scsi-sd-udev-accessing-an-uninitialized-scsi_disk-results-in-a-crash.patch
> altix-more-acpi-prt-support.patch

Would you forward the x86-64 dma_noncoherent API build fix I posted? 
Anything that uses that API won't build on x86-64 without my [simple and 
obvious] patch.


> - I have r8169-fix-a-race-between-pci-probe-and-dev_open.patch floating
>   about, but I forget its status.  

I posted a preferred patch (which someone then noted need to use 
setup_timer), and am waiting for an "it works" response of some sort

	Jeff



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03  2:03     ` Jeff Garzik
@ 2007-02-03  2:15       ` Andrew Morton
  0 siblings, 0 replies; 61+ messages in thread
From: Andrew Morton @ 2007-02-03  2:15 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List,
	Eric Van Hensbergen, Trond Myklebust, Neil Brown,
	Stephen Hemminger, Frederic Riss, Benjamin Herrenschmidt,
	Andi Kleen, Eric W. Biederman, Francois Romieu

On Fri, 02 Feb 2007 21:03:48 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> Andrew Morton wrote:
> > On Fri, 2 Feb 2007 06:49:16 +0100
> > Adrian Bunk <bunk@stusta.de> wrote:
> > 
> >> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
> >> that are not yet fixed in Linus' tree.
> > 
> > There are still a few things hanging around.
> > 
> > I have these queued:
> > 
> > aio-fix-buggy-put_ioctx-call-in-aio_complete-v2.patch
> > kexec-avoid-migration-of-already-disabled-irqs-ia64.patch
> > net-smc911x-match-up-spin-lock-unlock.patch
> > rtc-pcf8563-detect-polarity-of-century-bit-automatically.patch
> > alpha-fix-epoll-syscall-enumerations.patch
> > revert-blockdev-direct-io-back-to-2619-version.patch
> > scsi-sd-udev-accessing-an-uninitialized-scsi_disk-results-in-a-crash.patch
> > altix-more-acpi-prt-support.patch
> 
> Would you forward the x86-64 dma_noncoherent API build fix I posted? 
> Anything that uses that API won't build on x86-64 without my [simple and 
> obvious] patch.

Yup.  That's this:

--- a/include/asm-x86_64/dma-mapping.h~x86-64-define-dma-noncoherent-api-functions
+++ a/include/asm-x86_64/dma-mapping.h
@@ -63,6 +63,9 @@ static inline int dma_mapping_error(dma_
 	return (dma_addr == bad_dma_address);
 }
 
+#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
+#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
+
 extern void *dma_alloc_coherent(struct device *dev, size_t size,
 				dma_addr_t *dma_handle, gfp_t gfp);
 extern void dma_free_coherent(struct device *dev, size_t size, void *vaddr,
_

> 
> > - I have r8169-fix-a-race-between-pci-probe-and-dev_open.patch floating
> >   about, but I forget its status.  
> 
> I posted a preferred patch (which someone then noted need to use 
> setup_timer), and am waiting for an "it works" response of some sort

OK, thanks, I'll drop it.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03  0:44 ` 2.6.20-rc7: known regressions (v2) (part 1) Adrian Bunk
@ 2007-02-03  6:06   ` Auke Kok
  2007-02-03  7:41     ` Eric W. Biederman
  0 siblings, 1 reply; 61+ messages in thread
From: Auke Kok @ 2007-02-03  6:06 UTC (permalink / raw)
  To: Adrian Bunk, Adam Kropelin
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	jgarzik, alan, Allen Parker, Auke Kok, jesse.brandeburg, gregkh,
	linux-pci, ebiederm, netdev

Adrian Bunk wrote:
> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
> that are not yet fixed in Linus' tree.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.


> Subject    : e1000: 82571EB/82572EI PCI-E cards: link is always down
>              (MSI related)
> References : http://lkml.org/lkml/2007/1/16/27
>              http://lkml.org/lkml/2007/1/17/182
> Submitter  : Allen Parker <parker@isohunt.com>
>              Adam Kropelin <akropel1@rochester.rr.com>
> Handled-By : Auke Kok <auke-jan.h.kok@intel.com>
> Status     : problem is being debugged

I probably can't fix this bug. Not only do I doubt that the e1000 driver is at 
fault here, I don't have a system with this particular chipset. Most likely the 
regression comes from a combination of MSI layer rewrites and possibly platform 
issues. We've seen many reports that are similar and all are on the platform 
type mentioned here. I really don't want to point fingers here either.

None of the MSI code in e1000 has changed significantly either. as far as I can 
see, the msi code in e1000 has not changed since 2.6.18. Nonetheless there's no 
way I can debug any of this without a system.

I will address the fact that we are lacking any of these systems to test on, but 
that is not going to get this issue handled (not to mention soon) in the way it 
needs to be.

I strongly encourage the people on the linux-pci list to help out, I'll trace 
the e1000 driver for suspicious activity (again), but I run countless tests on 
the latest trees and nothing has shown up recently, other than Eric Biederman's 
msi irq reclaim leak fix.

Perhaps Adam can git-bisect this issue? Adam?

Cheers,

Auke

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03  6:06   ` Auke Kok
@ 2007-02-03  7:41     ` Eric W. Biederman
  2007-02-03 18:06       ` Adam Kropelin
  0 siblings, 1 reply; 61+ messages in thread
From: Eric W. Biederman @ 2007-02-03  7:41 UTC (permalink / raw)
  To: Auke Kok
  Cc: Adrian Bunk, Adam Kropelin, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, ebiederm, netdev

Auke Kok <auke-jan.h.kok@intel.com> writes:

> Adrian Bunk wrote:
>> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
>> that are not yet fixed in Linus' tree.
>>
>> If you find your name in the Cc header, you are either submitter of one
>> of the bugs, maintainer of an affectected subsystem or driver, a patch
>> of you caused a breakage or I'm considering you in any other way possibly
>> involved with one or more of these issues.
>
>
>> Subject    : e1000: 82571EB/82572EI PCI-E cards: link is always down
>>              (MSI related)
>> References : http://lkml.org/lkml/2007/1/16/27
>>              http://lkml.org/lkml/2007/1/17/182
>> Submitter  : Allen Parker <parker@isohunt.com>
>>              Adam Kropelin <akropel1@rochester.rr.com>
>> Handled-By : Auke Kok <auke-jan.h.kok@intel.com>
>> Status     : problem is being debugged
>
> I probably can't fix this bug. Not only do I doubt that the e1000 driver is at
> fault here, I don't have a system with this particular chipset. Most likely the
> regression comes from a combination of MSI layer rewrites and possibly platform
> issues. We've seen many reports that are similar and all are on the platform
> type mentioned here. I really don't want to point fingers here either.
>
> None of the MSI code in e1000 has changed significantly either. as far as I can
> see, the msi code in e1000 has not changed since 2.6.18. Nonetheless there's no
> way I can debug any of this without a system.
>
> I will address the fact that we are lacking any of these systems to test on, but
> that is not going to get this issue handled (not to mention soon) in the way it
> needs to be.
>
> I strongly encourage the people on the linux-pci list to help out, I'll trace
> the e1000 driver for suspicious activity (again), but I run countless tests on
> the latest trees and nothing has shown up recently, other than Eric Biederman's
> msi irq reclaim leak fix.
>
> Perhaps Adam can git-bisect this issue? Adam?

Do we have any explanation about the weird /proc/interrupts output?
i.e. Multiple MSI irqs being assigned to the same card?

Does /sbin/ifconfig ethN down ; /sbin/ifconfig ethN up have anything to do
with the duplication in /proc/interrupts?

I can't see any way for a pci device that doesn't support msi-x to be assigned
multiple interrupts simultaneously.

I just skimmed through the code and there hasn't been any significant
generic MSI work since 2.6.19.

Did this device really work with MSI enabled in 2.6.19?

Eric

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03  1:55   ` Andrew Morton
  2007-02-03  2:03     ` Jeff Garzik
@ 2007-02-03  9:19     ` Frédéric Riss
  2007-02-03  9:24       ` Andrew Morton
  1 sibling, 1 reply; 61+ messages in thread
From: Frédéric Riss @ 2007-02-03  9:19 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List,
	Eric Van Hensbergen, Trond Myklebust, Neil Brown,
	Stephen Hemminger, Benjamin Herrenschmidt, Andi Kleen,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

Le vendredi 02 février 2007 à 17:55 -0800, Andrew Morton a écrit :
> - I have efi-x86-pass-firmware-call-parameters-on-the-stack.patch, but
>   I'm not sure it's right and unless something really rapid happens, we'll
>   ship with that bug unfixed.

Things I can say:
 - Works for me :-)
 - When you look at the code, it's obvious that switching to -mregparm=3
changed the way we call into EFI runtime services. If you consider that
that old code was correct, then the patch is needed to keep the good
calling convention.
 - It touches only arch/i386/kernel/efi.c which is compiled only with
CONFIG_EFI && X86
 - It changes code that is called only when booted in EFI mode.

Last 2 points mean the user base is pretty limited, which can be taken
both as an argument to push it for the release or not to. I'd obviously
prefer that someone knowledgeable about EFI looks at it and ACKs before
it goes in.

Fred.


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03  9:19     ` Frédéric Riss
@ 2007-02-03  9:24       ` Andrew Morton
  2007-02-03  9:33         ` Andi Kleen
  0 siblings, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2007-02-03  9:24 UTC (permalink / raw)
  To: Frédéric Riss, Matt Domsch
  Cc: Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List,
	Eric Van Hensbergen, Trond Myklebust, Neil Brown,
	Stephen Hemminger, Benjamin Herrenschmidt, Andi Kleen,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

On Sat, 03 Feb 2007 10:19:51 +0100 Frédéric Riss <frederic.riss@gmail.com> wrote:

> Le vendredi 02 février 2007 à 17:55 -0800, Andrew Morton a écrit :
> > - I have efi-x86-pass-firmware-call-parameters-on-the-stack.patch, but
> >   I'm not sure it's right and unless something really rapid happens, we'll
> >   ship with that bug unfixed.
> 
> Things I can say:
>  - Works for me :-)
>  - When you look at the code, it's obvious that switching to -mregparm=3
> changed the way we call into EFI runtime services. If you consider that
> that old code was correct, then the patch is needed to keep the good
> calling convention.
>  - It touches only arch/i386/kernel/efi.c which is compiled only with
> CONFIG_EFI && X86
>  - It changes code that is called only when booted in EFI mode.
> 
> Last 2 points mean the user base is pretty limited, which can be taken
> both as an argument to push it for the release or not to. I'd obviously
> prefer that someone knowledgeable about EFI looks at it and ACKs before
> it goes in.
> 

OK, well here it is again for everyone's reviwing pleasure:


From: Frederic Riss <frederic.riss@gmail.com>

When calling into the EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This patch is needed to allow the new Intel-based Macs to suspend to ram
(efi.get_time is called during the suspend phase).

Signed-off-by: Frederic Riss <frederic.riss@gmail.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: <artiom.myaskouvskey@intel.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 arch/i386/kernel/efi.c |   89 +++++++++++++++++++++++++++++++--------
 1 files changed, 73 insertions(+), 16 deletions(-)

diff -puN arch/i386/kernel/efi.c~efi-x86-pass-firmware-call-parameters-on-the-stack arch/i386/kernel/efi.c
--- a/arch/i386/kernel/efi.c~efi-x86-pass-firmware-call-parameters-on-the-stack
+++ a/arch/i386/kernel/efi.c
@@ -473,6 +473,70 @@ static inline void __init check_range_fo
 }
 
 /*
+ * Wrap all the virtual calls in a way that forces the parameters on the stack.
+ */
+
+#define efi_call_virt(f, args...) \
+     ((efi_##f##_t __attribute__((regparm(0)))*)efi.systab->runtime->f)(args)
+
+static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+{
+	return efi_call_virt(get_time, tm, tc);
+}
+
+static efi_status_t virt_efi_set_time (efi_time_t *tm)
+{
+	return efi_call_virt(set_time, tm);
+}
+
+static efi_status_t virt_efi_get_wakeup_time (efi_bool_t *enabled,
+					      efi_bool_t *pending,
+					      efi_time_t *tm)
+{
+	return efi_call_virt(get_wakeup_time, enabled, pending, tm);
+}
+
+static efi_status_t virt_efi_set_wakeup_time (efi_bool_t enabled,
+					      efi_time_t *tm)
+{
+	return efi_call_virt(set_wakeup_time, enabled, tm);
+}
+
+static efi_status_t virt_efi_get_variable (efi_char16_t *name,
+					   efi_guid_t *vendor, u32 *attr,
+					   unsigned long *data_size, void *data)
+{
+	return efi_call_virt(get_variable, name, vendor, attr, data_size, data);
+}
+
+static efi_status_t virt_efi_get_next_variable (unsigned long *name_size,
+						efi_char16_t *name,
+						efi_guid_t *vendor)
+{
+	return efi_call_virt(get_next_variable, name_size, name, vendor);
+}
+
+static efi_status_t virt_efi_set_variable (efi_char16_t *name,
+					   efi_guid_t *vendor,
+					   unsigned long attr,
+					   unsigned long data_size, void *data)
+{
+	return efi_call_virt(set_variable, name, vendor, attr, data_size, data);
+}
+
+static efi_status_t virt_efi_get_next_high_mono_count (u32 *count)
+{
+	return efi_call_virt(get_next_high_mono_count, count);
+}
+
+static void virt_efi_reset_system (int reset_type, efi_status_t status,
+				   unsigned long data_size,
+				   efi_char16_t *data)
+{
+	efi_call_virt(reset_system, reset_type, status, data_size, data);
+}
+
+/*
  * This function will switch the EFI runtime services to virtual mode.
  * Essentially, look through the EFI memmap and map every region that
  * has the runtime attribute bit set in its memory descriptor and update
@@ -525,22 +589,15 @@ void __init efi_enter_virtual_mode(void)
 	 * pointers in the runtime service table to the new virtual addresses.
 	 */
 
-	efi.get_time = (efi_get_time_t *) efi.systab->runtime->get_time;
-	efi.set_time = (efi_set_time_t *) efi.systab->runtime->set_time;
-	efi.get_wakeup_time = (efi_get_wakeup_time_t *)
-					efi.systab->runtime->get_wakeup_time;
-	efi.set_wakeup_time = (efi_set_wakeup_time_t *)
-					efi.systab->runtime->set_wakeup_time;
-	efi.get_variable = (efi_get_variable_t *)
-					efi.systab->runtime->get_variable;
-	efi.get_next_variable = (efi_get_next_variable_t *)
-					efi.systab->runtime->get_next_variable;
-	efi.set_variable = (efi_set_variable_t *)
-					efi.systab->runtime->set_variable;
-	efi.get_next_high_mono_count = (efi_get_next_high_mono_count_t *)
-					efi.systab->runtime->get_next_high_mono_count;
-	efi.reset_system = (efi_reset_system_t *)
-					efi.systab->runtime->reset_system;
+	efi.get_time = virt_efi_get_time;
+	efi.set_time = virt_efi_set_time;
+	efi.get_wakeup_time = virt_efi_get_wakeup_time;
+	efi.set_wakeup_time = virt_efi_set_wakeup_time;
+	efi.get_variable = virt_efi_get_variable;
+	efi.get_next_variable = virt_efi_get_next_variable;
+	efi.set_variable = virt_efi_set_variable;
+	efi.get_next_high_mono_count = virt_efi_get_next_high_mono_count;
+	efi.reset_system = virt_efi_reset_system;
 }
 
 void __init
_


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03  9:24       ` Andrew Morton
@ 2007-02-03  9:33         ` Andi Kleen
  2007-02-03  9:49           ` Frédéric Riss
  0 siblings, 1 reply; 61+ messages in thread
From: Andi Kleen @ 2007-02-03  9:33 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Frédéric Riss, Matt Domsch, Adrian Bunk,
	Linus Torvalds, Linux Kernel Mailing List, Eric Van Hensbergen,
	Trond Myklebust, Neil Brown, Stephen Hemminger,
	Benjamin Herrenschmidt, Jeff Garzik, Eric W. Biederman,
	Francois Romieu


>  /*
> + * Wrap all the virtual calls in a way that forces the parameters on the stack.
> + */
> +
> +#define efi_call_virt(f, args...) \
> +     ((efi_##f##_t __attribute__((regparm(0)))*)efi.systab->runtime->f)(args)
> +
> +static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> +{
> +	return efi_call_virt(get_time, tm, tc);

Wouldn't it be better to just declare the pointers in efi.systab with 
the correct attribute?  Then you wouldn't need all that ugly casting.

-Andi

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03  9:33         ` Andi Kleen
@ 2007-02-03  9:49           ` Frédéric Riss
  2007-02-03  9:58             ` Andi Kleen
  0 siblings, 1 reply; 61+ messages in thread
From: Frédéric Riss @ 2007-02-03  9:49 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, Matt Domsch, Adrian Bunk, Linus Torvalds,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

Le samedi 03 février 2007 à 10:33 +0100, Andi Kleen a écrit :
> >  /*
> > + * Wrap all the virtual calls in a way that forces the parameters on the stack.
> > + */
> > +
> > +#define efi_call_virt(f, args...) \
> > +     ((efi_##f##_t __attribute__((regparm(0)))*)efi.systab->runtime->f)(args)
> > +
> > +static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> > +{
> > +	return efi_call_virt(get_time, tm, tc);
> 
> Wouldn't it be better to just declare the pointers in efi.systab with 
> the correct attribute?  Then you wouldn't need all that ugly casting.

Was what I did in the initial patch: 
     http://lkml.org/lkml/2007/1/30/258 

The issue is that the structure definition is used on multiple
architectures (for now ia64 and i386) which might used different calling
conventions. As Bjorn Helgaas pointed out, ia64 already has such wrapper
functions. I agree that the casting isn't the nicest thing, but I prefer
that to writing asm stubs.

Fred


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03  9:49           ` Frédéric Riss
@ 2007-02-03  9:58             ` Andi Kleen
  2007-02-03 10:47               ` Frédéric Riss
  0 siblings, 1 reply; 61+ messages in thread
From: Andi Kleen @ 2007-02-03  9:58 UTC (permalink / raw)
  To: Frédéric Riss
  Cc: Andrew Morton, Matt Domsch, Adrian Bunk, Linus Torvalds,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

On Saturday 03 February 2007 10:49, Frédéric Riss wrote:

> Was what I did in the initial patch: 
>      http://lkml.org/lkml/2007/1/30/258 
> 
> The issue is that the structure definition is used on multiple
> architectures (for now ia64 and i386) which might used different calling
> conventions. As Bjorn Helgaas pointed out, ia64 already has such wrapper
> functions. I agree that the casting isn't the nicest thing, but I prefer
> that to writing asm stubs.

Define a efilinkage macro then that expands to nothing on ia64

Probably asmlinkage would work already, syscall_linkage as used on ia64 doesn't
seem to affect function pointers.

-Andi

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03  9:58             ` Andi Kleen
@ 2007-02-03 10:47               ` Frédéric Riss
  2007-02-03 10:51                 ` Andi Kleen
  0 siblings, 1 reply; 61+ messages in thread
From: Frédéric Riss @ 2007-02-03 10:47 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, Matt Domsch, Adrian Bunk, Linus Torvalds,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

Le samedi 03 février 2007 à 10:58 +0100, Andi Kleen a écrit :
> Define a efilinkage macro then that expands to nothing on ia64
> 
> Probably asmlinkage would work already, syscall_linkage as used on ia64 doesn't
> seem to affect function pointers.

And here it goes:

When calling into the EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This patch is needed to allow the new Intel-based Macs to suspend to ram
(efi.get_time is called during the suspend phase).

Signed-off-by: Frederic Riss <frederic.riss@gmail.com>
---

diff --git a/include/linux/efi.h b/include/linux/efi.h
index f8ebd7c..596e806 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -157,22 +157,39 @@ typedef struct {
 	unsigned long reset_system;
 } efi_runtime_services_t;
 
-typedef efi_status_t efi_get_time_t (efi_time_t *tm, efi_time_cap_t *tc);
-typedef efi_status_t efi_set_time_t (efi_time_t *tm);
-typedef efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, efi_bool_t *pending,
-					    efi_time_t *tm);
-typedef efi_status_t efi_set_wakeup_time_t (efi_bool_t enabled, efi_time_t *tm);
-typedef efi_status_t efi_get_variable_t (efi_char16_t *name, efi_guid_t *vendor, u32 *attr,
-					 unsigned long *data_size, void *data);
-typedef efi_status_t efi_get_next_variable_t (unsigned long *name_size, efi_char16_t *name,
-					      efi_guid_t *vendor);
-typedef efi_status_t efi_set_variable_t (efi_char16_t *name, efi_guid_t *vendor, 
-					 unsigned long attr, unsigned long data_size, 
-					 void *data);
-typedef efi_status_t efi_get_next_high_mono_count_t (u32 *count);
-typedef void efi_reset_system_t (int reset_type, efi_status_t status,
-				 unsigned long data_size, efi_char16_t *data);
-typedef efi_status_t efi_set_virtual_address_map_t (unsigned long memory_map_size,
+#ifdef CONFIG_X86_32
+#define efilinkage asmlinkage
+#else
+#define efilinkage
+#endif
+
+typedef efilinkage efi_status_t efi_get_time_t (efi_time_t *tm,
+						efi_time_cap_t *tc);
+typedef efilinkage efi_status_t efi_set_time_t (efi_time_t *tm);
+typedef efilinkage efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, 
+						       efi_bool_t *pending,
+						       efi_time_t *tm);
+typedef efilinkage efi_status_t efi_set_wakeup_time_t (efi_bool_t enabled,
+						       efi_time_t *tm);
+typedef efilinkage efi_status_t efi_get_variable_t (efi_char16_t *name,
+						    efi_guid_t *vendor,
+						    u32 *attr,
+						    unsigned long *data_size,
+						    void *data);
+typedef efilinkage efi_status_t efi_get_next_variable_t (unsigned long *name_sz,
+							 efi_char16_t *name,
+							 efi_guid_t *vendor);
+typedef efilinkage efi_status_t efi_set_variable_t (efi_char16_t *name,
+						    efi_guid_t *vendor,
+						    unsigned long attr,
+						    unsigned long data_size,
+						    void *data);
+typedef efilinkage efi_status_t efi_get_next_high_mono_count_t (u32 *count);
+typedef efilinkage void efi_reset_system_t (int reset_type, 
+					    efi_status_t status,
+					    unsigned long data_size,
+					    efi_char16_t *data);
+typedef efilinkage efi_status_t efi_set_virtual_address_map_t (unsigned long memory_map_size,
 						unsigned long descriptor_size,
 						u32 descriptor_version,
 						efi_memory_desc_t *virtual_map);




^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03 10:47               ` Frédéric Riss
@ 2007-02-03 10:51                 ` Andi Kleen
  2007-02-03 10:57                   ` Frédéric Riss
  2007-02-04 13:13                   ` Frédéric Riss
  0 siblings, 2 replies; 61+ messages in thread
From: Andi Kleen @ 2007-02-03 10:51 UTC (permalink / raw)
  To: Frédéric Riss
  Cc: Andrew Morton, Matt Domsch, Adrian Bunk, Linus Torvalds,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu


> +#ifdef CONFIG_X86_32
> +#define efilinkage asmlinkage
> +#else
> +#define efilinkage
> +#endif

No ifdefs, this should be somewhere in the headers for the EFI supporting
architectures

But I suspect you could actually get away with just using asmlinkage
(after reviewing the ia64 asmlinkage I think it's ok)

x86-64 when it is ever implemented will always need asm stubs though
because it uses completely incompatible calling conventions.

> +
> +typedef efilinkage efi_status_t efi_get_time_t (efi_time_t *tm,
> +						efi_time_cap_t *tc);

I assume you have double checked it actually works? (i vaguely recall some
issues with applying attributes to typedefs). If not you would need
to put them to the declarations.

-Andi

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03 10:51                 ` Andi Kleen
@ 2007-02-03 10:57                   ` Frédéric Riss
  2007-02-03 11:08                     ` Frédéric RISS
  2007-02-04 13:13                   ` Frédéric Riss
  1 sibling, 1 reply; 61+ messages in thread
From: Frédéric Riss @ 2007-02-03 10:57 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, Matt Domsch, Adrian Bunk, Linus Torvalds,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

Le samedi 03 février 2007 à 11:51 +0100, Andi Kleen a écrit :
> > +
> > +typedef efilinkage efi_status_t efi_get_time_t (efi_time_t *tm,
> > +						efi_time_cap_t *tc);
> 
> I assume you have double checked it actually works? (i vaguely recall some
> issues with applying attributes to typedefs). If not you would need
> to put them to the declarations.

Of course, I tested 10 suspend/resume cycles. This is with gcc 4.1.2, I
guess other compilers could mishandle it. Would you prefer the version
putting asmlinkage inside the struct definition?

Fred.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03 10:57                   ` Frédéric Riss
@ 2007-02-03 11:08                     ` Frédéric RISS
  0 siblings, 0 replies; 61+ messages in thread
From: Frédéric RISS @ 2007-02-03 11:08 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, Matt Domsch, Adrian Bunk, Linus Torvalds,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

Le samedi 03 février 2007 à 11:57 +0100, Frédéric Riss a écrit :
> Le samedi 03 février 2007 à 11:51 +0100, Andi Kleen a écrit :
> > > +
> > > +typedef efilinkage efi_status_t efi_get_time_t (efi_time_t *tm,
> > > +						efi_time_cap_t *tc);
> > 
> > I assume you have double checked it actually works? (i vaguely recall some
> > issues with applying attributes to typedefs). If not you would need
> > to put them to the declarations.
> 
> Of course, I tested 10 suspend/resume cycles. This is with gcc 4.1.2, I
> guess other compilers could mishandle it. Would you prefer the version
> putting asmlinkage inside the struct definition?

But then it then throws 'assignment from incompatible pointer type'
warnings in efi.c. This would need fixing in arch/ia64 and arch/i386. Or
should I put it in the typdefs _and_ in the struct to be safe ?

Fred


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03  7:41     ` Eric W. Biederman
@ 2007-02-03 18:06       ` Adam Kropelin
  2007-02-03 20:43         ` Auke Kok
  0 siblings, 1 reply; 61+ messages in thread
From: Adam Kropelin @ 2007-02-03 18:06 UTC (permalink / raw)
  To: Eric W. Biederman, Auke Kok
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, ebiederm, netdev

Eric W. Biederman wrote:
> Auke Kok <auke-jan.h.kok@intel.com> writes:
>> None of the MSI code in e1000 has changed significantly either. as
>> far as I can see, the msi code in e1000 has not changed since
>> 2.6.18. Nonetheless there's no way I can debug any of this without a
>> system.
>> [...]
>> Perhaps Adam can git-bisect this issue? Adam?
>
> Do we have any explanation about the weird /proc/interrupts output?
> i.e. Multiple MSI irqs being assigned to the same card?
>
> Does /sbin/ifconfig ethN down ; /sbin/ifconfig ethN up have anything
> to do with the duplication in /proc/interrupts?
>
> I can't see any way for a pci device that doesn't support msi-x to be
> assigned multiple interrupts simultaneously.
>
> I just skimmed through the code and there hasn't been any significant
> generic MSI work since 2.6.19.
>
> Did this device really work with MSI enabled in 2.6.19?

I've never had this device work 100% with MSI on any kernel version I've 
tested so far. But I'm not the original reporter of the problem, and I 
believe for him it was a true regression where a previous kernel wored 
correctly.

The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link status 
interrupts seem to work but rx/tx does not. A few more details here:
<http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450&db_name=linux_kernel>

I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report 
back any variations in behavior I notice.

--Adam


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03 18:06       ` Adam Kropelin
@ 2007-02-03 20:43         ` Auke Kok
  2007-02-03 21:00           ` Adam Kropelin
  2007-02-03 21:12           ` Eric W. Biederman
  0 siblings, 2 replies; 61+ messages in thread
From: Auke Kok @ 2007-02-03 20:43 UTC (permalink / raw)
  To: Adam Kropelin
  Cc: Eric W. Biederman, Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, netdev

Adam Kropelin wrote:
 > Eric W. Biederman wrote:
 >> Auke Kok <auke-jan.h.kok@intel.com> writes:
 >>> None of the MSI code in e1000 has changed significantly either. as
 >>> far as I can see, the msi code in e1000 has not changed since
 >>> 2.6.18. Nonetheless there's no way I can debug any of this without a
 >>> system.
 >>> [...]
 >>> Perhaps Adam can git-bisect this issue? Adam?
 >> Do we have any explanation about the weird /proc/interrupts output?
 >> i.e. Multiple MSI irqs being assigned to the same card?
 >>
 >> Does /sbin/ifconfig ethN down ; /sbin/ifconfig ethN up have anything
 >> to do with the duplication in /proc/interrupts?
 >>
 >> I can't see any way for a pci device that doesn't support msi-x to be
 >> assigned multiple interrupts simultaneously.
 >>
 >> I just skimmed through the code and there hasn't been any significant
 >> generic MSI work since 2.6.19.
 >>
 >> Did this device really work with MSI enabled in 2.6.19?
 >
 > I've never had this device work 100% with MSI on any kernel version I've
 > tested so far. But I'm not the original reporter of the problem, and I
 > believe for him it was a true regression where a previous kernel wored
 > correctly.

maybe I've been unclear, but here's how e1000 detects link changes:

1) by checking every 2 seconds in the watchdog by reading PHY registers
2) by receiving an interrupt from the NIC with the LSI bit in the interrupt 
control register

if the link is down to start with, the watchdog will obviously spot a 'link up' 
change since it doesn't use any interrupts.

The link interrupt (LSI) is a generic interrupt that comes over the same vector 
(be it MSI or not) as RX interrupts, and in your case doesn't arrive at all, 
which should be demonstrateable if you set e.g. the watchdog interval to 30 
seconds and unplug the cable - the driver won't spot the link change until the 
watchdog fires a lot later than you unplugged the cable.

 > The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link status
 > interrupts seem to work but rx/tx does not. A few more details here:
 > 
<http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450&db_name=linux_kernel>

 > I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report
 > back any variations in behavior I notice.

that would be a good start, but I still think that you might have a broken 
bridge on that system. Anyway, thanks for digging into this.

Auke

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03 20:43         ` Auke Kok
@ 2007-02-03 21:00           ` Adam Kropelin
  2007-02-03 21:26             ` Auke Kok
  2007-02-03 21:12           ` Eric W. Biederman
  1 sibling, 1 reply; 61+ messages in thread
From: Adam Kropelin @ 2007-02-03 21:00 UTC (permalink / raw)
  To: Auke Kok
  Cc: Eric W. Biederman, Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, netdev

Auke Kok wrote:
> Adam Kropelin wrote:
>> I've never had this device work 100% with MSI on any kernel version
>> I've tested so far. But I'm not the original reporter of the
>> problem, and I believe for him it was a true regression where a
>> previous kernel wored correctly.
>
> maybe I've been unclear, but here's how e1000 detects link changes:
>
> 1) by checking every 2 seconds in the watchdog by reading PHY
> registers

That would explain why I see link status changes but 0 interrupt count 
in /proc/interrupts. However, on >= 2.6.19 the link state never changes. 
Ever. It's always down. On <= 2.6.18 the link state does change but with 
0 interupt count.

> 2) by receiving an interrupt from the NIC with the LSI bit
> in the interrupt control register
>
> if the link is down to start with, the watchdog will obviously spot a
> 'link up' change since it doesn't use any interrupts.

This does not seem to work on 2.6.19+. Unless the watchdog interval is 
tens of minutes. I've waited at least 5 minutes and link never went up.

>> The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link
>> status interrupts seem to work but rx/tx does not. A few more
>> details here:
> <http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450&db_name=linux_kernel>
>
>> I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report
>> back any variations in behavior I notice.
>
> that would be a good start, but I still think that you might have a
> broken bridge on that system. Anyway, thanks for digging into this.

Will continue to dig.

--Adam


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03 20:43         ` Auke Kok
  2007-02-03 21:00           ` Adam Kropelin
@ 2007-02-03 21:12           ` Eric W. Biederman
  2007-02-03 23:20             ` Adam Kropelin
  1 sibling, 1 reply; 61+ messages in thread
From: Eric W. Biederman @ 2007-02-03 21:12 UTC (permalink / raw)
  To: Auke Kok
  Cc: Adam Kropelin, Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, netdev

Auke Kok <auke-jan.h.kok@intel.com> writes:

> maybe I've been unclear, but here's how e1000 detects link changes:
>
> 1) by checking every 2 seconds in the watchdog by reading PHY registers
> 2) by receiving an interrupt from the NIC with the LSI bit in the interrupt
> control register
>
> if the link is down to start with, the watchdog will obviously spot a 'link up'
> change since it doesn't use any interrupts.
>
> The link interrupt (LSI) is a generic interrupt that comes over the same vector
> (be it MSI or not) as RX interrupts, and in your case doesn't arrive at all,
> which should be demonstrateable if you set e.g. the watchdog interval to 30
> seconds and unplug the cable - the driver won't spot the link change until the
> watchdog fires a lot later than you unplugged the cable.
>
>> The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link status
>> interrupts seem to work but rx/tx does not. A few more details here:
>>
> <http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450&db_name=linux_kernel>
>
>> I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report
>> back any variations in behavior I notice.
>
> that would be a good start, but I still think that you might have a broken
> bridge on that system. Anyway, thanks for digging into this.

Right.  The basic question is on a problem system are MSI interrupts
from the card in /proc/interrupts observed.  If interrupts are not
observed (as it sounds like is the case) it is most likely something
outside of the card, and driver.  If interrupts are observed but the
card does not work correctly it could be a card or driver bug.

Ok.  In the archives I finally found the output of cat
/proc/interrupts and there were none.

This is a PCI-E to Hypertransport system from the lspci output.

Can I get the corresponding lspci -xxx output.  I suspect the BIOS
did not program the hypertransport MSI mapping capabilities correctly.
All it has to do is set the enable but still, occasionally BIOS
writers miss the most amazing things.

If that is the case with just a little creativity we should be able to
write a pci quirk that will enable the MSI mapping capability on this
class of systems and save ourselves a lot of trouble.

Although I thought I did see a quirk that disabled MSI if the enable
bit was not set.  Hmm.

Anyway please the lspci -xxx output.  Although if someone could teach
lspci to decode the hypertransport MSI mapping capability so that
lspic -vvv gave us this information that would be great too.

Eric

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03 21:00           ` Adam Kropelin
@ 2007-02-03 21:26             ` Auke Kok
  2007-02-03 22:24               ` Eric W. Biederman
  0 siblings, 1 reply; 61+ messages in thread
From: Auke Kok @ 2007-02-03 21:26 UTC (permalink / raw)
  To: Adam Kropelin
  Cc: Auke Kok, Eric W. Biederman, Adrian Bunk, Linus Torvalds,
	Andrew Morton, Linux Kernel Mailing List, jgarzik, alan,
	Allen Parker, jesse.brandeburg, gregkh, linux-pci, netdev

Adam Kropelin wrote:
> Auke Kok wrote:
>> Adam Kropelin wrote:
>>> I've never had this device work 100% with MSI on any kernel version
>>> I've tested so far. But I'm not the original reporter of the
>>> problem, and I believe for him it was a true regression where a
>>> previous kernel wored correctly.
>> maybe I've been unclear, but here's how e1000 detects link changes:
>>
>> 1) by checking every 2 seconds in the watchdog by reading PHY
>> registers
> 
> That would explain why I see link status changes but 0 interrupt count 
> in /proc/interrupts. However, on >= 2.6.19 the link state never changes. 
> Ever. It's always down. On <= 2.6.18 the link state does change but with 
> 0 interupt count.
> 
>> 2) by receiving an interrupt from the NIC with the LSI bit
>> in the interrupt control register
>>
>> if the link is down to start with, the watchdog will obviously spot a
>> 'link up' change since it doesn't use any interrupts.
> 
> This does not seem to work on 2.6.19+. Unless the watchdog interval is 
> tens of minutes. I've waited at least 5 minutes and link never went up.

that's explained by a driver change that did that. Since at initialization we're 
basically waiting for a link change to tell the stack that we're up, we decided 
to change the order to have the hardware fire an LSI interrupt to trigger a 
watchdog run. So no interrupts would immediately explain why the watchdog never 
runs. That's nothing to worry about for this problem, as soon as interrupts are 
seen in /proc/interrupts this all starts working for e1000.

Cheers,

Auke

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03 21:26             ` Auke Kok
@ 2007-02-03 22:24               ` Eric W. Biederman
  0 siblings, 0 replies; 61+ messages in thread
From: Eric W. Biederman @ 2007-02-03 22:24 UTC (permalink / raw)
  To: Auke Kok
  Cc: Adam Kropelin, Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, netdev

Auke Kok <auke-jan.h.kok@intel.com> writes:

> that's explained by a driver change that did that. Since at initialization we're
> basically waiting for a link change to tell the stack that we're up, we decided
> to change the order to have the hardware fire an LSI interrupt to trigger a
> watchdog run. So no interrupts would immediately explain why the watchdog never
> runs. That's nothing to worry about for this problem, as soon as interrupts are
> seen in /proc/interrupts this all starts working for e1000.


While I think we need to fix this issue, and in general the issue of MSI
interrupts on PCI-Express busses downstream of hypertransport chains.
This e1000 issue is not a regression, so not fixing it for 2.6.20 is
not a big deal.

I have yet to see all of the pieces I'm trying to look at confirmed,
but I believe by at least looking at the hypertransport MSI mapping
capability's enable bit in general we should be able to do a much
better job of detecting if MSI works in a system or not.

I though someone several months ago had made our MSI supported detect logic
a lot smarter, with defaults that were generally correct, but looking
at the kernel that code apparently never made it anywhere.  Instead
all I see are a handful of common chipsets special cased by the quirk logic.

We should be able to do a lot better but not in the 2.6.20 time frame.

As for the original problem report with duplicate MSI interrupts in
/proc/interrupts.  That sounds like a regression and is probably
simple to fix if we can get some more details.

Eric

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03 21:12           ` Eric W. Biederman
@ 2007-02-03 23:20             ` Adam Kropelin
  2007-02-04  1:14               ` Eric W. Biederman
  0 siblings, 1 reply; 61+ messages in thread
From: Adam Kropelin @ 2007-02-03 23:20 UTC (permalink / raw)
  To: Eric W. Biederman, Auke Kok
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, netdev

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

Eric W. Biederman wrote:
> Auke Kok <auke-jan.h.kok@intel.com> writes:
>
>> maybe I've been unclear, but here's how e1000 detects link changes:
>>
>> 1) by checking every 2 seconds in the watchdog by reading PHY
>> registers 2) by receiving an interrupt from the NIC with the LSI bit
>> in the interrupt control register
>>
>> if the link is down to start with, the watchdog will obviously spot
>> a 'link up' change since it doesn't use any interrupts.
>>
>> The link interrupt (LSI) is a generic interrupt that comes over the
>> same vector (be it MSI or not) as RX interrupts, and in your case
>> doesn't arrive at all, which should be demonstrateable if you set
>> e.g. the watchdog interval to 30 seconds and unplug the cable - the
>> driver won't spot the link change until the watchdog fires a lot
>> later than you unplugged the cable.
>>
>>> The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link
>>> status interrupts seem to work but rx/tx does not. A few more
>>> details here:
>>>
>> <http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450&db_name=linux_kernel>
>
> Can I get the corresponding lspci -xxx output.  I suspect the BIOS
> did not program the hypertransport MSI mapping capabilities correctly.
> All it has to do is set the enable but still, occasionally BIOS
> writers miss the most amazing things.

Here you go. This is from 2.6.20-rc7.

--Adam

[-- Attachment #2: lspci-2.6.20-rc7 --]
[-- Type: application/octet-stream, Size: 25954 bytes --]

00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00: de 10 f0 02 06 00 b0 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 f0 02
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00
40: de 10 f0 02 08 e0 e0 01 22 00 11 11 22 20 11 00
50: 23 06 7f 80 03 05 7f 80 00 00 03 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 06 36 05 00
70: 44 44 41 00 d0 09 00 00 11 00 00 00 11 11 88 00
80: 23 99 88 00 1f 00 64 0c 03 00 00 00 7f 00 00 00
90: 78 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 01 01 01 01 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 61 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 08 00 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 10
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00: de 10 fa 02 00 01 20 40 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 fa 02
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 10 00 21 21 14 00 11 11 00 00 03 00 00 00
60: 21 88 13 02 de 8f e1 1f 08 72 4e 10 02 3f 00 20
70: 10 32 54 0a 10 00 00 00 a0 00 00 00 10 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 50 3f 90 3f 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 01 00 00 00 80 f9 fd 00
e0: 00 00 c9 fe 00 00 00 00 00 fc ff ff 00 00 00 00
f0: 00 00 00 00 c7 02 28 00 00 00 00 00 00 00 00 00

00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00: de 10 fe 02 00 00 20 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 fe 02
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: de 10 fe 02 1b 1c 1c 60 1b 1c c0 21 00 00 00 00
50: 36 00 38 c9 01 00 00 00 37 00 39 c9 02 1f 1c 80
60: 02 1f 1c 00 00 00 00 00 02 10 1c a0 02 0c 1c 90
70: 02 10 1c 90 02 14 1c 90 02 0c 1c 80 02 10 1c 80
80: 02 14 1c 80 02 18 1c 80 02 1c 1c 80 01 10 1c 80
90: 02 14 1c 80 11 00 11 00 32 01 00 00 00 00 00 00
a0: c2 00 40 61 10 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 41 23 05 08
c0: fd ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00: de 10 f8 02 00 00 a0 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 f8 02
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: de 10 f8 02 00 00 00 00 02 10 1c 80 02 10 1c a0
50: 02 0c 1c 90 02 10 1c 90 02 14 1c 90 02 0c 1c 80
60: 02 10 1c 80 02 14 1c 80 02 18 1c 80 02 1c 1c 80
70: 01 10 1c 80 1f 20 c0 81 00 00 00 00 3e 30 40 c9
80: 01 00 00 00 45 30 47 c9 02 1f 1c 80 50 20 00 40
90: 89 da 01 09 00 00 00 00 11 00 10 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 08 00 00 00 22 19 00 00 10 00 02 00 40 04 40 04
c0: 00 00 00 00 00 00 00 00 01 01 00 05 00 00 00 00
d0: 00 00 f0 03 00 04 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 60 ea 10 10 18 00 00 20 00 00 00 00 00 00 00 00

00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00: de 10 f9 02 06 00 a0 00 a2 00 00 05 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 f9 02
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: ef dd 7b 2f f7 de 7b 2f f7 de 7b 2f f7 02 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00
70: 0a 00 00 00 03 00 00 00 25 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 05 00 00 00 04 00 00 00
90: 03 04 00 00 01 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: ff 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00: de 10 ff 02 06 00 b0 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 ff 02
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00
40: 17 00 00 00 00 fe fe 00 00 fe fe 00 00 fe fe 00
50: 00 fe fe 00 00 fe fe 00 00 fe fe 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00: de 10 7f 02 00 01 20 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 7f 02
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 08 00 00 00 00 00 00 00 00 80 cb fe 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00: de 10 7e 02 00 00 20 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 7e 02
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: de 10 7e 02 11 00 00 00 74 05 00 00 11 00 00 00
50: 74 05 00 00 40 00 60 00 60 60 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 04
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 04
b0: ff ff 03 00 10 11 00 00 ac 10 20 00 30 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00: de 10 fc 02 07 04 10 00 a1 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 a1 a1 00 00
20: 80 fd 80 fd 71 fd 71 fd 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 00 04 00
40: 0d 48 00 00 de 10 00 00 01 50 02 f8 00 00 00 00
50: 05 60 83 00 00 00 e0 fe 00 00 00 00 39 40 00 00
60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 10 00 41 01 c0 04 00 00 1f 28 00 00 11 3c 11 02
90: 40 00 11 30 00 00 00 00 c0 01 48 01 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00: de 10 fd 02 07 04 10 00 a1 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 00 81 81 00 00
20: e0 fd e0 fd d1 fd d1 fd 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 00 04 00
40: 0d 48 00 00 de 10 00 00 01 50 02 f8 00 00 00 00
50: 05 60 83 00 00 00 e0 fe 00 00 00 00 41 40 00 00
60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 10 00 41 01 c0 04 00 00 1f 28 00 00 11 3c 11 01
90: 00 00 11 10 00 00 00 00 c0 01 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00: de 10 fb 02 07 04 10 00 a1 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 03 03 00 b1 b1 00 00
20: c0 fd c0 fd 91 fd 91 fd 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 00 04 00
40: 0d 48 00 00 de 10 00 00 01 50 02 f8 00 00 00 00
50: 05 60 83 00 00 00 e0 fe 00 00 00 00 49 40 00 00
60: 08 80 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 10 00 41 01 c0 04 00 00 1f 28 00 00 01 3d 11 00
90: 00 00 01 11 00 00 00 00 c0 01 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express Bridge (rev a2)
00: de 10 41 02 07 00 b0 00 a2 00 00 03 00 00 00 00
10: 00 00 00 fc 0c 00 00 e0 00 00 00 00 04 00 00 fb
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 ed 01
30: 00 00 00 00 48 00 00 00 00 00 00 00 0b 01 00 00
40: 28 10 ed 01 00 00 00 00 01 50 02 00 00 00 00 00
50: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 00 00 00 04 00 00 00 00 00 00 00 01 00 00 00
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: 00 00 78 00 00 00 00 04 00 00 00 00 ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00: de 10 70 02 06 00 b0 00 a2 00 00 05 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 84 cb
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00
40: de 10 84 cb 08 e0 e9 01 22 20 00 00 d0 00 00 00
50: 23 05 7f 80 03 00 00 00 00 00 03 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 06 36 05 00
70: 44 44 44 00 d0 09 00 00 11 00 00 00 11 11 55 00
80: 23 55 55 00 fa 00 64 0c 03 00 00 00 7f 00 00 00
90: 78 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 01 01 01 01 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 08 00 00 a8 00 00 e0 fe 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00: de 10 60 02 0f 00 a0 00 a3 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 ed 01
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: 28 10 ed 01 00 00 ff fe fa 3e ff 00 fa 3e ff 00
50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 ff
70: 10 00 ff ff c5 00 00 00 00 00 04 19 00 c0 30 00
80: 09 20 00 d8 01 10 00 00 c0 00 00 01 00 00 00 00
90: 00 00 00 00 00 00 00 00 21 47 65 b7 ef cd 00 00
a0: 00 00 10 80 00 00 01 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 08 80 08 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00

00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00: de 10 64 02 01 00 b0 00 a3 00 05 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 1c 00 00 41 1c 00 00 00 00 00 00 28 10 ed 01
30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 00 00
40: 28 10 ed 01 01 00 02 c0 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 00 00
70: 01 00 00 00 00 00 c8 fe 00 00 fe fe 01 20 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: d4 30 80 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 08 10 05 00 00 a0 80 00 80 74 00 00 41 44 44 11
f0: 5a ff 5f bf 00 00 00 c0 10 00 00 00 00 00 00 00

00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
00: de 10 72 02 00 04 a0 00 a3 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 ed 01
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 10 00 00 10 00 00 10 10
50: 10 10 10 10 00 00 00 00 00 00 00 00 00 00 00 00
60: 02 03 00 00 12 00 00 00 02 00 00 00 10 01 12 00
70: 32 33 00 00 03 00 00 00 00 00 00 00 12 01 00 00
80: 10 00 00 00 00 00 00 00 00 00 00 00 30 02 00 00
90: 00 00 00 00 01 20 00 00 01 00 00 00 00 09 00 00
a0: 01 02 00 00 00 10 00 00 05 00 00 00 01 00 00 00
b0: 00 10 00 80 01 00 00 80 00 00 00 00 02 00 00 00
c0: 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00: de 10 6d 02 07 00 b0 00 a3 10 03 0c 00 00 80 00
10: 00 f0 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 ed 01
30: 00 00 00 00 44 00 00 00 00 00 00 00 0f 01 03 01
40: 28 10 ed 01 01 00 02 fe 00 00 00 00 00 00 00 00
50: 08 00 00 00 1d 47 40 00 10 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00: de 10 6e 02 06 00 b0 00 a3 20 03 0c 00 00 80 00
10: 00 e0 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 ed 01
30: 00 00 00 00 44 00 00 00 00 00 00 00 05 02 03 01
40: 28 10 ed 01 0a 80 98 20 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 20 20 01 00 00 60 18 85 03 3c 0a 01 00 00 00 00
70: 00 00 08 05 00 10 20 80 89 3d b6 22 77 25 04 00
80: 01 00 02 fe 00 00 00 00 00 00 00 00 15 16 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 00 01 00 00 08 c0 00 00 00 00 00 00 00 00
b0: 00 11 22 33 00 00 00 00 ff 00 00 00 00 00 00 00
c0: 10 10 2d 0d 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00

00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00: de 10 66 02 07 00 b0 00 a1 85 01 01 00 00 00 00
10: f1 09 00 00 f1 0b 00 00 71 09 00 00 71 0b 00 00
20: 01 e0 00 00 00 d0 02 fe 00 00 00 00 28 10 ed 01
30: 00 00 00 00 44 00 00 00 00 00 00 00 0b 01 03 01
40: 28 10 ed 01 01 b0 02 00 00 00 00 00 00 00 00 00
50: 03 00 00 00 00 00 00 00 a8 20 a8 20 66 00 20 20
60: 00 c6 00 c7 51 0c 00 00 00 0f 06 42 00 00 00 00
70: 2c 78 c4 40 01 10 00 00 01 10 00 00 20 00 20 00
80: 00 00 00 c0 00 60 f9 22 00 00 08 a0 00 fc 00 00
90: 00 00 08 80 00 00 00 00 06 00 06 10 00 00 01 01
a0: 14 10 00 2a 00 00 00 00 00 00 00 00 33 33 00 02
b0: 05 cc 84 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 0a 00 0a 00 08 00 02 a8
d0: 0a 00 02 6c 42 00 00 00 00 00 00 00 00 00 00 e0
e0: 0a 00 02 36 42 00 00 00 00 00 00 00 90 42 44 83
f0: 00 00 00 00 00 00 00 00 00 00 0c 00 00 00 00 00

00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00: de 10 67 02 07 00 b0 00 a1 85 01 01 00 00 00 00
10: e1 09 00 00 e1 0b 00 00 61 09 00 00 61 0b 00 00
20: 01 cc 00 00 00 c0 02 fe 00 00 00 00 28 10 ed 01
30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 03 01
40: 28 10 ed 01 01 b0 02 00 00 00 00 00 00 00 00 00
50: 03 00 00 00 00 00 00 00 a8 a8 a8 a8 aa 00 99 99
60: 00 00 00 00 51 0c 00 00 00 0f 06 42 00 00 00 00
70: 2c 78 c4 40 01 10 00 00 01 10 00 00 20 00 20 00
80: 00 00 00 00 d6 38 45 ff 00 00 c1 30 5e 61 bf ae
90: 00 00 1e 09 00 00 00 00 06 00 06 10 00 00 01 01
a0: 14 10 00 00 00 00 00 00 00 00 00 00 33 33 00 02
b0: 05 cc 84 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 0a 00 0a 00 08 00 02 a8
d0: 0a 00 02 36 42 00 00 00 00 00 00 00 01 00 80 00
e0: 0a 00 02 36 42 00 00 00 00 00 00 00 82 02 01 04
f0: 00 00 00 00 00 00 00 00 00 00 0c 00 00 00 00 00

00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00: de 10 6f 02 07 00 b0 00 a2 01 04 06 00 00 81 00
10: 00 00 00 00 00 00 00 00 00 04 04 20 90 90 80 02
20: b0 fd b0 fd a0 fd a0 fd 00 00 00 00 00 00 00 00
30: 00 00 00 00 b8 00 00 00 00 00 00 00 ff 00 04 02
40: 00 00 03 00 01 00 02 00 05 00 00 00 00 00 44 00
50: 00 00 fe 3f 00 00 00 00 ff 1f ff 1f 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 a8
90: 00 00 e0 fe 00 00 00 00 00 00 00 00 00 00 00 00
a0: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 ff ff 00 00 0d 8c 00 00 00 00 00 00
c0: 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00: de 10 6c 02 06 00 b0 00 a2 00 03 04 00 00 80 00
10: 00 40 02 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 ed 01
30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 02 02 05
40: 28 10 ed 01 01 50 02 c0 00 00 00 00 01 01 0f 00
50: 05 6c 80 01 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 0f 00 00 00 08 00 02 a8
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 46 00 29 00 00 00 00 00 00

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 01 01 01 00 01 01 01 00 01 01 01 00 01 01 01 00
50: 01 01 01 00 01 01 01 00 01 01 01 00 01 01 01 00
60: 00 00 01 00 e4 00 00 00 20 c8 0e 0f 0c 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 08 00 01 21 20 00 11 11 22 06 75 80 02 00 00 00
90: 69 01 61 01 00 00 04 00 07 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 00 00 00 00 00 3f 00 00 00 00 00 01 00 00 00
50: 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00
60: 00 00 00 00 04 00 00 00 00 00 00 00 05 00 00 00
70: 00 00 00 00 06 00 00 00 00 00 00 00 07 00 00 00
80: 03 0a 00 00 00 0b 00 00 00 00 00 00 00 00 00 00
90: 03 00 40 00 00 ff ef 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 03 00 f4 00 00 02 fe 00
b0: 03 00 f0 00 80 4f f0 00 00 00 00 00 00 00 00 00
c0: 13 80 00 00 00 f0 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 03 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 e0 3f 38 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 46 00 00 00 00 00 00 00
80: 20 00 00 00 00 00 00 00 24 c2 6a ae 20 13 82 00
90: 10 0c 01 00 5a 80 00 67 39 00 00 80 00 00 00 00
a0: ef 02 00 ae 00 00 00 00 00 00 00 00 00 00 00 00
b0: ef 65 f6 9f ce 00 00 00 27 19 20 20 92 4c c7 4c
c0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: ac 7e 5f 3b 5d 3b bf c3 45 85 7f 7d 40 94 08 61
e0: 61 3a ff 73 38 59 d5 61 85 ce 2d 67 af 61 8c 1a
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
00: 22 10 03 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 f0 00 00 00 00 00 00 00 00 00 00 00
40: ff 3b 04 00 40 00 10 0a 00 00 00 00 00 00 00 00
50: 68 43 29 d8 0d 00 00 00 00 00 00 00 80 39 91 97
60: 23 00 00 00 01 77 1f 00 00 00 00 00 00 00 00 00
70: 11 01 32 51 21 40 70 50 00 2a 00 08 17 21 00 00
80: 00 00 07 23 13 21 13 21 00 00 00 00 00 00 00 00
90: 00 00 00 00 e2 0c 00 00 10 90 8d 0e 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 01 a7 0d 00 00 00 a0 08 25 25 25 00
e0: 00 00 00 00 24 1a 4e 00 19 17 00 00 00 00 00 00
f0: 0f 00 10 00 00 00 00 00 00 00 00 00 b2 0f 04 00

01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
00: 86 80 b9 10 07 04 18 00 06 00 00 02 10 00 00 00
10: 00 00 8e fd 00 00 8c fd 01 ac 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 83 10
30: 00 00 00 00 c8 00 00 00 00 00 00 00 07 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 01 d0 22 c8 00 20 00 21
d0: 05 e0 81 00 00 00 e0 fe 00 00 00 00 81 40 00 00
e0: 10 00 01 00 c1 0c 00 00 10 28 1a 00 11 64 03 02
f0: 40 00 11 10 00 00 00 00 00 00 00 00 00 00 00 00

04:07.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
00: e4 14 0c 17 06 00 10 00 02 00 00 02 00 40 00 00
10: 00 e0 bf fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 ed 01
30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 00 00
40: 01 00 02 fe 00 40 00 34 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-03 23:20             ` Adam Kropelin
@ 2007-02-04  1:14               ` Eric W. Biederman
  2007-02-04  4:44                 ` Adam Kropelin
  0 siblings, 1 reply; 61+ messages in thread
From: Eric W. Biederman @ 2007-02-04  1:14 UTC (permalink / raw)
  To: Adam Kropelin
  Cc: Auke Kok, Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, netdev

"Adam Kropelin" <akropel1@rochester.rr.com> writes:

>> Can I get the corresponding lspci -xxx output.  I suspect the BIOS
>> did not program the hypertransport MSI mapping capabilities correctly.
>> All it has to do is set the enable but still, occasionally BIOS
>> writers miss the most amazing things.
>
> Here you go. This is from 2.6.20-rc7.

Thanks.  Conclusion.  I could not find bit 16 (the enable bit) set in any of
your hypertransport msi mapping capabilities.

So MSI interrupts won't work until someone enables your chipset
to transform them into hypertransport interrupts.

Ideally it is a BIOS issue, but it may be the kind of thing we can
fix up with quirks in the kernel.

Eric

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-04  1:14               ` Eric W. Biederman
@ 2007-02-04  4:44                 ` Adam Kropelin
  2007-02-04  5:12                   ` Eric W. Biederman
  0 siblings, 1 reply; 61+ messages in thread
From: Adam Kropelin @ 2007-02-04  4:44 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Auke Kok, Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, netdev

Eric W. Biederman wrote:
> "Adam Kropelin" <akropel1@rochester.rr.com> writes:
>
>>> Can I get the corresponding lspci -xxx output.  I suspect the BIOS
>>> did not program the hypertransport MSI mapping capabilities
>>> correctly. All it has to do is set the enable but still,
>>> occasionally BIOS writers miss the most amazing things.
>>
>> Here you go. This is from 2.6.20-rc7.
>
> Thanks.  Conclusion.  I could not find bit 16 (the enable bit) set in
> any of your hypertransport msi mapping capabilities.
>
> So MSI interrupts won't work until someone enables your chipset
> to transform them into hypertransport interrupts.

Naive question... Can the pci layer (or e1000) detect that MSI is not 
enabled in the hardware and avoid using it in that case? With the number 
of MSI problems showing up it seems risky to assume it's usable on any 
given platform without some sort of sanity check.

--Adam


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions (v2) (part 1)
  2007-02-04  4:44                 ` Adam Kropelin
@ 2007-02-04  5:12                   ` Eric W. Biederman
  0 siblings, 0 replies; 61+ messages in thread
From: Eric W. Biederman @ 2007-02-04  5:12 UTC (permalink / raw)
  To: Adam Kropelin
  Cc: Auke Kok, Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, jgarzik, alan, Allen Parker,
	jesse.brandeburg, gregkh, linux-pci, netdev

"Adam Kropelin" <akropel1@rochester.rr.com> writes:

> Naive question... Can the pci layer (or e1000) detect that MSI is not enabled in
> the hardware and avoid using it in that case? With the number of MSI problems
> showing up it seems risky to assume it's usable on any given platform without
> some sort of sanity check.
>

Yes, that is what we should do.  Start with the assumption MSI doesn't work
and enable it when we detect the hardware is setup properly.

Thing is that is going to take a little bit of work, and a little bit of
thinking on how to structure it properly.  So in real time it is going
to be a couple of weeks before the code to do that is ready.

Right now the model is that piecemeal we put in the code to
conditionally turn off chipsets that are known to have problems.
Which for building a reliable system when MSI isn't mandatory for
operation seems backwards.

Probably in addition we should have a warning such as:
"Found devices supporting MSI and but chipset is unknown".

Eric

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-03 10:51                 ` Andi Kleen
  2007-02-03 10:57                   ` Frédéric Riss
@ 2007-02-04 13:13                   ` Frédéric Riss
  2007-02-04 14:37                     ` Andi Kleen
  2007-02-04 17:34                     ` Linus Torvalds
  1 sibling, 2 replies; 61+ messages in thread
From: Frédéric Riss @ 2007-02-04 13:13 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, Matt Domsch, Adrian Bunk, Linus Torvalds,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

Le samedi 03 février 2007 à 11:51 +0100, Andi Kleen a écrit :
> > +
> > +typedef efilinkage efi_status_t efi_get_time_t (efi_time_t *tm,
> > +						efi_time_cap_t *tc);
> 
> I assume you have double checked it actually works? (i vaguely recall some
> issues with applying attributes to typedefs). If not you would need
> to put them to the declarations.

OK, I tried the following patch (simply adding asmlinkage to the
typedefs) with gcc 3.3, 3.4, 4.0 and 4.1. I couldn't easily try older
compilers.

New patch:

When calling into the EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This patch is needed to allow the new Intel-based Macs to suspend to ram
(efi.get_time is called during the suspend phase).

Signed-off-by: Frederic Riss <frederic.riss@gmail.com>
---
diff --git a/include/linux/efi.h b/include/linux/efi.h
index f8ebd7c..578bc2a 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -157,22 +157,33 @@ typedef struct {
 	unsigned long reset_system;
 } efi_runtime_services_t;
 
-typedef efi_status_t efi_get_time_t (efi_time_t *tm, efi_time_cap_t *tc);
-typedef efi_status_t efi_set_time_t (efi_time_t *tm);
-typedef efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, efi_bool_t *pending,
-					    efi_time_t *tm);
-typedef efi_status_t efi_set_wakeup_time_t (efi_bool_t enabled, efi_time_t *tm);
-typedef efi_status_t efi_get_variable_t (efi_char16_t *name, efi_guid_t *vendor, u32 *attr,
-					 unsigned long *data_size, void *data);
-typedef efi_status_t efi_get_next_variable_t (unsigned long *name_size, efi_char16_t *name,
-					      efi_guid_t *vendor);
-typedef efi_status_t efi_set_variable_t (efi_char16_t *name, efi_guid_t *vendor, 
-					 unsigned long attr, unsigned long data_size, 
-					 void *data);
-typedef efi_status_t efi_get_next_high_mono_count_t (u32 *count);
-typedef void efi_reset_system_t (int reset_type, efi_status_t status,
-				 unsigned long data_size, efi_char16_t *data);
-typedef efi_status_t efi_set_virtual_address_map_t (unsigned long memory_map_size,
+typedef asmlinkage efi_status_t efi_get_time_t (efi_time_t *tm,
+						efi_time_cap_t *tc);
+typedef asmlinkage efi_status_t efi_set_time_t (efi_time_t *tm);
+typedef asmlinkage efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, 
+						       efi_bool_t *pending,
+						       efi_time_t *tm);
+typedef asmlinkage efi_status_t efi_set_wakeup_time_t (efi_bool_t enabled,
+						       efi_time_t *tm);
+typedef asmlinkage efi_status_t efi_get_variable_t (efi_char16_t *name,
+						    efi_guid_t *vendor,
+						    u32 *attr,
+						    unsigned long *data_size,
+						    void *data);
+typedef asmlinkage efi_status_t efi_get_next_variable_t (unsigned long *name_sz,
+							 efi_char16_t *name,
+							 efi_guid_t *vendor);
+typedef asmlinkage efi_status_t efi_set_variable_t (efi_char16_t *name,
+						    efi_guid_t *vendor,
+						    unsigned long attr,
+						    unsigned long data_size,
+						    void *data);
+typedef asmlinkage efi_status_t efi_get_next_high_mono_count_t (u32 *count);
+typedef asmlinkage void efi_reset_system_t (int reset_type, 
+					    efi_status_t status,
+					    unsigned long data_size,
+					    efi_char16_t *data);
+typedef asmlinkage efi_status_t efi_set_virtual_address_map_t (unsigned long memory_map_size,
 						unsigned long descriptor_size,
 						u32 descriptor_version,
 						efi_memory_desc_t *virtual_map);



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-04 13:13                   ` Frédéric Riss
@ 2007-02-04 14:37                     ` Andi Kleen
  2007-02-04 17:34                     ` Linus Torvalds
  1 sibling, 0 replies; 61+ messages in thread
From: Andi Kleen @ 2007-02-04 14:37 UTC (permalink / raw)
  To: Frédéric Riss
  Cc: Andrew Morton, Matt Domsch, Adrian Bunk, Linus Torvalds,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu


> 
> When calling into the EFI firmware, the parameters need to be passed on
> the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
> This patch is needed to allow the new Intel-based Macs to suspend to ram
> (efi.get_time is called during the suspend phase).

Thanks looks good.

-Andi

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-04 13:13                   ` Frédéric Riss
  2007-02-04 14:37                     ` Andi Kleen
@ 2007-02-04 17:34                     ` Linus Torvalds
  2007-02-04 18:18                       ` Frédéric Riss
  2007-02-05  8:26                       ` Andi Kleen
  1 sibling, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2007-02-04 17:34 UTC (permalink / raw)
  To: Frédéric Riss
  Cc: Andi Kleen, Andrew Morton, Matt Domsch, Adrian Bunk,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

[-- Attachment #1: Type: TEXT/PLAIN, Size: 962 bytes --]



On Sun, 4 Feb 2007, Frédéric Riss wrote:
> 
> New patch:

I didn't get how this would fix the ia64 issues? I thought ia64 needed 
the standard calling convention?

My gut feel is that EFI should be handled exactly the same way that we 
used to handle APM: never even make it look like it's callable from C, but 
make architecture-specific wrapper functions that have bog-standard 
calling conventions, and then possibly even use inline asm to actually do 
the real call (but even if you don't, at that point it would be inside one 
particular arch-specific EFI source file - nobody outside of that would 
ever call into the firmware directly).

As it is, I don't think I dare apply this right now, which means that it 
will miss 2.6.20, and we'll have to backport it to the stable tree when 
everybody agrees and has acked it. I don't like having suspend broken on 
EFI macs, but on the other hand, I would hate to have an ia64 regression 
even more..

		Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-04 17:34                     ` Linus Torvalds
@ 2007-02-04 18:18                       ` Frédéric Riss
  2007-02-04 18:29                         ` Linus Torvalds
  2007-02-05  8:26                       ` Andi Kleen
  1 sibling, 1 reply; 61+ messages in thread
From: Frédéric Riss @ 2007-02-04 18:18 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andi Kleen, Andrew Morton, Matt Domsch, Adrian Bunk,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

Le dimanche 04 février 2007 à 09:34 -0800, Linus Torvalds a écrit :
> 
> On Sun, 4 Feb 2007, Frédéric Riss wrote:
> > 
> > New patch:
> 
> I didn't get how this would fix the ia64 issues? I thought ia64 needed 
> the standard calling convention?

I think Andi said that adding asmlinkage on the function pointers
shouldn't harm ia64. If you prefer wrapper functions, one of the patches
I sent ( http://lkml.org/lkml/2007/1/30/309 ) did that, but the casting
it uses looks clumsy.

Fred.



^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-04 18:18                       ` Frédéric Riss
@ 2007-02-04 18:29                         ` Linus Torvalds
  0 siblings, 0 replies; 61+ messages in thread
From: Linus Torvalds @ 2007-02-04 18:29 UTC (permalink / raw)
  To: Frédéric Riss
  Cc: Andi Kleen, Andrew Morton, Matt Domsch, Adrian Bunk,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

[-- Attachment #1: Type: TEXT/PLAIN, Size: 564 bytes --]



On Sun, 4 Feb 2007, Frédéric Riss wrote:
> 
> I think Andi said that adding asmlinkage on the function pointers
> shouldn't harm ia64. If you prefer wrapper functions, one of the patches
> I sent ( http://lkml.org/lkml/2007/1/30/309 ) did that, but the casting
> it uses looks clumsy.

I'm more comfortable with that one, at least for now. It's guaranteed to 
not break ia64, at least. Also, it does what I think is right: do the 
calling convention conversion at the call-site rather than at a C compiler 
level.

Will apply a whitespace-fixed version,

		Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-04 17:34                     ` Linus Torvalds
  2007-02-04 18:18                       ` Frédéric Riss
@ 2007-02-05  8:26                       ` Andi Kleen
  2007-02-05  9:35                         ` Eric W. Biederman
  1 sibling, 1 reply; 61+ messages in thread
From: Andi Kleen @ 2007-02-05  8:26 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Frédéric Riss, Andrew Morton, Matt Domsch, Adrian Bunk,
	Linux Kernel Mailing List, Eric Van Hensbergen, Trond Myklebust,
	Neil Brown, Stephen Hemminger, Benjamin Herrenschmidt,
	Jeff Garzik, Eric W. Biederman, Francois Romieu

On Sunday 04 February 2007 18:34, Linus Torvalds wrote:
> 
> On Sun, 4 Feb 2007, Frédéric Riss wrote:
> > 
> > New patch:
> 
> I didn't get how this would fix the ia64 issues? I thought ia64 needed 
> the standard calling convention?

asmlinkage is standard enough on ia64 as far as I can see.

It defines to an undocumented attribute that seems to only affect the
generated code for functions (basically it forces the compiler
to not reuse input arguments, similar to prevent_tail_call() on i386), 
not for pointers.

-Andi

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-05  8:26                       ` Andi Kleen
@ 2007-02-05  9:35                         ` Eric W. Biederman
  0 siblings, 0 replies; 61+ messages in thread
From: Eric W. Biederman @ 2007-02-05  9:35 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Linus Torvalds, Frédéric Riss, Andrew Morton,
	Matt Domsch, Adrian Bunk, Linux Kernel Mailing List,
	Trond Myklebust, Neil Brown, Stephen Hemminger,
	Benjamin Herrenschmidt, Jeff Garzik, Francois Romieu

Andi Kleen <ak@suse.de> writes:

> On Sunday 04 February 2007 18:34, Linus Torvalds wrote:
>> 
>> On Sun, 4 Feb 2007, Frédéric Riss wrote:
>> > 
>> > New patch:
>> 
>> I didn't get how this would fix the ia64 issues? I thought ia64 needed 
>> the standard calling convention?
>
> asmlinkage is standard enough on ia64 as far as I can see.
>
> It defines to an undocumented attribute that seems to only affect the
> generated code for functions (basically it forces the compiler
> to not reuse input arguments, similar to prevent_tail_call() on i386), 
> not for pointers.

Regardless.  If we are serious about supporting EFI instead of just
nursing it along for the rare person stuck with it, we are going
to need to remove the brain-dead relocate exactly once to virtual addresses
call, so we can use kexec.

Therefore we will need a trampoline to switch to physical mode.

Of course that presumes the Open (but no one is allowed to read or implement
the standard, or join the committee ) EFI is sufficiently interesting at
some point to bother supporting properly.

Eric

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
  2007-02-02  8:45 ` 2.6.20-rc7: known regressions Fabio Erculiani
@ 2007-02-02 13:58   ` Adrian Bunk
  0 siblings, 0 replies; 61+ messages in thread
From: Adrian Bunk @ 2007-02-02 13:58 UTC (permalink / raw)
  To: Fabio Erculiani; +Cc: linux-kernel

On Fri, Feb 02, 2007 at 08:45:42AM +0000, Fabio Erculiani wrote:

> Adrian, 

Hi Fabio,

> and this one? 
> http://bugzilla.kernel.org/show_bug.cgi?id=7589 

Not a regression in 2.6.20-rc compared to 2.6.19 - it's already in 
broken in 2.6.19.

This bug should be fixed, but it's outside the scope of my list.

> Fabio Erculiani 

cu
Adrian

BTW: Please don't strip me from the Cc when asking me a question.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: 2.6.20-rc7: known regressions
       [not found] <19868466.241170405430418.JavaMail.root@lxnaydesign.net>
@ 2007-02-02  8:45 ` Fabio Erculiani
  2007-02-02 13:58   ` Adrian Bunk
  0 siblings, 1 reply; 61+ messages in thread
From: Fabio Erculiani @ 2007-02-02  8:45 UTC (permalink / raw)
  To: linux-kernel

Adrian, 

and this one? 
http://bugzilla.kernel.org/show_bug.cgi?id=7589 

--- 
Fabio Erculiani 
http://www.sabayonlinux.org 
Sabayon Linux Founder 


^ permalink raw reply	[flat|nested] 61+ messages in thread

end of thread, other threads:[~2007-02-05  9:37 UTC | newest]

Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-31  4:28 Linux 2.6.20-rc7 Linus Torvalds
     [not found] ` <45C05150.6000802@agmk.net>
2007-01-31 16:04   ` Linus Torvalds
2007-01-31 23:13     ` Andrew Morton
     [not found]     ` <200702010037.48472.pluto@agmk.net>
2007-02-01  0:14       ` Andrew Morton
2007-02-01  0:19       ` Linus Torvalds
2007-02-01  0:26         ` Andrew Morton
2007-02-01  0:39           ` Linus Torvalds
2007-02-01  0:44         ` Nick Piggin
2007-02-01  0:54           ` Linus Torvalds
2007-02-01  6:48     ` Pekka Enberg
2007-01-31 17:11 ` [PATCH] x86_64: Fix preprocessor condition Josef 'Jeff' Sipek
2007-01-31 17:16   ` Andi Kleen
2007-01-31 17:40     ` Josef Sipek
2007-01-31 18:15 ` Linux 2.6.20-rc7 Sunil Naidu
2007-02-01  2:16 ` S.Çağlar Onur
2007-02-01  2:36   ` Linus Torvalds
2007-02-01  3:01     ` S.Çağlar Onur
2007-02-01  3:31       ` Linus Torvalds
2007-02-01  5:44         ` H. Peter Anvin
2007-02-01  6:00           ` Linus Torvalds
2007-02-01  6:10             ` H. Peter Anvin
2007-02-01  6:38               ` Alexander E. Patrakov
2007-02-01  6:53                 ` H. Peter Anvin
2007-02-02 20:52         ` S.Çağlar Onur
2007-02-01 21:06           ` H. Peter Anvin
2007-02-02  5:49 ` 2.6.20-rc7: known regressions Adrian Bunk
2007-02-03  1:55   ` Andrew Morton
2007-02-03  2:03     ` Jeff Garzik
2007-02-03  2:15       ` Andrew Morton
2007-02-03  9:19     ` Frédéric Riss
2007-02-03  9:24       ` Andrew Morton
2007-02-03  9:33         ` Andi Kleen
2007-02-03  9:49           ` Frédéric Riss
2007-02-03  9:58             ` Andi Kleen
2007-02-03 10:47               ` Frédéric Riss
2007-02-03 10:51                 ` Andi Kleen
2007-02-03 10:57                   ` Frédéric Riss
2007-02-03 11:08                     ` Frédéric RISS
2007-02-04 13:13                   ` Frédéric Riss
2007-02-04 14:37                     ` Andi Kleen
2007-02-04 17:34                     ` Linus Torvalds
2007-02-04 18:18                       ` Frédéric Riss
2007-02-04 18:29                         ` Linus Torvalds
2007-02-05  8:26                       ` Andi Kleen
2007-02-05  9:35                         ` Eric W. Biederman
2007-02-03  0:44 ` 2.6.20-rc7: known regressions (v2) (part 1) Adrian Bunk
2007-02-03  6:06   ` Auke Kok
2007-02-03  7:41     ` Eric W. Biederman
2007-02-03 18:06       ` Adam Kropelin
2007-02-03 20:43         ` Auke Kok
2007-02-03 21:00           ` Adam Kropelin
2007-02-03 21:26             ` Auke Kok
2007-02-03 22:24               ` Eric W. Biederman
2007-02-03 21:12           ` Eric W. Biederman
2007-02-03 23:20             ` Adam Kropelin
2007-02-04  1:14               ` Eric W. Biederman
2007-02-04  4:44                 ` Adam Kropelin
2007-02-04  5:12                   ` Eric W. Biederman
2007-02-03  0:47 ` 2.6.20-rc7: known regressions (v2) (part 2) Adrian Bunk
     [not found] <19868466.241170405430418.JavaMail.root@lxnaydesign.net>
2007-02-02  8:45 ` 2.6.20-rc7: known regressions Fabio Erculiani
2007-02-02 13:58   ` Adrian Bunk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).