Re: 2.4.5: USB audio crash again; now with info
On Mon, May 28, 2001 at 07:46:54AM +0200, Jakob Borg wrote: > system is a dual P2 400, details to be found in the attached dmesg and > .config. Hrm. Attached here; sorry. //jb May 28 07:13:01 narayan kernel: klogd 1.4.1#2, log source = /proc/kmsg started. May 28 07:13:01 narayan kernel: Inspecting /boot/System.map-2.4.5 May 28 07:13:01 narayan kernel: Loaded 18580 symbols from /boot/System.map-2.4.5. May 28 07:13:01 narayan kernel: Symbols match kernel version 2.4.5. May 28 07:13:01 narayan kernel: No module symbols loaded. May 28 07:13:01 narayan kernel: ce. May 28 07:13:01 narayan kernel: hm, page 000f6000 reserved twice. May 28 07:13:01 narayan kernel: hm, page 000f7000 reserved twice. May 28 07:13:01 narayan kernel: On node 0 totalpages: 131069 May 28 07:13:01 narayan kernel: zone(0): 4096 pages. May 28 07:13:01 narayan kernel: zone(1): 126973 pages. May 28 07:13:01 narayan kernel: zone(2): 0 pages. May 28 07:13:01 narayan kernel: Intel MultiProcessor Specification v1.4 May 28 07:13:01 narayan kernel: Virtual Wire compatibility mode. May 28 07:13:01 narayan kernel: OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 May 28 07:13:01 narayan kernel: Processor #1 Pentium(tm) Pro APIC version 17 May 28 07:13:01 narayan kernel: Floating point unit present. May 28 07:13:01 narayan kernel: Machine Exception supported. May 28 07:13:01 narayan kernel: 64 bit compare & exchange supported. May 28 07:13:01 narayan kernel: Internal APIC present. May 28 07:13:01 narayan kernel: SEP present. May 28 07:13:01 narayan kernel: MTRR present. May 28 07:13:01 narayan kernel: PGE present. May 28 07:13:01 narayan kernel: MCA present. May 28 07:13:01 narayan kernel: CMOV present. May 28 07:13:01 narayan kernel: PAT present. May 28 07:13:01 narayan kernel: PSE present. May 28 07:13:01 narayan kernel: MMX present. May 28 07:13:01 narayan kernel: FXSR present. May 28 07:13:01 narayan kernel: Bootup CPU May 28 07:13:01 narayan kernel: Processor #0 Pentium(tm) Pro APIC version 17 May 28 07:13:01 narayan kernel: Floating point unit present. May 28 07:13:01 narayan kernel: Machine Exception supported. May 28 07:13:01 narayan kernel: 64 bit compare & exchange supported. May 28 07:13:01 narayan kernel: Internal APIC present. May 28 07:13:01 narayan kernel: SEP present. May 28 07:13:01 narayan kernel: MTRR present. May 28 07:13:01 narayan kernel: PGE present. May 28 07:13:01 narayan kernel: MCA present. May 28 07:13:01 narayan kernel: CMOV present. May 28 07:13:01 narayan kernel: PAT present. May 28 07:13:01 narayan kernel: PSE present. May 28 07:13:01 narayan kernel: MMX present. May 28 07:13:01 narayan kernel: FXSR present. May 28 07:13:01 narayan kernel: Bus #0 is PCI May 28 07:13:01 narayan kernel: Bus #1 is PCI May 28 07:13:01 narayan kernel: Bus #2 is ISA May 28 07:13:01 narayan kernel: I/O APIC #2 Version 17 at 0xFEC0. May 28 07:13:01 narayan kernel: Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 05, APIC ID 2, APIC INT 05 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 08, APIC ID 2, APIC INT 08 May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e May 28 07:13:01 narayan kernel: Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f May 28 07:13:01 narayan kernel: Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 May 28 07:13:01 narayan kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 13, APIC ID 2, APIC INT 13 May 28 07:13:01 narayan kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12 May 28 07:13:01 narayan kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 2c, APIC ID 2, APIC INT 11 May 28 07:13:01 narayan kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 May 28 07:13:01 narayan kernel: Lint: type 3, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 00 May 28 07:13:01 narayan kernel: Lint: type 1, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 01 May 28 07:13:01 narayan kernel: Processors: 2 May 28 07:13:01 narayan kernel: mapped APIC to e000
2.4.5: USB audio crash again; now with info
Hey; 2.4.5 again seems to have the same bug that was introduced in 2.4.4, that the systems locks up completely when accessing and USB audio device. The system is a dual P2 400, details to be found in the attached dmesg and .config. The device in question is "device 3" after the kernel has enumerated devices (the other device being a webcam and there being no device 1). However, this time the following message was printed to the console a few seconds after the lockup (copied by hand, accurately I hope). I _really_ hope someone has an idea this time, because it makes any kernel >2.4.3 unuseable. wait_on_irq, CPU 1: irq: 1 [ 1 0 ] bh: 0 [ 0 1 ] Stack dumps: CPU 0: CPU 1:dfff3ec4 c028d233 0001 0020 c010825d c028d248 dfff3f14 dd5d7000 0001 c0186a97 dfff3f14 dfff3f14 c035e860 dd5d7368 c0118a8c dd5d7000 c030cc8c 0020 dd5d7130 dd5d7130 c01937db c030cb68 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Trace; c010825d <__global_cli+bd/124> Trace; c0186a97 Trace; c0118a8c <__run_task_queue+60/74> Trace; c01937db Trace; c01187eb Trace; c011870c Trace; c01085f5 Trace; c0105180 Trace; c0105180 Trace; c0106d2c Trace; c0105180 Trace; c0105180 Trace; c0100018 Trace; c01051ac Trace; c0105212 Trace; c0207ee7 Trace; c01906ce Best regards, //jb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-ntfs] Re: [Linux-NTFS-Dev] Re: ANN: NTFS new release available (1.1.15)
Martin von Loewis wrote: >That would not work: NT would split individual runs across extends >(i.e. split them in the middle). Did I misunderstand, or do you have a >solution for that as well. > Are you sure that it's true? My NTFS resizer interprets parts of runlist stored in different FILE records independently and I never experienced any problems with that. Yuri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac2
actually, it happens on ext2, also. it was fun trying to switch back to 2.2 after converting raid devs for 2.4 and trashing my emergency boot disk. i was finally able to restore from tape by mounting -o sync. there was still some minor corruption caught by fsck, though. the new sym53c875 driver seems to have fixed the pci_map_sg() problem i was having, but now it complains about scsi script errors. changing the TCQ defaults from 32 to 8 fixes that. though, the corruption (even with TCQ max 8 and -o sync) may be related. anyone else tried 2.4.5-ac2 on a miata or other alpha? On Sun, May 27, 2001 at 11:38:01PM -0400, Tom Vier wrote: > i haven't had any reiserfs crashes on my alpha, but restoring a backup of a > debian installation to a reiserfs partition doesn't quite work. untarring a > linux kernel tarball to the fs works, does work though. i get these kernel > messages: -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
File read.
hi, How do i read file within the kernel modules. I hope we can't use the FS open... calls within kernel. thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]initrd unmount problem
Hi, It seems that ioctl_by_bdev() in fs/block_dev.c has a problem. When initrd is unmounted it can cause OOPS. This problem occurs in recent ac patches. May be vanilla too. change_root() in fs/super.c calls ioctl_by_bdev() in fs/block_dev.c which does not set inode_fake.i_bdev. But ioctl of ramdisk (rd_ioctl() in rd.c) accesses to i_bdev->bd_openers of the inode and which causes OOPS. I attach the patch. - GO! --- linux/fs/block_dev.c.orig Mon May 28 12:40:12 2001 +++ linux/fs/block_dev.cMon May 28 12:40:12 2001 @@ -602,6 +602,7 @@ if (!bdev->bd_op->ioctl) return -EINVAL; inode_fake.i_rdev=rdev; + inode_fake.i_bdev=bdev; init_waitqueue_head(_fake.i_wait); set_fs(KERNEL_DS); res = bdev->bd_op->ioctl(_fake, NULL, cmd, arg);
Re: Console display in portrait mode with unusual dpi resolution
O Wyss writes: > [Running flatscreen in portrait mode] > > The portrait mode software starts working just about before the logon > screen is shown. All the BIOS and system messages are shown in landscape > mode. From the nature of a software solution I guess this can't be > changed neither of Windows NT4 nor Linux. Probably the place to hack this is in the framebuffer console code. This will not help with BIOS messages, but you _should_ be able to get all Linux output in the portrait rotated mode with the FB console. > 3. Obstacle > The EIZO L675 has a pixel pitch of 0.28x0.28 which is equivalent to > about 90dpi. Since Windows (any version) uses a default value on 96dpi, > everything is enlarged by about 5%. So even with an 18" display an A4 > page can't be normally viewed in Word. Current status from Microsoft > "problem is recognized, we are working on it". While there is no > solution for Windows (probably until SP1 for XP) what's the status of > Linux? X does not have a standard DPI, so it doesn't really matter. On CRT screens, you could adjust your DPI via XFree86 modelines. On LCD screens DPI is fixed so you have to work with that. If the screen supports DDC (it should if it is new), it will tell the X server what the DPI is, so you don't need to set it manually. Running "xdpyinfo" under X will tell you what the resolution is (my current screen happens to report 109x112 DPI = 1600x1200 on a 19" screen). I think GIMP can work with the DPI info reported from the X server. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Abysmal RECV network performance
Can someone please help me troubleshoot this problem - I am getting abysmal (see numbers below) network performance on my system, but the poor performance seems limited to receiving data. Transmission is OK. The computer in question is a dual Pentium 90 machine. The machine has RedHat 7.0 (kernel 2.2.16-22 from RedHat). I have compiled 2.2.19 (stock) and 2.4.3 (stock) for the machine and used those for testing. I had a NetGear FA310TX card that I used with the "tulip" driver and a 3Com 3CSOHO card (Hurricane chipset) that I used with the "3c59x" driver. I used the netperf package to test performance (latest version, but I don't have the version number off-hand). The numbers netperf is giving me seem to correlate well to FTP statistics I see to the box. I have a second machine (P2-350) with a NetGear FA311 (running 2.4.3 and the "natsemi" driver) that I used to talk with the Pentium 90 machine. The two machines are connected through a NetGear FS105 10/100 switch. I also tried using a 10BT hub (see below). When connected, the switch indicated 100 Mbps, full duplex connections to both cards. This matches the speed indicator lights on both cards. I have run the miidiag program in the past to verify that the cards are actually set to full duplex, but I didn't run it again this time (this isn't the first time I have tried to chase this problem down). For the purposes of this message, call the P2-350 machine "A" and the dual P-90 machine "B". I ran the following tests: Machine "A" to localhost754.74 Mbps Kernel 2.2.19SMP Machine "B" to localhost80.63 Mbps Machine "B" to "A" (tulip) 55.38 Mbps Machine "A" to "B" (tulip) 10.60 Mbps Machine "A" to "B" (3c95x) 12.10 Mbps Kernel 2.4.3 SMP Machine "B" to localhost83.87 Mbps Machine "B" to "A" (tulip) 68.07 Mbps Machine "A" to "B" (tulip) 1.62Mbps Machine "A" to "B" (3c95x) 2.37Mbps Kernel 2.2.16-22 (RedHat kernel) Machine "B" to localhost92.29 Mbps Machine "B" to "A" (tulip) 57.34 Mbps Machine "A" to "B" (tulip) 9.98Mbps Machine "A" to "B" (3c95x) 9.05Mbps Now, with both "A" and "B" plugged into a 10BT hub: Kernel 2.2.19SMP Machine "B" to "A" (tulip) 6.96Mbps Machine "A" to "B" (tulip) 6.89Mbps At the end of the runs, I do not see any messages in syslog that would indicate a problem. Using the switch, there were no collisions but looking at /sbin/ifconfig there were a lot of "Frame:" errors on receive. "A lot" means ~30% of the total packets received. This happened with both cards and all kernels. The conclusions I draw from this data are: 1) Both machines connecting to localhost (data not going out over the wire) give reasonable numbers and are considerably above what I actually see going over the network (as would be expected). 2) The P-90 machine seems to have good transmit speed over both cards and all kernels. Transmit performance is close to the localhost numbers, so I can believe them. In the past, I have compared the performance of the FA310 to the 3ComSOHO card and there did not seem to be any measurable performance difference between the two. 3) Both the FA310 and the 3ComSOHO card have similar receive speeds, leading me to believe that the problem lies with either the machine or the kernel and not the individual cards or drivers. 4) Booting the machine as a uni-processor machine (with a non-SMP 2.2.16 kernel) did not change anything, so it does not appear to be a problem with SMP. 5) Kernel 2.4.3 receive performance is significantly lower than either 2.2.x kernel, so that tends to point to some fundamental problem in the kernel. 6) As I understand it, the 3Com card has some hardware acceleration for checksumming, and this is a slow machine, so why is the performance almost identical to the FA310? So, my questions are: What kind of performance should I be seeing with a P-90 on a 100Mbps connection? I was expecting something in the range of 40-70 Mbps - certainly not 1-2 Mbps. What can I do to track this problem down? Has anyone else had problems like this? Thanks in advance for any help you can offer. - John _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac2
Ok, things are fast again now! :)) Performance is back to that of 2.4.2-ac26, and stability is a lot better. Under heavy FS pressure 2.4.5-ac2 is about 5-10% faster than vanilla 2.4.5, the aa1,2 kernels have the same performance of vanilla 2.4.5. Which one of your changes affected performance so much? BTW: the hangs that you are talking about in the 2.4.4 series, are they total freezes? I've sporadically observed in a few 2.4.4-acX kernels strange hung-ups where the system is still running, but very slowly, ps and other similar commands (top) hang and you cannot kill them anymore. I think that this is some sort of (memory?) resource deadlock. The only miraculous way to resurrect such a locked system is to start Mozilla... everything goes back to normal! For the curious, the latest Ximian Gnone has the terminal and the mozilla icons next to each other and I clicked on the wrong icon by mistake... - Fabio Alan Cox wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > Intermediate diffs are available from > http://www.bzimage.org > > In terms of going through the code audit almost all the sound drivers still > need fixing to lock against format changes during a read/write. Poll creating > and starting a buffer as write does and also mmap during write, write during > an mmap. > > 2.4.5-ac2 > o Restore lock_kernel on umount (Al Viro) > | Should cure Reiserfs crash in 2.4.5 > o Fix additional scsi_ioctl leak (John Martin) > o Clean up scsi_ioctl error handling (me) > o Configure.help typo fixes (Nerijus Baliunas) > o Fix hgafb problems with logos (Ferenc Bakonyi) > o Fix lock problems in the rio driver (Rasmus Andersen) > o Make new cmpci SMP safe (Carlos E Gorges) > o Fix missing restore flags in soundmodem (Rasmus Andersen) > o Set max sectors in ps2esdi (Paul Gortmaker) > o Fix interrupt restore problems in mixcom(Rasmus Andersen) > o Fix alpha compile on dp264/generic (Andrea Arcangeli) > o Fix irda irport locking restores(Rasmus Andersen) > o Fix failed kmalloc handling in hisax(Kai Germaschewski) > o Add missing memory barrier in qlogicisp (?) > o Fix missing restore_flags in eata_dma (Rasmus Andersen) > o Fix procfs locking in irttp (Rasmus Andersen) > o Winbond updates (Manfred Spraul) > o Stop network eating PF_MEMALLOC ram (Manfred Spraul) > o Drop fs/buffer.c low mem flush changes (me) > o Drop changes to mm/highmem.c(me) > | I don't think the Linus one is quite right but its easier > | for everyone to be working off one base > o Revert GFP_FAIL and some other alloc bits (me) > o Hopefully fix initrd problem(me) > o Fix kmalloc check in ide-tape (Rasmus Andersen) > o Fix irda irtty locking (Rasmus Andersen) > o Fix missing irq restore in qla1280 (Rasmus Andersen) > o Fix proc/pid/mem cross exec behaviour (Arjan van de Ven) > o Fix direct user space derefs in eicon (me) > | From Stanford checker > o Fix direct user space derefs in ipddp (me) > | From Stanford checker > o Fix direct user space derefs in ixj (me) > | From Stanford checker > o Fix direct user space derefs in decnet (me) > | From Stanford checker > > 2.4.5-ac1 > o Merge Linus 2.4.5 tree > > Summary of changes for Linux 2.4.5-ac versus Linus 2.4.5 > > o Fix memory leak in wanrouter > o Fix memory leak in wanmain > o Use non atomic memory for linearising NFS buffers as they are > done in task context > o Fix dereference of freed memory in NetROM drivers > o Fix writing to freed memory in ax25_ip > o Support debugging of slab pools > o NinjaSCSI pcmcia scsi driver > o Raw HID device for USB peripheral buttons/controllers > o Updated NTFS > o RAMfs with resource limits > o NMI watchdog available on uniprocessor x86 > o Update CMPCI drivers (not yet SMP safe) > o Configurable max_map_count > o Dynamic sysctl key registration > o SE401 USB camera driver > o Updated Zoran ZR3606x driver (replaces buz) > o w9966 parallel port camera driver (partially merged with Linus) > o Include headers in etags > o Don't delete empty directories on make distclean > o Fix halt/reboot handling on Alcor Alpha > o IDE driver support for Etrax E100 > o IDE infrastructure support
Re: Linux 2.4.5-ac2
i haven't had any reiserfs crashes on my alpha, but restoring a backup of a debian installation to a reiserfs partition doesn't quite work. untarring a linux kernel tarball to the fs works, does work though. i get these kernel messages: May 27 23:28:47 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=17, free_space=132 rdkey May 27 23:28:47 zero kernel: vs-5150: search_by_key: invalid format found in block 11693. Fsck? May 27 23:28:47 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [1361 1362 0x0 SD] May 27 23:28:47 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (1361 1362) not found May 27 23:28:47 zero last message repeated 2 times May 27 23:28:48 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:48 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:48 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3215 3216 0x0 SD] May 27 23:28:48 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3215 3216) not found May 27 23:28:48 zero last message repeated 2 times May 27 23:28:49 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:49 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:49 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3208 3210 0x0 SD] May 27 23:28:49 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3208 3210) not found May 27 23:28:49 zero last message repeated 2 times May 27 23:28:49 zero kernel: is_leaf: free space seems wrong: level=1, nr_items=18, free_space=568 rdkey May 27 23:28:49 zero kernel: vs-5150: search_by_key: invalid format found in block 14392. Fsck? May 27 23:28:49 zero kernel: vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of [3208 3211 0x0 SD] May 27 23:28:49 zero kernel: vs-13048: reiserfs_iget: bad_inode. Stat data of (3208 3211) not found May 27 23:28:49 zero last message repeated 8 times On Mon, May 28, 2001 at 01:33:42AM +0100, Alan Cox wrote: > 2.4.5-ac2 > o Restore lock_kernel on umount (Al Viro) > | Should cure Reiserfs crash in 2.4.5 -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Performance lack !
"Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote: > > Are you sure it is idle. It might be running something from cron- > say 'updatedb' or similar. That will cause a lot of disk i/o, > and _ofcourse_ performance will be bad then - the machine is > doing a lot of other things. > I am the only user who use my linux boxes , i never use cron , and i have no relation with database at all. > It might also be that you don't have enough memory and the > machine is swapping itself to death. Running netscape or > mozilla perhaps? These are known to blow themselves up to > 50-100 MB (!). That will cause the exact symptoms you're seeing. > I never go to X-Windows , i do all my work from console. cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 114475008 111816704 2658304 5234688 68067328 24711168 Swap: 583954432 2654208 581300224 MemTotal:111792 kB MemFree: 2596 kB MemShared: 5112 kB Buffers: 66472 kB Cached: 24132 kB SwapTotal: 570268 kB SwapFree:567676 kB > > 2.4.2 isn't all that good either.. 2.4.x doesn't have VM sorted > out just yet > may be this problem of VM as suggested by Mark Hahn. Thank you, Jaswinder. -- These are my opinions not 3Di. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hard lockup switching to X from vc; Matrox G400 AGP
I experienced lost of the signal when switching from X to the console when booting with vga=ext or some of the graphic modes. It was reported here that the problem was the Matrox drivers. Recently, with kernel 2.4.4+ and XFree 4.0.3 (@1280x1024/head)+ Matrox drivers (http://matrox.com/mga/support/drivers/files/linux_06.cfm) and booting with vga=794 (1280x1024) I have not had problems. I've a G450. -- Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Matrox G400 Dualhead
It would help if you reported which version of kernel and XF86 you are using. I had problems using the framebuffer in the console awhile back. Currently, running 2.4.4+ and XFree86 4.0.3 + Matrox's drivers (http://matrox.com/mga/support/drivers/files/linux_06.cfm) give me no problem. I don't run the frame buffer for X for dual head. -- Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Configure.help entries wanted
Jaswinder Singh wrote: > > What is the companion chip in DMIDA ? HD64465. > IrDA and USB are working properly in linux ? No. IrDA seems easy, just haven't got around to it. USB is a major pain on the HD64465 because of the way it deals with "host" memory. I had a driver which initialised the root hub at one point but haven't had time to push it any further. Greg. -- If it's a choice between being a paranoid, hyper-suspicious global village idiot, or a gullible, mega-trusting sheep, I don't look good in mint sauce. - jd, slashdot, 11Feb2000. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Configure.help entries wanted
"Greg Banks" <[EMAIL PROTECTED]> wrote: > > Manufacturer = DataMyte, a division of Rockwell. > Machine = DataMyte Industrial Digital Assistant 4000 > (aka DMIDA, www.dmida.com) > What is the companion chip in DMIDA ? IrDA and USB are working properly in linux ? Thank you, Best Regards, Jaswinder. -- These are my opinions not 3Di. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
License Clarification [X15 beta 1 - source release]
Some people pointed out that I misused the term "Open Source" wrt our Source License. Our license doesn't meet the required criteria of the OSI since we restrict the usage of our sources for personal use only. As was already pointed out in my previous message people will have to buy a license for commercial exploitation of the code (i.e. running a commercial web site). Sorry for the inconvenience, - Fabio Fabio Riccardi wrote: > Dear all, > > I finally managed to package the X15 web accelerator for the first > source release. > > The current release includes a CGI module, an Apache configuration > module and several salability improvements. It is a beta 1, quite stable > but it may/will still contain a few bugs. The README is a bit outdated > and the code could use more comments... :) > > The code It is released under an Open Source license very much in the > spirit of Sun/Solaris, Apple/Darwin, etc., but less restrictive. > > Basically (for what I have been explained by our lawyers :) the license > says that: > > 1) you can peruse the code for your own use and/or research in any way > you like, > > 2) you can use X15 for your own non commercial use (i.e., you can have > the fastest family reunion pictures website of the planet), > > 3) if you want to use the software for any commercial exploitation you > have to buy a license from Chromium Communications, > > 4) if you make changes they belong to you, but if you send them back to > us than you agree to not claim anything for them. > > You can get the sources from: > http://www.chromium.com/cgi-bin/crosforum/YaBB.pl > > or (when the DNS gets propagated) from: http://source.chromium.com/ > > Our source site sports one of those nifty sourceforge-like interfaces > for discussions, bug reports and whatever, I'd prefer you to use that > instead of sending email directly to me or to this list. > > I'll build a proper "product" web page and add more documentation in the > next few days. > > - Fabio > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPU Dedicated Interrupts
> What is the easiest way to tell a CPU to ignore certain interrupts from > module? > Is there an IRQ mask for each processor? Is that symbol exported? > I also what to know this :) Please help us . Thank you. Jaswinder. -- These are my opinions not 3Di. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/devfs/base.c
Akash Jain writes: > hello, > > in fs/devfs/base.c, > the struct devfsd_notify_struct is approx 1056 bytes, allocating it > on a stack of 8k seems unreasonable. here we simply move it to the > heap, i don't think it is a _must_ be on stack type thing I absolutely don't want this patch applied. It's bogus. It is entirely safe to alloc 1 kB on the stack in this code, since it has a short and well-controlled code path from syscall entry to the function. This is not some function that can be called from some random place in the kernel and thus has a random call path. Using the stack is much faster than calling kmalloc() and it also doesn't add to system memory pressure. That's why I did it this way in the first place. Further, it's much safer to use the stack, since the memory is freed automatically. Thus, there's less scope for introducing errors. Please fix your checker to deal with this class of functions which have a well-defined call path. I'd suggest looking at the total stack allocations from syscall entry point all the way to the end function. Ideally, you'd trace the call path to every function, but of course that may be computationally infeasible. Hopefully it's feasible to do this for any function which has a stack allocation which exceeds some threshold. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems Configurating NFS
I am trying to config my RedHat7.0 computer to run NFS server, I have edited the exports file, and turned on portmap and NFS, but there were some problems as follows, how can I fix it? Starting system logger: [ OK ] Starting kernel logger: [ OK ] Starting portmapper: [ OK ] Starting NFS file locking services: Starting NFS lockd: portmap: server localhost not responding, timed out portmap: server localhost not responding, timed out lockd_up: makesock failed, error=-5 portmap: server localhost not responding, timed out lockdsvc: Input/output error [FAILED] Starting NFS statd: [ OK ] Starting up APM daemon: [ OK ] Initializing random number generator: [ OK ] Mounting NFS filesystems: mount: can't get address for server [FAILED] Mounting other filesystems: [MS-DOS FS Rel. 12,FAT 16,check=n,conv=b,uid=0,gid=0,umask=022,bmap] [me=0x7e,cs=756,#f=16,fs=62548,fl=193668,ds=3292308,de=4734,data=3292608,se=5246,ts=2116189728,ls=3198,rc=0,fc=4294967295] Transaction block size = 512 VFS: Can't find a valid MSDOS filesystem on dev 03:05. mount: wrong fs type, bad option, bad superblock on /dev/hda5, I wish to be personally CC'ed the answers/comments posted to the list in response to my posting. Thank you. Thanks, Anton -- Åwªï¨Ï¥ÎHongKong.com¶l¥ó¨t²Î Thank you for using hongkong.com Email system - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keys
Hi Greg, On 25-May-2001 Greg KH wrote: > On Thu, May 24, 2001 at 09:34:04PM -0700, Aaron Lehmann wrote: >> This message sparked a long thread on the debian-legal mailing list, >> which is long since dead. I am personally very curious about whether >> this has been resolved upstream. I consider it a very important issue, >> which is why I asked for RMS' opinion. He said that what is being done >> is clearly not "mere aggregation", and that such firmware should be >> moved out of the kernel (and even the tarball) to stop violating the >> GPL and make Linux be free software. > > Last I heard, Hugh was talking with the Keyspan people to get this > resolved. But that was a few weeks ago. > > Any news Hugh? Will follow it up. Cheers, Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Problems with ac12 kernels and up
>> I looked at the root_mountflags usage and it looks ok, so I put it in >> the "figure out later" pile. >> >> Haven't yet verified if this 'ac' only problem > >Think I have it sussed. Time for -ac2 I took down my Jerry Garcia poster, and put up an Alan Cox poster. 2.4.5-ac2 boots like a champ. Thanks! (will this make it into a 2.4.4-ac19 patch?) -- John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hard lockup switching to X from vc; Matrox G400 AGP
Hi, thanks for confirming this. But if it's Matrox's code (we are talking about the mga_hal_drv.o module for X, correct?) then the ball is in their court. Has anyone reported this to them so that they can fix it? Cheers, Chris > On Mon, May 28, 2001 at 12:24:50AM +0200, Ben Twijnstra wrote: > > Hi Chris, > > > > Seen the same behaviour; you're not alone. I'm running XF86 4.0.3 with > > a G400. My guess is that mga_drv goes into some local loop while trying > > to restore the display. mga_drv at that moment has I/O privileges and if > > it hangs, Linux hangs too. > > It is problem with their driver. Their are resetting too much of > hardware state during mode switches and if someone accesses memory > at that moment, whole thing locks up your PCI bus - if you have ATX > box, try hitting poweroff button next time it lockups. If poweroff > does not work you'll have bad time to get it debugged. If poweroff > button works, you can try kdb... > > On my machine it is 100% reproducible if I run 'fbtv -k' and start X. > It will die immediately. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Configure.help entries wanted
> Their co-operation came not from a spirit of enlightment but > because this was a commercial venture to port Linux to the box > to replace WinCE. You can buy these with Linux now. Including open source drivers for their touchscreen ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 2.4.5 does not link on Ruffian (alpha)
On Sun, May 27, 2001 at 07:54:17PM -0400, Jeff Garzik wrote: > FWIW the documentation seems to imply that the option is necessary only > when directly booting from SRM, i.e.. no bootloader is involved at all. Err, well, you can't have _no_ bootloader. > It uses the example of MILO's presence or absence as indicating the need > for this option. Exactly. aboot doesn't substitute. > So... is it safe to always enable this option, with a little hacking > perhaps? :) Well, yes, it is obviously possible. The generic config does what you want. You just need to permanently enable some of that configury. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac2
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac2 o Restore lock_kernel on umount (Al Viro) | Should cure Reiserfs crash in 2.4.5 o Fix additional scsi_ioctl leak (John Martin) o Clean up scsi_ioctl error handling (me) o Configure.help typo fixes (Nerijus Baliunas) o Fix hgafb problems with logos (Ferenc Bakonyi) o Fix lock problems in the rio driver (Rasmus Andersen) o Make new cmpci SMP safe (Carlos E Gorges) o Fix missing restore flags in soundmodem (Rasmus Andersen) o Set max sectors in ps2esdi (Paul Gortmaker) o Fix interrupt restore problems in mixcom(Rasmus Andersen) o Fix alpha compile on dp264/generic (Andrea Arcangeli) o Fix irda irport locking restores(Rasmus Andersen) o Fix failed kmalloc handling in hisax(Kai Germaschewski) o Add missing memory barrier in qlogicisp (?) o Fix missing restore_flags in eata_dma (Rasmus Andersen) o Fix procfs locking in irttp (Rasmus Andersen) o Winbond updates (Manfred Spraul) o Stop network eating PF_MEMALLOC ram (Manfred Spraul) o Drop fs/buffer.c low mem flush changes (me) o Drop changes to mm/highmem.c(me) | I don't think the Linus one is quite right but its easier | for everyone to be working off one base o Revert GFP_FAIL and some other alloc bits (me) o Hopefully fix initrd problem(me) o Fix kmalloc check in ide-tape (Rasmus Andersen) o Fix irda irtty locking (Rasmus Andersen) o Fix missing irq restore in qla1280 (Rasmus Andersen) o Fix proc/pid/mem cross exec behaviour (Arjan van de Ven) o Fix direct user space derefs in eicon (me) | From Stanford checker o Fix direct user space derefs in ipddp (me) | From Stanford checker o Fix direct user space derefs in ixj (me) | From Stanford checker o Fix direct user space derefs in decnet (me) | From Stanford checker 2.4.5-ac1 o Merge Linus 2.4.5 tree Summary of changes for Linux 2.4.5-ac versus Linus 2.4.5 o Fix memory leak in wanrouter o Fix memory leak in wanmain o Use non atomic memory for linearising NFS buffers as they are done in task context o Fix dereference of freed memory in NetROM drivers o Fix writing to freed memory in ax25_ip o Support debugging of slab pools o NinjaSCSI pcmcia scsi driver o Raw HID device for USB peripheral buttons/controllers o Updated NTFS o RAMfs with resource limits o NMI watchdog available on uniprocessor x86 o Update CMPCI drivers (not yet SMP safe) o Configurable max_map_count o Dynamic sysctl key registration o SE401 USB camera driver o Updated Zoran ZR3606x driver (replaces buz) o w9966 parallel port camera driver (partially merged with Linus) o Include headers in etags o Don't delete empty directories on make distclean o Fix halt/reboot handling on Alcor Alpha o IDE driver support for Etrax E100 o IDE infrastructure support for IDE using non standard data transfers o Run ~/bin/installkernel if present o Support for out of order stores on x86 with this mode (IDT Winchip) - worth 20% performance on them o Configure level debugging menu o Make BUG() default to an oops only - saves 70K o Power management help for UP-APIC o Work around 440BX APIC hang (eg the ne2000 SMP hang) o Run time configurable APM behaviour (interrupts, psr etc) o Smarter DMI parser - handles multiple use of names o DMI layer has blacklist tables fixing Dell Inspiron 5000e crashes, PowerEdge reboot problems , and IBM laptop APM problems o PNPBios support o Fix atomicity of IRQ error count o Handle PCI/ISA boxes that don't list edge levels but have an ELCR o Don't erroneously mangle settings on all VIA bridges - cures the horrible performance problem in 2.4.5 vanilla with VIA o Fix bootmem corruption on x86 boot o Scan and retrieve multipliers for processors (not yet used to handle the SMP cases where we
[patch][rfc]: highmem block support
Hi, Given the recent talk about highmem deadlocking x86 machines, I decided to backport my 2.5 stuff to be somewhat non-intrusive and apply to recent 2.4 kernel. It enables x86 machines to do I/O on highmem pages, typically this means up to 4GB. There are two parts: - zone-dma32-4. Add extra memory zone, to cover the range that PCI can DMA to safely. So when we are not eating pages from the reserved highmem pool, we can alloc a highmem page as bounce instead of always going to low memory. - block-highmem-1. The actual patch to enable block I/O to highmem. It will only work on x86 right now, the other architectures that have similar mapping restrictions need to define page_to_bus, the appropriate zone sizing at init time (look at the x86 changes), the KM_BH_IRQ kmap type, and the set_bh_sg bh -> scatterlist mapper. Maybe a bit more, I forget :-) Is it worth it? Yes! If you look at profiling numbers for even just a 1GB machine (which then has only 128MB of highmem), the bounce copying of pages has an even higher cost than the I/O scheduler queue scan. In fact, it scores 3rd for ticks for a single dbench run. This 2.4 version is designed to have _minimal_ impact on existing drivers, so if they don't explicitly enable highmem I/O it should work just like it did before. What works? IDE works in DMA (duh) and PIO maps highmem pages temporarily if it needs to. Note that highmem I/O is only enabled if DMA is enabled, and if DMA gets disabled we set normal highmem bounce behaviour again. So the PIO mappings only happen if a DMA enabled host falls back to PIO. The IDE low level drivers need to set hwif->highmem to enable the functionality, and even so it's just set for ATA disks. SCSI works too, there's a similar can_dma32 host flag that needs to be set. I just enabled it on aic7xxx (new) and sym53c8xx, you need to add the one-liner to other drivers if you want to test. This version is not tested as well as the stuff it's ported from, but at least that version passes hours of cerberus testing. So it should be stable and safe to try. Random comments: - SCSI always uses scatter/gather even for single segments, it makes it easier to verify it's right. If we run out of mem for the sg tables, we do revert to a non-sg single-segment request, and highmem pages are mapped. Performance is down the drain in this case anyway, so it should be ok. - The additions to scatterlist are a bit of a hack, however it's part of the 'keep the impact and changes small' solution. The current scatterlist is not of much use on highmem... Oh, and the highmem stuff should just be hidden for non-highmem compiles. That's it for now, get the two patches from: *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.5/ -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm in 2.4.5
On 05.26 Rik van Riel wrote: > On Sat, 26 May 2001, J . A . Magallon wrote: > > > It does not begin to use swap in a growing fashion, it just appears > > full in a moment. > > It gets _allocated_ in a moment, but things don't actually get > swapped out. This isn't a problem. > > The real problem is that we don't actively reclaim swap space > when it gets full. We just assign swap to parts of processes, > but we never reclaim it when we need swap space for something > else; at least, not until the process exit()s or exec()s. > > > And when all the gcc process ends, my mem ends up like: > > > total used free sharedbuffers cached > > Swap: 152576 152576 0 > > > > What process do belong the 150Mb of swap ??? > > Shouldn't that pages have been freed when gcc ends ? > > Linux reclaims swap cache (and swap space) when it encounters > them in its scan of memory. It doesn't take the trouble of > freeing the swap on exit() but the swap space will be freed > later. > That seems to be partially true, if I start just the same comilation when the first finishes, it behaves like preivous, in the moment the new gcc needs swap the old swap gets freed, but not the in-core cache, so if I choose carefully the number of 'puts' lines to stress my system just to the border, I can't do two times the same 'gcc tst.c'. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac15 #1 SMP Wed May 23 21:55:23 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 2.4.5 does not link on Ruffian (alpha)
Richard Henderson wrote: > On Sat, May 26, 2001 at 06:48:30PM -0400, Jeff Garzik wrote: > > When built with CONFIG_ALPHA_NAUTILUS, my UP1000's IDE totally fails. > > Mine doesn't. > > > I am booting w/ aboot 0.7a from SRM, -without- the > > srm-as-bootloader kernel config option. > > That is the error. Ok, thanks. FWIW the documentation seems to imply that the option is necessary only when directly booting from SRM, i.e.. no bootloader is involved at all. It uses the example of MILO's presence or absence as indicating the need for this option. So... is it safe to always enable this option, with a little hacking perhaps? :) Regards, Jeff > Using SRM as bootloader > CONFIG_ALPHA_SRM > There are two different types of booting firmware on Alphas: SRM, > which is command line driven, and ARC, which uses menus and arrow > keys. Details about the Linux/Alpha booting process are contained in > the Linux/Alpha FAQ, accessible on the WWW from > http://www.alphalinux.org . > > The usual way to load Linux on an Alpha machine is to use MILO > (a bootloader that lets you pass command line parameters to the > kernel just like lilo does for the x86 architecture) which can be > loaded either from ARC or can be installed directly as a permanent > firmware replacement from floppy (which requires changing a certain > jumper on the motherboard). If you want to do either of these, say N > here. If MILO doesn't work on your system (true for Jensen > motherboards), you can bypass it altogether and boot Linux directly > from an SRM console; say Y here in order to do that. Note that you > won't be able to boot from an IDE disk using SRM. > > If unsure, say N. -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 2.4.5 does not link on Ruffian (alpha)
On Sat, May 26, 2001 at 06:48:30PM -0400, Jeff Garzik wrote: > When built with CONFIG_ALPHA_NAUTILUS, my UP1000's IDE totally fails. Mine doesn't. > I am booting w/ aboot 0.7a from SRM, -without- the > srm-as-bootloader kernel config option. That is the error. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cross compile alpha make bootpfile fails
Cross compiling kernel (any recent version) on any non-64bit host (ie: x86) to ALPHA the "make bootpfile" step fails. The problem is localized to arch/alpha/boot/tools/objstrip.c Various 'elf' structure members are 64 bit, not 32bit and the wrong version of the structure is being choosen. (To bad you can't use the binutils library here!) I have hand coded around this, and can easily produce bootp files. I would like to submit patches but my change/hack is not real pretty. There are other issues associated with cross compiling this file, who is an appropriate person reguarding alpha specific items such as these? if you wish to disucuss this off-list, email duane_ellis _AT_ franklin.com -Duane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5 alpha rawhide interrupt fix
PALcode will ack the interrupt in the normal interrupt return path,
but 2.4 re-enables interrupts before that. This means we re-enable
interrupts without the hardware being acked, which results in nasty
interrupt storms.
Fixed thus.
r~
--- linux/arch/alpha/kernel/sys_rawhide.c.orig Sun May 27 15:51:03 2001
+++ linux/arch/alpha/kernel/sys_rawhide.c Sun May 27 15:57:42 2001
@@ -59,10 +59,11 @@ rawhide_enable_irq(unsigned int irq)
irq -= 16;
hose = irq / 24;
irq -= hose * 24;
+ mask = 1 << irq;
spin_lock(_irq_lock);
- mask = cached_irq_masks[hose] |= 1 << irq;
- mask |= hose_irq_masks[hose];
+ mask |= cached_irq_masks[hose];
+ cached_irq_masks[hose] = mask;
rawhide_update_irq_hw(hose, mask);
spin_unlock(_irq_lock);
}
@@ -75,14 +76,37 @@ rawhide_disable_irq(unsigned int irq)
irq -= 16;
hose = irq / 24;
irq -= hose * 24;
+ mask = ~(1 << irq) | hose_irq_masks[hose];
spin_lock(_irq_lock);
- mask = cached_irq_masks[hose] &= ~(1 << irq);
- mask |= hose_irq_masks[hose];
+ mask &= cached_irq_masks[hose];
+ cached_irq_masks[hose] = mask;
rawhide_update_irq_hw(hose, mask);
spin_unlock(_irq_lock);
}
+static void
+rawhide_mask_and_ack_irq(unsigned int irq)
+{
+ unsigned int mask, mask1, hose;
+
+ irq -= 16;
+ hose = irq / 24;
+ irq -= hose * 24;
+ mask1 = 1 << irq;
+ mask = ~mask1 | hose_irq_masks[hose];
+
+ spin_lock(_irq_lock);
+
+ mask &= cached_irq_masks[hose];
+ cached_irq_masks[hose] = mask;
+ rawhide_update_irq_hw(hose, mask);
+
+ /* Clear the interrupt. */
+ *(vuip)MCPCIA_INT_REQ(MCPCIA_HOSE2MID(hose)) = mask1;
+
+ spin_unlock(_irq_lock);
+}
static unsigned int
rawhide_startup_irq(unsigned int irq)
@@ -104,7 +128,7 @@ static struct hw_interrupt_type rawhide_
shutdown: rawhide_disable_irq,
enable: rawhide_enable_irq,
disable:rawhide_disable_irq,
- ack:rawhide_disable_irq,
+ ack:rawhide_mask_and_ack_irq,
end:rawhide_end_irq,
};
@@ -145,8 +169,12 @@ rawhide_init_irq(void)
mcpcia_init_hoses();
for (hose = hose_head; hose; hose = hose->next) {
- int h = hose->index;
- rawhide_update_irq_hw(h, hose_irq_masks[h]);
+ unsigned int h = hose->index;
+ unsigned int mask = hose_irq_masks[h];
+
+ cached_irq_masks[h] = mask;
+ *(vuip)MCPCIA_INT_MASK0(MCPCIA_HOSE2MID(h)) = mask;
+ *(vuip)MCPCIA_INT_MASK1(MCPCIA_HOSE2MID(h)) = 0;
}
for (i = 16; i < 128; ++i) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matrox G400 Dualhead
I have a serious problem when usind the second head of my Matrox with the matroxfb driver.If I login to /dev/tty0 (fb0) and then to /dev/tty6(fb1) and make fb1 to scroll,if I switch back to /dev/tty0 and make fb0 to scroll while fb1 is still scrolling I get a segmentation fault.Also sometimes I get a message like this: INIT:Id "1" respawning too fast disabled for 5 minutes. Can anyone help me ? Mythos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-ntfs] Re: [Linux-NTFS-Dev] Re: ANN: NTFS new release available (1.1.15)
At 13:53 27/05/2001, Martin von Loewis wrote: > > Yes and no. They will be uncompressed but not when opening the inode. It > > will be "uncompress required extent's run list on demand". > >Are you sure this can work? No. >Initially, I thought I could use the attribute list to only uncompress the >extend that has the VCN I'm interested in. Same idea here. >That would not work: NT would split individual runs across extends >(i.e. split them in the middle). Argh! That seems really stupid thing to do, as it makes it difficult to interpret what the highest_vcn/lowest_vcn field of attribute extents is supposed to mean!?! This does however explain some of the code uglyness I have seen (and chosen to ignore) in the ntfs.sys disassembly run list handling... >Did I misunderstand, or do you have a solution for that as well. No solution. I wasn't aware this could happen. I knew a compression block could be split in it halves but I didn't realize this braindamaged complication. I guess we will have to decode the whole run list in one go then. Anything else would be slower over all. - What we could do of course is to walk the mapping pairs array real quick not reading the numbers only to get the correct starting offset into the next extent and then only decode that one but that would mean walking the mapping pairs array repeatedly (once to get each extent) which would be overall slower than just getting the lot at once. - I maintain that we should do this on demand and not on inode open, though. - I will have another think about this, but if it is true that NT splits the records anywhere, then it would be impossible to start at any extent other than the first one. Anton -- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hard lockup switching to X from vc; Matrox G400 AGP
Hi Chris, Seen the same behaviour; you're not alone. I'm running XF86 4.0.3 with a G400. My guess is that mga_drv goes into some local loop while trying to restore the display. mga_drv at that moment has I/O privileges and if it hangs, Linux hangs too. Grtz, Ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG?: 2.4.5 breaks reiserfs (kernel BUG)
On Sun, 27 May 2001, Bjerkeset, Svein Olav wrote:
> Hi,
>
> Today I downloaded kernel 2.4.5 and compiled it. The kernel worked fine
> until
> I tried to halt the computer. When trying to unmount the reiserfs
> filesystems,
> the system freezes with the following output:
>
> journal_begin called without kernel lock held
> kernel BUG at journal.c:423!
Yes. My fault - badly merged patch in -pre6, actually.
Details:
* kill_super() gets called without BKL, but doesn't grab BKL around
the calls of ->write_super() and ->put_super()
* by the time when it calls these methods filesystem is quiet. I.e.
nothing else has a chance to touch its data structures. So actually only
reiserfs (which checks that we hold BKL) had noticed.
* It _is_ a bug - changing locking rules is for 2.5.
Fix:
--- fs/super.c Fri May 25 21:51:14 2001
+++ fs/super.c Sun May 27 00:21:53 2001
@@ -873,6 +873,7 @@
}
spin_unlock(_lock);
down_write(>s_umount);
+ lock_kernel();
sb->s_root = NULL;
/* Need to clean after the sucker */
if (fs->fs_flags & FS_LITTER)
@@ -901,6 +902,7 @@
put_filesystem(fs);
sb->s_type = NULL;
unlock_super(sb);
+ unlock_kernel();
up_write(>s_umount);
if (bdev) {
blkdev_put(bdev, BDEV_FS);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
>--- include/asm-arm/atomic.h.old Sun May 27 22:30:58 2001 >+++ include/asm-arm/atomic.h Sun May 27 22:58:20 2001 >@@ -12,6 +12,7 @@ > * 13-04-1997 RMK Made functions atomic! > * 07-12-1997 RMK Upgraded for v2.1. > * 26-08-1998 PJB Added #ifdef __KERNEL__ >+ * 27-05-2001 APB Removed #ifdef __KERNEL__ > */ > #ifndef __ASM_ARM_ATOMIC_H > #define __ASM_ARM_ATOMIC_H >@@ -30,7 +31,6 @@ This is no good. The ARM kernel just doesn't provide any atomic primitives that will work in user space. If you want atomicity you have to use libpthread. p. PGP signature
Re: IDE Performance lack !
In article <00c701c0e6d8$2b28ea40$4aa6b3d0@Toshiba>, Jaswinder Singh <[EMAIL PROTECTED]> wrote: >I am not able to understand why Linux read and/or write harddisk after some >time (after few hours ) , harddisk read/write leds keep on glowing for few >minutes , even though nobody working on it and machine is in idle state. Are you sure it is idle. It might be running something from cron- say 'updatedb' or similar. That will cause a lot of disk i/o, and _ofcourse_ performance will be bad then - the machine is doing a lot of other things. It might also be that you don't have enough memory and the machine is swapping itself to death. Running netscape or mozilla perhaps? These are known to blow themselves up to 50-100 MB (!). That will cause the exact symptoms you're seeing. >>Have you tried 2.2.x ? >> > >yes i am taking about 2.2.12 . 2.2.12 is old. In my experience, 2.2.19 is the first really good 2.2 kernel. Especially in low-memory situations like you might be experiencing.. >And in my 2.4.2 :- 2.4.2 isn't all that good either.. 2.4.x doesn't have VM sorted out just yet >and when my machine becomes normal i got :- >9.07 MB/sec Sounds about right for a non-UDMA disk. >But my problem is why linux boxes do not response for few seconds >(sometimes) and especially during telnet/ssh it looks more worst and looks >similar to Microsoft Windows :( >there is problem in scheduling or what ? Try 2.2.19 Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with ac12 kernels and up
> I looked at the root_mountflags usage and it looks ok, so I put it in > the "figure out later" pile. > > Haven't yet verified if this 'ac' only problem Think I have it sussed. Time for -ac2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hard lockup switching to X from vc; Matrox G400 AGP
> out the Matrox-supplied mga_drv.o and mga_hal_drv.o modules and > replace them with the ones from the standard X 4.03 distribution, but > these are userspace objects and shouldn't be capable of bringing the > kernel down. (Like I said, the machine can't even be pinged.) Not really. The matrox code and X server run priviledged and bang on hardware directly. Its quite easily an X11 bug. Nice to know the free software one works better than the vendors 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Overkeen CDROM disk-change messages
> What's "magicdev"? I am not running GNOME or KDE. In fact, I wasn't > even running X at the time but had xmcd putting its display on another > machine over the local network. Then I guess it was xmcd continually opening/failing - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with ac12 kernels and up
Alan Cox wrote: > > > Checking root filesystem. /dev/hde13 is mounted. > > Cannot continue, aboorting. > > *** An error occurred during the file system check. > > *** Dropping you to a shell; the system will reboot > > *** when you leave the shell. > > That means the file system was mounted read/write at boot time. That normally > indicates a lilo misconfiguration however your lilo.conf looks > correct. On 'ac' kernels at MDK, only when initrd is used, we are seeing the root filesystem mounted read-write, no matter what rdev and bootloader settings are... Things are fine with no initrd. I looked at the root_mountflags usage and it looks ok, so I put it in the "figure out later" pile. Haven't yet verified if this 'ac' only problem -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hard lockup switching to X from vc; Matrox G400 AGP
REF: Linux 2.4.5, 2.4.4, 2.4.3 (and probably earlier); devfs; SMP (dual PIII); < 1GB main memory Hi, Has anyone noticed their Linux box lock up hard (as in cannot even be pinged from the local network) when switching from a text vc to a vc running X? This has happened for me even without the mga.o and agpgart.o modules being loaded. My current workaround has been to swap out the Matrox-supplied mga_drv.o and mga_hal_drv.o modules and replace them with the ones from the standard X 4.03 distribution, but these are userspace objects and shouldn't be capable of bringing the kernel down. (Like I said, the machine can't even be pinged.) My best guess is that the mga_hal_drv.o object is ticking an obscure kernel bug. I am raising this with the Matrox support line as well. Cheers, Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sun, May 27, 2001 at 10:45:17PM +0200, Daniel Phillips wrote:
> On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > > I'm not claiming there isn't breakage somewhere,
> >
> > you break UNIX fundamentals. But I'm quite relieved now because I'm
> > pretty sure that something like that will never go into the kernel.
>
> OK, I'll take that as "I couldn't find a piece of code that breaks, so
> it's on to the legal issues".
>
> SUS doesn't seem to have a lot to say about this. The nearest thing to
> a ruling I found was "The special filename dot refers to the directory
> specified by its predecessor". Which is not the same thing as:
>
>open("foo", O_RDONLY) == open ("foo/.", O_RDONLY)
>
> I don't know about POSIX (I don't have it: a pox on standards
> organizations that don't make their standards freely available) but SUS
> doesn't seem to forbid this.
My question is: Is it needed? You are advocating quite
non-obvious behaviour on a UNIX-like fs. Cant the end result
achieved in more obvious manner?
I see at most 3 types of magic files:
1) regular file - nothing special. Whether it has CHR/BLK set
or not is irrelevant.
2) file with subdevs. As 1) but you can acces dev/something
for subdev 'something'. Permissions should be probably taken
from 'dev'. Ofcourse you cant do 'ls' on the thing.
3) magicdev as directory. Act as ordinary directory. Only
reason is to group devices.
And all those should be manageable by devfsd, so you can tell
devfsd to take subdev and create it as file somewhere else.
So 2) and 3) are more like 'defaults'.
So: is there additional type required with non-obvious file/dir
behaviour mix?
--
marko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
On Sun, May 27, 2001 at 11:07:38PM +0200, Adrian Bunk wrote: > I do also explicitely send this mail to the people that seem to be > responsible for the pieces of code I touch. > > I'm not sure whether the compete removal of the "#ifdef __KERNEL__"'s is > too rude but there are already other architectures that don't have it in > their architecture specific versions of these files. You cannot use the kernel atomic/interrupt functions from userspace on ARM. You cannot disable interrupts in userspace, and therefore the kernel atomic functions do not work as you expect them to. If it is to do with code to be included into the kernel, then why aren't you defining __KERNEL__ ? Therefore this change (as far as ARM goes) makes zero sense. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac1 won't boot with 4GB bigmem option
> > mm: critical shortage of bounce buffers. > > Indeed this message has been pestering me in all the recent .4-acx kernels when > the machine is under heavy FS pressure. > > In these kernels I observe a significative (5-10%) performance degradation as > soon as the FS cache fills up all the available memory, at this moment "kswapd" Its there to prove we had a problem > 2.4.2-acx and early 2.4.3-acx kernles were much better in this respect and a lot > more stable. Hit any 2.4 kernel pre 2.4.5 vanilla [maybe fixed] and you will break bigmem that way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac1 won't boot with 4GB bigmem option
> I compiled and booted the 2.4.5-ac1 kernel with the CONFIG_HIGHMEM4G=y option > and got an oops in __alloc_pages() (called by alloc_bounce() called by > schedule()). Everything works fine if I turn the 4GB mode off. > Machine is a Dell Precision with 2 Xeons and 2GB of RAM. > > 2.4.5 works fine with the 4GB. Any idea what changed between the two? The -ac tree has some VM differences for bigmem that really need to be cleaned up and/or removed now the Linus tree is looking solid. I'll probably drop those diffs for -ac2 so that folks are working against one set of VM - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] softirq-2.4.5-B0
On 27 May 2001, Andi Kleen wrote: > I think the right way to fix it is to do a final atomic check for > softirqs when the kernel is exited. To be atomic this check neededs to > be done with interrupts off until the kernel exited. [...] check out my first softirq patch, it does exactly this. (but has the wrong explanation.) > [...] The same atomic check is needed for race free check of > need_schedule (which is still racy on plain i386). right, this need_resched race is fixed in the lowlatency patchset. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 does not link on Ruffian (alpha)
From: "Andrea Arcangeli" <[EMAIL PROTECTED]> > On Sun, May 27, 2001 at 06:41:23PM +0200, Andrea Arcangeli wrote: > > On Sun, May 27, 2001 at 04:49:24AM +0200, Andrea Arcangeli wrote: > > > caused me to write the posted patch to get all compilations right. > > > > The reason I needed that patch is that I was not using 2.4.5aa1 but a > > corrupted tree (I'm been fooled by an hardlink during developement), it > > was just two lines away from the real one. > > > > So this is the fix for all 2.4.5 based trees (ac1 and aa1 included) to > > get generic and dp264 compililations right: > > woops, the dp264 compilation wasn't right yet, this additional patch is > needed too. > 2.4.5aa1 broke on my ruffian, now it works beautifully, now i just gotta check if it boots :) Magnus Naeslund -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Programmer/Networker [|] Magnus Naeslund PGP Key: http://www.genline.nu/mag_pgp.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] softirq-2.4.5-B0
"David S. Miller" <[EMAIL PROTECTED]> writes: > > the attached softirq-2.4.5-B0 patch fixes this problem by calling > > do_softirq() from local_bh_enable() [if the bh count is 0, to avoid > > recursion]. > > Yikes! I do not like this fix. > > I'd rather local_bh_enable() not become a more heavy primitive. > > I know, in one respect it makes sense because it parallels how > hardware interrupts work, but not this thing is a function call > instead of a counter bump :-( > > Any other ideas how to zap this? I think the right way to fix it is to do a final atomic check for softirqs when the kernel is exited. To be atomic this check neededs to be done with interrupts off until the kernel exited. I just implemented a very similar way into the x86-64 kernel (which needs to turn off interrupts for kernel anyways for other reasons, this just extends the cli area a bit). The same atomic check is needed for race free check of need_schedule (which is still racy on plain i386). -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
initrd oops [was Re: Linux 2.4.5-ac1]
On Sun, May 27, 2001 at 07:26:50PM +0300, you [Ville Herva] claimed:
> On Sat, May 26, 2001 at 10:58:25PM +0100, you [Alan Cox] claimed:
> >
> > o Free the initial ramdisk correctly
>
> Who made this fix, or who can I contact?
>
> I have a reproducible oops on 2.4.4ac17 (see
> http://marc.theaimsgroup.com/?l=linux-kernel=99079948404775=2 for
> details) that seems to be related:
Ok, some more info:
2.4.2-2 (redhat) BOOTS OK
2.4.4ac17 OOPS
2.4.4ac17+av OOPS
2.4.5 OOPS
2.4.5ca1+avOOPS
2.4.4 BOOTS OK
2.4.4ac9 BOOTS OK
2.4.4ac10 BOOTS OK
2.4.4ac11 BOOTS OK
2.4.4ac12 fails to mount root ("Checking root filesystem.
/dev/sdb is mounted.")
2.4.4ac14 fails to mount root
2.4.4ac15 OOPS
This is:
600Mhz Xeon
256MB
megaraid RAID and sym53c875 (from which I boot)
gcc-2.96-85 (tried .91 as well)
So I gather the ac12 and ac15 Linux tree / av merges are the culprit?
-- v --
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
On Sun, 27 May 2001, Abramo Bagnara wrote:
> Adrian Bunk wrote:
> >
> > while looking for the reason of a build failure of the ALSA libraries on
> > ARM [1] I discovered the following strange thing:
> >
> > On some architectures a function is inside an "#ifdef __KERNEL__" in the
> > header file and on others not. Is there a reason for this or is this
> > inconsistency simply a bug?
>
> This is a bug on some architectures, I've personally fixed this on PPC
> sending a patch to Cort Dougan. It has been included in 2.4.5.
>
> I'd like you send a patch to maintainers (or perhaps to Alan).
I do also explicitely send this mail to the people that seem to be
responsible for the pieces of code I touch.
I'm not sure whether the compete removal of the "#ifdef __KERNEL__"'s is
too rude but there are already other architectures that don't have it in
their architecture specific versions of these files.
A patch for the problems I mentioned (except for parisc) would be:
--- include/asm-arm/atomic.h.oldSun May 27 22:30:58 2001
+++ include/asm-arm/atomic.hSun May 27 22:58:20 2001
@@ -12,6 +12,7 @@
* 13-04-1997RMK Made functions atomic!
* 07-12-1997RMK Upgraded for v2.1.
* 26-08-1998PJB Added #ifdef __KERNEL__
+ * 27-05-2001APB Removed #ifdef __KERNEL__
*/
#ifndef __ASM_ARM_ATOMIC_H
#define __ASM_ARM_ATOMIC_H
@@ -30,7 +31,6 @@
#define ATOMIC_INIT(i) { (i) }
-#ifdef __KERNEL__
#include
#define atomic_read(v) ((v)->counter)
@@ -107,5 +107,4 @@
__restore_flags(flags);
}
-#endif
#endif
--- include/asm-arm/system.h.oldSun May 27 22:31:47 2001
+++ include/asm-arm/system.hSun May 27 22:31:56 2001
@@ -1,8 +1,6 @@
#ifndef __ASM_ARM_SYSTEM_H
#define __ASM_ARM_SYSTEM_H
-#ifdef __KERNEL__
-
#include
#include
@@ -84,7 +82,5 @@
#define save_flags_cli(x) __save_flags_cli(x)
#endif /* CONFIG_SMP */
-
-#endif /* __KERNEL__ */
#endif
--- include/asm-sparc/atomic.h.old Sun May 27 22:32:29 2001
+++ include/asm-sparc/atomic.h Sun May 27 22:32:48 2001
@@ -11,7 +11,6 @@
typedef struct { volatile int counter; } atomic_t;
-#ifdef __KERNEL__
#ifndef CONFIG_SMP
#define ATOMIC_INIT(i) { (i) }
@@ -99,7 +98,5 @@
#define atomic_dec(v) ((void)__atomic_sub(1, (v)))
#define atomic_add_negative(i, v) (__atomic_add((i), (v)) < 0)
-
-#endif /* !(__KERNEL__) */
#endif /* !(__ARCH_SPARC_ATOMIC__) */
--- include/asm-sparc/system.h.old Sun May 27 22:32:50 2001
+++ include/asm-sparc/system.h Sun May 27 22:33:52 2001
@@ -33,8 +33,6 @@
ap1000 = 0x07, /* almost a sun4m */
};
-/* Really, userland should not be looking at any of this... */
-#ifdef __KERNEL__
extern enum sparc_cpu sparc_cpu_model;
@@ -335,8 +333,6 @@
}
extern void die_if_kernel(char *str, struct pt_regs *regs) __attribute__ ((noreturn));
-
-#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
--- include/asm-mips/atomic.h.old Sun May 27 22:38:35 2001
+++ include/asm-mips/atomic.h Sun May 27 22:38:48 2001
@@ -24,7 +24,6 @@
typedef struct { int counter; } atomic_t;
#endif
-#ifdef __KERNEL__
#define ATOMIC_INIT(i){ (i) }
#define atomic_read(v) ((v)->counter)
@@ -199,6 +198,5 @@
#define atomic_inc(v) atomic_add(1,(v))
#define atomic_dec(v) atomic_sub(1,(v))
-#endif /* defined(__KERNEL__) */
#endif /* __ASM_MIPS_ATOMIC_H */
--- include/asm-mips64/atomic.h.old Sun May 27 22:38:53 2001
+++ include/asm-mips64/atomic.h Sun May 27 22:39:02 2001
@@ -18,7 +18,6 @@
typedef struct { volatile int counter; } atomic_t;
-#ifdef __KERNEL__
#define ATOMIC_INIT(i){ (i) }
#define atomic_read(v) ((v)->counter)
@@ -99,6 +98,5 @@
#define atomic_inc(v) atomic_add(1,(v))
#define atomic_dec(v) atomic_sub(1,(v))
-#endif /* defined(__KERNEL__) */
#endif /* _ASM_ATOMIC_H */
cu
Adrian
--
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] severe softirq handling performance bug, fix, 2.4.5
On Sun, 27 May 2001, Andrea Arcangeli wrote: > Yes the stock kernel. yep you are right. i had this fixed too at a certain point, there is one subtle issue: under certain circumstances tasklets re-activate the tasklet softirq(s) from within the softirq handler, which leads to infinite loops if we just naively restart softirq handling. This fix is not in the -B0 patch yet. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac1 won't boot with 4GB bigmem option
Same here, I have a dual 1GHz PIII with 4G, I don't get an oops but an infinite loop of: > mm: critical shortage of bounce buffers. Indeed this message has been pestering me in all the recent .4-acx kernels when the machine is under heavy FS pressure. In these kernels I observe a significative (5-10%) performance degradation as soon as the FS cache fills up all the available memory, at this moment "kswapd" starts to take lots of CPU time (10-20%) and I keep getting plenty of the above messages. I'm running SpecWeb with the X15 webserver, which uses sendfile to send its content, and a very large file set (8-9G, more than twice as much as the physical RAM). 2.4.2-acx and early 2.4.3-acx kernles were much better in this respect and a lot more stable. - Fabio Ben Twijnstra wrote: > Hi, > > I compiled and booted the 2.4.5-ac1 kernel with the CONFIG_HIGHMEM4G=y option > and got an oops in __alloc_pages() (called by alloc_bounce() called by > schedule()). Everything works fine if I turn the 4GB mode off. > > Machine is a Dell Precision with 2 Xeons and 2GB of RAM. > > 2.4.5 works fine with the 4GB. Any idea what changed between the two? > > Grtz, > > Ben > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > It won't, the open for "." is handled in the VFS, not the
> > filesystem - it will open the directory. (Without needing to be
> > told it's a directory via O_DIRECTORY.) If you do open("magicdev")
> > you'll get the device, because that's handled by magicdevfs.
>
> You really mean that "magicdev" is a directory and:
>
> open("magicdev/.", O_RDONLY);
> open("magicdev", O_RDONLY);
>
> would both succeed but open different objects?
Yes, and:
open("magicdev/.", O_RDONLY | O_DIRECTORY);
open("magicdev", O_RDONLY | O_DIRECTORY);
will both succeed and open the same object.
> > I'm not claiming there isn't breakage somewhere,
>
> you break UNIX fundamentals. But I'm quite relieved now because I'm
> pretty sure that something like that will never go into the kernel.
OK, I'll take that as "I couldn't find a piece of code that breaks, so
it's on to the legal issues".
SUS doesn't seem to have a lot to say about this. The nearest thing to
a ruling I found was "The special filename dot refers to the directory
specified by its predecessor". Which is not the same thing as:
open("foo", O_RDONLY) == open ("foo/.", O_RDONLY)
I don't know about POSIX (I don't have it: a pox on standards
organizations that don't make their standards freely available) but SUS
doesn't seem to forbid this.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] add restore_flags to error path in irttp.c (245ac1)
Hi.
The following patch makes irttp_read_proc restore_flags()
in error cases too. Applies against 245ac1.
--- linux-245-ac1-clean/net/irda/irttp.cSun May 27 22:15:34 2001
+++ linux-245-ac1/net/irda/irttp.c Sun May 27 22:37:59 2001
@@ -1598,7 +1598,7 @@
self = (struct tsap_cb *) hashbin_get_first(irttp->tsaps);
while (self != NULL) {
if (!self || self->magic != TTP_TSAP_MAGIC)
- return len;
+ break;
len += sprintf(buf+len, "TSAP %d, ", i++);
len += sprintf(buf+len, "stsap_sel: %02x, ",
--
Regards,
Rasmus([EMAIL PROTECTED])
Which is worse: Ignorance or Apathy?
Who knows? Who cares?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] severe softirq handling performance bug, fix, 2.4.5
On Sun, May 27, 2001 at 12:09:29PM -0700, David S. Miller wrote: > "live lock". What do you hope to avoid by pushing softirq processing > into a scheduled task? I think doing that is a stupid idea. NOTE: I'm not pushing anything out of the atomic context, I'm using ksoftirqd only to cure the cases that are getting wrong by the fast-path code. It fixes the 1/HZ latency with the idle task and it gets right the case of softirq marked pending again under do_softirq. > You are saying that if we are getting a lot of soft irqs we should > defer it so that we can leave the trap handler, to avoid "live lock". Yes, that is what all kernels out there are doing. > I think this is a bogus scheme for several reasons. First of all, > deferring the processing will only increase the likelyhood that the > locality of the data will be lost, making the system work harder. Of course almost all the time the processing is not deferred. > Secondly, if we are getting softirqs at such a rate, we have other > problems. We are likely getting surged with hardware interrupts, and > until we have Jamals stuff in to move ethernet hardware interrupt > handling into softirqs your deferrals will be fruitless when they do > actually trigger. We will be livelocked in hardware interrupt > processing instead of being livelocked in softirq processing, what an > incredible improvement. :-) The sofitrq could be marked running also from another softirq, it doesn't need to be an interrupt. > from trap, no matter what kind, call do_softirq if softirqs are > pending. that just happens, I assume you mean you prefer to remove mask &= ~active from do_softirq() internally. But doing that will hang in irq as soon as a softirq or tasklet or that marks itself running again in software (and I think this happens just now in some driver to poll the hardware from atomic context where you cannot schedule). Furthmore the softirq is going to take more time than the irq core itself, so the live lock issue is not so obvious as you say I think. > Again, I am totally against ksoftirqd, I think it's a completely dumb > idea. Softirqs were meant to be as light weight as possible, don't > crap on them like this with this heavyweight live lock "solution". > It isn't even solving live locks, it's rather trading one kind for > another with zero improvement. softirq is still as light as possible but without ksoftirq the logic is wrong in some case, and so it can get a seneless 1/HZ latency sometime. ksofitrqd fixes all those broken cases in a clean manner. I'd like to know how much it helps on the gigabit benchmarks. For the 100mbit ethernet that I can test locally it is fine. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Overkeen CDROM disk-change messages
Maybe thats related to the problems with my CDROM drives (SCSI or IDE SCSI emulation). I cannot mount any CD with 2.4.5. kern.log says: May 26 15:31:17 bilbo kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0 May 26 15:31:17 bilbo kernel: Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0 May 26 15:31:17 bilbo kernel: Detected scsi CD-ROM sr2 at scsi2, channel 0, id 0, lun 0 May 26 15:31:17 bilbo kernel: sr0: scsi3-mmc drive: 0x/0x cd/rw xa/form2 cdda tray May 26 15:31:17 bilbo kernel: Uniform CD-ROM driver Revision: 3.12 May 26 15:31:17 bilbo kernel: sr1: scsi3-mmc drive: 32x/32x cd/rw xa/form2 cdda tray May 26 15:31:17 bilbo kernel: sr2: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray May 26 15:31:17 bilbo kernel: VFS: Disk change detected on device sr(11,1) May 26 15:31:17 bilbo last message repeated 3 times May 26 15:31:17 bilbo kernel: Device 0b:01 not ready. May 26 15:31:17 bilbo kernel: I/O error: dev 0b:01, sector 1024 Of course I did _not_ change the CD 4 times within 1 second. Regards Harri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] softirq-2.4.5-A1
On Sun, May 27, 2001 at 09:08:51PM +0200, Ingo Molnar wrote: > i took at look at your ksoftirq stuff yesterday, and i think it's > completely unnecessery and adds serious overhead to softirq handling. The > whole point of softirqs is to have maximum scalability and no > serialization. Why did you add ksoftirqd, would you mind explaining it? The only case ksoftirqd runs is when the stock kernel does the wrong thing and potentially delays the softirq of 1/HZ. Nothing else. When current kernel does the right thing ksoftirq cannot generate any scalability problem and furthmore ksoftirqd is a per-cpu thing so if you face a scalability problem with it that simply means you need to fix the scheduler because then it means you would face a scalability issue as well every time a tux thread calls schedule(). 90% of the time ksoftirqd will never run, when it runs it means you want to pay for a scheduler run to get it running. The price of the scheduler is just the price for the logic that balance the softirq load in a fair manner and without buggy latencies. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac1 won't boot with 4GB bigmem option
Hi, I compiled and booted the 2.4.5-ac1 kernel with the CONFIG_HIGHMEM4G=y option and got an oops in __alloc_pages() (called by alloc_bounce() called by schedule()). Everything works fine if I turn the 4GB mode off. Machine is a Dell Precision with 2 Xeons and 2GB of RAM. 2.4.5 works fine with the 4GB. Any idea what changed between the two? Grtz, Ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix interrupt flag bug(s) in irtty.c (244-ac18)
Hi.
The following patch fixes an interrupt flag bug in irtty.c
as per the stanford team's report way back. Applies against
224-ac18.
--- linux-244-ac18-clean/drivers/net/irda/irtty.c Sat May 19 20:59:17 2001
+++ linux-244-ac18/drivers/net/irda/irtty.c Sun May 27 21:56:14 2001
@@ -971,13 +971,17 @@
switch (cmd) {
case SIOCSBANDWIDTH: /* Set bandwidth */
if (!capable(CAP_NET_ADMIN))
- return -EPERM;
- irda_task_execute(self, irtty_change_speed, NULL, NULL,
- (void *) irq->ifr_baudrate);
+ ret = -EPERM;
+ else
+ irda_task_execute(self, irtty_change_speed, NULL, NULL,
+ (void *) irq->ifr_baudrate);
break;
case SIOCSDONGLE: /* Set dongle */
- if (!capable(CAP_NET_ADMIN))
- return -EPERM;
+ if (!capable(CAP_NET_ADMIN)) {
+ ret = -EPERM;
+ break;
+ }
+
/* Initialize dongle */
dongle = irda_device_dongle_init(dev, irq->ifr_dongle);
if (!dongle)
@@ -999,21 +1003,24 @@
break;
case SIOCSMEDIABUSY: /* Set media busy */
if (!capable(CAP_NET_ADMIN))
- return -EPERM;
- irda_device_set_media_busy(self->netdev, TRUE);
+ ret = -EPERM;
+ else
+ irda_device_set_media_busy(self->netdev, TRUE);
break;
case SIOCGRECEIVING: /* Check if we are receiving right now */
irq->ifr_receiving = irtty_is_receiving(self);
break;
case SIOCSDTRRTS:
if (!capable(CAP_NET_ADMIN))
- return -EPERM;
- irtty_set_dtr_rts(dev, irq->ifr_dtr, irq->ifr_rts);
+ ret = -EPERM;
+ else
+ irtty_set_dtr_rts(dev, irq->ifr_dtr, irq->ifr_rts);
break;
case SIOCSMODE:
if (!capable(CAP_NET_ADMIN))
- return -EPERM;
- irtty_set_mode(dev, irq->ifr_mode);
+ ret = -EPERM;
+ else
+ irtty_set_mode(dev, irq->ifr_mode);
break;
default:
ret = -EOPNOTSUPP;
--
Regards,
Rasmus([EMAIL PROTECTED])
Things are more like they are now than they ever were before.
-Former U.S. President Dwight D. Eisenhower
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] severe softirq handling performance bug, fix, 2.4.5
On Sun, May 27, 2001 at 09:05:50PM +0200, Ingo Molnar wrote: > > On Sun, 27 May 2001, Andrea Arcangeli wrote: > > > I mean everything is fine until the same softirq is marked active > > again under do_softirq, in such case neither the do_softirq in do_IRQ > > will run it (because we are in the critical section and we hold the ^^ > > per-cpu locks), nor we will run it again ourself from the underlying ^ > > do_softirq to avoid live locking into do_softirq. > > if you mean the stock kernel, this scenario you describe is not how it Yes the stock kernel. > behaves, because only IRQ contexts can mark a softirq active again. And > those IRQ contexts will run do_IRQ() naturally, so while *this* > do_softirq() invocation wont run those reactivated softirqs, the IRQ > context that just triggered the softirq will do so. it won't because the underlying do_softirq did local_bh_disable() and the in_interrupt() check will cause the do_softirq from do_IRQ to return immediatly. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add missing restore_flags to sm_wss.c (244-ac18)
Hi.
The following patch adds a missing restore_flags as per the
stanford team's report way back. Applies against 244ac18.
--- linux-244-ac18-clean/drivers/net/hamradio/soundmodem/sm_wss.c Wed Jul 19
01:55:19 2000
+++ linux-244-ac18/drivers/net/hamradio/soundmodem/sm_wss.c Sun May 27 21:36:25
+2001
@@ -172,8 +172,10 @@
/* MCE and interface config reg */
write_codec(dev, 0x49, fdx ? 0x8 : 0xc);
outb(0xb, WSS_CODEC_IA(dev->base_addr)); /* leave MCE */
- if (SCSTATE->crystal && !fullcalib)
+ if (SCSTATE->crystal && !fullcalib) {
+ restore_flags(flags);
return 0;
+ }
/*
* wait for ACI start
*/
--
Regards,
Rasmus([EMAIL PROTECTED])
I've overclocked my keyboard interface. It's quite messy dipping my
hands into the mineral oil, but *MAN* is my keyboard ever fast now!
- Anonymous Coward
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Overkeen CDROM disk-change messages
Hi, It looks like my CDROM driver had a busy night last night ... ;-). This was with Linux 2.4.5, dual Pentium III, devfs, < 1GB memory. There was no CDROM in the drive, but I had kept the CD player running anyway. Cheers, Chris May 27 02:10:03 twopit kernel: hdc: ATAPI 32X CD-ROM CD-R/RW drive, 4096kB Cache, UDMA(33) May 27 02:10:03 twopit kernel: Uniform CD-ROM driver Revision: 3.12 May 27 02:10:03 twopit kernel: VFS: Disk change detected on device ide1(22,0) May 27 02:10:35 twopit last message repeated 8 times May 27 02:11:35 twopit last message repeated 15 times May 27 02:12:35 twopit last message repeated 15 times May 27 02:13:35 twopit last message repeated 15 times May 27 02:14:35 twopit last message repeated 15 times May 27 02:15:35 twopit last message repeated 15 times May 27 02:16:35 twopit last message repeated 15 times May 27 02:17:36 twopit last message repeated 15 times May 27 02:18:32 twopit last message repeated 14 times May 27 02:19:32 twopit last message repeated 15 times May 27 02:20:32 twopit last message repeated 15 times May 27 02:21:32 twopit last message repeated 15 times May 27 02:22:32 twopit last message repeated 15 times May 27 02:23:32 twopit last message repeated 15 times May 27 02:24:33 twopit last message repeated 15 times May 27 02:25:33 twopit last message repeated 15 times May 27 02:26:33 twopit last message repeated 15 times May 27 02:27:33 twopit last message repeated 15 times May 27 02:28:33 twopit last message repeated 15 times May 27 02:29:33 twopit last message repeated 15 times May 27 02:30:34 twopit last message repeated 15 times May 27 02:31:34 twopit last message repeated 15 times May 27 02:32:34 twopit last message repeated 15 times May 27 02:33:34 twopit last message repeated 15 times ... [snip] ... May 27 12:23:32 twopit last message repeated 15 times May 27 12:24:33 twopit last message repeated 15 times May 27 12:25:33 twopit last message repeated 15 times May 27 12:26:33 twopit last message repeated 15 times May 27 12:27:33 twopit last message repeated 15 times May 27 12:28:33 twopit last message repeated 15 times May 27 12:29:33 twopit last message repeated 15 times May 27 12:30:33 twopit last message repeated 15 times May 27 12:31:34 twopit last message repeated 15 times May 27 12:32:34 twopit last message repeated 15 times May 27 12:33:34 twopit last message repeated 15 times May 27 12:33:58 twopit last message repeated 6 times - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] missing rio_spin_unlock_irqrestore in rioroute.c (244ac18)
Forgot l-k when sending this off..
- Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -
Hi.
The following patch fixes a missing rio_spin_unlock_irqrestore
in drivers/char/rio/rioroute.c as per the stanford team's
report a way back. It applies against 244ac18.
--- linux-244-ac18-clean/drivers/char/rio/rioroute.cSat May 19 20:58:18 2001
+++ linux-244-ac18/drivers/char/rio/rioroute.c Sun May 27 20:46:34 2001
@@ -657,6 +657,7 @@
*/
if (PortP->TxStart == 0) {
rio_dprintk (RIO_DEBUG_ROUTE, "Tx pkts not set
up yet\n");
+ rio_spin_unlock_irqrestore(>portSem,
+flags);
break;
}
--
Regards,
Rasmus([EMAIL PROTECTED])
While the Melissa license is a bit unclear, Melissa aggressively
encourages free distribution of its source code.
-- Kevin Dalley on Melissa being Open Source
- End forwarded message -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix for buggy variable reuse in riotable.c (244ac18)
Forgot l-k when sending this off...
- Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -
Hi.
The following patch fixes a buggy variable reuse i drivers/char/
rio/riotable.c (244-ac18) as reported by the stanford team way
back.
--- linux-244-ac18-clean/drivers/char/rio/riotable.cSun May 27 20:19:56 2001
+++ linux-244-ac18/drivers/char/rio/riotable.c Sun May 27 21:12:16 2001
@@ -501,7 +501,7 @@
struct Map *HostMapP;
struct Port *PortP;
int work_done = 0;
- unsigned long flags;
+ unsigned long lock_flags, sem_flags;
rio_dprintk (RIO_DEBUG_TABLE, "Delete entry on host %x, rta %x\n",
MapP->HostUniqueNum,
MapP->RtaUniqueNum);
@@ -509,10 +509,10 @@
for ( host=0; host < p->RIONumHosts; host++ ) {
HostP = >RIOHosts[host];
- rio_spin_lock_irqsave( >HostLock, flags );
+ rio_spin_lock_irqsave( >HostLock, lock_flags );
if ( (HostP->Flags & RUN_STATE) != RC_RUNNING ) {
- rio_spin_unlock_irqrestore(>HostLock, flags);
+ rio_spin_unlock_irqrestore(>HostLock, lock_flags);
continue;
}
@@ -529,7 +529,7 @@
if ( HostMapP->Topology[link].Unit !=
ROUTE_DISCONNECT ) {
rio_dprintk (RIO_DEBUG_TABLE, "Entry
is in use and cannot be deleted!\n");
p->RIOError.Error = UNIT_IS_IN_USE;
- rio_spin_unlock_irqrestore(
>HostLock, flags);
+ rio_spin_unlock_irqrestore(
+>HostLock, lock_flags);
return EBUSY;
}
}
@@ -544,7 +544,7 @@
PortP = p->RIOPortp[port];
rio_dprintk (RIO_DEBUG_TABLE, "Unmap
port\n");
- rio_spin_lock_irqsave(
>portSem, flags );
+ rio_spin_lock_irqsave(
+>portSem, sem_flags );
PortP->Mapped = 0;
@@ -602,7 +602,7 @@
WWORD(PortP->PhbP->destination,
dest_unit + (dest_port << 8));
}
-
rio_spin_unlock_irqrestore(>portSem, flags);
+
+rio_spin_unlock_irqrestore(>portSem, sem_flags);
}
}
rio_dprintk (RIO_DEBUG_TABLE, "Entry nulled.\n");
@@ -610,7 +610,7 @@
work_done++;
}
}
- rio_spin_unlock_irqrestore(>HostLock, flags);
+ rio_spin_unlock_irqrestore(>HostLock, lock_flags);
}
/* X lock me up */
--
Regards,
Rasmus([EMAIL PROTECTED])
We're going to turn this team around 360 degrees.
-Jason Kidd, upon his drafting to the Dallas Mavericks
- End forwarded message -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 does not link on Ruffian (alpha)
On Sun, May 27, 2001 at 06:41:23PM +0200, Andrea Arcangeli wrote: > On Sun, May 27, 2001 at 04:49:24AM +0200, Andrea Arcangeli wrote: > > caused me to write the posted patch to get all compilations right. > > The reason I needed that patch is that I was not using 2.4.5aa1 but a > corrupted tree (I'm been fooled by an hardlink during developement), it > was just two lines away from the real one. > > So this is the fix for all 2.4.5 based trees (ac1 and aa1 included) to > get generic and dp264 compililations right: woops, the dp264 compilation wasn't right yet, this additional patch is needed too. --- 2.4.5aa2/arch/alpha/kernel/core_tsunami.c.~1~ Sat May 26 04:03:35 2001 +++ 2.4.5aa2/arch/alpha/kernel/core_tsunami.c Sun May 27 20:44:59 2001 @@ -11,7 +11,6 @@ #include #include #include -#include #include #include @@ -21,6 +20,8 @@ #include #include #undef __EXTERN_INLINE + +#include #include "proto.h" #include "pci_impl.h" the bootmem include was the one that broke the __EXTERN_INLINE logic for dp264. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] softirq-2.4.5-B0
On Sun, 27 May 2001, David S. Miller wrote: > Hooray, some sanity in this thread finally :-) [ finally i had some sleep after a really long debugging session :-| ] > > the attached softirq-2.4.5-B0 patch fixes this problem by calling > > do_softirq() from local_bh_enable() [if the bh count is 0, to avoid > > recursion]. > > Yikes! I do not like this fix. i think we have no choice, unfortunately. and i think function calls are not that scary anymore, especially not with regparms and similar compiler optimizations. The function is simple, the function just goes in and returns in 90% of the cases, which should be handled nicely by most BTBs. we have other fundamental primitives that are a function call too, eg. dget(), and they are used just as frequently. In 2.4 we were moving inlined code into functions in a number of cases, and it appeared to work out well in most cases. > I'd rather local_bh_enable() not become a more heavy primitive. > > I know, in one respect it makes sense because it parallels how > hardware interrupts work, but not this thing is a function call > instead of a counter bump :-( i believe the important thing is that the function has no serialization or other 'heavy' stuff. BHs had the misdesign of not being restarted after being re-enabled, and it caused performance problems - we should not repeat history. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
Adrian Bunk wrote: > > Hi, > > while looking for the reason of a build failure of the ALSA libraries on > ARM [1] I discovered the following strange thing: > > On some architectures a function is inside an "#ifdef __KERNEL__" in the > header file and on others not. Is there a reason for this or is this > inconsistency simply a bug? This is a bug on some architectures, I've personally fixed this on PPC sending a patch to Cort Dougan. It has been included in 2.4.5. I'd like you send a patch to maintainers (or perhaps to Alan). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] softirq-2.4.5-B0
Ingo Molnar writes: > the bug/misbehavior causing bad latencies turned out to be the following: > if a hardirq triggers a softirq, but syscall-level code on the same CPU > disabled local bhs via local_bh_disable(), then we 'miss' the execution of > the softirq, until the next IRQ. (or next direct call to do_softirq()). Hooray, some sanity in this thread finally :-) Yes, this makes perfect sense, this is indeed what can happen. > the attached softirq-2.4.5-B0 patch fixes this problem by calling > do_softirq() from local_bh_enable() [if the bh count is 0, to avoid > recursion]. Yikes! I do not like this fix. I'd rather local_bh_enable() not become a more heavy primitive. I know, in one respect it makes sense because it parallels how hardware interrupts work, but not this thing is a function call instead of a counter bump :-( Any other ideas how to zap this? 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Console display in portrait mode with unusual dpi resolution
Overview: At business I just got a brand new EIZO 18" LCD display L675 to test its usability for working in portrait mode to show a full A4 page. These test were done on Windows NT4 but I'd really like to know how well Linux would have done. I'm going to describe all the obstacles I encountered on Windows so anybody may knows the corresponding answers for Linux. Maybe there are other problems on Linux? 1. Obstacle While the EIZO L675 is mechanically turnable, it doesn't handle the landscape/portrait mode switch itself. [OFFTOPIC] Are the any other displays capable of this? [OFFTOPIC OFF] The turning software had to be ordered/paid separate (Pivot software). Of course the display should handle it itself, but until this happens a software solution is okay. Is there any software solution for Linux? I've heard there are graphics cards which handles the landscape/portrait mode themselves (i.e. ATI radeon). This is almost as good as if the display handles it, as long as if there are the corresponding drivers available. How about Linux drivers? PS. My good old monochrome portrait monitor from Apple (around 1990) is an fine example. 2. Obstacle The portrait mode software starts working just about before the logon screen is shown. All the BIOS and system messages are shown in landscape mode. This looks funny but is acceptable as long as no user interaction is necessary. So i.e. it needs a rather high concentration to switch to another hardware profile (Windows NT4). From the nature of a software solution I guess this can't be changed neither of Windows NT4 nor Linux. 3. Obstacle The EIZO L675 has a pixel pitch of 0.28x0.28 which is equivalent to about 90dpi. Since Windows (any version) uses a default value on 96dpi, everything is enlarged by about 5%. So even with an 18" display an A4 page can't be normally viewed in Word. Current status from Microsoft "problem is recognized, we are working on it". While there is no solution for Windows (probably until SP1 for XP) what's the status of Linux? PS. My good old monochrome portrait monitor is again an example. While it has 80dpi and Apple defaults to 72dpi on these old monitors (10% decrease) and Macintosh typically there is no useless scrap around, I can view an A4 page. Of course it also shows that even Apple has no solution to the dpi problem. O. Wyss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] severe softirq handling performance bug, fix, 2.4.5
On Sun, 27 May 2001, Andrea Arcangeli wrote: > I mean everything is fine until the same softirq is marked active > again under do_softirq, in such case neither the do_softirq in do_IRQ > will run it (because we are in the critical section and we hold the > per-cpu locks), nor we will run it again ourself from the underlying > do_softirq to avoid live locking into do_softirq. if you mean the stock kernel, this scenario you describe is not how it behaves, because only IRQ contexts can mark a softirq active again. And those IRQ contexts will run do_IRQ() naturally, so while *this* do_softirq() invocation wont run those reactivated softirqs, the IRQ context that just triggered the softirq will do so. the real source of softirq latencies is the local_bh_disable()/enable() behavior, see my previous patch. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: problems with ac12 kernels and up
>> http://jcwren.com/linux/ac18.txt - ac18 dmesg dump >> http://jcwren.com/linux/build.txt - sequence I'm using to build >> >> The apparent interleaved garbage closer to the bottom is exactly what came >> out on the console. (Is linking to the dumps perferred over including it in >> the mail, or would folks prefer to have the text included? Since I'm not a > >The link is fine.. > >> I also rebuilt the ac12 kernel, and tried again. Same results as the quoted >> text above. > >This looks a lot like the superblock changes not only broke reiserfs but also >initd usage. > >Al ? If it's of any help, here's the System.map around that EIP: c017f0d0 T floppy_eject c017f100 t get_dma_residue c017f150 t rd_make_request c017f280 t rd_ioctl c017f380 t initrd_read c017f3d0 t initrd_release c017f420 t rd_open c017f4b0 t rd_release --John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4-ac17-2.4.5-ac1 oops in swapper process
On Sun, May 27, 2001 at 02:18:57PM -0400, you [[EMAIL PROTECTED]] claimed: > All, > > I have been getting a oops ever since 2.4.4-ac17 right after the kernel loads > the sym53c895 driver. I hand copied part of the oops before rebooting. This > happens in every kernel since 2.4.4-ac17. I have changed my compiler from > gcc-2.96 to egcs-1.12, thinking that the Mandrake gcc was bad. I still see > the same problems at the exact same point even after recompilation. > > ce at virtual address 0296 > print eip: c017f5d6 > *pde: > Oops > CPU: 0 > > EIP: 0010:[] > eflags: 0010202 > eax: 0286 ebx: 1261 ecx: edx: dfff3d74 > csi: edi: dfe66da0 ebp: dfe 63160 esp: dfff3d54 > ds: 0018 es: 0018 ss: 0018 > process swapper pid 1, stackpage=dfff3000 I think I'm seeing the same; see http://marc.theaimsgroup.com/?l=linux-kernel=99079948404775=2 Hmm, I have sym53c895 as well, but I thought this was initrd related. > thats all I got, I can try again and copy down any other information from that > oops that may be useful. Should I copy the whole thing and then put it > through ksymoops? Definetely. -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-ac17-2.4.5-ac1 oops in swapper process
All, I have been getting a oops ever since 2.4.4-ac17 right after the kernel loads the sym53c895 driver. I hand copied part of the oops before rebooting. This happens in every kernel since 2.4.4-ac17. I have changed my compiler from gcc-2.96 to egcs-1.12, thinking that the Mandrake gcc was bad. I still see the same problems at the exact same point even after recompilation. ce at virtual address 0296 print eip: c017f5d6 *pde: Oops CPU: 0 EIP: 0010:[] eflags: 0010202 eax: 0286 ebx: 1261 ecx: edx: dfff3d74 csi: edi: dfe66da0 ebp: dfe 63160 esp: dfff3d54 ds: 0018 es: 0018 ss: 0018 process swapper pid 1, stackpage=dfff3000 thats all I got, I can try again and copy down any other information from that oops that may be useful. Should I copy the whole thing and then put it through ksymoops? I have /var/log/ksymoops with the module and ksyms files to use. Please advise, I am willing to test anything thats needed. Sean lspci -v -v -v 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Subsystem: Asustek Computer, Inc.: Unknown device 8017 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 0 0 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 23) Subsystem: Asustek Computer, Inc.: Unknown device 8017 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping+ SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 11) (prog-if 0 0 [UHCI]) Subsystem: Unknown device 0925:1234 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:04.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050 (rev 30) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- [disabled] [size=64K] 00:0b.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02) Subsystem: Ensoniq: Unknown device 2003 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- 00:0c.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10) Subsystem: Accton Technology Corporation EN-1207D Fast Ethernet Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 00:0d.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c895 (rev 0 1) Subsystem: Tekram Technology Co.,Ltd.: Unknown device 3907 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Step ping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] 01:00.0 VGA compatible controller: nVidia Corporation NV15 (Geforce2 GTS) (rev a 3) (prog-if 00 [VGA]) Subsystem: LeadTek Research Inc.: Unknown device 2840 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- .config
RE: Problems with ac12 kernels and up
> >> Checking root filesystem. /dev/hde13 is mounted. >> Cannot continue, aboorting. >> *** An error occurred during the file system check. >> *** Dropping you to a shell; the system will reboot >> *** when you leave the shell. > >That means the file system was mounted read/write at boot time. That normally >indicates a lilo misconfiguration however your lilo.conf looks >correct. > >Alan I've built the ac18 kernel with the serial console enabled, and dumped the results (this is the one that kernel panics). http://jcwren.com/linux/ac18.txt - ac18 dmesg dump http://jcwren.com/linux/build.txt - sequence I'm using to build The apparent interleaved garbage closer to the bottom is exactly what came out on the console. (Is linking to the dumps perferred over including it in the mail, or would folks prefer to have the text included? Since I'm not a judge of exactly what you need to see, I'm not sure if 200 lines of dump would be appropriate or not). Just for good measure, I've installed the latest RH 7.1 LILO, mkinitrd, and associated tools. I also rebuilt the ac12 kernel, and tried again. Same results as the quoted text above. --John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Performance lack !
From: "Jakob Østergaard" <[EMAIL PROTECTED]> wrote :
>
> The answer for both of you is:
>
> hdparm -d1 /dev/hd{whatever}
>
> Without DMA enabled, performance is going to suck. 1.9 MB/sec is actually
pretty
> good without DMA ;)
>
i think DMA or PCI is not my solution , atleast :)
Thank you,
Best Regards,
Jaswinder.
--
These are my opinions not 3Di.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
usb-ohci module from 2.4.5 kernel refuses to load on alpha, usb-ohci in a monolithic kernel refuses to recognize devices
Hello, I'm having the following problem, when trying to load usb-ohci as a module: firmin:/usr/src/linux/drivers/usb# modprobe usb-ohci /lib/modules/2.4.5/kernel/drivers/usb/usb-ohci.o: init_module: No such device Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.4.5/kernel/drivers/usb/usb-ohci.o: insmod /lib/modules/2.4.5/kernel/drivers/usb/usb-ohci.o failed /lib/modules/2.4.5/kernel/drivers/usb/usb-ohci.o: insmod usb-ohci failed firmin:/usr/src/linux/drivers/usb# Compiling this into the kernel doesn't seem to solve the problem as the bootstrap mentions: usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings! When browsing through arch/alpha/kernel/sys_miata.c, it seemed to me that there are no irq assignments to the usb subsystem. Off the record, my system is a Digital Personal Workstation 500au. If you need more specs, do not hesitate to ask. Pieter. -- Pieter Barrezeele [EMAIL PROTECTED] 2e Lic Informatica KULeuvenUlyssis sysadmin, Linux enthousiast Build a system even a fool can use, and only a fool will want to use it ... -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Performance lack !
"Chris Wedgwood" <[EMAIL PROTECTED]> wrote: > On Sat, May 26, 2001 at 05:16:42PM -0700, Jaswinder Singh wrote: > > When ever i copy big data (around 400 to 700 MB ) from one > partion to another my machine do not response at all (i can not > work on another shell) during data transfer. > > Both paritions on the same spindle? That's going to suck no matter > what you do... I am having only one harddisk of 20 Gb , so i made four partitions on it. > but it shouldn't be as bad as you describe. But it is more bad then i described , especially when i do telnet/ssh from my home . I am not able to understand why Linux read and/or write harddisk after some time (after few hours ) , harddisk read/write leds keep on glowing for few minutes , even though nobody working on it and machine is in idle state. >Have you tried 2.2.x ? > yes i am taking about 2.2.12 . And in my 2.4.2 :- Harddisk read-write problem is also there , during harddisk read-write activity i took two hdparams and i got :- i . 963.76 kB/sec ii. 1.05 MB/sec and when my machine becomes normal i got :- 9.07 MB/sec and after hdparam -d1 i got :- 9.55 MB/sec But my problem is why linux boxes do not response for few seconds (sometimes) and especially during telnet/ssh it looks more worst and looks similar to Microsoft Windows :( there is problem in scheduling or what ? Thank you, Best Regards, Jaswinder. -- These are my opinions not 3Di. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Performance lack !
> The answer for both of you is:
>
> hdparm -d1 /dev/hd{whatever}
>
> Without DMA enabled, performance is going to suck. 1.9 MB/sec is actually pretty
> good without DMA ;)
I agree.
I get around 4MB/s without and 35.75MB/s with...
hdparm -c3 -d1 -m16 /dev/hda
on a KT133 (A7V) and 45GB IBM DTLA hard drive.
no data corruption, even with a sblive, an scsi
adapter, 2 hard drives...
François Cami
> --
> .
> : [EMAIL PROTECTED] : And I see the elder races, :
> :.: putrid forms of man:
> : Jakob Østergaard : See him rise and claim the earth, :
> :OZ9ABN : his downfall is at hand. :
> :.:{Konkhra}...:
> -
--
All that is gold does not glitter,
Not all those who wander are lost,
The old that is strong does not wither,
Deep roots are not touched by the frost.
From the ashes a fire shall be woken,
A light from the shadows shall spring,
Renewed shall the blade that was broken,
The crownless again shall be king.
The Riddle of Strider
JRR Tolkien
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE no go with 2.4.5-ac1
On Sun, May 27, 2001 at 08:28:14PM +0400, Oleg Drokin wrote:
> On Sun, May 27, 2001 at 05:18:20PM +0100, Alan Cox wrote:
> > > Vanilla 2.4.5 boots ok, but 2.4.5-ac1 finishes kernel initialisation and
> > > starts to print "hda: lost interrupt", I guess this is related to VIA IDE
> > > updates in AC kernels. Config for vanilla and AC kernel is the same.
> > > Here are the kernel logs from 2.4.5 and 2.4.5-ac1 (collected with serial
> > > ACPI: Core Subsystem version [20010208]
> > > ACPI: Subsystem enabled
> > > ACPI: Not using ACPI idle
> > > ACPI: System firmware supports: S0 S1 S4 S5
> > > hda: lost interrupt
> > > hda: lost interrupt
> > Does this still happen if you build without ACPI support. Also does
> > 'noapic' have any impact ?
> I will try this and report.
> I received this patch from Carlos E Gorges <[EMAIL PROTECTED]>,
> that allows my box to boot, but DMA is not enabled by default
> (and needs to be explicitly enabled by hdparm -d1 /dev/hda) regardless of
> what is written at boot time.
>
> --- drivers/ide/via82cxxx.c.orig Sun May 27 08:10:47 2001
> +++ drivers/ide/via82cxxx.c Sun May 27 08:11:13 2001
> @@ -105,7 +105,7 @@
> { "vt8233", PCI_DEVICE_ID_VIA_8233_0, 0x00, 0x2f, VIA_UDMA_100 },
> { "vt8231", PCI_DEVICE_ID_VIA_8231, 0x00, 0x2f, VIA_UDMA_66 },
> #endif
> - { "vt82c686b", PCI_DEVICE_ID_VIA_82C686, 0x40, 0x4f, VIA_UDMA_100 |
>VIA_BAD_PIO },
> + { "vt82c686b", PCI_DEVICE_ID_VIA_82C686, 0x40, 0x4f, VIA_UDMA_100 },
> { "vt82c686a", PCI_DEVICE_ID_VIA_82C686, 0x10, 0x2f, VIA_UDMA_66 },
> { "vt82c686", PCI_DEVICE_ID_VIA_82C686, 0x00, 0x0f, VIA_UDMA_33 |
>VIA_BAD_CLK66 },
> { "vt82c596b", PCI_DEVICE_ID_VIA_82C596, 0x10, 0x2f, VIA_UDMA_66 },
Not sure what version you're using, but if it's 3.23 (I believe it is)
then this patch does completely nothing, because the VIA_BAD_PIO flag
isn't used.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 + ReiserFS + SMP + umount = oops
Hi,
This was reported on the reiserfs list yesterday. Seems that the cleanup
applied late in 2.4.5-pre affected the locking of the umount process. This
was posted to fix the problem.
Ed Tomlinson
---
"Vladimir V. Saveliev" wrote:
>
> Hi
>
> Gergely Tamas wrote:
> >
> > Hi!
> >
> > Kernel is 2.4.5
> >
> > I've tried to unmount a reiserfs device (/uu.new) and got a segfault.
>
> Well, sys_umount in 2.4.5 changed to not lock_kernel() at the beginning and to not
>unlock_kernel() at the end correspondingly.
> journal_begin expectes kernel locked and it oopses when it is not. Maybe
>reiserfs_put_super should lock_kernel () itself?
>
Hi,
You are right.
It seems, the next patch can fix umount reiserfs bug in linux-2.4.5 :
diff -urN v2.4.5/fs/reiserfs/super.c linux/fs/reiserfs/super.c
--- v2.4.5/fs/reiserfs/super.c Sun Apr 29 16:02:25 2001
+++ linux/fs/reiserfs/super.cSat May 26 19:10:16 2001
@@ -104,7 +104,8 @@
{
int i;
struct reiserfs_transaction_handle th ;
-
+
+ lock_kernel() ;
/* change file system state to current state if it was mounted with
read-write permissions */
if (!(s->s_flags & MS_RDONLY)) {
journal_begin(, s, 10) ;
@@ -117,6 +118,7 @@
** to do a journal_end
*/
journal_release(, s) ;
+ unlock_kernel() ;
for (i = 0; i < SB_BMAP_NR (s); i ++)
brelse (SB_AP_BITMAP (s)[i]);
Thanks,
Yura.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac17
> Yes.. seems the caches need some size limits. ramfs will lock you in > a heart beat if you hit oom. (i made a typo during iozone run.. oops:) ramnfs has resource limits in -ac for a reason. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
> On some architectures a function is inside an "#ifdef __KERNEL__" in the > header file and on others not. Is there a reason for this or is this > inconsistency simply a bug? Its probably a bug - primarily it depends if the function is useful when exported to non kernel code - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
insl/outsl in parport_pc and !CONFIG_PCI
Hi, How is that supposed to work on systems without PCI? For now I have defined #define insl(port,buf,len) isa_insb(port,buf,(len)<<2) #define outsl(port,buf,len) isa_outsb(port,buf,(len)<<2) in asm-m68k/parport.h. Bye Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please help me fill in the blanks.
Thank you Jeff for your very helpfull answer. --- Jeff Garzik <[EMAIL PROTECTED]> skrev: > Cesar Da Silva wrote: > > * Alternative I/O Pathing > > be less vague What I mean with the above (my defenition) is: [Alternative I/O Pathing allows the operating system to re-route the I/O of devices, such as disk or network adapters, to a backup device, in case of failure. Regards, Cesar da Silva _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please help me fill in the blanks.
--- Ville Herva <[EMAIL PROTECTED]> skrev: > > > * Dynamic Memory Resilience > > > > RAM fault tolerance? There was a patch a long > time ago which detected > > bad ram, and would mark those memory clusters as > unuseable at boot. > > However that is clearly not dynamic. > > If you are referring to Badram patch by Rick van > Rein > (http://rick.vanrein.org/linux/badram/), it doesn't > detect the bad ram, > memtest86 does that part (and does it well) -- you > enter then enter the > badram clusters as boot param. But I have to say > badram patch works > marvellously (thanks, Rick.) Shame it didn't find > its way to standard > kernel. Hi Ville, and thanks for the great link and the information. Regards, Cesar da Silva _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Inconsistent "#ifdef __KERNEL__" on different architectures
Hi, while looking for the reason of a build failure of the ALSA libraries on ARM [1] I discovered the following strange thing: On some architectures a function is inside an "#ifdef __KERNEL__" in the header file and on others not. Is there a reason for this or is this inconsistency simply a bug? In this case the following functions are affected (in 2.4.5): atomic_read, atomic_inc and atomic_dec in include/asm-*/atomic.h "#ifdef __KERNEL__" only on arm, mips, mips64 and sparc (but not on sparc64) rmb and wmb in include/asm-*/system.h "#ifdef __KERNEL__" only on arm and sparc (but not on sparc64) not defined on parisc although used to define smp_rmb on SMP systems: <-- snip --> #ifdef CONFIG_SMP #define smp_mb()mb() #define smp_rmb() rmb() #define smp_wmb() wmb() #else <-- snip --> cu Adrian [1] http://bugs.debian.org/97988 -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG?: 2.4.5 breaks reiserfs (kernel BUG)
Hi,
Today I downloaded kernel 2.4.5 and compiled it. The kernel worked fine
until
I tried to halt the computer. When trying to unmount the reiserfs
filesystems,
the system freezes with the following output:
journal_begin called without kernel lock held
kernel BUG at journal.c:423!
invalid operand:
CPU:0
EIP:0010:[]
EFLAGS: 00210282
eax: 001d ebx: c1eb1f28 ecx: c7ab2000 edx: 0001
esi: c13c8200 edi: 3b11320b ebp: 000a esp: c1eb1ec0
ds: 0018 es: 0018 ss: 0018
Process umount (pid: 1027, stackpage=c1eb1000)
Stack: c02ef289 c02ef3e4 01a7 c01b855b c02f0401 c1eb1f28 c13c8200
c034e020
c13c8234 3b11320b c67f55c0 c13c8200 c1eb c13c8244
c01b876e
c1eb1f28 c13c8200 000a c01a92f8 c1eb1f28 c13c8200
000a
Call Trace: [] [] [] []
[] [] []
[] [] [] []
Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 90 31 c0 c3 90 56 be 40 2f
BTW: The kernel is compiled with egcs 2.91.66
Please CC to [EMAIL PROTECTED] as I am not subscribed to this list
Svein Olav Bjerkeset
èº{.nÇ+·®+%Ëlzwm
éb맲æìr¸zX§» ®w¥{ayº ÊÚë,j¢f£¢·hàz¹ ®w¥¢¸
¢·¦j:+v¨wèjØm¶ÿ¾«êçzZ+ùÝ¢j"ú!¶iOæ¬z·vØ^¶m§ÿðà nÆàþY&
Re: 2.4.5-ac1 hard disk corruption... acpi responsible?
> Today I moved to 2.4.5-ac1, the only different thing > than normal was I enabled ACPI instead of APM. Bad idea. The kernel ACPI is not the most debugged, the ACPI in many BIOSes is complete garbage and there isnt a lot you can do to debug them either. APM is a definite better choice, at least in the shorter term - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] severe softirq handling performance bug, fix, 2.4.5
On Sat, May 26, 2001 at 07:59:28PM +0200, Ingo Molnar wrote: > the two error cases are: > > #1 hard-IRQ interrupts user-space code, activates softirq, and returns to > user-space code Before returning to userspace do_IRQ just runs do_softirq by hand from C code. > #2 hard-IRQ interrupts the idle task, activates softirq and returns to > the idle task. The problem only happens when we return to the idle task and a softirq is been marked active again and we cannot keep running it or we risk to soft deadlock. I think the final fix for those issues (plus the case of a softirq marking itself running all the time) is ksoftirqd, it lets the scheduler to balance the softirq load, you can as well renice it. please try to benchmark after applying it, it should solve all your troubles cleanly, during tux load ksoftirq runs quite a lot btw: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa1/00_ksoftirqd-4 don't forget to apply this scheduler fix first, or your risk to run into troubles: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa1/00_cpus_allowed-1 I also suggest to apply the other scheduler fixes like the sched_yield and parent_timeslice too before running the test. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Performance lack !
On Sat, May 26, 2001 at 05:16:42PM -0700, Jaswinder Singh wrote:
> >
> > RedHat 7.1 - IDE IBM 41.1 GIG
> > Update to 2.4.5 -> noticed, that hdparm -t /dev/hda went down from 10
> > MByte/sec to 1.9 MByte/sec
> > Any special Options, beside ide-scsi driver activated ..
> >
> > Anybody noticed the same problem ? Any clues ?
> >
>
> yes , i am also not happy with IDE performance of Linux . That why i dont
> use Hard disk in my Target machines ;)
>
> When ever i copy big data (around 400 to 700 MB ) from one partion to
> another my machine do not response at all (i can not work on another shell)
> during data transfer.
The answer for both of you is:
hdparm -d1 /dev/hd{whatever}
Without DMA enabled, performance is going to suck. 1.9 MB/sec is actually pretty
good without DMA ;)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE no go with 2.4.5-ac1
Hello!
On Sun, May 27, 2001 at 05:18:20PM +0100, Alan Cox wrote:
> > Vanilla 2.4.5 boots ok, but 2.4.5-ac1 finishes kernel initialisation and
> > starts to print "hda: lost interrupt", I guess this is related to VIA IDE
> > updates in AC kernels. Config for vanilla and AC kernel is the same.
> > Here are the kernel logs from 2.4.5 and 2.4.5-ac1 (collected with serial
> > ACPI: Core Subsystem version [20010208]
> > ACPI: Subsystem enabled
> > ACPI: Not using ACPI idle
> > ACPI: System firmware supports: S0 S1 S4 S5
> > hda: lost interrupt
> > hda: lost interrupt
> Does this still happen if you build without ACPI support. Also does
> 'noapic' have any impact ?
I will try this and report.
I received this patch from Carlos E Gorges <[EMAIL PROTECTED]>,
that allows my box to boot, but DMA is not enabled by default
(and needs to be explicitly enabled by hdparm -d1 /dev/hda) regardless of
what is written at boot time.
--- drivers/ide/via82cxxx.c.origSun May 27 08:10:47 2001
+++ drivers/ide/via82cxxx.c Sun May 27 08:11:13 2001
@@ -105,7 +105,7 @@
{ "vt8233", PCI_DEVICE_ID_VIA_8233_0, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt8231", PCI_DEVICE_ID_VIA_8231, 0x00, 0x2f, VIA_UDMA_66 },
#endif
- { "vt82c686b", PCI_DEVICE_ID_VIA_82C686, 0x40, 0x4f, VIA_UDMA_100 |
VIA_BAD_PIO },
+ { "vt82c686b", PCI_DEVICE_ID_VIA_82C686, 0x40, 0x4f, VIA_UDMA_100 },
{ "vt82c686a", PCI_DEVICE_ID_VIA_82C686, 0x10, 0x2f, VIA_UDMA_66 },
{ "vt82c686", PCI_DEVICE_ID_VIA_82C686, 0x00, 0x0f, VIA_UDMA_33 |
VIA_BAD_CLK66 },
{ "vt82c596b", PCI_DEVICE_ID_VIA_82C596, 0x10, 0x2f, VIA_UDMA_66 },
Bye,
Oleg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[OOPS] Re: Linux 2.4.5-ac1
On Sat, May 26, 2001 at 10:58:25PM +0100, you [Alan Cox] claimed: > > o Free the initial ramdisk correctly Who made this fix, or who can I contact? I have a reproducible oops on 2.4.4ac17 (see http://marc.theaimsgroup.com/?l=linux-kernel=99079948404775=2 for details) that seems to be related: (1)Unable to handle kernel NULL pointer dereference at virtual address 0013 >>EIP; c02997f6 <__devices_1045+5a/a8> <= Trace; c0136447 Trace; c017fec3 Trace; c0118769 <__run_task_queue+49/60> Trace; c011b0f6 Trace; c011b304 Trace; c011868c Trace; c0118596 Trace; c011849b Trace; c010832f Trace; c0106f14 Trace; c0199756 Trace; c01330d6 Trace; c0131447 Trace; c0122cf5 Trace; c01416db Trace; c0142b81 Trace; c0136641 Trace; c013484a Trace; c0134ab0 Trace; c0105000 Trace; c01177e6 Trace; c0105000 Trace; c01051da Trace; c010520e Trace; c0105000 Trace; c01056a6 Trace; c0105200 Code; c02997f6 <__devices_1045+5a/a8> <_EIP>: Code; c02997f6 <__devices_1045+5a/a8> <= 0: 8b 40 10 mov0x10(%eax),%eax <= Code; c02997f9 <__devices_1045+5d/a8> 3: 83 f8 02 cmp$0x2,%eax Code; c02997fc <__devices_1045+60/a8> 6: 7e 62 jle6a <_EIP+0x6a> c0299860 <__devices_104a +c/20> Code; c02997fe <__devices_1045+62/a8> 8: b8 f0 ff ff ffmov$0xfff0,%eax Code; c0299803 <__devices_1045+67/a8> d: eb 74 jmp83 <_EIP+0x83> c0299879 <__devices_104b +5/18> Code; c0299805 <__devices_1045+69/a8> f: 85 c9 test %ecx,%ecx Code; c0299807 <__devices_1045+6b/a8> 11: b8 ea ff 00 00mov$0xffea,%eax Judging from the stack trace, I suspect that after kill_super is called (and hence, root device invalidated and freed), a function that that assumes a valid rootdev (ioctl_by_bdev) is called. Rdev is NULL, and hence the null ptr deref. Is this anywhere near the truth? -- v -- [EMAIL PROTECTED] PS: A this is a 600Mhz Xeon w/ 256MB RAM. Right after boot I did 'diff -nauR linux-2.4.5 linux-2.4.4ac17' on redhat 2.4.2-2, and it never finished: root@machine:/poista>diff -nauR linux-2.4.5 linux-2.4.4ac17 zsh: terminated diff -nauR linux-2.4.5 linux-2.4.4ac17 root@machine:/poista>free total used free sharedbuffers cached Mem:255572 253140 2432 0 8332 215108 -/+ buffers/cache: 29700 225872 Swap:0 0 0 root@machine:/poista>uname -a Linux machine 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown root@machine:/poista>dmesg | tail -2 Out of Memory: Killed process 804 (xfs). Out of Memory: Killed process 15857 (diff). So diff (which used very little RAM) filled the _cache_ and OOM rambo kicked in. Pretty embarrassing to say at least... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Re: 2.4.5aa1
On Sun, May 27, 2001 at 04:32:09AM +0200, Andrea Arcangeli wrote: > Ok, then I will add define_bool CONFIG_NO_PAGE_VIRTUAL y to sparc and typo: won't - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE no go with 2.4.5-ac1
> Vanilla 2.4.5 boots ok, but 2.4.5-ac1 finishes kernel initialisation and > starts to print "hda: lost interrupt", I guess this is related to VIA IDE > updates in AC kernels. Config for vanilla and AC kernel is the same. > Here are the kernel logs from 2.4.5 and 2.4.5-ac1 (collected with serial > ACPI: Core Subsystem version [20010208] > ACPI: Subsystem enabled > ACPI: Not using ACPI idle > ACPI: System firmware supports: S0 S1 S4 S5 > hda: lost interrupt > hda: lost interrupt Does this still happen if you build without ACPI support. Also does 'noapic' have any impact ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.4.5] buz.c compile errors
> I have written a patch for buz.c for 2.4.5, it should be solution, but i > don't know it really works, I don't have such hardware available. It doesnt work. The entire buz driver is totally broken and to be discarded - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zr36120.c
> I found this error using xgcc with metal as an error checker. It seems to > be a simple case of not freeing allocatd memory on an error path. > -john martin Already fixed in -ac - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5aa1
On Sat, May 26, 2001 at 10:15:48PM -0700, Phil Oester wrote: > Works for me. Running cerberus on a machine w/2gb RAM - deadlocks on 2.4.5 > vanilla, keeps running on 2.4.5aa1. great. That was the interesting test to try. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please help me fill in the blanks.
--- Rik van Riel <[EMAIL PROTECTED]> skrev: > On Sun, 27 May 2001, [iso-8859-1] Cesar Da Silva > wrote: > > > I am doing a thesis about comparing the Linux > kernel > > against HP-UX, AIX, Tru64 UNIX, and Solaris (as > you > > probably alredy know). > > I'm stuck now (and the thesis has to bee ready > until > > tomorow) > > Aren't you the same guy who posted this question > last > week? > > And the same guy who asked us to "fill in the > blanks" > on an essentially EMPTY work? ;) Yes, but this time I was more precise with what I wanted help with (I included a list in the message), and it helped, I got alot more responses this time. Regards, Cesar da Silva _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vm in 2.4.5 (fwd)
[Oh, and please don't let UUCP addresses get out] On Sat, 26 May 2001, Andrzej Krzysztofowicz wrote: > Am I right ? No. And not only that, you also snipped the part of my email which explains what is happening. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
