* Re: [PATCH]: unaligned
From: Juan Quintela @ 2002-12-19 13:57 UTC (permalink / raw)
To: Ralf Baechle; +Cc: mipslist
In-Reply-To: <20021219143115.A24914@linux-mips.org>
>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:
ralf> On Thu, Dec 19, 2002 at 11:40:38AM +0100, Juan Quintela wrote:
>> - asm wants a unsigned long
>> - verify_area wants a void *
>> one of the two places need a cast.
ralf> Making emulate_load_store take a void * as the address argument was much
ralf> nicer instead.
I didn't wanted to touch asm() parts yet :)
>> Once there, ralf? forgot that emulate_load_store returns void, then
>> nuke the return 1 part.
ralf> Already did that.
nice.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [PATCH 2.4.21-pre2 RESEND] sonypi driver update
From: Stelian Pop @ 2002-12-19 13:58 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Marcelo Tosatti, Alan Cox
Hi,
This little patch changes the way button release events are reported
by the sonypi driver to the application: previously, separate
release events were detected for each button. However, many buttons
(example: the jogdial, the capture button, the back button etc) share
the same release event.
The attached patch propagates a single 'ANYBUTTON_RELEASED' event
to the userspace, leaving all state machine intelligence to the
application.
Kunihiko IMAI should be credited for his ideas and tests.
Alan, Marcelo, please apply.
Stelian.
===== include/linux/sonypi.h 1.7 vs edited =====
--- 1.7/include/linux/sonypi.h Mon Dec 2 12:19:31 2002
+++ edited/include/linux/sonypi.h Thu Dec 19 10:08:17 2002
@@ -43,9 +43,9 @@
#define SONYPI_EVENT_JOGDIAL_DOWN_PRESSED 3
#define SONYPI_EVENT_JOGDIAL_UP_PRESSED 4
#define SONYPI_EVENT_JOGDIAL_PRESSED 5
-#define SONYPI_EVENT_JOGDIAL_RELEASED 6
+#define SONYPI_EVENT_JOGDIAL_RELEASED 6 /* obsolete */
#define SONYPI_EVENT_CAPTURE_PRESSED 7
-#define SONYPI_EVENT_CAPTURE_RELEASED 8
+#define SONYPI_EVENT_CAPTURE_RELEASED 8 /* obsolete */
#define SONYPI_EVENT_CAPTURE_PARTIALPRESSED 9
#define SONYPI_EVENT_CAPTURE_PARTIALRELEASED 10
#define SONYPI_EVENT_FNKEY_ESC 11
@@ -93,6 +93,7 @@
#define SONYPI_EVENT_MEYE_OPPOSITE 53
#define SONYPI_EVENT_MEMORYSTICK_INSERT 54
#define SONYPI_EVENT_MEMORYSTICK_EJECT 55
+#define SONYPI_EVENT_ANYBUTTON_RELEASED 56
/* get/set brightness */
#define SONYPI_IOCGBRT _IOR('v', 0, __u8)
===== drivers/char/sonypi.h 1.12 vs edited =====
--- 1.12/drivers/char/sonypi.h Mon Dec 2 12:16:22 2002
+++ edited/drivers/char/sonypi.h Thu Dec 19 10:08:17 2002
@@ -37,7 +37,7 @@
#ifdef __KERNEL__
#define SONYPI_DRIVER_MAJORVERSION 1
-#define SONYPI_DRIVER_MINORVERSION 16
+#define SONYPI_DRIVER_MINORVERSION 17
#define SONYPI_DEVICE_MODEL_TYPE1 1
#define SONYPI_DEVICE_MODEL_TYPE2 2
@@ -171,6 +171,13 @@
u8 data;
u8 event;
};
+
+/* The set of possible button release events */
+static struct sonypi_event sonypi_releaseev[] = {
+ { 0x00, SONYPI_EVENT_ANYBUTTON_RELEASED },
+ { 0, 0 }
+};
+
/* The set of possible jogger events */
static struct sonypi_event sonypi_joggerev[] = {
{ 0x1f, SONYPI_EVENT_JOGDIAL_UP },
@@ -186,7 +193,6 @@
{ 0x5d, SONYPI_EVENT_JOGDIAL_VFAST_UP_PRESSED },
{ 0x43, SONYPI_EVENT_JOGDIAL_VFAST_DOWN_PRESSED },
{ 0x40, SONYPI_EVENT_JOGDIAL_PRESSED },
- { 0x00, SONYPI_EVENT_JOGDIAL_RELEASED },
{ 0, 0 }
};
@@ -195,7 +201,6 @@
{ 0x05, SONYPI_EVENT_CAPTURE_PARTIALPRESSED },
{ 0x07, SONYPI_EVENT_CAPTURE_PRESSED },
{ 0x01, SONYPI_EVENT_CAPTURE_PARTIALRELEASED },
- { 0x00, SONYPI_EVENT_CAPTURE_RELEASED },
{ 0, 0 }
};
@@ -293,6 +298,7 @@
unsigned long mask;
struct sonypi_event * events;
} sonypi_eventtypes[] = {
+ { SONYPI_DEVICE_MODEL_TYPE1, 0, 0xffffffff, sonypi_releaseev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x70, SONYPI_MEYE_MASK, sonypi_meyeev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x30, SONYPI_LID_MASK, sonypi_lidev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x60, SONYPI_CAPTURE_MASK, sonypi_captureev },
@@ -301,6 +307,7 @@
{ SONYPI_DEVICE_MODEL_TYPE1, 0x30, SONYPI_BLUETOOTH_MASK, sonypi_blueev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x40, SONYPI_PKEY_MASK, sonypi_pkeyev },
+ { SONYPI_DEVICE_MODEL_TYPE2, 0, 0xffffffff, sonypi_releaseev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x38, SONYPI_LID_MASK, sonypi_lidev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_JOGGER_MASK, sonypi_joggerev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_CAPTURE_MASK, sonypi_captureev },
===== drivers/char/sonypi.c 1.11 vs edited =====
--- 1.11/drivers/char/sonypi.c Fri Nov 22 14:49:08 2002
+++ edited/drivers/char/sonypi.c Wed Dec 11 12:34:16 2002
@@ -714,11 +714,11 @@
SONYPI_DRIVER_MAJORVERSION,
SONYPI_DRIVER_MINORVERSION);
printk(KERN_INFO "sonypi: detected %s model, "
- "verbose = %s, fnkeyinit = %s, camera = %s, "
+ "verbose = %d, fnkeyinit = %s, camera = %s, "
"compat = %s, mask = 0x%08lx\n",
(sonypi_device.model == SONYPI_DEVICE_MODEL_TYPE1) ?
"type1" : "type2",
- verbose ? "on" : "off",
+ verbose,
fnkeyinit ? "on" : "off",
camera ? "on" : "off",
compat ? "on" : "off",
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: bart @ 2002-12-19 13:55 UTC (permalink / raw)
To: davej
Cc: torvalds, lk, hpa, terje.eggestad, drepper, matti.aarnio, hugh,
mingo, linux-kernel
On 19 Dec, Dave Jones wrote:
> On Thu, Dec 19, 2002 at 02:22:36PM +0100, bart@etpmod.phys.tue.nl wrote:
> > > However, there's another issue, namely process startup cost. I personally
> > > want it to be as light as at all possible. I hate doing an "strace" on
> > > user processes and seeing tons and tons of crapola showing up. Just for
> > So why not map the magic page at 0xffffe000 at some other address as
> > well?
> > Static binaries can just directly jump/call into the magic page.
>
> .. and explode nicely when you try to run them on an older kernel
> without the new syscall magick. This is what Linus' first
> proof-of-concept code did.
True, but unless I really don't get it, compatibility of a new static
binary with an old kernel is going to break anyway.
My point was that the double-mapped page trick adds no overhead in the
case of a static binary, and just one extra mmap in case of a shared
binary.
Bart
>
> Dave
>
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
^ permalink raw reply
* Mapping driver + MT28F0083B
From: Gettert, Wolfram @ 2002-12-19 14:15 UTC (permalink / raw)
To: Linux MTD (E-mail)
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hallo,
this is a patch against CVS snapshot-20021217 for a mapping driver for the
CPCI-735/736.
It's the mapping driver and an additional flash in jedec_table[]. Would be
great to integrate that into the CVS.
I tested this with a 2.2.18 kernel.
Is there anything else todo? It's my first patch send to mailing list.
Wolfram
--
Wolfram Gettert
Software Engineer
Force Computers GmbH
- A Solectron Company -
Lilienthalstr. 15
D-85579 Neubiberg/München
Wolfram.Gettert_at_fci.com
www.forcecomputers.com
<<snapshot-20021217-mtd.diff>>
[-- Attachment #2: snapshot-20021217-mtd.diff --]
[-- Type: application/octet-stream, Size: 11842 bytes --]
diff -urN --exclude=CVS snapshots20021217/mtd/drivers/mtd/chips/jedec_probe.c snapshots20021217/mtd-735/drivers/mtd/chips/jedec_probe.c
--- snapshots20021217/mtd/drivers/mtd/chips/jedec_probe.c 2002-11-13 00:00:06.000000000 +0100
+++ snapshots20021217/mtd-735/drivers/mtd/chips/jedec_probe.c 2002-12-19 12:29:27.000000000 +0100
@@ -93,6 +93,10 @@
#define MX29F004T 0x0045
#define MX29F004B 0x0046
+/* Micron */
+#define MT28F800B3T 0x889c
+#define MT28F800B3B 0x889D
+
/* ST - www.st.com */
#define M29W800T 0x00D7
#define M29W160DT 0x22C4
@@ -612,7 +616,33 @@
NumEraseRegions: 1,
regions: {ERASEINFO(0x10000,16),
}
- }, {
+ }, {
+ mfr_id: MANUFACTURER_INTEL,
+ dev_id: MT28F800B3T,
+ name: "Micron MT28F800B3T",
+ DevSize: SIZE_1MiB,
+ CmdSet: P_ID_INTEL_STD,
+ NumEraseRegions: 4,
+ regions: {
+ ERASEINFO(0x20000,7),
+ ERASEINFO(0x18000,1),
+ ERASEINFO(0x02000,2),
+ ERASEINFO(0x04000,1),
+ }
+ }, {
+ mfr_id: MANUFACTURER_INTEL,
+ dev_id: MT28F800B3B,
+ name: "Micron MT28F800B3B",
+ DevSize: SIZE_1MiB,
+ CmdSet: P_ID_INTEL_STD,
+ NumEraseRegions: 4,
+ regions: {
+ ERASEINFO(0x04000,1),
+ ERASEINFO(0x02000,2),
+ ERASEINFO(0x18000,1),
+ ERASEINFO(0x20000,2),
+ }
+ }, {
mfr_id: MANUFACTURER_ST,
dev_id: M29W800T,
name: "ST M29W800T",
diff -urN --exclude=CVS snapshots20021217/mtd/drivers/mtd/maps/Config.in snapshots20021217/mtd-735/drivers/mtd/maps/Config.in
--- snapshots20021217/mtd/drivers/mtd/maps/Config.in 2002-10-20 01:00:06.000000000 +0200
+++ snapshots20021217/mtd-735/drivers/mtd/maps/Config.in 2002-12-19 11:54:53.000000000 +0100
@@ -30,6 +30,7 @@
dep_tristate ' JEDEC Flash device mapped on Mixcom piggyback card' CONFIG_MTD_MIXMEM $CONFIG_MTD_JEDEC
dep_tristate ' JEDEC Flash device mapped on Octagon 5066 SBC' CONFIG_MTD_OCTAGON $CONFIG_MTD_JEDEC
dep_tristate ' JEDEC Flash device mapped on Tempustech VMAX SBC301' CONFIG_MTD_VMAX $CONFIG_MTD_JEDEC
+ dep_tristate ' JEDEC Flash device mapped on FORCE Computers CPCI735/36' CONFIG_MTD_CPCI735 $CONFIG_MTD_JEDEC $CONFIG_MTD_CFI
dep_tristate ' BIOS flash chip on Intel L440GX boards' CONFIG_MTD_L440GX $CONFIG_MTD_JEDECPROBE
dep_tristate ' ROM connected to AMD76X southbridge' CONFIG_MTD_AMD76XROM $CONFIG_MTD_GEN_PROBE
dep_tristate ' ROM connected to Intel Hub Controller 2' CONFIG_MTD_ICH2ROM $CONFIG_MTD_JEDECPROBE
diff -urN --exclude=CVS snapshots20021217/mtd/drivers/mtd/maps/Kconfig snapshots20021217/mtd-735/drivers/mtd/maps/Kconfig
--- snapshots20021217/mtd/drivers/mtd/maps/Kconfig 2002-11-26 23:30:32.000000000 +0100
+++ snapshots20021217/mtd-735/drivers/mtd/maps/Kconfig 2002-12-19 11:56:17.000000000 +0100
@@ -128,6 +128,14 @@
Board Computer. More information on the board is available at
<http://www.tempustech.com/tt301.htm>.
+config MTD_CPCI735
+ tristate "JEDEC Flash device mapped on FORCE Computers CPCI-735/736"
+ depends on X86 && MTD_JEDEC && MTD_CFI
+ help
+ This provides a 'mapping' driver which supports the BIOS flash of
+ CPCI-735/CPCI-736.
+ FORCE Computers GmbH <http://www.forcecomputers.com>.
+
config MTD_SCx200_DOCFLASH
tristate "Flash device mapped with DOCCS on NatSemi SCx200"
depends on X86 && MTD_CFI
diff -urN --exclude=CVS snapshots20021217/mtd/drivers/mtd/maps/Makefile snapshots20021217/mtd-735/drivers/mtd/maps/Makefile
--- snapshots20021217/mtd/drivers/mtd/maps/Makefile 2002-11-28 00:00:10.000000000 +0100
+++ snapshots20021217/mtd-735/drivers/mtd/maps/Makefile 2002-12-19 11:47:43.000000000 +0100
@@ -59,5 +59,6 @@
obj-$(CONFIG_MTD_UCLINUX) += uclinux.o
obj-$(CONFIG_MTD_NETtel) += nettel.o
obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
+obj-$(CONFIG_MTD_CPCI735) += cpci735.o
include $(TOPDIR)/Rules.make
diff -urN --exclude=CVS snapshots20021217/mtd/drivers/mtd/maps/cpci735.c snapshots20021217/mtd-735/drivers/mtd/maps/cpci735.c
--- snapshots20021217/mtd/drivers/mtd/maps/cpci735.c 1970-01-01 01:00:00.000000000 +0100
+++ snapshots20021217/mtd-735/drivers/mtd/maps/cpci735.c 2002-12-19 12:39:05.000000000 +0100
@@ -0,0 +1,312 @@
+/*
+ * $Id: $
+ *
+ * Mappings for FORCE Computers CPCI-735/736 bios flash in physical memory.
+ *
+ * Derived from physmap.c done by David Woodhouse <dwmw2@infradead.org>
+ * Adopted for CPCI-735/736 by Wolfram Gettert <Wolfram.Gettert@fci.com>
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <asm/io.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/config.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+
+#define WINDOW_ADDR 0xFFF80000
+#define WINDOW_SIZE 0x80000
+#define BUSWIDTH 1
+
+#define WRITE_ENABLE 0x40
+#define RANGE_1MB 0x02
+
+#define FPGA1_INDEX 0x100
+#define FPGA1_DATA 0x101
+#define FPGA2_INDEX 0x102
+#define FPGA2_DATA 0x103
+
+#define OSB4_VENDOR_ID 0x1166
+#define OSB4_DEVICE_ID 0x0200
+
+#define FLASH_CONTROL_REG 0x07
+
+#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,2,22)
+#define __raw_readb readb
+#define __raw_readw readw
+#define __raw_readl readl
+#define __raw_writeb writeb
+#define __raw_writew writew
+#define __raw_writel writel
+#endif
+
+static char module_name[] = "BIOS flash";
+
+static struct mtd_erase_region_info fl_28F800_top[] =
+{
+ {
+ offset: 0x00000000,
+ erasesize: 0x10000, //32 Kword
+ numblocks: 7, //we only use the upper 512 Kbyte
+ }, {
+ offset: 0x78000,
+ erasesize: 0x1000, //
+ numblocks: 6,
+ }, {
+ offset: 0x7E000,
+ erasesize: 0x1000,
+ numblocks: 2,
+ }
+};
+
+static inline void map_udelay(int us)
+{
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
+ unsigned long t = us * HZ / 1000000;
+ if (t) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(t);
+ return;
+ }
+#endif
+ udelay(us);
+ cond_resched();
+}
+
+
+static struct mtd_info *mymtd;
+/*static struct mtd_info mtd = {
+ type: MTD_NORFLASH,
+ flags: MTD_CAP_NORFLASH,
+ size: WINDOW_SIZE,
+ erasesize: 0x1000,
+ name: "CPCI-735 boot flash",
+ numeraseregions: sizeof(fl_28F800_top)/sizeof( struct mtd_erase_region_info),
+ eraseregions: fl_28F800_top,
+ module: THIS_MODULE,
+ erase: flash_erase,
+ read: flash_read,
+ write: flash_write,
+ lock: NULL,
+ unlock: NULL,
+ sync: NULL,
+ priv: (void *)0
+};
+*/
+__u8 cpci735_read8(struct map_info *map, unsigned long ofs)
+{
+
+ return __raw_readb(map->map_priv_1 + ofs);
+}
+
+__u16 cpci735_read16(struct map_info *map, unsigned long ofs)
+{
+ return __raw_readw(map->map_priv_1 + ofs);
+}
+
+__u32 cpci735_read32(struct map_info *map, unsigned long ofs)
+{
+ return __raw_readl(map->map_priv_1 + ofs);
+}
+
+void cpci735_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
+{
+ memcpy_fromio(to, map->map_priv_1 + from, len);
+}
+
+void cpci735_write8(struct map_info *map, __u8 d, unsigned long adr)
+{
+ __raw_writeb(d, map->map_priv_1 + adr);
+ mb();
+}
+
+void cpci735_write16(struct map_info *map, __u16 d, unsigned long adr)
+{
+ __raw_writew(d, map->map_priv_1 + adr);
+ mb();
+}
+
+void cpci735_write32(struct map_info *map, __u32 d, unsigned long adr)
+{
+ __raw_writel(d, map->map_priv_1 + adr);
+ mb();
+}
+
+void cpci735_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len)
+{
+ memcpy_toio(map->map_priv_1 + to, from, len);
+}
+
+struct map_info biosflash_map = {
+ name: module_name,
+ size: WINDOW_SIZE,
+ buswidth: BUSWIDTH,
+ read8: cpci735_read8,
+ read16: cpci735_read16,
+ read32: cpci735_read32,
+ copy_from: cpci735_copy_from,
+ write8: cpci735_write8,
+ write16: cpci735_write16,
+ write32: cpci735_write32,
+ copy_to: cpci735_copy_to
+};
+
+
+/* Set up the FPGA to be able to write to the flash */
+void enableFlash(void)
+{
+ char reg;
+
+ //Write-enable flash in FPGA2
+ outb(FLASH_CONTROL_REG,FPGA2_INDEX);
+ reg = inb(FPGA2_DATA);
+ DEBUG(MTD_DEBUG_LEVEL3,"%s: fpga2: data 0x%x\n",module_name,reg);
+ reg |= RANGE_1MB;
+ reg |= WRITE_ENABLE;
+ DEBUG(MTD_DEBUG_LEVEL3,"%s: fpga2: changed to data 0x%x\n",
+ module_name, reg);
+ outb(reg,FPGA2_DATA);
+}
+
+/* Set up the FPGA to be disable writing to the flash */
+void disableFlash(void)
+{
+ char reg;
+ //Write-disable flash in FPGA2
+ outb(FLASH_CONTROL_REG,FPGA2_INDEX);
+ reg = inb(FPGA2_DATA);
+ DEBUG(MTD_DEBUG_LEVEL3,"%s: fpga2: data 0x%x\n",module_name,reg);
+ reg &= (~RANGE_1MB);
+ reg &= (~WRITE_ENABLE);
+ DEBUG(MTD_DEBUG_LEVEL3,"%s: fpga2:changed to data 0x%x\n",
+ module_name,reg);
+ outb(reg,FPGA2_DATA);
+}
+
+int do_cpci_735_stuff_init(void)
+{
+ struct pci_dev *dev = NULL;
+ u8 reg41, reg0c6f=0;
+
+
+ enableFlash();
+
+ //Setup ISA misc control register, enable flash ROM
+ reg0c6f = inw(0xC6F);
+ reg0c6f |= 0x40;
+ outb(reg0c6f,0xC6F);
+ reg0c6f = inw(0xC6F);
+
+ //Set up OSB4 registers
+ dev = pci_find_device(OSB4_VENDOR_ID, OSB4_DEVICE_ID, dev);
+ if(dev)
+ {
+ pci_read_config_byte(dev, 0x41,®41);
+ reg41 |= 0x10;
+ pci_write_config_byte(dev, 0x41,reg41);
+ }
+ else
+ {
+ printk(KERN_NOTICE "%s: Couldn't find PCI device 0x%x:0x%x\n",
+ module_name,OSB4_VENDOR_ID,OSB4_DEVICE_ID);
+ return -EIO;
+ }
+ return 0;
+}
+
+int do_cpci_735_stuff_release(void)
+{
+ struct pci_dev *dev = NULL;
+ u8 reg41, reg0c6f=0;
+
+ disableFlash();
+ //Setup ISA misc control register, disable flash ROM
+ reg0c6f = inw(0xC6F);
+ reg0c6f &= (~0x40);
+ outb(reg0c6f,0xC6F);
+ reg0c6f = inw(0xC6F);
+
+ //Set up OSB4 registers
+ dev = pci_find_device(OSB4_VENDOR_ID, OSB4_DEVICE_ID, dev);
+ if(dev)
+ {
+ pci_read_config_byte(dev, 0x41,®41);
+ reg41 &= (~0x10);
+ pci_write_config_byte(dev, 0x41,reg41);
+ }
+ else
+ {
+ printk(KERN_NOTICE "%s: Couldn't find PCI device 0x%x:0x%x\n",
+ module_name,OSB4_VENDOR_ID,OSB4_DEVICE_ID);
+ return -EIO;
+ }
+ return 0;
+}
+
+
+int __init init_cpci735(void)
+{
+ static const char *rom_probe_types[] = {"jedec_probe", 0 };
+ const char **type;
+
+ printk(KERN_NOTICE "%s device: %x at %x\n",
+ module_name, WINDOW_SIZE, WINDOW_ADDR);
+ biosflash_map.map_priv_1 = (unsigned long)ioremap(WINDOW_ADDR, WINDOW_SIZE);
+ if (!biosflash_map.map_priv_1) {
+ printk("%s: Failed to ioremap\n",module_name);
+ return -EIO;
+ }
+
+ //Setup everything for write enable
+ if(do_cpci_735_stuff_init())
+ {
+ return -EIO;
+ }
+
+ DEBUG(MTD_DEBUG_LEVEL3,"%s: Start probing ...\n", module_name);
+ mymtd = 0;
+ type = rom_probe_types;
+ for(; !mymtd && *type; type++) {
+ DEBUG(MTD_DEBUG_LEVEL3,"%s: Probing %s\n",module_name, *type);
+ mymtd = do_map_probe(*type, &biosflash_map);
+ }
+ //The eraseregions are patched because only the upper 512 Kbyte
+ //are accesible
+ mymtd->numeraseregions = sizeof(fl_28F800_top)/sizeof( struct mtd_erase_region_info);
+ mymtd->eraseregions = fl_28F800_top;
+ if (mymtd) {
+ mymtd->module = THIS_MODULE;
+ add_mtd_device(mymtd);
+ return 0;
+ }
+
+ iounmap((void *)biosflash_map.map_priv_1);
+ return -ENXIO;
+}
+
+static void __exit cleanup_cpci735(void)
+{
+ if (mymtd)
+ {
+ del_mtd_device(mymtd);
+ map_destroy(mymtd);
+ }
+
+ if (biosflash_map.map_priv_1) {
+ iounmap((void *)biosflash_map.map_priv_1);
+ biosflash_map.map_priv_1 = 0;
+ }
+ do_cpci_735_stuff_release();
+}
+
+module_init(init_cpci735);
+module_exit(cleanup_cpci735);
+
+#ifdef MODULE_LICENSE
+ MODULE_LICENSE("GPL");
+#endif
+MODULE_AUTHOR("Wolfram Gettert <Wolfram.Gettert@fci.com>");
+MODULE_DESCRIPTION("BIOS flash MTD map driver for CPCI-735/736");
^ permalink raw reply
* raidtools-20010914
From: Jarmo Järvenpää @ 2002-12-19 13:38 UTC (permalink / raw)
To: linux-raid
- 3 RAID 1 devices with each having 2 partitions mirrored together.
- Kernel 2.4.20
I tried to remove /dev/hda1 from /dev/md0 by using raidhotgenerateerror
and got this:
md: trying to remove hda1 from md0 ...
md: bug in file md.c, line 2341
md: **********************************
md: * <COMPLETE RAID STATE PRINTOUT> *
md: **********************************
md0: <hde1><hda1> array superblock:
md: SB: (V:0.90.0) ID:<dafb19f4.cc607c07.b72647b4.6f585c6d> CT:3c18a44b
md: L1 S01024000 ND:3 RD:2 md0 LO:0 CS:8192
md: UT:3e01dcb3 ST:0 AD:2 WD:2 FD:1 SD:0 CSUM:f12faea4 E:00000050
D 0: DISK<N:0,hda1(3,1),R:0,S:6>
D 1: DISK<N:1,hde1(33,1),R:1,S:6>
D 2: DISK<N:2,[dev 00:00](0,0),R:2,S:9>
md: THIS: DISK<N:1,hde1(33,1),R:1,S:6>
md: rdev hde1: O:hde1, SZ:01024000 F:0 DN:1 <6>md: rdev superblock:
md: SB: (V:0.90.0) ID:<dafb19f4.cc607c07.b72647b4.6f585c6d> CT:3c18a44b
md: L1 S01024000 ND:3 RD:2 md0 LO:0 CS:8192
md: UT:3e01dcb3 ST:0 AD:2 WD:2 FD:1 SD:0 CSUM:f12fcb99 E:00000050
D 0: DISK<N:0,hda1(3,1),R:0,S:6>
D 1: DISK<N:1,hde1(33,1),R:1,S:6>
D 2: DISK<N:2,[dev 00:00](0,0),R:2,S:9>
md: THIS: DISK<N:1,hde1(33,1),R:1,S:6>
md: rdev hda1: O:hda1, SZ:01536064 F:0 DN:0 <6>md: rdev superblock:
md: SB: (V:0.90.0) ID:<dafb19f4.cc607c07.b72647b4.6f585c6d> CT:3c18a44b
md: L1 S01024000 ND:3 RD:2 md0 LO:0 CS:8192
md: UT:3e01dcb3 ST:0 AD:2 WD:2 FD:1 SD:0 CSUM:f12fcb79 E:00000050
D 0: DISK<N:0,hda1(3,1),R:0,S:6>
D 1: DISK<N:1,hde1(33,1),R:1,S:6>
D 2: DISK<N:2,[dev 00:00](0,0),R:2,S:9>
md: THIS: DISK<N:0,hda1(3,1),R:0,S:6>
md1: <hde5><hda5> array superblock:
md: SB: (V:0.90.0) ID:<9f552c55.10d01053.7e6a40ae.e9160862> CT:3c18a58a
md: L1 S05120000 ND:3 RD:2 md1 LO:0 CS:8192
md: UT:3e01dcb3 ST:0 AD:2 WD:2 FD:1 SD:0 CSUM:3b397b89 E:0000004d
D 0: DISK<N:0,hda5(3,5),R:0,S:6>
D 1: DISK<N:1,hde5(33,5),R:1,S:6>
D 2: DISK<N:2,[dev 00:00](0,0),R:2,S:9>
md: THIS: DISK<N:1,hde5(33,5),R:1,S:6>
md: rdev hde5: O:hde5, SZ:05120000 F:0 DN:1 <6>md: rdev superblock:
md: SB: (V:0.90.0) ID:<9f552c55.10d01053.7e6a40ae.e9160862> CT:3c18a58a
md: L1 S05120000 ND:3 RD:2 md1 LO:0 CS:8192
md: UT:3e01dcb3 ST:0 AD:2 WD:2 FD:1 SD:0 CSUM:3b39987e E:0000004d
D 0: DISK<N:0,hda5(3,5),R:0,S:6>
D 1: DISK<N:1,hde5(33,5),R:1,S:6>
D 2: DISK<N:2,[dev 00:00](0,0),R:2,S:9>
md: THIS: DISK<N:1,hde5(33,5),R:1,S:6>
md: rdev hda5: O:hda5, SZ:05120000 F:0 DN:0 <6>md: rdev superblock:
md: SB: (V:0.90.0) ID:<9f552c55.10d01053.7e6a40ae.e9160862> CT:3c18a58a
md: L1 S05120000 ND:3 RD:2 md1 LO:0 CS:8192
md: UT:3e01dcb3 ST:0 AD:2 WD:2 FD:1 SD:0 CSUM:3b39985e E:0000004d
D 0: DISK<N:0,hda5(3,5),R:0,S:6>
D 1: DISK<N:1,hde5(33,5),R:1,S:6>
D 2: DISK<N:2,[dev 00:00](0,0),R:2,S:9>
md: THIS: DISK<N:0,hda5(3,5),R:0,S:6>
md2: <hde6> array superblock:
md: SB: (V:0.90.0) ID:<7db46cc6.da202531.4acfe1c3.0a02808b> CT:3c18a596
md: L1 S53760064 ND:2 RD:2 md2 LO:0 CS:8192
md: UT:3e01dcb3 ST:0 AD:1 WD:1 FD:1 SD:0 CSUM:d3211a5a E:0000004b
D 0: DISK<N:0,[dev 00:00](0,0),R:0,S:9>
D 1: DISK<N:1,hde6(33,6),R:1,S:6>
D 2: DISK<N:2,[dev 00:00](0,0),R:2,S:9>
md: THIS: DISK<N:1,hde6(33,6),R:1,S:6>
md: rdev hde6: O:hde6, SZ:53760064 F:0 DN:1 <6>md: rdev superblock:
md: SB: (V:0.90.0) ID:<7db46cc6.da202531.4acfe1c3.0a02808b> CT:3c18a596
md: L1 S53760064 ND:2 RD:2 md2 LO:0 CS:8192
md: UT:3e01dcb3 ST:0 AD:1 WD:1 FD:1 SD:0 CSUM:d32136ef E:0000004b
D 0: DISK<N:0,[dev 00:00](0,0),R:0,S:9>
D 1: DISK<N:1,hde6(33,6),R:1,S:6>
D 2: DISK<N:2,[dev 00:00](0,0),R:2,S:9>
md: THIS: DISK<N:1,hde6(33,6),R:1,S:6>
md: **********************************
md: cannot remove active disk hda1 from md0 ...
md: trying to generate hda1 error in md0 ...
md: okay, generating error!
----------
> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5] [multipath]
read_ahead 1024 sectors
md0 : active raid1 hde1[1] hda1[0]
1024000 blocks [2/2] [UU]
...
So, it seems hotgenerateeror was not successful.
Any ideas?
Regards,
Jarmo
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Dave Jones @ 2002-12-19 13:38 UTC (permalink / raw)
To: bart
Cc: torvalds, lk, hpa, terje.eggestad, drepper, matti.aarnio, hugh,
davej, mingo, linux-kernel
In-Reply-To: <20021219132239.4650B51F88@gum12.etpnet.phys.tue.nl>
On Thu, Dec 19, 2002 at 02:22:36PM +0100, bart@etpmod.phys.tue.nl wrote:
> > However, there's another issue, namely process startup cost. I personally
> > want it to be as light as at all possible. I hate doing an "strace" on
> > user processes and seeing tons and tons of crapola showing up. Just for
> So why not map the magic page at 0xffffe000 at some other address as
> well?
> Static binaries can just directly jump/call into the magic page.
.. and explode nicely when you try to run them on an older kernel
without the new syscall magick. This is what Linus' first
proof-of-concept code did.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [PATCH]: unaligned
From: Ralf Baechle @ 2002-12-19 13:31 UTC (permalink / raw)
To: Juan Quintela; +Cc: mipslist
In-Reply-To: <m27ke6mgux.fsf@demo.mitica>
On Thu, Dec 19, 2002 at 11:40:38AM +0100, Juan Quintela wrote:
> - asm wants a unsigned long
> - verify_area wants a void *
> one of the two places need a cast.
Making emulate_load_store take a void * as the address argument was much
nicer instead.
> Once there, ralf? forgot that emulate_load_store returns void, then
> nuke the return 1 part.
Already did that.
Ralf
^ permalink raw reply
* [LARTC] Shaping traffic to local users ?
From: Dimitris Kotsonis @ 2002-12-19 13:30 UTC (permalink / raw)
To: lartc
Hello
Is it possible to shape incoming traffic for local linux users ?
Iptables can mark packets created from certain pid/uid/gid. Is there a
way to do the same for packets _destined_ for some pid/uid/gid so that I
can later shape them with IMQ ?
Thanks in advance
Dimitris Kotsonis
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: vt8235 fix, hopefully last variant
From: AnonimoVeneziano @ 2002-12-19 13:34 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: John Reiser, Patrick Petermair, Roland Quast, LKML
In-Reply-To: <20021219112640.A21164@ucw.cz>
Vojtech Pavlik wrote:
>Hi!
>
>Can you guys try out this last take on a fix for your ATAPI device
>problems? Applies against clean 2.4.20.
>
>Please report failure/success.
>
>Thanks.
>
>
>
>------------------------------------------------------------------------
>
>ChangeSet@1.884, 2002-12-19 11:23:11+01:00, vojtech@suse.cz
> VIA IDE: Always use slow address setup timings for ATAPI devices.
>
>
> via82cxxx.c | 19 ++++++-------------
> 1 files changed, 6 insertions(+), 13 deletions(-)
>
>
>diff -Nru a/drivers/ide/pci/via82cxxx.c b/drivers/ide/pci/via82cxxx.c
>--- a/drivers/ide/pci/via82cxxx.c Thu Dec 19 11:23:42 2002
>+++ b/drivers/ide/pci/via82cxxx.c Thu Dec 19 11:23:42 2002
>@@ -1,16 +1,5 @@
> /*
>- * $Id: via82cxxx.c,v 3.35-ac2 2002/09/111 Alan Exp $
>- *
>- * Copyright (c) 2000-2001 Vojtech Pavlik
>- *
>- * Based on the work of:
>- * Michel Aubry
>- * Jeff Garzik
>- * Andre Hedrick
>- */
>-
>-/*
>- * Version 3.35
>+ * Version 3.36
> *
> * VIA IDE driver for Linux. Supported southbridges:
> *
>@@ -152,7 +141,7 @@
> via_print("----------VIA BusMastering IDE Configuration"
> "----------------");
>
>- via_print("Driver Version: 3.35-ac");
>+ via_print("Driver Version: 3.36");
> via_print("South Bridge: VIA %s",
> via_config->name);
>
>@@ -351,6 +340,10 @@
> ide_timing_compute(peer, peer->current_speed, &p, T, UT);
> ide_timing_merge(&p, &t, &t, IDE_TIMING_8BIT);
> }
>+
>+ /* Always use 4 address setup clocks on ATAPI devices */
>+ if (drive->media != ide_disk)
>+ t.setup = 4;
>
> via_set_speed(HWIF(drive)->pci_dev, drive->dn, &t);
>
>
>
It said that 2 of 3 hunks are failed. I don't know why. Error in patch again
Bye
Marcello
^ permalink raw reply
* Re: heatload 0.4 now with throttling support
From: Ducrot Bruno @ 2002-12-19 13:23 UTC (permalink / raw)
To: Faye Pearson; +Cc: Malte Thoma, ACPI-Devel
In-Reply-To: <20021218180329.GA9439-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
On Wed, Dec 18, 2002 at 06:03:29PM +0000, Faye Pearson wrote:
> Malte Thoma [thoma-iYtK5bfT9M8b1SvskN2V4Q@public.gmane.org] wrote:
> > In which directory, in /proc/acpi or in ../thermal_zone ?
>
> Well, everything under /proc/acpi is well-known (so far at least)
> ac_adapter/
> thermal_zone/
> battery/
> processor/
> etc.
>
> In each of those directories there may be one or more other directories
> - one for each node eg.
>
> ACAD, AC0 for AC
> BAT0, BAT1, BAT2, BATR for batteries
> TZ0, THRM for thermal zones.
> CPU0, PROC, for processor
>
> The only thing you can do is opendir("/proc/acpi/thermalzone"), then
> readdir for each item - ignore . and .. of course.
No. scandir(). You can alphasort.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Stephen Satchell @ 2002-12-19 13:26 UTC (permalink / raw)
To: Andre Hedrick, D.A.M. Revok; +Cc: Manish Lachwani, linux-kernel
In-Reply-To: <Pine.LNX.4.10.10212181359350.8350-100000@master.linux-ide. org>
At 02:01 PM 12/18/02 -0800, Andre Hedrick wrote:
> >
> > Ah,
> > "What you are doing is not out of spec, just how
> > you are are doing it is."
> > eh??
>
>Like MC Hammer says, "Can't touch this!"
>
>There are times when you can do things and there are times you can not.
>Until I get authorization to expose and correct, I can not do anything.
>This is one of the prices I paid to get the docs under NDA.
You might tell them they lost another order, this one for 12 controllers.
Satch
--
The human mind treats a new idea the way the body treats a strange
protein: it rejects it. -- P. Medawar
This posting is for entertainment purposes only; it is not a legal opinion.
^ permalink raw reply
* Dedicated kernel bug database
From: John Bradford @ 2002-12-19 13:35 UTC (permalink / raw)
To: linux-kernel; +Cc: davej, alan, lm, lm, torvalds, vonbrand, akpm
Following on from yesterday's discussion about there not being much
interaction between the kernel Bugzilla and the developers, I began
wondering whether Bugzilla might be a bit too generic to be suited to
kernel development, and that maybe a system written from the ground up
for reporting kernel bugs would be better?
I.E. I am prepared to write it myself, if people think it's
worthwhile.
For example, we get a lot of posts on LKML like this:
"Hi, foobar doesn't work in 2.4.19"
Now, does that mean:
* The bug first appeared in 2.4.19, and is still in 2.4.20
* The bug reporter hasn't tested 2.4.20
* The bug reporter can't test 2.4.20 because something else is broken
* The bug actually first appeared in 2.4.10, but it didn't irritate
them enough to complain until now.
A bug database designed from scratch could allow such information to
be indexed in a way that could be processed and searched usefully. A
list of tick-boxes for worked/didn't work/didn't test/couldn't test
for several kernel versions could be presented.
Also, we could have a non-web interface, (telnet or gopher to the bug
DB, or control it by E-Mail).
It could warn the user if they attach an un-decoded oops that their
bug report isn't as useful as it could be, and if they mention a
distribution kernel version, that it's not a tree that the developers
will necessarily be familiar with.
I'm not criticising the fact that we've got Bugzilla up and running,
but just pointing out that we could do better, (and I'm prepared to
put in the time and effort). I just need ideas, really.
John.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: bart @ 2002-12-19 13:22 UTC (permalink / raw)
To: torvalds
Cc: lk, hpa, terje.eggestad, drepper, matti.aarnio, hugh, davej,
mingo, linux-kernel
On 18 Dec, Linus Torvalds wrote:
>
> On Wed, 18 Dec 2002, Jamie Lokier wrote:
>>
>> That said, you always need the page at 0xfffe0000 mapped anyway, so
>> that sysexit can jump to a fixed address (which is fastest).
>
> Yes. This is important. There _needs_ to be some fixed address at least as
> far as the kernel is concerned (it might move around between reboots or
> something like that, but it needs to be something the kernel knows about
> intimately and doesn't need lots of dynamic lookup).
>
> However, there's another issue, namely process startup cost. I personally
> want it to be as light as at all possible. I hate doing an "strace" on
> user processes and seeing tons and tons of crapola showing up. Just for
So why not map the magic page at 0xffffe000 at some other address as
well?
Static binaries can just directly jump/call into the magic page.
Shared binaries do somekind of mmap("/proc/self/mem") magic to put a
copy of the page at an address that is convenient for them. Shared
binaries have to do a lot of mmap-ing anyway, so the overhead should be
negligible.
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
^ permalink raw reply
* Re: Trident/ALi 5451 problem, 2.4.20-ac2
From: Ian Soboroff @ 2002-12-19 13:19 UTC (permalink / raw)
To: linux-kernel; +Cc: Alan Cox
In-Reply-To: <9cf4r9btpk8.fsf@rogue.ncsl.nist.gov>
Ian Soboroff <ian.soboroff@nist.gov> writes:
> Just tried 2.4.20-ac2 on my Fujitsu P-2040, and it seems to have a
> problem initializing the sound:
>
> (from dmesg)
>
> Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, version 0.14.10h,
> 17:35:49 Dec 16 2002
> PCI: Found IRQ 9 for device 00:04.0
> trident: ALi Audio Accelerator found at IO 0x1000, IRQ 9
> ALi 5451 did not come out of reset.
> trident_ac97_init: error resetting 5451.
Took a bit of a look... the trident.c part of the patch is pretty
short:
--- linux.vanilla/drivers/sound/trident.c 2002-11-29 21:27:19.000000000 +0
000
+++ linux.20-ac2/drivers/sound/trident.c 2002-11-14 15:24:35.000000000 +0
000
@@ -3936,9 +3936,11 @@
wReg = ali_ac97_get(card, 0, AC97_POWER_CONTROL);
if((wReg & 0x000f) == 0x000f)
return 0;
- udelay(500);
+ udelay(5000);
}
- return 0;
+
+ printk(KERN_ERR "ALi 5451 did not come out of reset.\n");
+ return 1;
}
/* AC97 codec initialisation. */
I guess the loop (which the patch only shows the bottom of) is trying
to reset the AC97, and check the reset witht he ali_ac97_get() call.
The old 2.4.20 code just returned 0 in any case, whether the reset
succeeded or not. On my laptop, if I change this routine back to
return 0 in all cases, sound works fine. With this patch, this
routine returns 1, and the trident.c init aborts.
Perhaps the loop check for reset success isn't right? Or not all ALi
5451's play nice? I've reached the end of my clue.
Ian
^ permalink raw reply
* Re: readdir within kernel
From: Matthew Wilcox @ 2002-12-19 13:09 UTC (permalink / raw)
To: Herbert Poetzl; +Cc: linux-fsdevel
In-Reply-To: <20021219050632.GB16235@www.13thfloor.at>
On Thu, Dec 19, 2002 at 06:06:32AM +0100, Herbert Poetzl wrote:
> I would like to know if this is the right way to
> read a directory contents for a given directory
> dentry within a kernel module ...
well, you probably _shouldn't_ be anyway... but since you are, this is
how I did it for debugging why my system couldn't find /sbin/init.
diff -u -p -r1.11 main.c
--- init/main.c 10 Dec 2002 22:03:28 -0000 1.11
+++ init/main.c 19 Dec 2002 13:08:45 -0000
@@ -501,6 +501,26 @@ static void do_pre_smp_initcalls(void)
extern void prepare_namespace(void);
+static int kernel_filler(void *buf, const char *name, int namlen, loff_t offset,
+ ino_t ino, unsigned int d_type)
+{
+ printk("%.*s\n", namlen, name);
+}
+
+static void kernel_ls(char *name)
+{
+ struct file *file;
+
+ file = filp_open(name, O_RDONLY, 0);
+ if (!file) {
+ printk("Could not open %s\n", name);
+ return;
+ }
+
+ vfs_readdir(file, kernel_filler, NULL);
+ filp_close(file, current->files);
+}
+
static int init(void * unused)
{
static char * argv_sh[] = { "sh", NULL, };
@@ -540,6 +560,9 @@ static int init(void * unused)
(void) dup(0);
(void) dup(0);
+
+ kernel_ls("/");
+ kernel_ls("/sbin");
/*
* We try each of these until one succeeds.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Stephen Satchell @ 2002-12-19 13:17 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel
In-Reply-To: <20021218140845.L7976@work.bitmover.com>
At 02:08 PM 12/18/02 -0800, Larry McVoy wrote:
>I don't understand why BK is part of the conversation. It has nothing to
>do with it. If every time I post to this list the assumption is that it's
>"time to beat larry up about BK" then it's time for me to get off the list.
>
>I can understand it when we're discussing BK; other than that, it's pretty
>friggin lame. If that's what was behind your posts, Alan, there is an
>easy procmail fix for that.
Boy, talk about humor-impaired. When was the last time you got out and had
some fun not related to computer, Larry?
I don't read more than 95 percent of this mailing list and I got the joke.
Lighten up, and take a hint from the nearest cat: see the toy in everything.
Satch, another relative nobody.
--
The human mind treats a new idea the way the body treats a strange
protein: it rejects it. -- P. Medawar
This posting is for entertainment purposes only; it is not a legal opinion.
^ permalink raw reply
* [PATCH] 2.2.23 wild pointer in struct sock
From: Smolinski @ 2002-12-19 13:09 UTC (permalink / raw)
To: linux-kernel, ak; +Cc: smolinsk, holger
Hi Andi,
this patch fixes a occurrence of a wild pointer in the cloned
struct sock, after SYN has been received. Kernel 2.4. resolves the
situation in the same way. Pls. apply.
Holger Smolinski
Index: net/core/sock.c
===================================================================
RCS file: /home/cvs/linux/net/core/sock.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 sock.c
--- net/core/sock.c 5 Jan 2000 13:50:34 -0000 1.1.1.1
+++ net/core/sock.c 18 Dec 2002 09:18:05 -0000
@@ -79,6 +79,7 @@
* Jay Schulist : Added SO_ATTACH_FILTER and SO_DETACH_FILTER.
* Andi Kleen : Add sock_kmalloc()/sock_kfree_s()
* Andi Kleen : Fix write_space callback
+ * Holger Smolinski: Fix initialization of sk->sleep
*
* To Fix:
*
@@ -1036,6 +1037,8 @@
sk->type = sock->type;
sk->sleep = &sock->wait;
sock->sk = sk;
+ } else {
+ sk->sleep = NULL;
}
sk->state_change = sock_def_wakeup;
Index: net/ipv4/tcp_ipv4.c
===================================================================
RCS file: /home/cvs/linux/net/ipv4/tcp_ipv4.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 tcp_ipv4.c
--- net/ipv4/tcp_ipv4.c 5 Jan 2000 13:50:34 -0000 1.1.1.1
+++ net/ipv4/tcp_ipv4.c 18 Dec 2002 09:18:05 -0000
@@ -44,7 +44,9 @@
* Andi Kleen: various fixes.
* Vitaly E. Lavrov : Transparent proxy revived after year coma.
* Andi Kleen : Fix new listen.
- * Andi Kleen : Fix accept error reporting.
+ * Andi Kleen : Fix accept error reporting.a
+ * Holger Smolinski : Fix initialization of newsk->sleep which
+ * points to a potentially invalid wait_queue
*/
#include <linux/config.h>
@@ -1464,6 +1466,7 @@
newsk->timer.function = &net_timer;
newsk->timer.data = (unsigned long) newsk;
newsk->socket = NULL;
+ newsk->sleep = NULL;
newtp->tstamp_ok = req->tstamp_ok;
if((newtp->sack_ok = req->sack_ok) != 0)
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Richard B. Johnson @ 2002-12-19 13:10 UTC (permalink / raw)
To: billyrose; +Cc: linux-kernel
In-Reply-To: <1040255473.3e0109f183d7e@209.51.155.18>
On Wed, 18 Dec 2002 billyrose@billyrose.net wrote:
> Richard B. Johnson wrote:
> > The number of CPU clocks necessary to make the 'far' or
> > full-pointer call by pushing the segment register, the offset,
> > then issuing a 'lret' is 33 clocks on a Pentium II.
> >
> > longcall clocks = 46
> > call clocks = 13
> > actual full-pointer call clocks = 33
>
> this is not correct. the assumed target (of a _far_ call) would issue a far
> return and only an offset would be left on the stack to return to (oops). the
> code segment of the orginal caller needs pushed to create the seg:off pair and
> hence a far return would land back at the original calling routine. this is a
> very convoluted method of making the orginal call being far, as simply calling
> far in the first pace should issue much faster. OTOH, if you are making a
> workaround to an already existing piece of code, this works beautifully (with
> the additional seg pushed on the stack).
>
The target, i.e., the label 'goto' would be the reserved page for the
system call. The whole purpose was to minimize the number of CPU cycles
necessary to call 0xfffff000 and return. The system call does not have
issue a 'far' return, it can do anything it requires. The page at
0xfffff000 is mapped into every process and is in that process CS space
already.
I have already gotten responses from people who looked at the code
and said it was broken. It is not broken. It does what is expected.
It takes the same number of CPU cycles as:
pushl $0xfffff000
call *(%esp)
addl $4, %esp
... which is the current proposal. It has the advantage that only
the return address is on the stack when the target code is executed.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: [LARTC] Filter in HTB not working
From: Corey Rogers @ 2002-12-19 12:50 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104029961502754@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 3739 bytes --]
From what I see you are running a telnet daemon. If not it will never
work. If you are doing this to shape telnet traffic from a telnet client
then rather than sport it'll have to be dport.
On Thu, 2002-12-19 at 08:06, Nestor S A Melo wrote:
> I have a problem in setting up HTB.
>
> It appears filters doesn't work at all, besides "tc filter show" show it as
> being correctly configured.
>
> Class 1:10 never sent any traffic, but as iptables show below, it should be
> sending packets.
>
> The HTB version I'm using is 3.3, with kernel 2.4.17.
>
> The setup is as follows:
> ---------------------------------------------------------------
> tc qdisc del dev eth0 root
> tc qdisc add dev eth0 root handle 1 htb default 20 r2q 10
>
> tc class add dev eth0 parent 1: classid 1:2 htb rate 256kbit
>
> tc class add dev eth0 parent 1:2 classid 1:10 htb rate 26kbit ceil 128kbit
> prio
> 1
> tc qdisc add dev eth0 parent 1:10 handle 10 sfq perturb 10
> tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 23
> 0xffff classid 1:10
>
> tc class add dev eth0 parent 1:2 classid 1:20 htb rate 220kbit ceil 256kbit
> prio 2
> tc qdisc add dev eth0 parent 1:20 handle 20 sfq perturb 10
> ---------------------------------------------------------------
>
> The stats:
> ---------------------------------------------------------------
> [root@NL1000 htb]# tc -s -d qdisc show
> qdisc sfq 20: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
> Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
>
> qdisc sfq 10: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
>
> qdisc htb 1: dev eth0 r2q 10 default 20 direct_packets_stat 0 ver 3.6
> Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
>
> [root@NL1000 htb]# tc -s -d class show dev eth0
> class htb 1:10 parent 1:2 leaf 10: prio 1 quantum 1000 rate 26Kbit ceil
> 128Kbit
> burst 1632b/8 mpu 0b cburst 1762b/8 mpu 0b level 0
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
> lended: 0 borrowed: 0 giants: 0
> tokens: 401969 ctokens: 88149
>
> class htb 1:2 root rate 256Kbit ceil 256Kbit burst 1926b/8 mpu 0b cburst
> 1926b/8 mpu 0b level 7
> Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
> lended: 0 borrowed: 0 giants: 0
> tokens: 46975 ctokens: 46975
>
> class htb 1:20 parent 1:2 leaf 20: prio 2 quantum 2816 rate 220Kbit ceil
> 256Kbit burst 1880b/8 mpu 0b cburst 1926b/8 mpu 0b level 0
> Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
> lended: 94 borrowed: 0 giants: 0
> tokens: 53324 ctokens: 46975
>
> [root@NL1000 htb]# tc -s -d filter show dev eth0
> filter parent 1: protocol ip pref 100 u32
> filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800
> bkt
> 0 flowid 1:10
> match 00170000/ffff0000 at 20
>
> [root@NL1000 htb]# iptables -t mangle -L -nvx
> Chain PREROUTING (policy ACCEPT 3590 packets, 557751 bytes)
> pkts bytes target prot opt in out source
> destination
> 0 0 MARK tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:23 MARK set 0x6
> 146 12954 MARK tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp spt:23 MARK set 0x6
>
> Chain OUTPUT (policy ACCEPT 315 packets, 16936 bytes)
> pkts bytes target prot opt in out source
> destination
> ---------------------------------------------------------------
>
> So, what is going wrong?
>
> Thanks in advance,
--
Corey Rogers <jrog@sunbeach.net>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Linux 2.2.24-rc1
From: Alan Cox @ 2002-12-19 12:48 UTC (permalink / raw)
To: Robert Boermans; +Cc: Pawel Kot, Alan Cox, linux-kernel
In-Reply-To: <3E01BD20.4080608@home.nl>
> i assume there was more to the patch?
Well no. Its just I got it slightly wrong 8)
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Andre Hedrick @ 2002-12-19 12:41 UTC (permalink / raw)
To: Tomas Szepe; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021219120307.GE17201@louise.pinerecords.com>
On Thu, 19 Dec 2002, Tomas Szepe wrote:
> > > > > > > So. I /think/ that somehow the Promise controller isn't being
> > > > > > > initialized properly by the Linux kernel, UNLESS the mobo's BIOS
> > > > > > > inits it first?
> > > > > >
> > > > > > In some situations yes. The BIOS does stuff including fixups we mere
> > > > > > mortals arent permitted to know about.
> > > > >
> > > > > OTOH mere mortals are allowed to make full dump of PCI config ;)
> > > > >
> > > > > "D.A.M. Revok" <marvin@synapse.net>, can you send lspci -vvvxxx
> > > > > outputs when you boot with BIOS enabled and BIOS disabled?
> > > >
> > > > Promise knows this point.
> > > > Thus they moved the setting to a push/pull in the vendor space in the
> > > > dma_base+1 and dma_base+3 respectively.
> > > >
> > > > lspci -vvvxxx fails when the content is located in bar4 io space.
> > >
> > > Clearly Promise is the one storage vendor whose products are best avoided.
> >
> > I would not say this is the case. What is going on is people are wanting
> > to migrate to more of an internal hidden operation.
> >
> > Think about it from their side.
> > They want to make it easier to program the card.
>
> The result of their attempts has seemed to be the exact opposite
> so far, so I'd say they're either hiding a bit too much or the
> hardware doesn't cut it.
>
> Anyway, what are the chances of the 2.4.21-pre PDC driver getting
> fixed up so it works like it did in 2.4.18?
Well, there is an issue.
I have a consulting contract with Promise outstanding.
It is on my desk, but there is on issue I refuse to agree to period.
Nobody in the right mind agrees to disclose their entire IP portfolio, as
a contractor or consultant. This allow the client to box you into a
corner so tight, that anything in the future they can claim as their own
and tie it back to an contract collecting dust.
> > Linux is an OS that like to know what is going on all the time,
> > and the two clash.
>
> Are you suggesting something to the point of Windows not having
> to cope with the same issues? There has to be some kind of fundamental
> difference given Promise themselves successfully hosed the Linux driver
> the instant they touched it, while the Windows one just works. :)
So I am not fixing anything until this issue is resolved.
They pay for what you clearly have stated above.
As for the Windows issue, the scsi-mini-port is a whole differenct beast.
Everyone jokes and laughs at my quote:
"The world of Storage is nothing but a BIG LIE"
SCSI is a run,poke,sense,verify,transform world.
ATA is a run,check,return world.
That being said, as far as I can tell, the WDDK for mini-port only cares
about the state returned. So if you do not like the state your hardware
is in, you boost the return and hook a TDI callback or poll check.
It is obvious the OEM Windows driver has unlimited power to fake the
response.
At this point I expect any contract is dead, so use 2.4.18.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* 'D' processes on a healthy system?
From: martin f krafft @ 2002-12-19 12:40 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]
[please CC me on replies]
Hi folks,
I just pulled up a fresh, powerful, and errorfree server on Debian
woody, with some packages from testing. It's running a vanilla 2.4.19
kernel with the grsecurity 1.9.7d and freeswan 1.99 patches. This is
an AMD Athlon Duron 1.2 GHz with 512 Mb of SD-RAM and a 7,200 UPM HDD
by Maxtor. Reiserfs is used as filesystem.
I also have a machine that's about a year old, still running a vanilla
2.4.12 kernel without any patches. It's an AMD K6-2 500 MHz with 192
Mb of RAM and a 5,400 UPM Western Digital drive. ext2 is the
filesystem here.
When either machine becomes loaded, certain processes become unusable
for a couple of seconds. top shows me this:
19268 madduck 18 0 2208 2208 1076 D 1.3 0.4 0:00 sanitizer
6 root 9 0 0 0 0 DW 0.3 0.0 1:10 kupdated
8457 root 10 0 1156 1156 820 R 0.3 0.2 0:02 top
10843 postfix 9 0 1364 1364 1016 D 0.3 0.2 0:00 cleanup
3156 madduck 0 0 636 636 540 D 0.1 0.1 0:00 procmail
28356 root 9 0 292 288 240 R 0.0 0.0 0:01 supervise
28706 root 9 0 2060 2036 1724 D 0.0 0.4 0:00 sshd
21395 root 15 0 1944 1944 1876 D 0.0 0.3 0:00 zsh
notice the number of processes in ^
uninterruptible sleep mode in this column.
This was after i did something like:
while true; do echo test | sendmail madduck; mailq; done
When this state is reached, programs like mutt take 7 minutes to open
a mailbox of 100 messages. With the server specs, this should not
happen.
I have memtest86'd the RAM and ran badblocks over all partitions
without finding anything.
My laptop, which is running Debian testing/unstable is not showing
this behaviour, and its load goes far higher at times. I also run
various other servers, partially on P5-120 systems, vanilla 2.4.xx
kernels and Debian testing, and there are no such problems there.
What is this an indication of? Hardware problems? Software problems?
Have you heard of this before? How can I fix it?
Thanks,
[Please CC me on replies]
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
NOTE: The public PGP keyservers are broken!
Get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 823 Video Controller Driver - where ?
From: Wolfgang Denk @ 2002-12-19 12:29 UTC (permalink / raw)
To: Steven Blakeslee, Embedded Linux PPC List
> In message <D73A25AA6E54D511AD74009027B1110F3C04C7@ORION> you wrote:
> >
> > We have Linux frame buffer drivers for our 823E(LITE DW) and our
> > IBM405GP(EP405PC).
>
> Where can I download the sources?
Steven,
did you ever reply to this question?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
It is common sense to take a method and try it. If it fails, admit it
frankly and try another. But above all, try something.
- Franklin D. Roosevelt
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Linux 2.2.24-rc1
From: Robert Boermans @ 2002-12-19 12:35 UTC (permalink / raw)
To: Pawel Kot; +Cc: Alan Cox, linux-kernel
In-Reply-To: <Pine.LNX.4.33.0212170113350.14563-100000@urtica.linuxnews.pl>
Pawel Kot wrote:
>Is it the following chunk? (I can't find anything more appropriate)
>@@ -1378,7 +1378,8 @@
> return;
>
> case X86_VENDOR_AMD:
>- init_amd(c);
>+ if(init_amd(c))
>+ return;
> return;
>
> case X86_VENDOR_CENTAUR:
>What does it fix?
>
>pkot
>
>
i assume there was more to the patch?
i mean first it did init_amd(c) and then return
now it does init_amd(c) and returns in the if or right on the next line,
so that's the same with extra bloat.
confused,
Robert Boermans.
^ permalink raw reply
* Re: [PATCH] (4/5) improved notifier callback mechanism - read copy update
From: Vamsi Krishna S . @ 2002-12-19 12:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linus Torvalds, Alan Cox, Kernel List
In-Reply-To: <1040249652.14364.192.camel@dell_ss3.pdx.osdl.net>
Hi Stephen,
On Wed, Dec 18, 2002 at 11:06:08PM +0000, Stephen Hemminger wrote:
> The notifier interface was only partially locked. The
> notifier_call_chain needs to be called in places where it is impossible
> to safely without having deadlocks; for example, NMI watchdog timeout.
>
> This patch uses read-copy-update to manage the list. One extra bit of
> safety is using a reference count on the notifier_blocks to allow for
> cases like oprofile which need to sleep in a callback.
>
<snip>
>
> int notifier_call_chain(struct list_head *list, unsigned long val, void
> *v)
> {
> - struct list_head *p;
> + struct list_head *p, *nxtp;
> int ret = NOTIFY_DONE;
>
> - list_for_each(p, list) {
> + rcu_read_lock();
> + list_for_each_safe_rcu(p, nxtp, list) {
> struct notifier_block *nb =
> list_entry(p, struct notifier_block, link);
>
> + atomic_inc(&nb->inuse);
> ret = nb->notifier_call(nb,val,v);
> + atomic_dec(&nb->inuse);
> +
There could be a small problem here. When rcu_read_lock() is called,
it bumps the preempt_count, so when the called handler attempts
to sleep, it will oops with "Bad: scheduling in atomic region".
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.