Hi,
I'm trying to implement a filter in the kernel that would basically wait for a particular time inside the device driver and then send the packet. For this I need to delay the execution for some microseconds.(highest accuracy needed is about 10 microseconds). I know that udelay() function does this but it ties down the kernel as it is a busy wait sleep. Is there another way to sleep for microsecond granularity without the kernel busy waiting.
Thanks in anticipation,
Sincerely,
Aamir
On Fri, 11 Aug 2000 13:21:55
owner-linux-kernel-digest wrote:
>
>linux-kernel-digest Friday, August 11 2000 Volume 01 : Number 1301
>
>In this issue:
>
> Re: [Sligtly Off-Topic] Status of Linux running on Athlon based boards?
> Re: ioremap return type
> [PATCH][RFC] tmspci.c using new pci api
> Re: [PATCH] Persistent RTC, against 2.2.16
> [RFC] Setting RTC alarm time
> 2.4.0-test6: PCI probe/config problem?
> re: 2.2.17pre15/16 NFS SMP lockup
> Re: patch for md.c in 2.2.16
> Re: Degrading disk read performance under 2.2.16
> Re: 2.2.17pre15/16 NFS SMP lockup
> [patch] PCI resource allocation
> Re: How to start to develop a filesystem ?
> Re: Kernel test6-preX-test6 not compiling. Networking/Netfilter problem?
> NTFS-like streams?
> Re: 2.2.17pre15 patched: state D
> Re: IDE Tape problem in 2.2.16 (bug?)
> Re: How to start to develop a filesystem ?
> [OOPS] linux-2.4.0test6 uhci.o
> Re: Degrading disk read performance under 2.2.16
> Re: oops 2.2.17pre15
> Re: HFS-formatted CDROMs (was: Re: Linux 2.4 Status)
> Re: 2.4.0-test6 swapon problems, nearly hangs
> Re: HFS-formatted CDROMs (was: Re: Linux 2.4 Status)
> Re: IDE Tape problem in 2.2.16 (bug?)
> [PATCH] fix cosa.c resource allocation
> Re: pte_pagenr/MAP_NR deleted in pre6
> Re: How to start to develop a filesystem ?
> Re: lock_kernel() & kmalloc - evil together?
> Re: 2.4.0-test6 -- Problem with PCI -- Error while updating region 01:00.0/1 (10800000 != 00000000)
> Re: Degrading disk read performance under 2.2.16
> Re: IDE Tape problem in 2.2.16 (bug?)
>
>See the end of the digest for information on subscribing to the linux-kernel
>or linux-kernel-digest mailing lists.
>
>----------------------------------------------------------------------
>
>From: Byron Stanoszek <gandalf@winds.org>
>Date: Fri, 11 Aug 2000 11:20:26 -0400 (EDT)
>Subject: Re: [Sligtly Off-Topic] Status of Linux running on Athlon based boards?
>
>I own a EP-7KXA motherboard (Via Chipset) with a 750 MHz Classic Athlon CPU.
>I experience no problems running with either PC100 or PC133 SDRAM...
>
>However I do get a problem when overclocking the bus to 110 MHz from 100.
>But, this is probably expected--I start to get memory errors. I'm wondering if
>that's because of non-prime RAM Chips or becuase the CPU can't handle the
>speed.. I'm thinking it's the chips though.
>
>FYI, Specs on this machine:
>
>/proc/cpuinfo:
>processor : 0
>vendor_id : AuthenticAMD
>cpu family : 6
>model : 2
>model name : AMD Athlon(tm) Processor
>stepping : 2
>cpu MHz : 751.350481
>cache size : 512 KB
>fdiv_bug : no
>hlt_bug : no
>sep_bug : no
>f00f_bug : no
>coma_bug : no
>fpu : yes
>fpu_exception : yes
>cpuid level : 1
>wp : yes
>flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
>pse36 mmxext mmx fxsr 3dnowext 3dnow
>bogomips : 1497.50
>
>lspci:
>00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev 02)
>00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391
>00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 21)
>00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
>00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev
>30)
>00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo
>Super AC97/Audio] (rev
>20)
>00:08.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+]
>00:09.0 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 01)
>00:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev
>34)
>
>/proc/interrupts:
> CPU0
> 0: 12998875 XT-PIC timer
> 1: 4273 XT-PIC keyboard
> 2: 0 XT-PIC cascade
> 3: 3 XT-PIC serial
> 5: 43449 XT-PIC serial
> 7: 1 XT-PIC parport0
> 10: 171957 XT-PIC soundblaster
> 11: 0 XT-PIC eth0
> 12: 12 XT-PIC PS/2 Mouse
> 13: 1 XT-PIC fpu
> 14: 9028 XT-PIC ide0
>NMI: 0
>ERR: 0
>
>It supports my ISA AWE 32 pretty well too, as well as UDMA 33/66. :-)
>
>(Linux localhost 2.4.0-test6 #29 Wed Aug 9 23:02:18 EDT 2000 i686 unknown)
>
>
>- --
>Byron Stanoszek Ph: (330) 644-3059
>Systems Programmer Fax: (330) 644-8110
>Commercial Timesharing Inc. Email: bstanoszek@comtime.com
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Jes Sorensen <jes@linuxcare.com>
>Date: 11 Aug 2000 17:24:30 +0200
>Subject: Re: ioremap return type
>
>>>>>> "Philipp" == Philipp Rumpf <prumpf@parcelfarce.linux.theplanet.co.uk> writes:
>
>Philipp> On Thu, Aug 10, 2000 at 02:14:13PM +0200, Jamie Lokier wrote:
>>> Many drivers use a struct to define the offsets in their I/O or
>>> iomem space. E.g. acenic.c: readl(.s->CpuCtrl). We know that's
>>> not portable in the sense that struct layout is not guaranteed.
>>> However, provided all the fields are suitably padded & aligned, it
>>> works in practice. (So far..)
>
>Philipp> Not only does it work in practice, it's used by most drivers
>Philipp> and file systems when they describe on-disk or dma
>Philipp> structures. Currently the rules are:
>
>Philipp> - naturally align everything - all struct sizes might be
>Philipp> aligned to a multiple of four bytes
>
>Philipp> By now, I believe it is more likely that gcc would be fixed
>Philipp> for a new architecture that violates this assumption, so it's
>Philipp> not worth it to go around and "fix" those drivers.
>
>Nononononono, gcc on the m68k does 'natural' alignments to two byte
>boundaries and not 4 bytes. Yes it sucks and no we cannot change it
>now.
>
>If you use structures to describe hardware you should *always*
>perform explicit padding and never ever expect the compiler to do it
>for you. Just because it works on one architecture doesn't mean the
>alignments will be the same on another, and it is not just a question
>of fixing the compiler, if the architecture ABI says on thing then
>thats normally what to listen to.
>
>Jes
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
>Date: Fri, 11 Aug 2000 12:39:37 -0300
>Subject: [PATCH][RFC] tmspci.c using new pci api
>
>Hi,
>
> Could you please take a look at this patch, converting
>drivers/net/tokenring/tmspci.c to the new pci API? It compiles, so it must be
>good! 8)
>
> - Arnaldo
>
>- --- linux-2.4.0-test6/drivers/net/tokenring/tmspci.c Sat Apr 29 03:00:05 2000
>+++ linux-2.4.0-test6.acme/drivers/net/tokenring/tmspci.c Fri Aug 11 08:03:53 2000
>@@ -16,15 +16,20 @@
> * Maintainer(s):
> * AF Adam Fritzler mid@auk.cx
> *
>+ * Contributors:
>+ * acme Arnaldo Carvalho de Melo acme@conectiva.com.br
>+ *
> * Modification History:
> * 30-Dec-99 AF Split off from the tms380tr driver.
> * 22-Jan-00 AF Updated to use indirect read/writes
>+ * 11-Aug-00 acme ported to new PCI API, new style
>+ * module init/exit
> *
> * TODO:
> * 1. See if we can use MMIO instead of port accesses
> *
> */
>- -static const char *version = "tmspci.c: v1.01 22/01/2000 by Adam Fritzler\n";
>+static const char *version = "tmspci.c: v1.02 08/11/2000 by Adam Fritzler\n";
>
> #include <linux/module.h>
> #include <linux/kernel.h>
>@@ -42,30 +47,47 @@
> #include "tms380tr.h"
>
> #define TMS_PCI_IO_EXTENT 32
>+#define TMS_PCI_MODULE_NAME "tmspci"
>
> struct cardinfo_table {
>- - int vendor_id; /* PCI info */
>- - int device_id;
> int registeroffset; /* SIF offset from dev->base_addr */
> unsigned char nselout[2]; /* NSELOUT vals for 4mb([0]) and 16mb([1]) */
> char *name;
> };
>
>- -struct cardinfo_table probelist[] = {
>- - { 0, 0,
>- - 0x0000, {0x00, 0x00}, "Unknown TMS380 Token Ring Adapter"},
>- - { PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TOKENRING,
>- - 0x0000, {0x03, 0x01}, "Compaq 4/16 TR PCI"},
>- - { PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_TR,
>- - 0x0000, {0x03, 0x01}, "SK NET TR 4/16 PCI"},
>- - { PCI_VENDOR_ID_TCONRAD, PCI_DEVICE_ID_TCONRAD_TOKENRING,
>- - 0x0000, {0x03, 0x01}, "Thomas-Conrad TC4048 PCI 4/16"},
>- - { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3C339,
>- - 0x0000, {0x03, 0x01}, "3Com Token Link Velocity"},
>- - { 0, 0, 0, {0x00, 0x00}, NULL}
>+typedef enum {
>+ BOARD_COMPAQ_TOKENRING = 0,
>+ BOARD_SYSKONNECT_TR,
>+ BOARD_TCONRAD_TOKENRING,
>+ BOARD_3COM_3C339,
>+} board_t;
>+
>+/* indexed by board_t, above */
>+
>+struct cardinfo_table board_info[] = {
>+ { 0x0000, {0x03, 0x01}, "Compaq 4/16 TR PCI"},
>+ { 0x0000, {0x03, 0x01}, "SK NET TR 4/16 PCI"},
>+ { 0x0000, {0x03, 0x01}, "Thomas-Conrad TC4048 PCI 4/16"},
>+ { 0x0000, {0x03, 0x01}, "3Com Token Link Velocity"},
>+};
>+
>+static struct pci_device_id tms_pci_pci_tbl[] __initdata =
>+{
>+ { PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TOKENRING, PCI_ANY_ID, PCI_ANY_ID,
>+ 0, 0, BOARD_COMPAQ_TOKENRING },
>+ { PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_TR, PCI_ANY_ID, PCI_ANY_ID,
>+ 0, 0, BOARD_SYSKONNECT_TR },
>+ { PCI_VENDOR_ID_TCONRAD, PCI_DEVICE_ID_TCONRAD_TOKENRING, PCI_ANY_ID, PCI_ANY_ID,
>+ 0, 0, BOARD_TCONRAD_TOKENRING },
>+ { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3C339, PCI_ANY_ID, PCI_ANY_ID,
>+ 0, 0, BOARD_3COM_3C339 },
>+ {0,}
> };
>
>- -int tms_pci_probe(void);
>+MODULE_DEVICE_TABLE (pci, tms_pci_pci_tbl);
>+MODULE_AUTHOR ("Adam Fritzler <mid@auk.cx>");
>+MODULE_DESCRIPTION ("TMS380-based PCI token ring cards driver");
>+
> static int tms_pci_open(struct net_device *dev);
> static int tms_pci_close(struct net_device *dev);
> static void tms_pci_read_eeprom(struct net_device *dev);
>@@ -91,145 +113,86 @@
> outw(val, dev->base_addr + reg);
> }
>
>- -struct tms_pci_card {
>- - struct net_device *dev;
>- - struct pci_dev *pci_dev;
>- - struct cardinfo_table *cardinfo;
>- - struct tms_pci_card *next;
>- -};
>- -static struct tms_pci_card *tms_pci_card_list = NULL;
>- -
>- -
>- -struct cardinfo_table * __init tms_pci_getcardinfo(unsigned short vendor,
>- - unsigned short device)
>- -{
>- - int cur;
>- - for (cur = 1; probelist[cur].name != NULL; cur++) {
>- - if ((probelist[cur].vendor_id == vendor) &&
>- - (probelist[cur].device_id == device))
>- - return &probelist[cur];
>- - }
>- -
>- - return NULL;
>- -}
>- -
>- -int __init tms_pci_probe(void)
>+int __init tms_pci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> {
> static int versionprinted = 0;
>- - struct pci_dev *pdev = NULL ;
> struct net_device *dev;
> struct net_local *tp;
> int i;
>+ unsigned long pci_ioaddr;
>+ struct cardinfo_table *cardinfo = &board_info[ent->driver_data];
>
>- - if (!pci_present())
>- - return (-1); /* No PCI present. */
>- -
>- - while ( (pdev=pci_find_class(PCI_CLASS_NETWORK_TOKEN_RING<<8, pdev))) {
>- - unsigned int pci_irq_line;
>- - unsigned long pci_ioaddr;
>- - struct tms_pci_card *card;
>- - struct cardinfo_table *cardinfo;
>- -
>- - if ((cardinfo =
>- - tms_pci_getcardinfo(pdev->vendor, pdev->device)) == NULL)
>- - continue;
>- -
>- - if (versionprinted++ == 0)
>- - printk("%s", version);
>- -
>- - if (pci_enable_device(pdev))
>- - continue;
>- -
>- - /* Remove I/O space marker in bit 0. */
>- - pci_irq_line = pdev->irq;
>- - pci_ioaddr = pci_resource_start (pdev, 0);
>- -
>- - if(check_region(pci_ioaddr, TMS_PCI_IO_EXTENT))
>- - continue;
>- -
>- - /* At this point we have found a valid card. */
>- -
>- - dev = init_trdev(NULL, 0);
>- - if (!dev) {
>- - continue; /*return (-ENOMEM);*/ /* continue; ?? */
>- - }
>- -
>- - request_region(pci_ioaddr, TMS_PCI_IO_EXTENT, cardinfo->name); /* XXX check return */
>- - if(request_irq(pdev->irq, tms380tr_interrupt, SA_SHIRQ,
>- - cardinfo->name, dev)) {
>- - release_region(pci_ioaddr, TMS_PCI_IO_EXTENT);
>- - /* XXX free trdev */
>- - continue; /*return (-ENODEV);*/ /* continue; ?? */
>- - }
>- -
>- - /*
>- - if (load_tms380_module("tmspci.c")) {
>- - return 0;
>- - }
>- - */
>- -
>- - pci_ioaddr &= ~3 ;
>- - dev->base_addr = pci_ioaddr;
>- - dev->irq = pci_irq_line;
>- - dev->dma = 0;
>- -
>- - printk("%s: %s\n", dev->name, cardinfo->name);
>- - printk("%s: IO: %#4lx IRQ: %d\n",
>- - dev->name, dev->base_addr, dev->irq);
>- - /*
>- - * Some cards have their TMS SIF registers offset from
>- - * their given base address. Account for that here.
>- - */
>- - dev->base_addr += cardinfo->registeroffset;
>+ if (versionprinted++ == 0)
>+ printk(KERN_INFO "%s", version);
>+
>+ if (pci_enable_device(pdev))
>+ return -ENODEV;
>+
>+ pci_ioaddr = pci_resource_start (pdev, 0);
>+
>+ if (!request_region(pci_ioaddr, TMS_PCI_IO_EXTENT, cardinfo->name))
>+ return -EBUSY;
>+
>+ dev = init_trdev(NULL, 0);
>+
>+ if (!dev)
>+ goto fail_init_trdev;
>+
>+ if (request_irq(pdev->irq, tms380tr_interrupt, SA_SHIRQ, cardinfo->name, dev))
>+ goto fail_request_irq;
>+
>+ /* if (load_tms380_module("tmspci.c")) return 0; */
>+
>+ pci_ioaddr &= ~3 ;
>+ dev->base_addr = pci_ioaddr;
>+ dev->irq = pdev->irq;;
>
>- - tms_pci_read_eeprom(dev);
>+ printk(KERN_INFO "%s: %s\n", dev->name, cardinfo->name);
>+ printk(KERN_INFO "%s: IO: %#4lx IRQ: %d\n", dev->name, dev->base_addr, dev->irq);
>+
>+ /*
>+ * Some cards have their TMS SIF registers offset from
>+ * their given base address. Account for that here.
>+ */
>
>- - printk("%s: Ring Station Address: ", dev->name);
>- - printk("%2.2x", dev->dev_addr[0]);
>- - for (i = 1; i < 6; i++)
>- - printk(":%2.2x", dev->dev_addr[i]);
>- - printk("\n");
>+ dev->base_addr += cardinfo->registeroffset;
>
>- - if (tmsdev_init(dev)) {
>- - printk("%s: unable to get memory for dev->priv.\n", dev->name);
>- - return 0;
>- - }
>- -
>- - tp = (struct net_local *)dev->priv;
>- - tp->dmalimit = 0; /* XXX: should be the max PCI32 DMA max */
>- - tp->setnselout = tms_pci_setnselout_pins;
>+ tms_pci_read_eeprom(dev);
>+
>+ printk(KERN_INFO "%s: Ring Station Address: ", dev->name);
>+ printk(KERN_INFO "%2.2x", dev->dev_addr[0]);
>+
>+ for (i = 1; i < 6; i++)
>+ printk(KERN_INFO ":%2.2x", dev->dev_addr[i]);
>+ printk(KERN_INFO "\n");
>
>- - tp->sifreadb = tms_pci_sifreadb;
>- - tp->sifreadw = tms_pci_sifreadw;
>- - tp->sifwriteb = tms_pci_sifwriteb;
>- - tp->sifwritew = tms_pci_sifwritew;
>+ if (tmsdev_init(dev))
>+ goto fail_tmsdev_init;
>+
>+ tp = (struct net_local *)dev->priv;
>+ tp->dmalimit = 0; /* XXX: should be the max PCI32 DMA max */
>+ tp->setnselout = tms_pci_setnselout_pins;
>
>- - memcpy(tp->ProductID, cardinfo->name, PROD_ID_SIZE + 1);
>+ tp->sifreadb = tms_pci_sifreadb;
>+ tp->sifreadw = tms_pci_sifreadw;
>+ tp->sifwriteb = tms_pci_sifwriteb;
>+ tp->sifwritew = tms_pci_sifwritew;
>+ tp->tmspriv = cardinfo;
>+ memcpy(tp->ProductID, cardinfo->name, PROD_ID_SIZE + 1);
>
>- - tp->tmspriv = cardinfo;
>+ dev->open = tms_pci_open;
>+ dev->stop = tms_pci_close;
>
>- - dev->open = tms_pci_open;
>- - dev->stop = tms_pci_close;
>+ pdev->driver_data = dev;
>+ return 0;
>
>- - if (register_trdev(dev) == 0) {
>- - /* Enlist in the card list */
>- - card = kmalloc(sizeof(struct tms_pci_card), GFP_KERNEL);
>- - card->next = tms_pci_card_list;
>- - tms_pci_card_list = card;
>- - card->dev = dev;
>- - card->pci_dev = pdev;
>- - card->cardinfo = cardinfo;
>- - } else {
>- - printk("%s: register_trdev() returned non-zero.\n", dev->name);
>- - kfree(dev->priv);
>- - kfree(dev);
>- - return -1;
>- - }
>- - }
>- -
>- - if (tms_pci_card_list)
>- - return 0;
>- - return (-1);
>+fail_tmsdev_init:
>+fail_request_irq:
>+ unregister_netdevice(dev);
>+ kfree(dev);
>+fail_init_trdev:
>+ release_region(pci_ioaddr, TMS_PCI_IO_EXTENT);
>+ return -1;
> }
>
> /*
>@@ -282,51 +245,48 @@
> return 0;
> }
>
>- -#ifdef MODULE
>- -
>- -int init_module(void)
>+static void __exit tms_pci_remove_one(struct pci_dev *pdev)
> {
>- - /* Probe for cards. */
>- - if (tms_pci_probe()) {
>- - printk(KERN_NOTICE "tmspci.c: No cards found.\n");
>+ struct net_device *dev = pdev->driver_data;
>+
>+ /*
>+ * If we used a register offset, revert here.
>+ */
>+
>+ if (dev->priv) {
>+ struct net_local *tp = (struct net_local *)dev->priv;
>+ struct cardinfo_table *cardinfo = (struct cardinfo_table *)tp->tmspriv;
>+
>+ dev->base_addr -= cardinfo->registeroffset;
> }
>- - /* lock_tms380_module(); */
>- - return (0);
>+
>+ unregister_netdev(dev);
>+ release_region(dev->base_addr, TMS_PCI_IO_EXTENT);
>+ free_irq(dev->irq, dev);
>+ kfree(dev->priv);
>+ kfree(dev);
>+ /* unlock_tms380_module(); */
> }
>
>- -void cleanup_module(void)
>+static struct pci_driver tms_pci_pci_driver = {
>+ name: TMS_PCI_MODULE_NAME,
>+ id_table: tms_pci_pci_tbl,
>+ probe: tms_pci_init_one,
>+ remove: tms_pci_remove_one,
>+};
>+
>+static int __init tms_pci_init_module (void)
> {
>- - struct net_device *dev;
>- - struct tms_pci_card *this_card;
>+ return pci_module_init(&tms_pci_pci_driver);
>+}
>
>- - while (tms_pci_card_list) {
>- - dev = tms_pci_card_list->dev;
>- -
>- - /*
>- - * If we used a register offset, revert here.
>- - */
>- - if (dev->priv)
>- - {
>- - struct net_local *tp;
>- - struct cardinfo_table *cardinfo;
>- -
>- - tp = (struct net_local *)dev->priv;
>- - cardinfo = (struct cardinfo_table *)tp->tmspriv;
>- -
>- - dev->base_addr -= cardinfo->registeroffset;
>- - }
>- - unregister_netdev(dev);
>- - release_region(dev->base_addr, TMS_PCI_IO_EXTENT);
>- - free_irq(dev->irq, dev);
>- - kfree(dev->priv);
>- - kfree(dev);
>- - this_card = tms_pci_card_list;
>- - tms_pci_card_list = this_card->next;
>- - kfree(this_card);
>- - }
>- - /* unlock_tms380_module(); */
>+static void __exit tms_pci_cleanup_module (void)
>+{
>+ pci_unregister_driver(&tms_pci_pci_driver);
> }
>- -#endif /* MODULE */
>+
>+module_init(tms_pci_init_module);
>+module_exit(tms_pci_cleanup_module);
>
>
> /*
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Chris McClellen" <chris@transtech.cc>
>Date: Fri, 11 Aug 2000 11:43:56 -0400
>Subject: Re: [PATCH] Persistent RTC, against 2.2.16
>
>Due to a gaffe in testing I thought this patch worked; it does not.
>Please reject.
>
>The alarm -> power on functionality seems to be part of the APM bios.
>
>Does anyone here know how one sets the alarm so that it is persisent?
>Setting the RTC alarm does not seem to affect this part of the bios.
>Also, the 1.2 APM spec doesnt say anything about setting RTC alarms.
>
>Or am I just missing something ? Should my patch work in theory?
>Or is the "alarm" setting you see in APM sections of bios set up screens
>derived from RTC alarm? I think they may be vendor extensions?
>
>Any help would be appreciated.
>
>
>- ----- Original Message -----
>From: Chris McClellen <chris@transtech.cc>
>To: Linux Kernel mailing list <linux-kernel@vger.rutgers.edu>; <torvalds@transmeta.com>; <alan@lxorguk.ukuu.org.uk>
>Sent: Wednesday, August 09, 2000 11:30 AM
>Subject: [PATCH] Persistent RTC, against 2.2.16
>
>
>
>The problem:
>
>We have machines in the field that we would like to power cycle;
>that is, turn off, and have them turn themselves back on w/o a human
>in general. This of course won't always work, but it will in general.
>
>This is possible -- we can halt w/poweroff. But, before we do, we can
>set the rtc alarm via /dev/rtc. We can also set up the interrupt on
>alarm via /dev/rtc. The mobos have wake-on-alarm, and they will
>power themselves back on when the alarm interrupt goes off.
>
>So, we can set the alarm, poweroff, and it will powerback on....
>
>Except that /dev/rtc will clear the alarm interrupt enable when the
>device is closed (rtc_release). In fact, it clears all rtc interrupt
>enables. So, when the process that sets AIE exits, AIE gets cleared,
>thwarting our efforts.
>
>Solution:
>
>Added a RTC_PERSIST status that can be read/set via ioctls.
>
>By default it is _NOT_ set, giving original /dev/rtc behavior.
>
>When Set the following occurs:
>- - AIE is not cleared when rtc_release is called. The other interrupt
> enables get cleared as normal. I thought this would be desired, but
> it would be trivial to not clear the other IEs if persist is set.
>- - RTC_PERSIST remains between opens/closes.
> + If we cleared persist on close, then during halt someone could
> open/close /dev/rtc and undo our AIE. Thus, once set, RTC_PERSIST
> remains between open/close until unset via ioctl.
>
>We would like to see this make it into the official kernel
>so we dont have to maintain special patched kernels in the field.
>Of course we can, but it would be nice to be able to just use stock
>kernels in the future.
>
>
>See the attached patch.
>
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Chris McClellen" <chris@transtech.cc>
>Date: Fri, 11 Aug 2000 11:50:33 -0400
>Subject: [RFC] Setting RTC alarm time
>
>Simple RFC: How does one set the RTC alarm time? I know you can
>try to do it via /dev/rtc. However, on reboot, whatever was set in
>the BIOS under APM type screens will blow away the RTC alarm setting.
>
>That is, I can set an alarm via bios.
>
>Boot up Linux, change ALM time via /dev/rtc.
>
>Eventually boot linux again, ALM time is set to what I put in BIOS,
>not what linux set via /dev/rtc.
>
>While linux is booted, and you look at /proc/rtc, the alarm time there
>reflects what I set via /dev/rtc. The overall problem is that I want
>to be able to set the alarm time via linux and have it _stick_ -- so that
>If I go back into the bios, under the Power MGMT functions, the RTC
>alarm will be set to what I set via /dev/rtc.
>
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: rct@gherkin.sa.wlk.com (Bob_Tracy)
>Date: Fri, 11 Aug 2000 11:04:52 -0500 (CDT)
>Subject: 2.4.0-test6: PCI probe/config problem?
>
>2.4.0-test5 works fine, but here's what I get when I try 2.4.0-test6 on
>a Dell Latitude CPx:
>
>(...)
>PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=1
>PCI: Using configuration type 1
>PCI: Probing PCI hardware
>PCI: Using IRQ router default [8086/1234] at 00:07.0
>PCI: Error while updating region 00:03.0/1 (10000000 != 220000a0)
>PCI: Error while updating region 00:03.1/1 (10001000 != 020000a0)
>(...)
>Linux PCMCIA Card Services 3.1.20
> kernel build: 2.4.0-test6 #1 Thu Aug 10 17:32:03 CDT 2000
> options: [pci] [cardbus] [apm]
>Intel PCIC probe:
> Bridge register mapping failed: check cb_mem_base setting
>not found.
>ds: no socket drivers loaded!
>
>The "PCI:" lines are identical for a 2.4.0-test5 boot except that
>the "Error" lines don't show up: the CardBus bridge is at the
>expected 0x10000000 and 0x10001000 addresses.
>
>Any idea what's going on here?
>
>- --
>Bob Tracy
>rct@wlk.com
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Wade Hampton <whampton@staffnet.com>
>Date: Fri, 11 Aug 2000 12:06:04 -0400
>Subject: re: 2.2.17pre15/16 NFS SMP lockup
>
>Update: 2.2.16 stock kernel locks up as well when
>accessing the NFS server.
>
>Cheers,
>- --
>W. Wade, Hampton <whampton@staffnet.com>
>On July 8, 1947, witnesses claim a spaceship with five aliens aboard
>crashed on a sheep and cattle ranch outside Roswell, New Mexico.
>On March 31, 1948, nine months later, Al Gore was born!
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Marcelo Tosatti <marcelo@conectiva.com.br>
>Date: Fri, 11 Aug 2000 10:04:48 -0300 (BRT)
>Subject: Re: patch for md.c in 2.2.16
>
>On Fri, 11 Aug 2000, Lars Callenbach wrote:
>
>> I don't know whether it is known that kernel 2.2.16 has a problem with
>> multiple devices. In the file md.c line 449
>>
>> md_blocksizes[minor] <<= FACTOR_SHIFT(FACTOR((md_dev+minor)));
>>
>> has to be commented to get a running kernel. The error is the following one:
>> grow_buffers wants to much memory - kernel message:
>>
>> VFS: grow_buffers size = 16384
>>
>> If I comment/erase line 449 then everything works fine.
>
>This line was already removed in 2.2.17pre series.
>
>Thanks for reporting.
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Corin Hartland-Swann <cdhs@commerce.uk.net>
>Date: Fri, 11 Aug 2000 17:11:59 +0100 (BST)
>Subject: Re: Degrading disk read performance under 2.2.16
>
>Mark,
>
>I'm cross-posting this to the kernel and RAID lists again, because there's
>more information about the problem in here. I hope this is acceptable.
>
>On Thu, 10 Aug 2000, Mark Hahn wrote:
>> > Intel 810E Chipset Motherboard (CA810EAL), Pentium III-667, 32M RAM,
>> > Maxtor DiamondMax Plus 40 40.9GB UDMA66 Disk, Model 54098U8
>>
>> a low-memory machine, by today's standards. with one of the fastest
>> disks available. and, for that matter, a pretty fast CPU.
>
>The RAM is deliberately lowered - it normally has 128M. I lowered it so
>that I could benchmark with 256M file size, instead of the 1G or so it
>would take to get decent results.
>
>The idea behind the spec was to use really quite currrent components,
>fast processor and disk to stress the kernel as much as possible and
>reveal bottlenecks.
>
>> > I used tiotest to benchmark, using a file size of 256MB, block size of 4K,
>> > and with 1, 2, 4, 16, 32 threads. The performance starts to get hit as
>
>I forgot to add that I ran each test five times so as to get consistent
>results.
>
>> does larger blocksizes change the picture at all? I'm wondering whether
>> readahead is effecting things (shouldnt, but...)
>
>mke2fs only allows block sizes of 1K, 2K or 4K, so I can't make the
>blocksize any larger...
>
>> > ==> 2.2.16 <==
>> > Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
>> > ----- ------ ------- ---- ------------- -------------- --------------
>> > /mnt/ 256 4096 1 27.0948 10.5% 25.9272 22.5% 147.264 0.83%
>> > /mnt/ 256 4096 2 20.5753 8.42% 25.9316 22.7% 143.113 0.56%
>> > /mnt/ 256 4096 4 13.0397 6.09% 25.7723 22.7% 143.619 0.51%
>> > /mnt/ 256 4096 16 9.38573 5.40% 25.6285 23.1% 147.815 0.51%
>> > /mnt/ 256 4096 32 6.96358 5.90% 25.2889 22.9% 151.182 0.57%
>>
>> so when this is running, does "vmstat 1" indicate that the system's
>> swapping? I'm guessing so, that it's trying to scavenge pages from
>> live processes, ineffectually (since they're live), and thrashing.
>
>After going to all the trouble of testing this out, I remembered that I
>had not allocated any swap so that it couldn't influence the results at
>all! d'oh!
>
>> > I also tested 2.4.0-test5, and performance there sucks with one thread,
>> > but doesn't degrade any more quickly than 2.2.15
>> >
>> > ==> 2.4.0-test5 <==
>> >
>> > Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
>> > ----- ------ ------- ---- ------------- -------------- --------------
>> > /mnt/ 256 4096 1 8.15398 49.6% 7.64104 71.2% 125.675 5.90%
>> > /mnt/ 256 4096 2 8.01528 56.1% 7.63085 69.8% 123.076 5.59%
>> > /mnt/ 256 4096 4 7.79720 61.6% 7.62060 68.1% 125.437 5.75%
>> > /mnt/ 256 4096 16 7.64617 65.2% 7.60466 62.5% 129.431 5.83%
>> > /mnt/ 256 4096 32 7.60580 67.6% 7.58702 51.7% 132.791 5.95%
>>
>> wow, that's horrible performance. I have some of these disks,
>> and have never seen anything that bad. have you verified that
>> the ide controller is being recognized properly, that it's
>> using a decent udma33 or udma6 mode, etc?
>
>I think I've located the problem... (with kernel 2.4, anyway) - it is
>refusing to use DMA.
>
>When I try hdparm -m -c -d1 -a, I get the following output:
>
>/dev/hdc:
> setting using_dma to 1 (on)
> HDIO_SET_DMA failed: Operation not permitted
> multcount = 16 (on)
> I/O support = 1 (32-bit)
> using_dma = 0 (off)
> readahead = 8 (on)
>
>The other values are the same as the ones I'm using under the other
>kernels. My dmesg output looks like this:
>
>ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
>PIIX4: IDE controller on PCI bus 00 dev f9
>PIIX4: chipset revision 2
>PIIX4: not 100% native mode: will probe irqs later
>hda: IBM-DJNA-371350, ATA DISK drive
>hdb: Maxtor 54098U8, ATA DISK drive
>hdc: Maxtor 54098U8, ATA DISK drive
>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>ide1 at 0x170-0x177,0x376 on irq 15
>hda: 26520480 sectors (13578 MB) w/1966KiB Cache, CHS=1650/255/63
>hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63
>hdc: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=79406/16/63
>Partition check:
> hda: hda1 hda2 hda3
> hdb: hdb1
> hdc: [PTBL] [4982/255/63] hdc1
>
>Can anyone explain to me what the [PTBL] bit means? I've been wondering
>this for about 4 years now, and still don't know :)
>
>Anybody have any suggestions about how to get DMA working? Is it a problem
>with the IDE controller?
>
>> > I haven't tried any of this with SCSI disks, so the problem may well lie
>> > in VFS or the VM subsystem (I know there are problems there as well). I
>> > don't know anything about those, so I guess I should just leave it to the
>> > professionals now :)
>>
>> hmm, I just booted my dev machine with mem=32m, rather than it's normal
>> 128M. it gave the same bonnie results as with 128m.
>
>The amount of RAM shouldn't affect disk results. If it does, then the test
>file size you are using with the benchmarking tool isn't big enough. So,
>basically, this is the right result.
>
>Thanks,
>
>Corin
>
>/------------------------+-------------------------------------\
>| Corin Hartland-Swann | Direct: +44 (0) 20 7544 4676 |
>| Commerce Internet Ltd | Mobile: +44 (0) 79 5854 0027 |
>| 22 Cavendish Buildings | Tel: +44 (0) 20 7491 2000 |
>| Gilbert Street | Fax: +44 (0) 20 7491 2010 |
>| Mayfair | Web: http://www.commerce.uk.net/ |
>| London W1K 5HJ | E-Mail: cdhs@commerce.uk.net |
>\------------------------+-------------------------------------/
>
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Marcelo Tosatti <marcelo@conectiva.com.br>
>Date: Fri, 11 Aug 2000 10:18:12 -0300 (BRT)
>Subject: Re: 2.2.17pre15/16 NFS SMP lockup
>
>On Fri, 11 Aug 2000, Wade Hampton wrote:
>
>> Greetings.
>>
>> I have a new VA system and loaded 2.2.17pre. When I
>> try to access directories or some files from my
>> very stable NFS server, my system hangs hard.
>> The server is RH 5.0 with patches to 5.2, 2.0.33,
>> uptime 450+ days. Following the hang, I have
>> no mouse, no keyboard, no magic sys req keys, etc.
>> This seems to be similar to a problem I was
>> having with earlier 2.2.x kernels (x=5-12) --
>> maybe last fall (seemed to be NFS related).
>>
>> I know the old server's NFS is sort of broken,
>> but it is very stable. Use of it should not
>> hang my workstation.
>
>Please try to apply the NMI oopser patch and recompile your kernel so we
>may get some useful information about your crash.
>
>You can get it at
>http://people.redhat.com/mingo/NMI-watchdog-patches/NMI-oopser-2.2.15-A0
>
>It applies cleanly against 2.2.17pre16.
>
>Thanks
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andrew Morton <andrewm@uow.edu.au>
>Date: Sat, 12 Aug 2000 02:26:03 +1000
>Subject: [patch] PCI resource allocation
>
>This is a multi-part message in MIME format.
>- --------------3A2B8A0EEF46B01992B45EFA
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>The pci_assign_bus_resource() stuff which went into
>test6-pre7 broke PCI configuration. This is the
>cause of all the "PCI: Error while updating region"
>reports.
>
>Patch against -test6 is attached.
>- --------------3A2B8A0EEF46B01992B45EFA
>Content-Type: text/plain; charset=us-ascii;
> name="pci.fix"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="pci.fix"
>
>- --- ../linux-2.4.0-test6/drivers/pci/setup-res.c Fri Aug 11 19:06:12 2000
>+++ drivers/pci/setup-res.c Sat Aug 12 02:12:57 2000
>@@ -60,7 +60,8 @@
> struct resource *res,
> unsigned long size,
> unsigned long min,
>- - unsigned int type_mask)
>+ unsigned int type_mask,
>+ int resno)
> {
> int i;
>
>@@ -83,7 +84,7 @@
> continue;
>
> /* Update PCI config space. */
>- - pcibios_update_resource(dev, r, res, i);
>+ pcibios_update_resource(dev, r, res, resno);
> return 0;
> }
> return -EBUSY;
>@@ -100,14 +101,15 @@
> min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
>
> /* First, try exact prefetching match.. */
>- - if (pci_assign_bus_resource(bus, dev, res, size, min, IORESOURCE_PREFETCH) < 0) {
>+ if (pci_assign_bus_resource(bus, dev, res, size, min, IORESOURCE_PREFETCH, i) < 0) {
> /*
> * That failed.
> *
> * But a prefetching area can handle a non-prefetching
> * window (it will just not perform as well).
> */
>- - if (!(res->flags & IORESOURCE_PREFETCH) || pci_assign_bus_resource(bus, dev, res, size, min, 0) < 0) {
>+ if (!(res->flags & IORESOURCE_PREFETCH) ||
>+ pci_assign_bus_resource(bus, dev, res, size, min, 0, i) < 0) {
> printk(KERN_ERR "PCI: Failed to allocate resource %d for %s\n", i, dev->name);
> return -EBUSY;
> }
>
>- --------------3A2B8A0EEF46B01992B45EFA--
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Matthew Wilcox <matthew@wil.cx>
>Date: Fri, 11 Aug 2000 11:21:31 -0400
>Subject: Re: How to start to develop a filesystem ?
>
>On Fri, Aug 11, 2000 at 02:40:38PM +0100, Tigran Aivazian wrote:
>> Seriously though, the way to go is probably to print out sources of two
>> filesystems: ramfs (fs/ramfs/inode.c) and minix (fs/minix/*.c +
>> include/linux/minix*.h) and study their interaction with buffer cache and
>> page cache and VFS. If you are brave and are not afraid of huge complexity
>> of ext2 replace minix -> ext2 above.
>
>I would disagree. ext2 is not large!
>
>ext2: 4873 total
>minix: 3065 total
>
>and for those extra lines you get the most commonly used filesystem,
>the one least likely to have bugs, and the most likely to do things the
>Right Way as far as the VFS and VM are concerned.
>
>- --
>Revolutions do not require corporate support.
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Grzegorz A. Wieczorek" <gigo@ibb.waw.pl>
>Date: Fri, 11 Aug 2000 18:27:40 +0200 (MDT)
>Subject: Re: Kernel test6-preX-test6 not compiling. Networking/Netfilter problem?
>
> Hi,
>I have exactly same problem. When I compile netfilter as modules -
>everything goes well.
>
>On Fri, 11 Aug 2000 06:55:58 +0200 Udo Held wrote:
>
>> Hi!
>> My kernel isn't compiling anymore. I think it started to not do so with
>> the first test6-pre release. Otherwise it should be the second test6-pre
>> release. Maybe just the compiler switches are wrong. I didn't modify
>> them. Here the output while compiling[cutted to important points]:
>>
>> make[2]: Entering directory `/usr/src/linux/net'
>> rm -f network.o
>> ld -m elf_i386 -r -o network.o netsyms.o socket.o protocols.o
>> core/core.o ethernet/ethernet.o 802/802.o sched/sched.o ipv4/ipv4.o
>> ipv4/netfilter/netfilter.o unix/unix.o netlink/netlink.o packet/packet.o
>> sysctl_net.o
>> ipv4/netfilter/netfilter.o(.kstrtab+0x100): multiple definition of
>> `__kstrtab_ipt_unregister_target'
>> netsyms.o(.kstrtab+0x19c0): first defined here
>> ipv4/netfilter/netfilter.o(__ksymtab+0x20): multiple definition of
>> `__ksymtab_ipt_register_match'
>> netsyms.o(__ksymtab+0x740): first defined here
>> ipv4/netfilter/netfilter.o(.kstrtab+0x60): multiple definition of
>> `__kstrtab_ipt_unregister_table'
>> netsyms.o(.kstrtab+0x1980): first defined here
>> ipv4/netfilter/netfilter.o(.kstrtab+0x7f): multiple definition of
>> `__kstrtab_ipt_register_match'
>> (...)
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Christopher Vickery <vickery@ntcv.cs.qc.edu>
>Date: Fri, 11 Aug 2000 12:31:41 -0400 (EDT)
>Subject: NTFS-like streams?
>
>I'm interested in implementing a system that associates
>meta-data with inodes, and would like to know if it has
>already been done or is in the works. NTFS allows you to
>create multiple "streams" within a file. "echo hello > x:y"
>creates a zero-byte file named x with a "stream" named y
>containing hello. If you copy, move, rename, or delete x
>then y goes with it. Canonical example is x.bmp contains an
>image and x.bmp:thumbnail contains a thumbnail of the
>image. So far as I can tell, the NTFS for Linux project is
>not under active development, and ext3, reiserfs, jfs, etc.
>do not deal with this issue. Am I missing anything?
>
>tia
>Chris Vickery
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Marcelo Tosatti <marcelo@conectiva.com.br>
>Date: Fri, 11 Aug 2000 10:25:54 -0300 (BRT)
>Subject: Re: 2.2.17pre15 patched: state D
>
>On Thu, 10 Aug 2000, octave klaba wrote:
>
>> Hi,
>> We have run pre15 with mercelo's patch since yesterday
>> (pre16 was out this night, we will patch it this afternoon)
>>
>> I have a littel problem with thoses process:
>>
>> root 6795 0.0 0.0 1344 116 pts/5 D 11:01 0:00 nslookup ns9
>> root 7200 0.0 0.0 1332 312 pts/0 D 11:02 0:00 nslookup ns9
>> root 7984 0.0 0.0 1332 312 pts/6 D 11:04 0:00 nslookup ns8
>> root 9232 0.0 0.0 1332 312 pts/7 D 11:06 0:00 nslookup ns9
>>
>> I killed named and restarted it. nothing
>> I killed lot of process, but the memory "used" is still high.
>>
>> Since it is not taking CPU, I will not reboot the server.
>> So if you have any idea to fix it.
>
>Can you please see where this processes are sleeping?
>
>(you can use the 'ps xeo "wchan command" | grep nslookup' to see that)
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Camm Maguire <camm@enhanced.com>
>Date: 11 Aug 2000 12:39:12 -0400
>Subject: Re: IDE Tape problem in 2.2.16 (bug?)
>
>Greetings! Just to add another report in the same vein.
>
>hdb: HP COLORADO 14GB, ATAPI TAPE drive
>Aug 11 10:26:06 intech20 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>Aug 11 10:26:06 intech20 kernel: ide-tape: hdb: overriding capabilities->speed (assuming 650KB/sec)
>Aug 11 10:26:06 intech20 kernel: ide-tape: hdb: overriding capabilities->max_speed (assuming 650KB/sec)
>
>
>1) Generic 2.2.16 -- mt status gives
> Aug 10 16:35:19 intech20 kernel: ide-tape: ht0: I/O error, pc
> = 8, key = 5, asc = 2c, ascq = 0
>
> Everything else basically works.
>
>2) 2.2.16 with ide patch
> mt status error as above
> writing tape appears to work
> can't read tape beyond a certain length
>
>Take care,
>
>
>- --
>Camm Maguire camm@enhanced.com
>==========================================================================
>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Tigran Aivazian <tigran@veritas.com>
>Date: Fri, 11 Aug 2000 17:45:02 +0100 (BST)
>Subject: Re: How to start to develop a filesystem ?
>
>On Fri, 11 Aug 2000, Matthew Wilcox wrote:
>> I would disagree. ext2 is not large!
>>
>> ext2: 4873 total
>> minix: 3065 total
>
>minix is actually two filesystems - V2 and V1. As for ext2 it may not be
>large in comparison to some others but it is still quite
>complicated. But yes, if something looks wrong or broken in some other
>filesystem one goes back to ext2 to use it as a perfect, known to be
>ideal, example.
>
>Regards,
>Tigran
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: khromy <khromy@khromy.ath.cx>
>Date: Fri, 11 Aug 2000 12:45:46 -0400
>Subject: [OOPS] linux-2.4.0test6 uhci.o
>
>I got this while I tried modprobe uhci;
>
>root@kpc:~# modprobe uhci
>kernel BUG at slab.c:805!
>invalid operand: 0000
>CPU: 0
>EIP: 0010:[<c0127010>]
>EFLAGS: 00010286
>eax: 0000001a ebx: c3fcf824 ecx: c020716c edx: 00000001
>esi: c3fcf81e edi: c48c6507 ebp: c3fcf82c esp: c1e07ef4
>ds: 0018 es: 0018 ss: 0018
>Process modprobe (pid: 8581, stackpage=c1e07000)
>Stack: c01d04f0 c01d0590 00000325 c48c2000 fffffff4 c48c204d ffffffea c3fcf840
> c02531ec c3fcf888 c1e07f24 00000004 00000000 c48c5920 c48c64f9 00000020
> 00000020 00000000 00000000 00000000 c48c2000 00000001 c0128b8b c48c5ac1
>Call Trace: [<c01d04f0>] [<c01d0590>] [<c48c2000>] [<c48c204d>] [<c48c5920>] [<c48c64f9>] [<c48c2000>]
> [<c0128b8b>] [<c48c5ac1>] [<c0118a08>] [<c48c2048>] [<c48d3000>] [<c48c2048>] [<c010a2cf>]
>Code: 0f 0b 83 c4 0c 8b 1b 81 fb 5c 81 20 c0 75 c2 a1 5c 81 20 c0
>Segmentation fault
>
>Here it is through ksymoops:
>
>ksymoops 2.3.4 on i686 2.4.0-test6. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.4.0-test6/ (default)
> -m /boot/System.map-2.4.0-test6 (default)
>
>Warning: You did not tell me where to find symbol information. I will
>assume that the log matches the kernel and modules that are running
>right now and I'll use the default options above for symbol resolution.
>If the current kernel and/or modules do not match the log, you can get
>more accurate output by telling me the kernel version and where to find
>map, modules, ksyms etc. ksymoops -h explains the options.
>
>invalid operand: 0000
>CPU: 0
>EIP: 0010:[<c0127010>]
>Using defaults from ksymoops -t elf32-i386 -a i386
>EFLAGS: 00010286
>eax: 0000001a ebx: c3fcf824 ecx: c020716c edx: 00000001
>esi: c3fcf81e edi: c48c6507 ebp: c3fcf82c esp: c1e07ef4
>ds: 0018 es: 0018 ss: 0018
>Process modprobe (pid: 8581, stackpage=c1e07000)
>Stack: c01d04f0 c01d0590 00000325 c48c2000 fffffff4 c48c204d ffffffea c3fcf840
> c02531ec c3fcf888 c1e07f24 00000004 00000000 c48c5920 c48c64f9 00000020
> 00000020 00000000 00000000 00000000 c48c2000 00000001 c0128b8b c48c5ac1
>Call Trace: [<c01d04f0>] [<c01d0590>] [<c48c2000>] [<c48c204d>] [<c48c5920>] [<c48c64f9>] [<c48c2000>]
> [<c0128b8b>] [<c48c5ac1>] [<c0118a08>] [<c48c2048>] [<c48d3000>] [<c48c2048>] [<c010a2cf>]
>Code: 0f 0b 83 c4 0c 8b 1b 81 fb 5c 81 20 c0 75 c2 a1 5c 81 20 c0
>
>>>EIP; c0127010 <kmem_cache_create+330/374> <=====
>Trace; c01d04f0 <tvecs+1620/13450>
>Trace; c01d0590 <tvecs+16c0/13450>
>Trace; c48c2000 <[usbserial].bss.end+1525/1585>
>Trace; c48c204d <[usbserial].bss.end+1572/1585>
>Trace; c48c5920 <[uhci]uhci_init+6c/130>
>Trace; c48c64f9 <[uhci].rodata.start+a19/ae1>
>Trace; c48c2000 <[usbserial].bss.end+1525/1585>
>Trace; c0128b8b <__free_pages+13/14>
>Trace; c48c5ac1 <[uhci]init_module+5/8>
>Trace; c0118a08 <sys_init_module+3d0/440>
>Trace; c48c2048 <[usbserial].bss.end+156d/1585>
>Trace; c48d3000 <[isofs]__module_kernel_version+0/1b>
>Trace; c48c2048 <[usbserial].bss.end+156d/1585>
>Trace; c010a2cf <system_call+33/38>
>Code; c0127010 <kmem_cache_create+330/374>
>00000000 <_EIP>:
>Code; c0127010 <kmem_cache_create+330/374> <=====
> 0: 0f 0b ud2a <=====
>Code; c0127012 <kmem_cache_create+332/374>
> 2: 83 c4 0c add $0xc,%esp
>Code; c0127015 <kmem_cache_create+335/374>
> 5: 8b 1b mov (%ebx),%ebx
>Code; c0127017 <kmem_cache_create+337/374>
> 7: 81 fb 5c 81 20 c0 cmp $0xc020815c,%ebx
>Code; c012701d <kmem_cache_create+33d/374>
> d: 75 c2 jne ffffffd1 <_EIP+0xffffffd1> c0126fe1 <kmem_cache_create+301/374>
>Code; c012701f <kmem_cache_create+33f/374>
> f: a1 5c 81 20 c0 mov 0xc020815c,%eax
>
>
>1 warning issued. Results may not be reliable.
>
>** Please let me know if you need anymore information. :)
>
>- --
>L1: khromy ;khromy@khromy.ath.cx
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andries Brouwer <aeb@veritas.com>
>Date: Fri, 11 Aug 2000 18:35:21 +0200
>Subject: Re: Degrading disk read performance under 2.2.16
>
>On Fri, Aug 11, 2000 at 05:11:59PM +0100, Corin Hartland-Swann wrote:
>
>> Partition check:
>> hda: hda1 hda2 hda3
>> hdb: hdb1
>> hdc: [PTBL] [4982/255/63] hdc1
>>
>> Can anyone explain to me what the [PTBL] bit means? I've been wondering
>> this for about 4 years now, and still don't know :)
>
>For all details (for 2.0.8, some things are slightly different today)
>see the Large-Disk HOWTO
> http://www.win.tue.nl/~aeb/linux/Large-Disk-8.html#ss8.5
>
>The short summary is that [PTBL] in front of the geometry
>means that the geometry was not taken from disk, or BIOS, or
>kernel command line, but derived from the partition table.
>
>Disk geometry is totally unrelated to disk performance.
>
>Andries
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Marcelo Tosatti <marcelo@conectiva.com.br>
>Date: Fri, 11 Aug 2000 10:53:17 -0300 (BRT)
>Subject: Re: oops 2.2.17pre15
>
>On Fri, 11 Aug 2000, octave klaba wrote:
>
><snip>
>
>> >>EIP; c011a733 <try_to_read_ahead+6f/114> <=====
>> Trace; c011ab92 <do_generic_file_read+2ee/5e4>
>> Trace; c011af3b <generic_file_read+63/7c>
>> Trace; c011ae88 <file_read_actor+0/50>
>> Trace; c0122a0a <sys_read+ae/c4>
>> Trace; c01079bc <system_call+34/38>
>> Code; c011a733 <try_to_read_ahead+6f/114>
>> 00000000 <_EIP>:
>> Code; c011a733 <try_to_read_ahead+6f/114> <=====
>> 0: 39 72 08 cmpl %esi,0x8(%edx) <=====
>> Code; c011a736 <try_to_read_ahead+72/114>
>> 3: 75 f4 jne fffffff9 <_EIP+0xfffffff9> c011a72c <try_to_read_ahead+68/114>
>> Code; c011a738 <try_to_read_ahead+74/114>
>> 5: 39 6a 0c cmpl %ebp,0xc(%edx)
>> Code; c011a73b <try_to_read_ahead+77/114>
>> 8: 75 ef jne fffffff9 <_EIP+0xfffffff9> c011a72c <try_to_read_ahead+68/114>
>> Code; c011a73d <try_to_read_ahead+79/114>
>> a: ff 42 14 incl 0x14(%edx)
>> Code; c011a740 <try_to_read_ahead+7c/114>
>> d: b8 02 00 00 00 movl $0x2,%eax
>> Code; c011a745 <try_to_read_ahead+81/114>
>> 12: 0f ab 00 btsl %eax,(%eax)
>
>Well, thats __find_page() again. (same problem as the
>update_vm_cache_conditional you reported)
>
>Did you had my previous patch applied when this oops happened?
>
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Theodore Ts'o" <tytso@mit.edu>
>Date: Fri, 11 Aug 2000 12:58:43 -0400
>Subject: Re: HFS-formatted CDROMs (was: Re: Linux 2.4 Status)
>
> Date: Thu, 10 Aug 2000 18:39:30 +0200
> From: Jens Axboe <axboe@suse.de>
>
> On Thu, Aug 10 2000, Theodore Ts'o wrote:
> > OK, can we get confirmation from folks that the problem with HFS
> > filesystems only occurs on with folks who are using SCSI CD-ROM's?
> >
> > I just want to make sure this is properly noted on the 2.4 issues
> > page.....
>
> I think this is a safe assumption, ide-cd works fine with < 2KB block
> size fs. Note that this problem is not restricted to HFS, ext2 with
> < 2KB block size on SCSI CD-ROM will also fail.
>
>Having not heard anyone who complained about reported problems HFS
>filesystems telling me that they have IDE devices, so noted.
>
>Next question. Is anyone lined up to fix this?
>
>(Jens, you're listed as the SCSI CDROM driver maintainer in the
>MAINTAINERs file; are you going to be working on getting this fixed, or
>is this a "will not fix" for 2.4?)
>
> - Ted
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Meino Christian Cramer <mccramer@s.netic.de>
>Date: Fri, 11 Aug 2000 18:57:22 +0200
>Subject: Re: 2.4.0-test6 swapon problems, nearly hangs
>
>Hello again ;-)
>
> ...sorry folks, wrong alert. It was my fault...modutils were
> wrongly installed.
>
> Kernel now boots at lightspeed (as usual...;-)
>
> Keep hacking on the right site of life!
> Meino
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Jens Axboe <axboe@suse.de>
>Date: Fri, 11 Aug 2000 19:05:10 +0200
>Subject: Re: HFS-formatted CDROMs (was: Re: Linux 2.4 Status)
>
>On Fri, Aug 11 2000, Theodore Ts'o wrote:
>> I think this is a safe assumption, ide-cd works fine with < 2KB block
>> size fs. Note that this problem is not restricted to HFS, ext2 with
>> < 2KB block size on SCSI CD-ROM will also fail.
>>
>> Having not heard anyone who complained about reported problems HFS
>> filesystems telling me that they have IDE devices, so noted.
>
>ide-cd never had this problem and I just verified with a 512 byte
>ext2 fs on a CD-ROM that it works there, but not with sr.
>
>> Next question. Is anyone lined up to fix this?
>>
>> (Jens, you're listed as the SCSI CDROM driver maintainer in the
>> MAINTAINERs file; are you going to be working on getting this fixed, or
>> is this a "will not fix" for 2.4?)
>
>Yes, I will fix it. I actually talked to Eric about this some months
>back, because the SCSI changes in 2.3 broke the support for < 2KB
>fs.
>
>- --
>* Jens Axboe <axboe@suse.de>
>* SuSE Labs
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Jens Axboe <axboe@suse.de>
>Date: Fri, 11 Aug 2000 19:02:05 +0200
>Subject: Re: IDE Tape problem in 2.2.16 (bug?)
>
>On Fri, Aug 11 2000, Camm Maguire wrote:
>> hdb: HP COLORADO 14GB, ATAPI TAPE drive
>> Aug 11 10:26:06 intech20 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>> Aug 11 10:26:06 intech20 kernel: ide-tape: hdb: overriding capabilities->speed (assuming 650KB/sec)
>> Aug 11 10:26:06 intech20 kernel: ide-tape: hdb: overriding capabilities->max_speed (assuming 650KB/sec)
>>
>>
>> 1) Generic 2.2.16 -- mt status gives
>> Aug 10 16:35:19 intech20 kernel: ide-tape: ht0: I/O error, pc
>> = 8, key = 5, asc = 2c, ascq = 0
>
>Command sequence error for the READ command. Does anyone know where
>ide-tape specs are located? I've been looking, but can't seem to find them.
>
>- --
>* Jens Axboe <axboe@suse.de>
>* SuSE Labs
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
>Date: Fri, 11 Aug 2000 14:15:31 -0300
>Subject: [PATCH] fix cosa.c resource allocation
>
>Hi,
>
> Please take a look and consider applying.
>
>- - Arnaldo
>
>
>- --- linux-2.4.0-test6/drivers/net/wan/cosa.c Thu Jul 13 01:58:43 2000
>+++ linux-2.4.0-test6.acme/drivers/net/wan/cosa.c Fri Aug 11 14:11:00 2000
>@@ -75,6 +75,8 @@
> /*
> * 5/25/1999 : Marcelo Tosatti <marcelo@conectiva.com.br>
> * fixed a deadlock in cosa_sppp_open
>+ * 8/11/2000 : Arnaldo Carvalho de Melo <acme@conectiva.com.br>
>+ * check resource allocation on cosa_probe
> */
>
> /* ---------- Headers, macros, data structures ---------- */
>@@ -551,20 +553,23 @@
> request_region(base, is_8bit(cosa)?2:4, cosa->type);
> if (request_irq(cosa->irq, cosa_interrupt, 0, cosa->type, cosa))
> goto bad1;
>- - if (request_dma(cosa->dma, cosa->type)) {
>- - free_irq(cosa->irq, cosa);
>- -bad1: release_region(cosa->datareg,is_8bit(cosa)?2:4);
>- - printk(KERN_NOTICE "cosa%d: allocating resources failed\n",
>- - cosa->num);
>- - return -1;
>- - }
>+ if (request_dma(cosa->dma, cosa->type))
>+ goto bad2;
>
> cosa->bouncebuf = kmalloc(COSA_MTU, GFP_KERNEL|GFP_DMA);
>+
>+ if (!cosa->bouncebuf)
>+ goto bad3;
>+
> sprintf(cosa->name, "cosa%d", cosa->num);
>
> /* Initialize the per-channel data */
> cosa->chan = kmalloc(sizeof(struct channel_data)*cosa->nchannels,
> GFP_KERNEL);
>+
>+ if (!cosa->chan)
>+ goto bad4:
>+
> memset(cosa->chan, 0, sizeof(struct channel_data)*cosa->nchannels);
> for (i=0; i<cosa->nchannels; i++) {
> cosa->chan[i].cosa = cosa;
>@@ -577,6 +582,13 @@
> cosa->datareg, cosa->irq, cosa->dma, cosa->nchannels);
>
> return nr_cards++;
>+
>+bad4: kfree(cosa->bouncebuf);
>+bad3: free_dma(cosa->dma);
>+bad2: free_irq(cosa->irq, cosa);
>+bad1: release_region(cosa->datareg,is_8bit(cosa)?2:4);
>+ printk(KERN_NOTICE "cosa%d: allocating resources failed\n", cosa->num);
>+ return -1;
> }
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Kanoj Sarcar <kanoj@google.engr.sgi.com>
>Date: Fri, 11 Aug 2000 10:21:17 -0700 (PDT)
>Subject: Re: pte_pagenr/MAP_NR deleted in pre6
>
>>
>> Roman Zippel writes:
>> > Can you send me that patch? I'd like to check it, if it can be used for
>
>http://oss.sgi.com/projects/numa/download/map.patch
>
>And even if it doesn't help m68k, it definitely will help mips64, ia64
>and ARM (from what I am understanding from Russell). So, unless it is
>_breaking_ m68k, I would rather see the patch go in ...
>
>> > the m68k port. m68k still has its own support for discontinous mem and
>> > from what I've seen so far I'm not really convinced yet to give it up.
>>
>> I don't see anything wrong in continuing with this. ARM also does
>> this in addition to support for the discontig mem stuff. Why?
>>
>> The generial discontig code is ok so long as you have a lot of RAM
>> in node 0. However, since all allocations currently come from node
>> 0, if this node is small, then there is a chance that you will run
>> out of memory at bootup, and then not be able to continue (and
>> because we both use fbcon, there is no message visible to the user,
>> and hence no diagnostics).
>
>Note: the biggest component of bootmem allocation is the mem_map for
>that node, which happens on specific nodes. I agree, other allocations
>happen out of node 0, but if there is a chance that on specific architectures
>we might run out of memory on node 0, we can fix this, although I would
>like to hear details offline ...
>
>>
>> Continuing with the single node but many "areas" that ARM follows, and
>> from what it sounds like m68k does, means that you can allocate from
>> any "area", and therefore don't hit this restriction.
>>
>> One way out of this would be if the NUMA stuff can have the "allocations
>> only from node 0" feature turned off, and then I'd be happy to let the
>> ARM version be replaced totally by the discontig case.
>
>This is not NUMA, this is regular DISCONTIG. One option while doing
>alloc_bootmem (ie, no node specified), is to do the allocation from node
>0, since no other node can be guranteed to exist.
>
>If this sounds too constricting, we can modify alloc_bootmem to try
>allocating from all nodes for which alloc_bootmem_node() has already
>been done. Shouldn't be too hard to implement and the changes are
>completely in the bootmem allocator code. Lets talk offline (along
>with Roman) if you are interested.
>
>Kanoj
>
>> _____
>> |_____| ------------------------------------------------- ---+---+-
>> | | Russell King rmk@arm.linux.org.uk --- ---
>> | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
>> | +-+-+ --- -+-
>> / | THE developer of ARM Linux |+| /|\
>> / | | | --- |
>> +-+-+ ------------------------------------------------- /\\\ |
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@kvack.org. For more info on Linux MM,
>> see: http://www.linux.eu.org/Linux-MM/
>>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: tdanis@canal-plus.fr
>Date: Fri, 11 Aug 2000 19:27:23 +0200
>Subject: Re: How to start to develop a filesystem ?
>
>On Fri, Aug 11, 2000 at 05:45:02PM +0100, tigran@veritas.com wrote:
>> On Fri, 11 Aug 2000, Matthew Wilcox wrote:
>> > I would disagree. ext2 is not large!
>> >
>> > ext2: 4873 total
>> > minix: 3065 total
>>
>> minix is actually two filesystems - V2 and V1. As for ext2 it may not be
>> large in comparison to some others but it is still quite
>> complicated. But yes, if something looks w
Send your favorite photo with any online greeting!
http://www.whowhere.lycos.com/redirects/americangreetings.rdct
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:25 EST