Linux 2.6.19-rc2

Linux 2.6.19-rc2

[Linus Torvalds]

Ok, it's a week since -rc1, so -rc2 is out there.

The diff itself is pretty huge, mainly because of two things:

 - we did the big interrupt handler argument passing cleanup, which 
   affects a _lot_ of drivers in very trivial ways.

   As a result, the diffstat shows a lot of files with a single line 
   changed (mostly just removing the unused "pt_regs" argument), but the 
   fallout also ended up being a lot of architectures cleaning up their 
   irq handling.

 - the initial ext4 code-drop (a lot of it is copyign the ext3 files and 
   renaming functions and variables to "ext4_xyzzy" instead of "ext3_xyzzy")

Both of those changes were done _after_ the -rc1, because nobody wanted to 
handle the combination of large merges and a lot of fairly cosmetic 
changes. The irq thing turned out to be perhaps a bit more painful than 
expected (lots of arch fallout), but it all looks a lot better now.

Aside from those two things, we've got some arch updates (PowerPC, MIPS, 
SH), and various random fixes. Oh, and Al has been busy annotating things. 

So if you had issues with -rc1 (which had a ton of merges - even more so 
than most -rc1 releases, I think), this should hopefully be a lot better.

		Linus
---
Adrian Bunk (2):
      HT_IRQ must depend on PCI
      [DLM] Kconfig: don't show an empty DLM menu

Akinbou Mita (1):
      [PKT_SCHED] sch_htb: use rb_first() cleanup

Al Viro (103):
      m68k: dma_alloc_coherent() has gfp_t as the last argument
      m68k pt_regs fixes
      minimal alpha pt_regs fixes
      m32r pt_regs fixes
      sparc32 pt_regs fixes
      sparc64 pt_regs fixes
      sparc32 rwlock fix
      m68k pt_regs fixes, part 2
      alpha pt_regs cleanups: device_interrupt
      alpha pt_regs cleanups: handle_irq()
      alpha pt_regs cleanups: machine_check()
      alpha pt_regs cleanups: collapse set_irq_regs() in titan_dispatch_irqs()
      missed ia64 pt_regs fixes
      misc arm pt_regs fixes
      misc ppc pt_regs fixes
      missing include in pdaudiocf_irq
      missing include of scatterlist.h
      missing forward declaration of pt_regs (asm-m68k/signal.h)
      linux/io.h needs types.h
      uml pt_regs fixes
      arm: it's OK to pass pointer to volatile as iounmap() argument...
      m68k/kernel/dma.c assumes !MMU_SUN3
      sparc64 irq pt_regs fallout
      fallout from alpha pt_regs patches
      more ia64 irq handlers
      extern doesn't make sense on a definition of function...
      trivial iomem annotations (arch/powerpc/platfroms/parsemi/pci.c)
      mv64630_pic NULL noise removal
      wrong order of arguments in copy_to_user() in ncpfs
      dlm gfp_t annotations
      hppfs: readdir callback missed in prototype change
      s390 traps.c __user annotations
      mos7840 annotations
      tifm __iomem annotations, NULL noise removal
      [POWERPC] ARCH=ppc pt_regs fixes
      advansys __iomem annotations
      more fs/compat.c __user annotations
      drivers/s390 misc sparse annotations
      dccp __user annotations
      __iomem annotations in sunzilog
      NULL noise removal: advansys
      fix misannotations in loop.c
      misc sata __iomem annotations
      hwdep_compat missed __user annotations
      devio __user annotations
      drivers/dma trivial annotations
      tipc __user annotations
      __user annotations: futex
      ia64/hp NULL noise removal
      ia64/sn __iomem annotations
      mtd: remove several bogus casts to void * in iounmap() argument
      fix misannotation in ioc4.h
      make kernel/relay.c __user-clean
      passing pointer to setup_timer() should be via unsigned long
      acpi NULL noise removal
      trivial iomem annotations: istallion
      ptrace32 trivial __user annotations
      gfp annotations: scsi_error
      gfp annotations: radix_tree_root
      trivial iomem annotations: sata_promise
      openprom NULL noise removal
      __user annotations: loop.c
      em28xx NULL noise removal
      fs/inode.c NULL noise removal
      cpuset ANSI prototype
      ptrdiff_t is %t, not %z
      strndup() would better take size_t, not int
      net/sunrpc/auth_gss/svcauth_gss.c endianness regression
      missed const in prototype
      use %zu for size_t
      use %p for pointers
      befs: remove bogus typedef
      befs: prepare to sanitizing headers
      befs: introduce on-disk endian types
      befs: missing fs32_to_cpu() in debug.c
      befs: endianness annotations
      fs/fat endianness annotations
      hpfs endianness annotations
      smbfs endianness annotations
      isofs endianness annotations
      fs/partitions endianness annotations
      ufs endianness annotations
      endianness annotations in s2io
      arm __user annotations
      arm: use unsigned long instead of unsigned int in get_user()
      arm-versatile iomem annotations
      m32r: C99 initializers in setup.c
      m32r: signal __user annotations
      m32r: NULL noise removal
      m32r: more __user annotations
      misuse of strstr
      m68k uaccess __user annotations
      misc m68k __user annotations
      sun3 __iomem annotations
      clean m68k ksyms
      amiga_floppy_init() in non-modular case
      z2_init() in non-modular case
      remove bogus arch-specific syscall exports
      alpha_ksyms.c cleanup
      i2Output always takes kernel data now
      fixing includes in alpha_ksyms.c
      more kernel_execve() fallout (sbus)
      uml shouldn't do HEADERS_CHECK

Alan Cox (2):
      libata: Don't believe bogus claims in the older PIO mode register
      ide-generic: jmicron fix

Alex Tomas (2):
      ext3: add extent map support
      ext4: 48bit physical block number support in extents

Alexandre Ratchov (2):
      ext4: allow larger descriptor size
      ext4: move block number hi bits

