Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
> > compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and > > Jakub > > ehhmm.. > > didn't barf here with 2.96-70. Which is correct - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bidirectional named pipe?
> I'm porting some software to Linux that requires use of a bidirectional, > named pipe. The architecture is as follows: A server creates a named pipe Pipes are not bidirectional in Linux. We follow traditional non stream behaviour > /dev/spx". I experiemented with socket-based pipes under Linux, but I > couldn't gain access to them by open()ing the name. Is there help? I AF_UNIX sockets are bidirectional but like all sockets use bind() and connect(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
> Please, do not do so. That depends on the PACKAGE name and version, and there > is no standard way of versioning a patched gcc. > The -54 is a RH'ism, for example Mandrake Cooker includes patches from > different sources, and gcc is versioned like > > werewolf:~# rpm -q gcc > gcc-2.96-0.33mdk Thats fine. It doesnt matcht he problem one. If you know which are the problem ones on Mandrake add those too You can also use if [ -e /bin/rpm ]; then if [ -e /etc/redhat-release ]; then - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
> kernel source is broken as designed. /usr/include/{linux,asm} must be
> real directories that are shipped as part of glibc, not symlinks to
> some random version of the kernel. Fix /usr/include.
You need to fix the kernel headers too - libc5 doesnt work otherwise
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Adding PCMCIA support to the kernel tree -- developers needed.
Hi, I asked David Hinds to write up an outline of the things that will be needed to get PCMCIA support cleanly and completely integrated into the kernel tree. David has expressed that he'll not be able to participate in this work. He has his hands full with his day job and his role as maintainer/developer of the pcmcia-cs package. David, I would appreciate one additional layer of information that is not present in your list. Would add the names of a few representative devices for each of your bullet points? For example, for the last list item, what are the names of the major (non-CardBus) PCI-to-PCMCIA bridges? Here is David's list: > To include 16-bit PCMCIA cards in the hot plug framework would require > few driver changes; the only mandatory changes would be in how drivers > register themselves and are hooked up with appropriate devices: > > -- Make up pcmcia_device_id and pcmcia_driver types, and write new >register/unregister calls to parallel PCI and USB drivers. This >would eventually take over for the "ds" module and cardmgr. > > -- Rewrite all PCMCIA client drivers to have MODULE_DEVICE_TABLE >entries and use the new driver services. This can all be done >incrementally, with ds/cardmgr handling old-style drivers. > > -- The CIS override functionality in the PCMCIA package is unpleasant >to support in a completely in-kernel framework. > > Missing functionality in the hot plug framework: > > -- Only new network devices generate /sbin/hotplug events now. Modify >all other device types to also do so: the ones currently handled by >PCMCIA include serial, parallel, SCSI (all types), and IDE. > > -- There is no mechanism to request a card eject in the new framework. >This is required for clean shutdown of SCSI and IDE adapters. > > -- The PCMCIA device configuration scripts have a lot of capabilities >that the hotplug scripts do not have yet. At the moment, the >extent of device-specific hotplug configuration is running "ifup". > > Missing functionality in the 2.4 PCMCIA drivers: > > -- The yenta driver can't handle CardBus adapter cards for desktop >systems. Many require explicit overrides for the default interrupt >delivery settings, and a few require other special bridge settings. > > -- The i82365 driver can't handle (non-CardBus) PCI-to-PCMCIA bridges >any more. Some of the PCI code in the old i82365 driver needs to >be put back. This list does seem to break out the work into chunks that can be tackled more or less independently. Anyone willing to sign up for some of this effort? Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[UPDATE] Zerocopy 2.4.1 rev 3
You know where to get it: ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.1-3.diff.gz Fixes: 1) pskb_expand_tail could corrupt SKB frag lists in some cases, leading to OOPS 2) Need to check for out of window data even in the partial packet cases of tcp_data_queue 3) Merged in some small net fixes from the AC patches. As of this moment, I know of no bugs (ie. corrupts data or crashes kernel) in the zerocopy patches. Some people have asked me about making a patch against the AC patches. It is doable, but would be quite a bit of work for me. If someone would like to do this and put those patches up somewhere, they can feel free to do so. Just let everyone on linux-kernel and netdev know about it. Probably, after the next zerocopy patch revision, I will ask Alan to add the zerocopy stuff to his tree anyways. Things really look good right now. Thanks. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAMFS
On Fri, 2 Feb 2001, Mike Galbraith wrote: > > Where exactly do you see the leaks? > > (I don't have a solid grip yet.. just starting to seek) Heh. I figured this must be a nice defenseless little buglet I could pick on (ramfs is pretty darn simple). Critter might not be quite as defenseless as I presumed ;-) Using ramfs under vm pressure breaks (hmm.. spinlock) instantly on my UP box. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: xirc2ps_cs driver timeouts/errors
I downloaded the pcmcia-cs 3.1.24 package and hand-merged the bugfix(es?)
into 2.4.1's xirc2ps_cs.c. A(n attempt at a) patch to bring 2.4.1
up to pcmcia-cs's version is attached to this email. So far, no
problems, but it'll be at least 48 hours before I can say whether
it happens or not.. This is also available at
http://incandescent.mp3revolution.net/kernel/xirc2ps_cs/.
Looking through logs, it appears as though the problem first
appeared in kernel 2.4.1-pre7, and has become frequent enough
to annoy me as of 2.4.1. Did anything change dealing w/ this
driver/card between 2.4.0 and 2.4.1-pre7?
On Fri, Feb 02, 2001 at 09:20:40PM -0800, David Hinds wrote:
>
> On Fri, Feb 02, 2001 at 11:54:31PM -0500, [EMAIL PROTECTED] wrote:
> >
> > Each time I get a transmit timeout, or UDP: short packet error,
> > networking on my laptop seems to go down. Reinsertion of the
> > card temporarily fixes it, and if I leave it long enough it
> > also fixes itself.
>
> Does the same happen with a 2.2 kernel and the 3.1.24 PCMCIA drivers?
> There is a bug fix in the 3.1.24 xirc2ps_cs driver that hasn't been
> merged into the kernel tree yet.
>
> -- Dave
--
"... 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]
diff -urN linux.old/drivers/net/pcmcia/xirc2ps_cs.c
linux/drivers/net/pcmcia/xirc2ps_cs.c
--- linux.old/drivers/net/pcmcia/xirc2ps_cs.c Thu Oct 26 19:52:16 2000
+++ linux/drivers/net/pcmcia/xirc2ps_cs.c Sat Feb 3 01:15:49 2001
@@ -382,6 +382,7 @@
static void do_powerdown(struct net_device *dev);
static int do_stop(struct net_device *dev);
+
/*=== Helper functions =*/
static void
flush_stale_links(void)
@@ -1348,7 +1349,6 @@
* packets */
lp->stats.rx_dropped++;
DEBUG(2, "%s: RX drop, too much done\n", dev->name);
- PutWord(XIRCREG0_DO, 0x8000); /* issue cmd: skip_rx_packet */
} else if (rsr & PktRxOk) {
struct sk_buff *skb;
@@ -1423,8 +1423,7 @@
if (!(rsr & PhyPkt))
lp->stats.multicast++;
}
- PutWord(XIRCREG0_DO, 0x8000); /* issue cmd: skip_rx_packet */
- } else {
+ } else { /* bad packet */
DEBUG(5, "rsr=%#02x\n", rsr);
}
if (rsr & PktTooLong) {
@@ -1439,6 +1438,9 @@
lp->stats.rx_fifo_errors++; /* okay ? */
DEBUG(3, "%s: Alignment error\n", dev->name);
}
+
+ /* clear the received/dropped/error packet */
+ PutWord(XIRCREG0_DO, 0x8000); /* issue cmd: skip_rx_packet */
/* get the new ethernet status */
eth_status = GetByte(XIRCREG_ESR);
Re: Missing modversions.h in module sources for 2.4.x?
On Fri, 02 Feb 2001 21:28:13 -0800, Martin Bogomolni <[EMAIL PROTECTED]> wrote: >c02817f0 usb_match_id_R__ver_usb_match_id >The solution was to add the #include header >into each of the drivers affected. Wrong. See http://www.tux.org/lkml/#s8-8 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Missing modversions.h in module sources for 2.4.x?
While trying to compile a new driver for an 802.11 pci card, I started work on upgrading the linux-wlan utilites to 2.4.0. Other than the usual small things (like replacing references to kfree_s with kfree) the work was going pretty smoothly. I spent a good hour though, trying to debug one problem. The device driver depends on having netlink in the kernel. When I attempted to load the driver however, it would give me an unresolved symbol error for netlink_broadcast, and netlink_kernel_create. A quick fgrep of /proc/ksyms showed the error.. No version information was included in the kernel symbol table. e.g. When loading usb-storage.o, with an SMP compiled kernel + modversions : insmod usb-storage Using /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved sd /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_deregister /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_free_dev /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_free_urb /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_inc_dev_use /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_alloc_urb /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_register /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_reset_device /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_string /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_submit_urb /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_control_msg /lib/modules/2.4.1-SMP/kernel/drivers/usb/storage/usb-storage.o: unresolved symbol usb_unlink_urb A quick peek at /proc/ksyms shows : fgrep usb_match_id /proc/ksyms c02817f0 usb_match_id_R__ver_usb_match_id ~ ~ ~ The solution was to add the #include header into each of the drivers affected. However, I have a feeling that there are a lot of these "gotchas" still out there in 2.4. Thoughts? Martin. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: xirc2ps_cs driver timeouts/errors
On Fri, Feb 02, 2001 at 11:54:31PM -0500, [EMAIL PROTECTED] wrote: > > Each time I get a transmit timeout, or UDP: short packet error, > networking on my laptop seems to go down. Reinsertion of the > card temporarily fixes it, and if I leave it long enough it > also fixes itself. Does the same happen with a 2.2 kernel and the 3.1.24 PCMCIA drivers? There is a bug fix in the 3.1.24 xirc2ps_cs driver that hasn't been merged into the kernel tree yet. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: did 2.4 messed up lilo?
I've now installed 21.6 downloaded from metlab and all seems to be ok now... well at least the dell box.. compaq boot sector may have been blown off for some reason..it won't boot at all athough this time it's a different way of being stuck like LI instead of LILO. I will try ibm box in the morning when the traffic is light. On Fri, Feb 02, 2001 at 05:58:21PM -0800, Miles Lane wrote: > Hmm. I just downloaded the lilo 21.6 source and the patch appears to > have > already been applied. I got 21.6 from: > > http://ftp.cnr.it/Linux/system/boot/lilo/lilo-21.6.1.tar.gz > > Miles Lane wrote: > > > > Chris Mason wrote: > > > > > > On Friday, February 02, 2001 03:36:18 PM -0500 [EMAIL PROTECTED] > > > wrote: > > > > > > > I'm not sure whether this problem is related > > > > to 2.4 kernel. > > > > > > > > > > I suspect it is a reiserfs problem, and that you are using lilo older than > > > 21.6. Are you mounting /boot with -o notail? > > > > > > Regardless, I'm willing to bet upgrading to lilo 21.6 will solve this. It > > > calls an ioctl reiserfs provides to unpack small files, and I've seen it > > > fix this exact problem on one of my devel boxes (no lilo prompt, append > > > lines in lilo.conf ignored). > > > > I also found this patch for lilo 21.6: > > > > http://industrial-linux.org/distro/download/lilo-21.6-glibc-2.2-reiserfs.patch > > > > Perhaps someone familiar with the lilo and reiserfs code could explain > > whether or not this patch is really needed. > > > > Miles > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: bidirectional named pipe?
Many thanks to all who have suggested to use UNIX domain sockets. That was my first thought--I just didn't know how to preserve the existing named interface. And yes, I have consulted several "decent" UNIX programming books which have led me to the likelihood that what I want to do cannot be done under Linux. A shame, really, even if it is a travestible, abominable way to do it. The common, named pipe interface was a way to maintain compatibility with legacy code of previous versions that are already out in the field. If I change the architecture now, folks porting from UnixWare to Linux (for example) will have to change their applications (maybe--I haven't fully analyzed whether I can change the underlying behavior without affecting our API) in order to use Linux. I am aware that the current design may not be the most efficient, or even the most portable, but I was hoping to maintain it for compatibility sake. If someone wants to tell me how to do it, great. If not, I'll assume it can't be done and start reworking everything to use socket() or socketpair(). Thanks all, Brendan Please cc: me on all replies. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
xirc2ps_cs driver timeouts/errors
My logs show the following: xirc2ps_cs.c 1.31 1998/12/09 19:32:55 (dd9jn+kvh) eth0: Xircom: port 0x300, irq 3, hwaddr 00:80:C7:1E:28:2A eth0: MII link partner: 0021 eth0: MII selected eth0: media 10BaseT, silicon revision 4 UDP: short packet: 137/58 NETDEV WATCHDOG: eth0: transmit timed out eth0: transmit timed out eth0: MII link partner: 0021 eth0: MII selected eth0: media 10BaseT, silicon revision 4 NETDEV WATCHDOG: eth0: transmit timed out eth0: transmit timed out eth0: MII link partner: 0021 eth0: MII selected eth0: media 10BaseT, silicon revision 4 UDP: short packet: 0/213 UDP: short packet: 0/58 Each time I get a transmit timeout, or UDP: short packet error, networking on my laptop seems to go down. Reinsertion of the card temporarily fixes it, and if I leave it long enough it also fixes itself. Hardware info: Socket 0: product info: "Xircom", "CreditCard 10/100", "CE3-10/100", "1.00" manfid: 0x0105, 0x010a function: 6 (network) Socket 0: Vcc 5.0V Vpp1 0.0V Vpp2 0.0V interface type is "memory and I/O" irq 3 [exclusive] [level] function 0: config base 0x0800 option 0x41 status 0x00 io 0x0300-0x030f [16bit] Bus 0, device 3, function 0: CardBus bridge: Texas Instruments PCI1225 (rev 1). IRQ 11. Master Capable. Latency=168. Min Gnt=192.Max Lat=5. Non-prefetchable 32 bit memory at 0x1000 [0x1fff]. Bus 0, device 3, function 1: CardBus bridge: Texas Instruments PCI1225 (#2) (rev 1). IRQ 11. Master Capable. Latency=168. Min Gnt=192.Max Lat=5. Non-prefetchable 32 bit memory at 0x10001000 [0x10001fff]. Kernel is stock 2.4.1. If any more info is needed, let me know. Please CC replies to me, as I'm not on the list. -- "... 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] Please read the FAQ at http://www.tux.org/lkml/
RE: IDE timeouts 2.4.1
Do not trust the second channel to ATA devices.
Only ATAPI can live there.
I watch it all day long eat my second drives.
The OSB4 is not a pretty thing to play with, and I will have the chance to
fix the CSB5 before it goes final.
Cheers,
On Fri, 2 Feb 2001, Dunlap, Randy wrote:
> I'm also getting a ton of these, along with lots of
> file corruption. I could handle the timeouts and
> rebooting every once in awhile if I didn't also have
> the corruption.
>
> Do I have some incorrect IDE parameters?
>
> (using 2.4.0, not 2.4.1)
> dual Pentium III 933 MHz (STL2 board)
> SAMSUNG 20 GB IDE hard drive
> ServerWorks chipset
>
> details--
>
> Feb 2 19:34:51 localhost kernel: Linux version 2.4.0
> ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease))
> #34 SMP Tue Jan 30 17:49:24 PST 2001
> Feb 2 19:35:00 localhost kernel: DMI table at 0x000EF5C0.
> Feb 2 19:35:00 localhost kernel: BIOS Vendor: Intel Corporation
> Feb 2 19:35:01 localhost kernel: BIOS Version:
> STL20.86B.0016.P01.001008
> Feb 2 19:35:01 localhost kernel: BIOS Release: 10/11/2000
> Feb 2 19:35:01 localhost kernel: System Vendor: Intel.
> Feb 2 19:35:01 localhost kernel: Product Name: STL2.
> Feb 2 19:35:01 localhost kernel: Version .
> Feb 2 19:35:01 localhost kernel: Serial Number .
> Feb 2 19:35:01 localhost kernel: Board Vendor: Intel.
> Feb 2 19:35:01 localhost kernel: Board Name: STL2.
> Feb 2 19:35:01 localhost kernel: Board Version: 133-639718.
> Feb 2 19:35:01 localhost kernel: Asset Tag: .
> Feb 2 19:35:01 localhost kernel: Uniform Multi-Platform E-IDE driver
> Revision: 6.31
> Feb 2 19:35:02 localhost kernel: ide: Assuming 33MHz system bus speed for
> PIO modes; override with idebus=xx
> Feb 2 19:35:02 localhost kernel: ServerWorks OSB4: IDE controller on PCI
> bus 00 dev 79
> Feb 2 19:35:02 localhost kernel: ServerWorks OSB4: chipset revision 0
> Feb 2 19:35:02 localhost kernel: ServerWorks OSB4: not 100% native mode:
> will probe irqs later
> Feb 2 19:35:02 localhost kernel: hda: SAMSUNG SV2006D fc2_17, ATA DISK
> drive
> Feb 2 19:35:02 localhost kernel: hdb: TOSHIBA CD-ROM XM-6402B, ATAPI CDROM
> drive
> Feb 2 19:35:02 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> Feb 2 19:35:02 localhost kernel: hda: 40142592 sectors (20553 MB) w/480KiB
> Cache, CHS=2498/255/63
> Feb 2 19:35:02 localhost kernel: hdb: ATAPI 32X CD-ROM drive, 256kB Cache
> Feb 2 19:35:02 localhost kernel: Uniform CD-ROM driver Revision: 3.12
> Feb 2 19:35:02 localhost kernel: Partition check:
> Feb 2 19:35:02 localhost kernel: hda: hda1 hda2 hda3 < hda5 hda6 hda7 >
>
> /dev/hda:
> Model=SAMSUNG SV2006D fc2_17, FwRev=LS100, SerialNo=V7**BT0521
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
> BuffType=DualPortCache, BuffSize=480kB, MaxMultSect=16, MultSect=off
> CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=40142592
> IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: sdma0 sdma1 sdma2 *mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3
> udma4
>
> /dev/hda:
> I/O support = 0 (default 16-bit)
>
>CPU0 CPU1
> 0: 15519 9063IO-APIC-edge timer
> 1:404289IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 12: 0 0IO-APIC-edge PS/2 Mouse
> 14: 21517 20366IO-APIC-edge ide0
> 18:138121 IO-APIC-level eth0
> NMI: 24511 24512
> LOC: 24491 24492
> ERR: 0
>
> 00:0f.1 IDE interface: Relience Computer: Unknown device 0211 (prog-if 8a
> [Master SecP PriP])
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> SERR-Latency: 64 set
> Region 4: I/O ports at 5440 [size=16]
>
>
> ~Randy_
>
> Michael D. Black wrote:
> Happens every night on both hda and hdc -- no sure yet what triggers it but
> it is repeatable. Has happened since I've installed this machine with all
> the 2.4.x series.
> Jan 31 00:34:16 kernel: hdc: timeout waiting for DMA
> Jan 31 00:34:16 kernel: ide_dmaproc: chipset supported ide_dma_timeout func
> only: 14
> Jan 31 00:34:16 kernel: hdc: irq timeout: status=0x58 { DriveReady
> SeekComplete DataRequest }
> Jan 31 00:34:26 kernel: hdc: timeout waiting for DMA
> Jan 31 00:34:26 kernel: ide_dmaproc: chipset supported ide_dma_timeout func
> only: 14
> Jan 31 00:34:26 kernel: hdc: irq timeout: status=0x58 { DriveReady
> SeekComplete DataRequest }
> Jan 31 00:34:36 kernel: hdc: timeout waiting for DMA
> Jan 31 00:34:36 kernel: ide_dmaproc: chipset supported ide_dma_timeout func
>
Re: Fix for include/linux/fs.h in 2.4.0 kernels
> "Brian" == Brian Wellington <[EMAIL PROTECTED]> writes: Brian> No, it clearly says that glibc contains its own versions of Brian> the net/* and scsi/* files, and that /usr/include/asm and Brian> /usr/include/linux should remain as they were. Since they Brian> were symlinks in libc5 (which is what 'originally' seems to Brian> be referring to), they should still be symlinks. Oh I see now. Sorry for any confusion caused. -- Brian May <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
On 3 Feb 2001, Brian May wrote:
> > "Keith" == Keith Owens <[EMAIL PROTECTED]> writes:
>
> >> {PB} This was necessary for libc5, but is not correct when
> >> using glibc. Including the kernel header files directly in user
> >> programs usually does not work (see question 3.5). glibc
> >> provides its own and header files to replace
> >> them, and you may have to remove any symlink that you have in
> >> place before you install glibc. However, /usr/include/asm and
> >> /usr/include/linux should remain as they were.
> >>
> >> Keith, are you saying that glibc is wrong?
>
> Keith> Not me, Linus says that glibc is wrong.
>
> Keith> "I've asked glibc maintainers to stop the symlink
> Keith> insanity for the last few years now, but it doesn't seem to
> Keith> happen.
>
> Keith> Basically, that symlink should not be a symlink. It's a
> Keith> symlink for historical reasons, none of them very good any
> Keith> more (and haven't been for a long time), and it's a
> Keith> disaster unless you want to be a C library developer.
> Keith> Which not very many people want to be.
>
> Keith> The fact is, that the header files should match the
> Keith> library you link against, not the kernel you run on."
>
>
> I read Keith's response as: the symlink is wrong.
> I read the glib FAQ as: the symlink is wrong.
> I read Linus' response as: the symlink is wrong.
>
> Who is contradicting who here?
>
> (perhaps that last sentence in the glibc FAQ is confusing, however the
> rest of it clearly says that glibc contains its own version of those
> files, and a symlink should *not* be used. I think the part "[...] you
> may have to remove any symlink [...]" is clear enough).
No, it clearly says that glibc contains its own versions of the net/* and
scsi/* files, and that /usr/include/asm and /usr/include/linux should
remain as they were. Since they were symlinks in libc5 (which is what
'originally' seems to be referring to), they should still be symlinks.
Brian (who really doesn't care either way)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
On Fri, 2 Feb 2001, Jakub Jelinek wrote:
> You can do:
> if [ "$CC" = gcc ]; then
> echo 'inline void f(unsigned int n){int
>i,j=-1;for(i=0;i<10&<0;i++)if((1UL< > test.c
> gcc -O2 -o test test.c
> if ./test; then echo "*** Please don't use this compiler to compile kernel"; fi
> rm -f test.c test
> fi
>
> (the $CC = gcc test is there e.g. so that the test is not done when
> cross-compiling or when there is a separate kernel compiler and userland
> compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and
>
> Jakub
ehhmm..
[root@fogarty /tmp]# rpm -q gcc
gcc-2.96-70
[root@fogarty /tmp]# cat test.c
inline void f(unsigned int n){int
i,j=-1;for(i=0;i<10&<0;i++)if((1UL
Re: Fix for include/linux/fs.h in 2.4.0 kernels
> "Keith" == Keith Owens <[EMAIL PROTECTED]> writes:
>> {PB} This was necessary for libc5, but is not correct when
>> using glibc. Including the kernel header files directly in user
>> programs usually does not work (see question 3.5). glibc
>> provides its own and header files to replace
>> them, and you may have to remove any symlink that you have in
>> place before you install glibc. However, /usr/include/asm and
>> /usr/include/linux should remain as they were.
>>
>> Keith, are you saying that glibc is wrong?
Keith> Not me, Linus says that glibc is wrong.
Keith> "I've asked glibc maintainers to stop the symlink
Keith> insanity for the last few years now, but it doesn't seem to
Keith> happen.
Keith> Basically, that symlink should not be a symlink. It's a
Keith> symlink for historical reasons, none of them very good any
Keith> more (and haven't been for a long time), and it's a
Keith> disaster unless you want to be a C library developer.
Keith> Which not very many people want to be.
Keith> The fact is, that the header files should match the
Keith> library you link against, not the kernel you run on."
I read Keith's response as: the symlink is wrong.
I read the glib FAQ as: the symlink is wrong.
I read Linus' response as: the symlink is wrong.
Who is contradicting who here?
(perhaps that last sentence in the glibc FAQ is confusing, however the
rest of it clearly says that glibc contains its own version of those
files, and a symlink should *not* be used. I think the part "[...] you
may have to remove any symlink [...]" is clear enough).
--
Brian May <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Reasons to honor readonly mount requests
Jeff writes: > I understand that both ext3fs and > reiserfs will try to fix corrupt filesystems (or at least filesystems > with unprocessed log entries) in-place even if they're mounted > read-only. Clearly, virtual replay means more work, but -- just for > fun -- here are some cases in which it might matter: > > 1. You want the disk image untouched for forensic analysis or data >recovery. > 2. You don't trust the disk to do writes properly. > 3. You don't trust the driver to do writes properly. > 4. You want to test a newer or unstable FS implementation w/ option to >go back to the older one. Excluding the root fs (which probably isn't involved in these sorts of things anyways), you can always turn off the "RECOVERY" flag on the filesystem and mount ext3 as ext2, which will not do any recovery. > 5. You're sharing the disk via: > VMWare (multiple OS instances on 1 computer) > passive backplane (multiple computers on 1 bus) > PCI bridge (multiple computers w/ connected buses) > SCSI/FC/FireWire (multiple computers sharing device) > > The merit of #5 is reduced but not quite obviated by the fact that > it's generally unsafe to share a disk if even one party is writing to it. Very true. Any changes made by the writer will not be noticed by the reader if it has already cached those pages. Best to use a cluster filesystem in all of these cases. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A buglet with LVM-0.9.1
J Sloan writes: > I discovered that lvm seems to have a problem > with compaq raid controllers - the partitions > don't have the normal names like /dev/sda1, > but instead names like /dev/ida/c0d0p1 - > > lvm seems to works OK, but lvmdiskscan freaks... > > lvmdiskscan -- filling directory cache... > lvmdiskscan -- walking through all found disks / partitions > lvmdiskscan -- /dev/ida/c0d0p1 [1000.06 MB] free whole disk > lvmdiskscan -- no valid disks / partitions found > lvmdiskscan -- please check your disk device special files! LVM _should_ take care of such devices as well, because there are several block devices which don't live directly in /dev, especially with devfs. According to "lvm_dir_cache.c", it should already check /dev/ida for disks. If it doesn't work for you, this is a bug. It would be useful if you ran "lvmdiskscan -d" and "cat /proc/partitions" and sent the output to [EMAIL PROTECTED] Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: IDE timeouts 2.4.1
I'm also getting a ton of these, along with lots of
file corruption. I could handle the timeouts and
rebooting every once in awhile if I didn't also have
the corruption.
Do I have some incorrect IDE parameters?
(using 2.4.0, not 2.4.1)
dual Pentium III 933 MHz (STL2 board)
SAMSUNG 20 GB IDE hard drive
ServerWorks chipset
details--
Feb 2 19:34:51 localhost kernel: Linux version 2.4.0
([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease))
#34 SMP Tue Jan 30 17:49:24 PST 2001
Feb 2 19:35:00 localhost kernel: DMI table at 0x000EF5C0.
Feb 2 19:35:00 localhost kernel: BIOS Vendor: Intel Corporation
Feb 2 19:35:01 localhost kernel: BIOS Version:
STL20.86B.0016.P01.001008
Feb 2 19:35:01 localhost kernel: BIOS Release: 10/11/2000
Feb 2 19:35:01 localhost kernel: System Vendor: Intel.
Feb 2 19:35:01 localhost kernel: Product Name: STL2.
Feb 2 19:35:01 localhost kernel: Version .
Feb 2 19:35:01 localhost kernel: Serial Number .
Feb 2 19:35:01 localhost kernel: Board Vendor: Intel.
Feb 2 19:35:01 localhost kernel: Board Name: STL2.
Feb 2 19:35:01 localhost kernel: Board Version: 133-639718.
Feb 2 19:35:01 localhost kernel: Asset Tag: .
Feb 2 19:35:01 localhost kernel: Uniform Multi-Platform E-IDE driver
Revision: 6.31
Feb 2 19:35:02 localhost kernel: ide: Assuming 33MHz system bus speed for
PIO modes; override with idebus=xx
Feb 2 19:35:02 localhost kernel: ServerWorks OSB4: IDE controller on PCI
bus 00 dev 79
Feb 2 19:35:02 localhost kernel: ServerWorks OSB4: chipset revision 0
Feb 2 19:35:02 localhost kernel: ServerWorks OSB4: not 100% native mode:
will probe irqs later
Feb 2 19:35:02 localhost kernel: hda: SAMSUNG SV2006D fc2_17, ATA DISK
drive
Feb 2 19:35:02 localhost kernel: hdb: TOSHIBA CD-ROM XM-6402B, ATAPI CDROM
drive
Feb 2 19:35:02 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Feb 2 19:35:02 localhost kernel: hda: 40142592 sectors (20553 MB) w/480KiB
Cache, CHS=2498/255/63
Feb 2 19:35:02 localhost kernel: hdb: ATAPI 32X CD-ROM drive, 256kB Cache
Feb 2 19:35:02 localhost kernel: Uniform CD-ROM driver Revision: 3.12
Feb 2 19:35:02 localhost kernel: Partition check:
Feb 2 19:35:02 localhost kernel: hda: hda1 hda2 hda3 < hda5 hda6 hda7 >
/dev/hda:
Model=SAMSUNG SV2006D fc2_17, FwRev=LS100, SerialNo=V7**BT0521
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
BuffType=DualPortCache, BuffSize=480kB, MaxMultSect=16, MultSect=off
CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=40142592
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 *mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3
udma4
/dev/hda:
I/O support = 0 (default 16-bit)
CPU0 CPU1
0: 15519 9063IO-APIC-edge timer
1:404289IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
12: 0 0IO-APIC-edge PS/2 Mouse
14: 21517 20366IO-APIC-edge ide0
18:138121 IO-APIC-level eth0
NMI: 24511 24512
LOC: 24491 24492
ERR: 0
00:0f.1 IDE interface: Relience Computer: Unknown device 0211 (prog-if 8a
[Master SecP PriP])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- http://www.tux.org/lkml/
Reasons to honor readonly mount requests
On Thu, Jan 04 2001 at 17:49:46 EST, Stephen C. Tweedie wrote: > I will be adding support for virtual replay for root filesystems to > act as a last-chance way of recovering if you really cannot write to > the root, but journaling filesystems really do expect to be able to > write to the media so I am not sure whether it makes sense to support > this on non-root filesystems too. > ... > A root fs readonly mount is usually designed to prevent > the filesystem from being stomped on during the initial boot so that > fsck can run without the filesystem being volatile. That's the only > reason for the readonly mount: to allow recovery before we enable > writes. With ext3, that recovery is done in the kernel, so doing that > recovery during mount makes perfect sense even if the user is mounting > root readonly. Apologies for a belated follow-up, but the coverage of this thread in Kernel Traffic caught my eye. I understand that both ext3fs and reiserfs will try to fix corrupt filesystems (or at least filesystems with unprocessed log entries) in-place even if they're mounted read-only. Clearly, virtual replay means more work, but -- just for fun -- here are some cases in which it might matter: 1. You want the disk image untouched for forensic analysis or data recovery. 2. You don't trust the disk to do writes properly. 3. You don't trust the driver to do writes properly. 4. You want to test a newer or unstable FS implementation w/ option to go back to the older one. 5. You're sharing the disk via: VMWare (multiple OS instances on 1 computer) passive backplane (multiple computers on 1 bus) PCI bridge (multiple computers w/ connected buses) SCSI/FC/FireWire (multiple computers sharing device) The merit of #5 is reduced but not quite obviated by the fact that it's generally unsafe to share a disk if even one party is writing to it. (It might barely be possible do safe one-writer/many-reader disk sharing using a phase-tree-like FS, but as interesting projects go, it probably rivals heterogeneous SMP in perversity.) Come to think of it, you could probably use loopback to insulate the disk from writes in all these cases. Hmm. Please CC me on any follow-ups. --Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS Oops (2.4.1, deterministic, symlink related)
Ion Badulescu <[EMAIL PROTECTED]> writes: > On Fri, 2 Feb 2001, Alan Cox wrote: > > > Oh I can see why Hans wants to cut down his bug reporting load. I can also > > say from experience it wont work. If you put #error in then everyone will > > mail him and complain it doesnt build, if you put #warning in nobody will > > read it and if you dont put anything in you get the odd bug report anyway. > > > > Basically you can't win and unfortunately a shrink wrap forcing the user > > to read the README file for the kernel violates the GPL .. > > Oh, don't get me wrong, I fully understand that it's a lose-lose > situation. All I'm saying is that it was an incredibly bad idea to have > two compilers, one broken and one ok, identify themselves as the same > version. unfortunately, it's not limited to redhat and it's not limited to redhat's gcc-2.96. gcc-2.95.2 has some bugs (a certain strength reduction bug comes to mind). no new official gcc has come for over a year. many distributions have applied a patch to fix the strength reduction bug. do they all alter their version number? of those that do, do they alter it consistently? -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
On Sat, 3 Feb 2001 00:49:26 -0200,
Fr d ric L. W. Meunier <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> Relying on /usr/include/{linux,asm} always pointing at the
>> current kernel source is broken as designed.
>
>From glibc 2.2.1 FAQ:
>
>2.17. I have /usr/include/net and /usr/include/scsi as symlinks
> into my Linux source tree. Is that wrong?
>
>{PB} This was necessary for libc5, but is not correct when
>using glibc. Including the kernel header files directly in user
>programs usually does not work (see question 3.5). glibc
>provides its own and header files to replace
>them, and you may have to remove any symlink that you have in
>place before you install glibc. However, /usr/include/asm and
>/usr/include/linux should remain as they were.
>
>Keith, are you saying that glibc is wrong?
Not me, Linus says that glibc is wrong.
"I've asked glibc maintainers to stop the symlink insanity for the
last few years now, but it doesn't seem to happen.
Basically, that symlink should not be a symlink. It's a symlink for
historical reasons, none of them very good any more (and haven't been
for a long time), and it's a disaster unless you want to be a C
library developer. Which not very many people want to be.
The fact is, that the header files should match the library you link
against, not the kernel you run on."
http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
for the rest of Linus's reasons.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
> "Frédéric" == Frédéric L W Meunier <[EMAIL PROTECTED]> writes:
Frédéric> Keith Owens wrote:
>> Rule 2. Any glibc that has a symlink from
>> /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}
>> is wrong.
Frédéric> Such symlinks are created by the user.
>> Relying on /usr/include/{linux,asm} always pointing at the
>> current kernel source is broken as designed.
Frédéric> From glibc 2.2.1 FAQ:
Frédéric> 2.17. I have /usr/include/net and /usr/include/scsi as
Frédéric> symlinks into my Linux source tree. Is that wrong?
Frédéric> {PB} This was necessary for libc5, but is not correct
Frédéric> when using glibc. Including the kernel header files
Frédéric> directly in user programs usually does not work (see
Frédéric> question 3.5). glibc provides its own and
Frédéric> header files to replace them, and you may have
Frédéric> to remove any symlink that you have in place before you
Frédéric> install glibc. However, /usr/include/asm and
Frédéric> /usr/include/linux should remain as they were.
Frédéric> Keith, are you saying that glibc is wrong?
You both seem to be saying the same thing: that symlinks for
/usr/include/{linux,asm} are wrong.
Why try to argue when you agree?
(Debian does this right; last I heard Red-Hat didn't)
--
Brian May <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
Keith Owens wrote:
> Rule 2. Any glibc that has a symlink from
> /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}
> is wrong.
Such symlinks are created by the user.
> Relying on /usr/include/{linux,asm} always pointing at the
> current kernel source is broken as designed.
From glibc 2.2.1 FAQ:
2.17. I have /usr/include/net and /usr/include/scsi as symlinks
into my Linux source tree. Is that wrong?
{PB} This was necessary for libc5, but is not correct when
using glibc. Including the kernel header files directly in user
programs usually does not work (see question 3.5). glibc
provides its own and header files to replace
them, and you may have to remove any symlink that you have in
place before you install glibc. However, /usr/include/asm and
/usr/include/linux should remain as they were.
Keith, are you saying that glibc is wrong?
3.5.On Linux I've got problems with the declarations in Linux
kernel headers.
{UD,AJ} On Linux, the use of kernel headers is reduced to the
minimum. This gives Linus the ability to change the headers
more freely. Also, user programs are now insulated from changes
in the size of kernel data structures.
For example, the sigset_t type is 32 or 64 bits wide in the
kernel. In glibc it is 1024 bits wide. This guarantees that
when the kernel gets a bigger sigset_t (for POSIX.1e realtime
support, say) user programs will not have to be recompiled.
Consult the header files for more information about the
changes.
Therefore you shouldn't include Linux kernel header files
directly if glibc has defined a replacement. Otherwise you
might get undefined results because of type conflicts.
> /usr/include/{linux,asm} must be real directories that are
> shipped as part of glibc, not symlinks to some random version
> of the kernel. Fix /usr/include.
But make install didn't create them. I built 2.2 and 2.2.1.
--
Frédéric L. W. Meunier - http://www.pervalidus.net/
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: bidirectional named pipe?
> I've countless web searches and linux-kernel archives, but I haven't yet
> found the answer to my question.
>
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named pipe
> in the /tmp directory. Any client can then open("/tmp/pipename",
> O_RDWR|O_NDELAY) and gain access to the server. The pipe is bidirectional,
> so the client and server communicate on the same pipe. I support a number
> of clients on the single pipe using file-locking to prohibit from two
> clients from writing/reading at once.
>
> How can I do this under Linux? In SVR4 Unices, I just use pipe() as it's
> pipes are bidirectional, and I can attach a name with fattach(). In SVR3
> Unices, I go through a bunch of hacking using the "stream clone device --
> /dev/spx". I experiemented with socket-based pipes under Linux, but I
> couldn't gain access to them by open()ing the name. Is there help? I
> really don't want to use LiS (the Linux Streams) package, as I'd rather do
> something native and not be dependent on another module. Plus, I read
> somewhere that this was a poor way to do things.
How about use a unix socket instead of a named pipe.
--
Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
On Fri, 2 Feb 2001, David Lang wrote: > Thanks, that info on sendfile makes sense for the fileserver situation. > for webservers we will have to see (many/most CGI's look at stuff from the > client so I still have doubts as to how much use cacheing will be) CGI performance isn't directly affected by this - the whole point is to reduce the "cost" of handling static requests to zero (at least, as close as possible) leaving as much CPU as possible for the CGI to use. So sendfile won't help your CGI directly - it will just give your CGI more resources to work with. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: svgalib problem
> svgalib: mmap error in paged screen memory.
A fix is to build SVGAlib without background execution support.
Take a look at http://www.arava.co.il/matan/svgalib/hypermail/
--
Frédéric L. W. Meunier - http://www.pervalidus.net/
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
On Sat, 3 Feb 2001, Hans Reiser wrote: > Alan Cox wrote: > > > > > It makes sense to refuse to build a piece of the kernel if it break's > > > a machine - anything else is a timebomb waiting to explode. > > > > The logical conclusion of that is to replace the entire kernel tree with > > > > #error "compiler or program might have a bug. Aborting" > > No, this is a compiler that DOES have a bug. ReiserFS is, as best as > I can make it, for mission critical servers where some sysadmin > doesn't want to explain it to the CEO. There are plenty of ways that > I fail at this, but not intentionally. Yep. For once, I agree with Hans here: if you *KNOW* the current compiler is fatally broken, the best thing to do is blow up. As hard as possible, as soon as possible. Anything else is just hiding the problem. (snip) > My design objective in ReiserFS is not to say that it wasn't my fault > they had that bug because they are so ignorant about a filesystem that > really isn't very important to them unless it screws up. My design > objective is to ensure they don't have that bug. They are more > important than me. Hrm... better idiot-proofing just tends to produce better idiots. > > The kernel is NOT some US home appliance festooned with 'do not eat this > > furniture' and 'do not expose your laserwrite to naked flame' messages. > > The readme says its been tested with egcs-1.1.2 and gcc 2.95. Hrm. Ever wonder which country Alan lives in? :-) (Alan: Visit the next McDonalds you pass, and buy a coffee. Look at the warning on the side about the coffee being hot... then complain it isn't, after a suitable delay...) > > Large numbers of people routinely build the kernel with 'unsupported' compilers > > notably the pgcc project people and another group you will cause problems for > > - the GCC maintainers. They use the kernel tree as part of the test set for > > their kernel, something putting #ifdefs all over it will mean they have to > > mess around to fix too. If it's specific enough to that particular gcc, it won't trip the gcc people up - unless they're really using that specific version, in which case it SHOULD blow up anyway! > A moment of precision here. We won't test to see if the right > compiler is used, we will just test for the wrong one. Which is fine, IMO. "Warning: your compiler MIGHT be broken - please look at README" is OK, as is "Error: this compiler *IS* broken - it's gcc X.XX, which we know is broken because (foo)". "Error: this compiler looks like version foo, which we think might be broken" isn't, as Alan says... James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: did 2.4 messed up lilo?
Hmm. I just downloaded the lilo 21.6 source and the patch appears to have already been applied. I got 21.6 from: http://ftp.cnr.it/Linux/system/boot/lilo/lilo-21.6.1.tar.gz Miles Lane wrote: > > Chris Mason wrote: > > > > On Friday, February 02, 2001 03:36:18 PM -0500 [EMAIL PROTECTED] > > wrote: > > > > > I'm not sure whether this problem is related > > > to 2.4 kernel. > > > > > > > I suspect it is a reiserfs problem, and that you are using lilo older than > > 21.6. Are you mounting /boot with -o notail? > > > > Regardless, I'm willing to bet upgrading to lilo 21.6 will solve this. It > > calls an ioctl reiserfs provides to unpack small files, and I've seen it > > fix this exact problem on one of my devel boxes (no lilo prompt, append > > lines in lilo.conf ignored). > > I also found this patch for lilo 21.6: > > http://industrial-linux.org/distro/download/lilo-21.6-glibc-2.2-reiserfs.patch > > Perhaps someone familiar with the lilo and reiserfs code could explain > whether or not this patch is really needed. > > Miles > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 - can't read root fs (devfs maybe?)
> image=/boot/bzImage > label=linux > append="root=/dev/ide/host0/bus0/target0/lun0/part1 vga=3845" root=/dev/ide/host will work the same as root=/dev/hda... in pre-devfs -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: did 2.4 messed up lilo?
Chris Mason wrote: > > On Friday, February 02, 2001 03:36:18 PM -0500 [EMAIL PROTECTED] > wrote: > > > I'm not sure whether this problem is related > > to 2.4 kernel. > > > > I suspect it is a reiserfs problem, and that you are using lilo older than > 21.6. Are you mounting /boot with -o notail? > > Regardless, I'm willing to bet upgrading to lilo 21.6 will solve this. It > calls an ioctl reiserfs provides to unpack small files, and I've seen it > fix this exact problem on one of my devel boxes (no lilo prompt, append > lines in lilo.conf ignored). I also found this patch for lilo 21.6: http://industrial-linux.org/distro/download/lilo-21.6-glibc-2.2-reiserfs.patch Perhaps someone familiar with the lilo and reiserfs code could explain whether or not this patch is really needed. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug report
On Thu, Feb 01 2001, Anders S. Buch wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > It seems that the ide/cdrom/amd756 code can cause some bad lockups, at > least on my system. I have an Athlon 500 system running the 2.4.1 kernel > with Redhat 6.1 + updated modutils, etc. Have you tried disabling DMA on the atapi drive, not all do atapi dma in an orderly fashion (yet)? -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18: weird eepro100 msgs
On Fri, 2 Feb 2001, Ion Badulescu wrote: > On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos <[EMAIL PROTECTED]> wrote: > > > Sometimes when I reboot the system, as soon as the eepro100 module is > > loaded, I start to get these msgs on the screen: > > > > eth0: card reports no resources. > > eth0: card reports no RX buffers. > > eth0: card reports no resources. > > eth0: card reports no RX buffers. > > eth0: card reports no resources. > > eth0: card reports no RX buffers. > > (...) > > Does the following patch, taken from 2.4.1, help? I'm currently testing. I'll get back to you soon (have to reboot the system a lot to make sure it's really solved ... :)). Thanks for the quick response!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CPU capabilities -- an update proposal
Hugh Dickins wrote: > > I wonder (you or hpa may very quickly point out why this is stupid > and impossible), could we move the identify_cpu() calls into > cpu_init()? I used to think it was called too early for that, but > now I see it's already using current, smp_processor_id(), printk(). > I like that idea. I think it would clean up a lot of crud. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: bidirectional named pipe?
I thought mkfifo was only unidirectional...
Brendan
Please cc: me personally, as I am not subscribed.
-Original Message-
From: J . A . Magallon [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 4:47 PM
To: Miller, Brendan
Cc: 'linux-kernel @ vger . kernel . org'
Subject: Re: bidirectional named pipe?
Perhaps man 2 mkfifo ?
On 02.03 "Miller, Brendan" wrote:
>
> I've countless web searches and linux-kernel archives, but I haven't yet
> found the answer to my question.
>
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named
pipe
> in the /tmp directory. Any client can then open("/tmp/pipename",
> O_RDWR|O_NDELAY) and gain access to the server. The pipe is
bidirectional,
> so the client and server communicate on the same pipe. I support a number
> of clients on the single pipe using file-locking to prohibit from two
> clients from writing/reading at once.
>
> How can I do this under Linux? In SVR4 Unices, I just use pipe() as it's
> pipes are bidirectional, and I can attach a name with fattach(). In SVR3
> Unices, I go through a bunch of hacking using the "stream clone device --
> /dev/spx". I experiemented with socket-based pipes under Linux, but I
> couldn't gain access to them by open()ing the name. Is there help? I
> really don't want to use LiS (the Linux Streams) package, as I'd rather do
> something native and not be dependent on another module. Plus, I read
> somewhere that this was a poor way to do things.
>
> Brendan
>
> Please cc: me personally, as I am not subscribed.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
--
J.A. Magallon $> cd pub
mailto:[EMAIL PROTECTED] $> more
beer
Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: DFE-530TX with no mac address
On 2 Feb 2001, at 20:17, Urban Widmark wrote:
>
> > >I did this and compiled it into the kernel. It detects it at boot
> > >(via- rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the
> > >hardware address (mac address?) is 00-00-00-00-00-00.
>
> This is a good example of what is missed by not copying the exact
> message. For example, mine says:
Im Sorry.
> eth0: VIA VT3043 Rhine at 0xd400, 00:50:ba:a4:15:86, IRQ 19.
> eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link
> .
>
> Does it say "VIA VT6102 Rhine-II" for both of you?
> If not, could you do an 'lspci -n'?
Yep (see attachments), as bootup:-
via-rhine.c:v1.08b-LK1.1.6 8/9/2000 Written by Donald Becker
http://www.scyld.com/network/via-rhine.html
PCI: Found IRQ 9 for device 00:0a.0
eth0: VIA VT6102 Rhine-II at 0xd400, 00:00:00:00:00:00, IRQ 9.
> My VT3043 survives win98, but it may be a new feature in the newer
> chip. It may be a bios setting or something ...
>
>
> > I have an identical card, which usually works - except when I've
> > rebooted from Windows, when it shows the above symptoms. After
> > using Windows, I have to power the machine off, including turning
> > off the "standby power" switch on the PSU, then turn it back on and
> > boot straight into Linux. Very occasionally it also loses
> > "identity" and requires a similar reset, even when running Linux.
>
> Yes, the card is in some (for the linux driver) unknown state.
> Powering off completely resets it. Something that could help someone
> find out what is going on is running these two commands, both when the
> card is working and when it is not.
>
> via-diag -aaeemm
> lspci -vvvxxx -d 1106:3065
>
> via-diag is available from http://www.scyld.com/diag/index.html
>
> (1106:3065 is the pci id, if lspci -n gives you a different number you
> use
> that of course.)
>
> /Urban
>
I can now get my card to work (when I unplug the box), thank u
people.
My device is 00:0a.0, which is 1106:3065 (as u said)
I have supplyed my outputs from via-diag and lspci in body and as
attachments. Sorry for the long message.
tom
via-daig -aaeemm, with card not working:-
via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED])
http://www.scyld.com/diag/index.html
Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400.
Station address 00:00:00:00:00:00.
Tx disabled, Rx disabled, half-duplex (0x0804).
Receive mode is 0x00: Unknown/invalid.
Transmit mode is 0x00: Normal transmit, 128 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
0x000: 0804
0x020: 0400
0x040:
feff
0x060: 0e09131f 8100
0880 0247
No interrupt sources are pending ().
Access to the EEPROM has been disabled (0x80).
Direct reading or writing is not possible.
EEPROM contents (Assumed from chip registers):
0x100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x110: 00 00 00 00 00 00 00 00 09 0e 00 00 47 02 73 73
***WARNING***: No MII transceivers found!
via-diag -aaeemm, with card working:-
via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED])
http://www.scyld.com/diag/index.html
Index #1: Found a VIA VT3065 Rhine-II adapter at 0xd400.
Station address 00:50:ba:6e:d8:55.
Tx enabled, Rx enabled, full-duplex (0x0c5a).
Receive mode is 0x6c: Normal unicast and hashed multicast.
Transmit mode is 0x20: Normal transmit, 256 byte threshold.
VIA VT3065 Rhine-II chip registers at 0xd400
0x000: 6eba5000 206c55d8 0c5a 4eff 8000
01264010 01264190
0x020: 8400 0600 079ae810 01264020 8000
0600 079ad010 01264030
0x040: 00e08000 012641a0
013c013c feff
0x060: 00061108 782d8100
0880 0247
No interrupt sources are pending ().
Access to the EEPROM has been disabled (0x80).
Direct reading or writing is not possible.
EEPROM contents (Assumed from chip registers):
0x100: 00 50 ba 6e d8 55 00 00 00 00 00 00 00 00 00 00
0x110: 00 00 00 00 00 00 00 00 06 00 00 00 47 02 73 73
MII PHY found at address 8, status 0x782d.
MII PHY #8 transceiver registers:
3000 782d 0016 f880 01e1 4461
0022 ff40 0050 ffc0 00a0
.
lspci -vvxxx with card not working:-
00:0a.0 Ethernet controller: VIA Technologies, Inc.: Unknown
device 3065 (rev 42)
Subsystem: D-Link System Inc: Unknown device 1400
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+
VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr-
DEVSEL=medium >TAbort- SERR- TAbort- SERR-
via-diag.c:v2.04 7/14/2000 Donald Becker ([EMAIL PROTECTED])
Re: Keyboard Scancode Problems
Hi Udo! On Thu, 01 Feb 2001, Udo A. Steinberg wrote: > > Hi all, > > With all the latest kernels (at least since 2.4.0-test12) > I have had occasional problems with a PS/2 keyboard when > switching back and forth between X and text consoles. > > In most cases the problem occurs when switching from X to > a text console, which renders the keyboard totally unusable. > Pressing any key results in ^W ^E and other garbage. > Sometimes pressing Ctrl fixes the problem, other times not > even SysRq works. > > The kernel logs the following stuff: > > keyboard: unrecognized scancode (70) - ignored > keyboard: unrecognized scancode (66) - ignored > keyboard: unknown scancode e0 71 > keyboard: unknown scancode e0 70 > > and so forth. I cannot reliably reproduce it though. > > Can someone enlighten me whether this is a keyboard problem, > X problem or something wrong with the kernel's console stuff? > I had the same problem when upgrading from 2.4.0-test10 to 2.4.0, altough my keyboard worked for about half a year without problems. But, what a coincidence, it turned out to be a hardware problem. Two pins of the PS/2 connector were moved inside the connector, thus they didn't connect to the keyboard controller. I replaced the keyboard cable and all is well. Did you try to replace the keyboard ? Regards, Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
On Fri, Feb 02, 2001 at 02:58:14PM -0800, [EMAIL PROTECTED] wrote: > Now, it seems to me, as long as the ReiserFS folks are going to be getting the > bulk of the extra work(/mail/whatever) out of this, and they've been advised > of the risks to their own person and are ok with that (which they apparently > are), then they might as well go ahead and try it. It's their inboxes. okay, i don't really want to prolong this debate any longer, but why not put something in Documentation/Configure.help along the lines of "warning: gcc 2.96 has been known to cause errors with reiserfs! if it goes weird on you, _upgrade (or downgrade) your compiler and re-compile your kernel_." imho Configure.help would be one of the best places to put notices such as these. -- / #ozone <[EMAIL PROTECTED]>; (mobile# 0411 882299) trust in love to save - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bidirectional named pipe?
Perhaps man 2 mkfifo ?
On 02.03 "Miller, Brendan" wrote:
>
> I've countless web searches and linux-kernel archives, but I haven't yet
> found the answer to my question.
>
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named pipe
> in the /tmp directory. Any client can then open("/tmp/pipename",
> O_RDWR|O_NDELAY) and gain access to the server. The pipe is bidirectional,
> so the client and server communicate on the same pipe. I support a number
> of clients on the single pipe using file-locking to prohibit from two
> clients from writing/reading at once.
>
> How can I do this under Linux? In SVR4 Unices, I just use pipe() as it's
> pipes are bidirectional, and I can attach a name with fattach(). In SVR3
> Unices, I go through a bunch of hacking using the "stream clone device --
> /dev/spx". I experiemented with socket-based pipes under Linux, but I
> couldn't gain access to them by open()ing the name. Is there help? I
> really don't want to use LiS (the Linux Streams) package, as I'd rather do
> something native and not be dependent on another module. Plus, I read
> somewhere that this was a poor way to do things.
>
> Brendan
>
> Please cc: me personally, as I am not subscribed.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
--
J.A. Magallon $> cd pub
mailto:[EMAIL PROTECTED] $> more beer
Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] Re: 1st glance at kiobuf overhead in kernelaiovs pread vs user aio
Ingo Molnar wrote:
>
> On Fri, 2 Feb 2001, Rajagopal Ananthanarayanan wrote:
>
> > Do you really have worker threads? In my reading of the patch it seems
> > that the wtd is serviced by keventd. [...]
>
> i think worker threads (or any 'helper' threads) should be avoided. It can
> be done without any extra process context, and it should be done that way.
> Why all the trouble with async IO requests if requests are going to end up
> in a worker thread's context anyway? (which will be a serializing point,
> otherwise why does it end up there?)
>
Good point. Can you expand on how you plan to service pending
chunks of work (eg. issuing readpage() on some pages) without
the use of threads?
thanks,
--
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
bidirectional named pipe?
I've countless web searches and linux-kernel archives, but I haven't yet
found the answer to my question.
I'm porting some software to Linux that requires use of a bidirectional,
named pipe. The architecture is as follows: A server creates a named pipe
in the /tmp directory. Any client can then open("/tmp/pipename",
O_RDWR|O_NDELAY) and gain access to the server. The pipe is bidirectional,
so the client and server communicate on the same pipe. I support a number
of clients on the single pipe using file-locking to prohibit from two
clients from writing/reading at once.
How can I do this under Linux? In SVR4 Unices, I just use pipe() as it's
pipes are bidirectional, and I can attach a name with fattach(). In SVR3
Unices, I go through a bunch of hacking using the "stream clone device --
/dev/spx". I experiemented with socket-based pipes under Linux, but I
couldn't gain access to them by open()ing the name. Is there help? I
really don't want to use LiS (the Linux Streams) package, as I'd rather do
something native and not be dependent on another module. Plus, I read
somewhere that this was a poor way to do things.
Brendan
Please cc: me personally, as I am not subscribed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: CPU capabilities -- an update proposal
On Fri, 2 Feb 2001, H. Peter Anvin wrote:
>
> > diff -up --recursive --new-file linux-2.4.0-ac12.macro/include/asm-i386/bugs.h
>linux-2.4.0-ac12/include/asm-i386/bugs.h
> > --- linux-2.4.0-ac12.macro/include/asm-i386/bugs.h Sun Jan 28 09:41:20 2001
> > +++ linux-2.4.0-ac12/include/asm-i386/bugs.hWed Jan 31 22:18:40 2001
> > @@ -83,12 +83,12 @@ static void __init check_fpu(void)
> > extern void __buggy_fxsr_alignment(void);
> > __buggy_fxsr_alignment();
> > }
> > - if (cpu_has_fxsr) {
> > + if (boot_has_fxsr) {
> > printk(KERN_INFO "Enabling fast FPU save and restore... ");
> > set_in_cr4(X86_CR4_OSFXSR);
> > printk("done.\n");
> > }
> > - if (cpu_has_xmm) {
> > + if (boot_has_xmm) {
> > printk(KERN_INFO "Enabling unmasked SIMD FPU exception support...
>");
> > set_in_cr4(X86_CR4_OSXMMEXCPT);
> > printk("done.\n");
>
> Once you enable OSFXSR (therefore allowing user-space code to issue SSE
> instructions) you *have* to save using FXSAVE, which you can only do if
> *all* CPUs support FXSR. Therefore, I would say this is a buggy
> change... it is not save to enable OSFXSR unless *all* the CPUs support
> FXSR (they don't have to all support SSE, however, although since you
> can't control which CPU you execute on, it's pretty useless if they
> don't.)
That's nothing new: all Maciej has done there is update the names
of the macros. Of course you are right, it is in principle unsafe,
and it would be nice to know about all the CPUs before making such
decisions; but I think there are many other choices like that (TSC?
PSE? PGE? PAE?) made on the basis of that first CPU, before the
others have even been booted, and it's not been a serious problem
in practice. I seem to recall that Intel only support mixed CPU
steppings if the earliest (presumably least capable) is the first
to boot. It would be quite easy to add a second bugs.h check,
this time on common_x86_capability once all CPUs have booted;
but that may be too late, and I doubt it's worth trying harder.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
On Sat, Feb 03, 2001 at 12:40:03AM +0100, J . A . Magallon wrote:
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc is versioned like
You can do:
if [ "$CC" = gcc ]; then
echo 'inline void f(unsigned int n){int
i,j=-1;for(i=0;i<10&<0;i++)if((1UL< test.c
gcc -O2 -o test test.c
if ./test; then echo "*** Please don't use this compiler to compile kernel"; fi
rm -f test.c test
fi
(the $CC = gcc test is there e.g. so that the test is not done when
cross-compiling or when there is a separate kernel compiler and userland
compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and
on 2.97 until end of November or so).
Similarly a testcase for the reload bug which caused in 2.95.2
miscompilation of some long long stuff in the kernel could be added as well
if you want to go that way.
Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: isdn_ppp.c bug (isdn_lzscomp.c aka STAC compression > oops on 2.4.x)
Hi, Unfortunately you are too right. It appears that the "!!!HACK,HACK,HACK!!! 2048 is only assumed" line is gone in 2.4.1, but is back in 2.4.1-ac1. Can this be fixed? Regards, infernix - Original Message - From: "Kai Germaschewski" <[EMAIL PROTECTED]> To: "infernix" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, February 02, 2001 6:18 PM Subject: Re: isdn_ppp.c bug (isdn_lzscomp.c aka STAC compression > oops on 2.4.x) > > On Fri, 2 Feb 2001, infernix wrote: > > > However, the patch hasn't been implemented yet, neither in 2.4.1 or in > > 2.4.1-ac1, because the obvious "HACK,HACK,HACK" sentence is still present :) > > Could someone see to it that this mail reaches the kernel's isdn_ppp.c > > maintainer and get this thing moving? Thanks. > > Look again. The patch you quoted is in patch-2.4.1.bz2. Don't know about > 2.4.1-ac1. (But I doubt it's reverted there :) > > --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Every Make option ends in error.
On 02.02 Ken Moffat wrote: > Hi guys, > I guess I'm doing something stupid, so please can somebody point it out > and put me out of my misery ? > > Copied a plain 2.4.0 tree to a new directory, patched it to 2.4.1 without > any errors. Then I realised it had all the object files from my last > compile, so I thought "make mrproper" was called for. It did a little, > then Do a 'cp -a linux-2.4.0 linux-2.4.1', and symlinks (asm...) will not be de-referenced. Or even better, if you are going to patch, do a 'cp -rl', and your new tree will not waste almost any space (hard-links all the files, so space only is duplicated when patch changes some file - and if you remove the old kernel tree, the space just goes to the new). -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
I would agree with you, and I was about to write something saying that trusting that rpm is installed is bad, except that then I realized, only RedHat made this error, and only RedHat installs need this protection. Now, if we want to have a more general bad gcc's list, and we envision this code evolving, then yes, Alan's code is way too specific, and we should do it differently so as to force them to increment what gcc -v returns whenever they want anybody to pay attention to their having fixed a bug. I was trying to be sociable for once though Hans "J . A . Magallon" wrote: > > On 02.02 Hans Reiser wrote: > > Alan Cox wrote: > > > Run a small shell check and let it fail if the shell stuff errors. > > > > > > The fragment you want is > > > > > > if [ -e /bin/rpm ]; then > > > X=`rpm -q gcc` > > > if [ "$X" = "gcc-2.96-54" ]; then > > > echo "*** GCC 2.96-54 will miscompile Reiserfs. Please > > update your compiler" > > > echo "See >http://www.redhat.com/support/errata/RHBA-2000-132.html" > > > exit 255 > > > fi > > > fi > > Ok, thanks Alan, we'll use it, Yura, write something resembling or equal to > > this, test it, and check it into our CVS branch. > > > > Please, do not do so. That depends on the PACKAGE name and version, and there > is no standard way of versioning a patched gcc. > The -54 is a RH'ism, for example Mandrake Cooker includes patches from > different sources, and gcc is versioned like > > werewolf:~# rpm -q gcc > gcc-2.96-0.33mdk > > and ChangeLog is: > > werewolf:~# rpm -q --changelog gcc > * Mon Jan 15 2001 David BAUDENS <[EMAIL PROTECTED]> 2.96-0.33mdk > > - Fix build on PPC > > * Mon Jan 15 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.96-0.32mdk > > - Try to fix when alternatives is broken in %post. > - Merge with RH package (rel70) of Jakub : > ^^^ > .. > > so it suits a 2.96-70 gcc. > > -- > J.A. Magallon $> cd pub > mailto:[EMAIL PROTECTED] $> more beer > > Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] tmpfs for 2.4.1
On 02.02 H. Peter Anvin wrote: > "J . A . Magallon" wrote: > > > > On 02.02 Christoph Rohland wrote: > > > "H. Peter Anvin" <[EMAIL PROTECTED]> writes: > > > > > > > What happened with this being a management tool for shared memory > > > > segments?! > > > > > > Unfortunately we lost this ability in the 2.4.0-test series. SYSV shm > > > now works only on an internal mounted instance and does not link the > > > directory entry to the deleted state of the segment. > > > > > > > Mm, does this mean that mounting /dev/shm is no more needed ? > > One step more towards easy 2.2 <-> 2.4 switching... > > > > In some ways it's kind of sad. I found the /dev/shm interface to be > rather appealing :) > I did not get the chance to deal too much with it, but apart from moving functionality from userspace (ipcs) to kernel (ls), what were/could be the benefits of /dev/shm ?. Can you create a shared memory segment by simply creating a file there, or it is just a picture of what is in kernelspace?. First time I saw that I thought: what could happen if /dev/shm is shared in a cluster ? or, lets suppose that /dev/shm is a logical volume made by addition of some nfs mounted volumes, one of each node, so one piece of the shm fs is local and other remote...kinda DSM/NUMA...? (just too much marijuana late at night...) -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CPU capabilities -- an update proposal
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote: > > Following is the current state of my CPU capabilities rework. It > introduces a new global variable, common_x86_capability, which holds the > common set of flags for CPUs. The boot_cpu_data is used appropriately > again, i.e. it's treated as current_cpu_data before smp_store_cpu_info() > is called (it doesn't matter for UP). I defined a set of macros named > boot_has_* for the purpose of accessing boot_cpu_data. I did not create > current_has_* macros to access current_cpu_data as I think this might > encourage people to use them instead of cpu_has_* incorrectly. I like common_x86_capability[], and I like that it's _not_ a struct cpuinfo_x86 - saves us from wasting time on inventing "common" values for the other cpuinfo_x86 fields (and'ing, or'ing, min'ing, etc.). I agree with not defining current_has_ macros (at least until good reason for them appears). And I'm glad you're doing a patch to fix these common capabilities, without getting bogged down in the issue of how to publish them via /proc (I think that's something for later). But I don't much like those two sets of macros (one of you is welcome but enough!). Congratulations if you have indeed got them all right (I found no errors), but I'm afraid someone else will later choose the wrong one, however well you comment. Which was why my version kept copying the "and" back into boot_cpu_data (admittedly a hack). I wonder (you or hpa may very quickly point out why this is stupid and impossible), could we move the identify_cpu() calls into cpu_init()? I used to think it was called too early for that, but now I see it's already using current, smp_processor_id(), printk(). If identify_cpu() went in there, then we'd only need one set of macros (cpu_has_ testing common_x86_capability), and a considerable source of potential errors would be gone. Not just errors from using the wrong macro: it's worried me that so much of startup is relying on the feature flags before identify_cpu() comes in to adjust them (e.g. adding PGE for an AMD, removing TSC from a Cyrix and a Centaur). We could eliminate dodgy_tsc() then, its work already done. I've not applied and installed your patch, but the only problem I noticed was in i386_ksyms.c: you've put #if 0 #endif around the EXPORT_SYMBOL(boot_cpu_data), but you need to export it for UP; and you've no EXPORT_SYMBOL(common_x86_capability), which you'll need for SMP. Actually, I'd prefer EXPORT_SYMBOL(boot_cpu_data) to be replaced by EXPORT_SYMBOL(common_x86_capability) (of course, without #ifdef 0 #endif), and the SMP/UP divergence removed from processor.h - give UP its own separate common_x86_capability[] (hmm, it's already there in setup.c, does that compile?) and its own cpu_data[1]. A little space wasted, but more confusion gone - and if you dare, boot_cpu_data can then be __initdata? Very minor point: remember mem=nopentium switches off PSE, should be reflected in cpu_data and common_x86_capability. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, someone is trying to be funny
Michael H. Warfield writes: > On Fri, Feb 02, 2001 at 03:36:46PM -0800, David S. Miller wrote: > So block them using the /etc/mail/access database for sendmail > and do it with a "451" error code. The data will back up on their > mail server and start clogging their mail spool till they get a clue. > (Ok... 5 day expiration on the messages, but ITMT, they get several > warning and error messages from each too). We don't use sendmail at vger, we use zmailer. Sendmail could not keep up with the load :-) And yes I've done the zmailer equivalent (manual SPAM block database) of what you've suggested. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, someone is trying to be funny
On Fri, Feb 02, 2001 at 03:36:46PM -0800, David S. Miller wrote: > Ok, it seems somebody is running a cron script or similar > to keep resubscribing that [EMAIL PROTECTED] address > to linux-kernel. So block them using the /etc/mail/access database for sendmail and do it with a "451" error code. The data will back up on their mail server and start clogging their mail spool till they get a clue. (Ok... 5 day expiration on the messages, but ITMT, they get several warning and error messages from each too). > So if you see the "moderation" message back from a posting > you make to linux-kernel, please dont' report it to us here > at vger.kernel.org, we know about it. > Later, > David S. Miller > [EMAIL PROTECTED] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
On 02.02 Hans Reiser wrote: > Alan Cox wrote: > > Run a small shell check and let it fail if the shell stuff errors. > > > > The fragment you want is > > > > if [ -e /bin/rpm ]; then > > X=`rpm -q gcc` > > if [ "$X" = "gcc-2.96-54" ]; then > > echo "*** GCC 2.96-54 will miscompile Reiserfs. Please > update your compiler" > > echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html" > > exit 255 > > fi > > fi > Ok, thanks Alan, we'll use it, Yura, write something resembling or equal to > this, test it, and check it into our CVS branch. > Please, do not do so. That depends on the PACKAGE name and version, and there is no standard way of versioning a patched gcc. The -54 is a RH'ism, for example Mandrake Cooker includes patches from different sources, and gcc is versioned like werewolf:~# rpm -q gcc gcc-2.96-0.33mdk and ChangeLog is: werewolf:~# rpm -q --changelog gcc * Mon Jan 15 2001 David BAUDENS <[EMAIL PROTECTED]> 2.96-0.33mdk - Fix build on PPC * Mon Jan 15 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.96-0.32mdk - Try to fix when alternatives is broken in %post. - Merge with RH package (rel70) of Jakub : ^^^ .. so it suits a 2.96-70 gcc. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Ok, someone is trying to be funny
Ok, it seems somebody is running a cron script or similar to keep resubscribing that [EMAIL PROTECTED] address to linux-kernel. So if you see the "moderation" message back from a posting you make to linux-kernel, please dont' report it to us here at vger.kernel.org, we know about it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18: weird eepro100 msgs
On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos <[EMAIL PROTECTED]> wrote: > Sometimes when I reboot the system, as soon as the eepro100 module is > loaded, I start to get these msgs on the screen: > > eth0: card reports no resources. > eth0: card reports no RX buffers. > eth0: card reports no resources. > eth0: card reports no RX buffers. > eth0: card reports no resources. > eth0: card reports no RX buffers. > (...) Does the following patch, taken from 2.4.1, help? Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. --- linux-2.2.18/drivers/net/eepro100-old.c Fri Feb 2 15:30:23 2001 +++ linux-2.2.18/drivers/net/eepro100.c Fri Feb 2 15:33:19 2001 @@ -751,6 +751,7 @@ This takes less than 10usec and will easily finish before the next action. */ outl(PortReset, ioaddr + SCBPort); + inl(ioaddr + SCBPort); /* Honor PortReset timing. */ udelay(10); @@ -839,6 +840,7 @@ #endif /* kernel_bloat */ outl(PortReset, ioaddr + SCBPort); + inl(ioaddr + SCBPort); /* Honor PortReset timing. */ udelay(10); @@ -1062,6 +1064,9 @@ /* Set the segment registers to '0'. */ wait_for_cmd_done(ioaddr + SCBCmd); outl(0, ioaddr + SCBPointer); + /* impose a delay to avoid a bug */ + inl(ioaddr + SCBPointer); + udelay(10); outb(RxAddrLoad, ioaddr + SCBCmd); wait_for_cmd_done(ioaddr + SCBCmd); outb(CUCmdBase, ioaddr + SCBCmd); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
David Lang writes: > right, assuming that there is enough sendfile() benifit to overcome the > write() penalty from the stuff that can't be cached or sent from a file. > > my question was basicly are there enough places where sendfile would > actually be used to make it a net gain. There are non-performance issues as well (really, all of these points have been mentioned in this thread btw). One is that since paged SKBs use only single-order page allocations, the memory allocation subsystem is stressed less than the current scheme where SLAB allocates multi-order pages to satisfy allocations of linear SKB data buffers. This has consequences and benefits system wide. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] Re: 1st glance at kiobuf overhead in kernelaiovs pread vs user aio
On Fri, 2 Feb 2001, Rajagopal Ananthanarayanan wrote: > Do you really have worker threads? In my reading of the patch it seems > that the wtd is serviced by keventd. [...] i think worker threads (or any 'helper' threads) should be avoided. It can be done without any extra process context, and it should be done that way. Why all the trouble with async IO requests if requests are going to end up in a worker thread's context anyway? (which will be a serializing point, otherwise why does it end up there?) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
Let's see all the work being done for clustering would definitely benefit... all the static images on your webserver--and static images makes up most of the bandwidth from web servers (images, activeX controls, java apps, sound clips...)... NFS servers, Samba servers (both of which are used more than you may think)... email servers... Once Real Networks patches their Realserver to use sendfile (which shouldn't bee all that hard), then that would help too I think that sendfile can be used in a LOT of applications, and the only ones that wouldn't benefit are mostly low-bandwidth anyway (CGI apps almost always return either a small html file or a small image file, then there's telnet and other interactive utilities...). Most applications that use a lot of bandwidth (and thus a lot of CPU time sending the packets) are capable of being patched to use sendfile. On Fri, 2 Feb 2001, David Lang wrote: > right, assuming that there is enough sendfile() benifit to overcome the > write() penalty from the stuff that can't be cached or sent from a file. > > my question was basicly are there enough places where sendfile would > actually be used to make it a net gain. > > David Lang > > On Fri, 2 Feb 2001, David S. Miller wrote: > > > Date: Fri, 2 Feb 2001 15:09:13 -0800 (PST) > > From: David S. Miller <[EMAIL PROTECTED]> > > To: David Lang <[EMAIL PROTECTED]> > > Cc: Andrew Morton <[EMAIL PROTECTED]>, lkml <[EMAIL PROTECTED]>, > > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > Subject: Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN) > > > > > > David Lang writes: > > > Thanks, that info on sendfile makes sense for the fileserver situation. > > > for webservers we will have to see (many/most CGI's look at stuff from the > > > client so I still have doubts as to how much use cacheing will be) > > > > Also note that the decreased CPU utilization resulting from > > zerocopy sendfile leaves more CPU available for CGI execution. > > > > This was a point I forgot to make. > > > > Later, > > David S. Miller > > [EMAIL PROTECTED] > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
On Sat, 03 Feb 2001 00:04:16 +0100,
Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
>I had some problems while compiling some applications
>with the 2.4.0 kernel.
>The problem was a conflict between string.h from the libc
>and the one from the kernel, which is included in fs.h
Rule 1. Applications must not include include kernel headers directly.
Rule 2. Any glibc that has a symlink from /usr/include/{linux,asm} to
/usr/src/linux/include/{linux,asm} is wrong.
Relying on /usr/include/{linux,asm} always pointing at the current
kernel source is broken as designed. /usr/include/{linux,asm} must be
real directories that are shipped as part of glibc, not symlinks to
some random version of the kernel. Fix /usr/include.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] Re: 1st glance at kiobuf overhead in kernelaio vs pread vs user aio
Benjamin LaHaise wrote:
>
> Hey Ingo,
>
> On Fri, 2 Feb 2001, Ingo Molnar wrote:
>
> > - first of all, great patch! I've got a conceptual question: exactly how
> > does the AIO code prevent filesystem-related scheduling in the issuing
> > process' context? I'd like to use (and test) your AIO code for TUX, but i
> > do not see where it's guaranteed that the process that does the aio does
> > not block - from the patch this is not yet clear to me. (Right now TUX
> > uses separate 'async IO' kernel threads to avoid this problem.) Or if it's
> > not yet possible, what are the plans to handle this?
>
> Thanks! Right now the code does the page cache lookup allocations and
> lookups in the caller's thread, the write path then attempts to lock all
> pages sequentially during io using the async page locking function
> wtd_lock_page. I've tried to get this close to some of the ideas proposed
> by Jeff Merkey, and have implemented async page and buffer locking
> mechanisms so far. The down in the write path is still synchronous,
> mostly because I want some feedback before going much further down this
> path. The read path verifies the up2date state of individual pages, and
> if it encounters one which is not, then it queues the request for the
> worker thread which calls readpage on all the pages that need updating.
[ Ben, good to see you have a patch to send, something which I've been requesting
you for sometime now ;-) ]
Do you really have worker threads? In my reading of the patch it seems
that the wtd is serviced by keventd. And by using mapped kiobuf's you've
avoided issues such as:
a. (not) requiring a requestor's process context to perform the copy (copy-out
on read, for example)
b. avoiding requestor's (user) page from being unmapped when a
__iodesc_read_finish is being executed.
These are two major improvements I'm glad to see over my earlier KAIO patch
(obURL: http://oss.sgi.com/projects/kaio/) ... of course, several abstractions,
including kiobufs & more generic task queues in 2.4 have made this easier,
which is a good thing.
I see several similarities to the KAIO patch too; stuff like splitting
generic_read routine (which now you have expanded to include the write
routine also), and the handling of RAW devices.
A nice addition in your patch is the introduction of kiobuf as a common container of
pages, which in the KAIO patch was handled with an ad-hoc (page *) vector
for non RAW & kiobuf's for the RAW case.
One point which is not clear is how one would implement aio_suspend(...)
which waits for any ONE of N aiocb's to complete. The aio_complete(...)
routine in your patch expects a particular idx to wait on, so I assume
as is, only one aiocb can be waited upon. Am I correct? This particular
case is solved in the KAIO patch ...
Also, can you also put out a library that goes with the kernel patch?
I can imagine what it would look like, but ...
Cheers,
ananth.
--
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] Re: 1st glance at kiobuf overhead in kernelaio vs pread vs user aio
On Fri, 2 Feb 2001, Benjamin LaHaise wrote: > Thanks! Right now the code does the page cache lookup allocations and > lookups in the caller's thread, [...] (the killer is not the memory allocation(s), if there is enough RAM then we can get a free page without having to block.) The real problem is the implicit ->bmap() in readpage(). IMO this is the tough part in AIO. There can be zillions of sub-IOs generated during filesystem ->bmap(). Doing the data reads asynchronously is just about 30% of the work, and as long as there is even a *single* inode-related blocking point in the synchronous async IO path, the whole scheme remains useless for practical applications. It does not matter that 90% of the IO is asynchronous - if we are blocking on the remaining 10% then the whole operation degrades to synchronous! To make this work correctly, lowlevel filesystem code must be modified in nontrivial ways. If this is easy then please give me a quick description of how this is going to be done. Plus there is the issue of not blocking in __wait_request() either. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
right, assuming that there is enough sendfile() benifit to overcome the write() penalty from the stuff that can't be cached or sent from a file. my question was basicly are there enough places where sendfile would actually be used to make it a net gain. David Lang On Fri, 2 Feb 2001, David S. Miller wrote: > Date: Fri, 2 Feb 2001 15:09:13 -0800 (PST) > From: David S. Miller <[EMAIL PROTECTED]> > To: David Lang <[EMAIL PROTECTED]> > Cc: Andrew Morton <[EMAIL PROTECTED]>, lkml <[EMAIL PROTECTED]>, > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN) > > > David Lang writes: > > Thanks, that info on sendfile makes sense for the fileserver situation. > > for webservers we will have to see (many/most CGI's look at stuff from the > > client so I still have doubts as to how much use cacheing will be) > > Also note that the decreased CPU utilization resulting from > zerocopy sendfile leaves more CPU available for CGI execution. > > This was a point I forgot to make. > > Later, > David S. Miller > [EMAIL PROTECTED] > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
David Lang writes: > Thanks, that info on sendfile makes sense for the fileserver situation. > for webservers we will have to see (many/most CGI's look at stuff from the > client so I still have doubts as to how much use cacheing will be) Also note that the decreased CPU utilization resulting from zerocopy sendfile leaves more CPU available for CGI execution. This was a point I forgot to make. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fix for include/linux/fs.h in 2.4.0 kernels
I had some problems while compiling some applications with the 2.4.0 kernel. The problem was a conflict between string.h from the libc and the one from the kernel, which is included in fs.h So, using and at the same time brings some conflicts. It seems to me that should not be apparent from user mode, so I did this patch: --- fs.h-orig Fri Feb 2 23:55:35 2001 +++ fs.hFri Feb 2 21:26:05 2001 @@ -20,7 +20,7 @@ #include #include #include -#include +/* #include */ #include #include @@ -190,6 +190,7 @@ #include #include +#include extern void update_atime (struct inode *); #define UPDATE_ATIME(inode) update_atime (inode) Like this, the #include is "protected" by a #ifdef __KERNEL__, so I don't have any conflict any more. I recompiled my kernel without any problem since I did that patch. Regards. Jocelyn Mayer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18: weird eepro100 msgs
Hello, The system is as follows: - Intel CA810EAL motherboard (built-in EtherExpress Pro 10/100) - 128MB RAM - 10GB IDE HD (Western Digital WD100) - Linux kernel 2.2.18 Sometimes when I reboot the system, as soon as the eepro100 module is loaded, I start to get these msgs on the screen: eth0: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. (...) They go on forever, and the box becomes inoperational (I can see the msgs on the screen, but I can't login, type anything ...). If I reboot the system, the msgs do NOT show up anymore, and then I can use the system again. Could anyone _please_ shed a light on this one for me?!?! How could I solve it?? What kind of additional info you need?? Please let me know. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
Thanks, that info on sendfile makes sense for the fileserver situation. for webservers we will have to see (many/most CGI's look at stuff from the client so I still have doubts as to how much use cacheing will be) David Lang On Fri, 2 Feb 2001, David S. Miller wrote: > Date: Fri, 2 Feb 2001 14:46:07 -0800 (PST) > From: David S. Miller <[EMAIL PROTECTED]> > To: David Lang <[EMAIL PROTECTED]> > Cc: Andrew Morton <[EMAIL PROTECTED]>, lkml <[EMAIL PROTECTED]>, > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN) > > > David Lang writes: > > 1a. for webservers that server static content (and can therefor use > > sendfile) I don't see this as significant becouse as your tests have been > > showing, even a modest machine can saturate your network (unless you are > > useing gigE at which time it takes a skightly larger machine) > > Start using more than one interface, then it begins to become > interesting. > > > 1b. for webservers that are not primarily serving static content, they > > have to use write() for the output from cgi's, etc and therefor pay the > > performance penalty without being able to use sendfile() much to get the > > advantages. These machines are the ones that really need the performance > > as the cgi's take a significant amount of your cpu. > > CGI's can be cached btw if the implementation is clever (f.e. CGI > tells the web server that if the file used as input to the CGI does > not change then the output from the CGI will not change, meaning CGI > output is based solely on input, therefore CGI output can be cached > by the web server). > > > 2. for other fileservers sendfile() sounds like it would be useful if the > > client is reading the entire file, but what about the cases where the > > client is reading part of the file, or is writing to the file. In both of > > these cases it seems that the fileserver is back to the write() penalty. > > does anyone have stats on the types of requests that fileservers are being > > asked for? > > It helps no matter what part of the file the client reads. > > sendfile() can be used on an arbitrary offset+len portion of > a file, it is not limited to just sending an entire fire. > > Later, > David S. Miller > [EMAIL PROTECTED] > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17: weird eepro100 msgs
Hello, The system is as follows: - Intel CA810EAL motherboard (built-in EtherExpress Pro 10/100) - 128MB RAM - 10GB IDE HD (Western Digital WD100) - Linux kernel 2.2.18 Sometimes when I reboot the system, as soon as the eepro100 module is loaded, I start to get these msgs on the screen: eth0: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. (...) They go on forever, and the box becomes inoperational (I can see the msgs on the screen, but I can't login, type anything ...). If I reboot the system, the msgs do NOT show up anymore, and then I can use the system again. Could anyone _please_ shed a light on this one for me?!?! How could I solve it?? What kind of additional info you need?? Please let me know. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
On Sat, Feb 03, 2001 at 01:03:00AM +0300, Hans Reiser wrote: > My design objective in ReiserFS is not to say that it wasn't my fault they had > that bug because they are so ignorant about a filesystem that > really isn't very important to them unless it screws up. My design objective is > to ensure they don't have that bug. They are more important than me. The whole argument back and forth here seems to be: Hans: It's better if it fails to compile with a clear message than compiling ok and breaking horribly and unpredictably later. Alan: It won't work and it'll generate more mail, not less. Now, it seems to me, as long as the ReiserFS folks are going to be getting the bulk of the extra work(/mail/whatever) out of this, and they've been advised of the risks to their own person and are ok with that (which they apparently are), then they might as well go ahead and try it. It's their inboxes. The one thing I do have to say about all of this, however, is that if this sort of testing for compiler issues (or tool issues, or library issues or anything else) is going to be done as part of individual kernel components, there should be some way to globally configure this, so that it can be turned off should someone, for some reason, want (or need) to do something with an unsupported version of something and know what they're doing, without having to hunt through every line of kernel source to find the multiple places different developers have put in different checks for the thing they're trying to do. Perhaps a "Kernel Hacking" configuration option (or just something in a documented .h file) for "Allow compiling with buggy GCC 2.96" which would turn off all such checks? -alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
On Sat, 3 Feb 2001, Hans Reiser wrote: > That said, my opinion is that bug reporting load is not as important as bug > avoidance, but I understand your position has merit to it also. If you do it, at least restrict it to 2.96.0. Maybe Red Hat will see the light and release a fixed 2.96.1... 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
On Fri, 2 Feb 2001 16:39:18 -0500 (EST), Alan Cox <[EMAIL PROTECTED]> wrote: >Large numbers of people routinely build the kernel with 'unsupported' compilers gcc version 2.96-ia64-000717 snap 001117 - works for me doing cross compile from ia32 to ia64. Anybody adding #ifdef, please include this version, oh and also include the version of gcc on the latest Redhat ia64 beta, and the version of gcc on the latest Turbolinux ia64 beta. Don't forget to include a check for cross compile, querying the local rpm will not work in cross compile mode. On second thoughts, forget about #ifdef. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > > their kernel, something putting #ifdefs all over it will mean they have to > > > mess around to fix too. > > > > > A moment of precision here. We won't test to see if the right compiler is used, > > we will just test for the wrong one. > > Ok that makes a lot more sense Ok, so with that last clarification, we are all in agreement I think. Thanks for the code frag Alan, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Recommended swap for 2.4.x.
On Fri, 2 Feb 2001, Pavel Machek wrote: > Hi! > > > I am asking because I have just ordered a new drive for my Vaio (8.1 gig > > in a 8.45mm drive!) and I want to install 2.4.x on it. (I like getting > > 8.1GB in under centimeter? That's 8.1GB in compactflash slot? Standard laptop drive size except 8.45mm thick as opposed to 9.5mm thick. (Kind of bites too. If it would take a 9.5mm drive I could put in 30 gigs instead of 8.1gigs.) [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
David Lang writes: > 1a. for webservers that server static content (and can therefor use > sendfile) I don't see this as significant becouse as your tests have been > showing, even a modest machine can saturate your network (unless you are > useing gigE at which time it takes a skightly larger machine) Start using more than one interface, then it begins to become interesting. > 1b. for webservers that are not primarily serving static content, they > have to use write() for the output from cgi's, etc and therefor pay the > performance penalty without being able to use sendfile() much to get the > advantages. These machines are the ones that really need the performance > as the cgi's take a significant amount of your cpu. CGI's can be cached btw if the implementation is clever (f.e. CGI tells the web server that if the file used as input to the CGI does not change then the output from the CGI will not change, meaning CGI output is based solely on input, therefore CGI output can be cached by the web server). > 2. for other fileservers sendfile() sounds like it would be useful if the > client is reading the entire file, but what about the cases where the > client is reading part of the file, or is writing to the file. In both of > these cases it seems that the fileserver is back to the write() penalty. > does anyone have stats on the types of requests that fileservers are being > asked for? It helps no matter what part of the file the client reads. sendfile() can be used on an arbitrary offset+len portion of a file, it is not limited to just sending an entire fire. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > It makes sense to refuse to build a piece of the kernel if it break's > > a machine - anything else is a timebomb waiting to explode. > > The logical conclusion of that is to replace the entire kernel tree with > > #error "compiler or program might have a bug. Aborting" No, this is a compiler that DOES have a bug. ReiserFS is, as best as I can make it, for mission critical servers where some sysadmin doesn't want to explain it to the CEO. There are plenty of ways that I fail at this, but not intentionally. These sorts of mission critical servers are frequently installed by persons short on sleep because a whole lot of things more interesting than ReiserFS had to be gotten working for that server, and who are barely able to convince their boss that compiling a kernel themselves is an okay thing for them to be allowed to do. Taking an attitude of, you didn't read the README, you didn't read Slashdot, you just assumed the distro wouldn't install a compiler unable to compile the kernel, you lose, is not the way I treat such customers. Our users have better things to do than read our FAQ. They REALLY do. ReiserFS is a product of only marginal interest to them. They trust that it will just work because it isn't a Microsoft product. My design objective in ReiserFS is not to say that it wasn't my fault they had that bug because they are so ignorant about a filesystem that really isn't very important to them unless it screws up. My design objective is to ensure they don't have that bug. They are more important than me. > > The kernel is NOT some US home appliance festooned with 'do not eat this > furniture' and 'do not expose your laserwrite to naked flame' messages. > The readme says its been tested with egcs-1.1.2 and gcc 2.95. > > The same people who can't read documentation will just mail the list with > 'it doesnt compile, help' or 'it doesnt compile, you suck' in less enlightened > cases/ > > Large numbers of people routinely build the kernel with 'unsupported' compilers > notably the pgcc project people and another group you will cause problems for > - the GCC maintainers. They use the kernel tree as part of the test set for > their kernel, something putting #ifdefs all over it will mean they have to > mess around to fix too. > > Alan A moment of precision here. We won't test to see if the right compiler is used, we will just test for the wrong one. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlinkrelated)
On Fri, 2 Feb 2001, Alan Cox wrote: > Oh I can see why Hans wants to cut down his bug reporting load. I can also > say from experience it wont work. If you put #error in then everyone will > mail him and complain it doesnt build, if you put #warning in nobody will > read it and if you dont put anything in you get the odd bug report anyway. > > Basically you can't win and unfortunately a shrink wrap forcing the user > to read the README file for the kernel violates the GPL .. Oh, don't get me wrong, I fully understand that it's a lose-lose situation. All I'm saying is that it was an incredibly bad idea to have two compilers, one broken and one ok, identify themselves as the same version. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Your message to Meltingpot awaits moderator approval
Richard B. Johnson writes: > WARNING!! Messages to linux-kernel are now being intercepted > (and answered) by this company: > On Fri, 2 Feb 2001 [EMAIL PROTECTED] wrote: > > My message was sent directly to linux-kernel, with no cc address. > It should not have gone anywhere else. I've removed the meltingpot address from linux-kernel. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
> my convenience matters as much as that of the users. I don't want to use > #ifdefs, I want it to die explosively and verbosely informatively. make isn't > the most natural language for that, but I am sure Yura can find a way. Run a small shell check and let it fail if the shell stuff errors. The fragment you want is if [ -e /bin/rpm ]; then X=`rpm -q gcc` if [ "$X" = "gcc-2.96-54" ]; then echo "*** GCC 2.96-54 will miscompile Reiserfs. Please update your compiler" echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html" exit 255 fi fi > Please delay shipping the 3.0 CVS branch on RedHat for a while.:-) Sorry, I > couldn't resist. Grin. gcc 3.0 is going to be just as much fun Im sure, but finally should give everyone a stable C and more importantly C++ base including the LSB standards. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.4.0-ac12: APIC lock-ups
Gérard Roudier wrote:
>
> So, why not using a pure software flag in memory and only tampering the
> things if the offending interrupt is actually delivered ? If the given
> interrupt is delivered and the software mask is set we could simply do:
>
> - MASK the given interrupt
> - EOI it.
> - return
>
Good idea.
I implemented it, and it was a full success: not it always locks up :-(
If I apply the attached patch, then I get a lockup after ~ 100 packets
flood ping.
I've also attached the dmesg print.
I know that startup is currently wrong (must set trigger to level), but
that doesn't matter since I only ifup once.
But I think we can change the bug description:
If an io apic io redirection entry is unmasked while the irq pin is
active, then the io apic sends out the interrupt as edge triggered, but
nevertheless sets the IRR bit.
In a second test run I checked the TMR bit in the local apics: the bit
on the cpu that received the last interrupt is really 0.
I'll not try a 2 step enable:
* unmask.
* io_apic_sync()
* set trigger mode to level.
--
Manfred
--- 2.4/arch/i386/kernel/io_apic.c Fri Feb 2 15:51:57 2001
+++ build-2.4/arch/i386/kernel/io_apic.cFri Feb 2 23:04:44 2001
@@ -115,10 +115,10 @@
/*
* It appears there is an erratum which affects at least the 82093AA
- * I/O APIC. If a level-triggered interrupt input is being masked in
- * the redirection entry while the interrupt is send pending (its
- * delivery status bit is set), the interrupt is erroneously
- * delivered as edge-triggered but the IRR bit gets set nevertheless.
+ * I/O APIC. If a level-triggered interrupt input is being unmasked in
+ * the redirection entry while the interrupt line is active, then
+ * the interrupt is erroneously delivered as edge-triggered but the
+ * IRR bit gets set nevertheless.
* As a result the I/O unit expects an EOI message but it will never
* arrive and further interrupts are blocked for the source.
*
@@ -126,12 +126,8 @@
* a level-triggered interrupt and to revert the mode when unmasking.
* The idea is from Manfred Spraul.
*/
-DO_ACTION( __mask, 0, = (reg & 0x7fff) | 0x0001,
- io_apic_sync(entry->apic)) /* mask = 1, trigger = edge */
-DO_ACTION( __unmask_edge, 0, &= 0xfffe,
- ) /* mask = 0 */
-DO_ACTION( __unmask_level, 0, = (reg & 0xfffe) | 0x8000,
- ) /* mask = 0, trigger = level */
+DO_ACTION( __mask, 0, = (reg & 0x7fff) | 0x0001,
+io_apic_sync(entry->apic))/* mask = 1 */
+DO_ACTION( __unmask, 0, &= 0xfffe, ) /* mask = 0 */
static void mask_IO_APIC_irq (unsigned int irq)
{
@@ -142,26 +138,15 @@
spin_unlock_irqrestore(_lock, flags);
}
-static void unmask_edge_IO_APIC_irq (unsigned int irq)
+static void unmask_IO_APIC_irq (unsigned int irq)
{
unsigned long flags;
spin_lock_irqsave(_lock, flags);
- __unmask_edge_IO_APIC_irq(irq);
+ __unmask_IO_APIC_irq(irq);
spin_unlock_irqrestore(_lock, flags);
}
-static void unmask_level_IO_APIC_irq (unsigned int irq)
-{
- unsigned long flags;
-
- spin_lock_irqsave(_lock, flags);
- __unmask_level_IO_APIC_irq(irq);
- spin_unlock_irqrestore(_lock, flags);
-}
-
-#define unmask_IO_APIC_irq unmask_edge_IO_APIC_irq
-
void clear_IO_APIC_pin(unsigned int apic, unsigned int pin)
{
struct IO_APIC_route_entry entry;
@@ -712,7 +697,7 @@
printk(KERN_WARNING " to [EMAIL PROTECTED]\n");
}
-void __init print_IO_APIC(void)
+void print_IO_APIC(void)
{
int apic, i;
struct IO_APIC_reg_00 reg_00;
@@ -1117,7 +1102,7 @@
* that was delayed but this is now handled in the device
* independent code.
*/
-#define enable_edge_ioapic_irq unmask_edge_IO_APIC_irq
+#define enable_edge_ioapic_irq unmask_IO_APIC_irq
static void disable_edge_ioapic_irq (unsigned int irq) { /* nothing */ }
@@ -1142,7 +1127,7 @@
if (i8259A_irq_pending(irq))
was_pending = 1;
}
- __unmask_edge_IO_APIC_irq(irq);
+ __unmask_IO_APIC_irq(irq);
spin_unlock_irqrestore(_lock, flags);
return was_pending;
@@ -1182,21 +1167,66 @@
*/
static unsigned int startup_level_ioapic_irq (unsigned int irq)
{
- unmask_level_IO_APIC_irq(irq);
+ unmask_IO_APIC_irq(irq);
return 0; /* don't check for pending */
}
#define shutdown_level_ioapic_irq mask_IO_APIC_irq
-#define enable_level_ioapic_irqunmask_level_IO_APIC_irq
-#define disable_level_ioapic_irq mask_IO_APIC_irq
+
+static void enable_level_ioapic_irq (unsigned int i)
+{
+ unsigned long flags;
+ int pin;
+ struct irq_pin_list *entry;
+
+ spin_lock_irqsave(_lock, flags);
+ entry = irq_2_pin + i;
+
+ for (;;) {
+ unsigned int reg, reg2;
+
2.4.1: DMA gets disabled due to irq timeout
Hi,
I was trying 2.4.1 kernel but under some IO load (bonnie++)
DMA gets disabled with following messages:
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: DMA disabled
ide0: reset: success
I am wondering is there known way how to fix (workaround) this problem?
May it be because of ServerWorks chipset (support for ServerWorks was
compiled in)? or SMP?
Here is except from dmesg:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ServerWorks OSB4: IDE controller on PCI bus 00 dev 79
ServerWorks OSB4: chipset revision 0
ServerWorks OSB4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:pio, hdd:pio
hda: FUJITSU MPG3307AT, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 60046560 sectors (30744 MB) w/2048KiB Cache, CHS=3737/255/63, UDMA(33)
I will appreciate your help,
-igor
p.s.
Please cc: me explicitly, because i am not on the list now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Ethernet dies after one hour
I have a box with: a couple of analog ISA modem cards in it which have 8 modems a piece the modems use devices ttyS4-19 a realtek 8039 pci ethernet card (100 mbit) 486 dx Its running redhat 6.2 and a 2.2.17 kernel with ppp ip-forwarding ip aliasing and ip masq support. The kernel is patched with a rastel driver (serial.c and dummy.h from memory) Although this is 2.2 kernel it has support for proxy arp after the patch. I am running portslave terminal server. And I use proxy arp on dialin connections to add an entry in the arp table (I don't like this but ppp won't work otherwise with this particular kernel after the patch) I am using iputils-20001010-1.6x.i386.rpm ppp-2.3.11-4.i386.rpm When I ping I get a warning saying that time goes back and taking precautions. I have tried changing the time on the hwclock and clock but doesn't seem to make any difference. These warnings occur even when I ping the loopback interface. After the box is up for an hour (in which times it functions perfectly) it ceases to be on the network. Its almost as if the cable has been unplugged. If I go down into single user mode and come back up it reappears on the network for about 5 seconds and then disappears again. After a 'shutdown -r now' it comes up and is on the network for another hour. The log files only contain messages like: radius server not responding etc which you would expect if the ethernet was down. ifconfig shows nothing unusual, that is it is still up. I can ping the loopback and the ip address from the box itself to itself after it's ethernet has ceased to function. The ethernet hub shows a slow blink for the box (corresponding to the volume of traffic) after it has ceased to function. Is this a kernel problem? A portslave problem? An iputils-20001010-1.6x problem? Buggey ethernet card? thanks derek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
> > their kernel, something putting #ifdefs all over it will mean they have to > > mess around to fix too. > > > A moment of precision here. We won't test to see if the right compiler is used, > we will just test for the wrong one. Ok that makes a lot more sense - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.2.19pre7 opps on low mem machine
- Original Message - From: "Peter 'Luna' Runestig" <[EMAIL PROTECTED]> To: "Linux Kernel Mailing list" <[EMAIL PROTECTED]> Sent: Wednesday, January 24, 2001 7:29 PM Subject: PROBLEM: 2.2.19pre7 opps on low mem machine > [1.] One line summary of the problem: > Oops with 2.2.19pre7 on memory stressed, old PC. > > [2.] Full description of the problem/report: > An old 486/66 with 20 Meg memory runs a a firewall at home. Probably runs > too much for that amount of memory (sendmail, bind, ntpd and FreeSWAN VPN), > but I can't find any more memory modules! I have gotten four or five oops > the last week or so (in different processes), running 2.2.18. Stepped up to > 2.2.19pre7 and hooked up a serial console two days ago, now I got one again. > > [4.] Kernel version (from /proc/version): > Linux version 2.2.19pre7 ([EMAIL PROTECTED]) (gcc version 2.95.2 19991024 > (release)) #1 Mon Jan 22 11:57:12 CET 2001 OK, following the reiserfs/compiler thread, I can see now that my bug report may have been ignored since I was using a non-kosher compiler (although I have used it since late October -99 without any problems). Or, it might not have been ignored, just nobody told me he/she wasted some time on it. Since it seems to be hardware related; that oops wasn't the only one, and after some more strange behaviour, I moved the hard drive to another, almost identical, PC, with even less memory, 16 MB (but this one I have the chips to run 48 MB, but I wanted to stress it). And it's been running for a week now, like a clock. So, sorry for the false alarm! Cheers, Peter Peter 'Luna' Runestig (fd. Altberg), Sweden <[EMAIL PROTECTED]> PGP Key ID: 0xD07BBE13 Fingerprint: 7B5C 1F48 2997 C061 DE4B 42EA CB99 A35C D07B BE13 AOL Instant Messenger Screenname: PRunestig - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Your message to Meltingpot awaits moderator approval
On Fri, 2 Feb 2001, David S. Miller wrote: > > Richard B. Johnson writes: > > WARNING!! Messages to linux-kernel are now being intercepted > > (and answered) by this company: > > On Fri, 2 Feb 2001 [EMAIL PROTECTED] wrote: > > > > My message was sent directly to linux-kernel, with no cc address. > > It should not have gone anywhere else. > > I've removed the meltingpot address from linux-kernel. > > Later, > David S. Miller > [EMAIL PROTECTED] > Thanks. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
Alan Cox wrote: > > > As it stands, there is no way to determine programatically whether > > gcc-2.96 is broken or now. The only way to do it is to check the RPM > > version -- which, needless to say, is a bit difficult to do from the > > C code about to be compiled. So I can't really blame Hans if he decides > > to outlaw gcc-2.96[.0] for reiserfs compiles. > > Oh I can see why Hans wants to cut down his bug reporting load. I can also > say from experience it wont work. If you put #error in then everyone will > mail him and complain it doesnt build, if you put #warning in nobody will > read it and if you dont put anything in you get the odd bug report anyway. > > Basically you can't win and unfortunately a shrink wrap forcing the user > to read the README file for the kernel violates the GPL .. > > Jaded, me ? > > Alan I fear that you are speaking from experience about the complaints it doesn't build, and that there is a strong element of truth in what you say. That said, my opinion is that bug reporting load is not as important as bug avoidance, but I understand your position has merit to it also. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > my convenience matters as much as that of the users. I don't want to use > > #ifdefs, I want it to die explosively and verbosely informatively. make isn't > > the most natural language for that, but I am sure Yura can find a way. > > Run a small shell check and let it fail if the shell stuff errors. > > The fragment you want is > > if [ -e /bin/rpm ]; then > X=`rpm -q gcc` > if [ "$X" = "gcc-2.96-54" ]; then > echo "*** GCC 2.96-54 will miscompile Reiserfs. Please update your >compiler" > echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html" > exit 255 > fi > fi > > > Please delay shipping the 3.0 CVS branch on RedHat for a while.:-) Sorry, I > > couldn't resist. > > Grin. gcc 3.0 is going to be just as much fun Im sure, but finally should give > everyone a stable C and more importantly C++ base including the LSB standards. > > Alan Ok, thanks Alan, we'll use it, Yura, write something resembling or equal to this, test it, and check it into our CVS branch. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.2.19pre7 opps on low mem machine
> OK, following the reiserfs/compiler thread, I can see now that my bug report > may have been ignored since I was using a non-kosher compiler (although I > have used it since late October -99 without any problems). Or, it might not > have been ignored, just nobody told me he/she wasted some time on it. Since > it seems to be hardware related; that oops wasn't the only one, and after > some more strange behaviour, I moved the hard drive to another, almost > identical, PC, with even less memory, 16 MB (but this one I have the chips > to run 48 MB, but I wanted to stress it). And it's been running for a week > now, like a clock. Thanks for the info. I dont ignore gcc 2.95 stuff with 2.2 nowdays since Im pretty sure 2.2 + gcc 2.95 is solid - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
On Fri, Feb 02, 2001 at 09:57:39PM +, Alan Cox wrote: : > As it stands, there is no way to determine programatically whether : > gcc-2.96 is broken or now. The only way to do it is to check the RPM : > version -- which, needless to say, is a bit difficult to do from the : > C code about to be compiled. So I can't really blame Hans if he decides : > to outlaw gcc-2.96[.0] for reiserfs compiles. : : Oh I can see why Hans wants to cut down his bug reporting load. I can also : say from experience it wont work. If you put #error in then everyone will : mail him and complain it doesnt build, if you put #warning in nobody will : read it and if you dont put anything in you get the odd bug report anyway. : : Basically you can't win and unfortunately a shrink wrap forcing the user : to read the README file for the kernel violates the GPL .. Alan, as a user (one of those few that actually read documentation), I think it is a good idea to stop people from hurting their data by using the wrong compiler and assuming everything is ok until shit happens. As you explained, one either gets the bug reports or the complaints that $SOURCE doesn't compile. The work for the developers might be about the same size, the impact on the users' side is less destructive, though. Arthur -- arthur dot erhardt at pit dot physik dot uni dash tuebingen dot de *pgp key available* dg7sea A physicist is an atom's way of knowing about atoms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Version 2.4.1 cannot be built.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wednesday, Richard B. Johnson ([EMAIL PROTECTED]) wrote: > Now just a cotton-picken minute. When was the last time you > accessed that site? I spent most of last night looking through > EMPTY directories with files that are invisible to ftp but > (sometimes) show with their `ls`, and never with nlist. > Maybe you can still download stuff if you are running from a > Web Crawler, but it doesn't work with `ftp` anymore. We've had no problem reports, and it works fine for me. Mo. - -- Mo McKinlay -- GNU Webmaster [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjp7M0MACgkQRcGgB3aidfnX9wCgjiWJvUlgfRzNGfOMJZJ1rmzR 9XMAoNXVFRJzC5aRUOAQo0moWuchmAsO =yDvE -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
question regarding routing/ethertap
I have a quick question regarding the ethertap device and routing. We're seeing the contents of the packet coming up through the ethertap device just fine, but the originating address seems to be overwritten with the ethertap device's address. Am I missing something obvious here? I'm positive that this isn't how it's supposed to work, but I don't know enough about the routing/forwarding stuff in the kernel to know what I need to change. Thanks, Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use > > reiserfs. It is that simple. How can you even consider defending allowing the > > use of it without requiring a positive affirmation by the user that they don't > > know what they are doing and want to do it anyway?:-) I could understand > > The kernel documentation explicitly says to use egcs-1.1.2 or 2.95 for x86. > If you want to put in #ifdefs then let me assure you that you will then get > a million emails that 'reiserfs doesnt build'. I went this way with older > gcc's in 2.0 and the amount of mail more than doubled by doing the check I'd rather have them complain it doesn't build than never complain because they think reiserfs is still a little too new and has bugs. Also, I just don't think my convenience matters as much as that of the users. I don't want to use #ifdefs, I want it to die explosively and verbosely informatively. make isn't the most natural language for that, but I am sure Yura can find a way. > > If people use other compilers then certainly ignore the bug reports. For 2.2 > until recently that was policy with gcc 2.95 We don't (at least not intentionally, surely someone is going to mention one where we did) ignore bug reports on our mailing list. Period. We are capable of telling users, you know, this is user error, if you want detailed help send me a note that you have put $25 in the mail, and I'll have someone give you step by step help with it. If it is easy to narrow the user error down from the first email I typically just tell them what it is. > > Also remember to check for 2.96 but not 2.96-69 (the errata one) and remember > to do specific architecture tests as there is no other compiler set available > for IA64 for example. > > > to respond to their having them. I look forward to gcc 3.00, and I encourage > > the compiler guys to get over being (understandably) irked that somebody else > > Gcc 3.0 CVS branch wont build the kernel either right now - DAC960 fails. > > Alan Please delay shipping the 3.0 CVS branch on RedHat for a while.:-) Sorry, I couldn't resist. Look, everybody lets a piece of software slip out that should not have gone at some point in their career. It is just that RedHat is big enough that everyone is inconvenienced when they do so, and so we need to patch a Makefile to reduce the annoyance. No biggie. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> As it stands, there is no way to determine programatically whether > gcc-2.96 is broken or now. The only way to do it is to check the RPM > version -- which, needless to say, is a bit difficult to do from the > C code about to be compiled. So I can't really blame Hans if he decides > to outlaw gcc-2.96[.0] for reiserfs compiles. Oh I can see why Hans wants to cut down his bug reporting load. I can also say from experience it wont work. If you put #error in then everyone will mail him and complain it doesnt build, if you put #warning in nobody will read it and if you dont put anything in you get the odd bug report anyway. Basically you can't win and unfortunately a shrink wrap forcing the user to read the README file for the kernel violates the GPL .. Jaded, me ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Every Make option ends in error.
Dick, and Mark, thanks. It's compiling nicely now. We learn by experience. Cheers, Ken > Not to worry. In your new Linux directory tree do: > > cd include > mv asm /tmp # or /usr/src, someplace temporary. > > cd .. # Back to Linux > cp .config .. # Save your configuration > make mrproper # Make like a distribution > cp ../.config . # Restore configuration > make oldconfig# Re-do configuration > make dep # Re-do dependencies > make bzImage # Doit toit > > After everything works, recursively delete the saved 'asm' > directory that was moved outside the kernel tree. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Every Make option ends in error.
> Copied a plain 2.4.0 tree to a new directory, patched it to 2.4.1 without > any errors. Then I realised it had all the object files from my last > compile, so I thought "make mrproper" was called for. It did a little, > then You copied the link and turned it into its contents > rm: include/asm: is a directory > make: *** [mrproper] Error 1 do rm -rf include/asm and then rerun the makes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Lets not go overboard Alan ;-) > > It makes sense to refuse to build a piece of the kernel if it break's > > a machine - anything else is a timebomb waiting to explode. > > The logical conclusion of that is to replace the entire kernel tree with > > #error "compiler or program might have a bug. Aborting" > > The kernel is NOT some US home appliance festooned with 'do not eat this > furniture' and 'do not expose your laserwrite to naked flame' messages. > The readme says its been tested with egcs-1.1.2 and gcc 2.95. > > The same people who can't read documentation will just mail the list with > 'it doesnt compile, help' or 'it doesnt compile, you suck' in less enlightened > cases/ > > Large numbers of people routinely build the kernel with 'unsupported' compilers > notably the pgcc project people and another group you will cause problems for > - the GCC maintainers. They use the kernel tree as part of the test set for > their kernel, something putting #ifdefs all over it will mean they have to > mess around to fix too. > > Alan > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] PCI-SCI Drivers v1.1-6 released
Linux Kernel, (Sorry, had one more change that did not make the patch. this release contains the corrected patch). Version 1.1-6 of the Dolphin PCI-SCI (Scalable Coherent Interface) drivers for Linux kernels 2.2.X and 2.4.X have been posted at vger.timpanogas.org:/sci. These drivers are freely available under the GNU public license and are provided in both RPM and tar.gz formats. NOTES: This release corrects an SMP/non-SMP auto-detection problem during driver install. If someone is using an SMP kernel on a single processor system, this version checks the kernel build tree to determine which option was built with the drivers in the /usr/src/linux/.config file prior to installing the drivers. This version corrects a reported bug for those folks who compile an SMP kernel on a APIC supported single CPU system during driver install. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] G450 and lockup
> Alan, I'm sending it to you and not to Linus, as ac1 contains newer > matroxfb than Linus tree and doing otherwise would make your work harder > without any reason. But please make sure that Linus's 2.4.2 will contain > this fix. I can try. You might want to send him the stuff too though 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops - 2.4.0-ac12
Finally, after many crashes which I have not been able to capture, here is two Oops'es which I have transfered by hand from my one machine to another. Solid lockup I am afraid, only thing working was Alt-SysRq keys. # Oops #1 follows Unable to handle kernel paging request at virtual address 5b919ba8 printing eip: c01a66c2 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00013086 eax: c5d0a200 ebx: 200a ecx: 8028edx: 5b919aa8 esi: 200a edi: 0001 ebp: c02d4820esp: c5061f4c ds: 0018 es: 0018 ss: 0018 Process X (pid: 800, stackpage=c5061000) Stack: c02d4120 0001 b634 0001 c01a437a 0001 0001 0001 c02d4120 002d4820 c01a446d 0001 c02ab580 c01a965f 0001 0006 c011984c 0001 c02ab5d8 0007 Call Trace: [] [] [] [] [] [] Code: 8b 82 00 01 00 00 89 3d 28 46 2d c0 39 10 74 21 8b 81 20 48 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing # Then I did Alt-SysRq-U and got the following SysRq: Emergency Remount R/O Remounting device 03:03 ... Scheduling in interrupt Kernel BUG at sched.c:688! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00013286 eax: 001b ebx: c5061dd8 ecx: 0001edx: c0263b88 esi: c11fc240 edi: c506 ebp: c5061dc4esp: c5061d94 ds: 0018 es: 0018 ss: 0018 Process X (pid: 800, stackpage=c5061000) Stack: c021c765 c021c8b6 02b0 c5061dd8 c11fc240 c506 c0119a44 c02d5b60 c5061dd8 c11fc240 c02d5bc4 c013106a c39a7240 0303 0001 c506 c11fc28c c11fc28c c0131114 c11fc240 0303 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing This should be fairly accurate. I did my best to copy it across w/o mistakes. After rebooting I got these stats out. -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux alien 2.4.0-ac12 #2 Thu Feb 1 11:51:08 GMT 2001 i686 unknown Kernel modules 2.3.17 Gnu C 2.95.2 Gnu Make 3.79.1 Binutils 2.10.0.26 Linux C Library2.1.3 Dynamic Linker ldd (GNU libc) 2.1.3 Procps 2.0.7 Mount 2.10o Net-tools 1.57 Console-tools 0.2.3 Sh-utils 2.0 Modules Loaded tulip_cb cb_enabler ibmtr_cs ds i82365 pcmcia_core ipt_REDIRECT ipt_MASQUERADE ip_nat_ftp iptable_nat iptable_mangle iptable_filter ipt_unclean ipt_tos ipt_state ipt_owner ipt_multiport ipt_mark ipt_mac ipt_limit ipt_TOS ipt_REJECT ipt_MIRROR ipt_MARK ipt_LOG ip_tables ip_conntrack_ftp ip_conntrack mpu401 sb sb_lib uart401 sound soundcore If any more details should be required, I will be more than happy to try and get them. The interesting thing was that the system reported all filesystems clean upon boot. (!) /Anders - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
> It makes sense to refuse to build a piece of the kernel if it break's > a machine - anything else is a timebomb waiting to explode. The logical conclusion of that is to replace the entire kernel tree with #error "compiler or program might have a bug. Aborting" The kernel is NOT some US home appliance festooned with 'do not eat this furniture' and 'do not expose your laserwrite to naked flame' messages. The readme says its been tested with egcs-1.1.2 and gcc 2.95. The same people who can't read documentation will just mail the list with 'it doesnt compile, help' or 'it doesnt compile, you suck' in less enlightened cases/ Large numbers of people routinely build the kernel with 'unsupported' compilers notably the pgcc project people and another group you will cause problems for - the GCC maintainers. They use the kernel tree as part of the test set for their kernel, something putting #ifdefs all over it will mean they have to mess around to fix too. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
My last comment on this... It makes sense to refuse to build a piece of the kernel if it break's a machine - anything else is a timebomb waiting to explode. I feel politics are at play here...I don't really care who's bug it is - all I know is using pre 2.96 fixes it and everyone needs to be aware of this. If this means checking in Reiserfs makefile or the main Linux makefile then so be it. Its simple logic ;-) John > Alan Cox wrote: > > > > > So, did Linus say no? If not, let's ask him with a patch. Quite simply, > > > neither we nor the users should be burdened with this, and the patch removes > > > the burden. > > > > Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget > > to stop those being used as well. Oh look you'll need CVS gcc to build the > > kernel... ah but wait that misbuilds DAC960.c... > > > > Oh look nothing compiles the kernel. > > > > Congratulations 8) > > > > Alan > > > Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use > reiserfs. It is that simple. How can you even consider defending allowing the > use of it without requiring a positive affirmation by the user that they don't > know what they are doing and want to do it anyway?:-) I could understand > arguing that you don't want to be bothered with protecting the users because you > don't have the time, but if somebody else finds the time to write the patch > > I would indeed encourage Linus to accept patches to test for known bad compilers > at make time. It is less work for us all to prevent users from having bugs than > to respond to their having them. I look forward to gcc 3.00, and I encourage > the compiler guys to get over being (understandably) irked that somebody else > released their code prematurely, and to increment the version number to 2.97 so > that users can more easily avoid the baddie. > > Hans > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
