[PATCH] mmaper_kern.c fixes [buffer overruns]
* copy_from_user() can fail; ->write() must check its return
value.
* severe buffer overruns both in ->read() and ->write() - lseek
to the end (i.e. to mmapper_size) and
if(count + *ppos > mmapper_size)
count = count + *ppos - mmapper_size;
will do absolutely nothing. Then it will call
copy_to_user(buf,_buf[*ppos],count);
with obvious results (similar for ->write()).
Fixed by turning read to simple_read_from_buffer() and by doing
normal limiting of count in ->write().
* gratitious lock_kernel() in ->mmap() - it's useless there.
* lots of gratitious includes.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-base/arch/um/drivers/mmapper_kern.c
current/arch/um/drivers/mmapper_kern.c
--- RC13-rc7-base/arch/um/drivers/mmapper_kern.c2005-06-17
15:48:29.0 -0400
+++ current/arch/um/drivers/mmapper_kern.c 2005-08-27 01:25:20.0
-0400
@@ -9,19 +9,11 @@
*
*/
-#include
-#include
-#include
-#include
+#include
#include
#include
-#include
-#include
-#include
#include
#include
-#include
-#include
#include "mem_user.h"
#include "user_util.h"
@@ -31,35 +23,22 @@
static char *v_buf = NULL;
static ssize_t
-mmapper_read(struct file *file, char *buf, size_t count, loff_t *ppos)
+mmapper_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
- if(*ppos > mmapper_size)
- return -EINVAL;
-
- if(count + *ppos > mmapper_size)
- count = count + *ppos - mmapper_size;
-
- if(count < 0)
- return -EINVAL;
-
- copy_to_user(buf,_buf[*ppos],count);
-
- return count;
+ return simple_read_from_buffer(buf, count, ppos, v_buf, mmapper_size);
}
static ssize_t
-mmapper_write(struct file *file, const char *buf, size_t count, loff_t *ppos)
+mmapper_write(struct file *file, const char __user *buf, size_t count, loff_t
*ppos)
{
- if(*ppos > mmapper_size)
+ if (*ppos > mmapper_size)
return -EINVAL;
- if(count + *ppos > mmapper_size)
- count = count + *ppos - mmapper_size;
-
- if(count < 0)
- return -EINVAL;
+ if (count > mmapper_size - *ppos)
+ count = mmapper_size - *ppos;
- copy_from_user(_buf[*ppos],buf,count);
+ if (copy_from_user(_buf[*ppos], buf, count))
+ return -EFAULT;
return count;
}
@@ -77,7 +56,6 @@
int ret = -EINVAL;
int size;
- lock_kernel();
if (vma->vm_pgoff != 0)
goto out;
@@ -92,7 +70,6 @@
goto out;
ret = 0;
out:
- unlock_kernel();
return ret;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
Em Fri, Aug 26, 2005 at 09:06:22PM -0700, Mitchell Blank Jr escreveu: > Andi Kleen wrote: > > - it doesn't seem to help that much on modern CPUs with good > > branch prediction and big icaches anyways. > > Really? I would think that as pipelines get deeper (although that trend > seems to have stopped, thankfully) and Icache-miss penalties get relatively > larger we'd see unlikely() becoming MORE of a benefit, not less. Storing > the used part of a "hot" function in 1 Icacheline instead of 4 seems like > an obvious win. > > Personally I've never found unlikely() to be ugly; if anything I think > it serves as a nice little human-readable comment about whats going on > in the control-flow. I guess I'm in the minority on that one, though. Hey, even if unlikely was: #define unlikely(x) (x) I'd find it useful :-) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
Em Fri, Aug 26, 2005 at 07:37:59PM -0400, Robert Love escreveu: > On Fri, 2005-08-26 at 17:44 -0500, Dmitry Torokhov wrote: > > > Is this function used in a hot path to warrant using "unlikely"? There > > are to many "unlikely" in the code for my taste. > > unlikely() can result in better, smaller, faster code. and it acts as a > nice directive to programmers reading the code. Agreed, keep them :-) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops with 2.6.13-rc6-mm2 and USB mouse
Hi there. I just got myself a new USB mouse and it seems that kernel 2.6.13-rc6-mm2 (which is the kernel I am using right now) doesn't like it. I get an Oops (attached to this message) and it suddenly stops working. I still don't know if this is reproducible or if it occurs with other kernels. Please let me know whatever information you'd like to have to chase this bug. Thank you very much, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ Linux version 2.6.13-rc6-mm2-1 ([EMAIL PROTECTED]) (gcc version 4.0.1 (Debian 4.0.1-2)) #1 Thu Aug 25 03:18:21 BRT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009e800 (usable) BIOS-e820: 0009e800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 17fec000 (usable) BIOS-e820: 17fec000 - 17fef000 (ACPI data) BIOS-e820: 17fef000 - 17fff000 (reserved) BIOS-e820: 17fff000 - 1800 (ACPI NVS) BIOS-e820: - 0001 (reserved) 383MB LOWMEM available. On node 0, present: 98284, spanned: 98284 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 94188 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 ASUS ) @ 0x000f6a90 ACPI: RSDT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x17fec000 ACPI: FADT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x17fec080 ACPI: BOOT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x17fec040 ACPI: DSDT (v001 ASUS A7V 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0xe408 Allocating PCI resources starting at 1800 (gap: 1800:e7ff) Built 1 zonelists Initializing CPU#0 Kernel command line: auto BOOT_IMAGE=Linux root=2103 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1109.938 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 386332k/393136k available (1700k kernel code, 6264k reserved, 637k data, 128k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2221.23 BogoMIPS (lpj=1110619) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383f9ff c1c3f9ff CPU: After vendor identify, caps: 0383f9ff c1c3f9ff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After all inits, caps: 0383f9ff c1c3f9ff 0020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: AMD Duron(tm) Processor stepping 00 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0e20) softlockup thread 0 started up. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1 PCI: Using configuration type 1 ACPI: Subsystem revision 20050729 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 Disabling VIA memory write queue (PCI ID 0305, rev 02): [55] 89 & 1f -> 09 Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Bridge: :00:01.0 IO window: disabled. MEM window: dc80-dddf PREFETCH window: ddf0-dfff PCI: Setting latency timer of device :00:01.0 to 64 Simple Boot Flag at 0x3a set to 0x80 Machine check exception polling timer started. apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. Initializing Cryptographic API lp: driver loaded but no devices found Real Time Clock Driver v1.12 Non-volatile memory driver v1.2 Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Twister-K/KT133x/KM133 chipset agpgart: AGP aperture is 128M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI Interrupt
Re: Linux-2.6.13-rc7
On Aug 25 2005, at 16:04, Erik Mouw was caught saying: > On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > > I really wanted to release a 2.6.13, but there's been enough changes > > while we've been waiting for other issues to resolve that I think it's > > best to do a -rc7 first. > > There's something strange going on with either ACPI or cpufreq. When Is there ever anything not strange going on with ACPI. :p /me goes back to beer. ~Deepak -- Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net Even a stopped clock gives the right time twice a day. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 03:21:27AM +, Kent Robotti wrote: > The purpose of the patch is to overmount ramfs/rootfs with tmpfs before > the compressed cpio archive is unpacked and /init is run. yes and no there are people who want the overmount even without cpio decompression > But, it's only needed because the current initramfs implementation > doesn't offer tmpfs as an option. tmpfs isn't initialized early enough; i've hacked around this but a cleaner solution is needed > /init could just be a symbolic link to /sbin/init, or it could be > some other executable (shell script etc.), but there would be no > need to pivot or move root. pivot is evil, it probably should be depricated - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
Andi Kleen wrote: > - it doesn't seem to help that much on modern CPUs with good > branch prediction and big icaches anyways. Really? I would think that as pipelines get deeper (although that trend seems to have stopped, thankfully) and Icache-miss penalties get relatively larger we'd see unlikely() becoming MORE of a benefit, not less. Storing the used part of a "hot" function in 1 Icacheline instead of 4 seems like an obvious win. Personally I've never found unlikely() to be ugly; if anything I think it serves as a nice little human-readable comment about whats going on in the control-flow. I guess I'm in the minority on that one, though. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH ISDN] Fix capifs bug in initialization error path.
This patch fixes a bug in the capifs initialization code, where the
filesystem is not unregistered if kern_mount() fails.
Please apply.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
capifs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
diff -purN -X dontdiff linux-2.6.13-mm2.o/drivers/isdn/capi/capifs.c
linux-2.6.13-mm2.x/drivers/isdn/capi/capifs.c
--- linux-2.6.13-mm2.o/drivers/isdn/capi/capifs.c 2005-03-02
02:37:50.0 -0500
+++ linux-2.6.13-mm2.x/drivers/isdn/capi/capifs.c 2005-08-26
23:35:50.0 -0400
@@ -191,8 +191,10 @@ static int __init capifs_init(void)
err = register_filesystem(_fs_type);
if (!err) {
capifs_mnt = kern_mount(_fs_type);
- if (IS_ERR(capifs_mnt))
+ if (IS_ERR(capifs_mnt)) {
err = PTR_ERR(capifs_mnt);
+ unregister_filesystem(_fs_type);
+ }
}
if (!err)
printk(KERN_NOTICE "capifs: Rev %s\n", rev);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Richard Henderson wrote:
> Because I use "extern inline" in the proper way. That is, I have both
> inline and out-of-line versions of some routines.
Is there any reason not to just make the out-of-line version explicit?
i.e.:
/* in some .h file: */
static /*(always!)*/inline int my_func(void)
{
return FOO;
}
extern int OOL_my_func(void);
/* in some .c file: */
int OOL_my_func(void)
{
return my_func();
}
It's a little ugly but there really aren't that many cases of this, right?
Or is this just the principal of the thing? :-)
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc7
Hello, It crashes for me right off the bat: Here is the kernel output: --- Filesystem type is ext2fs, partition type 0x83 kernel /boot/vmlinuz-2.6.13-rc7-git1 root=/dev/hda3 ro console=ttyS0,115200n8 CONSOLE=/dev/ttyS0 [Linux-bzImage, setup=0x1200, size=0x1fe4fa] savedefault boot Linux version 2.6.13-rc7-git1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)) #1 SMP Fri Aug 26 15:18:21 EDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 2fff (usable) BIOS-e820: 2fff - 2fff3000 (ACPI NVS) BIOS-e820: 2fff3000 - 3000 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) 767MB LOWMEM available. found SMP MP-table at 000f5fd0 DMI 2.2 present. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 17 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:8 APIC version 17 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 3000:cec0) Built 1 zonelists Kernel command line: root=/dev/hda3 ro console=ttyS0,115200n8 CONSOLE=/dev/ttyS0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 868.668 MHz processor. Using tsc for high-res timesource 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: 774032k/786368k available (2926k kernel code, 11824k reserved, 1174k data, 220k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1739.92 BogoMIPS (lpj=8699649) Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Coppermine) stepping 0a Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay using timer specific routine.. 1737.36 BogoMIPS (lpj=8686805) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Coppermine) stepping 0a Total of 2 processors activated (3477.29 BogoMIPS). ENABLING IO-APIC IRQs .TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfb2c0, last bus=1 PCI: Using configuration type 1 mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs. mtrr: corrected configuration. ACPI: Subsystem revision 20050408 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 *7 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 10 devices SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Bridge: :00:01.0 IO window: a000-afff MEM window: d000-d3ff PREFETCH window: d400-d5ff Machine check exception polling timer started. audit: initializing netlink socket (disabled) audit(1125070419.160:1): initialized Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). Initializing Cryptographic API PCI: Enabling Via external APIC routing ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Sleep Button (CM) [SLPB] ACPI: CPU0 (power states: C1[C1]) ACPI: CPU1 (power states: C1[C1]) lp: driver loaded but no devices found Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Apollo Pro 133 chipset agpgart: AGP aperture is 256M @ 0xc000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :01:00.0[A] -> GSI 16
No DMA with ASUS W3030V - ahci/ata_piix issue? Workarounds?
Greetings, I am having problems with DMA access on my laptops drives. My research so far indicates that this is likely to be an issue with the current state of ahci development. There are no BIOS options available for the IDE that are suggested in workarounds. Is there anything I can do to enable DMA for IDE drives, enable/disbale options in the kernel? Any help greatly appreciated. Kind regards, The laptop: ASUS W3030V. Kernel: 2.6.12-gentoo-sources-r9 lspci output: :00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) :00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03) :00:1b.0 Class 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) :00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) :00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) :00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) :00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04) :00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04) :00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) :00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) :00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04) :00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) :00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04) :01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility X600] :03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) :03:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3) :03:01.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08) :03:01.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17) :03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 08) :03:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05) lsmod output: Module Size Used by michael_mic 2368 2 arc41600 2 ieee80211_crypt_tkip 9600 2 md5 3712 1 ipv6 244608 13 eth139417224 0 pcmcia 21576 2 ohci_hcd 33284 0 psmouse28804 0 rtc10872 0 ipw2200 172552 0 ieee80211 44548 1 ipw2200 ieee80211_crypt 4868 3 ieee80211_crypt_tkip,ipw2200,ieee80211 ohci1394 32052 0 ieee1394 291064 2 eth1394,ohci1394 yenta_socket 20296 1 rsrc_nonstatic 9792 1 yenta_socket pcmcia_core42504 3 pcmcia,yenta_socket,rsrc_nonstatic skge 33424 0 radeonfb 88128 0 i2c_algo_bit8520 1 radeonfb i2c_i8017564 0 ehci_hcd 43592 0 uhci_hcd 30284 0 evdev 7552 0 snd_seq50128 0 snd_seq_device 6860 1 snd_seq usbcore 118780 4 ohci_hcd,ehci_hcd,uhci_hcd ntfs 211252 1 isofs 32184 0 zlib_inflate 17600 1 isofs ide_cd 37956 0 cdrom 38432 1 ide_cd cpufreq_userspace 3548 0 cpufreq_powersave 1472 0 cpufreq_ondemand5276 1 cpufreq_conservative 6308 0 snd_hda_intel 12576 1 snd_hda_codec 56448 1 snd_hda_intel snd_pcm84296 2 snd_hda_intel,snd_hda_codec snd_timer 21892 2 snd_seq,snd_pcm snd45924 8 snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer soundcore 7584 1 snd snd_page_alloc 7620 2 snd_hda_intel,snd_pcm video 13892 0 thermal10504 0 fan 3204 0 battery 7556 0 acpi_cpufreq4868 1 freq_table 3524 1 acpi_cpufreq processor 18228 2 thermal,acpi_cpufreq ac 3396 0 asus_acpi 9556 0 radeon 76224 0 drm61012 1 radeon intel_agp 20444 1 agpgart29512 2 drm,intel_agp ata_piix7364 0 libata 42436 1 ata_piix scsi_mod 85064 1 libata -- Marek W == (2b | !2b) == Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe
Re: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 05:40:45PM -0700, Chris Wedgwood wrote: > On Fri, Aug 26, 2005 at 09:12:31PM +, Kent Robotti wrote: > > > Ideally, I don't know why you would want to overmount unless the > > kernel detects an initramfs. > > because the rootfs doesn't work the way you think it does. there are > a number of complex and sublte issues > > if you look at the patch it does quite a lot of work because of this The purpose of the patch is to overmount ramfs/rootfs with tmpfs before the compressed cpio archive is unpacked and /init is run. If there's no compressed cpio archive there's no need to overmount with tmpfs, because we're not doing initramfs. That's my understanding of it. > > I know the patch is just a quick and simple way to use tmpfs for > > initramfs, and it seems to work. > > as previously mentioned, there are a number of subtle issues to > consider that are non-obvious > > people are free to do their own patches but the rootfs does not always > work the way you expect it to > > > But, it would be nice if were cleaned up for that less than one > > percent. > > given most people don't need/want this i don't see that happening. > once klibc is merged i might go over this again but until then it > doesn't seem useful Even as it is I find it useful. But, it's only needed because the current initramfs implementation doesn't offer tmpfs as an option. If you had the option of using tmpfs as the initramfs you wouldn't need to do pivot-root or mount-move etc., because you would already be where you wanted. /init could just be a symbolic link to /sbin/init, or it could be some other executable (shell script etc.), but there would be no need to pivot or move root. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sym53c8xx_2 is flooding my syslog ...
... with the following message: Aug 21 04:53:28 mudlark kernel: ..<6>sd 0:0:6:0: phase change 6-7 [EMAIL PROTECTED] resid=7. every 2 seconds. Since the problem being reported seems to have no effect on the operation of the scsi devices is it really necessary to report it so often? Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
From: Andi Kleen <[EMAIL PROTECTED]> Date: 27 Aug 2005 04:34:07 +0200 > "David S. Miller" <[EMAIL PROTECTED]> writes: > > > From: Alexey Dobriyan <[EMAIL PROTECTED]> > > Date: Sat, 27 Aug 2005 02:58:48 +0400 > > > > > What's the point of having unlikely() attached to every possible if ()? > > > > If can result in smaller code, for one thing, even if it > > isn't a performance critical path. > > Really? At least on x86 it tends to generate bigger code when > block reordering is enabled because a jump forward and a jump > backward and a possible label alignment are bigger than just > a single jump forward. In the cases I've studied on sparc64 it keeps gcc from doing basic block replication in the unlikely paths. I've only checked gcc-3.4 and earlier, gcc-4.x is just big bloated useless garbage and should be avoided for a couple of years. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
"David S. Miller" <[EMAIL PROTECTED]> writes: > From: Alexey Dobriyan <[EMAIL PROTECTED]> > Date: Sat, 27 Aug 2005 02:58:48 +0400 > > > What's the point of having unlikely() attached to every possible if ()? > > If can result in smaller code, for one thing, even if it > isn't a performance critical path. Really? At least on x86 it tends to generate bigger code when block reordering is enabled because a jump forward and a jump backward and a possible label alignment are bigger than just a single jump forward. But then it doesn't make that much difference because the compiler does it on its own for every block. On x86-64 I keep it disabled because: - it generates bigger code - it makes the assembly code unreadable - it doesn't seem to help that much on modern CPUs with good branch prediction and big icaches anyways. -Andi (who originally introduced likely/unlikely, but regrets it these days because it's far overused and makes code uglier everywhere) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] acpi-cpufreq: Remove P-state read after a P-state write in normal path
applied to acpi test tree.
thanks,
-Len
>-Original Message-
>From: Venkatesh Pallipadi [mailto:[EMAIL PROTECTED]
>Sent: Friday, August 26, 2005 8:11 PM
>To: Andrew Morton
>Cc: linux-kernel; Brown, Len
>Subject: [PATCH] acpi-cpufreq: Remove P-state read after a
>P-state write in normal path
>
>
>
>Remove P-state read status after a P-state write in normal case. As
>that operation is expensive. There are no known failures of a
>set and we can
>assume success in the common case. acpi_pstate_strict
>parameter can be used
>to force it back on any systems that is known to have errors.
>
>Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
>
>Index: linux-2.6.12/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>===
>---
>linux-2.6.12.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>2005-08-16 09:41:52.977456128 -0700
>+++ linux-2.6.12/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>2005-08-17 13:32:33.034651136 -0700
>@@ -31,6 +31,7 @@
> #include
> #include
> #include
>+#include
> #include
> #include
> #include
>@@ -57,6 +58,8 @@
>
> static struct cpufreq_driver acpi_cpufreq_driver;
>
>+static unsigned int acpi_pstate_strict;
>+
> static int
> acpi_processor_write_port(
> u16 port,
>@@ -163,34 +166,44 @@
> }
>
> /*
>- * Then we read the 'status_register' and compare the
>value with the
>- * target state's 'status' to make sure the transition
>was successful.
>- * Note that we'll poll for up to 1ms (100 cycles of
>10us) before
>- * giving up.
>+ * Assume the write went through when
>acpi_pstate_strict is not used.
>+ * As read status_register is an expensive operation and there
>+ * are no specific error cases where an IO port write will fail.
>*/
>-
>- port = data->acpi_data.status_register.address;
>- bit_width = data->acpi_data.status_register.bit_width;
>-
>- dprintk("Looking for 0x%08x from port 0x%04x\n",
>- (u32) data->acpi_data.states[state].status, port);
>-
>- for (i=0; i<100; i++) {
>- ret = acpi_processor_read_port(port, bit_width, );
>- if (ret) {
>- dprintk("Invalid port width 0x%04x\n",
>bit_width);
>- retval = ret;
>- goto migrate_end;
>+ if (acpi_pstate_strict) {
>+ /* Then we read the 'status_register' and
>compare the value
>+ * with the target state's 'status' to make sure the
>+ * transition was successful.
>+ * Note that we'll poll for up to 1ms (100
>cycles of 10us)
>+ * before giving up.
>+ */
>+
>+ port = data->acpi_data.status_register.address;
>+ bit_width = data->acpi_data.status_register.bit_width;
>+
>+ dprintk("Looking for 0x%08x from port 0x%04x\n",
>+ (u32)
>data->acpi_data.states[state].status, port);
>+
>+ for (i=0; i<100; i++) {
>+ ret = acpi_processor_read_port(port,
>bit_width, );
>+ if (ret) {
>+ dprintk("Invalid port width
>0x%04x\n", bit_width);
>+ retval = ret;
>+ goto migrate_end;
>+ }
>+ if (value == (u32)
>data->acpi_data.states[state].status)
>+ break;
>+ udelay(10);
> }
>- if (value == (u32) data->acpi_data.states[state].status)
>- break;
>- udelay(10);
>+ } else {
>+ i = 0;
>+ value = (u32) data->acpi_data.states[state].status;
> }
>
> /* notify cpufreq */
> cpufreq_notify_transition(_freqs, CPUFREQ_POSTCHANGE);
>
>- if (value != (u32) data->acpi_data.states[state].status) {
>+ if (unlikely(value != (u32)
>data->acpi_data.states[state].status)) {
> unsigned int tmp = cpufreq_freqs.new;
> cpufreq_freqs.new = cpufreq_freqs.old;
> cpufreq_freqs.old = tmp;
>@@ -537,6 +550,8 @@
> return;
> }
>
>+module_param(acpi_pstate_strict, uint, 0644);
>+MODULE_PARM_DESC(acpi_pstate_strict, "value 0 or non-zero.
>non-zero -> strict ACPI checks are performed during frequency
>changes.");
>
> late_initcall(acpi_cpufreq_init);
> module_exit(acpi_cpufreq_exit);
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] [PATCH] sg.c: fix a memory leak in devices seq_file implementation (2nd)
On Fri, 2005-08-26 at 12:18 -0700, Chris Wright wrote: > plain text document attachment (fix-memory-leak-in-sg.c- > seq_file.patch) > -stable review patch. If anyone has any objections, please let us know. Looks fine to me. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7 qla2xxx unaligned accesses
On Thu, 25 Aug 2005, Keith Owens wrote:
> On Wed, 24 Aug 2005 11:22:52 -0700,
> Andrew Vasquez <[EMAIL PROTECTED]> wrote:
> >On Wed, 24 Aug 2005, Keith Owens wrote:
> >
> >> 2.6.13-rc7 + kdb on ia64. The qla2xxx drivers are getting unaligned
> >> accesses at startup.
> >>
> >> qla2300 :01:02.0: Found an ISP2312, irq 66, iobase 0xc0080f30
> >> qla2300 :01:02.0: Configuring PCI space...
> >> PCI: slot :01:02.0 has incorrect PCI cache line size of 0 bytes,
> >> correcting to 128
> >> qla2300 :01:02.0: Configure NVRAM parameters...
> >> qla2300 :01:02.0: Verifying loaded RISC code...
> >> qla2300 :01:02.0: Waiting for LIP to complete...
> >> qla2300 :01:02.0: Cable is unplugged...
> >> scsi1 : qla2xxx
> >> kernel unaligned access to 0xe0300667800c, ip=0xa001005cd0b1
> >
> >Yes, I have a fix for this in my patch-queue. I'll attach it here for
> >reference. I'll forward onto linux-scsi post 2.6.13.
> >
> >--
> >av
> >
> >---
> >
> >On some platforms the hard-casting of the 8 byte node_name
> >and port_name arrays to an u64 would cause unaligned-access
> >warnings. Generalize the conversions with consistent
> >shifting of WWN bytes.
> >
> >Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]>
> >---
> >
> > drivers/scsi/qla2xxx/qla_attr.c | 27 +--
> > 1 files changed, 17 insertions(+), 10 deletions(-)
> >
> >24e16c86578498fd71a3e33bebbd8be7323a03c6
> >diff --git a/drivers/scsi/qla2xxx/qla_attr.c
> >b/drivers/scsi/qla2xxx/qla_attr.c
> >--- a/drivers/scsi/qla2xxx/qla_attr.c
> >+++ b/drivers/scsi/qla2xxx/qla_attr.c
> >@@ -345,6 +345,15 @@ struct class_device_attribute *qla2x00_h
> >
> > /* Host attributes. */
> >
> >+static u64
> >+wwn_to_u64(uint8_t *wwn)
> >+{
> >+return (u64)wwn[0] << 56 | (u64)wwn[1] << 48 |
> >+(u64)wwn[2] << 40 | (u64)wwn[3] << 32 |
> >+(u64)wwn[4] << 24 | (u64)wwn[5] << 16 |
> >+(u64)wwn[6] << 8 | (u64)wwn[7];
> >+}
> >+
>
> Any reason you defined your own function instead of using the standard
> get_unaligned()?
I was unaware there was even such a helper. Anyway, the wwn_to_u64()
function adds another benefit -- clarity, were converting a 8 byte
WWN array to it's endian-agnosting 64bit value. I suppose, we could
make it inline.
--
AV
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-rt1
On Tue, Aug 16, 2005 at 02:32:01PM +0200, Michal Schmidt wrote: > Ingo Molnar wrote: > >i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the > >usual place: > > > > http://redhat.com/~mingo/realtime-preempt/ > > > >as the name already suggests, i've switched to a new, simplified naming > >scheme, which follows the usual naming convention of trees tracking the > >mainline kernel. The numbering will be restarted for every new upstream > >kernel the -RT tree is merged to. > > Great! With this naming scheme it is easy to teach Matt Mackall's > ketchup script about the -RT tree. > The modified ketchup script can be downloaded from: > http://www.uamt.feec.vutbr.cz/rizeni/pom/ketchup-0.9+rt > > Matt, would you release a new ketchup version with this support for > Ingo's tree? Thanks. I've put this in my version, which is now exported as a Mercurial repo at: http://selenic.com/repo/ketchup This version also has -git support, finally. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: HPET drift question
Yes. Looks like "ti->drift = HPET_DRIFT;" is right here. However, I would like to double check this with Bob. Thanks, Venki >-Original Message- >From: Alex Williamson [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 25, 2005 8:17 AM >To: Pallipadi, Venkatesh >Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org >Subject: HPET drift question > >Hi Venki, > > I'm confused by the calculation of the drift value in the hpet >driver. The specs defines the recommended minimum hardware >implementation is a frequency drift of 0.05% or 500ppm. However, the >drift passed in when registering with the time interpolator is: > >ti->drift = ti->frequency * HPET_DRIFT / 100; > >Isn't that absolute number of ticks per second drift? The time >interpolator defines the drift in parts per million. Shouldn't this >simply be: > >ti->drift = HPET_DRIFT; > >The current code seems to greatly penalize any hpet timer with greater >than a 1MHz frequency. Thanks, > > Alex > >-- >Alex Williamson HP Linux & Open Source Lab > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building the kernel with Cygwin
On Thu, Aug 25, 2005 at 02:45:51PM -0400, Christopher Faylor wrote: >On Thu, Aug 25, 2005 at 01:05:24PM -0400, linux-os (Dick Johnson) wrote: >>On Thu, 25 Aug 2005, Chris du Quesnay wrote: >>>The scripts/basic directory contains a fixdep.exe after the make is >>>run. There is no fixdep file. I tried renaming the fixdep.exe to >>>fixdep, but that also resulted in the same make error. >> >>Ah yes! The Makefile will not execute 'fixdep.exe` it executes 'fixdep' >>--hard coded. I don't know how well cygwin emulates a Unix >>environment, but maybe you can use an alias??? .. Like... alias >>fixdep='fixdep.exe' > >How about a symlink? > >ln -s fixdep.exe fixdep FWIW, I've just built a linux kernel on my cygwin system using a ppc cross compiler. Here's roughly what I did (this is not verbatim what I did but it should serve as a rough guide): c:\>c:\cygwin\bin\bash bash$ export PATH=/bin:$PATH bash$ cd /tmp bash$ wget http://cygwin.com/snapshots/cygwin-inst-20050826.tar.bz2 bash$ wget http://cygwin.com/snapshots/cygwin1-20050826.dll.bz2 bash$ wget ftp://ftp.kernel.org:/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2 bash$ bzip2 -d cygwin1-20050826.dll.bz2 bash$ cd / bash$ # expect some errors about being unable to overwrite bash$ # cygwin1.dll below bash$ tar xjf /tmp/cygwin-inst-20050826.tar.bz2 bash$ # exit from the running cygwin process so that the cygwin DLL can bash$ # be overwritten bash$ exit c:\>copy c:\cygwin\tmp\cygwin1-20050826.dll c:\cygwin\bin\cygwin1.dll c:\>c:\cygwin\bin\bash bash$ export PATH=/bin:/path-to-cross/compiler:$PATH bash$ mkdir /cygdrive/c/managed /managed bash$ mount -b -o managed c:/managed /managed bash$ cd /managed bash$ tar xjf /tmp/linux-2.6.12.tar.bz2 bash$ cd linux-2.6.12 bash$ make ARCH=ppc HOST_LOADLIBES=-lintl defconfig bash$ make ARCH=ppc CROSS_COMPILE=ppc-linux- Note that I have recently added the elf.h header files to cygwin so this should allow the kernel to be built without any addition steps. But, you need to download a cygwin snapshot to get this because the headers aren't part of the latest version of cygwin yet. You also need to specify HOST_LOADLIBES on the command line because it's required for cygwin. Using a "managed" mount also allows the creation of files with mixed case. I haven't yet checked that the kernel produced from these steps works but the make does seem to complete without error. cgf -- Christopher Faylor spammer? -> [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Use sg_init_one where appropriate
The same code as in sg_init_one can be found in a number of places, this
patch changes them to call the function instead.
Signed-off-by: David Härdeman <[EMAIL PROTECTED]>
---
crypto/hmac.c | 23 ++-
crypto/tcrypt.c | 29 -
drivers/md/dm-crypt.c | 11 ---
drivers/net/wireless/airo.c |5 ++---
drivers/scsi/arm/scsi.h |6 ++
drivers/scsi/libata-core.c| 10 ++
drivers/scsi/sg.c |5 ++---
drivers/usb/misc/usbtest.c|6 ++
include/linux/scatterlist.h |5 +++--
net/ipv6/addrconf.c |9 +++--
net/sunrpc/auth_gss/gss_krb5_crypto.c | 22 ++
11 files changed, 40 insertions(+), 91 deletions(-)
Index: linux-sginitone/include/linux/scatterlist.h
===
--- linux-sginitone.orig/include/linux/scatterlist.h2005-03-02
08:38:32.0 +0100
+++ linux-sginitone/include/linux/scatterlist.h 2005-08-27 00:20:53.0
+0200
@@ -1,8 +1,9 @@
#ifndef _LINUX_SCATTERLIST_H
#define _LINUX_SCATTERLIST_H
-static inline void sg_init_one(struct scatterlist *sg,
- u8 *buf, unsigned int buflen)
+static inline void sg_init_one(const struct scatterlist *sg,
+ const u8 *buf,
+ const unsigned int buflen)
{
memset(sg, 0, sizeof(*sg));
Index: linux-sginitone/crypto/hmac.c
===
--- linux-sginitone.orig/crypto/hmac.c 2005-03-02 08:38:09.0 +0100
+++ linux-sginitone/crypto/hmac.c 2005-08-27 00:32:26.0 +0200
@@ -19,17 +19,15 @@
#include
#include
#include
+#include
#include "internal.h"
static void hash_key(struct crypto_tfm *tfm, u8 *key, unsigned int keylen)
{
struct scatterlist tmp;
-
- tmp.page = virt_to_page(key);
- tmp.offset = offset_in_page(key);
- tmp.length = keylen;
+
+ sg_init_one(tmp, key, keylen);
crypto_digest_digest(tfm, , 1, key);
-
}
int crypto_alloc_hmac_block(struct crypto_tfm *tfm)
@@ -70,10 +68,7 @@
for (i = 0; i < crypto_tfm_alg_blocksize(tfm); i++)
ipad[i] ^= 0x36;
- tmp.page = virt_to_page(ipad);
- tmp.offset = offset_in_page(ipad);
- tmp.length = crypto_tfm_alg_blocksize(tfm);
-
+ sg_init_one(tmp, ipad, crypto_tfm_alg_blocksize(tfm));
crypto_digest_init(tfm);
crypto_digest_update(tfm, , 1);
}
@@ -104,17 +99,11 @@
for (i = 0; i < crypto_tfm_alg_blocksize(tfm); i++)
opad[i] ^= 0x5c;
- tmp.page = virt_to_page(opad);
- tmp.offset = offset_in_page(opad);
- tmp.length = crypto_tfm_alg_blocksize(tfm);
-
+ sg_init_one(tmp, opad, crypto_tfm_alg_blocksize(tfm));
crypto_digest_init(tfm);
crypto_digest_update(tfm, , 1);
- tmp.page = virt_to_page(out);
- tmp.offset = offset_in_page(out);
- tmp.length = crypto_tfm_alg_digestsize(tfm);
-
+ sg_init_one(tmp, out, crypto_tfm_alg_blocksize(tfm));
crypto_digest_update(tfm, , 1);
crypto_digest_final(tfm, out);
}
Index: linux-sginitone/crypto/tcrypt.c
===
--- linux-sginitone.orig/crypto/tcrypt.c2005-08-19 22:40:05.0
+0200
+++ linux-sginitone/crypto/tcrypt.c 2005-08-27 00:45:05.0 +0200
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -109,9 +110,7 @@
memset (result, 0, 64);
p = hash_tv[i].plaintext;
- sg[0].page = virt_to_page (p);
- sg[0].offset = offset_in_page (p);
- sg[0].length = hash_tv[i].psize;
+ sg_init_one([0], p, hash_tv[i].psize);
crypto_digest_init (tfm);
if (tfm->crt_u.digest.dit_setkey) {
@@ -146,9 +145,7 @@
hash_tv[i].tap[k]);
temp += hash_tv[i].tap[k];
p = [IDX[k]];
- sg[k].page = virt_to_page (p);
- sg[k].offset = offset_in_page (p);
- sg[k].length = hash_tv[i].tap[k];
+ sg_init_one([k], p, hash_tv[i].tap[k]);
}
crypto_digest_digest (tfm, sg, hash_tv[i].np, result);
@@ -203,9 +200,7 @@
p = hmac_tv[i].plaintext;
klen = hmac_tv[i].ksize;
- sg[0].page = virt_to_page(p);
- sg[0].offset = offset_in_page(p);
- sg[0].length = hmac_tv[i].psize;
+ sg_init_one([0], p,
Re: kgdb on EM64T
Wilkerson, Bryan P wrote: George Anzinger [mailto:[EMAIL PROTECTED] wrote: Well, I checked, it is "int $3". Why then the panic? If you try the boot with kgdb (i.e. wait) and the do: (gdb) disass gdb_interrupt What do you find at +75? Below is the console from the session it is interesting that gdb is not able to access the memory. I let it continue and then ctrl-c broke it later in the boot cycle and tried disass again with the same result. Feel free to flog me if this is stupid but I have just one EM64T machine (test) and I'm using a regular P4 machine as dev. I build the test kernel on the EM64T machine and then copy the updated sources, object files, and images via NFS to the dev machine. I believe I read in the kgdb doc that it was possible to use to different architecture machines for test and dev although there wasn't any information about how to do it. This is probably the source of the OS/ABI warning. I can probably get the mothership to send me another EM64T machine if need be. What you need is a cross development environment. Not having that, your gdb is likely not aware of how to talk to the hardware you are using. The cross develoment should cost a whole lot less than another machine. George -- vincent:/home/bwilkers/proj/linux-2.6.13-rc4-mm1 # gdb vmlinux GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 0x80503b50 in ?? () warning: no shared library support for this OS / ABI (gdb) disass gdb_interrupt Dump of assembler code for function gdb_interrupt: 0x80247009 : Cannot access memory at address 0x80247009 (gdb) c Continuing. Bootdata ok (command line is root=/dev/sda2 kgdb console=kgdb) Linux version 2.6.13-rc4-mm1-perfmon-em64t ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #43 SMP Sat Aug 27 15:56:14 MDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e6000 - 0010 (reserved) BIOS-e820: 0010 - 3fe2f800 (usable) BIOS-e820: 3fe2f800 - 3fe3f832 (ACPI NVS) BIOS-e820: 3ff1 - 3ff3 (reserved) BIOS-e820: 3ff3 - 3ff4 (ACPI data) BIOS-e820: 3ff4 - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fed13000 - fed1a000 (reserved) BIOS-e820: fed1c000 - feda (reserved) ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.
On Saturday 27 August 2005 01:05, Christoph Lameter wrote:
> On Fri, 26 Aug 2005, Rusty Lynch wrote:
> > Just to be sure everyone understands the overhead involved, kprobes only
> > registers a single notifier. If kprobes is disabled (CONFIG_KPROBES is
> > off) then the overhead on a page fault is the overhead to execute an
> > empty notifier chain.
>
> Its the overhead of using registers to pass parameters, performing a
> function call that does nothing etc. A waste of computing resources. All
> of that unconditionally in a performance critical execution path that
> is executed a gazillion times for an optional feature that I frankly
> find not useful at all and that is disabled by default.
In the old days notifier_call_chain used to be inline. Then someone looking
at code size out of lined it. Perhaps it should be inlined again or notifier.h
could supply a special faster inline version for time critical code.
Then it would be simple if (global_var != NULL) { ... } in the fast path.
In addition the call chain could be declared __read_mostly.
I suspect with these changes Christoph's concerns would go away, right?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radix-tree: Remove unnecessary indirections and clean up code
I was thinking about Nick's lockless pagecache patches and had a look at
radix-tree.c. At first I had some trouble with some of the way things
were done but after getting used to the style it became clear. However,
I'd like to have these things fixed so that others do not get tripped up
too.
---
[PATCH] radix-tree: Remove unnecessary indirections and clean up code
- There is frequent use of indirections in the radix code. This patch
removes those indirections, makes the code more readable and allows
the compilers to generate better code.
- Removing indirections allows the removal of several casts.
- Removing indirections allows the reduction of the radix_tree_path
size from 3 to 2 words.
- Use pathp-> consistently.
- Remove unnecessary tmp variable in radix_tree_insert
- Separate the upper layer processing from the lowest layer in __lookup()
in order to make it easier to understand what is going on and allow
compilers to generate better code for the loop.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc7/lib/radix-tree.c
===
--- linux-2.6.13-rc7.orig/lib/radix-tree.c 2005-08-23 20:39:14.0
-0700
+++ linux-2.6.13-rc7/lib/radix-tree.c 2005-08-26 17:10:54.0 -0700
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2001 Momchil Velikov
* Portions Copyright (C) 2001 Christoph Hellwig
+ * Copyright (C) 2005 SGI, Christoph Lameter <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -51,7 +52,7 @@ struct radix_tree_node {
};
struct radix_tree_path {
- struct radix_tree_node *node, **slot;
+ struct radix_tree_node *node;
int offset;
};
@@ -227,7 +228,7 @@ out:
int radix_tree_insert(struct radix_tree_root *root,
unsigned long index, void *item)
{
- struct radix_tree_node *node = NULL, *tmp, **slot;
+ struct radix_tree_node *node = NULL, *slot;
unsigned int height, shift;
int offset;
int error;
@@ -240,38 +241,42 @@ int radix_tree_insert(struct radix_tree_
return error;
}
- slot = >rnode;
+ slot = root->rnode;
height = root->height;
shift = (height-1) * RADIX_TREE_MAP_SHIFT;
offset = 0; /* uninitialised var warning */
while (height > 0) {
- if (*slot == NULL) {
+ if (slot == NULL) {
/* Have to add a child node. */
- if (!(tmp = radix_tree_node_alloc(root)))
+ if (!(slot = radix_tree_node_alloc(root)))
return -ENOMEM;
- *slot = tmp;
- if (node)
+ if (node) {
+ node->slots[offset] = slot;
node->count++;
+ } else
+ root->rnode = slot;
}
/* Go a level down */
offset = (index >> shift) & RADIX_TREE_MAP_MASK;
- node = *slot;
- slot = (struct radix_tree_node **)(node->slots + offset);
+ node = slot;
+ slot = node->slots[offset];
shift -= RADIX_TREE_MAP_SHIFT;
height--;
}
- if (*slot != NULL)
+ if (slot != NULL)
return -EEXIST;
+
if (node) {
node->count++;
+ node->slots[offset] = item;
BUG_ON(tag_get(node, 0, offset));
BUG_ON(tag_get(node, 1, offset));
- }
+ } else
+ root->rnode = item;
- *slot = item;
return 0;
}
EXPORT_SYMBOL(radix_tree_insert);
@@ -286,27 +291,25 @@ EXPORT_SYMBOL(radix_tree_insert);
void *radix_tree_lookup(struct radix_tree_root *root, unsigned long index)
{
unsigned int height, shift;
- struct radix_tree_node **slot;
+ struct radix_tree_node *slot;
height = root->height;
if (index > radix_tree_maxindex(height))
return NULL;
shift = (height-1) * RADIX_TREE_MAP_SHIFT;
- slot = >rnode;
+ slot = root->rnode;
while (height > 0) {
- if (*slot == NULL)
+ if (slot == NULL)
return NULL;
- slot = (struct radix_tree_node **)
- ((*slot)->slots +
- ((index >> shift) & RADIX_TREE_MAP_MASK));
+ slot = slot->slots[(index >> shift) & RADIX_TREE_MAP_MASK];
shift -= RADIX_TREE_MAP_SHIFT;
height--;
}
- return *slot;
+ return slot;
}
EXPORT_SYMBOL(radix_tree_lookup);
@@ -326,27 +329,27 @@ void *radix_tree_tag_set(struct radix_tr
[PATCH] acpi-cpufreq: Remove P-state read after a P-state write in normal path
Remove P-state read status after a P-state write in normal case. As
that operation is expensive. There are no known failures of a set and we can
assume success in the common case. acpi_pstate_strict parameter can be used
to force it back on any systems that is known to have errors.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.12/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
===
--- linux-2.6.12.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
2005-08-16 09:41:52.977456128 -0700
+++ linux-2.6.12/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c2005-08-17
13:32:33.034651136 -0700
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -57,6 +58,8 @@
static struct cpufreq_driver acpi_cpufreq_driver;
+static unsigned int acpi_pstate_strict;
+
static int
acpi_processor_write_port(
u16 port,
@@ -163,34 +166,44 @@
}
/*
-* Then we read the 'status_register' and compare the value with the
-* target state's 'status' to make sure the transition was successful.
-* Note that we'll poll for up to 1ms (100 cycles of 10us) before
-* giving up.
+* Assume the write went through when acpi_pstate_strict is not used.
+* As read status_register is an expensive operation and there
+* are no specific error cases where an IO port write will fail.
*/
-
- port = data->acpi_data.status_register.address;
- bit_width = data->acpi_data.status_register.bit_width;
-
- dprintk("Looking for 0x%08x from port 0x%04x\n",
- (u32) data->acpi_data.states[state].status, port);
-
- for (i=0; i<100; i++) {
- ret = acpi_processor_read_port(port, bit_width, );
- if (ret) {
- dprintk("Invalid port width 0x%04x\n", bit_width);
- retval = ret;
- goto migrate_end;
+ if (acpi_pstate_strict) {
+ /* Then we read the 'status_register' and compare the value
+* with the target state's 'status' to make sure the
+* transition was successful.
+* Note that we'll poll for up to 1ms (100 cycles of 10us)
+* before giving up.
+*/
+
+ port = data->acpi_data.status_register.address;
+ bit_width = data->acpi_data.status_register.bit_width;
+
+ dprintk("Looking for 0x%08x from port 0x%04x\n",
+ (u32) data->acpi_data.states[state].status, port);
+
+ for (i=0; i<100; i++) {
+ ret = acpi_processor_read_port(port, bit_width, );
+ if (ret) {
+ dprintk("Invalid port width 0x%04x\n",
bit_width);
+ retval = ret;
+ goto migrate_end;
+ }
+ if (value == (u32) data->acpi_data.states[state].status)
+ break;
+ udelay(10);
}
- if (value == (u32) data->acpi_data.states[state].status)
- break;
- udelay(10);
+ } else {
+ i = 0;
+ value = (u32) data->acpi_data.states[state].status;
}
/* notify cpufreq */
cpufreq_notify_transition(_freqs, CPUFREQ_POSTCHANGE);
- if (value != (u32) data->acpi_data.states[state].status) {
+ if (unlikely(value != (u32) data->acpi_data.states[state].status)) {
unsigned int tmp = cpufreq_freqs.new;
cpufreq_freqs.new = cpufreq_freqs.old;
cpufreq_freqs.old = tmp;
@@ -537,6 +550,8 @@
return;
}
+module_param(acpi_pstate_strict, uint, 0644);
+MODULE_PARM_DESC(acpi_pstate_strict, "value 0 or non-zero. non-zero -> strict
ACPI checks are performed during frequency changes.");
late_initcall(acpi_cpufreq_init);
module_exit(acpi_cpufreq_exit);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] acpi: Handle cpu_index greater than 256 properly in processor_core.c
Fix convert_acpiid_to_cpu function to handle cpu_index greater than 256. This
patch also prevents a warning in IA64 cross-compile of this file
(drivers/acpi/processor_core.c:517: warning: comparison is always false due
to limited range of data type).
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.12/drivers/acpi/processor_core.c
===
--- linux-2.6.12.orig/drivers/acpi/processor_core.c 2005-08-16
09:41:53.687348208 -0700
+++ linux-2.6.12/drivers/acpi/processor_core.c 2005-08-16 10:53:29.957215912
-0700
@@ -425,18 +425,20 @@
#define ARCH_BAD_APICID(0xff)
#endif
-static u8 convert_acpiid_to_cpu(u8 acpi_id)
+static int convert_acpiid_to_cpu(u8 acpi_id, unsigned int *cpu_index)
{
u16 apic_id;
- int i;
+ unsigned int i;
apic_id = arch_acpiid_to_apicid[acpi_id];
if (apic_id == ARCH_BAD_APICID)
return -1;
for (i = 0; i < NR_CPUS; i++) {
- if (arch_cpu_to_apicid[i] == apic_id)
- return i;
+ if (arch_cpu_to_apicid[i] == apic_id) {
+ *cpu_index = i;
+ return 0;
+ }
}
return -1;
}
@@ -453,7 +455,8 @@
acpi_status status = 0;
union acpi_object object = {0};
struct acpi_buffer buffer = {sizeof(union acpi_object), };
- u8 cpu_index;
+ int retval;
+ unsigned intcpu_index;
static int cpu0_initialized;
ACPI_FUNCTION_TRACE("acpi_processor_get_info");
@@ -497,10 +500,10 @@
*/
pr->acpi_id = object.processor.proc_id;
- cpu_index = convert_acpiid_to_cpu(pr->acpi_id);
+ retval = convert_acpiid_to_cpu(pr->acpi_id, _index);
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
- if ( !cpu0_initialized && (cpu_index == 0xff) &&
+ if ( !cpu0_initialized && retval &&
(num_online_cpus() == 1)) {
cpu_index = 0;
}
@@ -514,9 +517,9 @@
* less than the max # of CPUs. They should be ignored _iff
* they are physically not present.
*/
- if (cpu_index >= NR_CPUS) {
+ if (retval) {
if (ACPI_FAILURE(acpi_processor_hotadd_init(pr->handle,
>id))) {
- ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Error getting cpuindex for acpiid 0x%x\n",
pr->acpi_id));
return_VALUE(-ENODEV);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Promise ATA/133 Errors With 2.6.10+
It appears that 2.6.13-rc7 has fixed the bug.
I would like to know *What* changed, but I'll probably never find out :(
On Thu, 28 Jul 2005, Andrew Morton wrote:
Justin Piszcz <[EMAIL PROTECTED]> wrote:
I have two different machines with the 7200.8 Seagate 8MB 400GB drives.
Both have ATA/133 controllers, the error is the same on both:
Jun 24 15:24:18 localhost kernel: hde: no DRQ after issuing MULTWRITE_EXT
I put the drive on an (older) Promise ATA/100 controller = works great!
I put the drive on the second box on the motherboard IDE interface = works
great!
What happened > 2.6.10 to the promise driver?
??
Jun 24 15:24:18 localhost kernel: PDC202XX: Primary channel reset.
Jun 24 15:24:18 localhost kernel: hde: timeout waiting for DMA
Jun 24 15:24:18 localhost kernel: hde: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Jun 24 15:24:18 localhost kernel:
Jun 24 15:24:18 localhost kernel: ide: failed opcode was: unknown
Jun 24 15:24:18 localhost kernel: hde: drive not ready for command
Jun 24 15:24:18 localhost kernel: hde: status timeout: status=0xd0 { Busy
}
Jun 24 15:24:18 localhost kernel:
Jun 24 15:24:18 localhost kernel: ide: failed opcode was: unknown
Jun 24 15:24:18 localhost kernel: PDC202XX: Primary channel reset.
Jun 24 15:24:18 localhost kernel: hde: no DRQ after issuing MULTWRITE_EXT
Jun 24 15:24:18 localhost kernel: ide2: reset: success
Is this still happening in 2.6.13-rc4?
If so, can you please cc linux-kernel on the reply? Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7-rt3 compile fix
On Fri, 2005-08-26 at 18:43 -0500, K.R. Foley wrote: > Steven Rostedt wrote: > > Oops! my bad. I saw that needed locking, but I didn't have the tracing > > on (I was trying for internal deadlocks), so that part of the code > > wasn't compiling. If you turn off tracing it would compile :-) > > Understood. ;-) > I'm wrong again :-) It wasn't the tracing. Here's the ifdef #if defined(ALL_TASKS_PI) && defined(CONFIG_RT_DEADLOCK_DETECT) And Ingo turned on ALL_TASKS_PI now. But I had CONFIG_RT_DEADLOCK_DETECT also turned off. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7-rt3 compile fix
Steven Rostedt wrote: > On Fri, 2005-08-26 at 16:17 -0500, K.R. Foley wrote: > >>2.6.13-rc7-rt3 won't compile without the simple patch below. >> > > - __raw_spin_lock(old_owner->task->pi_lock); > + __raw_spin_lock(_owner->task->pi_lock); > TRACE_WARN_ON_LOCKED(plist_empty(>pi_list)); > TRACE_WARN_ON_LOCKED(lock_owner(lock)); > > @@ -683,7 +683,7 @@ > } > TRACE_WARN_ON_LOCKED(1); > ok: > - __raw_spin_unlock(old_owner->task->pi_lock); > + __raw_spin_unlock(_owner->task->pi_lock); > return; > > > Oops! my bad. I saw that needed locking, but I didn't have the tracing > on (I was trying for internal deadlocks), so that part of the code > wasn't compiling. If you turn off tracing it would compile :-) Understood. ;-) > > Anyway, the next time I modify code that's protected by ifdefs, I'll > change my config and see at least the code compiles. > > Thanks, > > -- Steve > > > -- kr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kgdb on EM64T
George Anzinger [mailto:[EMAIL PROTECTED] wrote: > >Well, I checked, it is "int $3". Why then the panic? If you try the >boot with kgdb (i.e. wait) and the do: >(gdb) disass gdb_interrupt >What do you find at +75? Below is the console from the session it is interesting that gdb is not able to access the memory. I let it continue and then ctrl-c broke it later in the boot cycle and tried disass again with the same result. Feel free to flog me if this is stupid but I have just one EM64T machine (test) and I'm using a regular P4 machine as dev. I build the test kernel on the EM64T machine and then copy the updated sources, object files, and images via NFS to the dev machine. I believe I read in the kgdb doc that it was possible to use to different architecture machines for test and dev although there wasn't any information about how to do it. This is probably the source of the OS/ABI warning. I can probably get the mothership to send me another EM64T machine if need be. vincent:/home/bwilkers/proj/linux-2.6.13-rc4-mm1 # gdb vmlinux GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i386:x86-64 settings. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 0x80503b50 in ?? () warning: no shared library support for this OS / ABI (gdb) disass gdb_interrupt Dump of assembler code for function gdb_interrupt: 0x80247009 : Cannot access memory at address 0x80247009 (gdb) c Continuing. Bootdata ok (command line is root=/dev/sda2 kgdb console=kgdb) Linux version 2.6.13-rc4-mm1-perfmon-em64t ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #43 SMP Sat Aug 27 15:56:14 MDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e6000 - 0010 (reserved) BIOS-e820: 0010 - 3fe2f800 (usable) BIOS-e820: 3fe2f800 - 3fe3f832 (ACPI NVS) BIOS-e820: 3ff1 - 3ff3 (reserved) BIOS-e820: 3ff3 - 3ff4 (ACPI data) BIOS-e820: 3ff4 - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fed13000 - fed1a000 (reserved) BIOS-e820: fed1c000 - feda (reserved) ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
On Fri, 2005-08-26 at 17:44 -0500, Dmitry Torokhov wrote: > Is this function used in a hot path to warrant using "unlikely"? There > are to many "unlikely" in the code for my taste. unlikely() can result in better, smaller, faster code. and it acts as a nice directive to programmers reading the code. > input_[un]register_device and del_timer_sync are "long" operations. I > think a semaphore would be better here. I was considering moving all locking to a single semaphore, actually. Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12 Performance problems
Danial Thom wrote: I didn't refuse. I just chose to take help from Ben, because Ben took the time to reproduce the problem and to provide useful settings that made sense to me. There's nothing wrong with my machine. Well, I didn't see the slowdown on my system when I tried 2.6 v/s 2.4. You reported a 3x slowdown. In your original mail, you didn't mention trying to do compiles at the same time as your network test. I *did* see a pathetic slowdown (from 250kpps bridging to about 6kpps getting through the bridge) when I coppied a 512MB CDROM to the HD, but let's get the pure network slowdown on your system figured out before we start looking at the impact of disk IO. So, if you see a 3x slowdown on an unloaded machine when going from 2.4 to 2.6, then there is something unique about your system and we should figure out what it is. Also, my numbers (about 250kpps with moderate amount of drops) was a lot better than the 100kpps you reported for 2.6. My hardware is different (P-IV, HT, 3.0Ghz 1MB Cache, 1GB RAM, dual Intel pro/1000 NIC in PCI-X 66/133 slot), but I would not expect that to be 2x faster than your Opteron (or whatever you had). You could mention what you are using to generate traffic. (I was using pktgen to generate a stream of 60 byte pkts.) I think you should give us some better information on exactly what you are doing on 2.4 v/s 2.6. And for heaven's sake, don't hesitate to send kernel configs and hardware listings to folks that ask. Ruling out problems is as useful as finding problems in this sort of thing. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:[PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.
On Fri, 26 Aug 2005, Rusty Lynch wrote: > Just to be sure everyone understands the overhead involved, kprobes only > registers a single notifier. If kprobes is disabled (CONFIG_KPROBES is > off) then the overhead on a page fault is the overhead to execute an empty > notifier chain. Its the overhead of using registers to pass parameters, performing a function call that does nothing etc. A waste of computing resources. All of that unconditionally in a performance critical execution path that is executed a gazillion times for an optional feature that I frankly find not useful at all and that is disabled by default. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: process creation time increases linearly with shmem
On Fri, 26 Aug 2005, Rik van Riel wrote: > On Fri, 26 Aug 2005, Hugh Dickins wrote: > > > Well, I still don't think we need to test vm_file. We can add an > > anon_vma test if you like, if we really want to minimize the fork > > overhead, in favour of later faults. Do we? > > When you consider NUMA placement (the child process may > end up running elsewhere), allocating things like page > tables lazily may well end up being a performance win. It should be easy enough to benchmark something like kernel compiles etc, which are reasonably fork-rich and should show a good mix for something like this. Or even just something like "time to restart a X session" after you've brought it into memory once. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
From: Alexey Dobriyan <[EMAIL PROTECTED]> Date: Sat, 27 Aug 2005 02:58:48 +0400 > What's the point of having unlikely() attached to every possible if ()? If can result in smaller code, for one thing, even if it isn't a performance critical path. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: process creation time increases linearly with shmem
On Fri, 26 Aug 2005, Hugh Dickins wrote: > Well, I still don't think we need to test vm_file. We can add an > anon_vma test if you like, if we really want to minimize the fork > overhead, in favour of later faults. Do we? When you consider NUMA placement (the child process may end up running elsewhere), allocating things like page tables lazily may well end up being a performance win. -- All Rights Reversed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: process creation time increases linearly with shmem
On Fri, 26 Aug 2005, Hugh Dickins wrote: > > Well, I still don't think we need to test vm_file. We can add an > anon_vma test if you like, if we really want to minimize the fork > overhead, in favour of later faults. Do we? I think we might want to do it in -mm for testing. Because quite frankly, otherwise the new fork() logic won't get a lot of testing. Shared memory isn't that common. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
On Fri, Aug 26, 2005 at 06:18:45PM -0400, Robert Love wrote:
> Attached patch provides a driver for the IBM Hard Drive Active
> Protection System (hdaps) on top of 2.6.13-rc6-mm2.
> --- linux-2.6.13-rc6-mm2/drivers/hwmon/hdaps.c
> +++ linux/drivers/hwmon/hdaps.c
> +static int hdaps_probe(struct device *dev)
> +{
> + int ret;
> +
> + ret = accelerometer_init();
> + if (unlikely(ret))
What's the point of having unlikely() attached to every possible if ()?
> +static ssize_t hdaps_temp_show(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + u8 temp;
> + int ret;
> +
> + ret = accelerometer_readb_one(HDAPS_PORT_TEMP, );
> + if (unlikely(ret < 0))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote:
> +static void hdaps_calibrate(void)
> +{
> + int x, y, ret;
> +
> + ret = accelerometer_read_pair(HDAPS_PORT_XPOS, HDAPS_PORT_YPOS, ,
> );
> + if (unlikely(ret))
> + return;
> +
> + rest_x = x;
> + rest_y = y;
> +}
Is this function used in a hot path to warrant using "unlikely"? There
are to many "unlikely" in the code for my taste.
> +
> +static ssize_t hdaps_mousedev_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int enable;
> +
> + if (sscanf(buf, "%d", ) != 1)
> + return -EINVAL;
> +
> + spin_lock(_lock);
> + if (enable == 1)
> + hdaps_mousedev_enable();
> + else if (enable == 0)
> + hdaps_mousedev_disable();
> + spin_unlock(_lock);
> +
> + return count;
> +}
input_[un]register_device and del_timer_sync are "long" operations. I
think a semaphore would be better here.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
Robert Love <[EMAIL PROTECTED]> writes: > On Fri, 2005-08-26 at 15:33 -0400, Jeff Garzik wrote: > > > Since such a check is possible, that's definitely a merge-stopper IMO > > First, I am not asking that Linus merge this. Everyone needs to relax. > > Second, we don't know a DMI-based solution will work. I'll check it out. With some luck it might be in the ACPI name space with a known name. If yes that would be far more reliable than DMI. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] New SBC8360 watchdog driver
Andrew, Attached patch provides a driver for the hardware watchdog on-board the SBC8360 single board computer. This board is used in many industrial and embedded systems, including many touch-panel computers from Axiomtek, Inc. Please consider for inclusion into the mainline Linux kernel. Signed-off-by: Ian E. Morgan <[EMAIL PROTECTED]> drivers/char/watchdog/Kconfig | 13 + drivers/char/watchdog/Makefile |1 drivers/char/watchdog/sbc8360.c | 421 3 files changed, 435 insertions(+) Regards, Ian Morgan -- --- Ian E. Morgan Vice President & C.O.O. Webcon, Inc. imorgan at webcon dot ca PGP: #2DA40D07 www.webcon.ca * Customized Linux Network Solutions for your Business * --- diff -urN linux/drivers/char/watchdog/Kconfig~ linux/drivers/char/watchdog/Kconfig --- linux/drivers/char/watchdog/Kconfig~2005-02-15 18:19:22.0 -0500 +++ linux/drivers/char/watchdog/Kconfig 2005-02-15 18:19:22.0 -0500 @@ -224,6 +224,19 @@ Most people will say N. +config SBC8360_WDT + tristate "SBC8360 Watchdog Timer" + depends on WATCHDOG && X86 + ---help--- + + This is the driver for the hardware watchdog on the SBC8360 Single + Board Computer produced by Axiomtek Co., Ltd. (www.axiomtek.com). + + To compile this driver as a module, choose M here: the + module will be called sbc8360.ko. + + Most people will say N. + config WAFER_WDT tristate "ICP Wafer 5823 Single Board Computer Watchdog" depends on WATCHDOG && X86 diff -urN linux/drivers/char/watchdog/Makefile~ linux/drivers/char/watchdog/Makefile --- linux/drivers/char/watchdog/Makefile~ 2005-02-15 18:20:03.0 -0500 +++ linux/drivers/char/watchdog/Makefile2005-02-15 18:20:03.0 -0500 @@ -6,6 +6,7 @@ obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o obj-$(CONFIG_IB700_WDT) += ib700wdt.o +obj-$(CONFIG_SBC8360_WDT) += sbc8360.o obj-$(CONFIG_MIXCOMWD) += mixcomwd.o obj-$(CONFIG_SCx200_WDT) += scx200_wdt.o obj-$(CONFIG_60XX_WDT) += sbc60xxwdt.o diff -urN /dev/null linux/drivers/char/watchdog/sbc8360.c --- /dev/null 2004-02-23 16:02:56.0 -0500 +++ linux/drivers/char/watchdog/sbc8360.c 2005-08-26 16:41:12.0 -0400 @@ -0,0 +1,421 @@ +/* + * SBC8360 Watchdog driver + * + * (c) Copyright 2005 Webcon, Inc. + * + * Based on ib700wdt.c, which is based on advantechwdt.c which is based + * on acquirewdt.c which is based on wdt.c. + * + * (c) Copyright 2001 Charles Howes <[EMAIL PROTECTED]> + * + * Based on advantechwdt.c which is based on acquirewdt.c which + * is based on wdt.c. + * + * (c) Copyright 2000-2001 Marek Michalkiewicz <[EMAIL PROTECTED]> + * + * Based on acquirewdt.c which is based on wdt.c. + * Original copyright messages: + * + * (c) Copyright 1996 Alan Cox <[EMAIL PROTECTED]>, All Rights Reserved. + * http://www.redhat.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Neither Alan Cox nor CymruNet Ltd. admit liability nor provide + * warranty for any of this software. This material is provided + * "AS-IS" and at no charge. + * + * (c) Copyright 1995Alan Cox <[EMAIL PROTECTED]> + * + * 14-Dec-2001 Matt Domsch <[EMAIL PROTECTED]> + * Added nowayout module option to override CONFIG_WATCHDOG_NOWAYOUT + * Added timeout module option to override default + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +static unsigned long sbc8360_is_open; +static spinlock_t sbc8360_lock; +static char expect_close; + +#define PFX "sbc8360: " + +/* + * + * Watchdog Timer Configuration + * + * The function of the watchdog timer is to reset the system automatically + * and is defined at I/O port 0120H and 0121H. To enable the watchdog timer + * and allow the system to reset, write appropriate values from the table + * below to I/O port 0220H and 0221H. To disable the timer, write a zero + * value to I/O port 0221H for the system to stop the watchdog function. + * + * The following describes how the timer should be programmed (according to + * the vendor documentation) + * + * Enabling Watchdog: + * MOV AX,000AH (enable, phase I) + * MOV DX,0120H + * OUT DX,AX + * MOV AX,000BH (enable, phase II) + * MOV DX,0120H + * OUT DX,AX + * MOV AX,000nH (set multiplier n, from 1-4) + * MOV DX,0120H
Re: 2.6.12 Performance problems
--- Danial Thom <[EMAIL PROTECTED]> wrote: > > > --- Ben Greear <[EMAIL PROTECTED]> wrote: > > > Danial Thom wrote: > > > > > > --- Ben Greear <[EMAIL PROTECTED]> > > wrote: > > > > > > > > >>Danial Thom wrote: > > >> > > >> > > >>>I think the concensus is that 2.6 has made > > >> > > >>trade > > >> > > >>>offs that lower raw throughput, which is > > what > > >> > > >>a > > >> > > >>>networking device needs. So as a router or > > >>>network appliance, 2.6 seems less > suitable. > > A > > >> > > >>raw > > >> > > >>>bridging test on a 2.0Ghz operton system: > > >>> > > >>>FreeBSD 4.9: Drops no packets at 900K pps > > >>>Linux 2.4.24: Starts dropping packets at > > 350K > > >> > > >>pps > > >> > > >>>Linux 2.6.12: Starts dropping packets at > > 100K > > >> > > >>pps > > >> > > >>I ran some quick tests using kernel 2.6.11, > > 1ms > > >>tick (HZ=1000), SMP kernel. > > >>Hardware is P-IV 3.0Ghz + HT on a new > > >>SuperMicro motherboard with 64/133Mhz > > >>PCI-X bus. NIC is dual Intel pro/1000. > > Kernel > > >>is close to stock 2.6.11. > > > > > What GigE adapters did you use? Clearly > every > > > driver is going to be different. My > > experience is > > > that a 3.4Ghz P4 is about the performance > of > > a > > > 2.0Ghz Opteron. I have to try your tuning > > script > > > tomorrow. > > > > Intel pro/1000, as I mentioned. I haven't > > tried any other > > NIC that comes close in performance to the > > e1000. > > > > > If your test is still set up, try compiling > > > something large while doing the test. The > > drops > > > go through the roof in my tests. > > > > Installing RH9 on the box now to try some > > tests... > > > > Disk access always robs networking, in my > > experience, so > > I am not supprised you see bad ntwk > performance > > while > > compiling. > > > > Ben > > It would be useful if there were some way to > find > out "what" is getting "robbed". If networking > has > priority, then what is keeping it from getting > back to processing the rx interrupts? > > Ah, the e1000 has built-in interrupt > moderation. > I can't get into my lab until tomorrow > afternoon, > but if you get a chance try setting ITR in > e1000_main.c to something larger, like 20K. and > see if it makes a difference. At 200K pps that > would cause an interrupt every 10 packets, > which > may allow the routine to grab back the cpu more > often. > > > Danial > Just FYI, setting interrupt moderation to 20,000 didn't make much difference. Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] IBM HDAPS accelerometer driver, with probing.
Andrew,
Attached patch provides a driver for the IBM Hard Drive Active
Protection System (hdaps) on top of 2.6.13-rc6-mm2.
Over the previous post, it contains several fixes and improvements,
including a dev->probe() routine and a DMI whitelist.
Robert Love
Driver for the IBM HDAPS
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
MAINTAINERS|7
drivers/hwmon/Kconfig | 17 +
drivers/hwmon/Makefile |1
drivers/hwmon/hdaps.c | 664 +
4 files changed, 689 insertions(+)
diff -urN linux-2.6.13-rc6-mm2/drivers/hwmon/hdaps.c linux/drivers/hwmon/hdaps.c
--- linux-2.6.13-rc6-mm2/drivers/hwmon/hdaps.c 1969-12-31 19:00:00.0
-0500
+++ linux/drivers/hwmon/hdaps.c 2005-08-26 18:17:33.0 -0400
@@ -0,0 +1,664 @@
+/*
+ * drivers/hwmon/hdaps.c - driver for IBM's Hard Drive Active Protection System
+ *
+ * Copyright (C) 2005 Robert Love <[EMAIL PROTECTED]>
+ * Copyright (C) 2005 Jesper Juhl <[EMAIL PROTECTED]>
+ *
+ * The HardDisk Active Protection System (hdaps) is present in the IBM ThinkPad
+ * T41, T42, T43, and R51, at least. It provides a basic two-axis
+ * accelerometer and other misc. data.
+ *
+ * Based on the document by Mark A. Smith available at
+ * http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html and a lot of trial
+ * and error.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HDAPS_LOW_PORT 0x1600 /* first port used by hdaps */
+#define HDAPS_HIGH_PORT0x162f /* last port used by hdaps */
+
+#define STATE_FRESH0x50/* accelerometer data is fresh */
+
+#define REFRESH_ASYNC 0x00/* do asynchronous refresh */
+#define REFRESH_SYNC 0x01/* do synchronous refresh */
+
+#define HDAPS_PORT_STATE 0x1611 /* device state */
+#defineHDAPS_PORT_XPOS 0x1612 /* x-axis position */
+#define HDAPS_PORT_YPOS0x1614 /* y-axis position */
+#define HDAPS_PORT_TEMP0x1616 /* device temperature, in
celcius */
+#define HDAPS_PORT_XVAR0x1617 /* x-axis variance (what is
this?) */
+#define HDAPS_PORT_YVAR0x1619 /* y-axis variance (what is
this?) */
+#define HDAPS_PORT_TEMP2 0x161b /* device temperature (again?) */
+#define HDAPS_PORT_UNKNOWN 0x161c /* what is this? */
+#define HDAPS_PORT_KMACT 0x161d /* keyboard or mouse activity */
+
+#define HDAPS_READ_MASK0xff/* some reads have the low 8
bits set */
+
+#define KEYBD_MASK 0x20/* set if keyboard activity */
+#define MOUSE_MASK 0x40/* set if mouse activity */
+
+#define KEYBD_ISSET(n) (!! (n & KEYBD_MASK))
+#define MOUSE_ISSET(n) (!! (n & MOUSE_MASK))
+
+static spinlock_t hdaps_lock = SPIN_LOCK_UNLOCKED;
+
+
+/*
+ * __get_latch - Get the value from a given port latch. Callers must hold
+ * hdaps_lock.
+ */
+static inline unsigned short __get_latch(unsigned short port)
+{
+ return inb(port) & HDAPS_READ_MASK;
+}
+
+/*
+ * __check_latch - Check a port latch for a given value. Callers must hold
+ * hdaps_lock.
+ */
+static inline unsigned int __check_latch(unsigned short port, unsigned char
val)
+{
+ if (__get_latch(port) == val)
+ return 1;
+ return 0;
+}
+
+/*
+ * __wait_latch - Wait up to 100us for a port latch to get a certain value,
+ * returning nonzero if the value is obtained and zero otherwise. Callers
+ * must hold hdaps_lock.
+ */
+static unsigned int __wait_latch(unsigned short port, unsigned char val)
+{
+ unsigned int i;
+
+ for (i = 0; i < 20; i++) {
+ if (__check_latch(port, val))
+ return 1;
+ udelay(5);
+ }
+
+ return 0;
+}
+
+/*
+ * __request_refresh - Request a refresh from the accelerometer.
+ *
+ * If sync is REFRESH_SYNC, we perform a synchronous refresh and will wait for
+ * the refresh. Returns nonzero if successful or zero on error.
+ *
+ * If sync is REFRESH_ASYNC, we merely kick off a new refresh if the device is
+ * not up-to-date. Always returns true. On the next read from the device, the
+ * data should be up-to-date but a
Re: Kernel/Box Freezes Under Kernel 2.6.12.5
I have three different Maxtor (promise) ATA/133 controllers, it happens with all three. On Fri, 26 Aug 2005, Patrick McFarland wrote: On Friday 26 August 2005 05:36 pm, Justin Piszcz wrote: 2- ATA/133 Maxtor (ATA/Promise Controller) Make sure its actually the kernel and not that controller. Go find another identical one and test with it. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel/Box Freezes Under Kernel 2.6.12.5
On Friday 26 August 2005 05:36 pm, Justin Piszcz wrote: > 2- ATA/133 Maxtor (ATA/Promise Controller) Make sure its actually the kernel and not that controller. Go find another identical one and test with it. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpaQMYAAXGrv.pgp Description: PGP signature
Re: [patch 1/2] Fixup symlink function pointers for hppfs [for 2.6.13]
On Fri, Aug 26, 2005 at 10:04:43PM +0200, Blaisorblade wrote:
> And beyond that what? I cannot even think what's the rest *. And "obvious"
> doesn't hold with me.
vfsmount *mnt = do_kern_mount("proc", 0, "proc", NULL);
done at init time,
mntput(mnt);
at exit
and mntget(mnt) instead of your NULL in dentry_open().
Do not mess with get_fs_type() anywhere - the above will give you access
to procfs superblock just fine.
The real issue is what you are doing with procfs dentries there. You do
*not* call ->d_revalidate(). And you do not evict these suckers when
procfs dentry goes away. E.g. when process dies...
What the hell is going on with iget() calls, BTW? Especially since all
of them get the same inumber... Looks completely broken.
Why does is_pid() bother with checks for fs dentry belongs to?
copy_from_user() return value needs to be checked.
Use of file->f_pos is blatantly racy; don't do that.
->permission() is missing on hppfs; since procfs is not using generic one,
we have a problem.
read_proc() is a guaranteed fsckup if hppfs_open() is called with KERNEL_DS.
That's from the quick look through the current code...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] late spinlock initialization in ieee1394/ohci
Thanks Al. I'll commit this to our tree. Linus, feel free to apply this to your tree. Signed-off-by: Ben Collins <[EMAIL PROTECTED]> On Thu, Aug 25, 2005 at 11:13:14PM +0100, Al Viro wrote: > spinlock used in irq handler should be initialized before registering > irq, even if we know that our device has interrupts disabled; handler > is registered shared and taking spinlock is done unconditionally. As > it is, we can and do get oopsen on boot for some configuration, depending > on irq routing - I've got a reproducer. > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > > diff -urN RC13-rc7-base/drivers/ieee1394/ohci1394.c > current/drivers/ieee1394/ohci1394.c > --- RC13-rc7-base/drivers/ieee1394/ohci1394.c 2005-08-24 01:56:37.0 > -0400 > +++ current/drivers/ieee1394/ohci1394.c 2005-08-25 18:02:49.0 > -0400 > @@ -478,7 +478,6 @@ > int num_ports, i; > > spin_lock_init(>phy_reg_lock); > - spin_lock_init(>event_lock); > > /* Put some defaults to these undefined bus options */ > buf = reg_read(ohci, OHCI1394_BusOptions); > @@ -3402,7 +3401,14 @@ > /* We hopefully don't have to pre-allocate IT DMA like we did >* for IR DMA above. Allocate it on-demand and mark inactive. */ > ohci->it_legacy_context.ohci = NULL; > + spin_lock_init(>event_lock); > > + /* > + * interrupts are disabled, all right, but... due to SA_SHIRQ we > + * might get called anyway. We'll see no event, of course, but > + * we need to get to that "no event", so enough should be initialized > + * by that point. > + */ > if (request_irq(dev->irq, ohci_irq_handler, SA_SHIRQ, >OHCI1394_DRIVER_NAME, ohci)) > FAIL(-ENOMEM, "Failed to allocate shared interrupt %d", > dev->irq); -- Ubuntu - http://www.ubuntu.com/ Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ SwissDisk - http://www.swissdisk.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7-rt3 compile fix
On Fri, 2005-08-26 at 16:17 -0500, K.R. Foley wrote: > 2.6.13-rc7-rt3 won't compile without the simple patch below. > - __raw_spin_lock(old_owner->task->pi_lock); + __raw_spin_lock(_owner->task->pi_lock); TRACE_WARN_ON_LOCKED(plist_empty(>pi_list)); TRACE_WARN_ON_LOCKED(lock_owner(lock)); @@ -683,7 +683,7 @@ } TRACE_WARN_ON_LOCKED(1); ok: - __raw_spin_unlock(old_owner->task->pi_lock); + __raw_spin_unlock(_owner->task->pi_lock); return; Oops! my bad. I saw that needed locking, but I didn't have the tracing on (I was trying for internal deadlocks), so that part of the code wasn't compiling. If you turn off tracing it would compile :-) Anyway, the next time I modify code that's protected by ifdefs, I'll change my config and see at least the code compiles. Thanks, -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel/Box Freezes Under Kernel 2.6.12.5
Kernel 2.6.12.5: 1- 400GB Seagate 8MB cache, 7200RPM, ATA/100 drive. 2- ATA/133 Maxtor (ATA/Promise Controller) 1) Attached 400GB to Seagate 400GB drive. 2) (Not mounted yet) 3) See below hde: 781422768 sectors (400088 MB) w/8192KiB Cache, CHS=48641/255/63, UDMA(100) 4) Partition with fdisk (hde1). 5) mkfs.xfs /dev/hde1 *** KERNEL FREEZE *** (ENTIRE MACHINE LOCKS UP) Do the SAME EXACT THING on the motherboard (INTEL) controller or an ATA/100 Promise Controller, there are NO problems. Either people with this problem are *not* reporting it or do not know where to report the problem to. This is the second machine I have seen this problem with. Has anyone looked into this? Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 01:22:26PM -0700, Chris Wedgwood wrote: > On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote: > > > Overmount_rootfs shouldn't take place until you know for sure the > > kernel detects an initramfs. > > Actually, it was a deliberate decision to *always* overmount after > some discussion with people. Ideally, I don't know why you would want to overmount unless the kernel detects an initramfs. > It's not a clean solution and the overall goals aren't clear here so > it was never submitted for inclusion --- an the fact is 99.9% of users > simply don't need or care for this. I know the patch is just a quick and simple way to use tmpfs for initramfs, and it seems to work. But, it would be nice if were cleaned up for that less than one percent. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.13-rc7-rt3 compile fix
2.6.13-rc7-rt3 won't compile without the simple patch below. -- kr --- linux-2.6.13/kernel/rt.c.orig 2005-08-26 15:51:35.0 -0500 +++ linux-2.6.13/kernel/rt.c 2005-08-26 15:51:55.0 -0500 @@ -672,7 +672,7 @@ struct rt_mutex_waiter *w; struct plist *curr1; - __raw_spin_lock(old_owner->task->pi_lock); + __raw_spin_lock(_owner->task->pi_lock); TRACE_WARN_ON_LOCKED(plist_empty(>pi_list)); TRACE_WARN_ON_LOCKED(lock_owner(lock)); @@ -683,7 +683,7 @@ } TRACE_WARN_ON_LOCKED(1); ok: - __raw_spin_unlock(old_owner->task->pi_lock); + __raw_spin_unlock(_owner->task->pi_lock); return; }
Re: 2.6.12 Performance problems
--- Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Fri, Aug 26, 2005 at 10:06:51AM -0700, > Danial Thom wrote: > >... > > I don't think I'm obligated to answer every > > single person who pipes into a thread. People > who > > say "show me your config and dmesg" are not > > useful. Linux has long had a philisophical > > problem of dropping packets as a "performance > > feature", and we've already established I > think > > that you can't eliminate it altogether, if > you > > read the thread carefully. > >... > > You say you have observed for a long time a > problem. > > The only person participating in this thread > who is one of the > networking maintainers is Patrick McHardy. > > Did _he_ say this was a known and unfixable > problem? I don't know. He said that the network stack has absolute priority, so perhaps he can explain why compiling a kernel causes an exponential increase in packet loss? The FreeBSD "network maintainers" are largely clueless about just about every problem in 5.x, so I'm not sure the title qualifies someone as knowing all there is to know. I haven't heard him claim that he can do the things I'm doing without any receive errors or drops. I'd like to hear about what test he runs to test this sort of problem. Before you can solve a problem you have to have a clear understanding of what the problem is, and admit that you have a problem. > > He wanted to help you and you pissed him off > because you refuxed to give > him dmesg, .config and other information that > would have helped him to > debug your problem. If you don't feel obliged > to help the persons > responsible for the part of the kernel you have > a problem with to debug > your problem your whole initial mail was > pointless. I didn't refuse. I just chose to take help from Ben, because Ben took the time to reproduce the problem and to provide useful settings that made sense to me. There's nothing wrong with my machine. I don't know who is who; I judge people based on the intelligence of their analysis. People responsible for the network stack may not be the right people, because this is more likely a scheduler issue. There's probably nothing wrong with the stack or the drivers; the machine just doesn't react fast enough to avert ring overruns. DT __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
On 8/26/05, Patrick McHardy <[EMAIL PROTECTED]> wrote: > Alessandro Suardi wrote: > > Stack is hand-copied from the dead box's console. > > > > [] die+0xe4/0x170 > > [] do_trap+0x7f/0xc0 > > [] do_invalid_op+0xa3/0xb0 > > [] error_code+0x4f/0x54 > > [] kfree_skbmem+0xb/0x20 > > [] __kfree_skb+0x5f/0xf0 > > [] tcp_clean_rtx_queue+0x16a/0x470 > > [] tcp_ack+0xf6/0x360 > > [] tcp_rcv_established+0x277/0x7a0 > > [] tcp_v4_do_rcv+0xf0/0x110 > > [] tcp_v4_rcv+0x6e0/0x820 > > [] ip_local_deliver_finish+0x84/0x160 > > [] nf_reinject+0x13a/0x1c0 > > [] ipq_issue_verdict+0x28/0x40 > > [] ipq_set_verdict+0x48/0x70 > > [] ipq_receive_peer+0x39/0x50 > > [] ipq_receive_sk+0x172/0x190 > > [] netlink_data_ready+0x35/0x60 > > [] netlink_sendskb+0x24/0x60 > > [] netlink_unicast+0x127/0x160 > > [] netlink_sendmsg+0x204/0x2b0 > > [] sock_sendmsg+0xb0/0xe0 > > [] sys_sendmsg+0x134/0x240 > > [] sys_socketcall+0x224/0x230 > > [] sysenter_past_esp+0x54/0x75 > > Code: 8b 41 0c 85 c0 75 1b 8b 86 94 00 00 00 e8 9e 37 e5 ff 5b 5e c9 > > c3 89 d0 e8 43 46 e5 ff 8d 76 00 eb d2 89 f0 e8 f7 fe ff ff eb dc <0f> > > 0b 54 01 16 d2 36 c0 eb b4 8d 74 26 00 8d bc 27 00 00 00 00 > > <0>Kernel panic - not syncing: Fatal exception in interrupt > > > > If there's need for further info I'd be happy to provide it. For now > > the box is rebooted into the same kernel and running the same > > PG/eD2k programs, if the issue reproduces I'll follow up on my > > own message. > > Any chance you can get the entire Oops including registers etc > using netconsole or serial console? Not right now, as I noticed netconsole requires netpoll and this latter can't be modular; but I'll do so before leaving tomorrow morning, obviously rebuilding with 2.6.13-rc7-git1 or -git2 if the new snapshot comes out. At the moment, the box has been running for 32 hours with no sign of wanting to oops... [EMAIL PROTECTED] ~]# ps ax | egrep 'peer|edon' 2416 pts/2Sl25:37 peerguardnf -d -l /var/log/pg.log -c /etc/PG.conf 25186 pts/0R+76:37 ./edonkey2000 25189 pts/0S+ 0:06 ./edonkey2000 25191 pts/0S+ 9:49 ./edonkey2000 7007 pts/0S+ 0:00 ./edonkey2000 7011 pts/3R+ 0:00 egrep peer|edon [EMAIL PROTECTED] ~]# w 22:37:53 up 1 day, 7:49, 4 users, load average: 0.15, 0.18, 0.25 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0donkey:2.0 Thu14 20:15m 1:26m 0.00s bash root pts/1donkey:2.0 Thu14 13:40m 0.41s 1:57 gnome-terminal --sm-config-prefix /gnome-terminal-wBjEOn/ - root pts/2donkey:2.0 Thu144:07 25:37 0.49s bash root pts/3192.168.1.6 22:370.00s 0.06s 0.01s w Thanks, --alessandro "Not every smile means I'm laughing inside" (Wallflowers - "From The Bottom Of My Heart") - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
To make molded parts for you to save your cost.Small Q'ty is OK(inj-com-wlw)
Dear Sir/Madam, We learnt your e-mail add.from internet. FIRST OF ALL,PLEASE KINDLY NOTE THIS E-MAIL IS SENT BY OUR "ADVERTISING COMPANY" AND THE E-MAIL ADDRESS IS NOT "REAL"(VIRTUAL),THEREFORE,PLEASE CONTACT US VIA "FAX" OR "POST".DON'T DIRECTLY RESPONSE VIA " E-MAIL" BECAUSE WE CAN'T RECEIVE YOUR E-MAIL. IF YOU WANT TO BE REMOVED FROM THE LIST,PLEASE ADVISE YOUR E-MAIL ADDRESS & THIS E-MAIL CONTENT OR SUBJECT VIA "FAX" OR "POST". We are the professional mold & die maker and molded parts(moldings) supplier for the following parts: * Castings(sand castings) for iron & aluminium * (Pressure) Die Casting for Zinc or aluminium * Plastic Injection moldings. * Sheet Metal Stampings. * Oil Seals & other Rubber Moldings(both for industrial or general uses). * Various Magnets. * Machinings(Machined parts) * Assembled unit(components assembled) SMALL ORDER IS OK,PLEASE CONTACT US TO SAVE YOUR COST! Thank you Best Regards J.S.Fu/President & CEO No.107,Kuan-Fu Rd.,Bei-Dou(521),Chan ghwa Hsien,Taiwan. Fax:886-4-8876126 (886 is the country code) Developing Japan markets.doc Description: Binary data
Re: [patch] IBM HDAPS accelerometer driver.
On Fri, Aug 26, 2005 at 03:29:15PM -0400, Robert Love wrote: > On Fri, 2005-08-26 at 20:55 +0100, Alan Cox wrote: > > > I think that should be fixed before its merged. > > Let me be clear, it has an init routine that effectively probes for the > device. > > It just lacks a simple quick non-invasive check. > > The driver will definitely fail to load on a laptop without the > requisite hardware. Poking IO ports on hardware where you don't have the device can be fatal. What happens if I have something completely different at io port 0x1600 ? (Thus satisfying your request_region() check). accelerometer_init() then happily starts poking ports, and performing all kinds of voodoo. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote: > Overmount_rootfs shouldn't take place until you know for sure the > kernel detects an initramfs. Actually, it was a deliberate decision to *always* overmount after some discussion with people. It's not a clean solution and the overall goals aren't clear here so it was never submitted for inclusion --- an the fact is 99.9% of users simply don't need or care for this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: very weired random io behavior
sorry. my dumb.
here is not
x = (rand() >> 1) << 1;
but
x = (rand() >> 10) << 10;
file is in bytes while lba is in sector. ;P
ming
On Fri, 2005-08-26 at 16:08 -0400, Ming Zhang wrote:
> ---
> #define _LARGEFILE64_SOURCE
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> int n;
> int i, count;
> char *name;
> char buf[4096];
> int fd;
>
> if (argc != 3) {
> printf("%s name count\n", argv[0]);
> exit(1);
> }
> name = argv[1];
> count = atoi(argv[2]);
>
> fd = open(name, O_CREAT|O_WRONLY, S_IRWXU);
> for (i = 0; i < count; i++) {
> unsigned long x;
>
> x = (rand() >> 1) << 1;
> lseek64(fd, x, SEEK_SET);
> write(fd, buf, 4096);
> }
> printf("done\n");
> close(fd);
> return 0;
> }
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hardware-Detection
Is there any Hardware-Detection Program, that directly gets its Information from the I/O and not from /proc/ files?? Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote: > On Fri, 2005-08-26 at 14:27 -0500, Dmitry Torokhov wrote: > > > What this completion is used for? I don't see any other references to it. > > It was the start of the release() routine, but I decided to move to > platform_device_register_simple() and use its release, instead. So this > is gone now in my tree. > > > I'd rather you used absolute coordinates and set up > > hdaps_idev->absfuzz to do the filtering. > > Me too. > Btw, if you set up absolute input device it will be claimed by joydev instead of mousedev and will not get in a way of normal operation while still available for playing. So you could just kill all that enabling/disabling code and have input device always activated. > > > > What about using sysfs_attribute_group? > > I don't see this in my tree? Sorry, it is called struct attribute_group, sysfs_create_group() and sysfs_remove_group(). See fs/sysfs/group.c -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
very weired random io behavior
I ran a small test program on a 400GB SATA disk connected to Marvel
chip. Using 2.6.11.12 kernel and get this strange behavior.
# iostat -k -p /dev/sdj
Linux 2.6.11.12 (bakstor2u.localdomain) 08/26/2005
avg-cpu: %user %nice%sys %iowait %idle
0.110.006.63 54.75 38.51
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
sdj 0.00 0.01 0.00 36 0
start with no io. run program with /dev/sdj and count 10240. i supposed
it should only write 40MB data and no read should be generated. but
result is quite weired. there are almost same amount of read and total
size is around 80MB.
# iostat -k -p /dev/sdj
Linux 2.6.11.12 (bakstor2u.localdomain) 08/26/2005
avg-cpu: %user %nice%sys %iowait %idle
0.110.006.48 55.65 37.77
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
sdj 4.2611.3111.47 80476 81640
pls cc to me.
Thanks!
Ming
---
#define _LARGEFILE64_SOURCE
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
int n;
int i, count;
char *name;
char buf[4096];
int fd;
if (argc != 3) {
printf("%s name count\n", argv[0]);
exit(1);
}
name = argv[1];
count = atoi(argv[2]);
fd = open(name, O_CREAT|O_WRONLY, S_IRWXU);
for (i = 0; i < count; i++) {
unsigned long x;
x = (rand() >> 1) << 1;
lseek64(fd, x, SEEK_SET);
write(fd, buf, 4096);
}
printf("done\n");
close(fd);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote: > On Fri, 2005-08-26 at 15:39 -0400, Robert Love wrote: > > > > This is racy - 2 threads can try to do this simultaneously. > > > > Fixed. Thanks. > > Actually, doesn't sysfs and/or the vfs layer serialize the two > simultaneous writes? > Not between 2 separate processes (or, rather, separate file handles) as far as I can see... -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Fixup symlink function pointers for hppfs [for 2.6.13]
On Friday 26 August 2005 21:03, Al Viro wrote:
> On Fri, Aug 26, 2005 at 04:57:44PM +0200, [EMAIL PROTECTED] wrote:
> > From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> > Update hppfs for the symlink functions prototype change.
> > Should be trivial, but please verify it's correct.
> > Yes, I know the code I leave there is still _bogus_, see next patch for
> > this.
About what it's doing, hppfs (HoneyPot Proc FS) is a wrapper for procfs, which
must be able to hide part of the content for avoid an hacker inside UML
realize he's hacking a virtual machine, and it's normally mounted on /proc,
if used.
> Assuming that the next patch was "hppfs: fix symlink error path",
Yes.
> you've still left BS in there -
BullShit? Thanks for improving my acronym dictionary!
> > proc_file = dentry_open(dget(proc_dentry), NULL, O_RDONLY);
> is obviously wrong; at the very least you need vfsmount in there.
And beyond that what? I cannot even think what's the rest *. And "obvious"
doesn't hold with me.
I'm _not_ a VFS hacker, I don't go beyond Documentation/filesystems/vfs.txt,
so I'd better leave fixing that to you.
At least what you don't mention. I'll fix vfsmount in these days (if you want
to do it yourself, I've put together needed info below).
I had to check dentry_open prototype to realize you're referring to the NULL
there and not to dget.
And the dentries you see are all descendants of the root one, taken in
hppfs_fill_super() from
err = init_inode(root_inode, proc_sb->s_root);
I guess the current hack could be replaced with reading
fs/proc/inode.c:proc_mnt... I wouldn't pass proc_mnt directly because we
don't know we took _that_ mount inside hppfs_fill_super(), but I like
replacing
list_entry(get_fs_type("proc")->fs_supers.next,...)
with proc_mnt->mnt_sb (assuming it's always filled in - IIRC I already checked
the initialization order).
* I've verified that there's no missing dput() in failure case as that's
handled by dentry_open().
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___
Yahoo! Messenger: chiamate gratuite in tutto il mondo
http://it.beta.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] Re: [RFC] [patch 0/18] remap_file_pages protection support (for UML), try 3
On Friday 26 August 2005 21:11, Hugh Dickins wrote: > On Fri, 26 Aug 2005, Blaisorblade wrote: > > This is a followup to my post of last week (Aug 12) about > > remap_file_pages protection support. I've improved and consolidated the > > patches and updated them against 2.6.13-rc6/rc7 (the same patches apply > > against both versions). I'm sending the full patch series only to akpm, > > mingo and LKML. > > > > I've also reduced them to only 18, and made the splitting more > > significant. I'm not resending all the patches for foreign architectures, > > because they're almost unchanged since last time (there's just a trivial > > reject from ppc32, because one change has already been done after -rc4). > > > > I'm working on this to provide support for UML, which currently easily > > creates more than 64K (the default limit) vma's for a single process. > > Actually, it needs one VMA per each page. So, with this patch and > > specific UML support, which Ingo wrote and which I'm porting to recent > > UMLs. > > I'll try to take a look sometime next week - or, if I wait until > next Friday, can we expect it to have come down to 9 patches ;-? :-) Don't think so, unless you want just me to join patches together. However, there are still some oneliners, so the patchset is not so huge. Well, diffstat seems to contradict me (on the joined-up patch): Documentation/feature-removal-schedule.txt | 12 + arch/i386/mm/fault.c | 19 ++ arch/um/kernel/trap_kern.c | 52 ++- arch/x86_64/mm/fault.c |6 include/asm-i386/mman.h|1 include/asm-i386/pgtable-2level.h | 15 +- include/asm-i386/pgtable-3level.h | 11 + include/asm-i386/pgtable.h |3 include/asm-ia64/mman.h|1 include/asm-ppc/mman.h |1 include/asm-ppc64/mman.h |1 include/asm-s390/mman.h|1 include/asm-um/pgtable-2level.h| 15 +- include/asm-um/pgtable-3level.h| 21 ++- include/asm-um/pgtable.h |3 include/asm-x86_64/mman.h |1 include/asm-x86_64/pgtable.h | 12 + include/linux/mm.h | 40 -- include/linux/pagemap.h| 32 mm/filemap.c | 18 ++ mm/fremap.c| 135 +++- mm/madvise.c |2 mm/memory.c| 193 ++--- mm/mmap.c | 14 +- mm/mprotect.c |3 mm/rmap.c |6 mm/shmem.c | 13 + > I should say, my initial reaction is very much like Andi's last week. > sys_remap_file_pages solves a real problem, but it does so by breaking > lots of rules. For more than a year after it came in, almost every > development we tried in mm would come up against "but then what do we > do about the nonlinear mappings?". Nonuniform mappings are much less of a problem. Really. The reason nonlinear mappings reached mainline before nonuniform ones (and I don't know if they willl ever) is not simplicity, but the miss of uses until now. And also the fact that Ingo hadn't the time to finish it. In fact, I've been playing a lot with the GIT history during this month of development, particularly with objrmap, so I've come across those problems quite a lot, but what I noticed is that you mostly don't care about the VMA to be uniform, just it to be linear or not (because nonlinear VMAs break objrmap). This patch, in comparison, is just: *) check permissions in the generic VM when faulting in pages, if and only if the vma is nonuniform (yes, nontrivial at all). *) be anally picky to save the PTE protections together with the rest, and do it *everywhere*; but if you say "nonuniform implies linear", you lose this problem almost completely. The only exception is that when you remap an address range with PROT_NONE (thus effectively unmapping those addressed), you can't clear the PTEs but you must use pfn_pte(0, __S000) to fill them in (this is done in the optimization-fixup patch #15). > That has settled down now, but I don't look forward to extending it. > On the other hand, UML does deserve better support. > Hugh -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 12:06:47PM -0700, Chris Wedgwood wrote: > On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote: > > > Wouldn't it be better to put overmount_rootfs in initramfs.c > > and call it only if there's a initramfs? > > I don't see what or how that helps. Yes we can shuffle some code > about but the real problem still exists. > > That is is that (by design) the early userspace is unpacked as soon as > possible before all kernel subsystems are up. Overmount_rootfs shouldn't take place until you know for sure the kernel detects an initramfs. I know the patch only has one purpose and you can assume the user is using it just for that, but if the user uses the patched kernel without an initramfs it runs overmount_rootfs anyway. Also, in shmem.c init_tmpfs isn't run because it assumes that overmount_rootfs will be, so if the kernel is being used in a non initramfs way (tmpfs isn't registered). #ifndef CONFIG_EARLYUSERSPACE_ON_TMPFS module_init(init_tmpfs) #endif /* !CONFIG_EARLYUSERSPACE_ON_TMPFS */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kgdb on EM64T
George Anzinger wrote: Wilkerson, Bryan P wrote: Thanks you Tom and George for the tips on using kgdb with 2.6.13-rc4-mm1. I almost have it working but kgdb seems to have a few issues. I can get it running from the dev machine using the kgdb and console=kgdb boot options on the test kernel. The kernel waits as it should and when I attach with "target remote /dev/ttyS0" and I can continue the boot but eventually it gets to a point in the boot where it frees unused kernel memory successfully and then a warning, "unable to open an initial console", followed by, "Kernel panic - not syncing: Attempted to kill init!" Removing the console=kgdb boot option and the machine boots all the way to run level 5. I tried to break into kgdb at this point using the $echo -e "\003" > /dev/ttyS0 from the dev machine but the test kernel panics at gdb_interrupt+75 when it receives anything on the serial port. Hmmm... I'm wondering if I'm maybe just the first to try this on EM64T (kernel builds in the arch/x86_64 tree). Possibly:). Since the serial port seems to work (i.e. the first test above), the fault seems to be in handling the int3. Is int3 the right instruction for this machine? If not you would make the change in kgdb.h. I think that is the only place it is defined. Well, I checked, it is "int $3". Why then the panic? If you try the boot with kgdb (i.e. wait) and the do: (gdb) disass gdb_interrupt What do you find at +75? -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On Gwe, 2005-08-26 at 15:37 -0400, Robert Love wrote: > Second, we don't know a DMI-based solution will work. I'll check it out. Another good sanity check would be tool for the right bridge chips with device->subvendor == IBM ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Need better is_better_time_interpolator() algorithm
Christoph Lameter wrote: On Fri, 26 Aug 2005, Alex Williamson wrote: Would we ever want to favor a frequency shifting timer over anything else in the system? If it was noticeable perhaps we'd just need a callback to re-evaluate the frequency and rescan for the best timer. If it happens without notice, a flag that statically assigns it the lowest priority will due. Or maybe if the driver factored the frequency shifting into the drift it would make the timer undesirable without resorting to flags. Thanks, Timers are usually constant. AFAIK Frequency shifts only occur through power management. In that case we usually have some notifiers running before the change. These notifiers need to switch to a different time source if the timer frequency will be shifting or the timer will become unavailable. If there is a notifier, I presume we can track it. We might want to refine things so as to not hit too big a bump when the shift occures, but I think it is doable. The desirability of doing it, I think, depends on the availablity of something better. The access time of the TSC is "really" enticing. Even so, I think a _good_ clock would not depend on long term accuracy of something as fast as the TSC. Vendors are even modulating these to reduce RFI, but still, because of its speed, it makes the best interpolator for the jiffie to jiffie times. -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [CIFS] Fix for oops in fs/locks.c in 2.6.13-rc running connectathon byte range lock test over cifs
[CIFS] Fix oops in fs/locks.c on close of file with pending locks The recent change to locks_remove_flock code in fs/locks.c changes how byte range locks are removed from closing files, which shows up a bug in cifs. The assumption in the cifs code was that the close call sent to the server would remove any pending locks on the server on this file, but that is no longer safe as the fs/locks.c code on the client wants unlock of 0 to PATH_MAX to remove all locks (at least from this client, it is not possible AFAIK to remove all locks from other clients made to the server copy of the file). Note that cifs locks are different from posix locks - and it is not possible to map posix locks perfectly on the wire yet, due to restrictions of the cifs network protocol, even to Samba without adding a new request type to the network protocol (which we plan to do for Samba 3.0.21 within a few months), but the local client will have the correct, posix view, of the lock in most cases. The correct fix for cifs for this would involve a bigger change than I would like to do this late in the 2.6.13-rc cycle - and would involve cifs keeping track of all unmerged (uncoalesced) byte range locks for each remote inode and scanning that list to remove locks that intersect or fall wholly within the range - locks that intersect may have to be reaquired with the smaller, remaining range. Signed-off-by: Steve French <[EMAIL PROTECTED]> Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]> diff -Naur linux-2.6.13-rc7/fs/cifs/file.c linux/fs/cifs/file.c --- linux-2.6.13-rc7/fs/cifs/file.c 2005-06-17 14:48:29.0 -0500 +++ linux/fs/cifs/file.c2005-08-26 07:40:37.0 -0500 @@ -643,7 +643,7 @@ netfid, length, pfLock->fl_start, numUnlock, numLock, lockType, wait_flag); - if (rc == 0 && (pfLock->fl_flags & FL_POSIX)) + if (pfLock->fl_flags & FL_POSIX) posix_lock_file_wait(file, pfLock); FreeXid(xid); return rc; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: suspicious behaviour in pcwd driver.
Hi! > > 2. that printk will never hit the logs, so the admin will just find > > a powered off box with no idea what happened. > > Should we at least sync block devices before doing the power off ? > > AFAICS, this is still a problem with kernel_power_off() though ? > Look at how acpi does this; we probably want to trigger clean shutdown. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On Fri, 2005-08-26 at 15:39 -0400, Robert Love wrote: > > This is racy - 2 threads can try to do this simultaneously. > > Fixed. Thanks. Actually, doesn't sysfs and/or the vfs layer serialize the two simultaneous writes? Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Posix file attribute support on VFAT (take #2)
Hi! > > Unfortunately, it makes sense. If you have compact flash card, you > > really want to have VFAT there, so that it is a) compatible with > > windows and b) so that you don't kill the hardware. > > VFAT is plenty good at killing hardware. It's a terrible filesystem for > flash cards (if they don't do their own wear leveling properly). Most Well, they actually do test those cards with VFAT. Rumors are, they have some VFAT specific hacks in flash card firmware. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix whitespace handling on sysfs attributes
Hi! > The first version of this patch didn't allow for the request firmware > case which does multiple parsing passes on the parameter. This was > discussed in the thread '2.6.13-rc6-mm1' I still thing this is very wrong to do. sysfs should not try to outguess users. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] [IPV4]: Fix DST leak in icmp_push_reply()
-stable review patch. If anyone has any objections, please let us know.
--
Based upon a bug report and initial patch by
Ollie Wild.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: "David S. Miller" <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/ipv4/icmp.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.12.y/net/ipv4/icmp.c
===
--- linux-2.6.12.y.orig/net/ipv4/icmp.c
+++ linux-2.6.12.y/net/ipv4/icmp.c
@@ -349,12 +349,12 @@ static void icmp_push_reply(struct icmp_
{
struct sk_buff *skb;
- ip_append_data(icmp_socket->sk, icmp_glue_bits, icmp_param,
- icmp_param->data_len+icmp_param->head_len,
- icmp_param->head_len,
- ipc, rt, MSG_DONTWAIT);
-
- if ((skb = skb_peek(_socket->sk->sk_write_queue)) != NULL) {
+ if (ip_append_data(icmp_socket->sk, icmp_glue_bits, icmp_param,
+ icmp_param->data_len+icmp_param->head_len,
+ icmp_param->head_len,
+ ipc, rt, MSG_DONTWAIT) < 0)
+ ip_flush_pending_frames(icmp_socket->sk);
+ else if ((skb = skb_peek(_socket->sk->sk_write_queue)) != NULL) {
struct icmphdr *icmph = skb->h.icmph;
unsigned int csum = 0;
struct sk_buff *skb1;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Need better is_better_time_interpolator() algorithm
On Fri, 26 Aug 2005, Alex Williamson wrote: >Would we ever want to favor a frequency shifting timer over anything > else in the system? If it was noticeable perhaps we'd just need a > callback to re-evaluate the frequency and rescan for the best timer. If > it happens without notice, a flag that statically assigns it the lowest > priority will due. Or maybe if the driver factored the frequency > shifting into the drift it would make the timer undesirable without > resorting to flags. Thanks, Timers are usually constant. AFAIK Frequency shifts only occur through power management. In that case we usually have some notifiers running before the change. These notifiers need to switch to a different time source if the timer frequency will be shifting or the timer will become unavailable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On Fri, 2005-08-26 at 15:33 -0400, Jeff Garzik wrote: > Since such a check is possible, that's definitely a merge-stopper IMO First, I am not asking that Linus merge this. Everyone needs to relax. Second, we don't know a DMI-based solution will work. I'll check it out. Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On Fri, 2005-08-26 at 14:27 -0500, Dmitry Torokhov wrote: > What this completion is used for? I don't see any other references to it. It was the start of the release() routine, but I decided to move to platform_device_register_simple() and use its release, instead. So this is gone now in my tree. > I'd rather you used absolute coordinates and set up > hdaps_idev->absfuzz to do the filtering. Me too. > This is racy - 2 threads can try to do this simultaneously. Fixed. Thanks. > > + > > + device_create_file(_plat_dev.dev, _attr_position); > > + device_create_file(_plat_dev.dev, _attr_variance); > > + device_create_file(_plat_dev.dev, _attr_temp); > > + device_create_file(_plat_dev.dev, _attr_calibrate); > > + device_create_file(_plat_dev.dev, _attr_mousedev); > > + device_create_file(_plat_dev.dev, > > _attr_mousedev_threshold); > > + device_create_file(_plat_dev.dev, _attr_mousedev_poll_ms); > > + > > What about using sysfs_attribute_group? I don't see this in my tree? Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kgdb on EM64T
Wilkerson, Bryan P wrote: Thanks you Tom and George for the tips on using kgdb with 2.6.13-rc4-mm1. I almost have it working but kgdb seems to have a few issues. I can get it running from the dev machine using the kgdb and console=kgdb boot options on the test kernel. The kernel waits as it should and when I attach with "target remote /dev/ttyS0" and I can continue the boot but eventually it gets to a point in the boot where it frees unused kernel memory successfully and then a warning, "unable to open an initial console", followed by, "Kernel panic - not syncing: Attempted to kill init!" Removing the console=kgdb boot option and the machine boots all the way to run level 5. I tried to break into kgdb at this point using the $echo -e "\003" > /dev/ttyS0 from the dev machine but the test kernel panics at gdb_interrupt+75 when it receives anything on the serial port. Hmmm... I'm wondering if I'm maybe just the first to try this on EM64T (kernel builds in the arch/x86_64 tree). Possibly:). Since the serial port seems to work (i.e. the first test above), the fault seems to be in handling the int3. Is int3 the right instruction for this machine? If not you would make the change in kgdb.h. I think that is the only place it is defined. -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
Robert Love wrote: On Fri, 2005-08-26 at 20:55 +0100, Alan Cox wrote: I think that should be fixed before its merged. Let me be clear, it has an init routine that effectively probes for the device. It just lacks a simple quick non-invasive check. Since such a check is possible, that's definitely a merge-stopper IMO Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote:
> +/* device class stuff */
> +
> +static DECLARE_COMPLETION(hdaps_obj_is_free);
> +static void hdaps_release_dev(struct device *dev)
> +{
> + complete(_obj_is_free);
> +}
> +
What this completion is used for? I don't see any other references to it.
> +
> +static void hdaps_mousedev_poll(unsigned long unused)
> +{
> + int movex, movey, x, y, ret;
> +
> + ret = accelerometer_read_pair(HDAPS_PORT_XPOS, HDAPS_PORT_YPOS, ,
> );
> + if (unlikely(ret))
> + return;
> +
> + movex = rest_x - x;
> + movey = rest_y - y;
> + if (abs(movex) > hdaps_mousedev_threshold)
> + input_report_rel(_idev, REL_Y, movex);
> + if (abs(movey) > hdaps_mousedev_threshold)
> + input_report_rel(_idev, REL_X, movey);
> + input_sync(_idev);
> +
> + mod_timer(_poll_timer, jiffies +
> msecs_to_jiffies(hdaps_poll_ms));
> +}
> +
I'd rather you used absolute coordinates and set up
hdaps_idev->absfuzz to do the filtering.
> +static ssize_t hdaps_mousedev_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int enable;
> +
> + if (sscanf(buf, "%d\n", ) != 1)
> + return -EINVAL;
> +
> + if (enable == 1)
> + hdaps_mousedev_enable();
> + else if (enable == 0)
> + hdaps_mousedev_disable();
> +
> + return count;
> +}
> +
This is racy - 2 threads can try to do this simultaneously.
> +
> + device_create_file(_plat_dev.dev, _attr_position);
> + device_create_file(_plat_dev.dev, _attr_variance);
> + device_create_file(_plat_dev.dev, _attr_temp);
> + device_create_file(_plat_dev.dev, _attr_calibrate);
> + device_create_file(_plat_dev.dev, _attr_mousedev);
> + device_create_file(_plat_dev.dev, _attr_mousedev_threshold);
> + device_create_file(_plat_dev.dev, _attr_mousedev_poll_ms);
> +
What about using sysfs_attribute_group?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On Fri, 2005-08-26 at 20:55 +0100, Alan Cox wrote: > I think that should be fixed before its merged. Let me be clear, it has an init routine that effectively probes for the device. It just lacks a simple quick non-invasive check. The driver will definitely fail to load on a laptop without the requisite hardware. Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] [PATCH] Revert unnecessary zlib_inflate/inftrees.c fix
-stable review patch. If anyone has any objections, please let us know.
--
It turns out that empty distance code tables are not an error, and that
a compressed block with only literals can validly have an empty table
and should not be flagged as a data error.
Some old versions of gzip had problems with this case, but it does not
affect the zlib code in the kernel.
Analysis and explanations thanks to Sergey Vlasov <[EMAIL PROTECTED]>
Cc: Sergey Vlasov <[EMAIL PROTECTED]>
Cc: Tavis Ormandy <[EMAIL PROTECTED]>
Cc: Tim Yamin <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
lib/zlib_inflate/inftrees.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.12.y/lib/zlib_inflate/inftrees.c
===
--- linux-2.6.12.y.orig/lib/zlib_inflate/inftrees.c
+++ linux-2.6.12.y/lib/zlib_inflate/inftrees.c
@@ -141,7 +141,7 @@ static int huft_build(
{
*t = NULL;
*m = 0;
-return Z_DATA_ERROR;
+return Z_OK;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Need better is_better_time_interpolator() algorithm
On Fri, 2005-08-26 at 12:16 -0700, George Anzinger wrote: > Alex Williamson wrote: > > On Fri, 2005-08-26 at 08:39 -0700, Christoph Lameter wrote: > >>1. If a system boots up with a single cpu then there is no question that > >>the ITC/TSC should be used because of the fast access. > > We need to factor in frequency shifting here, especially if it happens > with out notice. Would we ever want to favor a frequency shifting timer over anything else in the system? If it was noticeable perhaps we'd just need a callback to re-evaluate the frequency and rescan for the best timer. If it happens without notice, a flag that statically assigns it the lowest priority will due. Or maybe if the driver factored the frequency shifting into the drift it would make the timer undesirable without resorting to flags. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] [IPSEC] Restrict socket policy loading to CAP_NET_ADMIN - CAN-2005-2555
-stable review patch. If anyone has any objections, please let us know. -- The interface needs much redesigning if we wish to allow normal users to do this in some way. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Signed-off-by: "David S. Miller" <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- net/ipv4/ip_sockglue.c |3 +++ net/ipv6/ipv6_sockglue.c |3 +++ 2 files changed, 6 insertions(+) Index: linux-2.6.12.y/net/ipv4/ip_sockglue.c === --- linux-2.6.12.y.orig/net/ipv4/ip_sockglue.c +++ linux-2.6.12.y/net/ipv4/ip_sockglue.c @@ -848,6 +848,9 @@ mc_msf_out: case IP_IPSEC_POLICY: case IP_XFRM_POLICY: + err = -EPERM; + if (!capable(CAP_NET_ADMIN)) + break; err = xfrm_user_policy(sk, optname, optval, optlen); break; Index: linux-2.6.12.y/net/ipv6/ipv6_sockglue.c === --- linux-2.6.12.y.orig/net/ipv6/ipv6_sockglue.c +++ linux-2.6.12.y/net/ipv6/ipv6_sockglue.c @@ -503,6 +503,9 @@ done: break; case IPV6_IPSEC_POLICY: case IPV6_XFRM_POLICY: + retv = -EPERM; + if (!capable(CAP_NET_ADMIN)) + break; retv = xfrm_user_policy(sk, optname, optval, optlen); break; -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On Gwe, 2005-08-26 at 13:33 -0400, Brian Gerst wrote: > Is there any way to detect that this device is present (PCI, ACPI, etc.) > without poking at ports? DMI or probably IBM ssid values. Presumably IBM have somewhere they look for this information ? Making the driver only load on a DMI match or with an option "force=1" which tells people to submit the DMI data would rapidly fill a table if IBM can't answer the general question. At the very least it should check for an ibm laptop first. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver.
On Gwe, 2005-08-26 at 14:03 -0400, Robert Love wrote: > On Fri, 2005-08-26 at 20:01 +0200, Arjan van de Ven wrote: > > > > Not that we've been able to tell. It is a legacy platform device. > > > > > > So, unfortunately, no probe() routine. > > > > dmi surely > > Patches accepted. I think that should be fixed before its merged. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] [PATCH] fix gl_skb/skb type error in genelink driver in usbnet
-stable review patch. If anyone has any objections, please let us know. -- I think there is a type error when port genelink driver to 2.6.. With this error, a linux host will panic when it link with a windows host. Cc: David Brownell <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- drivers/usb/net/usbnet.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.12.y/drivers/usb/net/usbnet.c === --- linux-2.6.12.y.orig/drivers/usb/net/usbnet.c +++ linux-2.6.12.y/drivers/usb/net/usbnet.c @@ -1922,7 +1922,7 @@ static int genelink_rx_fixup (struct usb // copy the packet data to the new skb memcpy(skb_put(gl_skb, size), packet->packet_data, size); - skb_return (dev, skb); + skb_return (dev, gl_skb); } // advance to the next packet -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] [PATCH] NPTL signal delivery deadlock fix
-stable review patch. If anyone has any objections, please let us know.
--
This bug is quite subtle and only happens in a very interesting
situation where a real-time threaded process is in the middle of a
coredump when someone whacks it with a SIGKILL. However, this deadlock
leaves the system pretty hosed and you have to reboot to recover.
Not good for real-time priority-preemption applications like our
telephony application, with 90+ real-time (SCHED_FIFO and SCHED_RR)
processes, many of them multi-threaded, interacting with each other for
high volume call processing.
Acked-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
kernel/signal.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.12.y/kernel/signal.c
===
--- linux-2.6.12.y.orig/kernel/signal.c
+++ linux-2.6.12.y/kernel/signal.c
@@ -686,7 +686,7 @@ static void handle_stop_signal(int sig,
{
struct task_struct *t;
- if (p->flags & SIGNAL_GROUP_EXIT)
+ if (p->signal->flags & SIGNAL_GROUP_EXIT)
/*
* The process is in the middle of dying already.
*/
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] [IPV6]: Fix SKB leak in ip6_input_finish()
-stable review patch. If anyone has any objections, please let us know.
--
Changing it to how ip_input handles should fix it.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: "David S. Miller" <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/ipv6/ip6_input.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6.12.y/net/ipv6/ip6_input.c
===
--- linux-2.6.12.y.orig/net/ipv6/ip6_input.c
+++ linux-2.6.12.y/net/ipv6/ip6_input.c
@@ -198,12 +198,13 @@ resubmit:
if (!raw_sk) {
if (xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb)) {
IP6_INC_STATS_BH(IPSTATS_MIB_INUNKNOWNPROTOS);
- icmpv6_param_prob(skb, ICMPV6_UNK_NEXTHDR,
nhoff);
+ icmpv6_send(skb, ICMPV6_PARAMPROB,
+ ICMPV6_UNK_NEXTHDR, nhoff,
+ skb->dev);
}
- } else {
+ } else
IP6_INC_STATS_BH(IPSTATS_MIB_INDELIVERS);
- kfree_skb(skb);
- }
+ kfree_skb(skb);
}
rcu_read_unlock();
return 0;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] [PATCH] sg.c: fix a memory leak in devices seq_file implementation (2nd)
-stable review patch. If anyone has any objections, please let us know.
--
I know that scsi procfs is legacy code but this is a fix for a memory leak.
While reading through sg.c I realized that the implementation of
/proc/scsi/sg/devices with seq_file is leaking memory due to freeing the
pointer returned by the next() iterator method. Since next() might
return NULL or an error this is wrong. This patch fixes it through using
the seq_files private field for holding the reference to the iterator
object.
Here is a small bash script to trigger the leak. Use slabtop to watch
the size-32 usage grow and grow.
#!/bin/sh
while true; do
cat /proc/scsi/sg/devices > /dev/null
done
Signed-off-by: Jan Blunck <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
drivers/scsi/sg.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6.12.y/drivers/scsi/sg.c
===
--- linux-2.6.12.y.orig/drivers/scsi/sg.c
+++ linux-2.6.12.y/drivers/scsi/sg.c
@@ -2969,23 +2969,22 @@ static void * dev_seq_start(struct seq_f
{
struct sg_proc_deviter * it = kmalloc(sizeof(*it), GFP_KERNEL);
+ s->private = it;
if (! it)
return NULL;
+
if (NULL == sg_dev_arr)
- goto err1;
+ return NULL;
it->index = *pos;
it->max = sg_last_dev();
if (it->index >= it->max)
- goto err1;
+ return NULL;
return it;
-err1:
- kfree(it);
- return NULL;
}
static void * dev_seq_next(struct seq_file *s, void *v, loff_t *pos)
{
- struct sg_proc_deviter * it = (struct sg_proc_deviter *) v;
+ struct sg_proc_deviter * it = s->private;
*pos = ++it->index;
return (it->index < it->max) ? it : NULL;
@@ -2993,7 +2992,9 @@ static void * dev_seq_next(struct seq_fi
static void dev_seq_stop(struct seq_file *s, void *v)
{
- kfree (v);
+ struct sg_proc_deviter * it = s->private;
+
+ kfree (it);
}
static int sg_proc_open_dev(struct inode *inode, struct file *file)
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: remove-stale-comment-from-swapfilec.patch added to -mm tree
On Fri, 26 Aug 2005, Blaisorblade wrote: > On Wednesday 24 August 2005 15:26, Hugh Dickins wrote: > > > If do_swap_page gets > > a write fault, it either determines it can go ahead and use the swap > > page, or if it can't, gets do_wp_page to Copy-On-Write for it (that's > > a call I added in 2.6.7, as an optimization, and as a necessity for > > correct behaviour of ptrace's get_user_pages; the latter has just in > > 2.6.13-rc been made more resilient, so we could remove do_swap_page's > > call to do_wp_page now - though I'm inclined to let it stay as an > > optimization, avoiding the second fault which would follow). > get_user_pages() can still get two faults there, because VM_FAULT_WRITE is > not > returned by do_swap_page(). And faults can be very expensive (for UML a fault > is given by a SIGSEGV delivery). You're right that it can get two "faults" there, but it's such a rare case (ptrace modifying an area readonly to the process) that I didn't bother about it. It isn't even two real faults, just two iterations within get_user_pages - or does that somehow get worse in the UML case? > > If do_swap_page gets a read fault, it doesn't COW at all. > > > I don't know what the "early" COW break referred to is: the write_access > > call to do_wp_page could be deferred, yes, but it's hardly early. > The idea in my mind is that after loading the page from swap the first time > there's no need to copy the page to give a private copy to the process, if > the page is kept on swap. > > We COW it anyway to break the sharing, to keep the original copy in the > swapcache, instead of reading it again from the disk. This is *early*. We always prefer not to read from the disk. You're right that we could choose to remove the page from the swap cache at that point (locking considerations?) and make it private (in the case where it has actually been written to the disk, often not yet so), but that's not how the page cache has ever been treated. Avoid going to slow disk at all costs. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] -stable review
This is the start of the stable review cycle for the 2.6.12.6 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name tothe list. If you want to be off the reviewer list, also email us. Responses should be made by Sun Aug 28 19:00 UTC 2005. Anything received after that time, might be too late. thanks, the -stable release team -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Need better is_better_time_interpolator() algorithm
Alex Williamson wrote: On Fri, 2005-08-26 at 08:39 -0700, Christoph Lameter wrote: I think a priority is something useful for the interpolators. Some of the decisions about which time sources to use also have criteria different from drift/latency/jitter/cpu. F.e. timers may not survive various power-saving configurations. Thus I would think that we need a priority plus some flags. Some of the criteria for choosing a time source may be: Hi Christoph, I sent another followup to this thread with a patch containing a fairly crude algorithm that I think better explains my starting point. I'm sure the weighting and scaling factors need work, but I think many of the criteria you describe will favor the right clock. 1. If a system boots up with a single cpu then there is no question that the ITC/TSC should be used because of the fast access. We need to factor in frequency shifting here, especially if it happens with out notice. ~ -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote: > I'm curious as to why the kernel has to include the decoder - why > you can't just run a self-extracting executable in an empty > initramfs (with a preset capacity if needs be). You could do tht right now if you wished. We just support decompression in the kernel because it's not overly painful to do so (the code exists and works fairly well for the most part). The code to do so isn't ver large and it's marked __init too (well, it should be). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote: > What if you have a root.cpio.gz that requires 200MB to hold, but you > only have 300MB of memory? then it won't work with nay of the schemes you've suggested > 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%). no, actually it won't - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12 Performance problems
On Thu, Aug 25, 2005 at 09:55:27AM -0700, Ben Greear wrote: > Of course. Never found a motherboard yet with decent built-in > NICs. The built-ins on this board are tg3 and they must be on > a slow bus, because they cannot go faster than about 700Mbps > (using big pkts). There should be a number of decent boards out on the market these days. Try picking up one with a CSA gige adapter (a dedicated high bandwidth link to an e1000) or PCI Express (although that is harder to pick up on from the specifications of most motherboards). -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [patch 0/18] remap_file_pages protection support (for UML), try 3
On Fri, 26 Aug 2005, Blaisorblade wrote: > This is a followup to my post of last week (Aug 12) about remap_file_pages > protection support. I've improved and consolidated the patches and updated > them against 2.6.13-rc6/rc7 (the same patches apply against both versions). > I'm sending the full patch series only to akpm, mingo and LKML. > > I've also reduced them to only 18, and made the splitting more significant. > I'm not resending all the patches for foreign architectures, because they're > almost unchanged since last time (there's just a trivial reject from ppc32, > because one change has already been done after -rc4). > > I'm working on this to provide support for UML, which currently easily > creates > more than 64K (the default limit) vma's for a single process. Actually, it > needs one VMA per each page. So, with this patch and specific UML support, > which Ingo wrote and which I'm porting to recent UMLs. I'll try to take a look sometime next week - or, if I wait until next Friday, can we expect it to have come down to 9 patches ;-? I should say, my initial reaction is very much like Andi's last week. sys_remap_file_pages solves a real problem, but it does so by breaking lots of rules. For more than a year after it came in, almost every development we tried in mm would come up against "but then what do we do about the nonlinear mappings?". That has settled down now, but I don't look forward to extending it. On the other hand, UML does deserve better support. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote: > Wouldn't it be better to put overmount_rootfs in initramfs.c > and call it only if there's a initramfs? I don't see what or how that helps. Yes we can shuffle some code about but the real problem still exists. That is is that (by design) the early userspace is unpacked as soon as possible before all kernel subsystems are up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Fixup symlink function pointers for hppfs [for 2.6.13]
On Fri, Aug 26, 2005 at 04:57:44PM +0200, [EMAIL PROTECTED] wrote: > > From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> > > Update hppfs for the symlink functions prototype change. > Should be trivial, but please verify it's correct. > > Yes, I know the code I leave there is still _bogus_, see next patch for this. Assuming that the next patch was "hppfs: fix symlink error path", you've still left BS in there - > proc_file = dentry_open(dget(proc_dentry), NULL, O_RDONLY); is obviously wrong; at the very least you need vfsmount in there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: process creation time increases linearly with shmem
On Fri, 26 Aug 2005, Ross Biro wrote: > On 8/26/05, Rik van Riel <[EMAIL PROTECTED]> wrote: > > > > Filling in all the page table entries at the first fault to > > a VMA doesn't make much sense, IMHO. > > > > I suspect we would be better off without that extra complexity, > > unless there is a demonstrated benefit to it. > > You are probably right, but do you want to put in a patch that might > have a big performance impact in either direction with out verifying > it? > > My suggestion is safe, but most likely sub-optimal. What everyone > else is suggesting may be far better, but needs to be verified first. It all has to be verified, and the problem will be that some things fare well and others badly: how to reach a balanced decision? Following your suggestion is no more safe than not following it. > I'm suggesting that we change the code to do the same work fork would > have done on the first page fault immediately, since it's easy to > argue that it's not much worse than we have now and much better in > many cases, and then try to experiment and figure out what the > correct solution is. We don't know what work fork would have done, that information was in the ptes we decided not to bother to copy. Perhaps every pte of the vma was set, perhaps none, perhaps only one. Also, doing it at fault time has significantly more work to do than just zipping along the ptes incrementing page counts and clearing bits. I think; but probably much less extra work than I originally imagined, since Andrew gave us the gang lookup of the page cache. All the same, I'm with Rik: one of the great virtues of the original idea was its simplicity; I'd prefer not to add complexity. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