Alexey Dobriyan (8):
      cdrom: add endianness annotations
      serpent: fix endian warnings
      chelsio: add endian annotations
      Finish annotations of struct vlan_ethhdr
      fs/*: use BUILD_BUG_ON
      DAC960: use memmove for overlapping areas
      lockdep: use BUILD_BUG_ON
      md: use BUILD_BUG_ON

Amol Lad (1):
      [ALSA] sound/pci/au88x0/au88x0.c: ioremap balanced with iounmap

Andi Kleen (6):
      x86-64: Update defconfig
      i386: Update defconfig
      i386: Fix PCI BIOS config space access
      x86: Terminate the kernel stacks for the unwinder
      x86-64: Fix FPU corruption
      x86-64: Annotate interrupt frame backlink in interrupt handlers

Andreas Mohr (1):
      fs/bio.c: tweaks

Andrew Morton (15):
      i386: irqs build fix
      kauditd_thread warning fix
      Fix WARN_ON / WARN_ON_ONCE regression
      irq_reqs: export __irq_regs
      x86_64 irq_regs fix
      ibmveth irq fix
      revert "nvidiafb: use generic ddc reading"
      ext4 uninline ext4_get_group_no_and_offset()
      ext4 64 bit divide fix
      ext4: rename logic_sb_block
      ext4 whitespace cleanups
      grow_buffers() infinite loop fix
      invalidate_inode_pages2_range() debug
      dell_rbu: printk() warning fix
      [CIFS] cifs Kconfig: don't select CONNECTOR

Aneesh Kumar (2):
      Fix typos in mm/shmem_acl.c
      fix lockdep-design.txt

Aneesh Kumar K.V (1):
      use struct irq_chip instead of struct hw_interrupt_type

Anton Blanchard (1):
      [POWERPC] Update MTFSF_L() comment

Arnaud Patard (1):
      [ALSA] emu10k1: Fix outl() in snd_emu10k1_resume_regs()

Atsushi Nemoto (5):
      [MIPS] ret_from_irq adjustment
      [MIPS] Fix build errors related to wbflush.h on tx4927/tx4938.
      [MIPS] Make sure cpu_has_fpu is used only in atomic context
      [MIPS] <asm/irq.h> does not need pt_regs anymore.
      [MIPS] Optimize and cleanup get_saved_sp, set_saved_sp

Badari Pulavarty (1):
      ext4: 48bit i_file_acl

Benjamin Herrenschmidt (8):
      [POWERPC] Fix zImage decompress location
      [POWERPC] Don't get PCI IRQ from OF for devices with no IRQ
      page fault retry with NOPAGE_REFAULT
      [POWERPC] Make U4 PCIe work on maple
      [POWERPC] Fix Maple secondary IDE interrupt
      [POWERPC] Update maple defconfig
      [POWERPC] Fix i2c-powermac platform device usage
      [POWERPC] Fix windfarm platform device usage

Bill Nottingham (1):
      Introduce vfs_listxattr

Brian King (1):
      [POWERPC] Update pSeries defconfig for SATA

Chad Sellers (1):
      SELinux: Bug fix in polidydb_destroy

Chen, Kenneth W (1):
      hugetlb: fix linked list corruption in unmap_hugepage_range()

Christian Borntraeger (2):
      [S390] ap bus poll thread priority.
      [S390] stacktrace bug.

Christoph Lameter (2):
      slab: remove wrongly placed BUG_ON
      mm: kevent threads: use MPOL_DEFAULT

Cornelia Huck (5):
      [S390] cio: 0 is a valid chpid.
      [S390] cio: add missing KERN_INFO printk header.
      [S390] cio: Use ccw_dev_id and subchannel_id in ccw_device_private
      [S390] cio: Remove grace period for vary off chpid.
      [S390] cio: remove casts from/to (void *).

Dan Cyr (1):
      [ALSA] hda-intel - New pci id for Nvidia MCP61

Dave Jones (2):
      [HEADERS] Put linux/config.h out of its misery.
      move rmap BUG_ON outside DEBUG_VM

Dave Kleikamp (4):
      ext4: initial copy of files from ext3
      jbd2: initial copy of files from jbd
      jbd2: cleanup ext4_jbd.h
      Documentation/filesystems/ext4.txt

David Brownell (1):
      ohci: don't play with IRQ regs

David Howells (7):
      IRQ: Typedef the IRQ flow handler function type
      IRQ: Typedef the IRQ handler function type
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
      IRQ: Use the new typedef for interrupt handler function pointers
      ReiserFS: Make sure all dentries refs are released before calling kill_block_super()
      AUTOFS: Make sure all dentries refs are released before calling kill_anon_super()
      VFS: Destroy the dentries contributed by a superblock on unmounting

David S. Miller (5):
      [SPARC64]: Update MAINTAINERS entry.
      [SPARC64]: Fix of_device bus_id settings.
      [SPARC64]: Update defconfig.
      [SPARC32]: pcic.c needs asm/irq_regs.h
      [NET]: Do not memcmp() over pad bytes of struct flowi.

David Woodhouse (2):
      Add CONFIG_HEADERS_CHECK option to automatically run 'make headers_check'
      Fix headers_check for O= builds; disable automatic check on UML.

Davide Libenzi (1):
      epoll_pwait()

Deepak Saxena (1):
      Update smc91x driver with ARM Versatile board info

Dmitry Mishin (2):
      ext4: errors behaviour fix
      ext3: errors behaviour fix

Eran Tromer (1):
      libata: return sense data in HDIO_DRIVE_CMD ioctl

Eric Eric Sesterhenn (1):
      reiserfs: null pointer dereferencing in reiserfs_read_bitmap_block

Eric Sesterhenn (3):
      [ALSA] Fix memory leak in sound/isa/es18xx.c
      null dereference in fs/jbd/journal.c
      Remove unnecessary check in fs/fat/inode.c

Eric W. Biederman (5):
      i386/x86_64: FIX pci_enable_irq to set dev->irq to the irq number
      i386/x86_64: Remove global IO_APIC_VECTOR
      x86_64 irq: Allocate a vector across all cpus for genapic_flat.
      x86_64 irq: Scream but don't die if we receive an unexpected irq
      x86_64 irq: Properly update vector_irq

Florin Malita (2):
      [ALSA] Dereference after free in snd_hwdep_release()
      fix Module taint flags listing in Oops/panic

Franck Bui-Huu (1):
      Fix up mmap_kmem

Frederik Deweerdt (2):
      fix qla{2,4} build error
      ixp4xxdefconfig arm fixes

Geert Uytterhoeven (8):
      m68k: syscall updates
      m68k: more syscall updates
      m68k/HP300: Enable HIL configuration options
      m68k/Atari: Interrupt updates
      m68k/Apollo: Remove obsolete arch/m68k/apollo/dma.c
      m68k/MVME167: SERIAL167 is no longer broken
      m68k/MVME167: SERIAL167 tty flip buffer updates
      m68knommu: sync syscalls with m68k

Geoff Levand (2):
      [POWERPC] Minor fix for bootargs property
      [POWERPC] cell: fix default zImage build target

Haavard Skinnemoen (1):
      IRQ: Fix AVR32 breakage

Heiko Carstens (4):
      [S390] irq change build fixes.
      sysrq: irq change build fix.
      [S390] irq change improvements.
      Disable DETECT_SOFTLOCKUP for s390

Helge Deller (1):
      Fix section mismatch in de2104x.c

Henne (1):
      sched: fix a kerneldoc error on is_init()

Ingo Molnar (2):
      i386: fix rwsem build bug on CONFIG_M386=y
      lockdep: fix printk recursion logic

Ishai Rabinovitz (2):
      IB/srp: Remove redundant memset()
      IB/srp: Enable multiple connections to the same target

Jack Morgenstein (1):
      IB/mthca: Query port fix

James Bottomley (3):
      [VOYAGER] fix genirq mess
      [VOYAGER] fix up attribute packed specifiers in voyager.h
      [VOYAGER] fix up ptregs removal mess

James Morris (1):
      IPsec: propagate security module errors up from flow_cache_lookup

Jamie Lenehan (1):
      sh: Fix pr_debug statements for sh4

Jan Blunck (1):
      Fix typo in "syntax error if percpu macros are incorrectly used" patch

Jan-Bernd Themann (2):
      ehea: firmware (hvcall) interface changes
      ehea: fix port state notification, default queue sizes

Jaroslav Kysela (1):
      [ALSA] version 1.0.13

Jeff Garzik (17):
      [netdrvr] b44: handle excessive multicast groups
      arch/i386/kernel/time: don't shadow 'irq' function arg
      drivers/net: eliminate irq handler impossible checks, needless casts
      Various drivers' irq handlers: kill dead code, needless casts
      drivers/net/eepro: kill dead code
      drivers/isdn/act2000: kill irq2card_map
      irda: donauboe fixes, cleanups
      firmware/dcdbas: fix bug in error cleanup
      [libata] sata_promise: add PCI ID
      tpm: fix error handling
      x86/microcode: handle sysfs error
      firmware/dell_rbu: handle sysfs errors
      ipmi: handle sysfs errors
      EISA: handle sysfs errors
      firmware/efivars: handle error
      drivers/mca: handle sysfs errors
      ISDN: several minor fixes

Jens Axboe (4):
      elevator: elevator_type member not used
      splice: fix pipe_to_file() ->prepare_write() error path
      ide-cd: fix breakage with internally queued commands
      ide-cd: one more missing REQ_TYPE_CMD_ATA check

Jim Cromie (1):
      MAINTAINERS: take over scx200-* and pc8736* drivers

Jiri Kosina (1):
      make kernels with CONFIG_X86_GENERIC and !CONFIG_SMP compilable

Joerg Roedel (2):
      [IPV6]: Seperate sit driver to extra module
      [IPV6]: Seperate sit driver to extra module (addrconf.c changes)

Johann Lombardi (1):
      jbd2: rename slab

Jon Mason (4):
      x86-64: Calgary IOMMU: deobfuscate calgary_init
      x86-64: Calgary IOMMU: Fix off by one when calculating register space location
      x86-64: Calgary IOMMU: Update Jon's contact info
      x86-64: Calgary IOMMU: print PCI bus numbers in hex

Karl-Johan Karlsson (1):
      [MIPS] Show actual CPU information in /proc/cpuinfo

Karsten Keil (1):
      bonding: fix deadlock on high loads in bond_alb_monitor()

Karsten Wiese (3):
      [ALSA] Fix bug in snd-usb-usx2y's usX2Y_pcms_lock_check()
      [ALSA] Repair snd-usb-usx2y for usb 2.6.18
      [ALSA] Handle file operations during snd_card disconnects using static file->f_op

Keith Owens (1):
      Fix do_mbind warning with CONFIG_MIGRATION=n

Kyle McMartin (1):
      [PARISC] Make firmware calls irqsafe-ish...

Laurent Vivier (1):
      ext4: 64bit metadata

Linas Vepstas (20):
      powerpc/cell spidernet ethtool -i version number info.
      powerpc/cell spidernet burst alignment patch.
      Spidernet module parm permissions
      powerpc/cell spidernet force-end fix
      powerpc/cell spidernet zlen min packet length
      powerpc/cell spidernet add missing netdev watchdog
      Spidernet fix register field definitions
      Spidernet stop queue when queue is full.
      powerpc/cell spidernet bogus rx interrupt bit
      powerpc/cell spidernet fix error interrupt print
      powerpc/cell spidernet stop error printing patch.
      powerpc/cell spidernet incorrect offset
      powerpc/cell spidernet low watermark patch.
      powerpc/cell spidernet NAPI polling info.
      powerpc/cell spidernet refine locking
      powerpc/cell spidernet
      powerpc/cell spidernet reduce DMA kicking
      powerpc/cell spidernet variable name change
      powerpc/cell spidernet DMA direction fix
      powerpc/cell spidernet release all descrs

Linus Torvalds (7):
      Initial blind fixup for arm for irq changes
      ARM: fix up nested irq regs usage
      Revert "[POWERPC] Don't get PCI IRQ from OF for devices with no IRQ"
      Fix extraneous '&' in recent NFS client cleanup
      ACPI: Allow setting SCI_EN bit in PM1_CONTROL register
      Include proper header file for PFN_DOWN()
      Linux 2.6.19-rc2

Luca Tettamanti (1):
      Fix menuconfig build failure due to missing stdbool.h

Luke Zhang (1):
      [ALSA] WM9712 fixes for ac97_patch.c

Maciej W. Rozycki (2):
      swarm: Actually initialize the IDE driver
      32-bit compatibility HDIO IOCTLs

Mark Mason (1):
      [MIPS] Fix compilation warnings in arch/mips/sibyte/bcm1480/smp.c

Martin Habets (4):
      [SPARC32]: Fix prom.c build warning
      [SPARC32]: Mark srmmu_nocache_init as __init.
      [SPARC32]: Fix sparc32 modpost warnings with sunzilog
      [SPARC32]: Fix sparc32 modpost warnings.

Martin Schwidefsky (1):
      [S390] Use CONFIG_GENERIC_TIME and define TOD clock source.

Matthew Wilcox (7):
      Build fixes for struct pt_regs removal
      [PARISC] Use set_irq_regs
      [PA-RISC] Fix boot breakage
      [PARISC] pdc_init no longer exists
      [PARISC] More pt_regs removal
      Use linux/io.h instead of asm/io.h
      Consolidate check_signature

Matthias Urlichs (1):
      document the core-dump-to-a-pipe patch

Maxime Bizon (1):
      mv643xx_eth: Fix ethtool stats

Mel Gorman (2):
      mm: use symbolic names instead of indices for zone initialisation
      mm: remove memmap_zone_idx()

Melissa Howland (2):
      [S390] monwriter buffer limit.
      [S390] monwriter kzalloc size.

Michael Buesch (1):
      b44: fix eeprom endianess issue

Michael Ellerman (2):
      ibmveth: Harden driver initilisation
      [POWERPC] Fix boot wrapper invocation if CROSS_COMPILE contains spaces

Michael S. Tsirkin (1):
      IB/mthca: Fix off-by-one in mthca SRQ creation

Mike Frysinger (1):
      include linux/types.h in linux/nbd.h

Miklos Szeredi (1):
      [NET]: File descriptor loss while receiving SCM_RIGHTS

Mingming Cao (9):
      ext4: rename ext4 symbols to avoid duplication of ext3 symbols
      ext4: enable building of ext4
      jbd2: rename jbd2 symbols to avoid duplication of jbd symbols
      jbd2: enable building of jbd2 and have ext4 use it rather than jbd
      ext4: switch fsblk to sector_t
      jbd2: sector_t conversion
      ext4: blk_type from sector_t to unsigned long long
      ext4: removesector_t bits check
      jbd2: switch blks_type from sector_t to ull

Monakhov Dmitriy (1):
      D-cache aliasing issue in __block_prepare_write

Nathan Lynch (1):
      [POWERPC] linux,tce-size property is 32 bits

NeilBrown (2):
      md: fix bug where new drives added to an md array sometimes don't sync properly
      knfsd: tidy up up meaning of 'buffer size' in nfsd/sunrpc

Nick Piggin (5):
      [POWERPC] Fix harmless typo
      mm: bug in set_page_dirty_buffers
      mm: arch_free_page fix
      mm: locks_freed fix
      sched: likely profiling

Olaf Hering (4):
      fix mesh compile errors after irq changes
      [POWERPC] Fix up after irq changes
      [POWERPC] SPU fixup after irq changes
      [POWERPC] PReP fixup after irq changes

Olof Johansson (2):
      powerpc: irq change build breaks
      [POWERPC] Fix fsl_soc build breaks

Paolo 'Blaisorblade' Giarrusso (13):
      uml: revert wrong patch
      uml: correct removal of pte_mkexec
      uml: readd forgot prototype
      uml: make TT mode compile after setjmp-related changes
      uml: make UML_SETJMP always safe
      uml: fix processor selection to exclude unsupported processors and features
      uml: fix uname under setarch i386
      uml: declare in Kconfig our partial LOCKDEP support
      uml: allow using again x86/x86_64 crypto code
      uml: asm offsets duplication removal
      uml: remove duplicate export
      uml: deprecate CONFIG_MODE_TT
      uml: allow finer tuning for host VMSPLIT setting

Patrick Caulfield (1):
      [DLM] fix iovec length in recvmsg

Patrick McHardy (2):
      [DECNET]: Fix sfuzz hanging on 2.6.18
      [RTNETLINK]: Fix use of wrong skb in do_getlink()

Paul Mackerras (3):
      [PPC] Fix some irq breakage with ARCH=ppc
      [POWERPC] Fix xmon IRQ handler for pt_regs removal
      [POWERPC] Fix secondary CPU startup on old "powersurge" SMP powermacs

Paul Mundt (9):
      sh: First step at generic timeofday support.
      sh: Kill off timer_ops get_frequency().
      sh: Updates for IRQ handler changes.
      sh: Convert r7780rp IRQ handler to IRQ chip.
      sh: Convert INTC2 IRQ handler to irq_chip.
      sh: Convert IPR-IRQ to IRQ chip.
      sh: Zero-out coherent buffer in consistent_alloc().
      sh: Default enable R7780RP IRQs.
      sh: interrupt exception handling rework

paul.moore@hp.com (2):
      NetLabel: fix a cache race condition
      NetLabel: use SECINITSID_UNLABELED for a base SID

Pekka Enberg (2):
      slab: reduce numa text size
      um: irq changes break build

Peter Korsgaard (1):
      pata-qdi: fix le32 in data_xfer

Peter Osterlund (1):
      UDF: Fix mounting read-write

Peter Zijlstra (1):
      forcedeth: hardirq lockdep warning

Petr Vandrovec (1):
      Get core dump code to work...

Pierre Ossman (1):
      mmc: multi sector write transfers

Rafael J. Wysocki (2):
      swsusp: Make userland suspend work on SMP again
      swsusp: Use suspend_console

Ralf Baechle (23):
      [MIPS] Update Malta config.
      [MIPS] Complete fixes after removal of pt_regs argument to int handlers.
      handle_sysrq lost its pt_regs * argument
      [MIPS] DEC: pt_regs fixes for dec_intr_halt.
      [MIPS] Jazz: Fix I/O port resources.
      [MIPS] Jazz: Remove warning.  After 7 years probably somebody test this ;)
      [MIPS] Jazz: build fix - include <linux/screen_info.h>
      [MIPS] Jazz defconfig file.
      [MIPS] Ocelot C: Build fix - ll_mv64340_irq takes no more regs argument.
      [MIPS] Fix return type of gt64120_irq.
      [MIPS] DEC: pt_regs fixes for buserror handlers
      [MIPS] Cleanup unnecessary <asm/ptrace.h> inclusions.
      [MIPS] Fix RM9000 wait instruction detection.
      [MIPS] qtronix: remove driver.
      [MIPS] NUMA: Register all nodes before cpus or sysfs will barf.
      [RTC] Consistently use of tabs for formatting.
      [MIPS] Malta: Fix build for non-MIPS32/64 configuration.
      [MIPS] Alchemy: nuke usbdev; it's useless as is ...
      [MIPS] Workaround for bug in gcc -EB / -EL options.
      [MIPS] Cleanup definitions of speed_t and tcflag_t.
      [MIPS] BigSur: More useful defconfig.
      [MIPS] IP27: Make declaration of setup_replication_mask a proper prototype.
      [MIPS] Pass NULL not 0 for pointer value.

Randy Dunlap (6):
      x86-64: Fix compilation without CONFIG_KALLSYMS
      ext4: clean up comments in ext4-extents patch
      kernel-doc: fix function name in usercopy.c
      uaccess.h: match kernel-doc and function names
      kernel-doc: drop various "inline" qualifiers
      kernel-doc: make parameter description indentation uniform

Ravikiran Thirumalai (1):
      Fix build breakage with CONFIG_X86_VSMP

Reinette Chatre (1):
      bitmap: parse input from kernel and user buffers

Roland Dreier (2):
      RDMA/amso1100: Fix build with debugging off
      IPoIB: Check for DMA mapping error for TX packets

Roman Zippel (5):
      provide tickadj define
      m68k: cleanup string functions
      m68k: fix typo in __generic_copy_to_user
      m68k: small system.h cleanup
      m68k: fix NBPG define

Russell Cattelan (2):
      [GFS2] Fix a size calculation error
      [GFS2] Pass the correct value to kunmap_atomic

Ryusuke Sakato (1):
      sh: SH-4A UBC support

Santiago Leon (4):
      ibmveth: Add netpoll function
      ibmveth: kdump interrupt fix
      ibmveth: rename proc entry name
      ibmveth: fix int rollover panic

Sasha Khapyorsky (1):
      [ALSA] hda/patch_si3054: new codec vendor IDs

Scott Ashcroft (1):
      [MIPS] Cobalt: Time runs too quickly

Sean Hefty (2):
      IB/cm: Fix timewait crash after module unload
      IB/cm: Send DREP in response to unmatched DREQ

Stefan Richter (1):
      ieee1394: nodemgr: fix startup of knodemgrd

Stephane Eranian (1):
      Add carta_random32() library routine

Stephen Hemminger (8):
      sky2: incorrect length on receive packets
      skge: fix stuck irq when fiber down
      skge: pause mapping for fiber
      skge: better flow control negotiation
      skge: version 1.9
      sky2: revert pci express extensions
      sky2: set lower pause threshold to prevent overrun
      thermal throttle: sysfs error checking

Stephen Rothwell (3):
      [POWERPC] Update iseries_defconfig
      [POWERPC] Fix viocons for irq breakage
      [POWERPC] Fix iseries/smp.c for irq breakage

Steve French (26):
      CIFS: Use SEEK_END instead of hardcoded value
      [CIFS] Legacy time handling for Win9x and OS/2 part 1
      [CIFS] Remove static and unused symbols
      [CIFS] Fix build break
      [CIFS] Remove unused prototypes
      [CIFS] More removing of unused functions
      [CIFS] Fix build break ifdef in wrong place
      [CIFS] CIFS support for /proc/<pid>/mountstats part 1
      [CIFS] Handle legacy servers which return undefined time zone
      [CIFS] Rename server time zone field
      [CIFS] Fix typo in name of new cifs_show_stats
      [CIFS] Do not send newer QFSInfo to legacy servers which can not support it
      [CIFS] Make use of newer QFSInfo dependent on capability bit instead of
      [CIFS] Allow LANMAN21 support even in both POSIX non-POSIX path
      [CIFS] Fix readdir of large directories for backlevel servers
      [CIFS] Allow for 15 minute TZs (e.g. Nepal) and be more explicit about
      [CIFS] Fix typo
      [CIFS] Fix compiler warning with previous patch
      [CIFS] readdir (ffirst) enablement of accurate timestamps from legacy servers
      [CIFS] Fix leaps year calculation for years after 2100
      [CIFS] Do not need to adjust for Jan/Feb for leap day
      [CIFS] Fix old DOS time conversion to handle timezone
      [CIFS] fix typo in previous patch
      [CIFS] Level 1 QPathInfo needed for proper OS2 support
      [CIFS] Workaround incomplete byte length returned by some
      [CIFS] Missing flags2 for DFS

Steven Whitehouse (3):
      [GFS2] Fix uninitialised variable
      [GFS2] Fix bug where lock not held
      [GFS2] Update git tree name/location

Suparna Bhattacharya (1):
      ext4: uninitialised extent handling

Timur Tabi (1):
      [POWERPC] Add DTS for MPC8349E-mITX board

Tobin Davis (1):
      [ALSA] Add new subdevice ids for hda-intel

Tom Tucker (1):
      RDMA/amso1100: Add spinlocks to serialize ib_post_send/ib_post_recv

Tony Luck (1):
      [IA64] Fix breakage from irq change

Trond Myklebust (3):
      NFS: Fix typo in nfs_get_client()
      NFS: Fix typo in nfs_get_client()
      VM: Fix the gfp_mask in invalidate_complete_page2

Vasily Averin (1):
      ext2: errors behaviour fix

Vasily Tarasov (3):
      block layer: elevator_find function cleanup
      block layer: elv_iosched_show should get elv_list_lock
      block layer: ioprio_best function fix

Venkat Yekkirala (2):
      IPsec: correct semantics for SELinux policy matching
      IPsec: fix handling of errors for socket policies

Vlad Yasevich (2):
      [SCTP]: Fix receive buffer accounting.
      [SCTP]: Fix the RX queue size shown in /proc/net/sctp/assocs output.

Yoichi Yuasa (2):
      [MIPS] Fix DECserial build error by IRQ hander change
      [MIPS] Fix timer setup for Jazz

YOSHIFUJI Hideaki (4):
      [TCP]: Use TCPOLEN_TSTAMP_ALIGNED macro instead of magic number.
      [NET]: Use hton{l,s}() for non-initializers.
      [NET]: Use typesafe inet_twsk() inline function instead of cast.
      [NET]: Introduce protocol-specific destructor for time-wait sockets.

Zach Brown (1):
      64-bit jbd2 core

Re: Linux 2.6.19-rc2

[Alistair John Strachan]

On Friday 13 October 2006 17:49, Linus Torvalds wrote:
> Ok, it's a week since -rc1, so -rc2 is out there.

Does anybody know what's up with the git server? Hopefully it's just my 
connection...

[alistair] 18:38 [~/linux-git] git pull
fatal: unexpected EOF
Fetch failure: 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Linux 2.6.19-rc2

[Michal Piotrowski]

Hi,

Linus Torvalds wrote:
> Ok, it's a week since -rc1, so -rc2 is out there.
> 

Please consider applying this patches.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)


----
[PATCH] Fix 'headers_install' with separate output directory

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

diff --git a/Makefile b/Makefile
index 80dac02..bdf7c18 100644
--- a/Makefile
+++ b/Makefile
@@ -932,7 +932,7 @@ headers_install_all: include/linux/versi

 PHONY += headers_install
 headers_install: include/linux/version.h scripts_basic FORCE
-	@if [ ! -r include/asm-$(ARCH)/Kbuild ]; then \
+	@if [ ! -r $(srctree)/include/asm-$(ARCH)/Kbuild ]; then \
 	  echo '*** Error: Headers not exportable for this architecture ($(ARCH))'; \
 	  exit 1 ; fi
 	$(Q)$(MAKE) $(build)=scripts scripts/unifdef



---

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index cac8f21..6a7b740 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -168,7 +168,7 @@ ifdef GENASM
 	$(call cmd,gen)

 else
-$(objhdr-y) :		$(INSTALL_HDR_PATH)/$(_dst)/%.h: $(srctree)/$(obj)/%.h $(KBUILDFILES)
+$(objhdr-y) :		$(INSTALL_HDR_PATH)/$(_dst)/%.h: $(objtree)/$(obj)/%.h $(KBUILDFILES)
 	$(call cmd,o_hdr_install)

 $(header-y) :		$(INSTALL_HDR_PATH)/$(_dst)/%.h: $(srctree)/$(obj)/%.h $(KBUILDFILES)

Re: Linux 2.6.19-rc2

[H. Peter Anvin]

Alistair John Strachan wrote:
> On Friday 13 October 2006 17:49, Linus Torvalds wrote:
>> Ok, it's a week since -rc1, so -rc2 is out there.
> 
> Does anybody know what's up with the git server? Hopefully it's just my 
> connection...
> 
> [alistair] 18:38 [~/linux-git] git pull
> fatal: unexpected EOF
> Fetch failure: 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 

No, this is the result of a serious problem with gitweb.

We run gitweb behind a cache (otherwise it would be unacceptably 
expensive), but when httpd starts timing out on gitweb, it spawns gitweb 
over and over and over again, and the load on the machine skyrockets, 
throttling other services.

This happens every time we're on one server instead of two (one server 
is down right now for network rewiring.)

I think for now I'm just going to put a loadavg cap on running gitweb...

	-hpa

Re: Linux 2.6.19-rc2

[Paolo Ornati]

On Fri, 13 Oct 2006 18:40:28 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:

> Does anybody know what's up with the git server? Hopefully it's just my 
> connection...
> 
> [alistair] 18:38 [~/linux-git] git pull
> fatal: unexpected EOF
> Fetch failure: 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Same problem here.

-- 
	Paolo Ornati
	Linux 2.6.19-rc1-g9eb20074 on x86_64

Re: Linux 2.6.19-rc2

[Linus Torvalds]

On Fri, 13 Oct 2006, Alistair John Strachan wrote:
> 
> Does anybody know what's up with the git server? Hopefully it's just my 
> connection...

It's likely either
 - a mirroring issue (the git.kernel.org server is _not_ the main one I 
   push to, so it can take a while, and if some objects haven't made it, 
   the upload side will exit because the repository isn't "valid" until 
   the full mirror has happened)
 - too many clients trying at the same time

In this case, I suspect the latter.

		Linus

Re: Linux 2.6.19-rc2

[Michal Piotrowski]

On 13/10/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi,
>
> Linus Torvalds wrote:
> > Ok, it's a week since -rc1, so -rc2 is out there.
> >
>
> Please consider applying this patches.
>

Aghr... mirror problem. Please ignore.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0e7af8d04ecb4f6ba8cd1f731f036a004ad0e174

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: Linux 2.6.19-rc2

[Alex Romosan]

Linus Torvalds <torvalds@osdl.org> writes:

> So if you had issues with -rc1 (which had a ton of merges - even
> more so than most -rc1 releases, I think), this should hopefully be
> a lot better.

airo driver suspend is still broken. i still need to apply the patch
posted originally at (with an explanation of why airo suspend is not
working anymore)
http://marc.theaimsgroup.com/?l=linux-kernel&m=116025080215854&w=2 to
get the driver to suspend. (the patch still applies to 2.6.19-rc2 with
minor fuzz).

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |

Re: Linux 2.6.19-rc2

[Olaf Hering]

On Fri, Oct 13, Linus Torvalds wrote:

> 
> Ok, it's a week since -rc1, so -rc2 is out there.

The tar.gz is broken:
tar tvfz /mounts/mirror/kernel/v2.6/testing/linux-2.6.19-rc2.tar.gz| head
-rw-r--r-- git/git         542 2006-10-13 18:25:04 linux-2.6.19-rc2.gitignore
-rw-r--r-- git/git       18693 2006-10-13 18:25:04 linux-2.6.19-rc2COPYING
-rw-r--r-- git/git       90289 2006-10-13 18:25:04 linux-2.6.19-rc2CREDITS

Re: Linux 2.6.19-rc2

[Willy Tarreau]

On Fri, Oct 13, 2006 at 10:55:17AM -0700, H. Peter Anvin wrote:
> Alistair John Strachan wrote:
> >On Friday 13 October 2006 17:49, Linus Torvalds wrote:
> >>Ok, it's a week since -rc1, so -rc2 is out there.
> >
> >Does anybody know what's up with the git server? Hopefully it's just my 
> >connection...
> >
> >[alistair] 18:38 [~/linux-git] git pull
> >fatal: unexpected EOF
> >Fetch failure: 
> >git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >
> 
> No, this is the result of a serious problem with gitweb.
> 
> We run gitweb behind a cache (otherwise it would be unacceptably 
> expensive), but when httpd starts timing out on gitweb, it spawns gitweb 
> over and over and over again, and the load on the machine skyrockets, 
> throttling other services.
> 
> This happens every time we're on one server instead of two (one server 
> is down right now for network rewiring.)
> 
> I think for now I'm just going to put a loadavg cap on running gitweb...

I encountered a similar problem (to a far lower scale) when putting
gitweb on my poor parisc server behind my ADSL line. The machine used
to OOM several times a week. So I've set up an haproxy instance in
front of it with a limit on the number of concurrent connections per
backend. All excess connections are queued and served as soon as one
slot frees up. The machine has never crashed since. Would you be
interested in some help in trying to set it up ? Assuming that epoll
is available, I have absolutely no worries about the load. As an added
benefit, it could also provide HA and LB but I understand it's not the
main concern right now.

Willy

[0/3] 2.6.19-rc2: known regressions

[Adrian Bunk]

As usual, we are swamped with bug reports for regressions after -rc1.

For an easier reading (and hoping linux-kernel might not eat the emails), 
I've splitted the list of known regressions in three emails:
  [1/3] known unfixed regressions
  [2/3] knwon regressions with workarounds
  [3/3] known regressions with patches


cu
Adrian

-- 

       "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

[1/3] 2.6.19-rc2: known unfixed regressions

[Adrian Bunk]

This email lists some known unfixed regressions in 2.6.19-rc2 compared 
to 2.6.18.

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    : CONFIG_X86_VOYAGER=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter  : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By  : David Howells <dhowells@redhat.com>
             commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status     : unknown


Subject    : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter  : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By  : David Howells <dhowells@redhat.com>
             commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status     : unknown


Subject    : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter  : Alex Romosan <romosan@sycorax.lbl.gov>
Status     : unknown


Subject    : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter  : Thierry Vignaud <tvignaud@mandriva.com>
Status     : unknown


Subject    : monitor not active after boot
References : http://lkml.org/lkml/2006/10/5/338
Submitter  : Olaf Hering <olaf@aepfle.de>
Caused-By  : Antonino Daplas <adaplas@pol.net>
             commit 346bc21026e7a92e1d7a4a1b3792c5e8b686133d
Status     : unknown


Subject    : SMP x86_64 boot problem
References : http://lkml.org/lkml/2006/9/28/330
             http://lkml.org/lkml/2006/10/5/289
Submitter  : art@usfltd.com
Status     : submitter was asked to git bisect
             result of bisecting seems to be wrong


Subject    : do_IRQ: No irq handler for vector
References : http://lkml.org/lkml/2006/10/11/13
Submitter  : Robert Hancock <hancockr@shaw.ca>
Handled-By : "Eric W. Biederman" <ebiederm@xmission.com>
Status     : Andrew: a few people are seeing this. Eric is working it.


Subject    : messed up keyboard events, TSC related
References : http://bugzilla.kernel.org/show_bug.cgi?id=7291
Submitter  : David Gerber <dg-kernel-bug@zapek.com>
Handled-By : Dmitry Torokhov <dtor@insightbb.com>
             John Stultz <johnstul@us.ibm.com>
Status     : Dmitry and John are investigating


Subject    : ide-generic no longer finds marvell controller
References : http://bugzilla.kernel.org/show_bug.cgi?id=7353
Submitter  : Kenny Graunke <kenny@whitecape.org>
Caused-By  : Patrick Jefferson <henj@hp.com>
             commit a4bea10eca68152e84ffc4eaeb9d20ec2ac34664
Handled-By : Alan Cox <alan@redhat.com>
Status     : Alan is investigating


Subject    : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter  : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
Status     : Mark is investigating

[2/3] 2.6.19-rc2: knwon regressions with workarounds

[Adrian Bunk]

This email lists some known regressions with workarounds in 2.6.19-rc2 
compared to 2.6.18.

Unless proper solutions become available, we should implement the 
workarounds.

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.

Please trim the Cc when answering.

Subject    : snd-hda-intel <-> forcedeth MSI problem
References : http://lkml.org/lkml/2006/10/5/40
             http://lkml.org/lkml/2006/10/7/164
Submitter  : Prakash Punnoor <prakash@punnoor.de>
Status     : suggested workaround for 2.6.19:
             deactivate MSI in snd-intel-hda by default


Subject    : DVB frontend selection causes compile errors
References : http://lkml.org/lkml/2006/10/8/244
Submitter  : Adrian Bunk <bunk@stusta.de>
Caused-By  : "Andrew de Quincey" <adq_dvb@lidskialf.net>
             commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba
Handled-By : Michael Krufky <mkrufky@linuxtv.org>
             "Andrew de Quincey" <adq_dvb@lidskialf.net>
Status     : possible workaround: don't allow CONFIG_DVB_FE_CUSTOMISE=y

Re: [1/3] 2.6.19-rc2: known unfixed regressions

[Eric W. Biederman]

Adrian Bunk <bunk@stusta.de> writes:

> This email lists some known unfixed regressions in 2.6.19-rc2 compared 
> to 2.6.18.
>
> 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    : do_IRQ: No irq handler for vector
> References : http://lkml.org/lkml/2006/10/11/13
> Submitter  : Robert Hancock <hancockr@shaw.ca>
> Handled-By : "Eric W. Biederman" <ebiederm@xmission.com>
> Status     : Andrew: a few people are seeing this. Eric is working it.

Please see commit: 994bd4f9f5a065ead4a92435fdd928ac7fd33809
That part should fine in -rc2

YH found a corner case I missed (in my bug fix refactoring) and submitted a patch
earlier today.  But that only shows up when we resubmit an irq which
is almost never.

Eric

Re: [3/3] 2.6.19-r2: known regressions with patches

[Jean Delvare]

Hi Adrian,

On Sat, 14 Oct 2006 13:34:09 +0200, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.19-rc2 compared to 2.6.18
> with patches available.
> 
> Unless there are specific reasons against doing so, we should try to get 
> these patches into -rc3.
> 
> (Especially the lad who wrote the patch for the third entry should ush 
>  his patch...)
> 
> 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    : w83781d modprobing failure
> References : http://bugzilla.kernel.org/show_bug.cgi?id=7293
> Submitter  : Sylvain BERTRAND <sylvain.bertrand@gmail.com>
> Caused-By  : David Hubbard <david.c.hubbard@gmail.com> (?)
>              commit 8202632647278eba7223727dc442f49227c040d0 (?)
> Handled-By : Jean Delvare <khali@linux-fr.org>
> Patch      : http://bugzilla.kernel.org/show_bug.cgi?id=7293
> Status     : patch available

Patch was tested successfully by Sylvain, I sent it to Greg already,
who should push it to Linus soon (with 7 other hwmon patches.)

Thanks,
-- 
Jean Delvare

Re: [0/3] 2.6.19-rc2: known regressions

[Russell King]

On Sat, Oct 14, 2006 at 01:14:58PM +0200, Adrian Bunk wrote:
> As usual, we are swamped with bug reports for regressions after -rc1.
> 
> For an easier reading (and hoping linux-kernel might not eat the emails), 
> I've splitted the list of known regressions in three emails:
>   [1/3] known unfixed regressions
>   [2/3] knwon regressions with workarounds
>   [3/3] known regressions with patches

There's a raft of ARM regressions as well (see
http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html), mostly
related to the IRQ changes, as well as this error:

sysctl_net.c:(.text+0x64a8c): undefined reference to `highest_possible_node_id'

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [0/3] 2.6.19-rc2: known regressions

[Adrian Bunk]

On Sun, Oct 15, 2006 at 01:24:54PM +0100, Russell King wrote:
> On Sat, Oct 14, 2006 at 01:14:58PM +0200, Adrian Bunk wrote:
> > As usual, we are swamped with bug reports for regressions after -rc1.
> > 
> > For an easier reading (and hoping linux-kernel might not eat the emails), 
> > I've splitted the list of known regressions in three emails:
> >   [1/3] known unfixed regressions
> >   [2/3] knwon regressions with workarounds
> >   [3/3] known regressions with patches
> 
> There's a raft of ARM regressions as well (see
> http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html), mostly
> related to the IRQ changes, as well as this error:

Thanks, I'll look at them before preparing the next version of my 
regressions list.

> sysctl_net.c:(.text+0x64a8c): undefined reference to `highest_possible_node_id'

This problem already got an entry a few hours ago:

Subject    : undefined reference to highest_possible_node_id
References : http://lkml.org/lkml/2006/9/4/233
             http://lkml.org/lkml/2006/10/15/11
Submitter  : Olaf Hering <olaf@aepfle.de>
Caused-By  : Greg Banks <gnb@melbourne.sgi.com>
             commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
Status     : unknown

> Russell King

cu
Adrian

-- 

       "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

Re: 2.6.19-rc2: known unfixed regressions (v2)

[Olaf Hering]

On Tue, Oct 17, Adrian Bunk wrote:

> Subject    : monitor not active after boot
> References : http://lkml.org/lkml/2006/10/5/338
> Submitter  : Olaf Hering <olaf@aepfle.de>
> Caused-By  : Antonino Daplas <adaplas@pol.net>
>              commit 346bc21026e7a92e1d7a4a1b3792c5e8b686133d
> Status     : unknown

The nvidiafb change was removed again. I will see if I can figure out
why the EDID is lost.

Re: 2.6.19-rc2: known unfixed regressions (v2)

[Adrian Bunk]

On Tue, Oct 17, 2006 at 06:23:23PM +0200, Olaf Hering wrote:
> On Tue, Oct 17, Adrian Bunk wrote:
> 
> > Subject    : monitor not active after boot
> > References : http://lkml.org/lkml/2006/10/5/338
> > Submitter  : Olaf Hering <olaf@aepfle.de>
> > Caused-By  : Antonino Daplas <adaplas@pol.net>
> >              commit 346bc21026e7a92e1d7a4a1b3792c5e8b686133d
> > Status     : unknown
> 
> The nvidiafb change was removed again. I will see if I can figure out
> why the EDID is lost.

Thanks for the information, I missed this patch.

cu
Adrian

-- 

       "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

Re: [0/3] 2.6.19-rc2: known regressions

[Russell King]

On Sun, Oct 15, 2006 at 02:42:10PM +0200, Adrian Bunk wrote:
> On Sun, Oct 15, 2006 at 01:24:54PM +0100, Russell King wrote:
> > On Sat, Oct 14, 2006 at 01:14:58PM +0200, Adrian Bunk wrote:
> > > As usual, we are swamped with bug reports for regressions after -rc1.
> > > 
> > > For an easier reading (and hoping linux-kernel might not eat the emails), 
> > > I've splitted the list of known regressions in three emails:
> > >   [1/3] known unfixed regressions
> > >   [2/3] knwon regressions with workarounds
> > >   [3/3] known regressions with patches
> > 
> > There's a raft of ARM regressions as well (see
> > http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html), mostly
> > related to the IRQ changes, as well as this error:
> 
> Thanks, I'll look at them before preparing the next version of my 
> regressions list.
> 
> > sysctl_net.c:(.text+0x64a8c): undefined reference to `highest_possible_node_id'
> 
> This problem already got an entry a few hours ago:
> 
> Subject    : undefined reference to highest_possible_node_id
> References : http://lkml.org/lkml/2006/9/4/233
>              http://lkml.org/lkml/2006/10/15/11
> Submitter  : Olaf Hering <olaf@aepfle.de>
> Caused-By  : Greg Banks <gnb@melbourne.sgi.com>
>              commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> Status     : unknown

Looking at this commit and the mails, it was known on the 4th September
that this patch caused build errors while this change was in -mm, yet it
still found its way into mainline on 2nd October.

Is anyone going to look at fixing this problem, or should we be asking
for the commit to be reverted?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

[2.6.19 patch] drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...)

[Adrian Bunk]

On Wed, Oct 18, 2006 at 07:18:44PM -0400, Alan Cox wrote:
> On Thu, Oct 19, 2006 at 12:15:20AM +0200, Adrian Bunk wrote:
> > IOW, your patch does break existing setups since the change to 
> > module_param() requires prefixing with the module name (the ata_generic 
> > option with the same name is irrelevant)?
> > 
> > Considering that drivers/ide/ is slowly approaching a RIP status, 
> > is such an incompatible change really required?
> > 
> > I'd be more inclined to revert your patch.
> 
> We shouldn't revert it - there is a real problem for some users whose
> distro has it modular this fixed. We might want to honour both 

Agreed, patch below.

cu
Adrian


<--  snip  -->


The change from __setup() to module_param_named() requires users to 
prefix the option with "generic.".

This patch re-adds the __setup() additionally to the 
module_param_named().

Usually it would make sense getting rid of such an obsolete __setup() at 
some time, but considering that drivers/ide/ is slowly approaching a RIP 
status it's already implicitely scheduled for removal.

This patch fixes kernel Bugzilla #7353.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6/drivers/ide/pci/generic.c.old	2006-10-19 16:35:15.000000000 +0200
+++ linux-2.6/drivers/ide/pci/generic.c	2006-10-19 16:46:21.000000000 +0200
@@ -40,6 +40,19 @@
 
 static int ide_generic_all;		/* Set to claim all devices */
 
