Re: maximum number of sockets
Hello, Yes, I know this can be done in older kernels, however in 2.4.0-test8, I DO NOT see a /proc/sys/fs/inode-max! I also do not see any changes listed in the Documentation. Thanks, Lee --Original Message-- From: Dan Kegel <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Sent: September 20, 2000 7:00:22 AM GMT Subject: Re: maximum number of sockets Lee Chin ([EMAIL PROTECTED]) wrote: > How do I increase the maximum number of socket connections I can have open > in the 2.4 series kernel? See http://www.kegel.com/c10k.html#limits.filehandles - Dan __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __ucmpdi2
Jeremy Higdon writes:
> In reality, the switch does a 60 bit shift right, so I can cast to a
> uint, which is the right thing to do on old architectures :-), solving
> the problem. I had originally thought that the problem was in all the
> masks, shifts, and compares, but they are all inlined.
Well, what do you care about most? The problem can be solved in
other, more disturbing ways. :-) For example, gcc's computed goto.
uint64_t
former_user_of___ucmpdi2(uint64_t node, uint64_t port){
static const void *jumps[16] = {
&&case_foo, /* 0 */
&&case_foo, /* 1 */
&&case_foo, /* 2 */
&&case_foo, /* 3 */
&&case_foo, /* 4 */
&&case_foo, /* 5 */
&&case_foo, /* 6 */
&&case_foo, /* 7 */
&&case_bar, /* 8 */
&&case_bar, /* 9 */
&&case_bar, /* a */
&&case_bar, /* b */
&&case_baz, /* c */
&&case_baz, /* d */
&&case_xxx, /* e */
&&case_yyy /* f */
};
goto *(jumps[node>>60]);
case_foo:
/* foo code here */
return 42;
case_bar:
/* bar code here */
return 18;
case_baz:
/* baz code here */
return 34;
case_xxx:
/* xxx code here */
return 63;
case_yyy:
/* yyy code here */
return 81;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre3: sit tunnel problems
Gerhard Mack wrote: > > ifconfig sit0 up tunnel ::206.123.31.102 > SIOCSIFDSTADDR: No buffer space available > > Anyone know why it does this? I can't seem to find any documentation on > that error... > > Gerhard > > -- > Gerhard Mack > > [EMAIL PROTECTED] I have submitted a patch to solve this bug. Has not been accepted thow :-( Hi, I found that creating an ipv6 tunnel with ifconfig does not work. after some comparing between a 2.2 kernel and 2.4.0.testX I found that the name of the newly created sit device is not passed back to the reqestor. See linux/net/ipv6/addrconf.c and follow the call chain. This seems to be introduced by fact that the parameters in 2.4 are copied while in 2.2 kernels this was not the case. My simple patch fixes this one problem. after applying I can now successfuly create ipv6 tunnels with ifconfig. Please apply this patch. thanks, Jorg -- Jorg de Jong Work : mailto:[EMAIL PROTECTED] Play : mailto:[EMAIL PROTECTED] --- linux-2.4.0-test8/net/ipv6/sit.cMon Aug 28 21:03:11 2000 +++ linux/net/ipv6/sit.cTue Aug 15 22:28:27 2000 @@ -188,7 +188,7 @@ } if (i==100) goto failed; - memcpy(parms->name, dev->name, IFNAMSIZ); + memcpy(nt->parms.name, dev->name, IFNAMSIZ); } if (register_netdevice(dev) < 0) goto failed;
for Martin (Re: weird PCI problems... (fwd)
Martin, I got bounces from your <[EMAIL PROTECTED]> address - so I am not sure if you received this info you requested: -- Forwarded message -- Date: Tue, 19 Sep 2000 22:05:24 +0100 (BST) From: Tigran Aivazian <[EMAIL PROTECTED]> To: Martin Mares <[EMAIL PROTECTED]> Cc: Andrew Morton <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: weird PCI problems... On Tue, 19 Sep 2000, Martin Mares wrote: > Anyway, can you send me your /proc/ioports and /proc/iomem, please? Yes, sure: -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000d-000d0fff : Extension ROM 000d4000-000d47ff : Extension ROM 000f-000f : System ROM 0010-07fe : System RAM 0010-00246197 : Kernel code 00246198-0025cf37 : Kernel data 07ff-07ff : ACPI Tables 1000-1fff : Texas Instruments PCI1225 10001000-10001fff : Texas Instruments PCI1225 (#2) 100a-100f : reserved 1040-107f : PCI CardBus #03 1040-1041 : PCI device 10b7:5257 1080-10bf : PCI CardBus #03 1080-1080007f : PCI device 10b7:5257 10800080-108000ff : PCI device 10b7:5257 10c0-10ff : PCI CardBus #04 1100-113f : PCI CardBus #04 a000-afff : card services f000-f3ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge f500-f5ff : PCI Bus #02 f600-f6ff : PCI Bus #01 fa00-fbff : PCI Bus #02 fae0-faef : Intel Corporation 82557 [Ethernet Pro 100] faffd000-faffdfff : Adaptec AIC-7880U faffe000-faffefff : Intel Corporation 82557 [Ethernet Pro 100] faffe000-faffefff : eepro100 fafff800-fafff87f : 3Com Corporation 3c905C-TX [Fast Etherlink] fafffc00-fafffcff : Realtek Semiconductor Co., Ltd. RTL-8139 fafffc00-fafffcff : eth2 fc00-feff : PCI Bus #01 fcfff000-fcff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x fd00-fdff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x ffe0- : reserved - -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(set) 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0800-083f : Intel Corporation 82371AB PIIX4 ACPI 0840-085f : Intel Corporation 82371AB PIIX4 ACPI 0860-086f : Intel Corporation 82371AB PIIX4 IDE 0860-0867 : ide0 0868-086f : ide1 0cf8-0cff : PCI conf1 1000-10ff : PCI CardBus #03 1000-107f : PCI device 10b7:5257 1000-107f : eth3 1400-14ff : PCI CardBus #03 1800-18ff : PCI CardBus #04 1c00-1cff : PCI CardBus #04 d800-d8ff : ESS Technology ES1978 Maestro 2E d800-d8ff : ESS Maestro 2E dce0-dcff : Intel Corporation 82371AB PIIX4 USB e000-efff : PCI Bus #01 ec00-ecff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x f000- : PCI Bus #02 f000-f0ff : Adaptec AIC-7880U f800-f87f : 3Com Corporation 3c905C-TX [Fast Etherlink] f800-f87f : eth0 f880-f88f : CMD Technology Inc PCI0646 f880-f887 : ide2 f888-f88f : ide3 f898-f89b : CMD Technology Inc PCI0646 f8a0-f8a7 : CMD Technology Inc PCI0646 f8b0-f8b3 : CMD Technology Inc PCI0646 f8b8-f8bf : CMD Technology Inc PCI0646 f8c0-f8ff : Intel Corporation 82557 [Ethernet Pro 100] f8c0-f8ff : eepro100 fc00-fcff : Realtek Semiconductor Co., Ltd. RTL-8139 fc00-fcff : eth2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bug report
On Wed, 20 Sep 2000, frank wrote:
> ok:
> switch(parity) {
> case 'o': case 'O':
> cflag |= PARODD;
> cflag |= PARENB;
can't you just do (PARODD|PARENB) instead? Also, producing diff -ur output
makes it a lot easier to read, you know.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Jeremy Higdon wrote: [...] > My system has both an Adaptec adapter and a Qlogic adapter. The number of > disks on the Qlogic was variable (it was attached to a SAN). The boot > disk is attached to the Adaptec. If the Qlogic was probed first, then > linux could not find the root device, so I had to move the Adaptec 7xxx > above the Qlogic in hosts.c. > > Is there another way to do this? If so, I'd like to know. If not, then > we need the same configurability with the new scheme. > I have the same problem. Boot from raid-1 on a Tekram LVD controller, and have an adaptec with an old cdrom and sometimes a disk too. The adaptec is detected first. But there is an easy fix: Compile the boot controller into the kernel, and let the other controller be modular. Compiled-in controllers always go before modular. Ideally I'd like specifying controller order in menuconfig. Perhaps a "controller order" submenu in scsi, that display the default order of the selected controllers. The user can then change this. I guess that is 2.5 stuff though. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Given an image, how can show its config?
Dear all, I would like to upgrade my kernel which is bundled with Red Hat. However, I don't want to lose modules/functions it has complied. How can I do it? Is there any command to check the current config and how can I check the modules it has as well? Many thanks!!! Best regards, Boris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APIC errors on my dual celeron, 2.4.0-test7
Seth R Arnold wrote: [...] > APIC error on CPU1: 02(02) > APIC error on CPU1: 02(08) [...] > Is this something I should be worried about? No. The APIC retries the stuff that go wrong, so all you get is a very slight performance degradation. Nothing to worry about unless it happens hundreds of times per second, or require extreme latency on _every_ interrupt. > Is this something other > people are familiar with and know how to fix? Almost all bp6 owner get this when they run a kernel that report APIC trouble. You can improve the situation by: * not overclocking * use a really good power supply, a bp6 draws more current than a single-cpu board. One with lots of watts are probably good. Or look for "athlon approved", athlons require good power too. * extra cooling of the board. Replace that little green heatsink with a fan, and use thermal grease. A 486 fan or 40mm fan is suposed to fit perfectly. Make sure there is good airflow throgh the case, and good circulation over the entire board. > Is it something that > should be fixed? :) This isn't something you need to worry about - it is more a "I want a clean logfile" issue. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Freezes with test9-pre4 + mmap002
Hello, I got the same here. My computer (UP pentium 100 with 32 meg ram) froze this morning, i was not doing stresstesting at all, the machine was verry lightly or not loaded. The kernel i used before was test8-riel2-blk3, which never had such lockups. (so the bug has creeped in verry recently i guess) Greets, Frank Dekervel "Juan J. Quintela" wrote: > Hi > while I am running mmap002 in test9-pre4 I got the computer > frozen, it don't answer to my open windows anymore, it answers > only to pings. I have got the attached traces. The machine > is SMP with IDE disks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Given an image, how can show its config?
On Wed, 20 Sep 2000 17:09:27 +0800 (CST), <[EMAIL PROTECTED]> wrote: >I would like to upgrade my kernel which is bundled with Red Hat. Ask redhat for the .config, this is not a problem for the linux-kernel list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Wed, 20 Sep 2000 10:43:35 +0200, Helge Hafting <[EMAIL PROTECTED]> wrote: >Ideally I'd like specifying controller order in menuconfig. Perhaps a >"controller order" submenu in scsi, that display the default order >of the selected controllers. The user can then change this. >I guess that is 2.5 stuff though. Part of the 2.5 Makefile redesign is adding LINK_FIRST and LINK_LAST entries in Makefiles. The link order will be $(LINK_FIRST), (the rest), $(LINK_LAST). Link first and last entries will be done in the Makefile defined order, the rest will be linked in alphabetical order. And there will be a great big note: Do not use LINK_FIRST or LINK_LAST unless you really (and I mean *REALLY*) have to! All reasons for using LINK_FIRST and LINK_LAST must be documented. To handle newer controllers which mimic older controllers, the newer controllers would be listed in LINK_FIRST. At the moment we do not have any plans to allow user ordering of controllers via .config, only via editting the Makefile. The plan is to clean up the Makefiles first, introducing new facilities comes later (if ever). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
null TTY in tty_fasync?
At the end of a UUCP poll this message was logged: Sep 19 23:42:47 wonderland kernel: Warning: null TTY for (04:40) in tty_fasync What does it mean? Linux wonderland.linux.it 2.4.0-test8 #12 Sat Sep 16 19:35:51 CEST 2000 i586 unknown -- ciao, Marco - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __release_region() printf format
Hi!
> __release_region() always uses `%04lx', while start and end may be larger
> (e.g. for release_mem_region()).
What about making it %lx-%lx without any numbers?
Pavel
> --- linux-2.4.0-test9-pre2/kernel/resource.c.orig Mon Jul 17 15:24:34 2000
> +++ linux-2.4.0-test9-pre2/kernel/resource.c Mon Sep 18 16:15:33 2000
> @@ -288,7 +288,7 @@
> }
> p = &res->sibling;
> }
> - printk("Trying to free nonexistent resource <%04lx-%04lx>\n", start, end);
> + printk("Trying to free nonexistent resource <%08lx-%08lx>\n", start, end);
> }
>
> /*
>
> Gr{oetje,eeting}s,
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Keith Owens wrote: > > On Wed, 20 Sep 2000 10:43:35 +0200, > Helge Hafting <[EMAIL PROTECTED]> wrote: > >Ideally I'd like specifying controller order in menuconfig. Perhaps a > >"controller order" submenu in scsi, that display the default order > >of the selected controllers. The user can then change this. > >I guess that is 2.5 stuff though. > > Part of the 2.5 Makefile redesign is adding LINK_FIRST and LINK_LAST > entries in Makefiles. The link order will be $(LINK_FIRST), (the > rest), $(LINK_LAST). Link first and last entries will be done in the > Makefile defined order, the rest will be linked in alphabetical order. > > And there will be a great big note: Do not use LINK_FIRST or LINK_LAST > unless you really (and I mean *REALLY*) have to! All reasons for using > LINK_FIRST and LINK_LAST must be documented. > > To handle newer controllers which mimic older controllers, the newer > controllers would be listed in LINK_FIRST. At the moment we do not > have any plans to allow user ordering of controllers via .config, only > via editting the Makefile. The plan is to clean up the Makefiles > first, introducing new facilities comes later (if ever). Interesting. Do you mean that you don't want any user reordering via .config at all, or merely that you yourself have more important stuff to do. I can code up something myself if I feel the need. Complete control of order is ideal, it solves every problem an expert user might have. Ability to put one particular controller first solves the boot issues just fine though. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __release_region() printf format
On Tue, 19 Sep 2000 00:11:59 +0200,
Pavel Machek <[EMAIL PROTECTED]> wrote:
>Hi!
>
>> __release_region() always uses `%04lx', while start and end may be larger
>> (e.g. for release_mem_region()).
>
>What about making it %lx-%lx without any numbers?
If you really care about getting the exact number of leading zeroes,
this is portable (assuming 2 hex digits per byte).
printk("Trying to free nonexistent resource <%0*lx-%0*lx>\n",
2*sizeof(start), start, 2*sizeof(end), end);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Wed, 20 Sep 2000 11:42:24 +0200, Helge Hafting <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >> To handle newer controllers which mimic older controllers, the newer >> controllers would be listed in LINK_FIRST. At the moment we do not >> have any plans to allow user ordering of controllers via .config, only >> via editting the Makefile. The plan is to clean up the Makefiles >> first, introducing new facilities comes later (if ever). > >Interesting. Do you mean that you don't want any user reordering via >.config at all, or merely that you yourself have more >important stuff to do. I can code up something myself if I >feel the need. Complete control of order is ideal, it solves >every problem an expert user might have. Ability to >put one particular controller first solves the boot issues >just fine though. Current plans are to replace the current Makefile kludges with clean code that does the same thing, gets it right where current Makefiles are broken, is easier to maintain and (hopefully) is faster. The kbuild mantra is "Correctness, Maintainability, Speed", in that order. Part of the correctness and maintainability problem is the lack of documentation on required link orders in the existing Makefiles. People are scared to change the order of object entries because that defines link order and we do not know if existing orders are required or they are just coincidence. Once the orders are fully defined as LINK_FIRST, LINK_LAST and the rest, then we can think about allowing make xxx_config to change the orders. However that would be after the Makefile rewrite had been accepted. It would probably require the use of CML, I don't think the current make xxx_config language can cope with this sort of input. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2-fs error and geometry walk ... ???
On Mon, 18 Sep 2000, Andries Brouwer wrote: > If this is an unpatched vanilla 2.4.0test8 then I am surprised. > But if it is a patched version I would prefer to blame the patch. Andries, Going back to 2.4.0test5 with my patch it works perfectly. I will move this forward to 2.4.0test8, but all the patch does, is to expand the select method beyond the SELECT_DRIVE(hwif,drive). Since all drives report as an effective master, the select code only raise the device to that level. Thus I tend to focus on filesystems. The fact that partition check points are were it craps out on two different systems. One Cascade Project and the other is the DupliDisk II RaidCase, by sratching the first superblock on every other boot and not in 2.2.X kernels or 2.4.0-test5 currently testing and stepping forward. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Question: Using floating point in the kernel
On Tue, 19 Sep 2000, Richard B. Johnson wrote: > long int radians = (long) (2.0 * 3.141592654 * (float) HZ); Just out of curiosity: what's that cast to float about? Have it spring into the eye of a casual reader? That pi constant already is a double and C implicitly casts to the type with the wider range/higher precision. -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/proc/partitions is wrong
Hello, my /proc/partitions says I have 25 partitions while there are only 21. Fdisk shows the right information, so there's nothing wrong with my disk or so. Kernel version 2.2.17 Harddisk : Maxtor 54098U8 40GB 7200rpm ide /proc/partitions --- major minor #blocks name 3 0 40020624 hda 3 1 24066 hda1 3 23076447 hda2 3 4 1 hda4 3 5 136521 hda5 3 61028128 hda6 3 73076416 hda7 3 81028128 hda8 3 91028128 hda9 3101028128 hda10 311 313236 hda11 312 923706 hda12 3131542208 hda13 3142048256 hda14 3153076416 hda15 3163076416 hda16 3173076416 hda17 3183076416 hda18 3193076416 hda19 3203237066 hda20 3216144831 hda21 322 51200 hda22 323 397880 hda23 324 20480 hda24 3252606887 hda25 fdisk output Disk /dev/hda: 255 heads, 63 sectors, 4982 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /dev/hda1 1 3 24066 83 Linux /dev/hda2 * 4 386 3076447+ a5 BSD/386 /dev/hda4 387 4982 36917370f Win95 Ext'd (LBA) /dev/hda5 387 403136521 82 Linux swap /dev/hda6 404 531 1028128+ 83 Linux /dev/hda7 532 914 3076416 83 Linux /dev/hda8 915 1042 1028128+ 83 Linux /dev/hda9 1043 1170 1028128+ 83 Linux /dev/hda10 1171 1298 1028128+ 83 Linux /dev/hda11 1299 1337313236 83 Linux /dev/hda12 1338 1452923706 83 Linux /dev/hda13 1453 1644 1542208+ 83 Linux /dev/hda14 1645 1899 2048256 83 Linux /dev/hda15 1900 2282 3076416 83 Linux /dev/hda16 2283 2665 3076416 83 Linux /dev/hda17 2666 3048 3076416 83 Linux /dev/hda18 3049 3431 3076416 83 Linux /dev/hda19 3432 3814 3076416 83 Linux /dev/hda20 3815 4217 3237066 83 Linux /dev/hda21 4218 4982 6144831 83 Linux Marko No. 5 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Function calls not permitted in kernel code
Hi, couldn't find an answer to this in any FAQ: Can anyone point me to a clear summary of what can and what can't be called by kernel code. That is, can a kernel module open and read files or sockets, call libc functions, start processes? If, as I suspect, none of these are possible, are the options to: (1) Get a user process to do the work, communicating with the kernel via /proc or some other way. (2) Doing things really low-level through kernel calls (such as injecting skbs into TCP/IP code). Thanks -- Mark PS: Are there any plans to go beyond store and forward for IP forwarding to implement Tx as soon as the IP header is Rx-ed and checked, while the packet data is still being Rx-ed? How useful would this be for Internet latency on unsaturated links? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.4: Fix Cardbus
Jeff Garzik wrote: > Ok, it's time to get test9 running on my laptop, so I played the "what > code didn't get cut-n-pasted" game. > > With the attached tested patch against 2.4.0-test9-pre4, CardBus is > working again for me. This patch makes the logic match that of the old > code. Well. Still doesn't work for me. So I tested 2.2.17 and pcmcia-cs 3.1.20. # lsmod Module Size Used by tulip_cb 32092 0 (unused) cb_enabler 2504 1 [tulip_cb] ds 6440 2 [cb_enabler] i82365 22420 2 pcmcia_core50912 0 [cb_enabler ds i82365] [These are the correct modules, right? Loaded by hand, as 'make install' in pcmcia-cs appears to be a little confused by the latest kernel module reorg.] # dmesg [snip] Linux PCMCIA Card Services 3.1.20 kernel build: 2.2.17 #1 Wed Sep 20 09:32:23 CEST 2000 options: [pci] [cardbus] [apm] [pnp] PCI routing table version 1.0 at 0xfbda0 00:03.0 -> irq 11 00:03.1 -> irq 11 PnP: PNP BIOS installation structure at 0xc00fe2d0 PnP: PNP BIOS version 1.0, entry at f:e2f4, dseg at 40 Intel PCIC probe: TI 1225 rev 01 PCI-to-CardBus at slot 00:03, mem 0x6800 host opts [0]: [ring] [serial pci & irq] [pci irq 11] [lat 32/32] [bus 32/34] host opts [1]: [ring] [serial pci & irq] [pci irq 11] [lat 32/32] [bus 35/37] ISA irqs (scanned) = 3,7,9,10 PCI status changes cs: cb_alloc(bus 35): vendor 0x115d, device 0x0003 [/etc/init.d/pcmcia start] cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: clean. cs: IO port probe 0x0a00-0x0aff: clean. ROM image dump: cs: no valid ROM images found! Same problem, or different problem? This time, the card is not even detected... Dag B - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/partitions is wrong
On Wed, Sep 20, 2000 at 12:11:33PM +0200, Marko van Dooren wrote: > Hello, my /proc/partitions says I have 25 partitions while there are > only 21. Fdisk shows the right information, so there's nothing wrong > with my disk or so. ... > /dev/hda2 * 4 386 3076447+ a5 BSD/386 You have enabled BSD partitions (CONFIG_BSD_DISKLABEL) so Linux shows those too. > > Marko No. 5 > -- marko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI scanning changes break RAID autorun
[Matthew Kirkwood] > +ifeq ($(CONFIG_BLK_DEV_MD),y) > +SUB_DIRS += md > +MOD_SUB_DIRS += md > +else > + ifeq ($(CONFIG_BLK_DEV_MD),m) > + MOD_SUB_DIRS += md >endif > endif > Drop the 'else' bit; CONFIG_BLK_DEV_MD cannot be 'm'. > +obj-n:= > +obj- := These two variables are unused, don't bother initializing them. We only care about obj-y and obj-m. Rest looks OK (eyeballed, not tested). Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Given an image, how can show its config?
[<[EMAIL PROTECTED]>] > >I would like to upgrade my kernel which is bundled with Red Hat. [kaos] > Ask redhat for the .config, this is not a problem for the > linux-kernel list. Also you might make sure you have any relevant RH patches installed. Not being a RH user, I don't know which ones those would be. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Function calls not permitted in kernel code
On Wed, 20 Sep 2000, Mark James wrote: > That is, can a kernel module open and read files or sockets, > call libc functions, start processes? kernel code is, as userspace one, just a code to be executed by the CPU, I suspect you knew that already ;) Therefore, it can do absolutely anything the human tells it to. Even calling "libc functions" as long as you implement the desired libc functionality in the kernel yourself - most of what is needed is there already, e.g. sprintf() etc. Having said that, doing things like opening files and sockets is usually frowned upon and rightly so, except in special cases like khttpd and such. > (1) Get a user process to do the work, communicating > with the kernel via /proc or some other way. some other way may be by means of system calls. System calls are the most natural (by definition) way of communicating between userspace and kernel. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Function calls not permitted in kernel code
[Mark James] > That is, can a kernel module open and read files or sockets, call > libc functions, start processes? * Read files/sockets: you need a process context. That means if you are running in an interrupt you are SOL and if you are in an existing process context, the context owner might get upset with you for playing with its fd table without its knowledge. So the only safe way is to spawn a kernel thread; see below. * libc: absolutely not. The kernel has its own set of provided functions, some of which look suspiciously like libc functions, but your selection is very limited. Look in your lib/ directory to see what is available. * start processes: yes, if you must. Grep for the kernel_thread() function. Watch for the pitfalls (study existing usage). If you want to run a userspace program, see kernel/kmod.c for an example. > are the options to: > > (1) Get a user process to do the work, communicating > with the kernel via /proc or some other way. > > (2) Doing things really low-level through kernel calls > (such as injecting skbs into TCP/IP code). (1), in general. /proc files are a popular kludge, and /dev files with custom ioctl() calls are almost as popular. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Given an image, how can show its config?
Grab the kernel source rpm and install it. Once install you can find various configs in /usr/src/linux/configs/. I'm not sure if they include this will all sources. The last one I checked was 2.2.14 before modifying to my liking. [EMAIL PROTECTED] wrote: > > Dear all, > > I would like to upgrade my kernel which is bundled with Red Hat. However, > I don't want to lose modules/functions it has complied. How can I do > it? Is there any command to check the current config and how can I check > the modules it has as well? > > Many thanks!!! > > Best regards, > Boris > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.4: Fix Cardbus
On Wed, 20 Sep 2000, Jeff Garzik wrote: > Ok, it's time to get test9 running on my laptop, so I played the "what > code didn't get cut-n-pasted" game. > > With the attached tested patch against 2.4.0-test9-pre4, CardBus is > working again for me. This patch makes the logic match that of the old > code. Good stuff - it fixes the problem for me. I still don't understand the fix but that doesn't matter :) your fix looks much nicer than my blind guess! Thanks, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __ucmpdi2
[Cahalan] > Well, what do you care about most? The problem can be solved in > other, more disturbing ways. :-) For example, gcc's computed goto. [code snipped] You are sick. (: Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
Keith Owens wrote:
>
> Just because the traces end up in stext_lock does not mean that they
> are the same bug. Locks are optimized for pipeline performance, the
> code for "got the lock" is in the main text section, the code for
> "cannot get lock, need to wait" is moved to a separate text section.
> That way only the failure case gets pipeline stalls.
>
> The downside of this optimization is that all code that is waiting for
> a lock appears to be in the out of line section and the only label in
> that section is right at the start. So all lock code appears to be in
> stext_lock. What really matters is where the stext_lock code jumps
> back to, that tells you which code is waiting for the lock. In this
> case you have jumps back to blk_get_queue+9/60 so it is waiting on
> io_request_lock. Now all you have to do is work out who is holding
> onto io_request_lock.
What do you think of this addition to the x86 debug code, Keith:
If you get an NMI oops it says:
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:1
EIP:0010:[]
EFLAGS: 0086
Waiting on spinlock! Spinner's EIP is []
...
And if you get a spindeadlock with interrupts enabled
and hit ALT-SYSRQ-P it says:
CPU:1 << This is new, as well.
EIP: 0010:[] EFLAGS: 0286
Waiting on spinlock! Spinner's EIP is []
EAX: 000f EBX: cded5fbc ECX: 0002 EDX: 08fc
ESI: EDI: EBP: b5e4 DS: 0018 ES: 0018
CR0: 8005003b CR2: 4000a820 CR3: 0e0fc000 CR4: 0090
Doing this for rwlocks is, umm, trickier.
Will ksymoops automatically parse the EIP?
--- linux-2.4.0-test9-pre4/arch/i386/vmlinux.ldsTue Jul 11 22:21:12 2000
+++ linux-akpm/arch/i386/vmlinux.ldsWed Sep 20 20:58:25 2000
@@ -13,7 +13,9 @@
*(.fixup)
*(.gnu.warning)
} = 0x9090
+ __start___text_lock = .;
.text.lock : { *(.text.lock) } /* out-of-line lock text */
+ __stop___text_lock = .;
.rodata : { *(.rodata) }
.kstrtab : { *(.kstrtab) }
--- linux-2.4.0-test9-pre4/arch/i386/kernel/traps.c Tue Sep 19 19:42:08 2000
+++ linux-akpm/arch/i386/kernel/traps.c Wed Sep 20 23:49:22 2000
@@ -152,6 +152,40 @@
}
}
+#ifdef CONFIG_SMP
+void show_spinlock_owner(struct pt_regs *regs)
+{
+ extern int __start___text_lock, __stop___text_lock;
+ u8 *start_lock = (u8 *)&__start___text_lock;
+ u8 *stop_lock = (u8 *)&__stop___text_lock;
+ u8 *eip = (u8 *)regs->eip;
+ u8 *last_eip = eip + 16;/* size of spin_lock_string */
+
+ if (last_eip > stop_lock)
+ last_eip = stop_lock;
+
+ last_eip -= 5; /* size of `jmp xxx' */
+
+ /*
+* Search for the start of the jmp back. There may be
+* more than one 0xe9 opcode in there, but we only dump
+* the first one (which may be wrong).
+*/
+ while (eip >= start_lock && eip < last_eip) {
+ if (*eip == 0xe9) { /* relative jmp */
+ u8 *back = *(u8 **)(eip + 1);
+ back += (u32)(eip + 5);
+ printk("Waiting on spinlock! Spinner's EIP is [<%p>]\n", back);
+ break;
+ }
+ eip++;
+ }
+}
+#else
+void show_spinlock_owner(struct pt_regs *regs)
+{}
+#endif
+
static void show_registers(struct pt_regs *regs)
{
int i;
@@ -168,6 +202,7 @@
}
printk("CPU:%d\nEIP:%04x:[<%08lx>]\nEFLAGS: %08lx\n",
smp_processor_id(), 0x & regs->xcs, regs->eip, regs->eflags);
+ show_spinlock_owner(regs);
printk("eax: %08lx ebx: %08lx ecx: %08lx edx: %08lx\n",
regs->eax, regs->ebx, regs->ecx, regs->edx);
printk("esi: %08lx edi: %08lx ebp: %08lx esp: %08lx\n",
@@ -396,7 +431,7 @@
__setup("nmi_watchdog=", setup_nmi_watchdog);
-extern spinlock_t console_lock;
+extern spinlock_t console_lock, timerlist_lock;
static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
inline void nmi_watchdog_tick(struct pt_regs * regs)
@@ -411,7 +446,8 @@
*
* since NMIs dont listen to _any_ locks, we have to be extremely
* careful not to rely on unsafe variables. The printk might lock
-* up though, so we have to break up console_lock first ...
+* up though, so we have to break up console_lock and timerlist_lock
+* first ...
* [when there will be more tty-related locks, break them up
* here too!]
*/
@@ -441,6 +477,8 @@
*/
spin_trylock(&console_lock);
spin_unlock(&console_lock);
+ spin_trylock(&timerlist_lock);
+ spin_unlock(&timerlist_lock);
printk("NMI Watchdog detected LOCKUP on CPU%d, registers:\n",
cpu)
Re: null TTY in tty_fasync?
Marco d'Itri wrote: > > At the end of a UUCP poll this message was logged: > > Sep 19 23:42:47 wonderland kernel: Warning: null TTY for (04:40) in tty_fasync > > What does it mean? > Very hard to say. Ted, Google says this has only been reported three or four times. Could we please have a BUG() in that code path? It's probably unrelated to Harley's crash (http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.1/0049.html), but then, I have no explanation for Harley's crash. Having stared sleepily at the code for several evenings I see no way in which serial_driver.refcount can be non-zero while serial.o's module refcount is zero. But it happened. We can rule out the schedule() in release_dev(), which is definitely an rmmod window bug, because Harley has confirmed that the "release_dev: %s: read/write wait queue active!" message did not come out (he still has the logs). It's something else. It would be a shame to put the `struct module *owner' stuff into the tty layer prior to having an explanation for all of this, even though it's on the todo list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
On Thu, 21 Sep 2000 00:05:03 +1100, Andrew Morton <[EMAIL PROTECTED]> wrote: >> The downside of this optimization is that all code that is waiting for >> a lock appears to be in the out of line section and the only label in >> that section is right at the start. So all lock code appears to be in >> stext_lock. What really matters is where the stext_lock code jumps >> back to, that tells you which code is waiting for the lock. In this >> case you have jumps back to blk_get_queue+9/60 so it is waiting on >> io_request_lock. Now all you have to do is work out who is holding >> onto io_request_lock. > >What do you think of this addition to the x86 debug code, Keith: > >If you get an NMI oops it says: > > NMI Watchdog detected LOCKUP on CPU1, registers: > CPU:1 > EIP:0010:[] > EFLAGS: 0086 > Waiting on spinlock! Spinner's EIP is [] > ... Is the extra code worth it? The ix86 oops dump runs the stack printing anything that looks like a kernel address. This means that we "always" get the function that wants the lock, we just do not get the precise address of the call to spinlock(). All right, we do not always get the current function, sometimes we only get the function that called the function that call spinlock(). But even that seems to be enough for oops. kdb has to go to all the bother of decoding the .text.lock sections to get an accurate backtrace. Oops decoding has never pretended to be accurate, it gets lots of false positives. BTW, you made the same mistake I did with .text_lock. The kernel is not the only place where section .text.lock exists, each module has its own .text.lock section. That is one of the reasons that the kdb symbol table processing needs so much data, to extract sections from modules and find symbols for return addresses from all the strange out of line code - man kallsyms for the gory details. >Waiting on spinlock! Spinner's EIP is [] >Will ksymoops automatically parse the EIP? Not as it stands, but yet another regular expression is no big deal. IMHO the existing oops gives enough data, given the known restrictions of stack backtraces without full unwind support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __ucmpdi2
[Jeremy Higdon] > Is there a little FAQ of C constructions you should not use if you > are writing kernel code? It took a little doing to figure out that > it was the switch that was causing trouble and not the shifts and > arithmetic operations, and I'd like to avoid that in the future :-). Here are some of the big ones: * 64-bit division. Most such is by powers of two so you can use shifts instead. Probably the compiler should optimize this case automatically, but gcc doesn't, currently. * floating point. Use fixed point integers. Floating point registers (at least on i386) are not saved/restored in the right places (because doing so is very expensive on some CPUs), so you'll clobber someone else's context. * MMX. See floating point. * excess stack usage. The kernel stack is very very small, so don't waste it. Large automatic arrays are BAD. Use globals or dynamic allocation. * C++ exceptions, run-time types (RTTI) and other features-of-the-month. Stick to C and you'll be OK. * global variables initialized to 0. Not necessary, as uninitialized globals are zeroed automatically, and that way they don't take up space in the on-disk image. This is a concern for embedded systems. Also make sure to read Documentation/CodingStyle for, well, coding style. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
Keith Owens wrote: > > ... > > Waiting on spinlock! Spinner's EIP is [] > > ... > > Is the extra code worth it? The ix86 oops dump runs the stack printing > anything that looks like a kernel address. Fair enough. What about the ALT-SYSRQ-P thing? I guess that wouldn't be necessary if handle_sysrq() did a show_stack(0), which it doesn't, and probably should. hmmm.. The best solution would appear to be to crunch show_regs() and show_registers() together. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
NAT dropping packets
Hi, I've just spotted a small problem with 2.4.0-test8 running netfilter: NAT: 3 dropping untracked packet c065d3a0 1 192.168.0.1 -> 192.168.0.9 This seems to be caused when you have connection tracking enabled, and you ping the local network broadcast address. The filter rules specific to the ethernet interface where this packet originated from and the above response was dropped has the filter rules setup thus: iptables -A INPUT -i eth0 -j ACCEPT iptables -A OUTPUT -o eth0 -j ACCEPT There isn't any NAT in operation on eth0 (but there is NAT for packets going via other interfaces). If you require more information on the setup, let me know, and I'll provide it in private mail. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Questions on RAID1 on IDE hard disks
[Terence Ang] > Could anyone kindly tell me how to setup software RAID1 on IDE drives > under RedHat 6.2? > I have got one extra PCI IDE card with 2 hard disks (not mentioning > the existing Linux OS hard disk) > It seemed that the card could not be detected under Linux. It looks like you will need: * kernel source http://www.??.kernel.org/pub/linux/kernel/v2.2/... * Andre's IDE patch http://www.??.kernel.org/pub/linux/kernel/people/hedrick/... * Ingo's RAID patch http://people.redhat.com/mingo/raid-patches/... * raidtools version 0.90 or above http://http.??.debian.org/debian/dists/unstable/main/source/admin/raidtools2_0.90.990824.orig.tar.gz [In the above ?? stands for a country code near you] Apply the patches, read the raidtools docs, and go from there. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.4: Fix Cardbus
Dag Bakke wrote: > > Jeff Garzik wrote: > > > Ok, it's time to get test9 running on my laptop, so I played the "what > > code didn't get cut-n-pasted" game. > > > > With the attached tested patch against 2.4.0-test9-pre4, CardBus is > > working again for me. This patch makes the logic match that of the old > > code. > > Well. > Still doesn't work for me. So I tested 2.2.17 and pcmcia-cs 3.1.20. > > # lsmod > Module Size Used by > tulip_cb 32092 0 (unused) > cb_enabler 2504 1 [tulip_cb] [...] > cs: cb_alloc(bus 35): vendor 0x115d, device 0x0003 > > [/etc/init.d/pcmcia start] > cs: IO port probe 0x0c00-0x0cff: clean. > cs: IO port probe 0x0800-0x08ff: clean. > cs: IO port probe 0x0100-0x04ff: clean. > cs: IO port probe 0x0a00-0x0aff: clean. > ROM image dump: > cs: no valid ROM images found! > > Same problem, or different problem? This time, the card is not even > detected... Look around for patches from Keith Owens relating to this, and the xircom_tulip_cb driver. It needs a ROM image mapping into the address space, which is normally not done without the special "pci=rom" setting on the kernel command line. Keith's patch, IIRC, temporary does a mapping in order to get the necessary information from the ROM image. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: null TTY in tty_fasync?
Andrew Morton wrote: > Having stared sleepily at the code for several evenings I see no way in > which serial_driver.refcount can be non-zero while serial.o's module > refcount is zero. But it happened. Is it possible to replace serial_driver.refcount with calls to GET_USE_COUNT()? No need to have two refcounts for the same thing, usually... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: cPCI development
Am I right in assumming that 2.2.14 (as from RH6.2) supports cPCI? Or do I need to start developing on 2.4? I really do need to do some research into this, if I knew where to start. I need some docs! (either paper, URL, or the straight-jacket kind) Justin. > -Original Message- > From: Russell King [SMTP:[EMAIL PROTECTED]] > > [EMAIL PROTECTED] writes: > > I'm about to embark on some compact-PCI driver development for Linux and > I > > was wondering where I can find some info. Is there any difference > between > > PCI and cPCI development on Linux? > > > > URLs would be great! Or, if this is the wrong list for driver > development > > issues, a pointer to the correct mailing list would be lovely. > > I believe that cPCI is the same as normal PCI from the software point of > view. > However, cPCI has different connectors. > > I'm currently working on an ARM development board which can be used either > as a ATX motherboard with PCI slots, or plugged into a cPCI backplane, and > the only thing between the two is a standard DEC PCI to PCI bridge. > > Disclaimer: I haven't done any in-depth investigations yet, so I could be > talking complete and utter nonsense here. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
missing symbols with depmod - how to solve this?
Hi all, I have recently been plagued with the problem of depmod complaining of missing symbols after a kernel compile - and I am completely stumped as to what is causing this. - I confirm that no pre-existing /usr/src/linux or /lib/modules/2.2.17 directories exist. - I download and unpack a virgin v2.2.17 kernel into an empty /usr/src/linux directory. - I compile the kernel with the following commands: make menuconfig ; make dep ; make clean ; make bzImage ; make modules ; make modules_install - The compile ends successfully without any errors. - I copy the resulting bzImage and System.map files to the /boot directory, renaming them System.map-2.2.17 and vmlinubz-2.2.17 respectively. - I run depmod -m /boot/System.map-2.2.17 -a 2.2.17 And I get this: [root@jolanda /root]# depmod -m /boot/System.map-2.2.17 -a 2.2.17 /lib/modules/2.2.17/fs/nls_koi8-r.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-15.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-14.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-9.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-8.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-7.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-6.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-5.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-4.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-3.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-2.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_iso8859-1.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_cp950.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_cp949.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_cp936.o: unresolved symbol(s) /lib/modules/2.2.17/fs/nls_cp932.o: unresolved symbol(s) [hundreds of lines snipped] If I ignore the above, configure LILO with the new kernel and reboot, the same problem happens when depmod -a runs during startup. The system is a Redhat Linux v6.1 system. Has anyone any idea what on earth is causing this? I have been trawling the internet for a solution to this problem, but in all the documentation depmod is supposed to "just work" and in my case it "just doesn't". Anyone encountered this before? Regards, Graham -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Oops] Unable to handle kernel NULL pointer dereference
Hi, I ran into some trouble while compiling the pspell library that the new version of Balsa requires - okay, so perhaps I was asking for it :-) I ran the configure script fine, but a kernel oops occurred a few lines into the "make" process. I gather that it might be something to do with dodgy source code, but surely just compiling source code should not produce an oops (there were no compiler warnings until after the oops)? The oops is not fatal; I was able to download, compile and install the ksysmoops program to get the decoded oops message without having to reboot. I rebooted the system and tried compiling from clean sources again and got the same oops, so it seems to be repeatable on my system. If this is the wrong forum for such a message, please let me know! My system is RH6.2, with various updates probably best described by the output of the ver_linux script: Linux 2.4.0-test9 #1 Sat Sep 16 17:11:06 BST 2000 i586 unknown Kernel modules 2.3.14 Gnu C egcs-2.91.66 Binutils 2.9.5.0.22 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.7 Mount 2.10o Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded emu10k1 soundcore kernel version 2.4.0-test9p1 with Rick van Riel's VM patch System: P133 w/ 32Mb ram. More details available on request. The decoded Oops message is below. Unable to handle kernel NULL pointer dereference at virtual address 0034 c01527b9 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: ebx: ecx: 0001 edx: c1afc000 esi: edi: 0004 ebp: esp: c14d7ee0 ds: 0018 es: 0018 ss: 0018 Process ar (pid: 13549, stackpage=c14d7000) Stack: c14d7f24 c015357b 0001 c14d7f54 01f6 c0a51440 b960 c0706019 c109aa50 c14d7f2c c14d7f24 0013 c01363d8 0001 ff86 c000d220 c012c1e7 c0a51440 c14d7f54 Call Trace: [] [] [] [] [] [] [] Code: f6 43 34 40 74 07 31 c0 e9 f9 00 00 00 8b 53 48 85 d2 74 43 >>EIP; c01527b9<= Trace; c015357b Trace; c01363d8 Trace; c012c1e7 Trace; c01371a9 <__user_walk+4d/58> Trace; c012c23b Trace; c011d630 Trace; c0108d83 Code; c01527b9 <_EIP>: Code; c01527b9<= 0: f6 43 34 40 testb $0x40,0x34(%ebx) <= Code; c01527bd 4: 74 07 je d <_EIP+0xd> c01527c6 Code; c01527bf 6: 31 c0 xor%eax,%eax Code; c01527c1 8: e9 f9 00 00 00jmp106 <_EIP+0x106> c01528bf Code; c01527c6 d: 8b 53 48 mov0x48(%ebx),%edx Code; c01527c9 10: 85 d2 test %edx,%edx Code; c01527cb 12: 74 43 je 57 <_EIP+0x57> c0152810 John [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2)
On Thu, Sep 21, 2000 at 12:42:25AM +1100, Andrew Morton wrote: > What about the ALT-SYSRQ-P thing? I guess that wouldn't be necessary if > handle_sysrq() did a show_stack(0), which it doesn't, and probably > should. Yes, SYSRQ+P should definetly show the stack trace. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel oops & panic in ISDN
I've got a Redhat 6.2 box here with a HiSax PCI ISDN card
(modprobed with parameters: type=36 protocol=2). It's running a custom
compiled 2.2.17 kernel. If I do an "isdnctrl dial ippp0" it dials up and
negotiates the IP address, etc. However, I can't transmit any data across
the syncppp link - whenever I try to ping the remote peer, I get:
isdn_ppp: No compressor set!
ippp: no decompressor defined!
Fairly frequently when I send data across the syncppp link, I get either
an Oops or a panic (see below). From what I can tell from the call trace,
the oops happens in udp_recvmsg and the panic happens in net_bh.
Has anyone got any ideas how I can fix it, or is it a major bug with the
kernel and not going to work any time soon? (If it's a problem with that
particular card, I can go out and buy a new card, so that's not too much
of a problem).
--- OOPS ---
Unable to handle kernel NULL pointer dereference at virtual address 0004
current->tss.cr3 = 00aee000, %cr3 = 00aee000
*pde =
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010046
eax: c38ea720 ebx: c0375184 ecx: 0246 edx:
esi: c0aedeec edi: c0375140 ebp: c0375184 esp: c0aeddf4
ds: 0018 es: 0018 ss: 0018
Process ping (pid: 778, process nr: 41, stackpage=c0aed000)
Stack: c0aedf6c c0aede40 c0375184 c0375140 c0166929 c0375140
c0aede48 c0375140 c0aedf6c c0aedf6c dd43a1d5
c743a1d5 c0aedec8 3aebd833 c743a1d5 c0aede48 c016b0e0 c0375140
Call Trace: [] [] [] [] [] [<
[] [] [] [] []
Code: 89 5a 04 89 13 c7 00 00 00 00 00 c7 40 04 00 00 00 00 c7 40
---
--- PANIC ---
Unable to handle kernel NULL pointer dereference at virtual address 0040
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde =
Oops:
CPU:0
EIP:0010:[]
EFLAGS: 00010217
eax: ebx: c38eaa40 ecx: edx: c38eaa40
esi: c0ada0f4 edi: 0014 ebp: c01ddf40 esp: c01ddf2c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=c01dd000)
Stack: c38eaa40 c01d3274 c38eaa40 0002 0001 c38eaa40 c014bf65 c38eaa40
c3c9038c c01d3274 0001 c01ffce4 0001a82e c01ddf94 0001a82f 0008df94
c01178fd c01dc000 c0110555 0001 c01dc000 0001a82e 0018
Call Trace: [] [] [] [] [] [<
[] [] [] [] []
Code: 8b 40 40 ff d0 83 c4 04 eb 20 89 f6 ff 05 0c 32 1d c0 8b 55
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In swapper task - not syncing
---
--
- Steve Hill
System Administrator Email: [EMAIL PROTECTED]
Navaho Technologies Ltd. Tel: +44-870-7034015
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Scsi scanning fixes
Linus and others, Patch attached that should fix some of the problems with the new scsi scanning: devfs registration should be ok now with both builtin and module. link order changed to reflect hosts.c + minor additions. minor cleanups. First of all, please don't yell too loud about the Makefile changes. I really stink at this, but it seems to work for me. Tested different configs, with different hosts. Layers get linked: core - hosts - upper I'm sure the Makefile stuff can be done a lot better, so someone please do if my attempt is crap. I had to link scsi_syms separately in order not to get unresolved symbols with modules. Also, those of you that have special needs with regards to host order initialization, please let us know. Please specify which driver runs what controller. Thanks -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk diff -ur --exclude-from=/root/torben linux-2.4.0-test9p4/drivers/scsi/Makefile linux/drivers/scsi/Makefile --- linux-2.4.0-test9p4/drivers/scsi/Makefile Wed Sep 20 16:52:35 2000 +++ linux/drivers/scsi/Makefile Wed Sep 20 17:12:36 2000 @@ -4,6 +4,8 @@ # 30 May 2000, Christoph Hellwig <[EMAIL PROTECTED]> # Rewritten to use lists instead of if-statements. # +# 20 Sep 2000, Torben Mathiasen <[EMAIL PROTECTED]> +# Changed link order to reflect new scsi initialization. O_TARGET := scsidrv.o @@ -22,25 +24,14 @@ endif export-objs:= scsi_syms.o -list-multi := scsi_mod.o sr_mod.o initio.o a100u2w.o +list-multi := scsi_mod.o initio.o a100u2w.o CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF CFLAGS_gdth.o= # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ -DGDTH_STATISTICS CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM -obj-$(CONFIG_SCSI) += scsi_mod.o -obj-$(CONFIG_CHR_DEV_ST) += st.o -obj-$(CONFIG_BLK_DEV_SD) += sd_mod.o -obj-$(CONFIG_BLK_DEV_SR) += sr_mod.o -obj-$(CONFIG_CHR_DEV_SG) += sg.o +obj-$(CONFIG_SCSI) += scsi_mod.o scsi_syms.o -obj-$(CONFIG_SCSI_ADVANSYS)+= advansys.o -obj-$(CONFIG_SCSI_PCI2000) += pci2000.o -obj-$(CONFIG_SCSI_PCI2220I)+= pci2220i.o -obj-$(CONFIG_SCSI_PSI240I) += psi240i.o -obj-$(CONFIG_MVME16x_SCSI) += mvme16x.o53c7xx.o -obj-$(CONFIG_BVME6000_SCSI)+= bvme6000.o 53c7xx.o -obj-$(CONFIG_SCSI_SIM710) += sim710.o obj-$(CONFIG_A4000T_SCSI) += amiga7xx.o 53c7xx.o obj-$(CONFIG_A4091_SCSI) += amiga7xx.o 53c7xx.o obj-$(CONFIG_BLZ603EPLUS_SCSI) += amiga7xx.o 53c7xx.o @@ -48,8 +39,6 @@ obj-$(CONFIG_A3000_SCSI) += a3000.o wd33c93.o obj-$(CONFIG_A2091_SCSI) += a2091.o wd33c93.o obj-$(CONFIG_GVP11_SCSI) += gvp11.o wd33c93.o -obj-$(CONFIG_SCSI_SGIWD93) += sgiwd93.owd33c93.o -obj-$(CONFIG_SCSI_MCA_53C9X) += NCR53C9x.o mca_53c9x.o obj-$(CONFIG_CYBERSTORM_SCSI) += NCR53C9x.o cyberstorm.o obj-$(CONFIG_CYBERSTORMII_SCSI)+= NCR53C9x.o cyberstormII.o obj-$(CONFIG_BLZ2060_SCSI) += NCR53C9x.o blz2060.o @@ -58,69 +47,82 @@ obj-$(CONFIG_OKTAGON_SCSI) += NCR53C9x.o oktagon_esp.o oktagon_io.o obj-$(CONFIG_ATARI_SCSI) += atari_scsi.o obj-$(CONFIG_MAC_SCSI) += mac_scsi.o -obj-$(CONFIG_SUN3_SCSI)+= sun3_scsi.o obj-$(CONFIG_SCSI_MAC_ESP) += mac_esp.oNCR53C9x.o -obj-$(CONFIG_SCSI_PPA) += ppa.o -obj-$(CONFIG_SCSI_IMM) += imm.o -obj-$(CONFIG_SCSI_QLOGIC_FAS) += qlogicfas.o -obj-$(CONFIG_SCSI_QLOGIC_ISP) += qlogicisp.o -obj-$(CONFIG_SCSI_QLOGIC_1280) += qla1280.o -obj-$(CONFIG_SCSI_ACARD) += atp870u.o -obj-$(CONFIG_SCSI_INITIO) += initio.o -obj-$(CONFIG_SCSI_INIA100) += a100u2w.o -obj-$(CONFIG_SCSI_QLOGIC_FC) += qlogicfc.o +obj-$(CONFIG_SUN3_SCSI)+= sun3_scsi.o +obj-$(CONFIG_MVME16x_SCSI) += mvme16x.o53c7xx.o +obj-$(CONFIG_BVME6000_SCSI)+= bvme6000.o 53c7xx.o +obj-$(CONFIG_SCSI_SIM710) += sim710.o +obj-$(CONFIG_SCSI_ADVANSYS)+= advansys.o +obj-$(CONFIG_SCSI_PCI2000) += pci2000.o +obj-$(CONFIG_SCSI_PCI2220I)+= pci2220i.o +obj-$(CONFIG_SCSI_PSI240I) += psi240i.o +obj-$(CONFIG_SCSI_BUSLOGIC)+= BusLogic.o +obj-$(CONFIG_SCSI_U14_34F) += u14-34f.o +obj-$(CONFIG_SCSI_ULTRASTOR) += ultrastor.o obj-$(CONFIG_SCSI_AHA152X) += aha152x.o obj-$(CONFIG_SCSI_AHA1542) += aha1542.o obj-$(CONFIG_SCSI_AHA1740) += aha1740.o obj-$(CONFIG_SCSI_AIC7XXX) += aic7xxx.o obj-$(CONFIG_SCSI_IPS) += ips.o -obj-$(CONFIG_SCSI_DC390T) += tmscsim.o -obj-$(CONFIG_SCSI_AM53C974)+= AM53C974.o -obj-$(CONFIG_SCSI_BUSLOGIC)+= BusLogic.o -obj-$(CONFIG_SCSI_EATA_DMA)+= eata_dma.o -obj-$(CONFIG_SCSI_EATA_PIO)+= eata_pio.o -obj-$(CONFIG_SCSI_U14_34F) += u14-34f.o -obj-$(CONFIG_SCSI_SUNESP) += esp.o -obj-$(CONFIG_SCSI_QLOGICPTI) += qlogicpti.o -obj-$(CONFIG_SCSI_MESH)+= mesh.o -obj-$(CONFIG_SCSI_MAC53C94)+= mac53c94.o -obj-$(
linux-kernel-digest ?
Hi, I am just wondering if linux-kernel-digest is going to come back. Greetings Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Given an image, how can show its config?
** Reply to message from [EMAIL PROTECTED] on Wed, 20 Sep 2000 17:09:27 +0800 (CST) > I would like to upgrade my kernel which is bundled with Red Hat. However, > I don't want to lose modules/functions it has complied. How can I do > it? Is there any command to check the current config and how can I check > the modules it has as well? "make oldconfig" gets you 99% there. For some reason, it got the network adapter wrong, but otherwise it appeared to be correct. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Question about signals
I am working to get Diald up and running and with both 2.2.16 and the 2.4.0 series kernels I have been getting SIOCSIFMETRIC Operation not supported. I've looked through the kernel docs and include files but couldn't find a reference to that operation. Is there another name for that operation or does someone have the fix for Diald-0.99.4? Thanks Adam _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
l-k archive at tux.org vanishes?
http://boudicca.tux.org/hypermail/linux-kernel/ is gone. I was linking to individual posts there in my pages about kernel enhancements. What happened? Must I now laboriously link to some other archive? :-( And what linux-kernel archive is likely to be around long enough to be worth linking to? Guess I should learn: if you want to link to an article and have it stick, better make a copy yourself. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Very aggressive swapping after 2 hours rest
On Tue, 19 Sep 2000, Andrea Arcangeli wrote: > On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote: > > what I wanted to do in the new VM, except that I didn't > > see why we would want to restrict it to swap pages only? > > You _must_ do that _only_ for the swap_cache, that's a specific > issue of the swap_cache during swapout (notenote: not during > swapin!). Which part of "why" did you not understand? I see no reason why we should not do the same trick for mmap()ed pages and maybe other memory too... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops: Unable to handle kernel null pointer
Hi! When I boot by server (Siemens Primergy 500 / 4xPPro 200 / aic7xxx / Mylex DAC 960PD(not used) / 256MB RAM) using the kernel (2.4.0-test8 or 2.3.9) from sda1, it boots up correctly, telling me that runlevel 2 has been reached and starts reporting: Unable to handle kernel NULL pointer dereference at virtual address 0034 printing eip: c01542ab *pde = Oops: CPU: 1 EIP: 010:[] EFLAGS: 00010202 eax: ebx: ecx: cf4ef0c0 edx: cf4ef0c0 esi: 2180 edi: 0001 ebp: cfec7f04 esp: cfec7ec0 ds: 0018 es: 0018 ss: 0018 Process mingetty (pid: 99, stackpage=cfec7000) Stack: 2180 c01550fa 0001 cfec7f34 2180 cf5633a0 bdfc cfec7f0c 0001 c144fd60 cfexx005 ff86 fd20 cf4ef0c0 c012c3a2 cf5633a0 cfec7f34 Call Trace: [] [] [] [] [] [] [] Code: f6 43 34 40 74 07 31 c0 e9 fa 00 00 00 8b 53 48 85 d2 74 45 CPU: [0..3] (errors are split over all CPUs) pid: # (changing from pid to pid) /sbin/mingetty is the same size as on my working box (also Kernel 2.3.9) also I didn't touch it till the installation. Even after copying the working mingetty to the not-working box doesn't help. I really dont't know what to do now and I really need the box up and running. Thanks for any help, Sebastian PS: If I boot using the (SuSE) installation disk (loading the modules manually, letting him use /dev/sda1 as root device, everything works okay. -- m.o.p.Sys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9931-11 e-Mail: [EMAIL PROTECTED] Telefax: 05139/9931-31 Internet bundesweit zum Ortstarif! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Tue, 19 Sep 2000, Andrea Arcangeli wrote: > On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote: > > One of the issues which seems to be affecting performance > > is the elevator starvation bug, though, so I'm not sure how > > You are contraddicting yourself. If you decrease the latency (so > if you fix the starvation) the global disk throughput can only > decrease. Umm, where did I define "performance" as being the same as "global disk throughput" ?? You're imagining things again, and blaming me for it ;) > > Once the elevator problem has been solved, we should be able > > I'm tired of you screwing up the VM and then complaining the > elevator. At least try to vary and choose something else to > complain. There was a known starvation issue in the elevator, at least up to 2.4.0-test9-pre2. Until that problem is resolved, that is the logical thing to "blame" for the phenomenon that one process stalls while some others are still running at full speed. Besides, if it was a VM issue, all allocators would stall. That did not happen, so VM wasn't the subsystem to blame in this case. That said, there may be some interactivity issues with the VM, but with the elevator bug present, there is not much possibility to test for those. About screwing up the VM subsystem, why didn't you help with the details? (remember that you agreed about the design in Ottawa) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Tue, 19 Sep 2000, Andrea Arcangeli wrote: > I'm tired of you screwing up the VM and then complaining the elevator. At least > try to vary and choose something else to complain. At test1 time you may been > right, but now we're so permissive in the default settings exactly to be sure > the elevator isn't hurting performance. Hmm...Do I sense a little hostility here? Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Very aggressive swapping after 2 hours rest
On Wed, Sep 20, 2000 at 12:53:18PM -0300, Rik van Riel wrote: > On Tue, 19 Sep 2000, Andrea Arcangeli wrote: > > On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote: > > > what I wanted to do in the new VM, except that I didn't > > > see why we would want to restrict it to swap pages only? > > > > You _must_ do that _only_ for the swap_cache, that's a specific > > issue of the swap_cache during swapout (notenote: not during > > swapin!). > > Which part of "why" did you not understand? > > I see no reason why we should not do the same trick for > mmap()ed pages and maybe other memory too... It's quite obvious we not talking about the same thing (and it's also quite obvious the problem isn't addressed in test9), I'll restart from scratch trying to be more clear. There are two cases: 1) pageins 2) pageouts When we get a major page fault (pagein/swapin) and we create a swap cache page or a page-cache page, we must consider it a _more_ important page to keep in the working set. So it's fine to put it at the head->next of the LRU and to age it properly. So far so good. Now there's a very special (subtle) case that I addressed in classzone and that is only related to the swapout of a swap cache (well, strictly speaking the pageout of shared pages could take advantage of it as well but I didn't wrote a mechamism generic enough to do that for MAP_SHARED as well yet and that's much less important because the dirty page cache is just in the LRU and it have less chances to be in the lru_cache->next position). When we choose to swapout a page that's the less interesting page we have in the VM. If that wouldn't be true then our selection algorithm that chooses which page to swapout would be flawed. Ok, so now we have a page that we want to throw away by swapping it out. What we do now? We put it in the lru_cache->next position and we write it to disk. Then we left it in the lru_cache waiting shrink_mmap to free it. What happens now? Before shrink_mmap will have a chance to free this page, shrink_mmap will have to first throw away all the working set that we have in cache from lru_cache->next->next to lru_cache->prev. This is an obvious design bug that we have since 2.2.x and that degenerated with the proper LRU in 2.4.x. The bug is that to free 1 page with the swapout mechanism we first have to throw away all the working set in cache. In classzone I have a proper lru_swap_cache where those swapped out pages are put, and I always free those pages immediatly as soon as they're unlocked. This avoids to throw away the working set for each single swapout. One thing I will do to decrease the CPU usage in classzone is to make this lru_swap_cache LRU a IRQ spinlock LRU, so that I can move the pages into this lru_swap_cache only once the I/O is completed. As said this is a further optimization not strictly necessary to save the working set of the kernel. Aggressive aging can alleviate the problem indeed. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Question about signals
On Wed, 20 Sep 2000, Adam Watson wrote: > I am working to get Diald up and running and with both 2.2.16 and the 2.4.0 > series kernels I have been getting SIOCSIFMETRIC Operation not supported. > I've looked through the kernel docs and include files but couldn't find a > reference to that operation. > > Is there another name for that operation or does someone have the fix for > Diald-0.99.4? Sorry, no fix, but a question. Are you using diald to dial a PPP connection? If so, pppd has supported demand dialing for a while now. I found it much easier to set up. -Chris -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Question: Using floating point in the kernel
** Reply to message from "Lyle Coder" <[EMAIL PROTECTED]> on Wed, 20 Sep 2000 01:50:05 GMT > You cannot use MMX registers in the kernel either, since the kernel doesen't > save and restore FX state (fxsave, fxrstor) either (just like > (fsave/frstor). But what about these source files: include/asm-i386/mmx.h (which several other header files, like asm-i386/page.h, include) arch/i386/lib/mmx.c arch/i386/lib/usercopy.c It appears that MMX is being used in the kernel already. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cPCI development
Ondrej Feela Filip wrote: > On Wed, 20 Sep 2000 [EMAIL PROTECTED] wrote: > > > Am I right in assumming that 2.2.14 (as from RH6.2) supports cPCI? Or do I > > need to start developing on 2.4? > > ? I believe, that PCI and cPCI are from SW view identical. I run linux > (2.2.13+) on many cPCI systems and it works cool. :-) cPCI also has more cool features like hot-swap, high availability etc. Mostly not supported in the kernel yet. I'm into hot-swap, for example. :) Vitaly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Question: Using floating point in the kernel
Timur Tabi wrote: > > ** Reply to message from "Lyle Coder" <[EMAIL PROTECTED]> on Wed, 20 Sep 2000 > 01:50:05 GMT > > > You cannot use MMX registers in the kernel either, since the kernel doesen't > > save and restore FX state (fxsave, fxrstor) either (just like > > (fsave/frstor). > > But what about these source files: > > include/asm-i386/mmx.h (which several other header files, like asm-i386/page.h, > include) > arch/i386/lib/mmx.c > arch/i386/lib/usercopy.c > > It appears that MMX is being used in the kernel already. Only under carefully controlled conditions. The MMX copy routines are only used when the overhead of saving the user floating point register state can be marginalized by the size of the copy. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: PERCRAID 3 drivers?
Thanks to everyone who responded. The aacard driver patches that were in the Redhat pinstripe kernel SRPM work fine with 2.2.17. The machine seems pretty stable and speed is about the same as with the binary driver. Thanks again... -- Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[IDE]2.4.0test9-pre1, CD drive on hpt366 not detected correctly and locking up when activated
The subject says everything, while detecting the drive
i got the following strange thing:
[from dmesg]
>PIIX4: chipset revision 1
>PIIX4: not 100% native mode: will probe irqs later
>ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
>ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
>HPT366: onboard version of chipset, pin1=1 pin2=2
>HPT366: IDE controller on PCI bus 00 dev 98
>HPT366: chipset revision 1
>HPT366: not 100% native mode: will probe irqs later
>ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:pio, hdf:pio
>HPT366: IDE controller on PCI bus 00 dev 99
>HPT366: chipset revision 1
>HPT366: not 100% native mode: will probe irqs later
>ide3: BM-DMA at 0xe000-0xe007, BIOS settings: hdg:pio, hdh:pio
>hda: IBM-DPTA-372050, ATA DISK drive
>hdc: IDE/ATAPI CD-ROM 50XS, ATAPI CDROM drive
>hde: , ATAPI CDROM drive
no name here
>ide2: reset
>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>ide1 at 0x170-0x177,0x376 on irq 15
>ide2 at 0xcc00-0xcc07,0xd002 on irq 11
>hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=2495/255/63, UDMA(33)
>hdc: ATAPI 11X CD-ROM drive, 128kB Cache, UDMA(33)
>Uniform CD-ROM driver Revision: 3.11
>hde: ATAPI 8X CD-ROM CD-R drive, 512kB Cache, DMA
^ suddenly got one
I've done some inquiries with hdparm:
[root@Djinn dea]# hdparm -i /dev/hde
/dev/hde:
Model=, FwRev=, SerialNo=
Config={ SpinMotCtl Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=8224
BuffType=8224(?), BuffSize=4112kB, MaxMultSect=32, MultSect=off
DblWordIO=no, maxPIO=32(?), DMA=no
(maybe):
[root@Djinn dea]# hdparm -I /dev/hde
/dev/hde:
Model=RC2-08T1 E , FwRev=.101, SerialNo=
Config={ SpinMotCtl Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=2(DualPort), BuffSize=0kB, MaxMultSect=0
DblWordIO=no, maxPIO=3(eide), DMA=yes, maxDMA=1(medium)
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
tDMA={min:150,rec:230}, DMA modes: ***sword2 **mword1
IORDY=on/off, tPIO={min:180,w/IORDY:180}, PIO modes: mode3
When these were performed i got this in logs:
VFS: Disk change detected on device ide2(33,0)
ATAPI device hde:
Error: Not ready -- (Sense key=0x02)
(reserved error code) -- (asc=0x3a, ascq=0x01)
The failed "Read Table of Contents" packet command was:
"43 02 00 00 00 00 00 00 04 00 00 00 "
VFS: Disk change detected on device ide2(33,0)
ATAPI device hde:
Error: Not ready -- (Sense key=0x02)
(reserved error code) -- (asc=0x3a, ascq=0x01)
The failed "Read Table of Contents" packet command was:
"43 02 00 00 00 00 00 00 04 00 00 00 "
Please note the "Disk change detected": i haven't touch the drive between
the two hdparm.
When i attempt to mount the drive, the whole system got stuck with nothing
in logs(even on serial console).
I've tried different configurations(multimode on/off, reset ide2 on start, etc..)
the result is always the same: lockup when mounting and garbage in logs
when hdparm.
Feel free to ask for more tests or for my whole .config.
--
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandière 0240726275 %
% 44470 Thouare, France [EMAIL PROTECTED] %
% ICU:54999224 AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
% -datamining| .~. %
% -networking| /V\L I N U X%
% -opensource| // \\ >Fear the Penguin< %
% -GNOME/enlightenment/GIMP | /( )\ %
% feel enlighted| ^^-^^%
%-%
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
On Wed, 20 Sep 2000, Julian Anastasov wrote: >Hello, > >On Tue, 19 Sep 2000, Robert H. de Vries wrote: >> It would be better to change SI_SIGIO in all the >> include/asm-*/siginfo.h files from -5 to __SI_CODE(__SI_SIGIO, -5) >> __SI_SIGIO would become (6 << 16). > > This is not needed for SI_SIGIO. It is not generated from >the kernel. It seems this interface is already obsoleted. I think you are mistaking. The purpose of SIGIO is to notify user programs of IO events detected by the kernel. So its use is almost exclusively in the kernel. The reason it currently breaks is that when send_sig_info is used with real info data the check SI_FROMUSER evaluates to true. Other calls use a pointer to address 1 (ugh!) to inform bad_signal() that this signal is generated by the kernel. Robert -- Robert de Vries [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cPCI development
[EMAIL PROTECTED] wrote: > Am I right in assumming that 2.2.14 (as from RH6.2) supports cPCI? Or do I > need to start developing on 2.4? > > I really do need to do some research into this, if I knew where to start. I > need some docs! (either paper, URL, or the straight-jacket kind) cPCI is PCI + hotswap. Most people seem to ignore the hotswap, except at tradeshows. - Adrian Cox, AG Electronics - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17 crashes with RTL8139B and/or IPv6
Hi, I just upgraded our server (486DX2/120, running 186 days`) with a 100MBit RTL8139B network card and moved from 2.2.14 to 2.2.17 in this process, using the same .config (oldconfig) with two differences: IPv6 and the RTL8139 drivers. After about 20k of network activity the machine crashes (I cannot reproduce the message here because the box locks solid while the top of the message is above the top of the display, and the watchdog reboots the box after 20 seconds), reproducible. Ext2 seems to confuse some blocks (I've found portions of /var/lib/dpkg/available in /var/log/apache/access.log) as well, so I suspect some sort of recursion problem (would explain the long backtrace and the corrupted data). System information: Processor: AuthenticAMD 486 DX/4 stepping 4, no bugs, cpuid level 1, wp works in supervisor mode Memory: 36MB real, 6x128MB swap Harddisks: 2 IDE drives PCI listing (Bus 0): - Dev 12, func 0: Realtek 8139 (rev 16) ethernet on IRQ 11 (inactive) - Dev 14, func 0: Realtek 8029 (rev 0) ethernet on IRQ 12 - Dev 16, func 0: UMC UM8881F (rev 4) host bridge - Dev 18, func 0: UMC UM8886A (rev 14) ISA bridge - Dev 18, func 1: UMC UM8886BF (rev 16) IDE interface The kernel is monolithic, no SCSI support. Relevant /proc files (from the 2.2.14 kernel, 2.2.17 is too unstable) attached. I'm sorry that I can't provide more info, but having a running server is important to me... :-) Simon -- PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! processor : 0 vendor_id : AuthenticAMD cpu family : 4 model : 8 model name : 486 DX/4 stepping: 4 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 bogomips: 59.80 4: cascade -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 ff80-ff9f : eth0 CPU0 0: 429185 XT-PIC timer 1: 13 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 12: 314261 XT-PIC eth0 13: 1 XT-PIC fpu 14: 458552 XT-PIC ide0 15: 204256 XT-PIC ide1 NMI: 0 total:used:free: shared: buffers: cached: Mem: 35680256 34562048 1118208 15446016 4497408 20070400 Swap: 767729664 8470528 759259136 MemTotal: 34844 kB MemFree: 1092 kB MemShared:15084 kB Buffers: 4392 kB Cached: 19600 kB SwapTotal: 749736 kB SwapFree:741464 kB PCI devices found: Bus 0, device 12, function 0: Ethernet controller: Realtek 8139 (rev 16). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=64. Min Gnt=32.Max Lat=64. I/O at 0xfc00 [0xfc01]. Non-prefetchable 32 bit memory at 0xffbeff00 [0xffbeff00]. Bus 0, device 14, function 0: Ethernet controller: Realtek 8029 (rev 0). Medium devsel. IRQ 12. I/O at 0xff80 [0xff81]. Bus 0, device 16, function 0: Host bridge: UMC UM8881F (rev 4). Medium devsel. Master Capable. No bursts. Bus 0, device 18, function 0: ISA bridge: UMC UM8886A (rev 14). Medium devsel. Master Capable. No bursts. Bus 0, device 18, function 1: IDE interface: UMC UM8886BF (rev 16). Fast devsel. Master Capable. No bursts. I/O at 0x1f0 [0x1f1]. I/O at 0x3f4 [0x3f5]. I/O at 0x170 [0x171]. I/O at 0x374 [0x375]. I/O at 0xffa0 [0xffa1]. # # Automatically generated by make menuconfig: don't edit # # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Processor type and features # # CONFIG_M386 is not set CONFIG_M486=y # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M686 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_1GB=y # CONFIG_2GB is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # # Loadable module support # # CONFIG_MODULES is not set # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_QUIRKS=y CONFIG_PCI_OPTIMIZE=y CONFIG_PCI_OLD_PROC=y # CONFIG_MCA is not set # CONFIG_VISWS is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=y CONF
FWD: Re: Linux pipe question
Can anyone answer this? I am not sure if unnamed pipes in linux are pageable or not. If an unnamed pipe could be paged out what could be done to prevent that from happening? TIA, Mike - Forwarded message from AW <[EMAIL PROTECTED]> - Date: Wed, 20 Sep 2000 12:27:05 -0400 From: AW <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Linux pipe question > I am not sure... But would this be a named pipe or > not? This would be a UNnamed pipe, i.e., gen_confidential_data | gpg -e -r [EMAIL PROTECTED] ... The question is: is any of the clear text confidential data handled by the unnamed pipe at risk for being written to disk? Comments in the kernel code suggest that it's buffered in a single physical page but I suspect that it's actually a virtual page that could be paged out. Does the answer depend on if gen_confidential_data limits its write to not exceed PIPE_BUF (4096)? Clearly, gen_confidential_data is subject to being paged out unless it locks itself into memory. THANKS! Bob - End forwarded message - -- -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FWD: Re: Linux pipe question
On Wed, Sep 20, 2000 at 12:31:25PM -0400, Mike Panetta wrote:
> Can anyone answer this?
> I am not sure if unnamed pipes in linux
> are pageable or not. If an unnamed pipe
> could be paged out what could be done
> to prevent that from happening?
The pipe itself is not pageable, but the user programs
will use buffers to actually use the pipe, and user programs
are of course pageable.
You might want to look into encrypted swap-space
or at least using mlock() to lock the user programs in
core. It depends on how secure you want it. Could someone
actually access the swap space (eg. steal the disk), or
could someone install compromised versions of the programs
unnoticed ?
Most programs just fill their buffers with random data or
zeroes, after they're done with the confidential data.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Strange virtual/physical address of global data
I wrote a little module to test virt_to_phys:
unsigned long test_data;
int init_module(void)
{
void *virt = &test_data;
unsigned long phys = virt_to_phys(virt);
When I run this and check the valur of virt and phys, it appears that phys is
outside the range of physical memory! That is, if I have 512MB of RAM, then
phys is equal to about 520M. However, if I make test_data a local variable:
int init_module(void)
{
unsigned long test_data;
void *virt = &test_data;
unsigned long phys = virt_to_phys(virt);
Then I get a number which makes sense (less than 512M)
Could someone explain this to me?
--
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com
When replying to a mailing-list message, please don't cc: me, because then I'll just
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel 2.2.17 appears not support >512M RAM Disk
Ryan Tokarek writes: > On Linux kernel 2.2.17 running on an intel PIII system with 1GB RAM I > cannot successfully create a ramdisk of greater than 512MB. It may be that there is a bug, but I would be interested to know what you are really trying to do. Usually bugs like this exist because nobody ever tries such things due to reason of sanity... It may be you are trying to do something which can better be done another way. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __ucmpdi2
In article <[EMAIL PROTECTED]>, Jeremy Higdon <[EMAIL PROTECTED]> wrote: >> - Linux developers often do horribly stupid things, and use 64-bit >>division etc instead of using a simple shift. Again, not linking >>against libgcc finds those things early rather than late, because the >>horribly stupid things end up requireing libgcc support. > >I would have thought that the compiler would generate a shift if it >could (I'm presuming you're talking about shifting by a constant >here -- or are you talking about code that always shifts by a >computed power of two). The compiler is smart, but the compiler doesn't have ESP. For example, what some filesystems did was basically blocknumber = offset_64bit / filesystem->blocksize; which is not optimizable. Because while it _is_ a division by a power of two, gcc has no way of knowing that, nor _what_ power of two. Gcc doesn't know that the ext2 blocksize is 1024, 2048 or 4096 ;) The fix is to hit such Linux developers virtually on the head (by having a kernel that doesn't link ;), and rewrite the code as blocknumber = offset_64bit >> filesystem->blocksize_bits; which does exactly the same thing, except it is about a hundred times faster. See? >> In the case of __ucmpdi2, it appears to be a combination of kernel and >> compiler stupidity - there's no reason why __ucmpdi2 should not be done >> inline by the compiler, but at the same time there is probably also >> little reason to use a slow "long long" comparison in the kernel. > >Little reason or no reason? If there is a reason, and it doesn't >work, then the coder is forced to rewrite using 32 bit variables, >synthesizing the result. Then you have belabored C code as well >as belabored machine code, and it doesn't automatically clean up >when you move to a 64 bit machine. Oh, but usually it does. For example, most of the time these things are due to issues like if (offset >= page_offset(page)) ... where Page_offset() is simply "(unsigned long long)page->index << PAGE_CACHE_SHIFT" Very readable, no? But it doesn't get any worse by doing the comparison the other way around, and instead doing if (index(offset) >= page->index) which is faster (because now you have only one long long shift, not two shifts and a comparison), and equally readable (yeah, you have to think about it for a bit if you want to convince yourself that it's the same thing due to the low-order bits you lost, but in many cases where we did this conversion the end result was _more_ readable, because the end result was that we always worked on index+offset parts, and there was no confusion). And on 64-bit machines the code is exactly the same too. No slow-down. This was why I hated the original LFS patches. They mindlessly just increased a lot of stuff to 64 bits, with no regard for what teh code really _meant_. I ended up re-writing the core code completely before LFS was accepted into the 2.3.x series - using page index calculations instead, which meant that most of the actual critical routines _still_ did the same old 32-bit calculations, they just did them with the part of the values that really mattered - thus giving effectively a 44 bit address space. And btw, doing it this way means that on the alpha we could potentially have a "77-bit address space" for file mapping. So yes, it actually means other improvments too - even for 64-bit machines. (Now, the 77-bit address space that the new VM potentially gives to 64-bit architectures is only useful for people who use the page cache directly, because obviously file sizes are still just 64-bit integers. But it could be useful for the internal implementation of distributed memory, for example.) Ehh.. Basically, my argument boils down to the old truism: by thinking about the problem and doign the smart thing, you can often do more with less work. >So what we've said is: 64 bit is okay, except in a switch statement, >or other random expressions that might cause gcc to embed a call to >similar libgcc function. No, what Linux really says is that you should avoid using "long long" (and thus 64-bit values), because on many architectures it is slower. And I further say that it is usually very easy to avoid it. But you shouldn't go overboard. Simple "long long" arithmetic is useful and easy, even on 32-bit platforms. The kernel does quite a lot of it, as all file offsets are basically 64 bits. But by thinking about the problem some more, you can often limit it to those simple operations, which are fast anyway. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abuse of macros in swab.h
> +static inline __u64 ___swab16(__u64 x)
> +{
> + return (__u64)((x & (__u64)0x00ffULL) << 56) |
> + (__u64)((x & (__u64)0xff00ULL) << 40) |
> + (__u64)((x & (__u64)0x00ffULL) << 24) |
> + (__u64)((x & (__u64)0xff00ULL) << 8) |
> + (__u64)((x & (__u64)0x00ffULL) >> 8) |
> + (__u64)((x & (__u64)0xff00ULL) >> 24) |
> + (__u64)((x & (__u64)0x00ffULL) >> 40) |
> + (__u64)((x & (__u64)0xff00ULL) >> 56);
> +}
I'm afraid the above one will not compile correctly with gcc-2.7.2.3,
which is still "official" compiler (especially) for 2.2.
Old gcc versions seem not to supprt 64-bit inline functions...
Just check 2.4 compilation with CONFIG_HIGHMEM64G=y ...
Andrzej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-kernel-digest ?
On Wed, Sep 20, 2000 at 04:38:45PM +0100, Robert Greimel wrote: > Hi, > I am just wondering if linux-kernel-digest is going to come back. > Greetings According to DaveM: No. (Sometimes he holds possibly bad opinnions as ferociously as Linus, but on the other hand, that Majordomo 1.x digester breaks structured MIME messages BADLY. It should be trivial to fix, but I don't hack Md, I hack ZMailer -- and also sometimes the kernel.) > Robert /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-kernel-digest ?
Matti Aarnio wrote: > On Wed, Sep 20, 2000 at 04:38:45PM +0100, Robert Greimel wrote: > > Hi, > > I am just wondering if linux-kernel-digest is going to come back. > > Greetings > > According to DaveM: No. > (Sometimes he holds possibly bad opinnions as ferociously as Linus, >but on the other hand, that Majordomo 1.x digester breaks structured >MIME messages BADLY. It should be trivial to fix, but I don't hack >Md, I hack ZMailer -- and also sometimes the kernel.) > This is very unfortunate, since linux-kernel-digest was the great way to keep many interested people informed about state of Linux development Without it, > 200 mails daily in linux-kernel is fairly prohibitive if you are not an active developer. Dmitri Pogosyan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [IDE]2.4.0test9-pre1, CD drive on hpt366 not detected correctlyand locking up when activated
The ATAPI-DMA code for the use of all addon cards is not native.
You are not allowed to do ATAPI-DMA on these, yet.
I do not care what the OEM claims with their drivers, Linux chipset code
is not completed or started to do this in 95 % of the cases.
Cheers,
On Wed, 20 Sep 2000, FORT David wrote:
> The subject says everything, while detecting the drive
>
> i got the following strange thing:
>
> [from dmesg]
>
> >PIIX4: chipset revision 1
> >PIIX4: not 100% native mode: will probe irqs later
> >ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
> >ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
> >HPT366: onboard version of chipset, pin1=1 pin2=2
> >HPT366: IDE controller on PCI bus 00 dev 98
> >HPT366: chipset revision 1
> >HPT366: not 100% native mode: will probe irqs later
> >ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:pio, hdf:pio
> >HPT366: IDE controller on PCI bus 00 dev 99
> >HPT366: chipset revision 1
> >HPT366: not 100% native mode: will probe irqs later
> >ide3: BM-DMA at 0xe000-0xe007, BIOS settings: hdg:pio, hdh:pio
> >hda: IBM-DPTA-372050, ATA DISK drive
> >hdc: IDE/ATAPI CD-ROM 50XS, ATAPI CDROM drive
> >hde: , ATAPI CDROM drive
>
> no name here
> >ide2: reset
> >ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> >ide1 at 0x170-0x177,0x376 on irq 15
> >ide2 at 0xcc00-0xcc07,0xd002 on irq 11
> >hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=2495/255/63, UDMA(33)
> >hdc: ATAPI 11X CD-ROM drive, 128kB Cache, UDMA(33)
> >Uniform CD-ROM driver Revision: 3.11
> >hde: ATAPI 8X CD-ROM CD-R drive, 512kB Cache, DMA
>
> ^ suddenly got one
>
> I've done some inquiries with hdparm:
>
> [root@Djinn dea]# hdparm -i /dev/hde
>
> /dev/hde:
>
> Model=, FwRev=, SerialNo=
> Config={ SpinMotCtl Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
> RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=8224
> BuffType=8224(?), BuffSize=4112kB, MaxMultSect=32, MultSect=off
> DblWordIO=no, maxPIO=32(?), DMA=no
> (maybe):
>
> [root@Djinn dea]# hdparm -I /dev/hde
>
> /dev/hde:
>
> Model=RC2-08T1 E , FwRev=.101, SerialNo=
> Config={ SpinMotCtl Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
> RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
> BuffType=2(DualPort), BuffSize=0kB, MaxMultSect=0
> DblWordIO=no, maxPIO=3(eide), DMA=yes, maxDMA=1(medium)
> (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
> tDMA={min:150,rec:230}, DMA modes: ***sword2 **mword1
> IORDY=on/off, tPIO={min:180,w/IORDY:180}, PIO modes: mode3
>
> When these were performed i got this in logs:
>
> VFS: Disk change detected on device ide2(33,0)
> ATAPI device hde:
> Error: Not ready -- (Sense key=0x02)
> (reserved error code) -- (asc=0x3a, ascq=0x01)
> The failed "Read Table of Contents" packet command was:
> "43 02 00 00 00 00 00 00 04 00 00 00 "
> VFS: Disk change detected on device ide2(33,0)
> ATAPI device hde:
> Error: Not ready -- (Sense key=0x02)
> (reserved error code) -- (asc=0x3a, ascq=0x01)
> The failed "Read Table of Contents" packet command was:
> "43 02 00 00 00 00 00 00 04 00 00 00 "
>
> Please note the "Disk change detected": i haven't touch the drive between
>
> the two hdparm.
>
> When i attempt to mount the drive, the whole system got stuck with nothing
>
> in logs(even on serial console).
>
> I've tried different configurations(multimode on/off, reset ide2 on start, etc..)
>
> the result is always the same: lockup when mounting and garbage in logs
>
> when hdparm.
>
> Feel free to ask for more tests or for my whole .config.
>
> --
> %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
> % FORT David, %
> % 7 avenue de la morvandière 0240726275 %
> % 44470 Thouare, France [EMAIL PROTECTED] %
> % ICU:54999224 AIM: enlighted popo [EMAIL PROTECTED] %
> %--LINUX-HTTPD-PIOGENE%
> % -datamining| .~. %
> % -networking| /V\L I N U X%
> % -opensource| // \\ >Fear the Penguin< %
> % -GNOME/enlightenment/GIMP | /( )\ %
> % feel enlighted| ^^-^^%
> %-%
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Question: Using floating point in the kernel
On Wed, 20 Sep 2000, Timur Tabi wrote: > ** Reply to message from "Lyle Coder" <[EMAIL PROTECTED]> on Wed, 20 Sep 2000 > 01:50:05 GMT > > > > You cannot use MMX registers in the kernel either, since the kernel doesen't > > save and restore FX state (fxsave, fxrstor) either (just like > > (fsave/frstor). > > But what about these source files: > > include/asm-i386/mmx.h (which several other header files, like asm-i386/page.h, > include) > arch/i386/lib/mmx.c > arch/i386/lib/usercopy.c > > It appears that MMX is being used in the kernel already. > > Well the code does a fnsave. Somebody never looked at the damn book! it takes 143 clocks for this, plus at least 3 for fwait. Then it sets a flag to let return code 'know' if the context has to be restored. This code `exists` sort of like moss. I don't think it is ever executed and if it is, you get to keep both broken pieces. If you are going to use floating-point, you __must__ save and restore the state of the FP unit for every context-switch. With multiple CPUs, you have to save/restore the state of the right CPU. etc. And for what? So someone can do something stupid and put floating-point in the kernel. Floating-point is used for mathematics on fractional real numbers. There aren't any in the kernel. If you need fractional parts, which is most unlikely in a binary operated device, then you must express them as the ratio of two integers. Which, I will point out, is often a much more accurate way of handling numbers. 1/3 is denoted exactly. 0.33.. will never be. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FWD: Re: Linux pipe question
Thanks for the reply!
On Wed, Sep 20, 2000 at 07:29:06PM +0200, Jakob Østergaard wrote:
> On Wed, Sep 20, 2000 at 12:31:25PM -0400, Mike Panetta wrote:
> > Can anyone answer this?
> > I am not sure if unnamed pipes in linux
> > are pageable or not. If an unnamed pipe
> > could be paged out what could be done
> > to prevent that from happening?
>
> The pipe itself is not pageable, but the user programs
> will use buffers to actually use the pipe, and user programs
> are of course pageable.
>
> You might want to look into encrypted swap-space
> or at least using mlock() to lock the user programs in
> core. It depends on how secure you want it. Could someone
> actually access the swap space (eg. steal the disk), or
> could someone install compromised versions of the programs
> unnoticed ?
>
> Most programs just fill their buffers with random data or
> zeroes, after they're done with the confidential data.
>
> --
> ...
> : [EMAIL PROTECTED] : And I see the elder races, :
> :.: putrid forms of man:
> : Jakob Østergaard : See him rise and claim the earth, :
> :OZ9ABN : his downfall is at hand. :
> :.:{Konkhra}...:
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: uid
Dan: GNU tar uses text usernames preferentially, otherwise it falls back upon numeric IDs. So if you had a user with the same user name as in the tar file, it would chown it to that user's ID, not the same id as 'tarabas'. This is true only for GNU format tar, however; SysV format tar files do not store textual usernames. -Chris Wing [EMAIL PROTECTED] > Not true. All the kernels I download from a certain local mirror are owned > by the local user 'tarabas' since the uid happens to be the same with > those on the mirror site. So numeric uids. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
Hello, On Wed, 20 Sep 2000, Robert H. de Vries wrote: > > This is not needed for SI_SIGIO. It is not generated from > >the kernel. It seems this interface is already obsoleted. > > I think you are mistaking. The purpose of SIGIO is to notify user programs of > IO events detected by the kernel. So its use is almost exclusively in the > kernel. Not in 2.4-test. You have to show me the right place in the sources :) I'm talking about test8. __SI_CODE is in 2.4, not in 2.2. The handling is very different. We can't wait for si_code==SI_SIGIO in 2.4 anymore. SI_SIGIO is used only in 2.2:fs/fcntl.c. 2.4 stores POLL_xxx in si_code instead of SI_SIGIO. > The reason it currently breaks is that when send_sig_info is used with real > info data the check SI_FROMUSER evaluates to true. > Other calls use a pointer to address 1 (ugh!) to inform bad_signal() that > this signal is generated by the kernel. If your are talking about 2.2, of course it is broken but I'm not sure if this bug can be fixed without breaking the binary compatibility. But what about this ugly fix for 2.2: #define SI_KERN_SIGIO(0x200+SI_SIGIO) /* select better value */ fs/fcntl.c:send_sigio() to send SI_KERN_SIGIO (instead of SI_SIGIO) and send_sig_info() to change it to SI_SIGIO after the EPERM check: /* Send SI_SIGIO to user space */ if (info->si_code == SI_KERN_SIGIO) info->si_code = SI_SIGIO; The FROMUSER check is already performed from sys_rt_sigqueueinfo() before send_sig_info(). The other users of send_sig_info() always use info == 0 or 1. So, this allows the PERM check to be bypassed for the SI_SIGIO sent from the kernel. If there are other such codes that we must rewrite before sending them to the user space we can group them using something like this (0x100..0x1FF, SI_KERNEL=0x80 is not in this group, so > 0x100): if (info->si_code - 0x0100 >= 0) info->si_code -= 0x200; si_code is int No changes in the user space. The main goal: to bypass the EPERM check for SI_SIGIO sent from the kernel. Can such fix solve the problem? > Robert > > -- > Robert de Vries > [EMAIL PROTECTED] Regards -- Julian Anastasov <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-kernel-digest ?
I think DaveM also supplied an answer: "procmail" Select by header: X-Mailing-List: [EMAIL PROTECTED] Do note that TAB character, for some reason it really is not space.. Store into separate folder from your normal inbox. On Wed, Sep 20, 2000 at 02:26:33PM -0400, Dmitry Pogosyan wrote: > Date: Wed, 20 Sep 2000 14:26:33 -0400 > From: Dmitry Pogosyan <[EMAIL PROTECTED]> > X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-12 i686) > X-Accept-Language: en > To: [EMAIL PROTECTED] > Subject: Re: linux-kernel-digest ? > Precedence: bulk > X-Mailing-List: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.17 crashes with RTL8139B and/or IPv6
On Wed, 20 Sep 2000, Simon Richter wrote: > Hi, > > I just upgraded our server (486DX2/120, running 186 days`) with a 100MBit ^^ isn't it overclocked? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre4 VM unbalanced?
Hi, all. I've just brought up a 2.4.0-test kernel for the first time on this box (dual PIII with 1 GiB RAM), and I get the following message: Warning - running *really* short on DMA buffers With 1 GiB surely this shouldn't happen?!? This is 2.4.0-test9-pre4. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Wait queues and a race condition on 2.2.x
I'm working on a driver for the Hi/fn 7751 encryption chip, and I've run
into a weird problem and I'm not entirely sure how to fix it. The driver
was originally written for NT, but has been broken out into OS-specific and
OS-independent parts, and the Linux-specific part calls code in the
OS-independent part of the driver to process requests. The code I'm working
with is currently doing something like this:
.
.
.
/* send a request to the other part of the driver here */
save_flags(flags);
cli();
interruptible_sleep_on_timeout(callback, HZ) /* 1 second timeout */
restore_flags(flags);
if(timeout == 0) {
/* We timed out. Abort the request */
/* cleanup stuff goes here */
return -EIO;
}
.
.
.
where "callback" is a callback routine that wakes up when the Linux code
gets a response from the other side of the driver.
Now, the problem I'm having is that when I run with about 8 processes using
the driver at once, this part of the code appears to spill over, causing
all the sessions to act like the timeout expired and the other side of the
driver is having problems...but I can use a single session at this point,
and get a request through with no problems. I noticed that in the FreeBSD
version of the code, the original developer set splhigh() (pretty much the
equivalent of cli()) and tsleep()/wakeup(), which allow you to give a
context along with the request so that the wrong queue entry doesn't get
pulled; in FreeBSD, the problem doesn't happen. My theory is that, with
many processes hitting the card at once, the queue is getting overwhelmed
somehow. Am I handling this correctly, and more importantly, is there a
better way to do what I'm doing?
-lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/partitions is wrong
On Wed, Sep 20, 2000 at 12:11:33PM +0200, Marko van Dooren wrote: > Hello, my /proc/partitions says I have 25 partitions while there are > only 21. Fdisk shows the right information, so there's nothing wrong > with my disk or so. > Kernel version 2.2.17 > Harddisk : Maxtor 54098U8 40GB 7200rpm ide What a strange idea! The kernel is the authority, not fdisk. Your /proc/partitions is right, as you can probably verify by doing dd if=/dev/hda23 of=/dev/null or so. Looking at the kernel boot messages will tell you precisely what these unexpected partitions are. (Don't you have CONFIG_BSD_DISKLABEL enabled, and slices in this BSD partition?) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cPCI development
On Wed, 20 Sep 2000, Adrian Cox wrote: > cPCI is PCI + hotswap. Most people seem to ignore the hotswap, except at > tradeshows. ISPs certainly don't ignore hotswap. Unfortunately, Linux does. :) :( -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cPCI development
} On Wed, 20 Sep 2000, Adrian Cox wrote: } > cPCI is PCI + hotswap. Most people seem to ignore the hotswap, except at } > tradeshows. } } ISPs certainly don't ignore hotswap. Unfortunately, Linux does. :) :( PowerPC has hotswap for Motorola boards thanks to Johnnie Peters and Matt Porter. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.17 crashes with RTL8139B and/or IPv6
On Wed, 20 Sep 2000, Marco Colombo wrote: > On Wed, 20 Sep 2000, Simon Richter wrote: > > > Hi, > > > > I just upgraded our server (486DX2/120, running 186 days`) with a 100MBit > ^^ > isn't it overclocked? >From the CPU identification given later, it is said to be a 486 DX4/120 - 120 MHz core on a 40 MHz FSB, 3x clock multiplier. Simon: Have you tried the 8139too driver with this series?? I can't remember much detail about it off-hand, but it could be worth a try? James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NAT dropping packets
In <[EMAIL PROTECTED]> Russell King <[EMAIL PROTECTED]> writes: >NAT: 3 dropping untracked packet c065d3a0 1 192.168.0.1 -> 192.168.0.9 I see loads of these, in a firewall (state matching) and SNAT setup. When I send mail, I see them quite regularly. It is quite annoying, since they get dumped to the active text-mode console, in addition to being logged. Looking at the code a while back, quite a few of the netfilter printk()'s did not have a log-level setting. Was this omitted intentionally ? (Just checked 2.4.0-test9-pre4, it hasn't changed). -- Henrik Storner | "Crackers thrive on code secrecy. Cockcroaches breed <[EMAIL PROTECTED]> | in the dark. It's time to let the sunlight in." | | Eric S. Raymond, re. the Frontpage backdoor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-kernel-digest ?
Matti Aarnio wrote: > I think DaveM also supplied an answer: "procmail" > > Select by header: > > X-Mailing-List: [EMAIL PROTECTED] > > Do note that TAB character, for some reason it really is not space.. > Store into separate folder from your normal inbox. Ah!!! Thats why my there never matched. I just always do: X-Mailing-List:.*[EMAIL PROTECTED] but now I know why. Thanks. (This also makes it easy to put all mailing lists from one site in one mailbox. :-) Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2 (version numbering)
"Barry K. Nathan" <[EMAIL PROTECTED]> said: [...] > In other words, if I understand things correctly, once we have Linux > 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of > testing before release, 2.4.0-pre1 will be next... That so? Must get Linus an Alpha or SPARC64 ASAP so 2.4.0-test isn't unduly restricted by version numbers... -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre4: __alloc_pages(...) try_again:
Hi,
Trying to find out why test9-pre4 freezes with mmap002
I added a counter for try_again loops.
... __alloc_pages(...)
int direct_reclaim = 0;
unsigned int gfp_mask = zonelist->gfp_mask;
struct page * page = NULL;
+ int try_again_loops = 0;
- - -
+ printk("VM: sync kswapd (direct_reclaim: %d) try_again #
%d\n",
+direct_reclaim, ++try_again_loops);
wakeup_kswapd(1);
goto try_again;
Result was surprising:
direct_reclaim was 1.
try_again_loops did never stop increasing (note: it is not static,
and should restart from zero after each success)
Why does this happen?
a) kswapd did not succeed in freeing a suitable page?
b) __alloc_pages did not succeed in grabbing the page?
/RogerL
--
Home page:
http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
- Original Message -
From: "Linus Torvalds" <[EMAIL PROTECTED]>
To: "Torben Mathiasen" <[EMAIL PROTECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 6:59 PM
Subject: Re: [PATCH] Re: SCSI scanning
>
>
> On Wed, 20 Sep 2000, Torben Mathiasen wrote:
> >
> > I can't seem to find a clean way of getting the drivers outside
"drivers/scsi"
> > to link _after_ the other low-level drivers. My linux Makefile abilities
is
> > limited though, so if someone with the knowledge would do what Eric
requests
> > above please. We will probaly have to move some thing around, and that
would be a
> > _bad_ move at this point I guess.
>
> Note that ordering requirements are usually bad requirements. In many
> cases it's probably best to just fix the problem that causes ordering
> requirements in the first place.
Some of problems that are forcing ordering requirements are better fixed
in 2.5. The cleanups to allow disk and cdrom drivers to dynamicly resize
are probably in this category. If you disagree, I can take a stab at it,
but some of the changes won't be simple.
It isn't that I don't want to do it - I have been itching to clean this
up for some time now anyways - and it was getting near the top of things to
do :-). Actually once the groundwork is laid, the work for drivers outside
of SCSI could be handled by others, or even deferred (which in itself would
simplify the task) to 2.5.
We did get the character device (tape and generic) cleaned up so
*technically* there are no ordering requirements for those two. It is only
disk and tape that still have this problem, and it is the only issue that
imposes any ordering at all (other than the question of newer drivers/older
drivers, which can easily be addressed in the Makefile).
> So we don't need to do a "perfect" job on ordering. In fact, we probably
> want to avoid ordering as much as possible - I'd rather fix the problems
> that cause us to want to order thing than spending much time trying to
> order stuff.
>
> Some ordering is simple: making sure that newer drivers show up before
> older drivers that can catch on compatibility stuff. Some other cases are
> equally obvious: keeping the sort in pretty much the same order as the old
> hosts.c file just to avoid having peoples disks being re-ordered if
> somebody has multiple types of SCSI controllers. That's more of a "let's
> be polite" thing.
>
> But let's fix the real problems rather than hit our heads against the
> ordering wall..
My thinking is that for 2.4 we can impose a simple ordering by adding a
few lines to vmlinux.lds (the linker script that is used to collect assorted
ELF sections together, which lives in arch//vmlinux.lds). Thus
instead of:
.initcall.init : { *(.initcall.init) }
we could instead have:
.initcall.init : { *(.initcall.init1) }
.initcall.init : { *(.initcall.init2) }
.initcall.init : { *(.initcall.init) }
It would be trivial to ensure correct order by making the scsi core 1, make
the host adapters 2, make the upper level adapters normal initcall.
Everything else is left alone. If there is anything that needs to be
initialized prior to SCSI, we could invent an initcall.init0, but I doubt
that there is anything that would fit into this category.
It isn't as ugly as jumping through millions of hoops to get the Makefiles
to do it right.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: missing symbols with depmod - how to solve this?
On Wed, 20 Sep 2000 16:43:28 +0200, Graham Leggett <[EMAIL PROTECTED]> wrote: >[root@jolanda /root]# depmod -m /boot/System.map-2.2.17 -a 2.2.17 >/lib/modules/2.2.17/fs/nls_koi8-r.o: unresolved symbol(s) >/lib/modules/2.2.17/fs/nls_iso8859-15.o: unresolved symbol(s) Get the latest modutils and use depmod -F System.map. The -m flag is a RedHat addon which does not work correctly and will not be included in the standard modutils code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Wed, 20 Sep 2000, Eric Youngdale wrote: > > Some of problems that are forcing ordering requirements are better fixed > in 2.5. The cleanups to allow disk and cdrom drivers to dynamicly resize > are probably in this category. If you disagree, I can take a stab at it, > but some of the changes won't be simple. Oh, I don't disagree at all. I think we'll have the old order (Torben's patches seem to do that as far as I can tell) for now, but I just wanted the long-range plan to be that we shouldn't be as order-fragile as we are. No point in doing that now. > My thinking is that for 2.4 we can impose a simple ordering by adding a > few lines to vmlinux.lds (the linker script that is used to collect assorted > ELF sections together, which lives in arch//vmlinux.lds). Thus > instead of: [deleted] Yeah, I've considered it. For other reasons. We already have a few stages of ordering, like having to initialize things like PCI etc before initializing PCI devices, and right now those stages are all explicit (ie pci_init() is _not_ an initcall). Maybe. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.4: Fix Cardbus
On Wed, 20 Sep 2000 10:22:50 -0400, Jeff Garzik <[EMAIL PROTECTED]> wrote: >Dag Bakke wrote: >> ROM image dump: >> cs: no valid ROM images found! >> >> Same problem, or different problem? This time, the card is not even >> detected... > >Look around for patches from Keith Owens relating to this, and the >xircom_tulip_cb driver. It needs a ROM image mapping into the address >space, which is normally not done without the special "pci=rom" setting >on the kernel command line. Keith's patch, IIRC, temporary does a >mapping in order to get the necessary information from the ROM image. You must be thinking of my one line patch to pcibios_update_resource, adding new |= PCI_ROM_ADDRESS_ENABLE; But that patch was included in 2.4.0-test2-pre1. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PCMCIA: 2.4.0-test9pre4: PCI resource for 3CCFE575CT
Hello, I just installed the latest kernel: 2.4.0-test9pre4. I have also installed the pcmcia-cs-3.1.20 package. I have a Compaq Armada 7400 with 128 MB RAM and a 4 GB disk running Mandrake 7.0. I want to report the following malfunction. There is something bad between the PCI, the 3c59x cardbus driver and the PCMCIA. When I use the 3CCFE575CT, I got the following messages: Linux PCMCIA Card Services 3.1.20 options: [pci] [cardbus] [pm] Yenta IRQ list 0698, PCI irq11 Socket status: 3020 Yenta IRQ list 0698, PCI irq11 Socket status: 3006 cs: cb_alloc(bus 2): vendor 0x10b7, device 0x5257 PCI: Failed to allocate resource 0 for PCI device 10b7:5257 PCI: Failed to allocate resource 1 for PCI device 10b7:5257 PCI: Failed to allocate resource 2 for PCI device 10b7:5257 PCI: Failed to allocate resource 6 for PCI device 10b7:5257 PCI: Device 02:00.0 not available because of resource collisions 3c59x: vortex_probe1 fails. Returns -5 cs: IO port probe 0x1000-0x17ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x220-0x22f 0x250-0x257 0x330-0x337 0x378-0x37f 0x388-0x38f 0x408-0x40f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. When I use my 3CCE589ET, everything works fine. Any ideas ? Thanks for the support, Claude. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PCMCIA: 2.4.0-test9pre4: still reading only one socket
Hello, With 2.4.0-test7, it was impossible for me to have my two PCMCIA sockets running (2.2.x was OK). Only the socket 0 was working fine. I have upgraded to 2.4.0-test9pre4 and pcmcia-cs-3.1.20 and I still have the same problem. From my /var/log/messages, I get: Sep 20 16:06:10 qwerty cardmgr[383]: starting, version is 3.1.20 Sep 20 16:06:11 qwerty rc: Starting pcmcia succeeded Sep 20 16:06:11 qwerty cardmgr[383]: watching 1 sockets Sep 20 16:06:11 qwerty kernel: cs: IO port probe 0x1000-0x17ff: clean. Sep 20 16:06:11 qwerty kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x220-0x22f 0x250-0x257 0x330-0x337 0x378-0x37f 0x388-0x38f 0x408-0x40f 0x4d0-0x4d7 Correct me if I'm wrong, but would it be possible to try a polling configuration to finally get the socket 1 working or this problem is really a kernel side issue ? Thanks again, Claude. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2 (version numbering)
> "Barry K. Nathan" <[EMAIL PROTECTED]> said: > > > In other words, if I understand things correctly, once we have Linux > > 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of > > testing before release, 2.4.0-pre1 will be next... > > That so? Must get Linus an Alpha or SPARC64 ASAP so 2.4.0-test isn't unduly > restricted by version numbers... I just picked 2^32 as a jokingly large number - if I meant to imply a 32-bit limit, I would have done 2^32 - 1 (4294967295) instead. :) (When I was writing the email, I was wondering if I should have made it 4294967297 instead...) -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Hang on 2.2.17 - serial/tty related?
Hi, I just experianced a complete hang of one of my systems here after using the serial port a lot (ie, open, read/write, close). I was using minicom, and I started to notice that each time I quit minicom, it would not exit. ps alx revealed that it was waiting in tty_wait_until_sent, yet the serial port was not doing anything at all (I've got a couple of LEDs on the Tx and Rx lines). However, the port was in xon/xoff mode, but it seemed to be capable of transmitting immediately prior (note that at this time, the remote end had no capability to send an xon character to stop the transmission). When I say "waiting" above, I mean waiting for over 1 minute, dispite the timeouts being set at the default. Here are the port settings: /dev/ttyS2, Line 2, UART: 16550A, Port: 0x80092900, IRQ: 34 Baud_base: 460800, close_delay: 50, divisor: 0 Flags: spd_normal When the actual crash happened, I changed the baud rate on the target system, and just changed the local baud rate to 115200. I then hit the enter key and that was game over. No response on network, nor X. The machine was completely and utterly dead to the point of requiring a hardware reset. The serial driver is based on Tytso's driver; the changes present are to allow interrupt 0, high port numbers, and the baud_base to be specified when ports are registered with it via register_serial(). There was no oops, sorry. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2-fs error and geometry walk ... ???
Andries, The crap out is between 2.4.0-test5 and 2.4.0-test6. It takes four drives that were single partitioned and rips the first 130 blocks out and creates 4 bogus partitions. Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 p10 > /dev/ide/host0/bus0/target1/lun0: p1 /dev/ide/host2/bus0/target0/lun0: p1 p2 p3 p4 /dev/ide/host2/bus0/target1/lun0: p1 p2 p3 p4 /dev/ide/host2/bus0/target2/lun0: p1 p2 p3 p4 /dev/ide/host2/bus0/target3/lun0: p1 p2 p3 p4 Was Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 p10 > /dev/ide/host0/bus0/target1/lun0: p1 /dev/ide/host2/bus0/target0/lun0: p1 /dev/ide/host2/bus0/target1/lun0: p1 /dev/ide/host2/bus0/target2/lun0: p1 /dev/ide/host2/bus0/target3/lun0: p1 This is the difference between boots. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
sigtimedwait with a zero timeout
Hi.
While playing with signal queues it was discovered that sigtimedwait
with a zero timeout apparently does block somewhat even if it should
not.
Why:
It forces a schedule()
Also the actual delay seems to be at least 10msec more than requested,
but I guess that is an effect of the schedule()?
Attached is a small patch to optimize this case. (the .patchw version is
with -w to more clearly indicate the minimal changes made)
Some timings to prove the point: (Intel)
Linux-2.4.0-test7 without the patch:
timeout = 0 nsec: blocks for 10msec
timeout = 10 nsec: blocks for 20msec
Linux-2.4.0-test8 with the patch:
timeout = 0 nsec: does not block. ~0.1200 msec on my laptop.
timeout = 10 nsec: blocks for 20msec
Due to laziness I have not timed 2.4.0-test8 without the patch.
--
Henrik Nordstrom
--- linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c.orig Sat Sep 16
11:47:04 2000
+++ linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c Sat Sep 16 11:52:18
+2000
@@ -848,15 +848,18 @@
timeout = (timespec_to_jiffies(&ts)
+ (ts.tv_sec || ts.tv_nsec));
- current->state = TASK_INTERRUPTIBLE;
- timeout = schedule_timeout(timeout);
+ if (timeout) {
+ current->state = TASK_INTERRUPTIBLE;
+ timeout = schedule_timeout(timeout);
- spin_lock_irq(¤t->sigmask_lock);
- sig = dequeue_signal(&these, &info);
- current->blocked = oldblocked;
- recalc_sigpending(current);
- }
- spin_unlock_irq(¤t->sigmask_lock);
+ spin_lock_irq(¤t->sigmask_lock);
+ sig = dequeue_signal(&these, &info);
+ current->blocked = oldblocked;
+ recalc_sigpending(current);
+ spin_unlock_irq(¤t->sigmask_lock);
+ }
+ } else
+ spin_unlock_irq(¤t->sigmask_lock);
if (sig) {
ret = sig;
--- linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c.orig Sat Sep 16
11:47:04 2000
+++ linux-2.4.0-test7-reiserfs-3.6.14-raw-hno/kernel/signal.c Sat Sep 16 11:52:18
+2000
@@ -848,6 +848,7 @@
timeout = (timespec_to_jiffies(&ts)
+ (ts.tv_sec || ts.tv_nsec));
+ if (timeout) {
current->state = TASK_INTERRUPTIBLE;
timeout = schedule_timeout(timeout);
@@ -855,7 +856,9 @@
sig = dequeue_signal(&these, &info);
current->blocked = oldblocked;
recalc_sigpending(current);
+ spin_unlock_irq(¤t->sigmask_lock);
}
+ } else
spin_unlock_irq(¤t->sigmask_lock);
if (sig) {
Re: Software RAID
Steve Hill wrote: > > Has anyone had any problems with software RAID causing high loadaverage > peaks? I've got a number of i586 boxes here, dual IDE controllers, one > drive on each controller. They're using RAID 1 across the two > drives. Every few hours, the load average peaks very high, and it appears > to be the RAID (identacal boxes, running identical software but without > the RAID don't seem to have the problem). > > Is this normal, or is something broken on these boxes? > > -- > > - Steve Hill > System Administrator Email: [EMAIL PROTECTED] > Navaho Technologies Ltd. Tel: +44-870-7034015 Well I do have a 486dx2 (66Mhz-24Mb RAM) Root RAID 0 using three disks, and as far as I can see there are no spikes and the box runs smoothly. Perhaps it's a cron job or some daemon. -- Jorge Nerin <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre5
- pre1: - USB: OHCI controller unlink and bandwidth reclamation fixes - USB: storage update - sparc64: register window race. Non-deadlock rwlocks. - name clash in hamradio/pi2.c and hamradio/pt.c - epic100 credits, 8139too driver update, sr.c initcalls - acenic update - NFS sillyrename fixups - mktime(). Do it just once - not 16 times. - misc small fixes to random drivers by Tigran - IDE driver picks up master/slave relationships on its own. - truncate unmapped/uptodate case handled correctly - don't do notifier locking at low level: higher levels do (or should do) this already. - ACPI interpreter updates (and file renames - making this part big) - SysKonnect gigabit driver update - 3c59x driver update - pcmcia debounce logic. Ugh. - MM balancing (Rik Riel) - pre2: - "extern inline" -> "static inline". It doesn't matter right now, but it's proactive for future gcc versions. - various net drvr updates and fixes - more initcall updates - PPC updates (including PPC-related drivers etc) - disallow re-mounting same filesystem in same place multiple times. Too confusing. And /etc/mtab gets strange. - Riel VM update - sparc updates - PCI bridge scanning fix: assign numbers properly - network updates - scsi fixes - pre3: - uninitialized == zero. Remove extra initializers. - block_prepare_write and block_truncate_page: if the page is up-to-date, then so are the buffer heads inside it once they are mapped.. - SCSI initialization - move over to the modular case. No more double initialization. - Sync up with Alans 2.2.x driver changes - networking updates (iipv6 works non-modular etc) - netfilter update - adfs correct dentry operations - ARM update (including ARM drivers) - acenic driver update - floppy: we'd better hold the io_request_lock when playing with "CURRENT". - NFS cache coherency across file locking fix - NFS over TCP - handle TCP socket writability right.. - USB updates - pre4: - more USB updates - continued SCSI cleanup - pre5: - more drivers synced to Alan's 2.2.x changes - sis900 driver update - Andries: net device name allocation as in 2.2.x - pmac SCSI driver init update - ixj telephony driver fixes - _fput/__fput are no longer used. - more USB updates - codafs update - byteorder: use statement expressions instead of macros, to avoid argument re-use. - don't disallow Onstream ide-scsi devices - fix cardbus bridge resources.. - Make SCSI initialization order be same as before. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Updated serial driver for 2.2.x
Hello, I'd like to ask if there exists a backport of 2.4 serial driver to 2.2.x. I've got to get one Oxford Semiconductor PCI serial board with UART 16950 on it running but fail to do so under 2.2.17. Lubomir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
