Re: dropcopyright script
Same here. While it's a nice script and all, I personally want the copyright and associated contact information in a clear and easy-to-find place. In other words, if you get Linus to patch the kernel to do this, then I'm just going to try to get him to patch it back. Matt On Wed, Feb 14, 2001 at 07:55:03AM +, Russell King wrote: > Rick Hohensee writes: > > ... > > ## drop copyright notices to the bottoms of C files in current dir and > > # subs. > > Please don't run this on any files maintained by myself. I want the > copyright notices to be prominently displayed at the top of the file > so it can't be missed. > > Thanks. > > -- > Russell King ([EMAIL PROTECTED])The developer of ARM Linux > http://www.arm.linux.org.uk/personal/aboutme.html > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 PGP signature
2.4.2-pre2 -- Hard hang on warm reboot when the yenta driver attempts to detect the cardbus bridges.
Any debugging tips would be greatly appreciated. When I cold boot my machine with a 3c575 and a Belkin BusPort Mobile inserted in the Cardbus slots, I get the following in my kernel log: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Yenta IRQ list 0698, PCI irq11 Socket status: 3020 Yenta IRQ list 0698, PCI irq11 Socket status: 3020 But, if I remove and then reinsert the cards, call_usermodehelper and /sbin/hotplug recognizes and configure both cards, including bringing up eth0. I am able to use both cards with no trouble. Now, if I warm boot the machine, the boot process completely locks up after the line: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. SysRq commands fail to respond. When I cold boot the machine, lspci -vvxxx gives: 00:04.0 CardBus bridge: Texas Instruments PCI1131 (rev 01) Subsystem: Dell Computer Corporation: Unknown device 007e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 00: 4c 10 15 ac 07 00 00 02 01 00 07 06 08 a8 82 00 10: 00 00 00 10 00 00 00 a2 00 01 01 b0 00 00 40 10 20: 00 f0 7f 10 00 00 80 10 00 f0 bf 10 00 10 00 00 30: fc 10 00 00 00 14 00 00 fc 14 00 00 ff 01 00 05 40: 28 10 7e 00 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 20 30 24 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 3a 74 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:04.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) Subsystem: Dell Computer Corporation: Unknown device 007e Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 00: 4c 10 15 ac 07 00 00 02 01 00 07 06 08 a8 82 00 10: 00 10 00 10 00 00 00 02 00 05 05 b0 00 00 c0 10 20: 00 f0 ff 10 00 00 00 11 00 f0 3f 11 00 18 00 00 30: fc 18 00 00 00 1c 00 00 fc 1c 00 00 ff 02 00 05 40: 28 10 7e 00 01 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 20 30 24 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 3a 74 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01:00.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI]) Subsystem: OPTi Inc.: Unknown device c861 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M686 is not set # CONFIG_MK6 is not set CONFIG_MK7=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=32 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_MICROCODE is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set 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_NAMES=y # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set
Re: [patch] 2.4.2-pre3: parport_pc init_module bug
On Tue, 13 Feb 2001, Tim Waugh wrote:
> Here's a patch that fixes a bug that can cause PCI driver list
> corruption. If parport_pc's init_module fails after it calls
> pci_register_driver, cleanup_module isn't called and so it's still
> registered when it gets unloaded.
> --- linux/drivers/parport/parport_pc.c.init Tue Feb 13 23:31:25 2001
> +++ linux/drivers/parport/parport_pc.cTue Feb 13 23:35:56 2001
> @@ -89,6 +89,7 @@
> } superios[NR_SUPERIOS] __devinitdata = { {0,},};
>
> static int user_specified __devinitdata = 0;
> +static int registered_parport;
>
> /* frob_control, but for ECR */
> static void frob_econtrol (struct parport *pb, unsigned char m,
> @@ -2605,6 +2606,7 @@
> count += parport_pc_find_nonpci_ports (autoirq, autodma);
>
> r = pci_register_driver (_pc_pci_driver);
> + registered_parport = 1;
> if (r > 0)
> count += r;
Bad patch. It should be
if (r >= 0) {
registered_parport = 1;
if (r > 0)
count += r;
}
If pci_register_driver returns < 0, the driver is not registered with
the system.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dropcopyright script
On Wed, 14 Feb 2001, Russell King wrote: > Rick Hohensee writes: > > ... > > ## drop copyright notices to the bottoms of C files in current dir and > > # subs. > > Please don't run this on any files maintained by myself. I want the > copyright notices to be prominently displayed at the top of the file > so it can't be missed. Ditto. Don't touch drivers/net either. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dropcopyright script
Rick Hohensee writes: > ... > ## drop copyright notices to the bottoms of C files in current dir and > # subs. Please don't run this on any files maintained by myself. I want the copyright notices to be prominently displayed at the top of the file so it can't be missed. Thanks. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: piix.c and tuning question
hmmm this is my chipset:
Which motherboard do you have?
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
i've had irq timeouts but they were due to a slow CD-ROM causing the two DMA drives to
timeout (don't
know why).
ive never seen ide_dmaproc though.
This is my following hdparm config
hdparm -d 1 -X34 -u1 -k 1 /dev/hdb
hdparm -d 1 -X34 -u1 -k 1 /dev/hda
for both drives, one of them us a UDMA66 but this Pentium 200Mhz cant do UDMA even ;/
I have a AP53/AX AcerOpen Motherboard.
Shawn.
[EMAIL PROTECTED] wrote:
> I have a box w/ the following controllers:
>
> 00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03)
> 00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
> 00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
>
> I regularly see the following, during high i/o:
>
> Feb 14 02:15:27 inkbay kernel: hdd: timeout waiting for DMA
> Feb 14 02:15:27 inkbay kernel: ide_dmaproc: chipset supported ide_dma_timeout func
>only: 14
> Feb 14 02:15:27 inkbay kernel: hdd: irq timeout: status=0x58 { DriveReady
>SeekComplete DataRequest }
> Feb 14 02:21:13 inkbay kernel: hdc: DMA disabled
> Feb 14 02:21:13 inkbay kernel: hdd: DMA disabled
> Feb 14 02:21:22 inkbay kernel: hdd: timeout waiting for DMA
> Feb 14 02:21:22 inkbay kernel: ide_dmaproc: chipset supported ide_dma_timeout func
>only: 14
> Feb 14 02:21:22 inkbay kernel: hdd: irq timeout: status=0x58 { DriveReady
>SeekComplete DataRequest }
>
> (the DMA being disabled was me manually doing an hdparm -d0)
>
> According to Documentation/Configure.help:
>
> Intel PIIXn chipsets support
> CONFIG_BLK_DEV_PIIX
> This driver adds PIO mode setting and tuning for all PIIX IDE
> controllers by Intel. Since the BIOS can sometimes improperly tune
> PIO 0-4 mode settings, this allows dynamic tuning of the chipset
> via the standard end-user tool 'hdparm'.
>
> Please read the comments at the top of drivers/ide/piix.c.
>
> If you say Y here, you should also say Y to "PIIXn Tuning support",
> below.
>
> If unsure, say N.
>
> PIIXn Tuning support
> CONFIG_PIIX_TUNING
> This driver extension adds DMA mode setting and tuning for all PIIX
> IDE controllers by Intel. Since the BIOS can sometimes improperly
> set up the device/adapter combination and speed limits, it has
> become a necessity to back/forward speed devices as needed.
>
> Case 430HX/440FX PIIX3 need speed limits to reduce UDMA to DMA mode
> 2 if the BIOS can not perform this task at initialization.
>
> If unsure, say N.
>
> Obviously, the BIOS is not performing the DMA mode reduction, and must
> be done maually. However, that's about all the information I can gather
> about this problem. Has anyone looked at the top of piix.c (other than
> the IDE maintainer, that is)? It's quite cryptic:
> * | PIO 4 | MW2 | e3 | a3 | b |piix_tune_drive(drive, 4);
> *
> * sitre = word40 & 0x4000; primary
> * sitre = word42 & 0x4000; secondary
> *
> * 44 8421|8421hdd|hdb
> *
> * 48 8421 hdd|hdc|hdb|hda udma enabled
> *
> *0001 hda
> Wtf is a sitre? What are these odd numbers? And where is any useful
> info that, as a piix driver _user_, I might be able to use? Is it
> merely DMA which I want to tune, or do I want to mess w/ PIO modes
> (marked as dangerous in hdparm) as well?
>
> --
> "... being a Linux user is sort of like living in a house inhabited
> by a large family of carpenters and architects. Every morning when
> you wake up, the house is a little different. Maybe there is a new
> turret, or some walls have moved. Or perhaps someone has temporarily
> removed the floor under your bed." - Unix for Dummies, 2nd Edition
> -- found in the .sig of Rob Riggs, [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
piix.c and tuning question
I have a box w/ the following controllers:
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
I regularly see the following, during high i/o:
Feb 14 02:15:27 inkbay kernel: hdd: timeout waiting for DMA
Feb 14 02:15:27 inkbay kernel: ide_dmaproc: chipset supported ide_dma_timeout func
only: 14
Feb 14 02:15:27 inkbay kernel: hdd: irq timeout: status=0x58 { DriveReady SeekComplete
DataRequest }
Feb 14 02:21:13 inkbay kernel: hdc: DMA disabled
Feb 14 02:21:13 inkbay kernel: hdd: DMA disabled
Feb 14 02:21:22 inkbay kernel: hdd: timeout waiting for DMA
Feb 14 02:21:22 inkbay kernel: ide_dmaproc: chipset supported ide_dma_timeout func
only: 14
Feb 14 02:21:22 inkbay kernel: hdd: irq timeout: status=0x58 { DriveReady SeekComplete
DataRequest }
(the DMA being disabled was me manually doing an hdparm -d0)
According to Documentation/Configure.help:
Intel PIIXn chipsets support
CONFIG_BLK_DEV_PIIX
This driver adds PIO mode setting and tuning for all PIIX IDE
controllers by Intel. Since the BIOS can sometimes improperly tune
PIO 0-4 mode settings, this allows dynamic tuning of the chipset
via the standard end-user tool 'hdparm'.
Please read the comments at the top of drivers/ide/piix.c.
If you say Y here, you should also say Y to "PIIXn Tuning support",
below.
If unsure, say N.
PIIXn Tuning support
CONFIG_PIIX_TUNING
This driver extension adds DMA mode setting and tuning for all PIIX
IDE controllers by Intel. Since the BIOS can sometimes improperly
set up the device/adapter combination and speed limits, it has
become a necessity to back/forward speed devices as needed.
Case 430HX/440FX PIIX3 need speed limits to reduce UDMA to DMA mode
2 if the BIOS can not perform this task at initialization.
If unsure, say N.
Obviously, the BIOS is not performing the DMA mode reduction, and must
be done maually. However, that's about all the information I can gather
about this problem. Has anyone looked at the top of piix.c (other than
the IDE maintainer, that is)? It's quite cryptic:
* | PIO 4 | MW2 | e3 | a3 | b |piix_tune_drive(drive, 4);
*
* sitre = word40 & 0x4000; primary
* sitre = word42 & 0x4000; secondary
*
* 44 8421|8421hdd|hdb
*
* 48 8421 hdd|hdc|hdb|hda udma enabled
*
*0001 hda
Wtf is a sitre? What are these odd numbers? And where is any useful
info that, as a piix driver _user_, I might be able to use? Is it
merely DMA which I want to tune, or do I want to mess w/ PIO modes
(marked as dangerous in hdparm) as well?
--
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
swap errors
Under 2.4.1-ac11 I'm getting errors like: Feb 14 02:10:09 rhino kernel: Unused swap offset entry in swap_count 004dda00 Feb 14 02:10:09 rhino kernel: VM: Bad swap entry 004dda00 over and over. The system has 512M real and 1G swap allocated. This is occuring at: Mem:512492K total, 397780K used, 114712K free, 1192K buffers Swap: 982792K total, 284380K used, 698412K free, 298556K cached while running imagemagick on a bunch of tifs to convert them to jpgs. It's the first time I've seen this error. Is it more likely that the swap file has gone south or is it indicative of something else? Billy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The Next Yahoo
* Hi, linux-kernel What if Yahoo Paid You ? Now a reality !!! World's first completely commissionable Portal just released. Get paid as thousands search, email, or use any of our services. 14 months and 1.5 million dollars invested in the technology and infrastructure. We are going after Yahoo ! Imagine getting paid as others use eBay, Expedia, long distance, cell phones, insurance, electricity, and much more. We have solid long-term contracts with multi-million dollar companies. They are knocking down our door to be a part of our amazing viral customer acquisition model. Get your FREE portal today and start making solid income on thousands as they do what they normally do on the internet! Email: [EMAIL PROTECTED] OR just reply to this email. Include your phone number. We will call you back to let you in on how to get a founders position and create massive wealth ! We have taken applications for only 1 month now and have already paid out over $100,000 in commissions. Get your share ! We are set to have 1 million customers this year and launch globally this summer. This is the time millionaires will be made with us ! We look forward to speaking with you. ( Trip Wakefield, Houston, TX, USA, 1.877.627.6669 ) P.S. Many of us have already replaced our JOB incomes in 1 month! We have a simple, easy to follow, 3 step system for success ! Be sure to reply with your phone number. If you are outside of the USA, reply with International and your phone number. If you do not wish to correspond, reply with "remove" in the subject. Thank You! ** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem: Floppy drive[?] hang
On February 14, 2001 06:15 am, Mike Galbraith wrote: > On Mon, 12 Feb 2001, C. D. Thompson-Walsh wrote: > > [This sortof follows the format of the report form in REPORTING-BUGS] > > 1. I've found a consistent set of circumstances which will hang 2.4.x > > kernels on my system. > > > > 2. If the system is put under load to the point where it swaps heavily > > (swapping appears to be pre-requisite, based on a little messing about), > > and then given commands to use the floppy drive (mount, ls -- anything > > which necessitates reading/writing to the floppy), it will hang with no > > message (it does not OOPS, or at least it can not to the root console) > > I've done this several times, with different disks and kernels, with and > > without X. > > Hi, > > I tried to reproduce this on my PIII-500 VIA chipset box and couldn't. > (problem doesn't seem to be generic fwiw) > > -Mike > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Hmm... Well, I haven't succeeded in hanging 2.2.x this way... So the hardware, (while likely flakey) works... I'll try out another amd system of similar vintage (whose mb make I know! ;-), and see if I can't find anything more helpful/generic... (as well as give speicifc mb info for this system, since it seems to be hw specific) I was going to put 2.4 on it anyways, eventually... In the meantime, well, who uses floppies, anyways? :-) I really wish I knew enough about the kernel/fd and my c were good enough I could do something more constructive... I feel mildly guilty promising to do my best to expose someone else's bug... :-) Best wishes, C. D. Thompson-Walsh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: incremental patches for 2.4*-ac* kernels
On Wed, 14 Feb 2001, Willy Tarreau wrote: > I think that most of us using modems begin to experience a little pain in > downloading latest Alan's patches since they're becoming to be really big (and > interesting). > > Since I have an occasionnal access to a system equipped with a good line, I > began to make incremental patches for these kernels. These patches are about > 60 kb instead of nearly 2 Mb. Those who are interested can download them from > this url : > >http://www-miaif.lip6.fr/willy/pub/linux-patches/ac/ Cool. FWIW, people can also download Alan's patches and Linus' pre-patches from my 'gkernel' CVS at sourceforge. Instructions for anoncvs are on the SourceForge home page, near the bottom: http://sourceforge.net/projects/gkernel/ Check out module 'linux_2_2' or 'linux_2_4'. You --MUST-- use a branch tag when checking out. Branch tags are named based on kernel version, ie.: REL_2_4_1_ac11 REL_2_2_19_pre10 REL_2_4_2_pre3 Using CVS allows easy diff'ing of the full kernel > cvs -z9 rdiff -u -r REL_2_4_1_ac10 -r REL_2_4_1_ac11 linux_2_4 or just a part of the tree > cvs -z9 rdiff -u -r REL_2_4_1_ac10 -r REL_2_4_1_ac11 linux_2_4/drivers/net (as a side note, if you s/REL/hack/ in the above tag names, you get my public CVS tree...) Any questions, or anyone wanting my CVS import/merge scripts, just let me know. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
incremental patches for 2.4*-ac* kernels
Hi all, I think that most of us using modems begin to experience a little pain in downloading latest Alan's patches since they're becoming to be really big (and interesting). Since I have an occasionnal access to a system equipped with a good line, I began to make incremental patches for these kernels. These patches are about 60 kb instead of nearly 2 Mb. Those who are interested can download them from this url : http://www-miaif.lip6.fr/willy/pub/linux-patches/ac/ Of course, they are not signed nor official, and people who want to use them for production would better get them from the official sites. At the moment, only ac9-to-ac10 and ac10-to-ac12 are provided. To use them : - extract official linux-2.4.1 - apply one of Alan's patches (acXX) - apply one of these incremental patches (acXX-acYY) -> you'll get a 2.4.1-acYY Hope this will help people to test and report bugs. Cheers, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dropcopyright script
... ## drop copyright notices to the bottoms of C files in current dir and # subs. # /* # CopYriGHt Guess Who 2001All reserves righted. # */ grep -ilr "copyright" . > tempdropcopyrights for f in `cat tempdropcopyrights` do ed $f
Re: [UPDATE] zerocopy patch against 2.4.2-pre2
On Wed, Feb 14, 2001 at 12:27:10AM +1100, Andrew Morton wrote: > > It's getting very lonely testing this stuff. It would be useful if > someone else could help out - at least running the bw_tcp tests. It's > pretty simple: > > bw_tcp -s ; bw_tcp 0 OK, here's my bw_tcp results on a K6-2 450. I ran bw_tcp 10 times, then averaged the results. bw_tcp 2.4.2-pre3 57.0 2.4.2-pre3zc 52.6 -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PCI bridge handling 2.4.0-test10 -> 2.4.2-pre3
On Tue, 13 Feb 2001, Zink, Dan wrote: > Does it make sense to try and keep up with the latest and greatest in > chipsets > when there is a hardware independent way of doing things? You may be able > to > get information on current chipsets, but every time something changes, the > kernel may be broken for a time. If we rely on the BIOS, the kernel can > stay > out of the chipset information race. I understand the reluctance to depend > on BIOS in general but isn't it safe to say that systems using the > ServerWorks > chipsets in question are likely servers with a non-broken BIOS? > > I can tell you that if the BIOS doesn't report this stuff right on a > ProLiant > server, it would never make it out the door. It would break too many things > to go unnoticed. From this standpoint, the kernel is less likely to break > if > it relies on the BIOS rather than assuming some particular chipset design > that can easily change in the future. This is a fundamental reason for the > BIOS's existence. It's common knowledge that Linux is often better for hardware testing than Microsoft's pitiful ACT software. Intel and other companies have discovered hardware flaws that Linux exposes which all the Windows (and ACT) testing does not. (see early P4's...) Similarly, most BIOS out there work wonderfully with Windows but often have quirks with Linux. An overall policy of BIOS independence minimizes if not eliminates the chances of such quirks affecting Linux users. Getting a vendor to fix a broken BIOS is like trying to get a reluctant cow out of the barn: oftimes is just doesn't happen, especially if it is a Linux-only problem. Toshiba laptops have had broken ACPI tables for ages, but I have yet to see any BIOS updates regardless of the number of reports sent to Toshiba. Now, that said, in x86 land, we actually -do- allow the BIOS to setup the PCI bus for us, and for the most part, we leave that setup completely alone. grep for 'pcibios_assign_all_busses'... and note it is defined to zero for x86, and 1 for alpha. Finally, minimizing BIOS dependencies is also important for applications like linuxbios -- an embedded firmware that initializes the CPU and DRAM, and then passes control to a Linux kernel to do the rest. Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem: Floppy drive[?] hang
On Mon, 12 Feb 2001, C. D. Thompson-Walsh wrote: > [This sortof follows the format of the report form in REPORTING-BUGS] > 1. I've found a consistent set of circumstances which will hang 2.4.x kernels > on my system. > > 2. If the system is put under load to the point where it swaps heavily > (swapping appears to be pre-requisite, based on a little messing about), and > then given commands to use the floppy drive (mount, ls -- anything which > necessitates reading/writing to the floppy), it will hang with no message (it > does not OOPS, or at least it can not to the root console) I've done this > several times, with different disks and kernels, with and without X. Hi, I tried to reproduce this on my PIII-500 VIA chipset box and couldn't. (problem doesn't seem to be generic fwiw) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
> I was wondering why video drivers are not part of the kernel like every > other piece of hardware. I would think if video drivers were part of the > kernel and had a nice API for X or any other windowing system, would not > only improve performance but would allow competing windowing systems > without having to develop drivers for each. Has anyone thought or > rejected this idea. Yes. Problem is, X is a big old wad of code. It wasn't designed to run in a kernel environment. It isn't easy to rewrite, and getting rid of it isn't currently reasonable for normal desktop Linux systems. So then what, split X, with only the hardware access in the kernel? This can actually reduce performance, by a small or great amount depending on how it is done. Stability would improve a bit, assuming the new drivers have Linux quality rather than XFree86 quality. The gain is tiny, while the difficulty is large. At least we'd get a safe and reliable way to print an oops though. Both options could eat some memory. (but NOT anything like the VM size of an X server, much of which is the video memory itself) Putting the whole thing in the kernel does allow for memory pressure hooks though. Both options cause political troubles. Currently the X server is shared with OS/2 and other crummy systems. If the Linux kernel had serious video drivers for PC hardware, then driver support for the other operating systems would mostly go away. Linux would become a better desktop OS, at the expense of various crummy systems. Both options would tend to hurt people who like to leave X running on a low-memory web or NFS server. For a kernel X server, swapping must be done more-or-less explicitly. Both options cause more work for Linus. This totally kills the idea. See his past postings flaming the GGI/KGI developers. If you ever write this, go ahead and throw in the rest. I mean the window manager, xterm, and a GDK system call even. My hardware can spare the memory, but CPU cycles are way too scarce. Clean design can go screw itself when it eats CPU time. Don't worry about being accepted into the main kernel, because that won't happen no matter what you do. Have fun hacking, and whip XFree86's ass. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
On Tue, 13 Feb 2001, Louis Garcia wrote: > I was wondering why video drivers are not part of the kernel like every > other piece of hardware. See linux/drivers/video and linux/drivers/char/drm in kernel 2.4. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Destination Loose UDP in 2.4 (net/ipv4/netfilter)
What is the status of "dloose udp" in 2.4.x? From my reading in a few list archives it seems to have been some sort of a hack, yet it is needed for games such as Asheron's Call to be played behind a firewall. In 2.2.18 the code implementing this seems to be in net/ipv4/ip_masq.c and was controlled by a sysctl "ip_masq_udp_dloose". Is there anything in 2.4.x to replace this functionallity? Is there a way to replace it with an iptables rule? Any help would be much appreciated. -karl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
Martin, It looks like the numbers we picked for our respective IOCTLs conflict. I think I can change mine to the next higher since your patch seems to have been around longer. What is the general way to deal with these conflicts? -- Michael On 13 Feb 2001, Martin K. Petersen wrote: > > "Andries" == Andries Brouwer <[EMAIL PROTECTED]> writes: > > Andries> Anyway, an ioctl just to read the last sector is too silly. > Andries> An ioctl to change the blocksize is more reasonable. > > I actually sent you a patch implementing this some time ago, remember? > We need it for XFS... > > Patch against 2.4.2-pre3 follows. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
On Wed, 14 Feb 2001, Manfred Spraul wrote: > I have one additional user space only idea: > have you tried raw-io? bind a raw device to the partition, IIRC raw-io > is always in 512 byte units. That has been tried. No, it does not work. :-) Using Scsi-Generic is the only way so far found, but of course, it only works on SCSI drives. > > Probably an ioctl is the better idea, but I'd use absolute sector > numbers (not relative to the end), and obviously 64-bit sector numbers - > 2 TB isn't that far away. > I was deliberately trying to limit the scope to avoid misuse. This is to work around a flaw in the current API, not to create a new API. Limiting access to only those blocks that would normally be inaccessible through the normal API seemed like the best bet to me. -- Michael Brown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] starfire reads irq before pci_enable_device.
On 12 Feb 2001, Jes Sorensen wrote: > > "Donald" == Donald Becker <[EMAIL PROTECTED]> writes: > > Donald> On 9 Feb 2001, Jes Sorensen wrote: > >> The ia64 kernel has gotten mis aligned load support, but it's slow > >> as a dog so we really want to copy the packet every time anyway > >> when the header is not aligned. If people send out 802.3 headers or > >> other crap on Ethernet then it's just too bad. > > Donald> Note the word "required", meaning "must be done" > Donald> vs. "recommended" meaning "should be done". > > Donald> The initial issue was a comment in a starfire patch that > Donald> claimed an IA64 bug had been fixed. The copy breakpoint > Donald> change might have improved performance by doing a copy-align, > Donald> but it didn't fix a bug. > > I agree it was a bug, and yes it has been fixed. There was not a bug in the driver. The bug was/is in the protocol handling code. The protocol handling code *must* be able to handle unaligned IP headers. > Donald> That performance tradeoff was already anticipated: the > Donald> 'rx_copybreak' value that was changed was a module parameter, .. > In this case it just results in a performance degradation for 99% of > the usage. What about making the change so it is optimized away unless > IPX is enabled? ??? - It's not just IPX hosts that send 802.3 headers. - While a good initial value might depend on the architecture, the best setting is processor implementation and environment dependent. Those details are not known at compile time. - The code path cost of a module option is only a compare and a conditional branch. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with Ramdisk in linux-2.4.1
On Tue, 13 Feb 2001, Jaswinder Singh wrote: > > > > Can you point me to a cramfs generation procedure? (never used > > cramfs.. know where the docs are, but could use a small time warp) > > > > make ramdisk as you normally do and then compress it by gzip . Ok, it's not a cramfs. If you disable cramfs, it will likely work. There seems to be a (init order?) problem when cramfs is enabled. For instance, if I enable cramfs here, my minix gzipped initrd can not mount root.. kernel tries to use reiserfs instead for some unknown reason. I disable cramfs and all is well. Since the error message you posted seems to be from cramfs... -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bug in 2.4.x??
Hi
Well, it may not be a bug, but it sure is bugging me - i have been on this
for more than a week. Well, here goes;
Why is it that my DMA performance under the kernel 2.4.x is worse than the
one under 2.2? I have attached the stats below the mail- information and test
results under both kernels.
I use the following option under rc.local to set dma ;
/sbin/hdparm -c1 -d1 -m16 -X66 /dev/hda
I use resierfs, Iam disappointed that 2.4 results are about 1/3rd and need to
know what to do.
I use a i810 mobo and seagate 8.4 gb hdd
I have tried recompiling the kernel - iam informed a broken .config could
have caused this, but no change.
I have tried random settings with hdparm to tune /dev/hda.
Thanks for your time.
Ashwin
(Iam not on the list yet, so please cc me personally)
-
TEST RESULTS
___
a) Kernel 2.2.17 (mandrake)
(i) hdpartm -i:
/dev/hda:
Model=ST38420A, FwRev=3.07, SerialNo=7AZ0PTZT
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=512kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16841664
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2
(ii) hdpartm -t:
/dev/hda:
Timing buffered disk reads: 64 MB in 4.38 seconds = 14.61 MB/sec
b) Kernel 2.4.1 (linux )
(i) hdparm -i
/dev/hda:
Model=ST38420A, FwRev=3.07, SerialNo=7AZ0PTZT
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=512kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16841664
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2
(ii) hdparm -t
/dev/hda:
Timing buffered disk reads: 64 MB in 11.61 seconds = 5.51 MB/sec
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
On Tue, 13 Feb 2001, Louis Garcia wrote: > I was wondering why video drivers are not part of the kernel like every > other piece of hardware. I would think if video drivers were part of the > kernel and had a nice API for X or any other windowing system, would not > only improve performance but would allow competing windowing systems > without having to develop drivers for each. Has anyone thought or > rejected this idea. You should drop this subject as it will only result in flame wars. They have in the past and the result is always the same... 1) XFree86 is about the X window system. We don't give a damn about competing window systems. 2) There isn't a single API that can encompass all hardware. 3) Kernel drivers are OS specific things and XFree86 runs on too many platforms so we won't be able to abandon user-space drivers. At least not any time soon. That said, there are fbdev drivers for XFree86 and there are some hardware-specific solutions like NVIDIA's binary drivers. If you want to do something else, that's your perrogative. But don't waste your time trying to get everybody to agree with you. I won't happen. Sorry to be a bit abrupt, but there have been a few other discussions of this nature in the past and it's best that it doesn't go much further. At least not on XFree86 lists. Mark. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.1ac12 mkdep -I support - take 2
Get rid of the special case in drivers/acpi/Makefile. mkdep now uses
the same -I options in the same order as the compiler. Against 2.4.1ac12.
Change from take 1 - make is too dumb to realise that /path/name/file.h
is the same as file.h when current directory is /path/name, so do not
use the full pathname to files in the current directory.
--- 2.4.1-ac12/scripts/mkdep.c.orig Wed Feb 14 14:21:54 2001
+++ 2.4.1-ac12/scripts/mkdep.c Sun Feb 11 15:06:46 2001
@@ -221,15 +221,10 @@
char resolved_path[PATH_MAX+1];
const char *name2;
- if (strcmp(name, ".")) {
- name2 = realpath(name, resolved_path);
- if (!name2) {
- fprintf(stderr, "realpath(%s) failed, %m\n", name);
- exit(1);
- }
- }
- else {
- name2 = "";
+ name2 = realpath(name, resolved_path);
+ if (!name2) {
+ fprintf(stderr, "realpath(%s) failed, %m\n", name);
+ exit(1);
}
path_array = realloc(path_array, (++paths)*sizeof(*path_array));
@@ -246,7 +241,7 @@
exit(1);
}
strcpy(path->buffer, name2);
- if (path->len && *(path->buffer+path->len-1) != '/') {
+ if (*(path->buffer+path->len-1) != '/') {
*(path->buffer+path->len) = '/';
*(path->buffer+(++(path->len))) = '\0';
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.2-pre3 mkdep -I support - take 2
Get rid of the special case in drivers/acpi/Makefile. mkdep now uses
the same -I options in the same order as the compiler. Against 2.4.2-pre3.
Please jump up and down on this patch before I send it to Linus.
Change from take 1 - make is too dumb to realise that /path/name/file.h
is the same as file.h when current directory is /path/name, so do not
use the full pathname to files in the current directory.
Index: 2-pre3.1/scripts/mkdep.c
--- 2-pre3.1/scripts/mkdep.c Fri, 05 Jan 2001 13:42:29 +1100 kaos
(linux-2.4/12_mkdep.c 1.1 644)
+++ 2-pre3.4(w)/scripts/mkdep.c Wed, 14 Feb 2001 14:28:26 +1100 kaos
+(linux-2.4/12_mkdep.c 1.4 644)
@@ -2,7 +2,7 @@
* Originally by Linus Torvalds.
* Smart CONFIG_* processing by Werner Almesberger, Michael Chastain.
*
- * Usage: mkdep file ...
+ * Usage: mkdep cflags -- file ...
*
* Read source files and output makefile dependency lines for them.
* I make simple dependency lines for #include <*.h> and #include "*.h".
@@ -22,10 +22,17 @@
* 2.3.99-pre1, Andrew Morton <[EMAIL PROTECTED]>
* - Changed so that 'filename.o' depends upon 'filename.[cS]'. This is so that
* missing source files are noticed, rather than silently ignored.
+ *
+ * 2.4.2-pre3, Keith Owens <[EMAIL PROTECTED]>
+ * - Accept cflags followed by '--' followed by filenames. mkdep extracts -I
+ * options from cflags and looks in the specified directories as well as the
+ * defaults. Only -I is supported, no attempt is made to handle -idirafter,
+ * -isystem, -I- etc.
*/
#include
#include
+#include
#include
#include
#include
@@ -44,11 +51,10 @@ int hasdep;
struct path_struct {
int len;
- char buffer[256-sizeof(int)];
-} path_array[2] = {
- { 0, "" },
- { 0, "" }
+ char *buffer;
};
+struct path_struct *path_array;
+int paths;
/* Current input file */
@@ -181,9 +187,10 @@ void define_precious(const char * filena
/*
* Handle an #include line.
*/
-void handle_include(int type, const char * name, int len)
+void handle_include(int start, const char * name, int len)
{
- struct path_struct *path = path_array+type;
+ struct path_struct *path;
+ int i;
if (len == 14 && !memcmp(name, "linux/config.h", len))
return;
@@ -191,13 +198,58 @@ void handle_include(int type, const char
if (len >= 7 && !memcmp(name, "config/", 7))
define_config(name+7, len-7-2);
- memcpy(path->buffer+path->len, name, len);
- path->buffer[path->len+len] = '\0';
- if (access(path->buffer, F_OK) != 0)
- return;
+ for (i = start, path = path_array+start; i < paths; ++i, ++path) {
+ memcpy(path->buffer+path->len, name, len);
+ path->buffer[path->len+len] = '\0';
+ if (access(path->buffer, F_OK) == 0) {
+ do_depname();
+ printf(" \\\n %s", path->buffer);
+ return;
+ }
+ }
- do_depname();
- printf(" \\\n %s", path->buffer);
+}
+
+
+
+/*
+ * Add a path to the list of include paths.
+ */
+void add_path(const char * name)
+{
+ struct path_struct *path;
+ char resolved_path[PATH_MAX+1];
+ const char *name2;
+
+ if (strcmp(name, ".")) {
+ name2 = realpath(name, resolved_path);
+ if (!name2) {
+ fprintf(stderr, "realpath(%s) failed, %m\n", name);
+ exit(1);
+ }
+ }
+ else {
+ name2 = "";
+ }
+
+ path_array = realloc(path_array, (++paths)*sizeof(*path_array));
+ if (!path_array) {
+ fprintf(stderr, "cannot expand path_arry\n");
+ exit(1);
+ }
+
+ path = path_array+paths-1;
+ path->len = strlen(name2);
+ path->buffer = malloc(path->len+1+256+1);
+ if (!path->buffer) {
+ fprintf(stderr, "cannot allocate path buffer\n");
+ exit(1);
+ }
+ strcpy(path->buffer, name2);
+ if (path->len && *(path->buffer+path->len-1) != '/') {
+ *(path->buffer+path->len) = '/';
+ *(path->buffer+(++(path->len))) = '\0';
+ }
}
@@ -210,7 +262,7 @@ void use_config(const char * name, int l
char *pc;
int i;
- pc = path_array[0].buffer + path_array[0].len;
+ pc = path_array[paths-1].buffer + path_array[paths-1].len;
memcpy(pc, "config/", 7);
pc += 7;
@@ -228,7 +280,7 @@ void use_config(const char * name, int l
define_config(pc, len);
do_depname();
- printf(" \\\n $(wildcard %s.h)", path_array[0].buffer);
+ printf(" \\\n $(wildcard %s.h)", path_array[paths-1].buffer);
}
@@ -387,7 +439,7 @@ pound_include_dquote:
GETNEXT
CASE('\n', start);
NOTCASE('"', pound_include_dquote);
- handle_include(1, map_dot, next - map_dot - 1);
+
Video drivers and the kernel
I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. Anyway, This was running though my head for a long time and just thought I ask. Lou - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19pre10 doesn't compile on alphas (sunrpc)
On Mon, Feb 12, 2001 at 02:33:17PM -0800, David S. Miller wrote: > You have to add a few bits to arch/alpha/kernel/traps.c > I could be wrong though... Only to make the oops look pretty. Something like die_if_kernel((type == 1 ? "Kernel Bug" : "Instruction fault"), , type, 0); Don't have a 2.2 tree handy to look at the moment... r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] swapin flush cache bug
Alan Cox wrote: > Ok we need to handle that case a bit more intelligently so those flushes dont > get into other ports code paths. Possibly at fs/buffer.c:end_buffer_io_async? We need to flush the cache when I/O was READ or READA. Is there any way for end_buffer_io_async to distinguish which I/O (READ or WRITE) has been done? -- Problem with write-back cache. (1) Page got swapped out Swap out [ Disk ] < P [ Page ] (2) Page got swapped in asynchronously, possibly by read-ahead Swap in [ Disk ] > P [ Page ] K The I/O from disk goes through kernel virtual address K. We have cache entries indexed by K. (3) Page fault occurs at user space U [ Disk ] P [ Page ] <- U K The control goes to do_swap_page, found the page at lookup_swap_cache. If K and U indexes differently, we have cache alias issues, we need to flush the entries indexed by K. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] starfire reads irq before pci_enable_device.
On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]> wrote: > On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik ><[EMAIL PROTECTED]> wrote: > >> On 12 Feb 2001, Jes Sorensen wrote: >>> In fact one has to look out for this and disable the feature in some >>> cases. On the acenic not disabling Memory Write and Invalidate costs >>> ~20% on performance on some systems. >> >> And in another message, On Mon, 12 Feb 2001, David S. Miller wrote: >>> 3) The acenic/gbit performance anomalies have been cured >>>by reverting the PCI mem_inval tweaks. >> >> Just to be clear, acenic should or should not use MWI? With the zerocopy patch, acenic always disables MWI by default. >> And can a general rule be applied here? Newer Tulip hardware also >> has the ability to enable/disable MWI usage, IIRC. > > And so do eepro100 and starfire. On the eepro100 we're enabling MWI > unconditionally, and on the starfire we disable it unconditionally... > > I should probably take a look at acenic's use of PCI_COMMAND_INVALIDATE > to see when it gets activated. Some benchmarking would probably help, > too -- maybe later today. I did some testing with starfire, and the results are inconclusive -- at least on my P-III is makes absolutely no difference. Does it make a difference on other architectures? sparc64, ia64 maybe? I should probably rephrase this: MWI makes no difference on i386, but it is claimed that using MWI *reduces* performance on some systems. Are there any systems on which MWI *increases* performance? I've added some code to the starfire driver that allows changing the use of MWI at module load time, just in case. By default, it activates it. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Driver for Casio Cassiopia Fiva touchscreen, help with conversionto 2.4
Available at http://people.redhat.com/~sopwith/fidmour-linux.c is a driver for the touch screen used on the Cassiopia Fiva MPC-501 pen computer. It is a rather Bad Hack (seeing as it was built rather blindly to mimic the behaviour of the Windows driver, and has IRQ/port hardcoded in), but it works for me with the 2.2.16 kernel. The device outputs 5 byte packets - 1 status byte, 2 bytes each for X & Y coordinates. The devel branch of GTK+ has support for /dev/fidmour in the Linux framebuffer backend (gtk+/gdk/linux-fb/gdkmouse-fb.c), should you wish to see a code sample. I'm wondering if anyone has a resource that would provide information on porting this driver to the 2.4 kernel. I would welcome comments on this driver, or on the MPC-501 and Linux in general. Bonus points to anyone who actually understands why the driver works and how the hardware works. :) Hope this helps, -- Elliot Who me? I just wander from room to room. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] starfire reads irq before pci_enable_device.
On 12 Feb 2001, Jes Sorensen wrote: > Ion> Yes, but I'd rather let people turn off the always-copy behavior > Ion> by simply changing rx_copybreak. The unused code is not really > Ion> that much of a deal, it's only a few lines. > > However, it is in the hot path code where it hurts the most. I couldn't measure any difference, really. And for one extra branch, I really wouldn't expect a measurable difference.. Not even defining final_version, which removes a *lot* more conditional branches from the hot path, makes any measurable difference in the CPU utilization. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: block ioctl to read/write last sector
> > While we can read and write to this sector in the kernel
> > partition code, we have
> > no way for userspace to update this partition block.
>
> Are you sure?
I'm not sure, but when I asked about this in January, I suggested having an
IOCTL that get/set blksize_size[MAJOR(dev)][MINOR(dev)], which didn't seem
to work for me.
> I need to read/write the last 512-byte
> sector on an odd-sized disk (IDE and/or SCSI) from user space. Employing
> suggestions from you and l-k, I have implemented two IOCTLs that get/set
the
> blksize_size[MAJOR(dev)][MINOR(dev)] values (via set_blocksize()). In my
> application, I read the hardsector size of a disk device (/dev/sdb) via an
> IOCTL, read the current blksize_size, set it to the hardsector size, and
> then continue, resetting blksize_size back to the original value when
done.
>
> In between, I use fopen64() to open the device /dev/sdb (an odd-sized
disk),
> and lseek64()/fwrite64()/fread64() to write/read the last sector of the
disk
> as reported by the BLKGETSIZE ioctl. The seek succeeds, however, the
> reads/writes fail. Writes fail with "No space left on device". Read
> returns 0, indicating EOF. If I read/write the N-1th sector this way, it
> works just fine. On even-sized disks, this succeeds both with and
> without calling my new IOCTLs, as expected. On odd-sized disks, it
> fails in both cases.
Anton Altaparmakov responded:
> I am sure Andries will correct me if I am wrong but here is
> what I think of the situation at present:
>
> I suspect that you will find the problem in
> linux/fs/block_dev.c functions
> block_write() and block_read() which AFAIK only get called
> when you use
> usermode to read a /dev/* blockdevice as you probably are
> doing. From the
> kernel these functions AFAIK never get called and hence the problem
> doesn't exist (either way I am surprised that it works as looking at
> generic_make_request() there is a check of simillar type and AFAICS it
> would fail as well for the same reason. I probably don't understand
> something there and/or generic_make_request() is not being
> called either,
> as it obviously works, since you have tried it).
>
> In block_write() you find this (lines 58ff in the file in 2.4.0):
> [snip]
> if (blk_size[MAJOR(dev)])
> size = ((loff_t) blk_size[MAJOR(dev)][MINOR(dev)] <<
> BLOCK_SIZE_BITS) >> blocksize_bits;
> else
> size = INT_MAX;
> while (count>0) {
> if (block >= size)
> return written ? written : -ENOSPC;
> [snip]
>
> As you can see when size is calculated blk_size is multiplied
> by 1024 and
> then divided by 512, effectively blk_size is multiplied by 2.
>
> The effect of this is that size has the lowest bit always
> equal to zero
> and hence it always will be even.
>
> The subsequent check "if (block >= size)" of course is then
> true and we
> return with -ENOSPC straight away.
>
> In block_read() you find this (lines 195ff in the file in 2.4.0):
> [snip]
> if (blk_size[MAJOR(dev)])
> size = (loff_t) blk_size[MAJOR(dev)][MINOR(dev)] <<
> BLOCK_SIZE_BITS;
> else
> size = (loff_t) INT_MAX << BLOCK_SIZE_BITS;
>
> if (offset > size)
> left = 0;
> [snip]
> if (left <= 0)
> return 0;
> [snip]
>
> And again size is equal to blk_size multiplied by 1024 and
> hence always
> will be even.
If this analysis is correct (and I think it is), changing the block size
doesn't actually solve the problem.
I've got no problems requiring any IOCTL (either block-size-changing or just
a read/write last sector) to check that a device isn't in use somehow prior
to making these calls. Changing a disk's partition table while partitions
are actively in use on it isn't generally a good idea. But, fdisk and other
partition table-changing apps don't do this kind of check now IIRC.
Thanks,
Matt
--
Matt Domsch
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
> "Andries" == Andries Brouwer <[EMAIL PROTECTED]> writes:
Andries> Anyway, an ioctl just to read the last sector is too silly.
Andries> An ioctl to change the blocksize is more reasonable.
I actually sent you a patch implementing this some time ago, remember?
We need it for XFS...
Patch against 2.4.2-pre3 follows.
--
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
[EMAIL PROTECTED], http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/
diff -urN linux/arch/mips64/kernel/ioctl32.c linux-blksetsize/arch/mips64/kernel/ioctl32.c
--- linux/arch/mips64/kernel/ioctl32.c Wed Nov 29 00:42:04 2000
+++ linux-blksetsize/arch/mips64/kernel/ioctl32.c Tue Feb 13 14:15:20 2001
@@ -712,6 +712,7 @@
IOCTL32_HANDLER(BLKPG, blkpg_ioctl_trans),
IOCTL32_DEFAULT(BLKELVGET),
IOCTL32_DEFAULT(BLKELVSET),
+ IOCTL32_DEFAULT(BLKSETSIZE),
IOCTL32_DEFAULT(MTIOCTOP), /* mtio.h ioctls */
IOCTL32_HANDLER(MTIOCGET32, mt_ioctl_trans),
diff -urN linux/arch/sparc64/kernel/ioctl32.c linux-blksetsize/arch/sparc64/kernel/ioctl32.c
--- linux/arch/sparc64/kernel/ioctl32.c Tue Feb 13 14:12:17 2001
+++ linux-blksetsize/arch/sparc64/kernel/ioctl32.c Tue Feb 13 14:15:20 2001
@@ -3107,6 +3107,7 @@
COMPATIBLE_IOCTL(BLKFRASET)
COMPATIBLE_IOCTL(BLKSECTSET)
COMPATIBLE_IOCTL(BLKSSZGET)
+COMPATIBLE_IOCTL(BLKSETSIZE)
/* RAID */
COMPATIBLE_IOCTL(RAID_VERSION)
diff -urN linux/drivers/block/blkpg.c linux-blksetsize/drivers/block/blkpg.c
--- linux/drivers/block/blkpg.c Fri Oct 27 02:35:47 2000
+++ linux-blksetsize/drivers/block/blkpg.c Tue Feb 13 14:15:20 2001
@@ -208,6 +208,7 @@
int blk_ioctl(kdev_t dev, unsigned int cmd, unsigned long arg)
{
int intval;
+ long longval;
switch (cmd) {
case BLKROSET:
@@ -258,6 +259,22 @@
longval = g->part[MINOR(dev)].nr_sects;
return put_user(longval, (long *) arg);
#endif
+ case BLKSETSIZE:
+ /* Can be used to set block size from userland. */
+ if(!capable(CAP_SYS_ADMIN))
+return -EACCES;
+
+ if(!dev || !arg)
+return -EINVAL;
+
+ if (get_user(longval, (int *)(arg)))
+return -EFAULT;
+
+ if (longval > PAGE_SIZE || longval < 512 || (longval & (longval-1)))
+return -EINVAL;
+
+ set_blocksize(dev, longval);
+ return 0;
#if 0
case BLKRRPART: /* Re-read partition tables */
if (!capable(CAP_SYS_ADMIN))
diff -urN linux/drivers/ide/ide.c linux-blksetsize/drivers/ide/ide.c
--- linux/drivers/ide/ide.c Tue Feb 13 14:12:23 2001
+++ linux-blksetsize/drivers/ide/ide.c Tue Feb 13 14:15:20 2001
@@ -2672,6 +2672,7 @@
case BLKPG:
case BLKELVGET:
case BLKELVSET:
+ case BLKSETSIZE:
return blk_ioctl(inode->i_rdev, cmd, arg);
default:
diff -urN linux/drivers/md/lvm.c linux-blksetsize/drivers/md/lvm.c
--- linux/drivers/md/lvm.c Sun Jan 28 19:11:20 2001
+++ linux-blksetsize/drivers/md/lvm.c Tue Feb 13 14:15:20 2001
@@ -910,6 +910,8 @@
return -EFAULT;
break;
+ case BLKSETSIZE:
+ return blk_ioctl(inode->i_rdev, command, a);
case BLKFLSBUF:
/* flush buffer cache */
diff -urN linux/drivers/md/md.c linux-blksetsize/drivers/md/md.c
--- linux/drivers/md/md.c Tue Feb 13 14:12:24 2001
+++ linux-blksetsize/drivers/md/md.c Tue Feb 13 14:15:20 2001
@@ -2511,6 +2511,9 @@
(long *) arg);
goto done;
+ case BLKSETSIZE:
+ return blk_ioctl(dev, cmd, (long *) arg);
+
case BLKFLSBUF:
fsync_dev(dev);
invalidate_buffers(dev);
diff -urN linux/drivers/scsi/sd.c linux-blksetsize/drivers/scsi/sd.c
--- linux/drivers/scsi/sd.c Tue Feb 13 14:12:32 2001
+++ linux-blksetsize/drivers/scsi/sd.c Tue Feb 13 14:15:21 2001
@@ -234,6 +234,7 @@
case BLKPG:
case BLKELVGET:
case BLKELVSET:
+case BLKSETSIZE:
return blk_ioctl(inode->i_rdev, cmd, arg);
case BLKRRPART: /* Re-read partition tables */
diff -urN linux/include/linux/fs.h linux-blksetsize/include/linux/fs.h
--- linux/include/linux/fs.h Tue Feb 13 14:12:42 2001
+++ linux-blksetsize/include/linux/fs.h Tue Feb 13 14:15:21 2001
@@ -181,6 +181,7 @@
#define BLKSECTSET _IO(0x12,102)/* set max sectors per request (ll_rw_blk.c) */
#define BLKSECTGET _IO(0x12,103)/* get max sectors per request (ll_rw_blk.c) */
#define BLKSSZGET _IO(0x12,104)/* get block device sector size */
+#define BLKSETSIZE _IO(0x12,108)/* set device block size */
#if 0
#define BLKPG _IO(0x12,105)/* See blkpg.h */
#define BLKELVGET _IOR(0x12,106,sizeof(blkelv_ioctl_arg_t))/* elevator get */
Re: strange bug, alloca suspected
On Tue, 13 Feb 2001 22:10:27 +0100,
Yann Droneaud <[EMAIL PROTECTED]> wrote:
>Modprobe don't use alloca() correctly, then glibc failed. (stack corruption ?)
>This mail is sent to glibc, gcc and modutils maintainers.
Thanks, modutils bug, not a glibc problem. Against modutils 2.4.2.
Index: 3.2/insmod/modprobe.c
--- 3.2/insmod/modprobe.c Fri, 19 Jan 2001 17:26:33 +1100 kaos
(modutils-2.4/b/10_modprobe.c 1.2 644)
+++ 3.2(w)/insmod/modprobe.c Wed, 14 Feb 2001 11:39:38 +1100 kaos
+(modutils-2.4/b/10_modprobe.c 1.2 644)
@@ -1503,7 +1503,7 @@ int main(int argc, char *argv[])
{"help", 0, 0, 'h'},
{0, 0, 0, 0}
};
- int i, l = 0;
+ int i, l = 1;
char *command;
for (i = 0; i < argc; ++i)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19pre10 locks up hard on unloading the isdn module 'hisax.o'
On Tue, 13 Feb 2001 [EMAIL PROTECTED] wrote:
> SMP machine, 2x P3/700 on an Abit VP6.
> Never any trouble with the earlier 2.2.19pre's.
>
> a strace shows the hang to be in the delete_module("hisax") call.
I got another report of the same problem already. I'll try to sort it out
tomorrow.
What does "ps axwll" say for the rmmod process?
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Crash in request_region while handling kernel parameters
Hello kernel-hackers, I found a problem with kernel 2.4, that makes the kernel crash at bootup, for example when using the UMC8672 VLB IDE controller driver. The problem is in kernel/resource.c. In line 229 some memory for handling new io-regions is kmalloc()ed. This crashes the computer before mem_init(), as it seems. But some drivers, for example the above mentioned one in drivers/ide/umc8672.c, do already claim i/o ports in their kernel parameter driven initialization procedures, so they crash the system. The point to discuss is whether one needs to fix the drivers, to not request i/o space while handling kernel parameters or to fix the kernel to allow this behaviour. As I do not read this mailing list, a currently don't have web access ready, I don't know whether this topic has already been discussed. Currently I helped myself by just commenting out the calls for check_region and request_region in the umc8672.c file, but I know it smells. Please send me a cc if you think you have a decision how to fix the crash. Michael Karcher - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
Michael E Brown wrote: > > > > > Anyway, an ioctl just to read the last sector is too silly. > > An ioctl to change the blocksize is more reasonable. > > That may be better, I don't know. That's why this is an RFC. Are there any > possible races with that method? It seems to me that you might adversely > affect io in progress by changing the blocksize. The method demonstrated > in this patch shouldn't do that. > block size changing is dangerous: if you change the blocksize of a mounted partition you'll disrupt the filesystem. some kernels crash hard if you execute swapon /dev/ swapon won't overwrite your root fs: it changes the blocksize to 4kB and then notices that there is no swap signature. But the blocksize change is fatal. > > And I expect that this fixed blocksize will go soon. > that's 2.5. > That may be, I don't know that much about the block layer. All I know is > that, with the current structure, I cannot read or write to sectors where > (sector #) > total-disk-blocks - (total-disk-blocks / > (softblocksize/hardblocksize)) > I have one additional user space only idea: have you tried raw-io? bind a raw device to the partition, IIRC raw-io is always in 512 byte units. Probably an ioctl is the better idea, but I'd use absolute sector numbers (not relative to the end), and obviously 64-bit sector numbers - 2 TB isn't that far away. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test, please ignore
ok, for those who didn't ignore :) trying to correct a misconfigured MTA that made vger barf. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac12 -- SMP build for Athlon still broken -- hw_irq.h:198: `current' undeclared
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686 -malign-functions=4-c -o init/main.o init/main.c /usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile': In file included from /usr/src/linux/include/linux/irq.h:57, from /usr/src/linux/include/asm/hardirq.h:6, from /usr/src/linux/include/linux/interrupt.h:45, from /usr/src/linux/include/asm/string.h:296, from /usr/src/linux/include/linux/string.h:25, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use in this function) /usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is reported only once /usr/src/linux/include/asm/hw_irq.h:198: for each function it appears in.) /usr/src/linux/include/linux/interrupt.h: In function `raise_softirq': In file included from /usr/src/linux/include/asm/string.h:296, from /usr/src/linux/include/linux/string.h:25, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/linux/interrupt.h:89: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_schedule': /usr/src/linux/include/linux/interrupt.h:160: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_hi_schedule': /usr/src/linux/include/linux/interrupt.h:174: `current' undeclared (first use in this function) /usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d': In file included from /usr/src/linux/include/linux/string.h:25, from /usr/src/linux/include/linux/fs.h:23, from /usr/src/linux/include/linux/capability.h:17, from /usr/src/linux/include/linux/binfmts.h:5, from /usr/src/linux/include/linux/sched.h:9, from /usr/src/linux/include/linux/mm.h:4, from /usr/src/linux/include/linux/slab.h:14, from /usr/src/linux/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux/include/asm/string.h:305: `current' undeclared (first use in this function) /usr/src/linux/include/asm/string.h: In function `__memcpy3d': /usr/src/linux/include/asm/string.h:312: `current' undeclared (first use in this function) make: *** [init/main.o] Error 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OPPS] 2.2.18
On Linux version 2.2.18 (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) i got Unable to handle kernel paging request at virtual address 74723e0a current->tss.cr3 = 0353d000, %cr3 = 0353d000 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010816 eax: ebx: 0001 ecx: edx: esi: c0230940 edi: 0286 ebp: 74723e0a esp: c54a3f70 ds: 0018 es: 0018 ss: 0018 Process find (pid: 5346, process nr: 52, stackpage=c54a3000) Stack: 0805ba70 0805ba84 0202 c012b409 c54a2000 b980 0805ba70 b8b8 c012b974 0805ba84 c54a2000 b980 c0129a4e 0805ba84 c54a2000 b980 c0109374 0805ba84 b860 0805770c Call Trace: [] [] [] [] Code: 8b 45 00 89 06 89 70 04 89 e8 2b 05 4c 66 20 c0 8d 04 40 89 ksymoops 2.3.4 on i686 2.2.18. Options used -v /home/mistral/data/kernels/P200/vmlinux (specified) -K (specified) -l /proc/modules (default) -o /lib/modules/2.2.18/ (default) -m /boot/System.map (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel paging request at virtual address 74723e0a current->tss.cr3 = 0353d000, %cr3 = 0353d000 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010816 eax: ebx: 0001 ecx: edx: esi: c0230940 edi: 0286 ebp: 74723e0a esp: c54a3f70 ds: 0018 es: 0018 ss: 0018 Process find (pid: 5346, process nr: 52, stackpage=c54a3000) Stack: 0805ba70 0805ba84 0202 c012b409 c54a2000 b980 0805ba70 b8b8 c012b974 0805ba84 c54a2000 b980 c0129a4e 0805ba84 c54a2000 b980 c0109374 0805ba84 b860 0805770c Call Trace: [] [] [] [] Code: 8b 45 00 89 06 89 70 04 89 e8 2b 05 4c 66 20 c0 8d 04 40 89 >>EIP; c0121c2e <__get_free_pages+102/2b4> <= Trace; c012b409 Trace; c012b974 <__namei+c/58> Trace; c0129a4e Trace; c0109374 Code; c0121c2e <__get_free_pages+102/2b4> <_EIP>: Code; c0121c2e <__get_free_pages+102/2b4> <= 0: 8b 45 00 mov0x0(%ebp),%eax <= Code; c0121c31 <__get_free_pages+105/2b4> 3: 89 06 mov%eax,(%esi) Code; c0121c33 <__get_free_pages+107/2b4> 5: 89 70 04 mov%esi,0x4(%eax) Code; c0121c36 <__get_free_pages+10a/2b4> 8: 89 e8 mov%ebp,%eax Code; c0121c38 <__get_free_pages+10c/2b4> a: 2b 05 4c 66 20 c0 sub0xc020664c,%eax Code; c0121c3e <__get_free_pages+112/2b4> 10: 8d 04 40 lea(%eax,%eax,2),%eax Code; c0121c41 <__get_free_pages+115/2b4> 13: 89 00 mov%eax,(%eax) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lost charaters -- this is becoming annoying!
Hi Tigran, > PS. This only happens on this Dell latitude CPx (notice lost shift in > Latitude?) H450GT. I have a Dell Latitude CPx as well and I keep losing caps lock keypresses. I'm running a 2.2.18 kernel. It's very annoying since I have control mapped to caps lock. I suspected that my keyboard was crappy. Maybe not? Ulf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stale NFS handles on 2.4.1
> " " == stergaard writes: > What happens is that one machine will finish compiling, and > another machine will immediately thereafter do a "touch > some_output.o". This "touch" sometimes fails with a stale > handle message. Does the appended patch change anything? Cheers, Trond --- linux-2.4.1/fs/nfs/inode.c.orig Tue Dec 12 02:46:04 2000 +++ linux-2.4.1/fs/nfs/inode.c Wed Feb 14 01:00:33 2001 @@ -100,6 +100,7 @@ inode->i_rdev = 0; NFS_FILEID(inode) = 0; NFS_FSID(inode) = 0; + NFS_FLAGS(inode) = 0; INIT_LIST_HEAD(>u.nfs_i.read); INIT_LIST_HEAD(>u.nfs_i.dirty); INIT_LIST_HEAD(>u.nfs_i.commit); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] swapin flush cache bug
Russell King wrote: > Unless someone else (Rik/DaveM) says otherwise, it is my understanding > that any IO for page P will only ever be a write to disk. Therefore, > when you get a copy of the page from the swap cache, the physical memory > for that page is the same as it was when the process was using it last. [...] > The data from memory will still be up to date though. However, I agree > that you will end up with cache aliases. I will also end up with cache > aliases. The question now is, do these aliases really matter? > > On my caches, the answer is no because they're not marked dirty, and > therefore will get dropped from the cache without writeback to memory. > > If your cache doesn't write back clean cache data to memory, then you > should also behave well. Yes, that's the difference. It's write back cache, in my case. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
From [EMAIL PROTECTED] Wed Feb 14 00:37:25 2001 > Look at the addpart utility in the util-linux package. > It will allow you to add a partition disjoint from > previously existing partitions. > And since a partition can start on an odd sector, > this should allow you to also read the last sector. > > Do I overlook something? Yes. The addpart utility just uses the block-layer ioctls to dynamically add and/or remove partitions. What this is doing is just adjusting the kernel's idea of what the current partition scheme is. This has _nothing_ to do with actually reading or writing data from the disk. But it changes the idea of odd and even. A partition can start on an odd sector. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.2-pre3: parport_pc init_module bug
Linus,
Here's a patch that fixes a bug that can cause PCI driver list
corruption. If parport_pc's init_module fails after it calls
pci_register_driver, cleanup_module isn't called and so it's still
registered when it gets unloaded.
Tim.
*/
2001-01-13 Tim Waugh <[EMAIL PROTECTED]>
* parport_pc.c: Fix PCI driver list corruption on
unsuccessful module load (Andrew Morton).
--- linux/drivers/parport/parport_pc.c.init Tue Feb 13 23:31:25 2001
+++ linux/drivers/parport/parport_pc.c Tue Feb 13 23:35:56 2001
@@ -89,6 +89,7 @@
} superios[NR_SUPERIOS] __devinitdata = { {0,},};
static int user_specified __devinitdata = 0;
+static int registered_parport;
/* frob_control, but for ECR */
static void frob_econtrol (struct parport *pb, unsigned char m,
@@ -2605,6 +2606,7 @@
count += parport_pc_find_nonpci_ports (autoirq, autodma);
r = pci_register_driver (_pc_pci_driver);
+ registered_parport = 1;
if (r > 0)
count += r;
@@ -2667,6 +2669,7 @@
/* Work out how many ports we have, then get parport_share to parse
the irq values. */
unsigned int i;
+ int ret;
for (i = 0; i < PARPORT_PC_MAX_PORTS && io[i]; i++);
if (i) {
if (parport_parse_irqs(i, irq, irqval)) return 1;
@@ -2691,7 +2694,11 @@
}
}
- return !parport_pc_init (io, io_hi, irqval, dmaval);
+ ret = !parport_pc_init (io, io_hi, irqval, dmaval);
+ if (ret && registered_parport)
+ pci_unregister_driver (_pc_pci_driver);
+
+ return ret;
}
void cleanup_module(void)
*** linux/drivers/parport/ChangeLog.initFri Jan 5 10:41:52 2001
--- linux/drivers/parport/ChangeLog Tue Feb 13 23:32:02 2001
***
*** 0
--- 1,7
+ 2001-02-13 Andrew Morton <[EMAIL PROTECTED]>
+
+ * parport_pc.c (registered_parport): New static variable.
+ (parport_pc_find_ports): Set it when we register PCI driver.
+ (init_module): Unregister PCI driver if necessary when we
+ fail.
+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre2 ext2fs corruption
> sorry. intel piii, with an adaptec AHA-294X Ultra2 scsi adapter. the > disk in question is a 9gb IBM disk Model: DNES-309170W Rev: SA30. is > this what you need? do you need more? Thanks. Added to my collection of data, doesnt tally with other corruption reports (other aic7xxx reports with the older driver in the non-ac tree are of the it doesnt work/hung variety) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stale NFS handles on 2.4.1
On Tue, Feb 13, 2001 at 11:31:50PM +, Alan Cox wrote:
> > The NFS clients are getting
> > "Stale NFS handle"
> > messages every once in a while which will make a "touch somefile.o"
> > fail.
>
> If they have the previous .o handle cached and it was removed on another
> client thats quite reasonable behaviour. NFS isnt coherent
So a solution would be to
rm -f output.o
g++ -o output.o
touch output.o
I do the touch in the first place because a subsequent link job on
another remote node used to fail if I didn't. NFS caching magic I guess...
>
> > It's quite annoying and I didn't see it on 2.2 even after the NFS
> > patches were integrated.
>
> I wonder if its because 2.4 runs faster and caches better 8). You can
> tune the attribute cache times that may help. Are we talking 30 second
> intervals here or stuff being cached for far too long (which would imply a bug)
It runs faster indeed, and it makes the work more fun and makes the
internet go faster ! (uhhh... or maybe the internet speedup is because
of the Intel CPUs - I forgot...)
Usually how a compile goes is:
a make -j10 spawns concurrent compile jobs. Each job consists of
"spawn on remote node" g++ ... -o somefile.o
"on local node" touch somefile.o
After a truckload of .o files have been generated, it will start
up link jobs, on other remote nodes. I haven't tried this without
the touch trick for a long time.
Each g++ job takes from a few seconds to several minutes depending
on the file and optimization options etc. I think I mainly see this
with the fast jobs... Most .o files are ~1-4 MB and I have about 200
of them.
~200 compilers and ~12 linkers take about 4-5 minutes to complete on
the cluster of three dual machines and two-three single cpus. Producing
about 1.5G of object code in total (yes C++ symbols are HUGE).
So, the touch is _immediately_ after a compile completion. But the
.o file has not been in use on any other machine than the one running
the compiler for hours or at least many minutes (a different compile).
I'll try this without the touch trick and see how things fare...
--
: [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]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.1ac12
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.1-ac12 o Make tmpfs use link counts of 2 on directories (Christoph Rohland) o Update Documentation/sound/Introductions(Wade Hampton) o Fix bug in new tlb shootdown code (Ben LaHaise) o Add isa_* api to the Alpha (Richard Henderson) o Export down_trylock on Alpha(Richard Henderson) o Fix maestro3 build on ia64 (Bill Nottingham) 2.4.1-ac11 o Hack the setup code to do the right thing for (me) Cyrix processors. Cpuid on cyrix should now work o Change sigmatel codec inits (Jeff Garzik) o Revised TLB shootdown patch (Ben LaHaise) o Use pci quirks to handle the nonstandard irq(Andrey Panin) setup for VIA ACPI o If a user sets an io on the opl3sa2 assume they (me) mean it even if isapnp isnt turned off o Fix xmms cpu burn on i810 audio (Marcus Sundberg) o Fix pnic problems with tulip driver (Manfred Spraul) o Add pci skeleton driver (Jeff Garzik) o Fix vfat mishandling of 16bit characters(Kazuki Yasumatsu) o Fix syntax things found by his source code (Jean-Luc Leger) analyser o Fix pcmcia ixj build bug(Florian) o Remove dead via sound docs (Jeff Garzik) o add __dev_alloc_skb for drivers needing to force(Jeff Garzik) allocation types o Fix arcnet initializers (Jeff Garzik) o Fix various warnings(Keith Owens) o Further MPT fusion updates (Steve Ralston) o sock_alloc_send_skb fix (Manfred Spraul) o Fix signed/unsigned handling on 8139too (Jeff Garzik) o Document problem with old powertweak(Dave Jones) o s/controler/controller/ spelling fixes o S/390 build fixes (Neale Ferguson) 2.4.1-ac10 o Merge with Linus 2.4.2pre3 o More net driver clean up(Jeff Garzik) o Further maxiradio fix (Francois Romieu) o Lock reclaiming fixes (MCL) o Update ver_linux(Steven Cole) o Add support for the Socket LP-E CF+ ethernet(Nicolas Pitre) o Fix microtek scanner abort handling (Oliver Neukum) o Fix very dumb bug in my dma.c changes that (me) Linus noticed o Clean up AGP alloc/destroy a little (me) | Again a Linus request o Remove dead 8129 config help(Dave Jones) o Clean up extra unneeded check in setup.c(Dave Jones) o Improve mkdep, remove acpi special case (Keith Owens) o Fix bogus dead comment in fs.h (Jens Axboe) o Clean up config.in syntax errors(Christoph Hellwig) o Offer Duron in CPU option list for clarity (Terje Rosten) o New binutils need --oformat, old ones handle it (Andreas Jaeger) o Move bitops include in fs.h inside __KERNEL__ (Herbert Xu) o Fix misspellings of weird (Felix Odenkirchen) o Fix typos of 'valid' while we are at it (Luuk van der Duim) 2.4.1-ac9 o Merge with Linus 2.4.2pre2 o Highmem bounce fixes(Ingo Molnar) o Fix cosa driver kfree (Jan Kasprzak) o Clean up pdoc202xx driver sleeps(Vojtech Pavlik) o Final bits of NFS file handle changes (Trond Myklebust) o Fix usbnet driver (David Brownell) o ATM includes fixes (Werner Almesberger) o Remove unneeded vm_enough_memory check (Werner Almesberger) o Fix free_dma prototype case (Bill Nottingham) o Fix build bugs from pci_match_device fix(me) o HP5300 USB scanner driver (Oliver Neukum, John Fremlin, Jeremy Hall) o DSP_SETFRAGMENT fixes for ymfpci(Pavel Roskin) o Fix codafs error returns(Rob Radez) o Fix 48 misspellings of interrupt(André Dahlqvist) o Fix 20 misspellings of successful (André Dahlqvist) o Fix 11 misspellings of suppress (André Dahlqvist) o Fix 46 misspellings of address (André Dahlqvist) o Fix 26 misspellings of receive (André Dahlqvist) o Fix 7 misspellings of acquire (André
Re: 2.4.2-pre2 ext2fs corruption
Alan Cox <[EMAIL PROTECTED]> writes: > > i came in today to find the computer completely locked up. after > > rebooting and waiting for about an hour for fsck to finish i found the > > following errors in the system log: > > What hardware. I can see its some kind of scsi setup but what interfaces ? > sorry. intel piii, with an adaptec AHA-294X Ultra2 scsi adapter. the disk in question is a 9gb IBM disk Model: DNES-309170W Rev: SA30. is this what you need? do you need more? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
Hi Andries! On Tue, 13 Feb 2001 [EMAIL PROTECTED] wrote: > > The block device uses 1K blocksize, and will prevent userspace from > > seeing the odd-block at the end of the disk, if the disk is odd-size. > > > > IA-64 architecture defines a new partitioning scheme where there is a > > backup of the partition table header in the last sector of the disk. While > > we can read and write to this sector in the kernel partition code, we have > > no way for userspace to update this partition block. > > Are you sure? Yes. The only alternative at this time is to use the scsi-generic tools to read directly from the scsi-layer. But, of course, this only works with scsi devices. > > There may be no easy, convenient way right now, but > (without having checked anything) it seems to me > that you can, also today. Please go check :-) I believe my statement stands: You cannot read or write to odd-sectors at the end of the disk from userspace. (see below for definition of odd sector...) > Look at the addpart utility in the util-linux package. > It will allow you to add a partition disjoint from > previously existing partitions. > And since a partition can start on an odd sector, > this should allow you to also read the last sector. > > Do I overlook something? Yes. The addpart utility just uses the block-layer ioctls to dynamically add and/or remove partitions. What this is doing is just adjusting the kernel's idea of what the current partition scheme is. This has _nothing_ to do with actually reading or writing data from the disk. The ia64 gpt partitioning code defines a partition header at the front of the disk and at the end of the disk. I definetly have a need to read and write to these headers. What this proposed patch does has _nothing_ to do with partitioning :-) It is _only_ to read and write the last sector of the disk. It just so happens that the reason that I have to read that last sector is to read a partition header. > > Anyway, an ioctl just to read the last sector is too silly. > An ioctl to change the blocksize is more reasonable. That may be better, I don't know. That's why this is an RFC. Are there any possible races with that method? It seems to me that you might adversely affect io in progress by changing the blocksize. The method demonstrated in this patch shouldn't do that. > And I expect that this fixed blocksize will go soon. That may be, I don't know that much about the block layer. All I know is that, with the current structure, I cannot read or write to sectors where (sector #) > total-disk-blocks - (total-disk-blocks / (softblocksize/hardblocksize)) This ioctl can be deprecated when that is no longer the case. > > Andries > Thanks for the comments. > [Sorry if precisely the same discussion has happened earlier - > I have no memory.] > Not really. I have discussed this with some folks with Red Hat, but this is the first discussion on L-K. -- Michael Brown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac11, VM: Bad swap entry
2.4.1-ac11 creates repeatedly the following error messages on my box: kernel: VM: killing process crond (or any other process) kernel: VM: Bad swap entry e200(variable addresses) for example in intervals of about 5 to 10 seconds. This is on a notebook, AMD K6-433, 64megs RAM, VIA MVP4 chipset (VT8501 revision 3), Bus Master revision 6; didn't get these errors with the 2.4.1-ac6 patch which I ran before. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre2 ext2fs corruption
> i came in today to find the computer completely locked up. after > rebooting and waiting for about an hour for fsck to finish i found the > following errors in the system log: What hardware. I can see its some kind of scsi setup but what interfaces ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 loopback FS partial fix
Excellent - this solved my problems. I stress tested the loopback device
with a big copy and it seemed to work. I also made losetup use open64:
[root@crush mount]# diff lomount.c lomount.c~
230c230
< if ((ffd = open64 (file, mode)) < 0) {
---
> if ((ffd = open (file, mode)) < 0) {
and gave it a 10GB file. This seems to be working fine as well.
-John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.4.2-pre2 ext2fs corruption
i came in today to find the computer completely locked up. after rebooting and waiting for about an hour for fsck to finish i found the following errors in the system log: Feb 13 06:25:18 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_readdir: bad entry in directory #11: rec_len %% 4 != 0 - offset=0, inode=1179403647, rec_len=257, name_len=1 Feb 13 06:25:18 caliban kernel: init_special_inode: bogus imode (34503) Feb 13 06:25:18 caliban kernel: init_special_inode: bogus imode (30060) Feb 13 06:25:18 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_readdir: bad entry in directory #1170: directory entry across blocks - offset=0, inode=842214441, rec_len=11312, name_len=51 Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (52073) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (35144) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (71563) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (51117) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (72141) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (52101) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (36451) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (54522) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (30067) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (57505) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (31454) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (71145) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (74105) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (34063) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (51520) Feb 13 06:25:19 caliban kernel: init_special_inode: bogus imode (72151) Feb 13 06:25:19 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_readdir: bad entry in directory #16292: rec_len %% 4 != 0 - offset=0, inode=741488945, rec_len=12851, name_len=59 Feb 13 06:25:19 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_readdir: bad entry in directory #16293: rec_len %% 4 != 0 - offset=0, inode=740898354, rec_len=12337, name_len=56 [more of the same deleted] Feb 13 06:26:23 caliban kernel: init_special_inode: bogus imode (44) Feb 13 06:26:23 caliban kernel: init_special_inode: bogus imode (104) Feb 13 06:26:23 caliban kernel: init_special_inode: bogus imode (3) Feb 13 06:26:23 caliban kernel: init_special_inode: bogus imode (52731) Feb 13 06:26:23 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_readdir: bad entry in directory #679: rec_len %% 4 != 0 - offset=0, inode=842214450, rec_len=18235, name_len=101 Feb 13 06:26:23 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_readdir: bad entry in directory #827280: rec_len %% 4 != 0 - offset=0, inode=25203, rec_len=25206, name_len=0 Feb 13 06:26:24 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_readdir: bad entry in directory #822: rec_len is too small for name_len - offset=0, inode=32419, rec_len=128, name_len=235 [more of the same deleted] Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_inode: bit already cleared for inode 18434 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks in system zones - Block = 130, count = 1 Feb 13 06:28:31 caliban kernel: fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 925969465, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 675096887, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 824981816, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1026111543, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 959981610, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 892809516, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1347158057, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 977752909, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 959981684, count = 1 Feb 13 06:28:31 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 959918380, count = 1 [more deleted] Feb 13 06:28:48 caliban kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: Freeing blocks in system zones - Block = 128, count = 1 Feb 13 06:28:48 caliban
Re: Stale NFS handles on 2.4.1
> The NFS clients are getting > "Stale NFS handle" > messages every once in a while which will make a "touch somefile.o" > fail. If they have the previous .o handle cached and it was removed on another client thats quite reasonable behaviour. NFS isnt coherent > It's quite annoying and I didn't see it on 2.2 even after the NFS > patches were integrated. I wonder if its because 2.4 runs faster and caches better 8). You can tune the attribute cache times that may help. Are we talking 30 second intervals here or stuff being cached for far too long (which would imply a bug) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Stale NFS handles on 2.4.1
Hi !
I'm running a compilation cluster with various machines now
on 2.4.1 all mounting the same home filesystem over NFS from
the central NFS server.
All machines are 2.4.1 using NFSv3, some SMP some UP.
NFS server is a dual running an SMP kernel
The NFS clients are getting
"Stale NFS handle"
messages every once in a while which will make a "touch somefile.o"
fail.
It's quite annoying and I didn't see it on 2.2 even after the NFS
patches were integrated.
What happens is that one machine will finish compiling, and another
machine will immediately thereafter do a "touch some_output.o". This
"touch" sometimes fails with a stale handle message.
Is this a known problem or should I submit more info ? If so,
what info ?
(no nothing is overclocked, yes I'm using RedHat 7 kgcc)
--
: [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]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.1, 2.4.2-pre3: APIC lockups
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
> There is also an additional debugging/statistics counter provided in
> /proc/cpuinfo that counts interrupts which got delivered with its trigger
> mode mismatched. Check it out to find if you get any misdelivered
> interrupts at all.
I guess you mean the MIS: counter in /proc/interrupts? This is what it says on
my box after running some 33 interrupts (at a rate of app. 900/second)
through the network/usb IRQ:
cat /proc/interrupts
CPU0 CPU1
0: 31693 32749IO-APIC-edge timer
1: 1208 1174IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3:113 26IO-APIC-edge serial
4: 4689 4567IO-APIC-edge serial
14: 4440 4545IO-APIC-edge ide0
15: 1911 2132IO-APIC-edge ide1
16: 85021 84227 IO-APIC-level es1371, mga@PCI:1:0:0
17: 26 26 IO-APIC-level sym53c8xx
18: 0 0 IO-APIC-level btaudio, bttv
19: 165467 166254 IO-APIC-level eth0, eth1, usb-uhci
NMI: 64376 64376
LOC: 64364 64362
ERR: 0
MIS:647
So, that's about 650 misdelivered interrupts for 33 deliveries (the other
interrupts never gave me any trouble, so I guess the misdelivered ones are all
from IRQ 19), or about .2%
When I load the network and stream some audio over it, the sound becomes a bit
choppy. The MIS: counter only increases when the network (read: IRQ1() is
loaded, a single audio stream (app. 220 int/sec) causes no MISses to occur.
In general, I'd say the stability WITH the patch is good, and timeouts are
withing tolerable levels. If I need something better, I'll probably get myself
a better set of network cards...
So, quick conclusion, this seems a reasonable fix...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
On Tue, 13 Feb 2001, Jeremy Jackson wrote: > Next, gcc doesn't generate any code which would be placed in the > stack, nor does it generate any calls/jumps to the stack area. Unfortunately, you can't count on this. Objective C, for one, requires an executable stack. While there have been "unofficial" patches (Solar Designer) to lock out executing the stack for a long time, and it does work in most cases, this isn't really doable as a general solution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: To Linus: kdb in 2.4?
S! Do not nudge sleeping penguin. Here is blow-by-blow of last incident: http://kt.linuxcare.com/kernel-traffic/kt20001002_87.epl#1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multicast on loopback?
> locally over the loopback interface. This does not work without adding a > bogus route statement to get the kernel to hand up the packets from > loopback to my waiting application. The multicast ABI includes the ability to toggle loopback of multicast datagrams. Use the socket options instead - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-ac11 swap problems
> 2.4.1-ac10 works fine (I had it up 24 hours before, and am again running > it). > > Shortly after boot on 2.4.1-ac11, I get a ration of these: > kernel: Unused swap offset entry in swap_count 0015fb04 Yep there is a small bug in the tlb shootdown fixes. Ben has fixed that. I'll put up an ac12 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
On Tue, 13 Feb 2001 21:22:26 + (GMT) James Sutherland <[EMAIL PROTECTED]> wrote: > On Tue, 13 Feb 2001, Jeremy Jackson wrote: > > (Long description of how to create a non-executable stack on x86) > > ISTR there is a patch which does this for Linux, though?? See: http://www.openwall.com/linux/ for Solar Designer's patch, and: http://www.insecure.org/sploits/non-executable.stack.problems.html for the exploit. It was done to death on the linux-security ML a while ago, so you could search the archives if you want to know more. -- Bruce Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Multicast on loopback?
In developing multicast applications, I would like to be able to test locally over the loopback interface. This does not work without adding a bogus route statement to get the kernel to hand up the packets from loopback to my waiting application. This route statement is not necessary with other network drivers, so I assume that adding some logic to the loopback driver would fix this problem. Is it possible to get this added? -Erik G. Burrows - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: To Linus: kdb in 2.4?
[EMAIL PROTECTED] said: > I'm wondering about the possibility of re-examining the idea of a > kernel debugger option distributed with 2.4. First off, I'd like to say that I'm highly sympathetic to this, assuming that a kernel debugger doesn't change the kernel's behavior. However, > I'm thinking that it could be a great teaching tool to break and > examine structures, variables, process states, as well as an aid to > people who may not have a grasp of the entire kernel but need to write > device drivers. you might look at UML (http://user-mode-linux.sourceforge.net) for this. A number of kernel hackers are very successfully using UML for doing filesystem and mm development and debugging. With some help from the host, it's also possible to do driver development under UML. I also know of a number of people using UML to further their education by using it to poke around a running kernel. > Certainly Buddha doesn't need to know how to read to know his own > writings -- and certainly, if everyone meditates and 'evolves' to > their Buddha nature, they wouldn't need to read the texts or recognize > the letters either. So, if you can't convince Buddha of the wisdom of your arguments (or even if you can) check out UML. It makes a perfectly good kernel debugger available, and it's a lot easier to deal with than a native kernel. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ conflicts
Andrey Panin wrote: > > Hi Brian. > > I'm sorry, patch itself was not attached in previous post :( > Yes, this does fix that part of the problem. There is still the matter of the class code being wrong but I have ideas on how to fix that. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stale super_blocks in 2.2
Philip R. Auld writes: > Since deja was gobbled by google it's hard to do a good search of > this list. Can anyone take the time to help me understand the reason > for this choice? This seems to me to be backwards. When a device is > unmounted there should be no cached information. Try the following for a searchable mailing list: http://marc.theaimsgroup.com/?l=linux-kernel=1=4 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
> The block device uses 1K blocksize, and will prevent userspace from > seeing the odd-block at the end of the disk, if the disk is odd-size. > > IA-64 architecture defines a new partitioning scheme where there is a > backup of the partition table header in the last sector of the disk. While > we can read and write to this sector in the kernel partition code, we have > no way for userspace to update this partition block. Are you sure? There may be no easy, convenient way right now, but (without having checked anything) it seems to me that you can, also today. Look at the addpart utility in the util-linux package. It will allow you to add a partition disjoint from previously existing partitions. And since a partition can start on an odd sector, this should allow you to also read the last sector. Do I overlook something? Anyway, an ioctl just to read the last sector is too silly. An ioctl to change the blocksize is more reasonable. And I expect that this fixed blocksize will go soon. Andries [Sorry if precisely the same discussion has happened earlier - I have no memory.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stale super_blocks in 2.2
> That can be a problem for fiber channel devices. I saw some issues with > invalidate_buffers and page caching discussed in 2.4 space. Any reasons > come to mind why I shouldn't call invalidate on the the way down instead > (or in addition)? The I/O completed a few seconds later anyway when bdflush got around to writing the data back out. I dont plan to change 2.2. 2.4 doesnt do that optimisation which is annoying in a few cases and a lot less suprising in others - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stale super_blocks in 2.2
Alan Cox wrote: > > > does not do anything to invalidate the buffers associated with the > > unmounted device. We then rely on disk change detection on a > > subsequent mount to prevent us from seeing the old super_block. > > 2.2 yes, 2.4 no That can be a problem for fiber channel devices. I saw some issues with invalidate_buffers and page caching discussed in 2.4 space. Any reasons come to mind why I shouldn't call invalidate on the the way down instead (or in addition)? Thanks, Phil -- Philip R. Auld Kernel Engineer Egenera Corp.[EMAIL PROTECTED] 165 Forest St, Marlboro, MA 01752(508)786-9444 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will the IBM OMNI printer driver be making its way into the kernel tree?
** Reply to message from Miles Lane <[EMAIL PROTECTED]> on 13 Feb 2001 14:18:43 -0800 > The reason I asked about inclusion is that printing is one of the areas > that Linux seems to struggle in terms of usability and I thought perhaps > it would make sense to modular print drivers in the kernel tree. No, improving printing support is something that the distribution vendors are supposed to provide. I think you're under the assumption that this support were to be placed in the kernel, it would then become ubiquitous. That may be true, but it's irrelevant. Instead, what is needed is a sort of "standard" that indicates what every Linux distribution should have in addition to the kernel. And that's something that's being addressed by organization such as the Linux Standard Base (http://www.linuxbase.org/). You should ask them about it. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stale super_blocks in 2.2
> does not do anything to invalidate the buffers associated with the > unmounted device. We then rely on disk change detection on a > subsequent mount to prevent us from seeing the old super_block. 2.2 yes, 2.4 no - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Stale super_blocks in 2.2
Hello, It appears that the umount path in the 2.2 series kernels does not do anything to invalidate the buffers associated with the unmounted device. We then rely on disk change detection on a subsequent mount to prevent us from seeing the old super_block. Since deja was gobbled by google it's hard to do a good search of this list. Can anyone take the time to help me understand the reason for this choice? This seems to me to be backwards. When a device is unmounted there should be no cached information. Thanks for the help, Phil -- -- Philip R. Auld, Ph.D. technical staff Egenera Corp.[EMAIL PROTECTED] 165 Forest St, Marlboro, MA 01752(508)786-9444 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Announce] Version 1.9 of x86 performance counters driver
Version 1.9 of my x86 performance-monitoring counters driver is now available at http://www.csd.uu.se/~mikpe/linux/perfctr/. Summary: Version 1.9, 2001-02-13 - Fixed compilation problems for 2.2 and SMP kernels. [Caused by the kernel not passing "-nostdinc" to gcc, and RedHat 7.0 including 2.4.0 kernel headers in /usr/include/.] - Corrected VIA Cyrix III support. The "VIA Cyrix III" product has apparently used two distinct CPUs. Initial CPUs were a Cyrix design (Joshua) while current CPUs apparently are a Centaur design (Samuel). Added support for "Samuel" CPUs. [NOTE: This could use some testing on real HW. Any volunteers?] - Two corrections in the K7 perfctr event list. - Small tweaks to vperfctr interrupt handling. - Added preliminary interrupt-mode support for AMD K7. Future changes on the perfctr-1.x branch will be limited to bug fixes and updated glue patches for new 2.2 kernels. New features and hardware support will be implemented in the perfctr-2.x branch, but it will only support 2.4/2.5 kernels. (Sorry, but maintaining compatibility with 2.2 kernels is taking too much of my time.) / Mikael Pettersson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.1, 2.4.2-pre3: APIC lockups
"Maciej W. Rozycki" wrote: > > Hi, > > After performing various tests I came to the following workaround for > APIC lockups which people observe under IRQ load, mostly for networking > stuff. I believe the test should work in all cases as it basically > implements a manual replacement for EOI messages. In my simulated > environment I was unable to get a lockup with the code in place, even > though I was getting about every other level-triggered IRQ misdelivered. > > Please test it extensively, as much as you can, before I submit it for > inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!" > message, please report it to me immediately -- it means the code failed. > No messages. > There is also an additional debugging/statistics counter provided in > /proc/cpuinfo that counts interrupts which got delivered with its trigger > mode mismatched. Check it out to find if you get any misdelivered > interrupts at all. > I'm running my default webserver load test, and I get ~40 /second, 92735 total. bw_tcp says 1.13 MB/sec, that's wire speed. tcpdump | grep 'sack ' doesn't show unusually many lost packets. Look promising. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will the IBM OMNI printer driver be making its way into thekernel tree?
Whoops. The reason I asked about inclusion is that printing is one of the areas that Linux seems to struggle in terms of usability and I thought perhaps it would make sense to modular print drivers in the kernel tree. Since the OMNI driver is ghostscript-based, including it in the kernel is obviously a bogus idea. Sorry for missing the obvious. I do wonder if there are no print drivers that would make sense in the kernel tree. After all, we have USB device drivers in the tree, including scanners, which aren't all that different from printers, are they? I apologize in advance if I am just being incredibly stupid about this. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
To Linus: kdb in 2.4?
I'm wondering about the possibility of re-examining the idea of a kernel debugger option distributed with 2.4. I'm thinking that it could be a great teaching tool to break and examine structures, variables, process states, as well as an aid to people who may not have a grasp of the entire kernel but need to write device drivers. It's easy for someone who's "grown up" with Linux to know it all so thoroughly that such a tool seems fluff. But even the best mechanics on new cars use complex diagnostic tools to do car repair. Sure there may be experts that designed the engine that wouldn't need it, but large numbers of people need to repair cars or modify them for their purposes. Having tools to aid in that isn't so much a crutch as it is a learning tool. It's like being able to look at the characters of the alphabet individually before one learns to comprehend the entirety of the writings of Buddha. Certainly Buddha doesn't need to know how to read to know his own writings -- and certainly, if everyone meditates and 'evolves' to their Buddha nature, they wouldn't need to read the texts or recognize the letters either. But not everyone is at the same place on the mountain (or even the same mountain, for that matter). In wisdom, one would, I posit, understand others are in different places and may find it useful to have tools to learn to read before they comprehend. Just my 2-4 cents on the matter... -- L A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test
test - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x SMP blamed for Xfree 4.0 crashes
> Yes, actually it is... So I'm wrong then, it's not the same problem. A rebuild of the binaries in question should fix it. Anton - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will the IBM OMNI printer driver be making its way into the kernel tree?
Maybe I'm missing your point, but why would it go into the kernel tree ? This is all stuff that gets done in userland under Linux. The Omni drivers plugin with Ghostscript and generate output appropriate to the printer. There's no kernel relevance here. Tim On Tue, Feb 13, 2001 at 01:42:27PM -0800, Miles Lane wrote: > http://oss.software.ibm.com/developer/opensource/linux/projects/omni/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19ac-pre9 lo interface Broke
Sorry for all the fuss, I've been reliably informed, I put my foot in my own mouth... It was my net-tools package from Debian -(. I missed the fact I upgraded some packages same day I upgraded my kernel. I'll drop off the list again now. Sorry for the bother. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Will the IBM OMNI printer driver be making its way into the kernel tree?
Miles Lane ([EMAIL PROTECTED]) said: > http://oss.software.ibm.com/developer/opensource/linux/projects/omni/ Considering it's a ghostscript driver, I severely doubt it. :) Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gzipped executables
On Mon, Feb 12, 2001 at 11:09:39PM -0600, Matt Stegman wrote: > Is there any kernel patch that would allow Linux to properly recognize, > and execute gzipped executables? What's wrong with using gzexe? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Will the IBM OMNI printer driver be making its way into the kerneltree?
http://oss.software.ibm.com/developer/opensource/linux/projects/omni/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Updates for the PCI devices Database.
I'm starting to work on an Intel i815 board. I take this occasion to make a few updates to the PCI device database, so it will be easier to identify the whole hardware... I changed the base, according what Intel says in the datasheets for 82815 Chipset and 82801BA Chip. Here's the patch: --- pci.ids-origWed Jan 3 01:58:45 2001 +++ pci.ids Tue Feb 13 23:29:58 2001 @@ -4484,6 +4484,16 @@ 1014 0119 Netfinity Gigabit Ethernet SX Adapter 8086 1000 EtherExpress PRO/1000 Gigabit Server Adapter 1030 82559 InBusiness 10/100 + 1100 82815 Chipset GMCH / FSB DRAM Controler + 1101 82815 Chipset AGP/PCI Bridge + 1102 82815 Chipset Internal Graphic Device + 1110 82815 Chipset GMCH / FSB DRAM Controler [no AGP] + 1112 82815 Chipset Internal Graphic Device [no AGP] + 1120 82815 Chipset GMCH / FSB DRAM Controler [AGP only] + 1121 82815 Chipset AGP/PCI Bridge [AGP only] + 1130 82815 Chipset GMCH / FSB DRAM Controler + 1131 82815 Chipset AGP/PCI Bridge + 1132 82815 Chipset Internal Graphic Device 1161 82806AA PCI64 Hub Advanced Programmable Interrupt Controller 1209 82559ER 1221 82092AA_0 @@ -4584,13 +4594,18 @@ 11d4 0048 SoundMAX Integrated Digital Audio 2426 82801AB AC'97 Modem 2428 82801AB PCI Bridge - 2440 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) - 2442 82820 820 (Camino 2) Chipset USB (Hub A) - 2443 82820 820 (Camino 2) Chipset SMBus - 2444 82820 820 (Camino 2) Chipset USB (Hub B) - 2449 82820 820 (Camino 2) Chipset Ethernet - 244b 82820 820 (Camino 2) Chipset IDE U100 - 244e 82820 820 (Camino 2) Chipset PCI + 2440 82801BA (ICH2) Chipset Multi-purpose IO / Interrupt controler + 2442 82801BA (ICH2) Chipset USB (Hub A) + 2443 82801BA (ICH2) Chipset SMBus + 2444 82801BA (ICH2) Chipset USB (Hub B) + 2445 82801BA (ICH2) Chipset AC'97 Audio + 2446 82801BA (ICH2) Chipset Ac'97 Modem + 2448 82801BAM (ICH2-M) Chipset PCI Bridge + 2449 82801BA (ICH2) Chipset Ethernet + 244a 82801BAM (ICH2-M) Chipset IDE U100 + 244b 82801BA (ICH2) Chipset IDE U100 + 244c 82801BAM (ICH2-M) Multi-purpose IO / Interrupt controler + 244e 82801 (ICH2) Chipset PCI Bridge 2500 82820 820 (Camino) Chipset Host Bridge (MCH) 1043 801c P3C-2000 system chipset 2501 82820 820 (Camino) Chipset Host Bridge (MCH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1 loopback FS partial fix
For the other list readers with problems: I used patch 2.4.2-pre2 (not pre3) plus axboe's loop-4 patch (in the people directory). [EMAIL PROTECTED]:/pub/linux/kernel/people/axboe/patches/2.4.2-pre1 It solves most problems here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
strange bug, alloca suspected
Hi,
I found a strange bug with modprobe/glibc
I supposed this is a bad interaction between gcc alloca(), glibc and modprobe.
Modprobe don't use alloca() correctly, then glibc failed. (stack corruption ?)
This need more investigation.
This mail is sent to glibc, gcc and modutils maintainers.
>Submitter-Id: net
>Originator:Yann Droneaud <[EMAIL PROTECTED]>
>Organization: no others than mine
>Confidential: no
>Synopsis: undetermined
>Severity: non-critical
>Priority: low
>Category: libc
>Class: sw-bug
>Release: libc-2.1.3
>Environment:
Host type: i586-pc-linux-gnu
System: Linux Corwin.Ambre 2.4.0-prerelease #1 Mon Jan 1 23:11:11 CET 2001 i586
unknown
Architecture: i586
Addons: crypt linuxthreads
Build CFLAGS: -g -O2 -march=i586
Build CC: gcc
Compiler version: 2.95.2 19991024 (release)
Kernel headers: 2.4.1
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio
compiled against linux 2.3.99-pre5 with gcc-2.95.2
Others:
modutils-2.4.2
configured with './configure --prefix=/usr --exec-prefix= --disable-combined
--enable-combined-rmmod --enable-combined-lsmod --disable-strip'
gcc 2.95.2
bash 2.03.0(1)-release
>Description:
>How-To-Repeat:
How to reproduce bug
on shell prompt, as root type:
# /sbin/modprobe --help
just display help, no problem.
try this now:
# modprobe --help
display help,
but finish by a Segmentation Fault
What a strange behaviour, isn't it ?
>Fix:
A little taste of debugging:
I decide to debug modprobe.
I added a signal handler for SIGSEGV.
The handler only wait for the debugger.
0x400951f1 in __libc_nanosleep () from /lib/libc.so.6
(gdb) bt
#0 0x400951f1 in __libc_nanosleep () from /lib/libc.so.6
#1 0x40095188 in __sleep (seconds=1) at ../sysdeps/unix/sysv/linux/sleep.c:82
#2 0x804ba3a in sighandler ()
#3
#4 tdestroy_recurse (root=0x0, freefct=0x400f1d20 <_IO_2_1_stderr_>) at
tsearch.c:637
#5 0x100 in ?? ()
(gdb) directory /tmp/glibc-2.1.3/misc
Source directories searched: /tmp/glibc-2.1.3/misc:$cdir:$cwd
(gdb) frame 4
#4 tdestroy_recurse (root=0x0, freefct=0x400f1d20 <_IO_2_1_stderr_>) at
tsearch.c:637
637 if (root->left != NULL)
(gdb) list
632tree cannot be removed easily. We provide a function to do this. */
633 static void
634 internal_function
635 tdestroy_recurse (node root, __free_fn_t freefct)
636 {
637 if (root->left != NULL)
638 tdestroy_recurse (root->left, freefct);
639 if (root->right != NULL)
640 tdestroy_recurse (root->right, freefct);
641 (*freefct) ((void *) root->key);
(gdb) print root
$1 = 0x0
I wasn't able to find how/where this function could be call with a NULL
argument.
A little patch for glibc 2.1.3, misc/tsearch.c
=
--- tsearch.c Thu Nov 6 00:18:09 1997
+++ tsearch-meuh.c Sun Feb 11 23:54:37 2001
@@ -634,13 +634,22 @@
internal_function
tdestroy_recurse (node root, __free_fn_t freefct)
{
- if (root->left != NULL)
-tdestroy_recurse (root->left, freefct);
- if (root->right != NULL)
-tdestroy_recurse (root->right, freefct);
- (*freefct) ((void *) root->key);
- /* Free the node itself. */
- free (root);
+ if (root != NULL)
+{
+ if (root->left != NULL)
+ tdestroy_recurse (root->left, freefct);
+ if (root->right != NULL)
+ tdestroy_recurse (root->right, freefct);
+ (*freefct) ((void *) root->key);
+ /* Free the node itself. */
+ free (root);
+}
+#ifdef DEBUGGING
+ else
+{
+ assert(root != NULL);
+}
+#endif /* DEBUGGING */
}
void
===
For modprobe
I review the code before the getopt_long(), I found the alloca() call did not
reserve room for the last NUL char
The only thing important is the l++;
so the patch:
--- modutils-2.4.2/insmod/modprobe.cFri Jan 19 07:26:33 2001
+++ modutils-2.4.2-debug/insmod/modprobe.c Mon Feb 12 00:00:58 2001
@@ -33,6 +33,9 @@
#include
#include
#include
+#include
#include "module.h"
#include "obj.h"
#include "modstat.h"
@@ -1476,6 +1479,25 @@
);
}
+#ifdef DEBUG
+void sighandler(int sig)
+{
+ int i;
+ static int wait_for_gdb;
+ printf("%d: signal SIGSEGV: %d, waiting for debugger\n", getpid(), sig);
+ while (wait_for_gdb == 0)
+sleep(1);
+ /* wait about 10 seconds */
+ for(i = 0; i < 10 ; i++)
+sleep(1);
+ exit(1);
+}
+#endif
int main(int argc, char *argv[])
{
int ret = 0;
@@ -1506,10 +1528,18 @@
int i, l = 0;
char *command;
+#ifdef DEBUG
+ signal(SIGSEGV, sighandler);
+#endif
for (i = 0; i < argc; ++i)
l += strlen(argv[i]) + 1;
+ l++; /* be sure to have room
Re: 2.2.19pre10 locks up hard on unloading the isdn module 'hisax.o' - 2.2.19pre11 does too!
>SMP machine, 2x P3/700 on an Abit VP6.
>Never any trouble with the earlier 2.2.19pre's.
>
>a strace shows the hang to be in the delete_module("hisax") call.
>
>I'm having trouble with the sysrq-key, but I hope this is enough since
>there were some changes w.r.t. modules/locking etc. in pre10.
>
It's Linux, after all, so 2 minutes after creating this email
2.2.19pre11's announcement was here. I just tested it, and it has the
same problem.
from my config:
ISDN subsystem
#
CONFIG_ISDN=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_DRV_HISAX=m
CONFIG_HISAX_EURO=y
CONFIG_HISAX_W6692=y
Now, it's just one more crash and back to 2.2.19pre9 for me!
Good luck,
Jurriaan
--
When God is on the Bodhran
The atoms want to dance
Oysterband - In your eyes
GNU/Linux 2.2.19pre11 SMP/ReiserFS 2x1402 bogomips load av: 0.05 0.34 0.20
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
On Tue, 13 Feb 2001, Jeremy Jackson wrote: (Long description of how to create a non-executable stack on x86) I'm afraid you just reinvented the wheel. The idea has been around for a long time, and it was OK as a quick hack to stop existing exploits working, but it's possible to modify a buffer overflow exploit to work around this. It does sound look like a good idea, but it doesn't really gain you anything in the long run: the exploits just change a bit. ISTR there is a patch which does this for Linux, though?? James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19pre10 locks up hard on unloading the isdn module 'hisax.o' - 2.2.19pre11 does too!
> It's Linux, after all, so 2 minutes after creating this email > 2.2.19pre11's announcement was here. I just tested it, and it has the > same problem. Yep. Right now Im still working through the merges with Kai and I suspect the merge when completed may not fix your bug, but that it'll get squashed shortly after. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19ac-pre9 lo interface Broke
Gordon Sadler wrote: > > I have some further info here. > I performed strace on ifup -a and ifdown -a. > > They aren't more than 4Kb each, but I'll cut and paste what appear to be > most relevant: > > ifup.strace: > fork() = 17974 > wait4(17974, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 17974 > --- SIGCHLD (Child exited) --- > fork() = 17976 > wait4(17976, SIOCSIFADDR: Bad file descriptor > lo: unknown interface: Bad file descriptor > lo: unknown interface: Bad file descriptor > [WIFEXITED(s) && WEXITSTATUS(s) == 255], 0, NULL) = 17976 > --- SIGCHLD (Child exited) --- [snip] > > Can anyone point a finger? Debian bug #85774 http://cgi.debian.org/cgi-bin/bugreport.cgi?archive=no=85774 ifconfig broke, nothing to do with the kernel. Cheers, Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
> which are marked > supervisor-only (is this right?), and definitely don't contain user > code. x86 its a fair description. However someone has taken the same theory, including handling the exceptions and the x86 segment tricks needed to make it kind of fly. Its not a perfect cure but it works. Search for Solar Designer and non executable stack. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is this the ultimate stack-smash fix?
Greetings. This is my first post on linux-kernel, I hope this is appropriate. The recent CERT IN-2001-01 's massive repercussions and CA-2001-02's re-releasing old material in an attempt to coerce admins to update their OS, has led me to think about buffer overrun exploits. I have gained a new appreciation after being rooted twice this month. I believe there is a solution that can be implemented in the kernel (Linux and probably most Unix) that can prevent this type of exploit, has no effect on userspace code, and is minimally obtrusive for the kernel. Making a few assumptions here - I'm writing to confirm or deny this idea. Background: The virtual address space of a Linux process starts at a low address (0?) with a block containing -the executable's code & constant data mmaped read-only from the executable. -the executable's static initialized data mmapped copy-on-write from same file. -more of each of the above, but for shared libraries. each continuous address range from the above is described in a kernel vm_area_struct, and is mapped on demand and placed into hardware page-protection perms (rwx) by the CPU's PMMU hardware and the kernel's fault-handler's. Next, there is a variable ammount of un mapped memory, Followed by the Stack. The stack's vm_area grows downward, unlike the others ( brk() call) and begins at the high address at the top of user space, which varies but is 3GB for a 1GB max mem kernel. beyond this there is no vm_area's, and the page tables contain mappings which are marked supervisor-only (is this right?), and definitely don't contain user code. Next, gcc doesn't generate any code which would be placed in the stack, nor does it generate any calls/jumps to the stack area. Next, buffer overruns are the only source of code whch would execute from the stack, and from what I understand, remote (if not all) buffer overruns depend on this to "work". Solution: if the kernel sets up the CPU's memory management unit (PMMU) so that it won't execute code in the stack address space, the exploits are foiled. Problem: on intel, the page tables page permissions are not flexible enough, so when a page is marked (for userspace) read-write permissions, execute permission is implied. But, intel also has segment descriptors held in the GDT/LDTs, which configure a base address and range, and a different one can be selected for each segment register of a process. Under the current Linux the code segment (CS) has a descriptor from the GDT which allows code to be executed read-only from base address 0 with a range of 4G (i.e. the entire linear address space), and the data segment allows read-write but not execute (can't be loaded into CS register). SO, if the CS descriptor were changed by the kernel to track the bottom of the stack (lower in memory), then any attempt to execute code on the stack would segfault (or another signal to help track exploit attempts) It could get the bottom page address from the vm_area_struct for the stack (are there more than one GROWS_DOWN vm areas in a process?) Currently the CS for all linux programs gets it's descriptor from GDT, so it would have to be manually changed at each task-swap, and perhaps there are segment descriptor and other cache flushing issues, (maybe just store CS limit in the per-task data structure, and update GDT then reload CS at each context change) I realize that the GDT/LDT must be accessible, and that they are in kernel space (above 3GB), but I don't think these go through CS register access controls. The DS segment can be left alone. For other arch's, maybe they have separate read/write/execute perms per page, or something similar to segment descriptors. I would appreciate thoughful comments; anybody who knows why it won't work, tell me, I haven't got my hopes up for the Nobel prize yet :) Cheers, Jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
[EMAIL PROTECTED] (Kai Henningsen) writes: >[EMAIL PROTECTED] (Henning P. Schmiedehausen) wrote on 12.02.01 in ><968mjv$l9t$[EMAIL PROTECTED]>: >> [EMAIL PROTECTED] (Jan Gyselinck) writes: >> >> >There's not really something wrong with MX's pointing to CNAME's. It's >> >just that some mailservers could (can?) not handle this. So if you want to >> >be able to receive mail from all kinds of mailservers, don't use CNAME's >> >for MX's. >> >> No. It breaks a basic assumption set in stone in RFC821. It has >> nothing to do with mailer software. >May I point out that RFC 821 does not mention either CNAME or MX anywhere. RFC 974 is about the "DOMAIN NAME SYSTEM". RFC 821 mentions DOMAINS: 3.7. DOMAINS >So don't tell us about stuff set in stone in RFC XYZ, when it's plain >you've never looked at that RFC. Says who? RFC974 is a clarification of how to interpret Domain Name System contents in a mail context. RFC821 makes a clear statement about Domains in section 3.7: [...] Whenever domain names are used in SMTP only the official names are used, the use of nicknames or aliases is not allowed. [...] and in RFC974 it is stated: [...] In addition to mail information, the servers store certain other types of RR's which mailers may encounter or choose to use. These are: the canonical name (CNAME) RR, which simply states that the domain name queried for is actually an alias for another domain name, which is the proper, or canonical, name; [...] [...] In my understanding (and I assume that you're familiar with both as you've chosen to insult me by suggesting that I've not read this stuff), this means clearly: "YOU MUST NOT USE AN ALIAS WHENEVER DOMAINS ARE USED IN SMTP". (RFC821) and "THIS NAME IS AN ALIAS FOR ANOTHER DOMAIN NAME, WHICH IS THE PROPER, CANONICAL NAME". This boils down for me to "YOU MUST NOT USE A CNAME ANYWHERE IN SMTP". and "ANYWHERE" also states for me "in the 220 greeting". Any further questions? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2.19pre10 locks up hard on unloading the isdn module 'hisax.o'
SMP machine, 2x P3/700 on an Abit VP6.
Never any trouble with the earlier 2.2.19pre's.
a strace shows the hang to be in the delete_module("hisax") call.
I'm having trouble with the sysrq-key, but I hope this is enough since
there were some changes w.r.t. modules/locking etc. in pre10.
Good luck,
Jurriaan
--
The guy sure looks like plantfood to me
Little Shop of Horrors
GNU/Linux 2.2.19pre10 SMP/ReiserFS 2x1402 bogomips load av: 0.02 0.05 0.05
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with Ramdisk in linux-2.4.1
Dear Mike , - Original Message - From: "Mike Galbraith" <[EMAIL PROTECTED]> To: "Jaswinder Singh" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, February 13, 2001 11:56 AM Subject: Re: Problem with Ramdisk in linux-2.4.1 > On Tue, 13 Feb 2001, Jaswinder Singh wrote: > > > Dear Mike and others , > > > > I am using compressed ramdisk , i can not turn off cramfs . > > (ok.. really is compressed) > > > my error messages are very strange and irreregular . > > > > i am getting 3 different kind of error messages :- > > > > invalid compressed format (err=1) > > OR > > invalid compressed format (err=2) > > OR > > crc error > > > > I am using gzip 1.2.4 (18 Aug 93) > > > > But when i use same ramdisk with old kernel like 2.2.12 , it works fine . > > Can you point me to a cramfs generation procedure? (never used > cramfs.. know where the docs are, but could use a small time warp) > make ramdisk as you normally do and then compress it by gzip . You can see documentation on Ramdisk in Documentation/ramdisk.txt if you have some time ;) Best Regards, Jaswinder. -- These are my opinions not 3Di. > -Mike > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LK] Re: lkml subject line
"Mike A. Harris" <[EMAIL PROTECTED]> wrote: >What is right: > >1) not putting the thing in the subject from the list side >2) If an end user wants it in the subject, they can set up a mail >filter to PUT it in the subject. > >:0 fwh >* ^Sender:.*owner-linux-kernel >| sed -e 's/^Subject: /Subject: [lkml]/' >:0 A: >lkml > >The above filter should add [lkml] to your subject line. So why >try to force it on everyone? The other lists to which I subscribe (SAG-L and HP3000-L) don't force it on everyone. Each subscriber can turn the extra subject tags on or off whenever they please. I have them turned on, so the listserver tacks them on each message that is mailed to me. People who have this option turned off (the default) never see them. >If the above procmail filter doesn't work (untested) let me know >and I will MAKE it work. Windows users - tough luck - procmail >is open source - hire someone to port it... My employer chose Lotus Notes for our email system. All incoming messages go to a Notes server. In order to read them, I have to run a Notes client to connect to the server. As far as I know, there is no way to use another mail reader to access the Notes email database on the server. So, although I run Linux on my laptop, I have to run Notes (under wine) to access my mail. There is no way to filter on headers; in fact, the ONLY headers I can see are To, cc, and Subject. (OK, I can, after opening a message, select "Delivery Information" from a menu, and then scroll through the other headers in a four line by 50 character window; but I have to do this for each message, one at a time, after they reach my inbox. There's no way to search for text in any of these headers, either.) Even if I save the messages to disk (by "exporting" them), I still get only those three headers. I can sort the list of messages in my inbox by sender or by date, but not by subject. So I usually just read everything in FIFO order, without even looking at the subject, hitting the delete key within a couple of seconds for any message that doesn't interest me. After finishing with all the messages, I use the extra tags in the Subject line to (visually) separate the messages I want to keep and move them into separate folders for each mailing list. I always leave the lkml messages till last, because without the extra tags I have to pay special attention to keep them separate from my regular (non-mailing-list) email. As far as I'm concerned, Notes is a lousy mail client. Very little can be configured by the user. The only option for quoted replies simply appends the entire message to the bottom of the reply. (I had to cut and paste your text and add the ">" characters and the "Mike Harris wrote:" line manually.) I can't even set it to automatically forward my mail to my personal email account if I'm out of town. That requires a request to a Notes administrator to do it for me, and I have to ask him to change it back when I return. Plus, when the mail is auto-forwarded it is deleted from my Notes inbox, so if the administrator is slow about turning off auto-forwarding then I don't see any of my business email at work and have to wait until I can access my personal account from home. I haven't complained about any of this on the list until now, because I know I'm in the minority and I don't expect most people to care about my problems. But it bothered me seeing the criticism Mike Harrold has gotten for his request. Not everyone has problems because they're lazy. Some of us are boxed in by decisions that are beyond our control. For my part, if anyone can tell me a method (that doesn't require Notes administrator assistance) to get my mail, with headers intact, out of Notes and into elm or pine, I'd be ecstatic. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI GART (?)
On Tue, 13 Feb 2001 12:09:32 + (GMT), Michèl Alexandre Salim <[EMAIL PROTECTED]> wrote: > Currently running the XFree 4.0.2 from RH 7.0.90 (7.1 > beta, Fisher) on top of my RH 7 + Ximian system and > when using aviplay it doesn't use any acceleration > features at all, consequently choppy display. The same > file plays much better in Windows. Get the XFree ati.2 drivers from http://www.linuxvideo.org/gatos/, and you will have hardware scaling. DRI is not supported yet. > Xdpyinfo shows that Xvideo and Xrender are both > loaded, so I presume they *should* work. xvinfo is a bit more informative about these things. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19ac-pre9 lo interface Broke
> I have some further info here. > I performed strace on ifup -a and ifdown -a. Unfortunately you traced the script execution and nothing more useful so I cant tell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