+/*
+ * the module_param_named() was added for the modular case
+ * the __setup() is left as compatibility for existing setups
+ */
+#ifndef MODULE
+static int __init ide_generic_all_on(char *unused)
+{
+	ide_generic_all = 1;
+	printk(KERN_INFO "IDE generic will claim all unknown PCI IDE storage controllers.");
+	return 1;
+}
+__setup("all-generic-ide", ide_generic_all_on);
+#endif
 module_param_named(all_generic_ide, ide_generic_all, bool, 0444);
 MODULE_PARM_DESC(all_generic_ide, "IDE generic will claim all unknown PCI IDE storage controllers.");
 

Re: [2.6.19 patch] drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...)

[Randy Dunlap]

On Thu, 19 Oct 2006 17:26:51 +0200 Adrian Bunk wrote:

> On Wed, Oct 18, 2006 at 07:18:44PM -0400, Alan Cox wrote:
> > On Thu, Oct 19, 2006 at 12:15:20AM +0200, Adrian Bunk wrote:
> > > IOW, your patch does break existing setups since the change to 
> > > module_param() requires prefixing with the module name (the ata_generic 
> > > option with the same name is irrelevant)?
> > > 
> > > Considering that drivers/ide/ is slowly approaching a RIP status, 
> > > is such an incompatible change really required?
> > > 
> > > I'd be more inclined to revert your patch.
> > 
> > We shouldn't revert it - there is a real problem for some users whose
> > distro has it modular this fixed. We might want to honour both 
> 
> Agreed, patch below.
> 
> cu
> Adrian
> 
> 
> <--  snip  -->
> 
> 
> The change from __setup() to module_param_named() requires users to 
> prefix the option with "generic.".
> 
> This patch re-adds the __setup() additionally to the 
> module_param_named().
> 
> Usually it would make sense getting rid of such an obsolete __setup() at 
> some time, but considering that drivers/ide/ is slowly approaching a RIP 
> status it's already implicitely scheduled for removal.
> 
> This patch fixes kernel Bugzilla #7353.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> --- linux-2.6/drivers/ide/pci/generic.c.old	2006-10-19 16:35:15.000000000 +0200
> +++ linux-2.6/drivers/ide/pci/generic.c	2006-10-19 16:46:21.000000000 +0200
> @@ -40,6 +40,19 @@
>  
>  static int ide_generic_all;		/* Set to claim all devices */
>  
> +/*
> + * the module_param_named() was added for the modular case
> + * the __setup() is left as compatibility for existing setups
> + */
> +#ifndef MODULE
> +static int __init ide_generic_all_on(char *unused)
> +{
> +	ide_generic_all = 1;
> +	printk(KERN_INFO "IDE generic will claim all unknown PCI IDE storage controllers.");
> +	return 1;
> +}
> +__setup("all-generic-ide", ide_generic_all_on);
> +#endif
>  module_param_named(all_generic_ide, ide_generic_all, bool, 0444);
>  MODULE_PARM_DESC(all_generic_ide, "IDE generic will claim all unknown PCI IDE storage controllers.");

