* [rfc][patch] ipvs: use proper timeout instead of fixed value
From: Andy Gospodarek @ 2006-05-04 20:11 UTC (permalink / raw)
To: netdev; +Cc: wensong, horms, ja
Instead of using the default timeout of 3 minutes, this uses the timeout
specific to the protocol used for the connection. The 3 minute timeout
seems somewhat arbitrary (though I know it is used other places in the
ipvs code) and when failing over it would be much nicer to use one of
the configured timeout values.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
ip_vs_sync.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
--- a/net/ipv4/ipvs/ip_vs_sync.c
+++ b/net/ipv4/ipvs/ip_vs_sync.c
@@ -67,7 +67,6 @@ struct ip_vs_sync_conn_options {
struct ip_vs_seq out_seq; /* outgoing seq. struct */
};
-#define IP_VS_SYNC_CONN_TIMEOUT (3*60*HZ)
#define SIMPLE_CONN_SIZE (sizeof(struct ip_vs_sync_conn))
#define FULL_CONN_SIZE \
(sizeof(struct ip_vs_sync_conn) + sizeof(struct ip_vs_sync_conn_options))
@@ -279,6 +278,7 @@ static void ip_vs_process_message(const
struct ip_vs_sync_conn *s;
struct ip_vs_sync_conn_options *opt;
struct ip_vs_conn *cp;
+ struct ip_vs_protocol *pp;
char *p;
int i;
@@ -337,7 +337,8 @@ static void ip_vs_process_message(const
p += SIMPLE_CONN_SIZE;
atomic_set(&cp->in_pkts, sysctl_ip_vs_sync_threshold[0]);
- cp->timeout = IP_VS_SYNC_CONN_TIMEOUT;
+ pp = ip_vs_proto_get(s->protocol);
+ cp->timeout = pp->timeout_table[cp->state];
ip_vs_conn_put(cp);
if (p > buffer+buflen) {
^ permalink raw reply
* Re: i386/x86_84: disable PCI resource decode on device disable
From: Rajesh Shah @ 2006-05-04 20:01 UTC (permalink / raw)
To: Antonino A. Daplas
Cc: Dave Airlie, Rajesh Shah, gregkh, ak, linux-pci, linux-kernel,
akpm, Alan Cox
In-Reply-To: <4459CCF5.9080106@gmail.com>
On Thu, May 04, 2006 at 05:44:21PM +0800, Antonino A. Daplas wrote:
>
> Most, if not all PCI-based framebuffer drivers call pci_disable_device()
> in their unload routine. Although it's very rare that framebuffer drivers
> are unloaded, if you do, and the the resources are also disabled, it will
> kill the VGA core of the card. You lose your text console and even
> hang the machine.
>
> >
> > Alan Cox mentioned this somewhere before in relation to video cards..
>
> Alan Cox, if I remember correctly, advises against calling pci_disable_device()
> for video drivers when they unload.
>
Yeah, that's also what some other drivers do. For example, PCI/PCIE
bridges may support capabilities (like hotplug) that are controlled
by separate drivers. These drivers don't do pci_disable_device()
when they unload, since the bridge must continue to decode even
when the other capability driver is gone.
The problem is that most PCI bridges don't have any "extra"
resources padded into the address ranges they pass down. It
would be nice to be able to reuse address space released when
a device is disabled (e.g. for future hot-add), if it's really
no longer needed.
Rajesh
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Grant Likely @ 2006-05-04 20:04 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <445A534D.8090800@ics-ltd.com>
On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I'm looking into getting a BDI 2000 so I can start stepping through and
> see what is going on.
>
> I looked at the ML300 and V2Pro code in the arch/ppc/platforms/4xx
> folder, but I did not use any of that in my code. It looks like this is
> intended to be used with the BSP that is generated by Xilinx Platform
> Studio. I've tried generating the BSP this way, but the generated code
> is obviously not a complete patch to port Linux to your hardware, and I
> figure that by the time I figure out what I do/don't have to add, I
> might as well write the whole thing by myself. Have you had success
> integrating the automatically generated BSP from Xilinx Platform Studio?
No; the stuff in 2.6 is not integrated w/ platform studio. (only 2.4
is). However, you do need to extract the xparameters.h file from the
platform studio BSP. You can generate a Linux BSP w/o actually
telling it where your Linux tree is. Once its generated; pull out
xparameters.h and drop it into arch/ppc/platforms/4xx/xparameters/ in
your source tree. Note: it's important that you generate a LINUX BSP;
not a 'standalone' bsp. If you don't, then you'll be missing a bunch
of #defines.
Let me say that once more for clarity: The only file you need from
platform studio is the generated xparameters.h
This will give you at the very least a serial port driver. Once your
booting with that, you can focus on other device drivers.
Trust me; this is the path of far less pain.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Re: sched_clock() uses are broken
From: Florian Paul Schmidt @ 2006-05-04 20:02 UTC (permalink / raw)
To: Russell King; +Cc: Linux Kernel List
In-Reply-To: <20060502132953.GA30146@flint.arm.linux.org.uk>
On Tue, 2 May 2006 14:29:53 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> However, this is not the case. On x86 with TSC, it returns a 54 bit
> number. This means that when t1 < t0, time_passed_ns becomes a very
> large number which no longer represents the amount of time.
Hi,
is this specific to the sched_clock() or does the rdtsc on these systems
only use 54 bit?
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
^ permalink raw reply
* x86_64 invalid opcode
From: chris perkins @ 2006-05-04 20:00 UTC (permalink / raw)
To: linux-kernel
hi - i'm running the 2.6.16.13 x86_64 kernel on an athlon 64 and
periodically get invalid opcode and general protection faults. the system
continues to run for about 10 minutes following this and then crashes.
i've had similar problems with previous 2.6 kernels but unfortunately
don't have a capture of the output. below is the syslog output and my
.config... has anyone else seen anything similar?
thanks,
chris perkins
May 4 13:56:11 trgscratch kernel: ----------- [cut here ] ---------
[please bite here ] ---------
May 4 13:56:11 trgscratch kernel: Kernel BUG at mm/slab.c:1422
May 4 13:56:11 trgscratch kernel: invalid opcode: 0000 [1]
May 4 13:56:11 trgscratch kernel: CPU 0
May 4 13:56:11 trgscratch kernel: Modules linked in: nfsd exportfs
i2c_viapro sata_via libata
May 4 13:56:11 trgscratch kernel: Pid: 24416, comm: sshd Not tainted
2.6.16.13 #4
May 4 13:56:11 trgscratch kernel: RIP: 0010:[<ffffffff80164b90>]
<ffffffff80164b90>{kmem_freepages+112}
May 4 13:56:11 trgscratch kernel: RSP: 0018:ffff81003ade7ba8 EFLAGS:
00010046
May 4 13:56:11 trgscratch kernel: RAX: 0000000000000000 RBX:
0000000000000001 RCX: 0000000000000000
May 4 13:56:11 trgscratch kernel: RDX: ffff810001467070 RSI:
ffff810014202000 RDI: ffff81003ffaf7c0
May 4 13:56:11 trgscratch kernel: RBP: ffff81003ffaf7c0 R08:
00000000ffffff95 R09: 00000000000005a8
May 4 13:56:11 trgscratch kernel: R10: ffffffff80571b60 R11:
0000000000000246 R12: ffff810014202000
May 4 13:56:11 trgscratch kernel: R13: ffff810014202000 R14:
ffff81003ffab390 R15: ffff81003cb31248
May 4 13:56:11 trgscratch kernel: FS: 00002ac5062e6480(0000)
GS:ffffffff80629000(0000) knlGS:00000000f7fe46c0
May 4 13:56:11 trgscratch kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
May 4 13:56:11 trgscratch kernel: CR2: 000000000065ff00 CR3:
0000000018b01000 CR4: 00000000000006e0
May 4 13:56:11 trgscratch kernel: Process sshd (pid: 24416, threadinfo
ffff81003ade6000, task ffff810037cca180)
May 4 13:56:11 trgscratch kernel: Stack: ffff81003ffaf7c0
0000000000000008 ffff81001a762f00 ffffffff80164e23
May 4 13:56:11 trgscratch kernel: ffff81003cb31248
ffff81003ffaf7c0 0000000000000008 000000000000000c
May 4 13:56:11 trgscratch kernel: 0000000000000000
ffffffff80164f43
May 4 13:56:11 trgscratch kernel: Call Trace:
<ffffffff80164e23>{slab_destroy+163} <ffffffff80164f43>{free_block+211}
May 4 13:56:11 trgscratch kernel:
<ffffffff801650d5>{cache_flusharray+117} <ffffffff80164cfb>{kfree+123}
May 4 13:56:11 trgscratch kernel:
<ffffffff803bf009>{kfree_skbmem+9} <ffffffff803e4152>{tcp_recvmsg+1634}
May 4 13:56:11 trgscratch kernel:
<ffffffff803bde60>{sock_common_recvmsg+48}
<ffffffff803ba331>{do_sock_read+193}
May 4 13:56:11 trgscratch kernel:
<ffffffff803ba48f>{sock_aio_read+79} <ffffffff80168b20>{do_sync_read+208}
May 4 13:56:11 trgscratch kernel:
<ffffffff8013abc0>{autoremove_wake_function+0}
<ffffffff8017baf0>{sys_select+912}
May 4 13:56:11 trgscratch kernel: <ffffffff80168c58>{vfs_read+248}
<ffffffff80168f83>{sys_read+83}
May 4 13:56:11 trgscratch kernel:
<ffffffff8010a996>{system_call+126}
May 4 13:56:11 trgscratch kernel:
May 4 13:56:11 trgscratch kernel: Code: 0f 0b 68 18 f1 47 80 c2 8e 05 48
83 c2 38 48 ff c9 eb dd 48
May 4 13:56:11 trgscratch kernel: RIP
<ffffffff80164b90>{kmem_freepages+112} RSP <ffff81003ade7ba8>
...
May 4 14:02:20 trgscratch kernel: general protection fault: 0000 [2]
May 4 14:02:20 trgscratch kernel: CPU 0
May 4 14:02:20 trgscratch kernel: Modules linked in: nfsd exportfs
i2c_viapro sata_via libata
May 4 14:02:20 trgscratch kernel: Pid: 2158, comm: nfsd Not tainted
2.6.16.13 #4
May 4 14:02:20 trgscratch kernel: RIP: 0010:[<ffffffff80150f90>]
<ffffffff80150f90>{put_page+0}
May 4 14:02:20 trgscratch kernel: RSP: 0018:ffff81003d497e40 EFLAGS:
00010256
May 4 14:02:20 trgscratch kernel: RAX: 0000000000000000 RBX:
0000000000000001 RCX: ffff810029796640
May 4 14:02:20 trgscratch kernel: RDX: 0000000000000710 RSI:
ffff81003f510480 RDI: 2019c46deda0d8ad
May 4 14:02:20 trgscratch kernel: RBP: ffff81003f510480 R08:
ffff81003fd8a000 R09: 0000000000000000
May 4 14:02:20 trgscratch kernel: R10: 0000000000000000 R11:
0000000000000118 R12: ffff81003e21ee00
May 4 14:02:20 trgscratch kernel: R13: 0000000000000000 R14:
ffff810023cf2014 R15: 0000000000000006
May 4 14:02:20 trgscratch kernel: FS: 00002b3cc8a41b00(0000)
GS:ffffffff80629000(0000) knlGS:00000000f7f5e6c0
May 4 14:02:20 trgscratch kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
May 4 14:02:20 trgscratch kernel: CR2: 00002b686892f000 CR3:
00000000241a1000 CR4: 00000000000006e0
May 4 14:02:20 trgscratch kernel: Process nfsd (pid: 2158, threadinfo
ffff81003d496000, task ffff81003fdfb040)
May 4 14:02:20 trgscratch kernel: Stack: ffffffff803bf21a
ffffffff88033bf0 ffff81003f510480 ffff81003db2cc00
May 4 14:02:20 trgscratch kernel: ffffffff803bf009
ffff81003f510480 ffffffff804249a2 ffffffff80576ae0
May 4 14:02:20 trgscratch kernel: ffffffff88033bf0
ffff81003db2cc00
May 4 14:02:20 trgscratch kernel: Call Trace:
<ffffffff803bf21a>{skb_release_data+106}
May 4 14:02:20 trgscratch kernel:
<ffffffff803bf009>{kfree_skbmem+9} <ffffffff804249a2>{svc_send+146}
May 4 14:02:20 trgscratch kernel:
<ffffffff80423045>{svc_process+1093}
<ffffffff80124440>{default_wake_function+0}
May 4 14:02:20 trgscratch kernel: <ffffffff8801c260>{:nfsd:nfsd+0}
<ffffffff8801c406>{:nfsd:nfsd+422}
May 4 14:02:20 trgscratch kernel: <ffffffff8010b516>{child_rip+8}
<ffffffff8801c260>{:nfsd:nfsd+0}
May 4 14:02:20 trgscratch kernel: <ffffffff8801c260>{:nfsd:nfsd+0}
<ffffffff8010b50e>{child_rip+0}
May 4 14:02:20 trgscratch kernel:
May 4 14:02:20 trgscratch kernel: Code: 8b 07 f6 c4 40 74 09 e9 94 fd ff
ff 66 66 66 90 8b 47 08 ff
May 4 14:02:20 trgscratch kernel: RIP <ffffffff80150f90>{put_page+0} RSP
<ffff81003d497e40>
May 4 14:02:34 trgscratch ntpd[2207]: synchronized to 130.199.75.2,
stratum 2
May 4 14:02:44 trgscratch kernel: <7>retrans_out leaked.
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.16.13
# Wed May 3 18:23:06 2006
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_UID16=y
CONFIG_VM86=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_LBD=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VSMP is not set
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_GART_IOMMU=y
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_INTEL is not set
CONFIG_X86_MCE_AMD=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_ISA_DMA_API=y
#
# Power management options
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_SLEEP is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
# CONFIG_ACPI_VIDEO is not set
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_UNORDERED_IO is not set
# CONFIG_PCIEPORTBUS is not set
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_DEBUG is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_PNPACPI=y
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_SX8=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_SATA=m
CONFIG_SCSI_SATA_AHCI=m
# CONFIG_SCSI_SATA_SVW is not set
# CONFIG_SCSI_ATA_PIIX is not set
# CONFIG_SCSI_SATA_MV is not set
CONFIG_SCSI_SATA_NV=m
# CONFIG_SCSI_PDC_ADMA is not set
# CONFIG_SCSI_SATA_QSTOR is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_SX4 is not set
# CONFIG_SCSI_SATA_SIL is not set
# CONFIG_SCSI_SATA_SIL24 is not set
# CONFIG_SCSI_SATA_SIS is not set
# CONFIG_SCSI_SATA_ULI is not set
CONFIG_SCSI_SATA_VIA=m
# CONFIG_SCSI_SATA_VITESSE is not set
CONFIG_SCSI_SATA_INTEL_COMBINED=y
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=y
CONFIG_MD_RAID5=y
CONFIG_MD_RAID6=y
CONFIG_MD_MULTIPATH=y
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
CONFIG_DM_ZERO=y
# CONFIG_DM_MULTIPATH is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
CONFIG_AMD8111_ETH=y
CONFIG_AMD8111E_NAPI=y
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
CONFIG_FORCEDETH=y
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
CONFIG_8139CP=y
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_VIA_RHINE is not set
#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=y
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=y
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
CONFIG_NS83820=y
CONFIG_HAMACHI=y
CONFIG_YELLOWFIN=y
CONFIG_R8169=y
# CONFIG_R8169_NAPI is not set
CONFIG_SIS190=y
CONFIG_SKGE=y
CONFIG_SKY2=y
CONFIG_SK98LIN=y
CONFIG_VIA_VELOCITY=y
CONFIG_TIGON3=y
CONFIG_BNX2=y
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_XTKBD=y
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_VSXXXAA=m
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_UINPUT=m
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_STALDRV is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=y
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
#
# I2C support
#
CONFIG_I2C=y
# CONFIG_I2C_CHARDEV is not set
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
CONFIG_I2C_PCA_ISA=m
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
# CONFIG_SENSORS_PCA9539 is not set
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_RTC_X1205_I2C is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
#
# Multimedia Capabilities Port drivers
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_MACMODES is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=y
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
#
# Logo configuration
#
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
# CONFIG_CONFIGFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
CONFIG_RPCSEC_GSS_SPKM3=m
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
# CONFIG_KPROBES is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_IOMMU_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_X86_64 is not set
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
#
# Library routines
#
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
^ permalink raw reply
* Re: hpt366 driver oops or panic with HighPoint RocketRAID 1520 SATA (HPT372N)
From: Sergei Shtylyov @ 2006-05-04 19:53 UTC (permalink / raw)
To: Johan Palmqvist; +Cc: mlaks, linux-kernel, linux-ide
In-Reply-To: <1131467876.25192.51.camel@localhost.localdomain>
Hello.
Alan Cox wrote:
>>When used with a HighPoint RocketRAID 1520 SATA (HPT372N) the hpt366
>>driver, compiled as a module, oops'es on loading. If the driver is
>>compiled into the kernel it causes a kernel panic on boot while
>>detecting the card. Kernels tested: 2.6.13.2, 2.6.13.4 and 2.6.14.
>>Please CC any answers to me since I'm not on the list.
I think I've dealt with this oops now, see my recent patches to this
driver, particularly the one that reads the f_CNT value saved by BIOS...
WBR, Sergei
^ permalink raw reply
* Re: Ok lets get back on track
From: Hans @ 2006-05-04 19:52 UTC (permalink / raw)
To: Fredrik Söderlund, Linux-8086
In-Reply-To: <200605040145.53089.fille.sod@telia.com>
Hi Fille,
----- Original Message -----
From: "Fredrik Söderlund" <fille.sod@telia.com>
To: "Linux-8086" <linux-8086@vger.kernel.org>
Sent: Thursday, May 04, 2006 12:45 AM
Subject: Ok lets get back on track
> First of All
> Sorry for my horrible English.
> Sorry if i have offended anybody that was never my meaning !
Please no apology, if we don't understand we can always ask :-)
>
> Tanks Hans for bringing me to the right side ...
> http://www.alfonsomartone.itb.it/fhlvnr.html
>
> I mean running a C compiler under ELKS ore similuare "C++" ;-)
In that case you best bet is to use bcc (C only). You might be able to port
another compiler but I suspect that is not going to be easy.
>
> have learned now that some sort of C bcc, and Asambler, ACK.
> Is how to start Now i have to Study both English and Programming ;-)
For English I would use a spelling checker since that can help you a lot. I
am not sure about gaining some programming skills using ELKS unless you are
after embedded programming skills?
>
> And i am not the right person to judge if the site shuld have the diffrent
> Programming Language and compilers on the side But i dont think so.
mmmm..., I think we should since I am personally not a great fan of BCC
simply because I failed to build it under Cygwin and Gentoo64. I have
received a number of suggestion to solve this one like chrooting into a 32
bits environment but to be honest there are a lots of free 8086 compilers
available and some of them are quite good (e.g. Open Watcom, see
http://www.openwatcom.org/index.php/Main_Page).
Another suggestion is to use ACK. This has the added advantage that we can
target different microcontroller/processors something which might boost the
popularity of ELKS. David Given is working on (or has completed? )
resurrecting this compiler. See
http://www.opensubscriber.com/message/linux-8086@vger.kernel.org/1939852.html
for a trail of old messages.
>
> some "ftp" with programs none to work on ELKS .. like thre example from
> microwin
> ftp://microwindows.censoft.com/pub/microwindows/Binaries/ElksExamples
Interesting, I guess there are lots of good links lurking away on the
internet, Jody, what about adding a useful links page to the website?
Regards,
Hans.
www.ht-lab.com
> ore similare
>
> regurds Fille
>
>
>
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kernel debugging
From: Steve Iribarne (GMail) @ 2006-05-04 19:51 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <4459C774.8000300@dlasys.net>
On 5/4/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> Everyone has their own debugging style.
>
> Engineers seem to like hardware debugging tools. I have used some
> very fancy debugging hardware, but except for extremely rare instances
> it is more work to get setup
> and figure out what you are trying to do than inserting some
> debugging and rebuilding.
>
> My idea of debugging hardware is a port with an LED on it I can try
> to blink.
>
> I also only rarely use software debuggers.
>
> Most of the time when things go off the rails the critical question
> for me is Where did things go wrong. Once I know that usually the
> problem is obvious and I do nto need dumps of variables or memory.
>
> I also do development across numerous platforms, OS's and languages.
> I need debugging tools and techniques that are broadly portable. A
> hardware debugging tool might help with board bringup, but it would be
> of little use
> for web or perl programming. Investing time and capitol in highly
> specialized tools or knowledge requires being narrowly focused to get a
> worthwhile payback.
>
> Regardless, I think debugging is a sort of religious preference. You
> need to know who you are and what you need. Other peoples experience is
> useful but should not be determinative.
>
Yes I am finding this out. It's a long journey! :)
Most of the issues I have to deal with are systems that are already up
and running in the PPC world and I come in afterwords to clean up. So
for example, right now I think I have a DMA problem that is crashing
my PPC and rebooting the system.
To be sure, I would love to step over a few instructions and slow the
world down a bit. That's why I was going to setup kgdb or something
like that.
Thanks.
-stv
> Steve Iribarne (GMail) wrote:
> > Hello.
> >
> > This is more a general question to see what others do out here. I am
> > begining to get sick of printk debugging. I work on two different PPC
> > boards. An 860 and 8260.
> >
> > I want to get some feedback on the best kernel debugger to use. I
> > have been looking at three.
> >
> > 1. kgdb
> > 2. kdb
> > 3. UML
> >
> > I am leaning towards kgdb, but before I jump in I thought I'd put this
> > out to the best group I could think of linuxppc. Because I am sure
> > most of you are using something! :)
> >
> > Thanks.
> >
> > -stv
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
> --
> Dave Lynch DLA Systems
> Software Development: Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
> fax: 1.253.369.9244 Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too n=
umerous to list.
>
>
^ permalink raw reply
* Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Arjan van de Ven @ 2006-05-04 19:49 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, Dave Airlie, Andrew Morton, greg, linux-kernel, pjones
In-Reply-To: <200605041326.36518.bjorn.helgaas@hp.com>
Bjorn Helgaas wrote:
> On Thursday 04 May 2006 13:11, Arjan van de Ven wrote:
>> Bjorn Helgaas wrote:
>>> On Saturday 29 April 2006 03:04, Dave Airlie wrote:
>>>>> This patch adds an "enable" sysfs attribute to each PCI device. When read it
>>>>> shows the "enabled-ness" of the device, but you can write a "0" into it to
>>>>> disable a device, and a "1" to enable it.
>>>>>
>>>>> This later is needed for X and other cases where userspace wants to enable
>>>>> the BARs on a device (typical example: to run the video bios on a secundary
>>>>> head). Right now X does all this "by hand" via bitbanging, that's just evil.
>>>>> This allows X to no longer do that but to just let the kernel do this.
>>> I'm all in favor of cleaning up X. But making the X code prettier without
>>> changing the underlying issues of claiming and sharing resources doesn't
>>> help much. In fact, I suspect the ultimate plan for X does not involve
>>> an "enable" attribute in sysfs, so this may just introduce ABI cruft that
>>> will be difficult to remove later.
>> it goes well beyond X. Things like vbetool need this too to get to the content
>> of the rom for example. There are several other such cases...
>
> There's already a "rom" file in sysfs. Could vbetool and friends
> use that?
not unless the device is enabled.
> How do vbetool and X coordinate their usage of "enable"?
Just never disable :)
^ permalink raw reply
* Re: TCP/IP send, sendfile, RAW
From: Willy Tarreau @ 2006-05-04 19:48 UTC (permalink / raw)
To: Roy Rietveld; +Cc: linux-os, linux-kernel
In-Reply-To: <BAY105-F38F372575F5B72AF1DACE6E9B40@phx.gbl>
On Thu, May 04, 2006 at 07:43:34PM +0000, Roy Rietveld wrote:
> i Think the resolution of gettimeofday is 1us because
> gettimeofday(start)
> gettimeofday(end)
>
> end - start gives 1
>
> so when i leave out gettimeofday
>
> while(1)
> {
> sendto(socket,buffer,1400,....)
> }
>
> i measured with ethereal 4000 packets per second
Are you sure you are not limited by the interrupt rate ? may be interrupt
processing causes a large overhead at 4000/s for 177 MHz, and you might
need to find a way to either use interrupt mitigation or polling.
Regards,
Willy
^ permalink raw reply
* Re: [PATCH] HPT3xx: fix PCI clock detection
From: Sergei Shtylyov @ 2006-05-04 19:46 UTC (permalink / raw)
To: Andrew Morton
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel, Alan Cox
In-Reply-To: <4457DC97.3010807@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
Use the f_CNT value saved by the HighPoint BIOS if available as reading it
directly would give us a wrong PCI frequency after DPLL has already been
calibrated by BIOS.
Should apply on top of my recent patches.
MBR, Sergei
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[-- Attachment #2: HPT3xx-use-f_CNT-saved-by-BIOS.patch --]
[-- Type: text/plain, Size: 2922 bytes --]
Index: linus/drivers/ide/pci/hpt366.c
===================================================================
--- linus.orig/drivers/ide/pci/hpt366.c
+++ linus/drivers/ide/pci/hpt366.c
@@ -71,6 +71,8 @@
* needed and had many modes over- and underclocked, HPT372 33 MHz table was
* for 66 MHz and 50 MHz table missed UltraDMA mode 6, HPT374 33 MHz table was
* really for 50 MHz; switch to using HPT372 tables for HPT374...
+ * - use f_CNT value saved by the HighPoint BIOS as reading it directly gives
+ * the wrong PCI frequency since DPLL has already been calibrated by BIOS
* - fix the hotswap code: it caused RESET- to glitch when tristating the bus,
* and for HPT36x the obsolete HDIO_TRISTATE_HWIF handler was called instead
* - pass to init_chipset() handlers a copy of the IDE PCI device structure as
@@ -1050,8 +1052,8 @@ static void __devinit hpt37x_clocking(id
struct hpt_info *info = ide_get_hwifdata(hwif);
struct pci_dev *dev = hwif->pci_dev;
int adjust, i;
- u16 freq;
- u32 pll;
+ u16 freq = 0;
+ u32 pll, temp = 0;
u8 reg5bh = 0, mcr1 = 0;
/*
@@ -1065,15 +1067,34 @@ static void __devinit hpt37x_clocking(id
pci_write_config_byte(dev, 0x5b, 0x23);
/*
- * set up the PLL. we need to adjust it so that it's stable.
- * freq = Tpll * 192 / Tpci
+ * We'll have to read f_CNT value in order to determine
+ * the PCI clock frequency according to the following ratio:
*
- * Todo. For non x86 should probably check the dword is
- * set to 0xABCDExxx indicating the BIOS saved f_CNT
+ * f_CNT = Fpci * 192 / Fdpll
+ *
+ * First try reading the register in which the HighPoint BIOS
+ * saves f_CNT value before reprogramming the DPLL from its
+ * default setting (which differs for the various chips).
+ * In case the signature check fails, we'll have to resort to
+ * reading the f_CNT register itself in hopes that nobody has
+ * touched the DPLL yet...
*/
- pci_read_config_word(dev, 0x78, &freq);
- freq &= 0x1FF;
-
+ pci_read_config_dword(dev, 0x70, &temp);
+ if ((temp & 0xFFFFF000) != 0xABCDE000) {
+ int i;
+
+ printk(KERN_WARNING "HPT37X: no clock data saved by BIOS\n");
+
+ /* Calculate the average value of f_CNT */
+ for (temp = i = 0; i < 128; i++) {
+ pci_read_config_word(dev, 0x78, &freq);
+ temp += freq & 0x1ff;
+ mdelay(1);
+ }
+ freq = temp / 128;
+ } else
+ freq = temp & 0x1ff;
+
/*
* HPT3xxN chips use different PCI clock information.
* Currently we always set up the PLL for them.
@@ -1146,11 +1167,8 @@ static void __devinit hpt37x_clocking(id
info->flags |= PLL_MODE;
/*
- * FIXME: make this work correctly, esp with 372N as per
- * reference driver code.
- *
- * adjust PLL based upon PCI clock, enable it, and wait for
- * stabilization.
+ * Adjust the PLL based upon the PCI clock, enable it, and
+ * wait for stabilization...
*/
adjust = 0;
freq = (pll < F_LOW_PCI_50) ? 2 : 4;
^ permalink raw reply
* [lm-sensors] [PATCH 1/2 RESEND] hwmon: new vt1211 driver
From: Juerg Haefliger @ 2006-05-04 19:47 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <191fb4ca0604062128m60ba1c53gbcab205aa6f40c0c@mail.gmail.com>
Hi Jim,
> > The classic 2D array grouping is more elegant in term of function, but bit
> > strange on the hand of array mapping/dimension.
> >
> >
> Yes, I too like 1D for array of identical sensors, 2nd D for FN-specifier.
> Seems like what SENSOR_ATTR_2 was invented for.
> But then, I already had the separate arrays of identical sensors. ;-)
>
> IIRC, I asked Juerg about that, and he answered in a sense. (or maybe Im
> remembering someone else :-/)
> I didnt quite get the argument ( I think he gains other advantages by
> his grouping strategy)
> but I hadnt reviewed that diligently.
> (to misquote a marvel-ous Spiderman saying: with no power comes no
> responsibility :-D
Hmm... not exactly sure what you're talking about...
...juerg
^ permalink raw reply
* Re: Where to look for CRAMFS
From: Antonio Di Bacco @ 2006-05-04 19:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <c359a7c00605031415o545d761cha3a3498c9454f3df@mail.gmail.com>
Your flash is seen by the kernel as sequence of partitions, the size and
offset of each partition (mtd partition) can be specified in two ways:
1) Tipically your board has a specific file in drivers/mtd/maps/yourboard.c
that cares to partition the flash based on a static table that you provide.
2) The kernel can parse command line argument mtdparts (for example
mtdparts=0:384k(boot),1024k(kern),2560k(cramfs),-(jffs2) ) to get the size of
these partitions (this feature should be enabled when compiling the kernel)
Your cramfs will be written in one of this partitions and you can tell the
kernel in which one it resides specifying cmd line argument "root"
On my board I specified 4 partitions on my 8MB flash:
1) /dev/mtd0 -> 256kb for u-boot and its environment
2) /dev/mtd1 -> for the kernel
3) /dev/mtd2 -> for rootfs on a cramfs
4) /dev/mtd3 -> for a jffs2 filesystem
and therefore root=/dev/mtd2
If you want to load your software as a bundle of both kernel and cramfs and
not separately you can also provide your package with an header containing
the size of kernel and cramfs and instruct the kernel to partition the flash
based on this header.
Bye,
Antonio.
On Wednesday 03 May 2006 23:15, Sauro Salomoni wrote:
> Greetings.
>
> I have an embedded board using i.MX21.
>
> What I want to know is: how do I tell the kernel where my CRAMFS root
> file system is?
> I mean, I put it in a specific memory address, but how does the kernel
> know where it is?!
>
> What happens here is that the kernel looks in some address and don't
> find the Magic Number CRAMFS stores in its own start address. I have a
> "bad magic number" msg because my root fs is somewhere else.
> Can anyone help me, plz?
>
> Thanks in advance.
>
>
> Sauro
> Engineer
> Z Tec
> www.ztec.com.br
> +55 61 3322-2544
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] powerpc: add num_pmcs to 970MP cputable entry
From: Anton Blanchard @ 2006-05-04 19:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi,
The 970MP cputable entry needs a num_pmcs entry for oprofile to work.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 39e348a..f618ff4 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -230,6 +230,7 @@ struct cpu_spec cpu_specs[] = {
PPC_FEATURE_HAS_ALTIVEC_COMP,
.icache_bsize = 128,
.dcache_bsize = 128,
+ .num_pmcs = 8,
.cpu_setup = __setup_cpu_ppc970,
.oprofile_cpu_type = "ppc64/970",
.oprofile_type = PPC_OPROFILE_POWER4,
^ permalink raw reply related
* [lm-sensors] [PATCH 1/2 RESEND] hwmon: new vt1211 driver
From: Juerg Haefliger @ 2006-05-04 19:44 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <191fb4ca0604062128m60ba1c53gbcab205aa6f40c0c@mail.gmail.com>
Thanks for the review, Rudolf.
> > +/* -------------------------------------------------------------------------
>
> Hmm as Jim already mentioned I dont know if Jean will like it. On the other hand
> this line is on many places in kernel, but bit shorter, like this:
>
> /*-------------------------------------------------------------------------*/
OK, fix the length (or get rid of them alltogether).
> > + /* voltage (in) registers */
> > + for (ix = 0; ix <= 6; ix++) {
>
> The ARRAY_SIZE idea sounds good to me too.
Yep it is. Will fix it.
> > + /* temp registers */
> > + for (ix = 1; ix <= 7; ix++) {
>
> And Jims proposal for the "get rid of -1" is a good one too. And of course on
> other places too.
Hmm... If you guys feel so strongly about it I'll change it (even
though I still think it's easier to read the way it is now :-).
> > +#define SHOW_TEMP_INPUT 0
> > +#define SHOW_SET_TEMP_MAX 1
> > +#define SHOW_SET_TEMP_MAX_HYST 2
> > +#define SHOW_TEMP_ALARM 3
>
> Jim wrote that he likes the idea, well I'm myself still not convinced.
>
> The classic 2D array grouping is more elegant in term of function, but bit
> strange on the hand of array mapping/dimension.
>
> This case is vice-versa data structures are nice function is bit more
> complicated. I'm not telling you to remove it, but please at least change
> the default case to error and nr to some better name.
OK, I'll fix the default and the nr naming. I still prefer to keep the
combined callbacks, they make the source much smaller and the grouping
of functions for same sensors makes it very easy to read the code.
...juerg
^ permalink raw reply
* Re: assert/crash in __rmqueue() when enabling CONFIG_NUMA
From: Bob Picco @ 2006-05-04 19:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Bob Picco, Dave Hansen, Nick Piggin, Martin J. Bligh, Andi Kleen,
linux-kernel, Andrew Morton, Linux Memory Management,
Andy Whitcroft
In-Reply-To: <20060504192528.GA26759@elte.hu>
Ingo Molnar wrote: [Thu May 04 2006, 03:25:28PM EDT]
>
> * Bob Picco <bob.picco@hp.com> wrote:
>
> > Dave Hansen wrote: [Thu May 04 2006, 11:21:06AM EDT]
> > > I haven't thought through it completely, but these two lines worry me:
> > >
> > > > + start = pgdat->node_start_pfn & ~((1 << (MAX_ORDER - 1)) - 1);
> > > > + end = start + pgdat->node_spanned_pages;
> > >
> > > Should the "end" be based off of the original "start", or the aligned
> > > "start"?
> >
> > Yes. I failed to quilt refresh before sending. You mean end should be
> > end = pgdat->node_start_pfn + pgdat->node_spanned_pages before
> > rounding up.
>
> do you have an updated patch i should try?
>
> Ingo
You can try this but don't believe it will change your outcome. I've
booted this on ia64 with slight modification to eliminate
VIRTUAL_MEM_MAP and have only DISCONTIGMEM. Your case is failing at the
front edge of of the zone and not the ending edge which had a flaw in my
first post of the patch. I would have expected the first patch to handle
the front edge correctly.
I don't remember seeing your .config in the thread (or blind and unable
to see it). Would you please send it my way.
I'm also hoping Andy has time to look into this.
bob
Index: linux-2.6.17-rc3/mm/page_alloc.c
===================================================================
--- linux-2.6.17-rc3.orig/mm/page_alloc.c 2006-04-27 09:44:02.000000000 -0400
+++ linux-2.6.17-rc3/mm/page_alloc.c 2006-05-04 13:01:25.000000000 -0400
@@ -2123,14 +2123,22 @@ static void __init alloc_node_mem_map(st
#ifdef CONFIG_FLAT_NODE_MEM_MAP
/* ia64 gets its own node_mem_map, before this, without bootmem */
if (!pgdat->node_mem_map) {
- unsigned long size;
+ unsigned long size, start, end;
struct page *map;
- size = (pgdat->node_spanned_pages + 1) * sizeof(struct page);
+ /*
+ * The zone's endpoints aren't required to be MAX_ORDER
+ * aligned but the node_mem_map endpoints must be in order
+ * for the buddy allocator to function correctly.
+ */
+ start = pgdat->node_start_pfn & ~(MAX_ORDER_NR_PAGES - 1);
+ end = pgdat->node_start_pfn + pgdat->node_spanned_pages;
+ end = ALIGN(end, MAX_ORDER_NR_PAGES);
+ size = (end - start) * sizeof(struct page);
map = alloc_remap(pgdat->node_id, size);
if (!map)
map = alloc_bootmem_node(pgdat, size);
- pgdat->node_mem_map = map;
+ pgdat->node_mem_map = map + (pgdat->node_start_pfn - start);
}
#ifdef CONFIG_FLATMEM
/*
Index: linux-2.6.17-rc3/include/linux/mmzone.h
===================================================================
--- linux-2.6.17-rc3.orig/include/linux/mmzone.h 2006-04-27 09:44:02.000000000 -0400
+++ linux-2.6.17-rc3/include/linux/mmzone.h 2006-05-04 13:01:39.000000000 -0400
@@ -22,6 +22,7 @@
#else
#define MAX_ORDER CONFIG_FORCE_MAX_ZONEORDER
#endif
+#define MAX_ORDER_NR_PAGES (1 << (MAX_ORDER - 1))
struct free_area {
struct list_head free_list;
^ permalink raw reply
* Re: TCP/IP send, sendfile, RAW
From: Roy Rietveld @ 2006-05-04 19:43 UTC (permalink / raw)
To: linux-os; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.61.0605041459220.7134@chaos.analogic.com>
i Think the resolution of gettimeofday is 1us because
gettimeofday(start)
gettimeofday(end)
end - start gives 1
so when i leave out gettimeofday
while(1)
{
sendto(socket,buffer,1400,....)
}
i measured with ethereal 4000 packets per second
so
1400+headers = 1442
1442*8*4000 = 46MBits
I read something about zero copy may i need somelike that.
>From: "linux-os (Dick Johnson)" <linux-os@analogic.com>
>Reply-To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
>To: "Roy Rietveld" <rwm_rietveld@hotmail.com>
>CC: <linux-kernel@vger.kernel.org>, <jengelh@linux01.gwdg.de>
>Subject: Re: TCP/IP send, sendfile, RAW
>Date: Thu, 4 May 2006 15:12:34 -0400
>
>
>On Thu, 4 May 2006, Roy Rietveld wrote:
>
> > i tried but it doesn't help, still 40MBits. Does send or sento cost a
>lot of
> > cpu load.
> >
> > i tried to measure the cpu time sendto cost.
> >
> > gettimeofday(start)
> > sendto
> > gettimeofday(end)
> >
> > print end - start
> >
> > time measured is 250 us.
> >
>
>That's probably the granuarity of gettimeofday().
>
>You need to do something like:
> #define USEC 1e6
> double start_time, end_time, total_time, bytes_per_second;
> get_timeofday(&tb);
> start_time_usec = ((double)tb.tv_sec * USEC) +
>(double)tb.tv_usec;
> for(i= 0; i <1000; i++)
> sendto(s, buf, buf_size,...);
> get_timeofday(&tb);
> end_time_usec = ((double)tb.tv_sec * USEC) + (double)tb.tv_usec;
> total_time = (end_time_usec - start_time_usec) / USEC;
> bytes_per_second = (buf_size * 1000) / total_time;
>
>
> >
> >> From: "linux-os (Dick Johnson)" <linux-os@analogic.com>
> >> Reply-To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
> >> To: "Roy Rietveld" <rwm_rietveld@hotmail.com>
> >> CC: <linux-kernel@vger.kernel.org>,<jengelh@linux01.gwdg.de>
> >> Subject: Re: TCP/IP send, sendfile, RAW
> >> Date: Thu, 4 May 2006 14:27:47 -0400
> >>
> >>
> >> On Thu, 4 May 2006, Roy Rietveld wrote:
> >>
> >>> Yes it is 100 MBits and there is a listener. and there are no other
>pc's
> >> on
> >>> the link because its cross cable link. And when sending large buffers
> >>> 32Kbyte it will do 80 MBits. It think that there is a lot of overhead
>in
> >> the
> >>> fucntion send or something.
> >>>
> >>
> >> Use sendto() and recvfrom() for UDP. Stream protocols require an ACK
>and
> >> are slower.
> >>
> >>>
> >>>> From: "linux-os (Dick Johnson)" <linux-os@analogic.com>
> >>>> Reply-To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
> >>>> To: "Jan Engelhardt" <jengelh@linux01.gwdg.de>
> >>>> CC: "Roy Rietveld"
> >>>> <rwm_rietveld@hotmail.com>,<linux-kernel@vger.kernel.org>
> >>>> Subject: Re: TCP/IP send, sendfile, RAW
> >>>> Date: Thu, 4 May 2006 13:56:31 -0400
> >>>>
> >>>>
> >>>> On Thu, 4 May 2006, Jan Engelhardt wrote:
> >>>>
> >>>>>> I would like to send ethernet packets with 1400 bytes payload.
> >>>>>> I wrote a small program witch sends a buffer of 1400 bytes in a
> >> endless
> >>>> loop.
> >>>>>> The problem is that a would like 100Mbits throughtput but when i
> >> check
> >>>> this
> >>>>>> with ethereal.
> >>>>>> I only get 40 MBits. I tried sending with an UDP socket and RAW
> >> socket.
> >>>> I also
> >>>>>> tried sendfile.
> >>>>>> The RAW socket gives the best result till now 50 MBits throughtput.
> >>>>>
> >>>>> Limitation of Ethernet.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Jan Engelhardt
> >>>>
> >>>> Maybe he can tell what he means by 100 MBits! If he is looking for
> >>>> 100 megabits per second, that's easy, That's 100/8 = 12.5 megabytes
> >>>> per second. Anything, including Windows on a wet string, will
> >>>> do that. If he is looking for 100 megabytes per second, that's
> >>>> hard. He would need 100 * 8 = 800 megabits/second. A "gigabit" link
> >>>> runs that fast if nobody else is on it, but there is a header and CRC
> >>>> tail, in addition to the payload. UDP is the protocol to use to
>realize
> >>>> this kind of bandwidth, but its possible for some packets to get lost
> >> and,
> >>>> if they are routed, they could even be duplicated. Also, when testing
> >>>> UDP, there must be a listener in order to realize the high speed.
> >>>> You can't just spew out a dead-end link.
> >>>>
> >>>> Cheers,
> >>>> Dick Johnson
> >>>> Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89
>BogoMips).
> >>>> New book: http://www.lymanschool.com
> >>>> _
> >>>> \x1a\x04
> >>>>
> >>>> ****************************************************************
> >>>> The information transmitted in this message is confidential and may
>be
> >>>> privileged. Any review, retransmission, dissemination, or other use
>of
> >>>> this information by persons or entities other than the intended
> >> recipient
> >>>> is prohibited. If you are not the intended recipient, please notify
> >>>> Analogic Corporation immediately - by replying to this message or by
> >>>> sending an email to DeliveryErrors@analogic.com - and destroy all
> >> copies of
> >>>> this information, including any attachments, without reading or
> >> disclosing
> >>>> them.
> >>>>
> >>>> Thank you.
> >>>> -
> >>>> To unsubscribe from this list: send the line "unsubscribe
>linux-kernel"
> >> in
> >>>> the body of a message to majordomo@vger.kernel.org
> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>> Please read the FAQ at http://www.tux.org/lkml/
> >>>
> >>>
> >>>
> >>
> >> Cheers,
> >> Dick Johnson
> >> Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
> >> New book: http://www.lymanschool.com
> >> _
> >> \x1a\x04
> >>
> >> ****************************************************************
> >> The information transmitted in this message is confidential and may be
> >> privileged. Any review, retransmission, dissemination, or other use of
> >> this information by persons or entities other than the intended
>recipient
> >> is prohibited. If you are not the intended recipient, please notify
> >> Analogic Corporation immediately - by replying to this message or by
> >> sending an email to DeliveryErrors@analogic.com - and destroy all
>copies of
> >> this information, including any attachments, without reading or
>disclosing
> >> them.
> >>
> >> Thank you.
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
>Cheers,
>Dick Johnson
>Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
>New book: http://www.lymanschool.com
>_
>\x1a\x04
>
>****************************************************************
>The information transmitted in this message is confidential and may be
>privileged. Any review, retransmission, dissemination, or other use of
>this information by persons or entities other than the intended recipient
>is prohibited. If you are not the intended recipient, please notify
>Analogic Corporation immediately - by replying to this message or by
>sending an email to DeliveryErrors@analogic.com - and destroy all copies of
>this information, including any attachments, without reading or disclosing
>them.
>
>Thank you.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: assert/crash in __rmqueue() when enabling CONFIG_NUMA
From: Bob Picco @ 2006-05-04 19:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Bob Picco, Dave Hansen, Nick Piggin, Martin J. Bligh, Andi Kleen,
linux-kernel, Andrew Morton, Linux Memory Management,
Andy Whitcroft
In-Reply-To: <20060504192528.GA26759@elte.hu>
Ingo Molnar wrote: [Thu May 04 2006, 03:25:28PM EDT]
>
> * Bob Picco <bob.picco@hp.com> wrote:
>
> > Dave Hansen wrote: [Thu May 04 2006, 11:21:06AM EDT]
> > > I haven't thought through it completely, but these two lines worry me:
> > >
> > > > + start = pgdat->node_start_pfn & ~((1 << (MAX_ORDER - 1)) - 1);
> > > > + end = start + pgdat->node_spanned_pages;
> > >
> > > Should the "end" be based off of the original "start", or the aligned
> > > "start"?
> >
> > Yes. I failed to quilt refresh before sending. You mean end should be
> > end = pgdat->node_start_pfn + pgdat->node_spanned_pages before
> > rounding up.
>
> do you have an updated patch i should try?
>
> Ingo
You can try this but don't believe it will change your outcome. I've
booted this on ia64 with slight modification to eliminate
VIRTUAL_MEM_MAP and have only DISCONTIGMEM. Your case is failing at the
front edge of of the zone and not the ending edge which had a flaw in my
first post of the patch. I would have expected the first patch to handle
the front edge correctly.
I don't remember seeing your .config in the thread (or blind and unable
to see it). Would you please send it my way.
I'm also hoping Andy has time to look into this.
bob
Index: linux-2.6.17-rc3/mm/page_alloc.c
===================================================================
--- linux-2.6.17-rc3.orig/mm/page_alloc.c 2006-04-27 09:44:02.000000000 -0400
+++ linux-2.6.17-rc3/mm/page_alloc.c 2006-05-04 13:01:25.000000000 -0400
@@ -2123,14 +2123,22 @@ static void __init alloc_node_mem_map(st
#ifdef CONFIG_FLAT_NODE_MEM_MAP
/* ia64 gets its own node_mem_map, before this, without bootmem */
if (!pgdat->node_mem_map) {
- unsigned long size;
+ unsigned long size, start, end;
struct page *map;
- size = (pgdat->node_spanned_pages + 1) * sizeof(struct page);
+ /*
+ * The zone's endpoints aren't required to be MAX_ORDER
+ * aligned but the node_mem_map endpoints must be in order
+ * for the buddy allocator to function correctly.
+ */
+ start = pgdat->node_start_pfn & ~(MAX_ORDER_NR_PAGES - 1);
+ end = pgdat->node_start_pfn + pgdat->node_spanned_pages;
+ end = ALIGN(end, MAX_ORDER_NR_PAGES);
+ size = (end - start) * sizeof(struct page);
map = alloc_remap(pgdat->node_id, size);
if (!map)
map = alloc_bootmem_node(pgdat, size);
- pgdat->node_mem_map = map;
+ pgdat->node_mem_map = map + (pgdat->node_start_pfn - start);
}
#ifdef CONFIG_FLATMEM
/*
Index: linux-2.6.17-rc3/include/linux/mmzone.h
===================================================================
--- linux-2.6.17-rc3.orig/include/linux/mmzone.h 2006-04-27 09:44:02.000000000 -0400
+++ linux-2.6.17-rc3/include/linux/mmzone.h 2006-05-04 13:01:39.000000000 -0400
@@ -22,6 +22,7 @@
#else
#define MAX_ORDER CONFIG_FORCE_MAX_ZONEORDER
#endif
+#define MAX_ORDER_NR_PAGES (1 << (MAX_ORDER - 1))
struct free_area {
struct list_head free_list;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Matthew Garrett @ 2006-05-04 19:42 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, Dave Airlie, Andrew Morton, greg, linux-kernel, pjones,
Arjan van de Ven
In-Reply-To: <200605041326.36518.bjorn.helgaas@hp.com>
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> There's already a "rom" file in sysfs. Could vbetool and friends
> use that?
Not if you have multiple graphics cards.
> How do vbetool and X coordinate their usage of "enable"?
vbetool won't run at anything other than a text console, and X won't
mess with the graphics card if it's not on the current VT. You can mess
this up if you try hard enough (multihead, for instance) but by and
large it's a situation that you can avoid.
> What if we throw an in-kernel VGA driver into the mix? But I guess
> Jon has asked all these questions before; I just didn't get warm
> fuzzies that there were safe, maintainable answers.
This probably isn't the right long-term answer, but the right long-term
answer is going to be a very long time away. It's an improvement over
what we have now. I certainly don't intend to leave vbetool relying on
it - of course, the "right" answer is for graphics drivers to know how
to program cards from scratch so we can get rid of vbetool altogether,
but I'll probably be more concerned about getting my flying car to meet
new emission standards than I will be by graphics cards at that stage.
--
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org
^ permalink raw reply
* Re: Is there a way....
From: Pascal Hambourg @ 2006-05-04 19:40 UTC (permalink / raw)
To: netfilter
In-Reply-To: <Pine.LNX.4.58.0604301836350.26623@linux.dpsims.com>
Hi,
David Sims wrote :
>
> I want to use Linux to do NAT between some 192.168.x.x addresses
> in a routed network on one side and a single 10.0.0.x/24 on the other
> side. I want to do one-to-one NAT but in a dynamic way... such that a
> calling address is NATed into the next available 10.0.0.x/24.... in a
> round robin sort of way... IS there a way to do this using NETFILTER??
> If not NETFILTER, then how??
>
> This sort of thing is common in many-to-one NAT (port-address
> translation)... but I need each call to come from a separate NATed IP
> address to support my application (TN3270 session)... It's OK to reuse
> addresses after a call (session) is complete, but each session needs to
> come from it's own fixed (for the duration of the session) IP address....
If by "call" you mean a single TCP connection or UDP flow, maybe you
could use the standard SNAT target :
iptables -t nat -A POSTROUTING <matches...> \
-j SNAT --to $ip_range_start-$ip_range_end
The first connection will be SNATed with $ip_range_start, the next one
$ip_range+1 and so on until $ip_range_end, then $ip_range_start again in
a round-robin way (even if it is already used). You must ensure that
there will never be more simultaneous connections than the number of
available addresses in the SNAT address range. Note that consecutive
connections from the same source address will be SNATed with different
addresses.
^ permalink raw reply
* [PATCH] cg-admin-rewritehist: Seed the commit map with the parents specified with -r.
From: Johannes Sixt @ 2006-05-04 19:36 UTC (permalink / raw)
To: git, Petr Baudis
When the first commit is manufactured, its parents are looked up in the
commit map. However, without this patch the map is always empty at that time.
If the entire history is rewritten, this is no problem because the first
commit does not have any parents anyway. However, if -r is used to constrain
rewriting to only part of the history, this first commit is manufactured
incorrectly without parents because 'cat' fails.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I'm posting this again, because I haven't received any feedback nor has
the patch been applied.
cg-admin-rewritehist | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
977fc81815877a1e72040355b221fe8d62593eb7
diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
index 9fa4c2a..7dd83cf 100755
--- a/cg-admin-rewritehist
+++ b/cg-admin-rewritehist
@@ -141,6 +141,7 @@ _git_requires_root=1
tempdir=.git-rewrite
startrev=
+startrevparents=
filter_env=
filter_tree=
filter_index=
@@ -152,6 +153,7 @@ while optparse; do
tempdir="$OPTARG"
elif optparse -r=; then
startrev="^$OPTARG^ $OPTARG $startrev"
+ startrevparents="$OPTARG^ $startrevparents"
elif optparse --env-filter=; then
filter_env="$OPTARG"
elif optparse --tree-filter=; then
@@ -186,6 +188,12 @@ ret=0
mkdir ../map # map old->new commit ids for rewriting parents
+# seed with identity mappings for the parents where we start off
+for commit in $startrevparents; do
+ commit="$(git-rev-parse $commit)"
+ echo $commit > ../map/$commit
+done
+
git-rev-list --topo-order HEAD $startrev | tac >../revs
commits=$(cat ../revs | wc -l)
--
1.3.1.gaa6b
^ permalink raw reply related
* [PATCH] cg-admin-rewritehist: fix reappearing files with --filter-tree.
From: Johannes Sixt @ 2006-05-04 19:36 UTC (permalink / raw)
To: git, Petr Baudis
With --filter-tree a working copy is checked out for each commit.
However, if a file is removed by a commit, the file is _not_ removed
from the working copy by git-checkout-index. This must be done explicitly,
otherwise the file becomes added back again.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I'm posting this again, because I haven't received any feedback nor has
the patch been applied.
cg-admin-rewritehist | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
26bb71a2d3d583d9eee10f4e950ff1b7d400e975
diff --git a/cg-admin-rewritehist b/cg-admin-rewritehist
index 7dd83cf..13ffb5d 100755
--- a/cg-admin-rewritehist
+++ b/cg-admin-rewritehist
@@ -213,10 +213,13 @@ while read commit; do
if [ "$filter_tree" ]; then
git-checkout-index -f -u -a
+ # files that $commit removed are now still in the working tree;
+ # remove them, else they would be added again
+ git-ls-files -z --others | xargs -0 rm -f
eval "$filter_tree"
git-diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git-update-index --add --replace --remove
- git-ls-files --others | tr '\n' '\0' | \
+ git-ls-files -z --others | \
xargs -0 git-update-index --add --replace --remove
fi
--
1.3.1.gaa6b
^ permalink raw reply related
* [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var
From: Tim Bird @ 2006-05-04 19:35 UTC (permalink / raw)
To: linux-mips
The following patch allows to build using CROSS_COMPILE from the environment.
I have an automated system which works like this, but it chokes on MIPS when
I use it with (albeit non-standard-named) cross-compiler tools. An easy
workaround I'm using is to put CROSS_COMPILE on the make command line, but it would
be nice to use the definition already in the environment when I work
manually in the system.
For past discussion of this see:
http://www.linux-mips.org/archives/linux-mips/2003-02/msg00196.html
I'm not sure why the change didn't make it in back in 2003, but
if the complaint was about the use of "?=", that seems to be in use
other places, and fairly standard now.
For example, from the top level kernel Makefile:
ARCH ?= $(SUBARCH)
CROSS_COMPILE ?=
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
---
--- alp-linux.orig/arch/mips/Makefile 2006-05-04 12:22:17.000000000 -0700
+++ alp-linux/arch/mips/Makefile 2006-05-04 12:10:22.000000000 -0700
@@ -49,7 +49,7 @@ UTS_MACHINE := mips64
endif
ifdef CONFIG_CROSSCOMPILE
-CROSS_COMPILE = $(tool-prefix)
+CROSS_COMPILE ?= $(tool-prefix)
endif
CHECKFLAGS-y += -D__linux__ -D__mips__ \
^ permalink raw reply
* Re: [PATCH] bcm43xx-d80211: proper implementation of virtual interface support
From: Marcus Better @ 2006-05-04 19:26 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060502132037.059a7cb2@griffin.suse.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jiri Benc wrote:
> This is unnecessary. AFAIK bcm43xx hardware doesn't support more than one
> interface at a time (not counting monitor interfaces as those are somewhat
> special).
I wonder what exactly is causing this limitation? Why isn't it just a matter
of software support?
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEWlUrXjXn6TzcAQkRAoa6AJ97kI8F7Q42orjNQC6HBIXwj3I/DwCgux18
RBkhEcOFBDtQGEHFq2eMxKU=
=3WoL
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Bjorn Helgaas @ 2006-05-04 19:26 UTC (permalink / raw)
To: Arjan van de Ven
Cc: linux-pci, Dave Airlie, Andrew Morton, greg, linux-kernel, pjones
In-Reply-To: <445A51F1.9040500@linux.intel.com>
On Thursday 04 May 2006 13:11, Arjan van de Ven wrote:
> Bjorn Helgaas wrote:
> > On Saturday 29 April 2006 03:04, Dave Airlie wrote:
> >>> This patch adds an "enable" sysfs attribute to each PCI device. When read it
> >>> shows the "enabled-ness" of the device, but you can write a "0" into it to
> >>> disable a device, and a "1" to enable it.
> >>>
> >>> This later is needed for X and other cases where userspace wants to enable
> >>> the BARs on a device (typical example: to run the video bios on a secundary
> >>> head). Right now X does all this "by hand" via bitbanging, that's just evil.
> >>> This allows X to no longer do that but to just let the kernel do this.
> >
> > I'm all in favor of cleaning up X. But making the X code prettier without
> > changing the underlying issues of claiming and sharing resources doesn't
> > help much. In fact, I suspect the ultimate plan for X does not involve
> > an "enable" attribute in sysfs, so this may just introduce ABI cruft that
> > will be difficult to remove later.
>
> it goes well beyond X. Things like vbetool need this too to get to the content
> of the rom for example. There are several other such cases...
There's already a "rom" file in sysfs. Could vbetool and friends
use that?
How do vbetool and X coordinate their usage of "enable"? What if we
throw an in-kernel VGA driver into the mix? But I guess Jon has asked
all these questions before; I just didn't get warm fuzzies that there
were safe, maintainable answers.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.