Missing update to Documentation/kernel-parameters.txt ?
(maybe it's been missing forever?)

---
~Randy

Re: [2.6.19 patch] drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...)

[Adrian Bunk]

On Thu, Oct 19, 2006 at 09:07:41AM -0700, Randy Dunlap wrote:
> On Thu, 19 Oct 2006 17:26:51 +0200 Adrian Bunk wrote:
>...
> > --- linux-2.6/drivers/ide/pci/generic.c.old	2006-10-19 16:35:15.000000000 +0200
> > +++ linux-2.6/drivers/ide/pci/generic.c	2006-10-19 16:46:21.000000000 +0200
> > @@ -40,6 +40,19 @@
> >  
> >  static int ide_generic_all;		/* Set to claim all devices */
> >  
> > +/*
> > + * the module_param_named() was added for the modular case
> > + * the __setup() is left as compatibility for existing setups
> > + */
> > +#ifndef MODULE
> > +static int __init ide_generic_all_on(char *unused)
> > +{
> > +	ide_generic_all = 1;
> > +	printk(KERN_INFO "IDE generic will claim all unknown PCI IDE storage controllers.");
> > +	return 1;
> > +}
> > +__setup("all-generic-ide", ide_generic_all_on);
> > +#endif
> >  module_param_named(all_generic_ide, ide_generic_all, bool, 0444);
> >  MODULE_PARM_DESC(all_generic_ide, "IDE generic will claim all unknown PCI IDE storage controllers.");
> 
> Missing update to Documentation/kernel-parameters.txt ?
> (maybe it's been missing forever?)

It's been missing forever.

I'm not sure whether documenting it now where it's deprecated and nearly 
dead makes sense..

> ~Randy

cu
Adrian

-- 

       "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

Re: [2.6.19 patch] drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...)

[Alan Cox]

Ar Iau, 2006-10-19 am 18:13 +0200, ysgrifennodd Adrian Bunk:
> > Missing update to Documentation/kernel-parameters.txt ?
> > (maybe it's been missing forever?)
> 
> It's been missing forever.
> 
> I'm not sure whether documenting it now where it's deprecated and nearly 
> dead makes sense..

Its not dead, its so useful that drivers/ata also supports it

Re: [0/3] 2.6.19-rc2: known regressions

[Russell King]

On Thu, Oct 19, 2006 at 09:17:54AM +0100, Russell King wrote:
> On Sun, Oct 15, 2006 at 02:42:10PM +0200, Adrian Bunk wrote:
> > On Sun, Oct 15, 2006 at 01:24:54PM +0100, Russell King wrote:
> > > On Sat, Oct 14, 2006 at 01:14:58PM +0200, Adrian Bunk wrote:
> > > > As usual, we are swamped with bug reports for regressions after -rc1.
> > > > 
> > > > For an easier reading (and hoping linux-kernel might not eat the emails), 
> > > > I've splitted the list of known regressions in three emails:
> > > >   [1/3] known unfixed regressions
> > > >   [2/3] knwon regressions with workarounds
> > > >   [3/3] known regressions with patches
> > > 
> > > There's a raft of ARM regressions as well (see
> > > http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html), mostly
> > > related to the IRQ changes, as well as this error:
> > 
> > Thanks, I'll look at them before preparing the next version of my 
> > regressions list.
> > 
> > > sysctl_net.c:(.text+0x64a8c): undefined reference to `highest_possible_node_id'
> > 
> > This problem already got an entry a few hours ago:
> > 
> > Subject    : undefined reference to highest_possible_node_id
> > References : http://lkml.org/lkml/2006/9/4/233
> >              http://lkml.org/lkml/2006/10/15/11
> > Submitter  : Olaf Hering <olaf@aepfle.de>
> > Caused-By  : Greg Banks <gnb@melbourne.sgi.com>
> >              commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> > Status     : unknown
> 
> Looking at this commit and the mails, it was known on the 4th September
> that this patch caused build errors while this change was in -mm, yet it
> still found its way into mainline on 2nd October.
> 
> Is anyone going to look at fixing this problem, or should we be asking
> for the commit to be reverted?

Since everyone seems intent at ignoring this issue, here's a patch to
try to solve it.

Probably will suffer from occasionally not being included in the kernel,
and therefore the function not exported for modules, but at least it's
a _lot_ better than the current utterly broken situation.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

diff --git a/lib/Makefile b/lib/Makefile
index cf98fab..8845514 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -5,7 +5,7 @@ #
 lib-y := ctype.o string.o vsprintf.o cmdline.o \
 	 bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \
 	 idr.o div64.o int_sqrt.o bitmap.o extable.o prio_tree.o \
-	 sha1.o irq_regs.o
+	 sha1.o irq_regs.o nodemask.o
 
 lib-$(CONFIG_MMU) += ioremap.o
 lib-$(CONFIG_SMP) += cpumask.o
diff --git a/lib/cpumask.c b/lib/cpumask.c
index 7a2a73f..3a67dc5 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -43,19 +43,3 @@ int __any_online_cpu(const cpumask_t *ma
 	return cpu;
 }
 EXPORT_SYMBOL(__any_online_cpu);
-
-#if MAX_NUMNODES > 1
-/*
- * Find the highest possible node id.
- */
-int highest_possible_node_id(void)
-{
-	unsigned int node;
-	unsigned int highest = 0;
-
-	for_each_node_mask(node, node_possible_map)
-		highest = node;
-	return highest;
-}
-EXPORT_SYMBOL(highest_possible_node_id);
-#endif
diff --git a/lib/nodemask.c b/lib/nodemask.c
new file mode 100644
index 0000000..6c49eb5
--- /dev/null
+++ b/lib/nodemask.c
@@ -0,0 +1,19 @@
+#include <linux/kernel.h>
+#include <linux/cpumask.h>
+#include <linux/module.h>
+
+#if MAX_NUMNODES > 1
+/*
+ * Find the highest possible node id.
+ */
+int highest_possible_node_id(void)
+{
+	unsigned int node;
+	unsigned int highest = 0;
+
+	for_each_node_mask(node, node_possible_map)
+		highest = node;
+	return highest;
+}
+EXPORT_SYMBOL(highest_possible_node_id);
+#endif


-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [0/3] 2.6.19-rc2: known regressions

[Andrew Morton]

On Fri, 20 Oct 2006 19:07:22 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> > > Subject    : undefined reference to highest_possible_node_id
> > > References : http://lkml.org/lkml/2006/9/4/233
> > >              http://lkml.org/lkml/2006/10/15/11
> > > Submitter  : Olaf Hering <olaf@aepfle.de>
> > > Caused-By  : Greg Banks <gnb@melbourne.sgi.com>
> > >              commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> > > Status     : unknown
> > 
> > Looking at this commit and the mails, it was known on the 4th September
> > that this patch caused build errors while this change was in -mm, yet it
> > still found its way into mainline on 2nd October.
> > 
> > Is anyone going to look at fixing this problem, or should we be asking
> > for the commit to be reverted?
> 
> Since everyone seems intent at ignoring this issue, here's a patch to
> try to solve it.

I sent the below to Linus yesterday...



From: Andrew Morton <akpm@osdl.org>

Qooting Adrian:

- net/sunrpc/svc.c uses highest_possible_node_id()

- include/linux/nodemask.h says highest_possible_node_id() is
  out-of-line #if MAX_NUMNODES > 1

- the out-of-line highest_possible_node_id() is in lib/cpumask.c

- lib/Makefile: lib-$(CONFIG_SMP) += cpumask.o
  CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n, CONFIG_SUNRPC=y

-> highest_possible_node_id() is used in net/sunrpc/svc.c
   CONFIG_NODES_SHIFT defined and > 0

-> include/linux/numa.h: MAX_NUMNODES > 1

-> compile error

The bug is not present on architectures where ARCH_DISCONTIGMEM_ENABLE 
depends on NUMA (but m32r isn't the only affected architecture).


So move the function into page_alloc.c

Cc: Adrian Bunk <bunk@stusta.de>
Cc: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 lib/cpumask.c   |   16 ----------------
 mm/page_alloc.c |   16 ++++++++++++++++
 2 files changed, 16 insertions(+), 16 deletions(-)

diff -puN lib/cpumask.c~highest_possible_node_id-linkage-fix lib/cpumask.c
--- a/lib/cpumask.c~highest_possible_node_id-linkage-fix
+++ a/lib/cpumask.c
@@ -43,19 +43,3 @@ int __any_online_cpu(const cpumask_t *ma
 	return cpu;
 }
 EXPORT_SYMBOL(__any_online_cpu);
-
-#if MAX_NUMNODES > 1
-/*
- * Find the highest possible node id.
- */
-int highest_possible_node_id(void)
-{
-	unsigned int node;
-	unsigned int highest = 0;
-
-	for_each_node_mask(node, node_possible_map)
-		highest = node;
-	return highest;
-}
-EXPORT_SYMBOL(highest_possible_node_id);
-#endif
diff -puN mm/page_alloc.c~highest_possible_node_id-linkage-fix mm/page_alloc.c
--- a/mm/page_alloc.c~highest_possible_node_id-linkage-fix
+++ a/mm/page_alloc.c
@@ -3120,3 +3120,19 @@ unsigned long page_to_pfn(struct page *p
 EXPORT_SYMBOL(pfn_to_page);
 EXPORT_SYMBOL(page_to_pfn);
 #endif /* CONFIG_OUT_OF_LINE_PFN_TO_PAGE */
+
+#if MAX_NUMNODES > 1
+/*
+ * Find the highest possible node id.
+ */
+int highest_possible_node_id(void)
+{
+	unsigned int node;
+	unsigned int highest = 0;
+
+	for_each_node_mask(node, node_possible_map)
+		highest = node;
+	return highest;
+}
+EXPORT_SYMBOL(highest_possible_node_id);
+#endif
_

Re: Linux 2.6.19-rc2

[Kevin Radloff]

On 10/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Ok, it's a week since -rc1, so -rc2 is out there.

A bit behind, but booting still takes ages on my laptop as
libata/ata_piix tries to probe a device that isn't there (I reported
this previously against -rc1, but got no response):

Linux version 2.6.19-rc2 (root@farstrider) (gcc version 4.1.2 20061007
(prerelease) (Debian 4.1.1-16)) #1 PREEMPT Tue Oct 17 11:40:02 EDT
2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003f6f0000 (usable)
 BIOS-e820: 000000003f6f0000 - 000000003f6fb000 (ACPI data)
 BIOS-e820: 000000003f6fb000 - 000000003f700000 (ACPI NVS)
 BIOS-e820: 000000003f700000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000fec10000 - 00000000fec20000 (reserved)
 BIOS-e820: 00000000ffb00000 - 00000000ffc00000 (reserved)
 BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
1014MB LOWMEM available.
Entering add_active_range(0, 0, 259824) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   259824
early_node_map[1] active PFN ranges
    0:        0 ->   259824
On node 0 totalpages: 259824
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 1997 pages used for memmap
  Normal zone: 253731 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 FUJ                                   ) @ 0x000f5d80
ACPI: RSDT (v001 FUJ    FJNB189  0x01070000 FUJ  0x00000100) @ 0x3f6f4c92
ACPI: FADT (v001 FUJ    FJNB189  0x01070000 FUJ  0x00000100) @ 0x3f6faf8c
ACPI: SSDT (v001 FUJ    FJNB189  0x01070000 INTL 0x20030522) @ 0x3f6fab42
ACPI: BOOT (v001 FUJ    FJNB189  0x01070000 FUJ  0x00000100) @ 0x3f6faf64
ACPI: DSDT (v001 FUJ    FJNB189  0x01070000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0xfc08
Allocating PCI resources starting at 50000000 (gap: 40000000:bec10000)
Detected 1100.104 MHz processor.
Built 1 zonelists.  Total pages: 257795
Kernel command line: root=/dev/sda3 ro acpi_sleep=s3_bios
resume2=file:/dev/sda3:0x1f2df40
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=b0348000 soft=b0347000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1027448k/1039296k available (1660k kernel code, 11372k
reserved, 525k data, 120k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffff8000 - 0xfffff000   (  28 kB)
    vmalloc : 0xf0000000 - 0xffff6000   ( 255 MB)
    lowmem  : 0xb0000000 - 0xef6f0000   (1014 MB)
      .init : 0xb0324000 - 0xb0342000   ( 120 kB)
      .data : 0xb029f263 - 0xb0322a2c   ( 525 kB)
      .text : 0xb0100000 - 0xb029f263   (1660 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2200.79 BogoMIPS (lpj=1100399)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: a7e9f9bf 00000000 00000000 00000000
00000180 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 1024K
CPU: After all inits, caps: a7e9f9bf 00000000 00000000 00000040
00000180 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Pentium(R) M processor 1100MHz stepping 05
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
ACPI: setting ELCR to 0200 (from 0800)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd982, last bus=3
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using PIC 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 fc00-fc7f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region fc80-fcbf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Bus #03 (-#06) is hidden behind transparent bridge #01 (-#03)
(try 'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB_._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 8 devices
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bus 2, cardbus bridge: 0000:01:0a.0
  IO window: 00003400-000034ff
  IO window: 00003800-000038ff
  PREFETCH window: 50000000-51ffffff
  MEM window: 56000000-57ffffff
PCI: Bus 3, cardbus bridge: 0000:01:0a.1
  IO window: 00003c00-00003cff
  IO window: 00001000-000010ff
  PREFETCH window: 52000000-53ffffff
  MEM window: 58000000-59ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 3000-3fff
  MEM window: d0200000-d02fffff
  PREFETCH window: 50000000-53ffffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt 0000:01:0a.1[B] -> Link [LNKB] -> GSI 11 (level,
low) -> IRQ 11
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
Simple Boot Flag at 0x7f set to 0x1
SGI XFS with no debug enabled
io scheduler noop registered
io scheduler cfq registered (default)
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [CMB1] (battery present)
ACPI: Battery Slot [CMB2] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Lid Switch [LID]
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 855 Chipset.
agpgart: Detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xd8000000
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac6
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 11 (level,
low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
scsi0 : ata_piix
ata1.00: ATA-6, max UDMA/100, 156301488 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/100
scsi1 : ata_piix
ata2.00: ATAPI, max UDMA/33
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access     ATA      FUJITSU MHT2080A 0022 PQ: 0 ANSI: 5
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2 < sda5 > sda3
sd 0:0:0:0: Attached scsi disk sda
scsi 1:0:0:0: CD-ROM            MATSHITA UJDA755 DVD/CDRW 1.00 PQ: 0 ANSI: 5

As is actually detected, there's a hard drive on the first channel and
a DVD-ROM/CDRW on the second channel.

00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated
Graphics Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M)
USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface
Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
SMBus Controller (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
AC'97 Modem Controller (rev 03)
01:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
01:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
01:0a.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 03)
01:0a.3 System peripheral: Ricoh Co Ltd R5C576 SD Bus Host Adapter (rev 01)
01:0a.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter
01:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:0d.0 Ethernet controller: Atheros Communications, Inc. AR5212
802.11abg NIC (rev 01)

-- 
Kevin 'radsaq' Radloff
radsaq@gmail.com
http://thesaq.com/

Re: [0/3] 2.6.19-rc2: known regressions

[Linus Torvalds]

On Fri, 20 Oct 2006, Russell King wrote:
> 
> Since everyone seems intent at ignoring this issue, here's a patch to
> try to solve it.

Heh. I just merged another one (through Andrew), so it _should_ be fixed 
in my tree already. But thanks,

		Linus

Re: [0/3] 2.6.19-rc2: known regressions

[Russell King]

On Fri, Oct 20, 2006 at 11:19:00AM -0700, Andrew Morton wrote:
> On Fri, 20 Oct 2006 19:07:22 +0100
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> 
> > > > Subject    : undefined reference to highest_possible_node_id
> > > > References : http://lkml.org/lkml/2006/9/4/233
> > > >              http://lkml.org/lkml/2006/10/15/11
> > > > Submitter  : Olaf Hering <olaf@aepfle.de>
> > > > Caused-By  : Greg Banks <gnb@melbourne.sgi.com>
> > > >              commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> > > > Status     : unknown
> > > 
> > > Looking at this commit and the mails, it was known on the 4th September
> > > that this patch caused build errors while this change was in -mm, yet it
> > > still found its way into mainline on 2nd October.
> > > 
> > > Is anyone going to look at fixing this problem, or should we be asking
> > > for the commit to be reverted?
> > 
> > Since everyone seems intent at ignoring this issue, here's a patch to
> > try to solve it.
> 
> I sent the below to Linus yesterday...

Ah, okay.  Must not have poped out of the other side of Linus by 6am GMT
then.  (We also seem to have non-working git snapshots again, so when I
looked at the ARM kautobuild it showed the same old errors.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [0/3] 2.6.19-rc2: known regressions

[Linus Torvalds]

On Fri, 20 Oct 2006, Russell King wrote:
> 
> Ah, okay.  Must not have poped out of the other side of Linus by 6am GMT
> then. 

Yeah, I applied Andrew's patch-bomb just an hour or two ago.

> (We also seem to have non-working git snapshots again, so when I
> looked at the ARM kautobuild it showed the same old errors.)

Gaah. Remind me where the autobuild is again..

		Linus

Re: [0/3] 2.6.19-rc2: known regressions

[Russell King]

On Fri, Oct 20, 2006 at 11:50:53AM -0700, Linus Torvalds wrote:
> On Fri, 20 Oct 2006, Russell King wrote:
> > Ah, okay.  Must not have poped out of the other side of Linus by 6am GMT
> > then. 
> 
> Yeah, I applied Andrew's patch-bomb just an hour or two ago.

That explains why I hadn't seen it, and probably explains why there
hadn't been any git snapshots since Thursday morning (my time) - so
nothings actually broken.  Ignore me! 8)

> > (We also seem to have non-working git snapshots again, so when I
> > looked at the ARM kautobuild it showed the same old errors.)
> 
> Gaah. Remind me where the autobuild is again..

The main status page is at:
  http://armlinux.simtec.co.uk/kautobuild/

You could argue that it should be able to run off the git tree itself -
I'll probably even agree with you, but kautobuild isn't my system.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Linux 2.6.19-rc2

[Alan Cox]

Ar Gwe, 2006-10-20 am 14:30 -0400, ysgrifennodd Kevin Radloff:
> On 10/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > Ok, it's a week since -rc1, so -rc2 is out there.
> 
> A bit behind, but booting still takes ages on my laptop as
> libata/ata_piix tries to probe a device that isn't there (I reported
> this previously against -rc1, but got no response):

Probing is somewhat broken in 2.6.18 - something in the core code
changed as its upset quite a few drivers at once. One case causes
repeated errors and finally detection of an ATAPI device, the other
causes repeated errors and then failure when no device is present but
takes a few minutes and keeps IRQs locked off for long periods. Both
appear to be fallouts from the new EH code.

Alan

Re: [2.6.19 patch] drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...)

[Adrian Bunk]

On Thu, Oct 19, 2006 at 05:29:58PM +0100, Alan Cox wrote:
> Ar Iau, 2006-10-19 am 18:13 +0200, ysgrifennodd Adrian Bunk:
> > > Missing update to Documentation/kernel-parameters.txt ?
> > > (maybe it's been missing forever?)
> > 
> > It's been missing forever.
> > 
> > I'm not sure whether documenting it now where it's deprecated and nearly 
> > dead makes sense..
> 
> Its not dead, its so useful that drivers/ata also supports it

But in the drivers/ata case it's a module parameter, not a __setup 
kernel parameter.

And I don't think it makes sense to manually add module parameters to 
kernel-parameters.txt

If a documentation of all module parameters is considered useful, 
someone should write a script to automatically generate such a list.

cu
Adrian

-- 

       "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

Re: [0/3] 2.6.19-rc2: known regressions

[Linus Torvalds]

On Fri, 20 Oct 2006, Russell King wrote:
> > 
> > Gaah. Remind me where the autobuild is again..
> 
> The main status page is at:
>   http://armlinux.simtec.co.uk/kautobuild/

Ahh. At least _most_ builds seem ok. I only looked at the first failing 
one, and it _seems_ to be due to "drivers/usb/gadget/pxa2xx_udc.c" which 
still includes <asm/irq.h> rather than <linux/irq.h>.

Maybe. I could do the trivial fix myself, but there have been people who 
have ARM build environments, so maybe somebody who can actually verify 
whether that one-liner fixes things (or whether there is something else 
hiding) can do that and send me the patch.

[ Although I've gotten so much email lately that maybe I already missed 
  that patch. Ahh, the joys of SCM discussions ;) ]

			Linus

Re: Linux 2.6.19-rc2

[Jeff Garzik]

Alan Cox wrote:
> Ar Gwe, 2006-10-20 am 14:30 -0400, ysgrifennodd Kevin Radloff:
>> On 10/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
>>> Ok, it's a week since -rc1, so -rc2 is out there.
>> A bit behind, but booting still takes ages on my laptop as
>> libata/ata_piix tries to probe a device that isn't there (I reported
>> this previously against -rc1, but got no response):
> 
> Probing is somewhat broken in 2.6.18 - something in the core code
> changed as its upset quite a few drivers at once. One case causes
> repeated errors and finally detection of an ATAPI device, the other
> causes repeated errors and then failure when no device is present but
> takes a few minutes and keeps IRQs locked off for long periods. Both
> appear to be fallouts from the new EH code.

There are definitely warts related to the new EH stuff, but specifically 
for SATA + ata_piix, it has been a long hard road of trying various 
probing mechanisms.  Tejun has some patches that revert all the PCS work 
and rewinds back to original SATA ata_piix probing, in -mm for testing.

If testing feedback proves positive, let's go ahead and fast-track that 
up the line.

With ata_piix, I would worry more about PCS register follies than core 
libata.  Users can try the module option force_pcs=[0|1|2] to experiment 
and see if any of the three possibilities improves their boot.

	Jeff

Re: [2.6.19 patch] drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...)

[Randy Dunlap]

On Fri, 20 Oct 2006 23:05:33 +0200 Adrian Bunk wrote:

> On Thu, Oct 19, 2006 at 05:29:58PM +0100, Alan Cox wrote:
> > Ar Iau, 2006-10-19 am 18:13 +0200, ysgrifennodd Adrian Bunk:
> > > > Missing update to Documentation/kernel-parameters.txt ?
> > > > (maybe it's been missing forever?)
> > > 
> > > It's been missing forever.
> > > 
> > > I'm not sure whether documenting it now where it's deprecated and nearly 
> > > dead makes sense..
> > 
> > Its not dead, its so useful that drivers/ata also supports it
> 
> But in the drivers/ata case it's a module parameter, not a __setup 
> kernel parameter.

That's just an implementation nit/detail.  Users don't care which
way it's implemented, they just need to see some reasonable
documentation.

> And I don't think it makes sense to manually add module parameters to 
> kernel-parameters.txt

There are module parameters there already...
so we are being inconsistent.

> If a documentation of all module parameters is considered useful, 
> someone should write a script to automatically generate such a list.

I think that sounds great -- in theory.  Really, I do.
I even wrote a (simple) script for it last night.[1]
(but someone else is free to redo it, and probably not in
shell script :)

And maybe one "development community" answer is that this is
a distro problem, let them handle it.  (I don't like that answer,
but possibly the distros are OK with it.  I don't know.)

Ideally, users would be able to see/read documentation (like kernel
or module parameters) (a) without reading the source code and
(b) without building the module binary files.  Maybe that's too
much to ask of the development community, so the users can just
build all 1500 or so (and growing) loadable kernel modules
and run 'modinfo' on them to see what the possible module
parameters are.  Of course, if they need this information to be
able to install their (only) Linux system, then they are out of
luck, or they can use their other (or working) OS to search the
internet for such documenation.

Anyway, regarding your suggestion:  Yes, I think that it would be
good to generate such documentation instead of maintaining it
(and sometimes not doing that).  Maybe someone can & will make
that happen.

---
~Randy
[1] http://www.xenotime.net/linux/scripts/module-params

2.6.19-rc2: known unfixed regressions (v3)

[Adrian Bunk]

This email lists some known unfixed regressions in 2.6.19-rc2 compared 
to 2.6.18 that are not yet fixed 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    : ppc prep boot hang
References : http://lkml.org/lkml/2006/10/14/58
Submitter  : Meelis Roos <mroos@linux.ee>
Status     : unknown


Subject    : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter  : Martin Lorenz <martin@lorenz.eu.org>
Status     : unknown


Subject    : T60 stops triggering any ACPI events
References : http://lkml.org/lkml/2006/10/4/425
             http://lkml.org/lkml/2006/10/16/262
Submitter  : "Michael S. Tsirkin" <mst@mellanox.co.il>
Status     : unknown


Subject    : CONFIG_X86_VOYAGER=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter  : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By  : David Howells <dhowells@redhat.com>
             commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status     : unknown


Subject    : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter  : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By  : David Howells <dhowells@redhat.com>
             commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status     : unknown


Subject    : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter  : Thierry Vignaud <tvignaud@mandriva.com>
Status     : unknown


Subject    : SMP x86_64 boot problem
References : http://lkml.org/lkml/2006/9/28/330
             http://lkml.org/lkml/2006/10/5/289
Submitter  : art@usfltd.com
Status     : submitter was asked to git bisect
             result of bisecting seems to be wrong


Subject    : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter  : Alex Romosan <romosan@sycorax.lbl.gov>
Status     : unknown


Subject    : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter  : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
Status     : Mark is investigating


Subject    : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/16/291
Submitter  : Stephen Hemminger <shemminger@osdl.org>
Handled-By : Greg KH <greg@kroah.com>
Status     : Greg is working on a fix


Subject    : snd-hda-intel <-> forcedeth MSI problem
References : http://lkml.org/lkml/2006/10/5/40
             http://lkml.org/lkml/2006/10/7/164
Submitter  : Prakash Punnoor <prakash@punnoor.de>
Status     : patches are being discussed

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Andi Kleen]

On Sunday 22 October 2006 14:23, Adrian Bunk wrote:

> Subject    : SMP x86_64 boot problem
> References : http://lkml.org/lkml/2006/9/28/330
>              http://lkml.org/lkml/2006/10/5/289
> Submitter  : art@usfltd.com
> Status     : submitter was asked to git bisect
>              result of bisecting seems to be wrong

Does this still happen with 2.6.19rc2-latestGIT ?

-Andi

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Gene Heskett]

On Sunday 22 October 2006 08:23, Adrian Bunk wrote:
>This email lists some known unfixed regressions in 2.6.19-rc2 compared
>to 2.6.18 that are not yet fixed Linus' tree.
>
[...]
>
>Subject    : unable to rip cd
>References : http://lkml.org/lkml/2006/10/13/100
>Submitter  : Alex Romosan <romosan@sycorax.lbl.gov>
>Status     : unknown

FWIW Alex, I just ripped track 2 of a Trace Adkins CD using grip and 
cdparanoia, then listened to the track in mplayer, while running 
2.6.19-rc2.  No problem at all.  This is however, an older FC2 system, so 
I'd be inclined to point the finger at cdparanoia's latest version.  Mine 
hasn't been updated for quite a while.  I have these installed:

cdparanoia-alpha9.8-20.1
cdparanoia-libs-alpha9.8-20.1
cdparanoia-devel-alpha9.8-20.1

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Alex Romosan]

Gene Heskett <gene.heskett@verizon.net> writes:

> On Sunday 22 October 2006 08:23, Adrian Bunk wrote:
>>This email lists some known unfixed regressions in 2.6.19-rc2 compared
>>to 2.6.18 that are not yet fixed Linus' tree.
>>
> [...]
>>
>>Subject    : unable to rip cd
>>References : http://lkml.org/lkml/2006/10/13/100
>>Submitter  : Alex Romosan <romosan@sycorax.lbl.gov>
>>Status     : unknown
>
> FWIW Alex, I just ripped track 2 of a Trace Adkins CD using grip and 
> cdparanoia, then listened to the track in mplayer, while running 
> 2.6.19-rc2.  No problem at all.  This is however, an older FC2 system, so 
> I'd be inclined to point the finger at cdparanoia's latest version.  Mine 
> hasn't been updated for quite a while.  I have these installed:
>
> cdparanoia-alpha9.8-20.1
> cdparanoia-libs-alpha9.8-20.1
> cdparanoia-devel-alpha9.8-20.1

the system doesn't lock up all the time, but every time i start ripping
i get this in syslog:

Oct 22 08:08:16 trinculo kernel: hdc: write_intr: wrong transfer direction!

which didn't use to happen before 2.6.19-rc2 (the lockups did).
anyway, i just gave it another try, grip wasn't able to rip the cd but
i was able to eject the cd from the drive and then abort execution. i
am using cdparanoia that came with grip, and this is a very old
version (2.96, the last before they switched to gnome). i also tried
with the recent version of cdparanoia but the same thing happens.

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Gene Heskett]

On Sunday 22 October 2006 11:17, Alex Romosan wrote:
>Gene Heskett <gene.heskett@verizon.net> writes:
>> On Sunday 22 October 2006 08:23, Adrian Bunk wrote:
>>>This email lists some known unfixed regressions in 2.6.19-rc2 compared
>>>to 2.6.18 that are not yet fixed Linus' tree.
>>
>> [...]
>>
>>>Subject    : unable to rip cd
>>>References : http://lkml.org/lkml/2006/10/13/100
>>>Submitter  : Alex Romosan <romosan@sycorax.lbl.gov>
>>>Status     : unknown
>>
>> FWIW Alex, I just ripped track 2 of a Trace Adkins CD using grip and
>> cdparanoia, then listened to the track in mplayer, while running
>> 2.6.19-rc2.  No problem at all.  This is however, an older FC2 system,
>> so I'd be inclined to point the finger at cdparanoia's latest version. 
>> Mine hasn't been updated for quite a while.  I have these installed:
>>
>> cdparanoia-alpha9.8-20.1
>> cdparanoia-libs-alpha9.8-20.1
>> cdparanoia-devel-alpha9.8-20.1
>
>the system doesn't lock up all the time, but every time i start ripping
>i get this in syslog:
>
>Oct 22 08:08:16 trinculo kernel: hdc: write_intr: wrong transfer
> direction!
>
>which didn't use to happen before 2.6.19-rc2 (the lockups did).
>anyway, i just gave it another try, grip wasn't able to rip the cd but
>i was able to eject the cd from the drive and then abort execution. i
>am using cdparanoia that came with grip, and this is a very old
>version (2.96, the last before they switched to gnome). i also tried
>with the recent version of cdparanoia but the same thing happens.
>
My grip is a bit newer than that, 3.20 I believe.

>--alex--

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Andrey Panin]

[-- Attachment #1.1: Type: text/plain, Size: 996 bytes --]

On 295, 10 22, 2006 at 02:23:55PM +0200, Adrian Bunk wrote:
> This email lists some known unfixed regressions in 2.6.19-rc2 compared 
> to 2.6.18 that are not yet fixed 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    : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
> References : http://lkml.org/lkml/2006/10/7/51
> Submitter  : Jesper Juhl <jesper.juhl@gmail.com>
> Caused-By  : David Howells <dhowells@redhat.com>
>              commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
> Status     : unknown

Attached patch fixes this problem.

-- 
Andrey Panin		| Linux and UNIX system administrator
pazke@donpac.ru		| PGP key: wwwkeys.pgp.net

[-- Attachment #1.2: patch-fix-visws --]
[-- Type: text/plain, Size: 3962 bytes --]


Signed-off-by: Andrey Panin <pazke@donpac.ru>

 arch/i386/mach-visws/visws_apic.c       |    7 +---
 include/asm-i386/mach-visws/do_timer.h  |   53 --------------------------------
 include/asm-i386/mach-visws/mach_apic.h |    5 +++
 3 files changed, 8 insertions(+), 57 deletions(-)

diff -urdpNX /usr/share/dontdiff linux-2.6.19-rc2.vanilla/arch/i386/mach-visws/visws_apic.c linux-2.6.19-rc2/arch/i386/mach-visws/visws_apic.c
--- linux-2.6.19-rc2.vanilla/arch/i386/mach-visws/visws_apic.c	2006-10-22 14:32:13.000000000 +0400
+++ linux-2.6.19-rc2/arch/i386/mach-visws/visws_apic.c	2006-10-22 14:37:30.000000000 +0400
@@ -122,7 +122,7 @@ static void end_cobalt_irq(unsigned int 
 	spin_unlock_irqrestore(&cobalt_lock, flags);
 }
 
-static struct hw_interrupt_type cobalt_irq_type = {
+static struct irq_chip cobalt_irq_type = {
 	.typename =	"Cobalt-APIC",
 	.startup =	startup_cobalt_irq,
 	.shutdown =	disable_cobalt_irq,
@@ -159,7 +159,7 @@ static void end_piix4_master_irq(unsigne
 	spin_unlock_irqrestore(&cobalt_lock, flags);
 }
 
-static struct hw_interrupt_type piix4_master_irq_type = {
+static struct irq_chip piix4_master_irq_type = {
 	.typename =	"PIIX4-master",
 	.startup =	startup_piix4_master_irq,
 	.ack =		ack_cobalt_irq,
@@ -167,9 +167,8 @@ static struct hw_interrupt_type piix4_ma
 };
 
 
-static struct hw_interrupt_type piix4_virtual_irq_type = {
+static struct irq_chip piix4_virtual_irq_type = {
 	.typename =	"PIIX4-virtual",
-	.startup =	startup_8259A_irq,
 	.shutdown =	disable_8259A_irq,
 	.enable =	enable_8259A_irq,
 	.disable =	disable_8259A_irq,
diff -urdpNX /usr/share/dontdiff linux-2.6.19-rc2.vanilla/include/asm-i386/mach-visws/do_timer.h linux-2.6.19-rc2/include/asm-i386/mach-visws/do_timer.h
--- linux-2.6.19-rc2.vanilla/include/asm-i386/mach-visws/do_timer.h	2006-10-22 14:33:24.000000000 +0400
+++ linux-2.6.19-rc2/include/asm-i386/mach-visws/do_timer.h	1970-01-01 03:00:00.000000000 +0300
@@ -1,53 +0,0 @@
-/* defines for inline arch setup functions */
-
-#include <asm/fixmap.h>
-#include <asm/i8259.h>
-#include "cobalt.h"
-
-static inline void do_timer_interrupt_hook(void)
-{
-	/* Clear the interrupt */
-	co_cpu_write(CO_CPU_STAT,co_cpu_read(CO_CPU_STAT) & ~CO_STAT_TIMEINTR);
-
-	do_timer(1);
-#ifndef CONFIG_SMP
-	update_process_times(user_mode_vm(irq_regs));
-#endif
-/*
- * In the SMP case we use the local APIC timer interrupt to do the
- * profiling, except when we simulate SMP mode on a uniprocessor
- * system, in that case we have to call the local interrupt handler.
- */
-#ifndef CONFIG_X86_LOCAL_APIC
-	profile_tick(CPU_PROFILING);
-#else
-	if (!using_apic_timer)
-		smp_local_timer_interrupt();
-#endif
-}
-
-static inline int do_timer_overflow(int count)
-{
-	int i;
-
-	spin_lock(&i8259A_lock);
-	/*
-	 * This is tricky when I/O APICs are used;
-	 * see do_timer_interrupt().
-	 */
-	i = inb(0x20);
-	spin_unlock(&i8259A_lock);
-	
-	/* assumption about timer being IRQ0 */
-	if (i & 0x01) {
-		/*
-		 * We cannot detect lost timer interrupts ... 
-		 * well, that's why we call them lost, don't we? :)
-		 * [hmm, on the Pentium and Alpha we can ... sort of]
-		 */
-		count -= LATCH;
-	} else {
-		printk("do_slow_gettimeoffset(): hardware timer problem?\n");
-	}
-	return count;
-}
diff -urdpNX /usr/share/dontdiff linux-2.6.19-rc2.vanilla/include/asm-i386/mach-visws/mach_apic.h linux-2.6.19-rc2/include/asm-i386/mach-visws/mach_apic.h
--- linux-2.6.19-rc2.vanilla/include/asm-i386/mach-visws/mach_apic.h	2006-01-03 06:21:10.000000000 +0300
+++ linux-2.6.19-rc2/include/asm-i386/mach-visws/mach_apic.h	2006-10-22 14:16:53.000000000 +0400
@@ -51,6 +51,11 @@ static inline void clustered_apic_check(
 {
 }
 
+static inline int apicid_to_node(int logical_apicid)
+{
+	return 0;
+}
+
 /* Mapping from cpu number to logical apicid */
 static inline int cpu_to_logical_apicid(int cpu)
 {

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

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Meelis Roos]

> Subject    : ppc prep boot hang
> References : http://lkml.org/lkml/2006/10/14/58
> Submitter  : Meelis Roos <mroos@linux.ee>
> Status     : unknown

Seems to be fixed in 2.6.19-rc2+git as of 20061022.

-- 
Meelis Roos

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Adrian Bunk]

On Mon, Oct 23, 2006 at 06:20:18PM +0300, Meelis Roos wrote:
> >Subject    : ppc prep boot hang
> >References : http://lkml.org/lkml/2006/10/14/58
> >Submitter  : Meelis Roos <mroos@linux.ee>
> >Status     : unknown
> 
> Seems to be fixed in 2.6.19-rc2+git as of 20061022.

Thanks for the information, I've removed it from my list.

> Meelis Roos

cu
Adrian

-- 

       "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

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Stefan Richter]

Hi Adrian,

here is another one:

Subject    : [ohci1394 on PPC_PMAC] pci_set_power_state() failure and breaking suspend
References : http://lkml.org/lkml/2006/10/24/13
Submitter  : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Caused-By  : Stefan Richter <stefanr@s5r6.in-berlin.de>
             commit ea6104c22468239083857fa07425c312b1ecb424
Status     : looking for answer when to ignore return code of pci_set_power_state

-- 
Stefan Richter
-=====-=-==- =-=- ==---
http://arcgraph.de/sr/

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Michael S. Tsirkin]

Quoting r. Adrian Bunk <bunk@stusta.de>:
> Subject: 2.6.19-rc2: known unfixed regressions (v3)
> 
> This email lists some known unfixed regressions in 2.6.19-rc2 compared 
> to 2.6.18 that are not yet fixed 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.
>

skip, hope I didn't trim too much.

>
> Subject    : T60 stops triggering any ACPI events
> References : http://lkml.org/lkml/2006/10/4/425
>              http://lkml.org/lkml/2006/10/16/262
> Submitter  : "Michael S. Tsirkin" <mst@mellanox.co.il>
> Status     : unknown

Just retested with 2.6.19-rc3 - it's still there:
e.g. after I do a full kernel compile, my T60 stops triggering any ACPI events:
tail -f /var/log/acpid does not show anything, even on Fn/F4 which is supposed
to be always enabled.  Restarting the acpid doesn't do anything either - ACPI
starts working again, for a while, only after reboot.

Works fine in 2.6.18 ( + this patch http://lkml.org/lkml/2006/7/20/56).

-- 
MST

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Prakash Punnoor]

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

Am Sonntag 22 Oktober 2006 14:23 schrieben Sie:
> Subject    : snd-hda-intel <-> forcedeth MSI problem
> References : http://lkml.org/lkml/2006/10/5/40
>              http://lkml.org/lkml/2006/10/7/164
> Submitter  : Prakash Punnoor <prakash@punnoor.de>
> Status     : patches are being discussed

2.6.19-rc3 contains a work-around. Case closed. :-)
-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

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

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Adrian Bunk]

On Tue, Oct 24, 2006 at 04:57:43PM +0200, Stefan Richter wrote:
> Hi Adrian,
> 
> here is another one:
> 
> Subject    : [ohci1394 on PPC_PMAC] pci_set_power_state() failure and breaking suspend
> References : http://lkml.org/lkml/2006/10/24/13
> Submitter  : Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Caused-By  : Stefan Richter <stefanr@s5r6.in-berlin.de>
>              commit ea6104c22468239083857fa07425c312b1ecb424
> Status     : looking for answer when to ignore return code of pci_set_power_state

Thanks, added.

> Stefan Richter

cu
Adrian

-- 

       "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

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Adrian Bunk]

On Tue, Oct 24, 2006 at 07:27:48PM +0200, Prakash Punnoor wrote:
> Am Sonntag 22 Oktober 2006 14:23 schrieben Sie:
> > Subject    : snd-hda-intel <-> forcedeth MSI problem
> > References : http://lkml.org/lkml/2006/10/5/40
> >              http://lkml.org/lkml/2006/10/7/164
> > Submitter  : Prakash Punnoor <prakash@punnoor.de>
> > Status     : patches are being discussed
> 
> 2.6.19-rc3 contains a work-around. Case closed. :-)

Thanks for the confirmation.

cu
Adrian

-- 

       "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

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Pavel Machek]

On Tue 2006-10-24 17:00:51, Michael S. Tsirkin wrote:
> Quoting r. Adrian Bunk <bunk@stusta.de>:
> > Subject: 2.6.19-rc2: known unfixed regressions (v3)
> > 
> > This email lists some known unfixed regressions in 2.6.19-rc2 compared 
> > to 2.6.18 that are not yet fixed 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.
> >
> 
> skip, hope I didn't trim too much.
> 
> >
> > Subject    : T60 stops triggering any ACPI events
> > References : http://lkml.org/lkml/2006/10/4/425
> >              http://lkml.org/lkml/2006/10/16/262
> > Submitter  : "Michael S. Tsirkin" <mst@mellanox.co.il>
> > Status     : unknown
> 
> Just retested with 2.6.19-rc3 - it's still there:
> e.g. after I do a full kernel compile, my T60 stops triggering any ACPI events:
> tail -f /var/log/acpid does not show anything, even on Fn/F4 which is supposed
> to be always enabled.  Restarting the acpid doesn't do anything either - ACPI
> starts working again, for a while, only after reboot.
> 
> Works fine in 2.6.18 ( + this patch http://lkml.org/lkml/2006/7/20/56).

Bugzilla.kernel.org, assign it to acpi people...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.19-rc2: known unfixed regressions (v3)

[Michael S. Tsirkin]

Quoting r. Pavel Machek <pavel@suse.cz>:
> > >
> > > Subject    : T60 stops triggering any ACPI events
> > > References : http://lkml.org/lkml/2006/10/4/425
> > >              http://lkml.org/lkml/2006/10/16/262
> > > Submitter  : "Michael S. Tsirkin" <mst@mellanox.co.il>
> > > Status     : unknown
> > 
> > Just retested with 2.6.19-rc3 - it's still there:
> > e.g. after I do a full kernel compile, my T60 stops triggering any ACPI events:
> > tail -f /var/log/acpid does not show anything, even on Fn/F4 which is supposed
> > to be always enabled.  Restarting the acpid doesn't do anything either - ACPI
> > starts working again, for a while, only after reboot.
> > 
> > Works fine in 2.6.18 ( + this patch http://lkml.org/lkml/2006/7/20/56).
> 
> Bugzilla.kernel.org, assign it to acpi people...

Already done, http://bugzilla.kernel.org/show_bug.cgi?id=7408

-- 
MST

Re: [0/3] 2.6.19-rc2: known regressions

[Guennadi Liakhovetski]

Hi

I did search the archives, but it does seem to be the new one. r8169 
network driver introduced in 2.6.19-rcX a set_mac_address function, which 
doesn't work for me. It should resolve the bugreport 
http://bugzilla.kernel.org/show_bug.cgi?id=6032 but, as you see from the 
last comment from the original reporter and from my following comment, it 
doesn't seem to. I think, it should either be fixed or reverted. My 
test-system, was a ppc NAS (KuroboxHG):

0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (8000ns min, 16000ns max), Cache Line Size: 0x08 (32 bytes)        Interrupt: pin A routed to IRQ 16
        Region 0: I/O ports at bfff00 [size=256]
        Region 1: Memory at bfffff00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [dc] Power Management version 0
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: [0/3] 2.6.19-rc2: known regressions

[Linus Torvalds]

On Sun, 29 Oct 2006, Guennadi Liakhovetski wrote:
> 
> I did search the archives, but it does seem to be the new one. r8169 
> network driver introduced in 2.6.19-rcX a set_mac_address function, which 
> doesn't work for me. It should resolve the bugreport 
> http://bugzilla.kernel.org/show_bug.cgi?id=6032 but, as you see from the 
> last comment from the original reporter and from my following comment, it 
> doesn't seem to. I think, it should either be fixed or reverted. My 
> test-system, was a ppc NAS (KuroboxHG):

Can you please test the things that Francois asks you to test in the last 
comment?

That said, it does appear that the patch breaks things for some people, 
and the upsides seem very limited - only relevant when somebody tries to 
change the MAC address, which is not a very normal thing to do anyway.

So maybe reverting it is the right thing to do. Guennadi, can you confirm 
that it is commit a2b98a69 ("r8169: mac address change support") that 
breaks it, and that reverting just that one commit fixes things for you?

But please check the things that are suggested in the bugzilla entry 
first.

Francois? Jeff?

		Linus

r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Francois Romieu]

Linus Torvalds <torvalds@osdl.org> :
[regression related to r8169 MAC address change]
> Francois ? Jeff ?

Go revert it.

Despite what I claimed, I can not find a third-party confirmation by email
that it works elsewhere.

It would probably be enough to remove the call to __rtl8169_set_mac_addr()
in rtl8169_hw_start() though.

In place of the test suggested in bugzilla, I'd rather see Guennadi test
the thing below (acked on netdev by the initial victim if someone wonders
why it has not changed the status of bugzilla so far):

>From f092d907f78e81846dfaf1008a6409c3c4b58f27 Mon Sep 17 00:00:00 2001
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Sat, 21 Oct 2006 21:07:36 +0200
Subject: [PATCH] r8169: perform a PHY reset before any other operation at boot time

Realtek's 8139/810x (0x8136) PCI-E comes with a touchy PHY.
A big heavy reset seems to calm it down.

Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7378.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
---
 drivers/net/r8169.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index f1c7575..927fc17 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1440,6 +1440,22 @@ static void rtl8169_release_board(struct
 	free_netdev(dev);
 }
 
+static void rtl8169_phy_reset(struct net_device *dev,
+			      struct rtl8169_private *tp)
+{
+	void __iomem *ioaddr = tp->mmio_addr;
+	int i;
+
+	tp->phy_reset_enable(ioaddr);
+	for (i = 0; i < 100; i++) {
+		if (!tp->phy_reset_pending(ioaddr))
+			return;
+		msleep(1);
+	}
+	if (netif_msg_link(tp))
+		printk(KERN_ERR "%s: PHY reset failed.\n", dev->name);
+}
+
 static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
 {
 	void __iomem *ioaddr = tp->mmio_addr;
@@ -1468,6 +1484,8 @@ static void rtl8169_init_phy(struct net_
 
 	rtl8169_link_option(board_idx, &autoneg, &speed, &duplex);
 
+	rtl8169_phy_reset(dev, tp);
+
 	rtl8169_set_speed(dev, autoneg, speed, duplex);
 
 	if ((RTL_R8(PHYstatus) & TBI_Enable) && netif_msg_link(tp))
-- 
1.4.2.4

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Guennadi Liakhovetski]

On Sun, 29 Oct 2006, Francois Romieu wrote:

> Linus Torvalds <torvalds@osdl.org> :
> [regression related to r8169 MAC address change]
> > Francois ? Jeff ?
> 
> Go revert it.
> 
> Despite what I claimed, I can not find a third-party confirmation by email
> that it works elsewhere.
> 
> It would probably be enough to remove the call to __rtl8169_set_mac_addr()
> in rtl8169_hw_start() though.
> 
> In place of the test suggested in bugzilla, I'd rather see Guennadi test
> the thing below (acked on netdev by the initial victim if someone wonders
> why it has not changed the status of bugzilla so far):

AFAIU, you wanted it applied on the top of the "non-working" kernel 
(2.6.19-rc2-ish)? No, it didn't work. And, worse yet, I think, it is after 
testing that patch that the interface got into a state, when netconsole 
worked, ping worked, but ssh didn't. A poweroff was needed to recover. In 
case you still need it, here's the info you requested:

00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: I/O ports at febfff00 [size=256]
        Region 1: Memory at bffffc00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [dc] Power Management version 0
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: ec 10 69 81 17 00 b0 02 10 00 00 02 08 80 00 00
10: 01 ff bf 00 00 fc ff bf 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 dc 00 00 00 00 00 00 00 10 01 20 40

dmesg when it didn't work (I do use netconsole, don't think it matters?):

r8169 Gigabit Ethernet driver 2.2LK loaded
eth0: RTL8169s/8110s at 0xc9004c00, 00:0d:0b:99:44:70, IRQ 16
netconsole: device eth0 not up yet, forcing it
r8169: eth0: link down
r8169: eth0: link up

The same when it's working.

Yes, just commenting out the line

	__rtl8169_set_mac_addr(dev, ioaddr);

fixes it (without the patch from your previous email).

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Francois Romieu]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
[...]
> AFAIU, you wanted it applied on the top of the "non-working" kernel 
> (2.6.19-rc2-ish)?

No. Please apply it on top of a 2.6.19-rc3 where the mac address change
feature has been reverted (or where __rtl8169_set_mac_addr has been
commented out at your option). 

[...]
> dmesg when it didn't work (I do use netconsole, don't think it matters?):

I'd rather fix everything else without netconsole first. It will make
my life simpler.

-- 
Ueimor

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Oleg Verych]

On 2006-10-29, Francois Romieu wrote:
>
> Linus Torvalds <torvalds@osdl.org> :
> [regression related to r8169 MAC address change]
>> Francois ? Jeff ?
>
> Go revert it.
>
> Despite what I claimed, I can not find a third-party confirmation by email
> that it works elsewhere.

It works for me:
,--
|root@flower:/home/olecom# ip l set eth0 addr 00:00:00:00:00:02
|root@flower:/home/olecom# ip l set eth0 addr 00:00:00:00:00:03
|root@flower:/home/olecom# ip l set eth0 addr 00:00:00:00:00:04
|root@flower:/home/olecom# ip l set eth0 addr 04:44:44:44:44:04
|root@flower:/home/olecom# ip l show
|1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
|    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|    2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
|    link/ether 04:44:44:44:44:04 brd ff:ff:ff:ff:ff:ff
|root@flower:/home/olecom# lspci -v | grep Realtek
|    02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
|RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
|root@flower:/home/olecom#
|root@flower:/home/olecom# uname -a
|Linux flower 2.6.19-rc2-vanilla-ai #4 SMP PREEMPT Tue Oct 17 02:19:16
|UTC 2006 x86_64 GNU/Linux
|root@flower:/home/olecom#
`--
____

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Guennadi Liakhovetski]

On Mon, 30 Oct 2006, Francois Romieu wrote:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
> [...]
> > AFAIU, you wanted it applied on the top of the "non-working" kernel 
> > (2.6.19-rc2-ish)?
> 
> No. Please apply it on top of a 2.6.19-rc3 where the mac address change
> feature has been reverted (or where __rtl8169_set_mac_addr has been
> commented out at your option). 

Ok, with just __rtl8169_set_mac_addr disabled it works. With netconsole 
disabled, and your phy_reset patch applied it seems to still work. The 
printk

+		printk(KERN_ERR "%s: PHY reset failed.\n", dev->name);

doesn't get printed. If I uncomment __rtl8169_set_mac_addr it stops 
working again. What does it tell us about the original set_mac_address 
problem?

I haven't said it's an on-board chip, not a plug-in card. Don't know how 
setting the mac address worked in your configuration, but if it is storred 
in a prom, maybe it is just missing on my board?

The kernel is not 2.6.19-rc3 either. It is a clone of the powerpc git some 
time shortly after 2.6.19-rc2.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Guennadi Liakhovetski]

On Mon, 30 Oct 2006, Guennadi Liakhovetski wrote:

> Ok, with just __rtl8169_set_mac_addr disabled it works. With netconsole 
> disabled, and your phy_reset patch applied it seems to still work. The 

The "seems" above was the key word. Once again I had a case, when after 
re-compiling the kernel again with the disabled call to 
__rtl8169_set_mac_addr only ping worked. And a power-off was required to 
recover. So, that phy_reset doesn't seem to be very safe either.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Francois Romieu]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
[...]
> doesn't get printed. If I uncomment __rtl8169_set_mac_addr it stops 
> working again. What does it tell us about the original set_mac_address 
> problem?

Probably that it is issued too early/bluntly. I'll redo it later.

[...]
> The kernel is not 2.6.19-rc3 either. It is a clone of the powerpc git some 
> time shortly after 2.6.19-rc2.

You miss 73f5e28b336772c4b08ee82e5bf28ab872898ee1 and
733b736c91dd2c556f35dffdcf77e667cf10cefc. It should not matter.

-- 
Ueimor

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Francois Romieu]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
[...]
> The "seems" above was the key word. Once again I had a case, when after 
> re-compiling the kernel again with the disabled call to 
> __rtl8169_set_mac_addr only ping worked. And a power-off was required to 
> recover. So, that phy_reset doesn't seem to be very safe either.

Can you replace phy_reset by the patch below and try it twice ?

It's interesting to know if it does not always behave the same.

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index f1c7575..4b05dea 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -570,8 +570,8 @@ static void rtl8169_xmii_reset_enable(vo
 {
 	unsigned int val;
 
-	val = (mdio_read(ioaddr, MII_BMCR) | BMCR_RESET) & 0xffff;
-	mdio_write(ioaddr, MII_BMCR, val);
+	mdio_write(ioaddr, MII_BMCR, BMCR_RESET);
+	val = mdio_read(ioaddr, MII_BMCR);
 }
 
 static void rtl8169_check_link_status(struct net_device *dev,
@@ -1440,6 +1440,22 @@ static void rtl8169_release_board(struct
 	free_netdev(dev);
 }
 
+static void rtl8169_phy_reset(struct net_device *dev,
+			      struct rtl8169_private *tp)
+{
+	void __iomem *ioaddr = tp->mmio_addr;
+	int i;
+
+	tp->phy_reset_enable(ioaddr);
+	for (i = 0; i < 100; i++) {
+		if (!tp->phy_reset_pending(ioaddr))
+			return;
+		msleep(1);
+	}
+	if (netif_msg_link(tp))
+		printk(KERN_ERR "%s: PHY reset failed.\n", dev->name);
+}
+
 static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
 {
 	void __iomem *ioaddr = tp->mmio_addr;
@@ -1468,6 +1484,8 @@ static void rtl8169_init_phy(struct net_
 
 	rtl8169_link_option(board_idx, &autoneg, &speed, &duplex);
 
+	rtl8169_phy_reset(dev, tp);
+
 	rtl8169_set_speed(dev, autoneg, speed, duplex);
 
 	if ((RTL_R8(PHYstatus) & TBI_Enable) && netif_msg_link(tp))

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Guennadi Liakhovetski]

On Tue, 31 Oct 2006, Francois Romieu wrote:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
> [...]
> > The "seems" above was the key word. Once again I had a case, when after 
> > re-compiling the kernel again with the disabled call to 
> > __rtl8169_set_mac_addr only ping worked. And a power-off was required to 
> > recover. So, that phy_reset doesn't seem to be very safe either.
> 
> Can you replace phy_reset by the patch below and try it twice ?
> 
> It's interesting to know if it does not always behave the same.

Well, with that one I booted 3 times, all 3 times it worked. I'll leave it 
in to see if it ever fails. So, what does it tell us about the 
set_mac_address thing?

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Francois Romieu]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
[...]
> Well, with that one I booted 3 times, all 3 times it worked. I'll leave it 

Thanks.

Let's cross fingers.

> in to see if it ever fails. So, what does it tell us about the 
> set_mac_address thing?

It tells nothing more about the set_mac_address thing. If people need 
MAC address change support, I can surely hack something and keep a
patch for future reference. Imho it is anything but 2.6.19 material
though.

The patch that I sent to you on 2006/10/29 was enough to fix the link
detection issues experienced with the 0x8136 chipset (1. Darren Salt
on netdev {25/26/31}/08/2006 and {21/22}/10/2006, 2. Syed Azam on BZ,
see http://bugzilla.kernel.org/show_bug.cgi?id=7378).

Your computer was good at spotting issues with the MAC address stuff,
so it was the perfect candidate to test pending fixes for different
problems. As you noticed, it was not exactly safe to feed the MII
control register with some potentially uninitialized stuff, whence
the patch from yesterday.

It remains to be seen if:
- it still does the job for the 0x8136 
- it does not induce new regressions in existing 8169

o Darren and Syed, are your 0x8136 still happy with the patch
  0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.txt
  at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169
  on top of 2.6.19-rc4 ?

o Darren, still ok to keep your S-o-b in it ?

o Could the r8169 users out there check that the same patch does not add
  new regressions to their favorite 2.6.19-rc4 ?

o Lennert, can you apply the two patches
  - 0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.txt
  - 0002-r8169-more-magic.txt
  at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169 against
  2.6.19-rc4 (2.6.19-rc4 reverted the MAC address changes) and see if the
  n2100 board still needs to remove the SYSErr handler ?

-- 
Ueimor

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Guennadi Liakhovetski]

On Wed, 1 Nov 2006, Francois Romieu wrote:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
> 
> > in to see if it ever fails. So, what does it tell us about the 
> > set_mac_address thing?
> 
> It tells nothing more about the set_mac_address thing. If people need 
> MAC address change support, I can surely hack something and keep a
> patch for future reference. Imho it is anything but 2.6.19 material
> though.

Aha, ok, thanks. Just noticed that the set_mac_address has been reverted 
in -rc4, so, that's resolved. Good.

> Your computer was good at spotting issues with the MAC address stuff,
> so it was the perfect candidate to test pending fixes for different
> problems. As you noticed, it was not exactly safe to feed the MII
> control register with some potentially uninitialized stuff, whence
> the patch from yesterday.

Glad it was useful. I have to warn you though, that that "computer" is not 
very actively used ATM and doesn't stay on for too long. However, if you 
can suggest a way to stress test that phy reset thingie, I could run some 
overnight test.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Lennert Buytenhek]

On Wed, Nov 01, 2006 at 12:05:38AM +0100, Francois Romieu wrote:

> o Lennert, can you apply the two patches
>   - 0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.txt
>   - 0002-r8169-more-magic.txt
>   at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169 against
>   2.6.19-rc4 (2.6.19-rc4 reverted the MAC address changes) and see if the
>   n2100 board still needs to remove the SYSErr handler ?

2.6.19-rc4 + these two patches => doesn't work

2.6.19-rc4 + these two patches + SYSErr removal => works

For reference:
* 2.6.19-rc4 + SYSErr removal => works

So, while these two patches don't fix the problem, they don't seem
to be making things worse, something the MAC address change did do.


cheers,
Lennert

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Darren Salt]

This message is in MIME format which your mailer apparently does not support.
You either require a newer version of your software which supports MIME, or
a separate MIME decoding utility.  Alternatively, ask the sender of this
message to resend it in a different format.

--163681386--1739281754--1718250983
Content-Type: text/plain; charset=us-ascii

I demand that Francois Romieu may or may not have written...

[snip]
> o Darren and Syed, are your 0x8136 still happy with the patch
>   0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.txt
>   at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169
>   on top of 2.6.19-rc4 ?

It is.

I then tried 0002-r8169-more-magic.txt, mainly to see that it doesn't cause
any problems. Unfortunately, it did... however, a little reading showed that
you've stopped enabling transmit and receive for all but four of the chip
types supported by the driver.

An incremental fix is attached.

> o Darren, still ok to keep your S-o-b in it ?

Yes.

[snip]
-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy less and make it last longer.         INDUSTRY CAUSES GLOBAL WARMING.

Never have a drink when you are feeling sorry for yourself.

--163681386--1739281754--1718250983
Content-Type: text/plain; charset=iso-8859-1; name="0003-r8169-fix-more-magic.patch"
Content-Disposition: attachment; filename="0003-r8169-fix-more-magic.patch"

r8169: fix more magic so that 8101e etc. work again

r8169-more-magic killed transmit & receive on my laptop's RTL8101e. Turns out
to be that the enabling of these functions had been unitnentionally removed.

(This is one of two possible fixes, the other being the removal of the if()
guarding the other tx/rx-enable call. Both work here.)

Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>

--- drivers/net/r8169.c~	2006-11-01 19:53:02.000000000 +0000
+++ drivers/net/r8169.c	2006-11-01 19:54:16.000000000 +0000
@@ -1921,7 +1921,10 @@
 	    (tp->mac_version != RTL_GIGA_MAC_VER_02) &&
 	    (tp->mac_version != RTL_GIGA_MAC_VER_03) &&
 	    (tp->mac_version != RTL_GIGA_MAC_VER_04))
+	{
 		rtl8169_set_rx_tx_config_registers(tp);
+		RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+	}
 
 	RTL_W8(Cfg9346, Cfg9346_Lock);
 

--163681386--1739281754--1718250983--

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Francois Romieu]

Darren Salt <linux@youmustbejoking.demon.co.uk> :
[...]
> (This is one of two possible fixes, the other being the removal of the if()
> guarding the other tx/rx-enable call. Both work here.)

I'll update the patch with your change but the removal of the if() would
not match Realtek's init sequence.

Lennert, I have compared 2.6.19-rc4 + 0001-r8169-perform-a-PHY-reset-etc
with the serie of patches against 2.6.18-rc4 which was reported to work
on your n2100 (thread on netdev around 05/09/2006). Can you:

- apply the patch below on top of 2.6.19-rc4 + 0001 and see if it works ?
  Don't apply 0002, it is not required.

- if it works (it should if I have not messed it again), can you check
  that it still works if you do not apply the first hunk ? It should as
  well.

If everything went fine this far, it would be nice to know if both the
move of the write to ChipCmd and the mdio_write are required to fix
your issue (I'd expect the move alone to not be enough as 0002 got this
part right for the 8110sb).

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 50b753d..b2fdbb8 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -491,7 +491,7 @@ static int rtl8169_poll(struct net_devic
 #endif
 
 static const u16 rtl8169_intr_mask =
-	SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
+	LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
 static const u16 rtl8169_napi_event =
 	RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr;
 static const unsigned int rtl8169_rx_config =
@@ -1283,11 +1283,6 @@ static void rtl8169_hw_phy_config(struct
 	/* Shazam ! */
 
 	if (tp->mac_version == RTL_GIGA_MAC_VER_04) {
-		mdio_write(ioaddr, 31, 0x0001);
-		mdio_write(ioaddr,  9, 0x273a);
-		mdio_write(ioaddr, 14, 0x7bfb);
-		mdio_write(ioaddr, 27, 0x841e);
-
 		mdio_write(ioaddr, 31, 0x0002);
 		mdio_write(ioaddr,  1, 0x90d0);
 		mdio_write(ioaddr, 31, 0x0000);
@@ -1855,6 +1850,8 @@ rtl8169_hw_start(struct net_device *dev)
 
 
 	RTL_W8(Cfg9346, Cfg9346_Unlock);
+
+	RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
 	RTL_W8(EarlyTxThres, EarlyTxThld);
 
 	/* Low hurts. Let's disable the filtering. */
@@ -1895,7 +1892,7 @@ rtl8169_hw_start(struct net_device *dev)
 	RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK));
 	RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32));
 	RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK));
-	RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+
 	RTL_W8(Cfg9346, Cfg9346_Lock);
 
 	/* Initially a 10 us delay. Turned it into a PCI commit. - FR */

RE: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

[Azam, Syed S]

Yes, It is still working.


Syed Azam
System Software Engineer
Hewlett-Packard Company
 
-----Original Message-----
From: Darren Salt [mailto:linux@youmustbejoking.demon.co.uk] 
Sent: Wednesday, November 01, 2006 1:01 PM
To: g.liakhovetski@gmx.de; romieu@fr.zoreil.com
Cc: torvalds@osdl.org; bunk@stusta.de; akpm@osdl.org; jgarzik@pobox.com;
linux-kernel@vger.kernel.org; tmattox@gmail.com; spiky.kiwi@gmail.com;
r.bhatia@ipax.at; Azam, Syed S; buytenh@wantstofly.org
Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known
regressions)

This message is in MIME format which your mailer apparently does not
support.
You either require a newer version of your software which supports MIME,
or
a separate MIME decoding utility.  Alternatively, ask the sender of this
message to resend it in a different format.

--163681386--1739281754--1718250983
Content-Type: text/plain; charset=us-ascii

I demand that Francois Romieu may or may not have written...

[snip]
> o Darren and Syed, are your 0x8136 still happy with the patch
>
0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.t
xt
>   at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169
>   on top of 2.6.19-rc4 ?

It is.

I then tried 0002-r8169-more-magic.txt, mainly to see that it doesn't
cause
any problems. Unfortunately, it did... however, a little reading showed
that
you've stopped enabling transmit and receive for all but four of the
chip
types supported by the driver.

An incremental fix is attached.

> o Darren, still ok to keep your S-o-b in it ?

Yes.

[snip]
-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy less and make it last longer.         INDUSTRY CAUSES GLOBAL
WARMING.

Never have a drink when you are feeling sorry for yourself.

--163681386--1739281754--1718250983
Content-Type: text/plain; charset=iso-8859-1;
name="0003-r8169-fix-more-magic.patch"
Content-Disposition: attachment;
filename="0003-r8169-fix-more-magic.patch"

r8169: fix more magic so that 8101e etc. work again

r8169-more-magic killed transmit & receive on my laptop's RTL8101e.
Turns out
to be that the enabling of these functions had been unitnentionally
removed.

(This is one of two possible fixes, the other being the removal of the
if()
guarding the other tx/rx-enable call. Both work here.)

Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>

--- drivers/net/r8169.c~	2006-11-01 19:53:02.000000000 +0000
+++ drivers/net/r8169.c	2006-11-01 19:54:16.000000000 +0000
@@ -1921,7 +1921,10 @@
 	    (tp->mac_version != RTL_GIGA_MAC_VER_02) &&
 	    (tp->mac_version != RTL_GIGA_MAC_VER_03) &&
 	    (tp->mac_version != RTL_GIGA_MAC_VER_04))
+	{
 		rtl8169_set_rx_tx_config_registers(tp);
+		RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+	}
 
 	RTL_W8(Cfg9346, Cfg9346_Lock);
 

--163681386--1739281754--1718250983--