2.4.0 bug: file /proc/dri 4 times in ls listing
Hi, I'm running kernel 2.4.0 on Redhat 7.0. I tried to get direct rendering running (it failed, but that's another story). Today I noticed something strange in /proc: dri appears there 4 times. ls /proc: ... -r--r--r--1 root root0 Jan 16 08:57 dma dr-xr-xr-x3 root root0 Jan 16 08:57 dri dr-xr-xr-x3 root root0 Jan 16 08:57 dri dr-xr-xr-x3 root root0 Jan 16 08:57 dri dr-xr-xr-x3 root root0 Jan 16 08:57 dri dr-xr-xr-x2 root root0 Jan 16 08:57 driver ... Chdir /proc/dri/0 works fine: bobo:/proc/dri/0>ls bufs clients histo mem name queues vm vma No dri modules, everything is linked in (I know I don't need all of these, but I have lots of memory, so...). ... CONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_AGP_I810=y CONFIG_AGP_VIA=y CONFIG_AGP_AMD=y CONFIG_AGP_SIS=y CONFIG_AGP_ALI=y CONFIG_DRM=y CONFIG_DRM_TDFX=y CONFIG_DRM_GAMMA=y CONFIG_DRM_R128=y CONFIG_DRM_I810=y CONFIG_DRM_MGA=y ... Regards, bobo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0ac9
Hi, 2.4.0ac9 still kills the mouse on this machine. dmesg is attached. Something I find interesting is that the PCMCIA bridge is on IRQ12. We can't change the mouse or the PCMCIA bridges' interrupt. I'll be happy to provide additional info. Regards, Igmar Jan 16 08:33:06 mars kernel: Linux version 2.4.0-ac9 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Mon Jan 15 19:03:29 CET 2001 Jan 16 08:33:06 mars kernel: BIOS-provided physical RAM map: Jan 16 08:33:06 mars kernel: BIOS-e820: 0009f800 @ (usable) Jan 16 08:33:06 mars kernel: BIOS-e820: 0800 @ 0009f800 (reserved) Jan 16 08:33:06 mars kernel: BIOS-e820: 00015800 @ 000ea800 (reserved) Jan 16 08:33:06 mars kernel: BIOS-e820: 05f0 @ 0010 (usable) Jan 16 08:33:06 mars kernel: BIOS-e820: 00015800 @ fffea800 (reserved) Jan 16 08:33:06 mars kernel: On node 0 totalpages: 24576 Jan 16 08:33:06 mars kernel: zone(0): 4096 pages. Jan 16 08:33:06 mars kernel: zone(1): 20480 pages. Jan 16 08:33:06 mars atd: atd startup succeeded Jan 16 08:33:06 mars kernel: zone(2): 0 pages. Jan 16 08:33:07 mars kernel: Kernel command line: BOOT_IMAGE=test1 ro root=307 sb=0x220,5,1 Jan 16 08:33:07 mars kernel: Initializing CPU#0 Jan 16 08:33:07 mars kernel: Detected 232.110 MHz processor. Jan 16 08:33:07 mars kernel: Console: colour VGA+ 80x25 Jan 16 08:33:07 mars kernel: Calibrating delay loop... 462.02 BogoMIPS Jan 16 08:33:07 mars kernel: Memory: 94084k/98304k available (1252k kernel code, 3832k reserved, 508k data, 196k init, 0k highmem) Jan 16 08:33:07 mars kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Jan 16 08:33:07 mars kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Jan 16 08:33:07 mars kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Jan 16 08:33:07 mars kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Jan 16 08:33:07 mars kernel: VFS: Diskquotas version dquot_6.5.0 initialized Jan 16 08:33:00 mars rc.sysinit: Mounting proc filesystem succeeded Jan 16 08:33:07 mars crond: crond startup succeeded Jan 16 08:33:07 mars kernel: CPU: Before vendor init, caps: 0183f9ff , vendor = 0 Jan 16 08:33:00 mars sysctl: net.ipv4.ip_forward = 0 Jan 16 08:33:07 mars kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Jan 16 08:33:00 mars sysctl: net.ipv4.conf.all.rp_filter = 1 Jan 16 08:33:07 mars kernel: CPU: L2 cache: 512K Jan 16 08:33:00 mars sysctl: kernel.sysrq = 0 Jan 16 08:33:08 mars kernel: Intel machine check architecture supported. Jan 16 08:33:08 mars inet: inetd startup succeeded Jan 16 08:33:00 mars sysctl: error: 'net.ipv4.ip_always_defrag' is an unknown key Jan 16 08:33:08 mars kernel: Intel machine check reporting enabled on CPU#0. Jan 16 08:33:00 mars rc.sysinit: Configuring kernel parameters succeeded Jan 16 08:33:08 mars kernel: CPU: After vendor init, caps: 0183f9ff Jan 16 08:33:08 mars sshd: Starting sshd: Jan 16 08:33:00 mars date: Tue Jan 16 08:32:59 CET 2001 Jan 16 08:33:08 mars kernel: CPU: After generic, caps: 0183f9ff Jan 16 08:33:00 mars rc.sysinit: Setting clock : Tue Jan 16 08:32:59 CET 2001 succeeded Jan 16 08:33:08 mars kernel: CPU: Common caps: 0183f9ff Jan 16 08:33:00 mars rc.sysinit: Loading default keymap succeeded Jan 16 08:33:09 mars kernel: CPU: Intel Pentium II (Deschutes) stepping 02 Jan 16 08:33:00 mars rc.sysinit: Activating swap partitions succeeded Jan 16 08:33:09 mars kernel: Enabling fast FPU save and restore... done. Jan 16 08:33:00 mars rc.sysinit: Setting hostname mars.office.jdimedia.nl succeeded Jan 16 08:33:09 mars kernel: Checking 'hlt' instruction... OK. Jan 16 08:33:00 mars fsck: /dev/hda7: clean, 50558/114016 files, 196128/227800 blocks Jan 16 08:33:10 mars sshd: sshd startup succeeded Jan 16 08:33:10 mars sshd[557]: Server listening on 0.0.0.0 port 22. Jan 16 08:33:10 mars kernel: POSIX conformance testing by UNIFIX Jan 16 08:33:00 mars rc.sysinit: Checking root filesystem succeeded Jan 16 08:33:10 mars sshd: Jan 16 08:33:10 mars sshd[557]: Generating 768 bit RSA key. Jan 16 08:33:10 mars kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd9e3, last bus=0 Jan 16 08:33:00 mars rc.sysinit: Remounting root filesystem in read-write mode succeeded Jan 16 08:33:10 mars rc: Starting sshd succeeded Jan 16 08:33:10 mars kernel: PCI: Using configuration type 1 Jan 16 08:33:00 mars rc.sysinit: Finding module dependencies failed Jan 16 08:33:10 mars kernel: PCI: Probing PCI hardware Jan 16 08:33:00 mars depmod: depmod: Can't open /lib/modules/2.4.0-ac9/modules.dep for writing Jan 16 08:33:11 mars kernel: PCI: Using IRQ router PIIX [8086/7110] at 00:03.0 Jan 16 08:
"Received disconnect: Command terminated on signal 13." when logging in via ssh
I get this message when logging into a box via ssh. the box is running 2.4 Kernel with devfsd installed on debian potato. I have a *hunch* that this may be to do with devfsd, and the fact that devfsd is not creating the /dev/pts/x files correctly (or in a timely manner) to prove this, I check the /dev/pts/ (and /dev-state/pts) dirs, prior to logging in on another xterm, make sure that all /dev/pty/ entries are used, and try logging in again. same error. Now, when I try logging in on a new pts, it shows up in /dev-state/pts/ with root.root ownerships, and crw-rw-rw- permissions. in order to log in, I have to chown it to user.tty any ideas what is going wrong? any suggestions to fix it? Regards Allen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
quota and 2.4.0-ac9
When running 'quotaon -a' I get message 'quotaon: using /quota.user on /dev/hdc3: Invalid argument'. This occurs at least with 2.4.0-ac4 and 2.4.0-ac9, but not with 2.4.0. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mmap()/VM problems in 2.4.0
On Tue, 16 Jan 2001, Vlad Bolkhovitine wrote: > > My box thinks quite highly of that patch fwiw, but insists that he needs > > to apply Jens Axboes' blk patch first ;-) (Not because of tiobench) > > New data: > > 2.4.1pre3 + Marcelo's patch > >File Block Num Seq ReadRand Read Seq Write Rand Write > DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) > --- -- --- --- --- --- --- --- >. 1024 40962 12.68 9.23% 0.497 0.92% 10.57 15.3% 0.594 1.44% > > The same performance level as for 2.4.0. No improvement. I was refering to the stalls.. not throughput. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Doc bug? Is Sangoma S514 PCI WAN card supported?
Under 2.4.0-ac4 I find lots of mentions of the Sangoma S514 PCI Multiprotocol
Wide Area Networking card in
drivers/net/wan/sdla*
But in Documentation/Configure.help under CONFIG_VENDOR_SANGOMA I only see
mention of the S502E(A), S503 and S508. These same cards are listed in
documentation/networking/framerelay.txt but not S514.
I can't find the 502 or 503 cards on http://www.sangoma.com so maybe they're
obsolete and while the 508 looks like a pretty good card, it's an ISA card and
I'd much rather use the 514 which is PCI. The PCI card is $579 and the ISA card
is $529 so you don't have to pay much extra to get a card that's going to be
better for your box's well-being.
I'm moving to the first house I've ever owned in my life (so I'll get to drill
holes in the walls) and the only affordable high-speed internet option there
which allows the subscriber to run their own servers and have multiple static IP
addresses is frame relay.
(You can also do synchronous PPP, HDLC and X.25 with these cards).
An advantage of using a WAN card over a dedicated router is:
- it's cheaper
- you get the source code
- you can combine the function of the router with other things like webservers
and firewalls (I was going to run a separate FRAD and firewall - $$$) You can
probably get dedicated routers with firewalls built in but you don't then have
the option of source code or, likely, timely notification from your vendors
about security holes.
- the WAN router is running on a box with lots of memory, hard disk, XWindows,
etc. Routers often run some kind of Unix as their OS but have very limited
resources for loading them up with fun diagnostic tools.
- you get to learn lots of interesting acronyms and enthrall your friends and
relatives with your knowledge of wide area networking protocols
- cool diagnostics by indicating link status, send and receive by lighting up
your keyboard LED's.
These folks at Sangoma seem like they're some pretty cool froods to be providing
specs and drivers for their cards which they appear to have kept supported over
an extended period of time so we should support their efforts by letting Linux
users know all the options for the hardware that helpful vendors such as these
sell.
My first thought, quite unfairly, was that Sangoma was only releasing the specs
for the older ISA cards and keeping the PCI specs a secret.
The following two passages from the WANPIPE user manual
(ftp://ftp.sangoma.com/documents/wanpipe.pdf) have me pretty convinced this is a
vendor worth looking into:
> Make sure your "other end" is set up correctly. Many third party routers
> default to proprietary, non standard protocols, while WANPIPE adheres strictly
> to Internet or IETF standards of encapsulation.
well that's pretty reasonable and what I'd expect but check this out:
> You will find these utilities will turn you into a WAN guru.
> You will always know more about the WAN connection than either the
> network provider or the third party at the other end.
Reminds me of the days when I used to call up Sun support and talk their
technicians through the process of giving me tech support. Not to mention
dealing with a typical ISP's tech support ("ifconfig? which version of Windows
are you running, anyway?")
Lotsa good linux WAN stuff at ftp://ftp.sangoma.com/linux
Clueless about frame relay? I was before this evening spent a-googling. These
two pages are helpful places to start:
The Frame Relay Forum
http://www.frforum.com
They have an intro book you can read online as HTML or download as PDF.
IBM Frame Relay Guide
http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/EZ305800/CCONTENTS
Pretty dry but quite informative.
the abovementioned wanpipe.pdf file has some pretty helpful introductory info it
too. There's also a document called WanpipeForLinux.pdf which is helpful. It's
available actually in both PDF and text format at
ftp://ftp.sangoma.com/linux/current_wanpipe/doc/
Now I just hope there's enough physical wires running into my house to _get_
frame relay. May have to send the telephone man on top of a pole to drop me a
line. How many wires into your building are required for frame relay to work?
Can't seem to find _that_ anywhere, and this house isn't exactly in a place
where the telco would have thought to plan for lots of extra capacity.
Mike
--
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]
Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0 - lseek on /proc broken? [with patch]
Hi:
After diging around for some problems (shutdown/unmount related) I found
that some processes where hidden from ps, pidoff, ls /proc, etc.
A strace reveled that:
open("/proc", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 7
fstat(7, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
fcntl(7, F_SETFD, FD_CLOEXEC) = 0
getdents(7, /* 58 entries */, 984) = 980
lseek(7, 265, SEEK_SET) = -1 EINVAL (Invalid argument)
So I change proc_root_operations to use proc_file_lseek and the problems
vanished.
Comments?
Salvador Ortiz.
please CCs to me.
=== cut ===
diff -u linux/fs/proc/generic.c linux-2.4.0-ac7/fs/proc/generic.c
--- linux/fs/proc/generic.c Mon Dec 11 15:45:42 2000
+++ linux-2.4.0-msg/fs/proc/generic.c Tue Jan 16 00:05:24 2001
@@ -22,7 +22,7 @@
size_t nbytes, loff_t *ppos);
static ssize_t proc_file_write(struct file * file, const char * buffer,
size_t count, loff_t *ppos);
-static loff_t proc_file_lseek(struct file *, loff_t, int);
+loff_t proc_file_lseek(struct file *, loff_t, int);
int proc_match(int len, const char *name,struct proc_dir_entry * de)
{
@@ -137,7 +137,7 @@
}
-static loff_t
+loff_t
proc_file_lseek(struct file * file, loff_t offset, int orig)
{
switch (orig) {
diff -u linux/fs/proc/root.c linux-2.4.0-ac7/fs/proc/root.c
--- linux/fs/proc/root.cThu Nov 23 11:07:36 2000
+++ linux-2.4.0-msg/fs/proc/root.c Tue Jan 16 00:05:27 2001
@@ -81,7 +81,9 @@
* directories. Thus we don't use the generic
* directory handling functions for that..
*/
+extern loff_t proc_file_lseek(struct file *, loff_t, int);
static struct file_operations proc_root_operations = {
+ llseek: proc_file_lseek,
read:generic_read_dir,
readdir: proc_root_readdir,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ip_conntrack: maximum limit of 16368 entries exceeded
Hello, I got this in my logs: ip_conntrack: maximum limit of 16368 entries exceeded what does this mean, I know i can change the limits in /proc/sys/net/ipv4/ip_conntrack_max, but I want to know what this is for. P.S. I looked into linux/Documentation but did not find any mention of this configrable parameter -- Rodel T. Viado System Administrator Iligan Global Access Network Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mmap()/VM problems in 2.4.0
Mike Galbraith wrote: > > On 15 Jan 2001, Zlatko Calusic wrote: > > > "Vlad Bolkhovitine" <[EMAIL PROTECTED]> writes: > > > > > Here is updated info for 2.4.1pre3: > > > > > > Size is MB, BlkSz is Bytes, Read, Write, and Seeks are MB/sec > > > > > > with mmap() > > > > > > File Block Num Seq ReadRand Read Seq Write Rand Write > > > DirSize SizeThr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) > > > --- -- --- --- --- --- --- --- > > >. 1024 40962 1.089 1.24% 0.235 0.45% 1.118 4.11% 0.616 1.41% > > > [...] > > > Mmap() performance dropped dramatically down to almost unusable level. Plus, > > > system was unusable during test: "vmstat 1" updated results every 1-2 _MINUTES_! > > > > > > > You need Marcelo's patch. Please apply and retest. > > My box thinks quite highly of that patch fwiw, but insists that he needs > to apply Jens Axboes' blk patch first ;-) (Not because of tiobench) New data: 2.4.1pre3 + Marcelo's patch File Block Num Seq ReadRand Read Seq Write Rand Write DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) --- -- --- --- --- --- --- --- . 1024 40962 12.68 9.23% 0.497 0.92% 10.57 15.3% 0.594 1.44% The same performance level as for 2.4.0. No improvement. 2.4.1pre3 + Marcelo's patch + Jens Axboes' blk-13B patch File Block Num Seq ReadRand Read Seq Write Rand Write DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) --- -- --- --- --- --- --- --- . 1024 40962 12.47 10.0% 0.504 1.13% 9.998 16.5% 0.735 2.21% No significant difference, just noise. IMHO, it is expected, since 2 threads simply aren't enough to launch blk patch's mechanisms > -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: int. assignment on SMP + ServerWorks chipset
> And if anybody else understands pirq routing, speak up. It's a black art. > I have some experience with PIRQ and Serverworks, but I missed the first bit of this discussion - can someone catch me up? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sendpath() support, 2.4.0-test3/-ac9
On Mon, 15 Jan 2001, dean gaudet wrote: > On Mon, 15 Jan 2001, Ingo Molnar wrote: > > > just for kicks i've implemented sendpath() support. > > > > _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) > > hey so how do you implement transmit timeouts with sendpath() ? (i.e. > drop the client after 30 seconds of no progress.) The whole "sendpath()" idea is just stupid. You want to do a non-blocking send, so that you don't block on the socket, and do some simple multiplexing in your server. And "sendpath()" cannot do that without having to look up the name again, and again, and again. Which makes the performance "optimization" a horrible pessimisation. Basically, sendpath() seems to be only useful for blocking and uninterruptible file sending. Bad design. I'm not touching it with a ten-foot pole. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Caches, page coloring, virtual indexed caches, and more
On Mon, Jan 15, 2001 at 10:16:57AM -0700, Eric W. Biederman wrote: > Heck if we wanted to we could even lie about PAGE_SIZE, and say it was huge. > I'd have to have a clear example before I give it up that easily. > mmap has never allowed totally arbitrary offsets, and mmap(MAP_FIXED) > is highly discouraged so I'd like to see it. > > And on architectures that don't need this it should compile out with > no overhead. > > > sysv shared memory is exactly the same as shared mmap. Except instead > > > of a file offset you have an offset into the sysv segment. > > > > No, it's simpler in the MIPS case. The ABI guys were nice and did define > > that the virtual addresses have to be multiple of 256kbyte which is > > more than sufficient to kill the problem. > > If VIRT_INDEX_BITS == 18 and because you can only map starting at > the beginning of a sysv shared memory segment this is exactly what > my code boils down to. > > > kmap is a little different. using VIRT_INDEX_BITS is a little > > > subtle but should work. Currently kmap is used only with the page > > > cache so we can take advantage of the page->index field. From > > > page->index we can compute the logical offset of the page and make > > > certain the page mapped with all VIRT_INDEX_BITS the same as a mmap > > > alias. > > > > Yup. It gets somewhat tricker due to the page cache being in in KSEG0, > > an memory area which is essentially like a 512mb page that is hardwired > > in the CPU. It's preferable to stick with since it means we never take > > any TLB faults for pages in the page cache on MIPS. > > Good. Then we don't need (at least for mips) to worry about this case. > I was just thinking through the general case. Not that good. Think of mmaping a file, then write(2)ing to it, then reading from it's mapping. Same for a mmap(2), read(2) sequence followed by a read from the memory. This might result in aliases between the page cache and the userspace. A solution would be to use a kmap mapping outside KSEG0 for accessing the pagecache of all data that is also mapped to userspace, if aliases might occur. > I totally agree. Larger pages don't suck but are unnecessary. At least > I haven't been convinced otherwise yet. The big iron guys actually love LARGE pages; I think IRIX on Origins uses something lie 64kb pages or so and may make use of even larger pages in it's page tables and mappings to get the TLB fault rate down. There are Usenix papers from HP and SGI about the issue; the performance increase they report for certain apps are impressive. > > If both mappings are immediately created accessible you'll directly endup > > with aliases. There is no choice, if the pagesize is only 4kb an R4x00 > > will create aliases in the case. Bad. > > If MAP_FIXED isn't being used, I allocate them 256K apart. (Totally legal) > If MAP_FIXED is being used I fail the second(legal), or I lie and say that > PAGE_SIZE is 256K while I'm at it, so it falls out naturally. MIPS ABI says larger page size is ok; it's just that on Linux a page size of only 4kb (and 8kb for Alpha) has been hardcoded in tons of places. Oh well, let's break what's broken. Luckily the IA64 guys are already doing alot of the required fixing. > > At least for sparc it's already supported. Right now I don't feel like > > looking into the 2.4 solution but checkout srmmu_vac_update_mmu_cache in > > the 2.2 kernel. > > Hmm. I see. At least as of 2.2.12 (most recent I have on hand) the idea > looks o.k. (Though the code itself looks broken). It's kind of an > expensive idea though. Indeed - which is why I never was able to get myself a barf bag and implement the same for MIPS ;-) > Even if we had reverse page tables, it's extra work every page fault. It's only going to impact pages which actually have aliases. IRIX for example uses a dual strategy. They don't restrict addresses for MAP_FIXED but try hard to use non-conflicting addresses whereever possible. The part with the reverse mappings which I just explained is only the last alternative when a user actualy enforced the creation of mappings at conflicting addresses. Jamie Lokier's posting already mentioned it - mapping the same address space twice as in the code snipet I gave is a nice way of implementing circular buffers; I've already seen such code ... on Intel boxen. > > Virtual aliases are the kind of harmful collision that must be avoid or > > data corruption will result. We just happen to be lucky that there are > > only very few applications which will actually suffer from this problem. > > (Which is why we don't handle it correctly for all MIPSes ...) > > Exactly. So we must handle this. If you could comment on which apps > break with my solution, I'd like to hear about it. The problem with simply ignoring the problem is that it results in silent data corruption. So even if your solution is breaking more code I like it more - a syscall error return is a obvious problem which applica
Re: [patch] sendpath() support, 2.4.0-test3/-ac9
On Mon, 15 Jan 2001, Ingo Molnar wrote: > just for kicks i've implemented sendpath() support. > > _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) hey so how do you implement transmit timeouts with sendpath() ? (i.e. drop the client after 30 seconds of no progress.) -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: int. assignment on SMP + ServerWorks chipset
On Mon, 15 Jan 2001, Dunlap, Randy wrote: > > Thanks for looking into this. I'll be out of touch for > the rest of this week, but Petr ([EMAIL PROTECTED]) > should be able to test patches that Ingo comes up with. > > > Ok. That means that the problem is that we _should_ look at > > the pirq table even if we use the IO-APIC. > > How do we know when to do this? It's kind of nasty. The IO-APIC detection will disable the pirq table stuff, see pci-irq.c: /* If we're using the I/O APIC, avoid using the PCI IRQ routing table */ if (io_apic_assign_pci_irqs) pirq_table = NULL; now, you could just remove that logic, but I suspect that you'd get problems simply because the interrupt will then get routing information, but either the IO-APIC re-naming logic has already moved the irq and it will be routed to the wrong entry. So what I _think_ is the correct change is to do roughly this in arch/i386/kernel/pci-irq.c: - in pcibios_fixup_irqs(), remove the #idef CONFIG_X86_IO_APIC ... #endif section entirely. - in pcibios_enable_irq(), at the _end_ (after having enabled the irq with "pcibios_lookup_irq(dev, 1)", do something like irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin); if (irq > 0) dev->irq = irq; and add a LOT of debug printk's, and enable DEBUG in pci-i386.h. It probably won't work on the first try (even if I explained the above well enough), so send me and Ingo dmesg output, and maybe we'll figure out something. And if anybody else understands pirq routing, speak up. It's a black art. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-pre7 build error.
On Monday 15 January 2001 20:00, Steven Cole wrote: > Got this for 2.4.1-pre7 > > make[2]: *** No rule to make target `/usr/src/linux/incl', needed by > `softirq.o'. Stop. > make[2]: *** Waiting for unfinished jobs > make[2]: Leaving directory `/usr/src/linux-2.4.1-pre7/kernel' > make[1]: *** [first_rule] Error 2 I have successfully built 2.4.1-pre7 and am now running same. I just finished rebuilding 2.4.1-pre7 using 2.4.1-pre7, so everything is looking fine now. I was incautiously running 2.4.1-pre5 with the newly integrated ReiserFS even though I knew that potential problems were being worked out. BTW, it looks like I get the same messages when shutting down 2.4.1-pre7 associated with having ReiserFS as the root filesystem. This was fixed with 2.4.0-ac1. The patch to fix this was posted to the reiserfs-list. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IDE not fully found (2.4.0)
On Mon, 15 Jan 2001, Tim Hockin wrote: > Just built a new system with Linux-2.4.0. > > Motherboard (MSI 694D-AR) has Via Apollo Pro chipset, those IDE drives seem > fine. Board also has a promise PDC20265 RAID/ATA100 controller. On each > channel of this controller I have an IBM 45 GB ATA100 drive as master. > (hde and hdg?). BIOS sees these drives fine. Linux only see hde and never > hdg (ide[012] but not ide3). I thought I'd post it here, in case anyone > else knew the answer right away. Ask AE...B > Second question: Does the RAID functionality of this device work under > linux? If so, is it better than LVM or MD? NO, frauds allowed (raid) > boot snippet: > --- > VP_IDE: IDE controller on PCI bus 00 dev 39 > VP_IDE: chipset revision 16 > VP_IDE: not 100% native mode: will probe irqs later > VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1 > ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio > PDC20265: IDE controller on PCI bus 00 dev 60 > PDC20265: chipset revision 2 > PDC20265: not 100% native mode: will probe irqs later > PDC20265: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER > Mode. > ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:pio, hdf:pio > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Latency: allowing resheduling while holding spin_locks
Roger Larsson wrote: > > On Sunday 14 January 2001 01:06, george anzinger wrote: > > Nigel Gamble wrote: > > > On Sat, 13 Jan 2001, Roger Larsson wrote: > > > > A rethinking of the rescheduling strategy... > > > > > > Actually, I think you have more-or-less described how successful > > > preemptible kernels have already been developed, given that your > > > "sleeping spin locks" are really just sleeping mutexes (or binary > > > semaphores). > > > > > > 1. Short critical regions are protected by spin_lock_irq(). The maximum > > > value of "short" is therefore bounded by the maximum time we are happy > > > to disable (local) interrupts - ideally ~100us. > > > > > > 2. Longer regions are protected by sleeping mutexes. > > > > > > 3. Algorithms are rearchitected until all of the highly contended locks > > > are of type 1, and only low contention locks are of type 2. > > > > > > This approach has the advantage that we don't need to use a no-preempt > > > count, and test it on exit from every spinlock to see if a preempting > > > interrupt that has caused a need_resched has occurred, since we won't > > > see the interrupt until it's safe to do the preemptive resched. > > > > I agree that this was true in days of yore. But these days the irq > > instructions introduce serialization points and, me thinks, may be much > > more time consuming than the "++, --, if (false)" that a preemption > > count implemtation introduces. Could some one with a knowledge of the > > hardware comment on this? > > > > I am not suggesting that the "++, --, if (false)" is faster than an > > interrupt, but that it is faster than cli, sti. Of course we are > > assuming that there is between the cli and the sti as there is > > between the ++ and the -- if (false). > > > > The problem with counting scheme is that you can not schedule inside any > spinlock - you have to split them up. Maybe you will have to do that anyway. > But if your RT process never needs more memory - it should be quite safe. > > The difference with a sleeping mutex is that it can be made lazier - keep it > in the runlist, there should be very few... > Nigel and I agree on the approach he has layed out with the possible exception of just how to handle the short spinlocks. It is agreed that we can not preempt a task that has a spinlock. He suggests that the overhead of testing for preemption on the exit of a spinlock protected with the preempt_count is higher than the cost of turning off and on the interrupt system. He may well be right, and surly was right 5 or 10 years ago. Today the cost of an cli or sti is much higher relative to the memory references, especially if we don't need to make the result visible to other processors (and we don't). We only have to serialize WRT our own interrupt system, but the interrupt itself will do this, and only when we need it. snip WRT your patch, A big problem with simple sleeping mutexes is that of priority inversion. An example: Given tasks L of low priority, M of medium, and H of high and X a mutex. If L is holding X when it is preempted by M and M wants to run a long time Then when H preempts M and trys to get X it will have to wait while M does his thing, just because L can not get the cycles needed to get out of X. A priority inherit mutex (pi_mutex) handles this by, when H trys to get X, boosting the priority of L (the holder of X) to its own priority until L releases X. At this point L reverts to its prior priority and H continues, now having suceeded in getting X. This is all complicated, of course, by remembering that a task can hold several mutexes at a time and each can have several waiters. >From a real time point of view, we would NEVER want to scan the task list looking for someone to wake up. We should know who to wake up from the getgo. Likewise, clutter in the run_list adds wasted cycles and cache lines to the schedule process. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386/setup.c cpuinfo notsc
Followup to: <[EMAIL PROTECTED]> By author:"Maciej W. Rozycki" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Mon, 15 Jan 2001, H. Peter Anvin wrote: > > > Right, but I'd also like to see the global flags exported explicitly to > > /proc/cpuinfo. > > That's desirable, but how would we fit it into the existing layout? I was thinking of having a global section at the top, without a "Processor:" header. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
up_read/up_write redefinitions in asm/semaphore.h and linux/usbdevice_fs.h
Hi,
I just asked on the linuxppc-dev list, but here is proably the better
place to ask.
We had a linuxppc_2_3 tree which had the #defines below disabled.
The fresh linuxppc_2_4 tree doesn't have it anymore.
The 2.4.0-ac9 patch has the current status of
linclude/asm-ppc/semaphore.h:
...
#define up_read(sem) \
do { \
unsigned long flags; \
\
CHECK_MAGIC((sem)->__magic); \
\
spin_lock_irqsave(&(sem)->lock, flags); \
if (!--(sem)->rd && waitqueue_active(&(sem)->wait)) \
wake_up(&(sem)->wait); \
spin_unlock_irqrestore(&(sem)->lock, flags); \
} while (0)
...
What needs to be changed, the ppc/semaphore.h file or the
linux/usbdevice_fs.h to avoid this conflict?
Gruss Olaf
- Forwarded message from Olaf Hering <[EMAIL PROTECTED]> -
Date: Tue, 16 Jan 2001 04:17:43 +0100
From: Olaf Hering <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: up_read/up_write redefinitions in asm/semaphore.h and linux/usbdevice_fs.h
Hi,
I have some redefinitions when I compile usbdevfs:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0.SuSE/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
-D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2
-Wno-uninitialized -mmultiple -mstring-c -o inode.o inode.c
In file included from inode.c:41:
/usr/src/linux-2.4.0.SuSE/include/linux/usbdevice_fs.h:173: warning:
`up_read' redefined
/usr/src/linux-2.4.0.SuSE/include/asm/semaphore.h:186: warning: this is
the location of the previous definition
/usr/src/linux-2.4.0.SuSE/include/linux/usbdevice_fs.h:174: warning:
`up_write' redefined
We had this patch in the linuxppc_2_3 tree:
diff -urN linux-2.4.0-ac4/include/linux/usbdevice_fs.h
linux-2.4.0-ac4-ppc/include/linux/usbdevice_fs.h
--- linux-2.4.0-ac4/include/linux/usbdevice_fs.hThu Jan 4
23:52:32 2001
+++ linux-2.4.0-ac4-ppc/include/linux/usbdevice_fs.hMon Jan 8
10:44:29 2001
@@ -166,13 +166,14 @@
* sigh. rwsemaphores do not (yet) work from modules
*/
+#if 0
#define rw_semaphore semaphore
#define init_rwsem init_MUTEX
#define down_read down
#define down_write down
#define up_read up
#define up_write up
-
+#endif
struct dev_state {
struct list_head list; /* state list */
It is gone in linuxppc_2_4 tree.
The USB layer should proably not use these generic names.
How can we fix that?
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
- End forwarded message -
--
--
$ man clone
BUGS
Main feature not yet implemented...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: pre5 VM feedback..
On 15 Jan 2001, Linus Torvalds wrote: > Now, I'm not saying your filesystem is toast. I'm just saying that if > you booted up in pre6, I'd suggest a quick reboot into a better kernel > might be a good idea (be a jock, and do a sync and just push the reset > button to force a proper fsck when it comes up - just in case). > > (And yes, I renamed the pre6's really quickly, so you had to be unlucky > to see them.) Alas, I was one of those poor saps who got his / filesystem mangled a bit by pre6. Luckly nothing too horrid happened...just /etc/inittab happened to not exist and other strangeness. At least I know I am not losing my mind now :) Aaron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
IDE not fully found (2.4.0)
Just built a new system with Linux-2.4.0. Motherboard (MSI 694D-AR) has Via Apollo Pro chipset, those IDE drives seem fine. Board also has a promise PDC20265 RAID/ATA100 controller. On each channel of this controller I have an IBM 45 GB ATA100 drive as master. (hde and hdg?). BIOS sees these drives fine. Linux only see hde and never hdg (ide[012] but not ide3). I thought I'd post it here, in case anyone else knew the answer right away. Second question: Does the RAID functionality of this device work under linux? If so, is it better than LVM or MD? boot snippet: --- VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1 ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode. ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:pio, hdf:pio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pre5 VM feedback..
In article <[EMAIL PROTECTED]>, Jeff Garzik <[EMAIL PROTECTED]> wrote: >Linus Torvalds wrote: >> In article <[EMAIL PROTECTED]>, >> Jeff Garzik <[EMAIL PROTECTED]> wrote: >> >$!@#@! pre6 is already out :) > >> Yes, and for heavens sake don't use it, [...] > >Too late... First and foremost, a correction: The VM data I posted was >for pre1, not pre5. Here is the VM data from a freshly rebooted pre6, >if that's worth anything: http://gtf.org/garzik/vm2/ > >Hopefully pre6 will survive long enough to complete tulip testing :) Careful, careful, careful. The problem is that pre6 survives quite nicely, but because of the silly typo in __mark_inode_dirty() it won't actually mark inodes dirty. Unless you are actually using the newly integrated raiser-fs, in which case you should be just peachy ;) Note that the bug is not even noticeable under many loads - especially if you have lots of memory. The inodes just get happily cached for a long time. Which is why I could release a pre6, not even noticing that it's strange and not writing out inode data to the disk. With a gig of RAM, inodes tend to cache really well. Now, I'm not saying your filesystem is toast. I'm just saying that if you booted up in pre6, I'd suggest a quick reboot into a better kernel might be a good idea (be a jock, and do a sync and just push the reset button to force a proper fsck when it comes up - just in case). (And yes, I renamed the pre6's really quickly, so you had to be unlucky to see them.) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pre5 VM feedback..
Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Jeff Garzik <[EMAIL PROTECTED]> wrote: > >$!@#@! pre6 is already out :) > Yes, and for heavens sake don't use it, [...] Too late... First and foremost, a correction: The VM data I posted was for pre1, not pre5. Here is the VM data from a freshly rebooted pre6, if that's worth anything: http://gtf.org/garzik/vm2/ Hopefully pre6 will survive long enough to complete tulip testing :) Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.1-pre7 build error.
Got this for 2.4.1-pre7 make[2]: *** No rule to make target `/usr/src/linux/incl', needed by `softirq.o'. Stop. make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/usr/src/linux-2.4.1-pre7/kernel' make[1]: *** [first_rule] Error 2 Waiting for 2.4.1-pre8. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pre5 VM feedback..
In article <[EMAIL PROTECTED]>, Jeff Garzik <[EMAIL PROTECTED]> wrote: >$!@#@! pre6 is already out :) Yes, and for heavens sake don't use it, because the reiserfs merge got some dirty inode logic wrong. pre7 fixes just that one line and should be ok again. >Anyway, this may be a totally subjective (and incorrect) perception, but >it seems to me like the recent 2.4.x-test kernels and thereafter start >swapping things out really quickly. Case in point: "diff -urN >linux.vanilla linux" command swaps out Konqueror and Netscape Mail, even >though I was using them only a few minutes ago. Yes. It's really nice for some stuff, but a bit too aggressive for normal use, I think. If you want to play with tuning, I'd suggest something like - make SWAP_SHIFT bigger (try with 7 instead of 5) - do the "self-swap-out" only for __GFP_VM allocations, and add the __GFP_VM flag to all page fault allocations (ie __GPF_VM would be a flag that says "this allocation will grow my RSS"). The latter is kind of debatable - some allocations can't easily be put in one category or the other (ie page cache growing - do we do it because of the page cache or because we want to map the page?) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-pre3 kernel oops from kmem_cache_create(...)
On Mon, Jan 15 2001, David Michael Norris wrote: > During boot of the 2.4.1-pre3 kernel, I received this oops: > > BUG() in slab.c:804 > EIP: 0010:[] > Code: 0f 0b 83 c4 0c 8b 1b 81 fb 7c 52 27 c0 75 c2 a1 7c 52 27 c0 module_init marks loop_init __init, and ll_rw_blk:blk_dev_init calls it too. So just remove the latter loop_init() call and it should be fine. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops with 4GB memory setting in 2.4.0 stable
On Mon, 15 Jan 2001 20:09:14 -0200 (BRST),
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
>On Tue, 16 Jan 2001, Rainer Mager wrote:
>>>EIP; f889e044<=
>Trace; f889d966
>
>It seems the oops is happening in a module's function.
>
>You have to make ksymoops parse the oops output against a System.map which
>has all modules symbols. Load each module by hand with the insmod -m
>option ("insmod -m module.o") and _append_ the outputs to System.map.
No need, just create directory /var/log/ksymoops. insmod and rmmod
will automatically save the list of modules and the symbol table on
every module load or unload, neatly timestamped. When you get an oops,
find the entries just before the oops and point ksymoops at those.
ksymoops -m /lib/modules/2.4.0/System.map \
-k /var/log/ksymoops/20010116093850.ksyms \
-l /var/log/ksymoops/20010116093850.modules < oops.txt
man insmod, section KSYMOOPS ASSISTANCE. Much easier than trying to
reproduce the environment by hand.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.1-pre3 kernel oops from kmem_cache_create(...)
During boot of the 2.4.1-pre3 kernel, I received this oops: BUG() in slab.c:804 EIP:0010:[] Code: 0f 0b 83 c4 0c 8b 1b 81 fb 7c 52 27 c0 75 c2 a1 7c 52 27 c0 ksymoops 2.3.5 on i586 2.4.1-pre2. Options used -V (default) -K (specified) -L (specified) -o /lib/modules/2.4.1-pre2/ (default) -m /usr/src/linux/System.map (default) No modules in ksyms, skipping objects EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Code: 0f 0b 83 c4 0c 8b 1b 81 fb 7c 52 27 c0 75 c2 a1 7c 52 27 c0 >>EIP; c01251df<= Code; c01251df <_EIP>: Code; c01251df<= 0: 0f 0b ud2a <= Code; c01251e1 2: 83 c4 0c add$0xc,%esp Code; c01251e4 5: 8b 1b mov(%ebx),%ebx Code; c01251e6 7: 81 fb 7c 52 27 c0 cmp$0xc027527c,%ebx Code; c01251ec d: 75 c2 jneffd1 <_EIP+0xffd1> c01251b0 Code; c01251ee f: a1 7c 52 27 c0mov0xc027527c,%eax I was running 2.4.1-pre3 with Axboe's loop-1 patch and the int-2.4.0.2 patch. And I first encountered this problem after applying the loop patch and it occurs every time I boot into this kernel. /proc/cpuinfo : processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 2 model name : Pentium 75 - 200 stepping: 5 cpu MHz : 75.002 fdiv_bug: no hlt_bug : no f00f_bug: yes coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 bogomips: 149.50 .config : # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set CONFIG_M586TSC=y # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_EISA=y # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Crypto options # CONFIG_CRYPTO=y CONFIG_CIPHERS=y CONFIG_CIPHER_AES=y # CONFIG_CIPHER_RIJNDAEL is not set # CONFIG_CIPHER_TWOFISH is not set # CONFIG_CIPHER_MARS is not set # CONFIG_CIPHER_RC6 is not set CONFIG_CIPHER_SERPENT=y # CONFIG_CIPHER_DFC is not set # CONFIG_CIPHER_BLOWFISH is not set # CONFIG_CIPHER_IDEA is not set # CONFIG_CIPHER_RC5 is not set # CONFIG_CIPHER_DES_EDE3 is not set # CONFIG_CIPHER_DES is not set # CONFIG_DIGEST is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_LOOP_DEP=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_GEN=y # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFI
delete object file
Hi, How do i remove an object file. Like if I have a "mparallel.o" file and need to remove and regenerate it. how do i do this if i may ask?. "/lib/modules/misc/mparallel.o". J _ 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] Please read the FAQ at http://www.tux.org/lkml/
pre5 VM feedback..
$!@#@! pre6 is already out :) Anyway, this may be a totally subjective (and incorrect) perception, but it seems to me like the recent 2.4.x-test kernels and thereafter start swapping things out really quickly. Case in point: "diff -urN linux.vanilla linux" command swaps out Konqueror and Netscape Mail, even though I was using them only a few minutes ago. Since hacking involves a lot of "run this command, then do something else until it finishes" :) my perception of the recent 2.4.x kernels is that my X apps are always getting swapped out just because a big diff or make was the only active process for ~5 minutes. Anyway, the hard data. The following is VM measurements taken during a diff of two kernel trees (2.4.1-pre4 and pre5, in fact): before diff --- ps aux: http://gtf.org/garzik/vm1/before.ps.txt meminfo: http://gtf.org/garzik/vm1/before.meminfo.txt after diff -- ps aux: http://gtf.org/garzik/vm1/after.ps.txt meminfo: http://gtf.org/garzik/vm1/after.meminfo.txt "vmstat 3" was running in the background during the diff. The following is the output from that. It should be noted that the final burst of swapping came from my switching X desktops, forcing Netscape and Konqueror to swap in. http://gtf.org/garzik/vm1/vmstat.log Obligatory dmesg output, which includes hardware info. Summary: Dual P-II w/ 128MB RAM http://gtf.org/garzik/vm1/after.dmesg.txt FWIW I am not attempting to imply that any particular conclusion should be drawn from this data. I just thought that the VM folks might find it interesting and/or useful. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Slot Number Question
On Tue, 16 Jan 2001, Dominik Kubla wrote: > On Mon, Jan 15, 2001 at 03:22:58PM -0500, Richard B. Johnson wrote: > > > > In any case, there is no way to correlate the device number with a > > PC connector slot just as there is no way to find out which of the > > 4 INT lines go to these connectors. The BIOS vendor only knows for > > sure, and since BIOSes are not updated as often as boards, even the > > BIOS is often incorrect. > > Well actually there seems to be a way to do this. Quoting "System Management > BIOS Reference Specification" v2.3.1 (p.51): > >3.3.10 System Slots (Type 9) > >The information in this structure defines the attributes of a system >slot. One structure is provided for each slot in the system. > > And later in table 3.3.10.5 (p.53): > >Identifies the value present in the Slot Number field of the PCI Interrupt >Routing Table entry that is associated with this slot, in offset 09h [...] > >Software can determine the PCI bus number and device associated with the >slot by matching the "Slot ID" to an entry in the routing table... and >ultimately determine what device is present in that slot. > > Right now Linux' SMBIOS implementation use only the first 3 tables to determine > the manufacturer of system and BIOS to blacklist known buggy APM/ACPI > implementations. Since i have the SMBIOS specs at hand i will have a lot. > Is there a PCI spec available on the net? www.pcisig.org asks for a password > when you try to download the specs... (don't you just love "secret" standards?) > > Yours, > Dominik Kubla > -- > Sign me! > Well yes and no. The problem is that the 'slot' is not the connector! It's easy to determine the slot to which they refer simply from the bits at <11:15>. However, applications are not supposed to do the port I/O to get this info, though. Instead, they are supposed to use BIOS32 or other provisions. All of the information necessary to observe/configure the bridge(s) is/are available from the two ports specified in the standard. Machines that don't have 'ports' emulate them (also in the standard) so that minimum changes are necessary. When a vendor puts a PCI Ethernet controller or a SCSI controller on the board (or both). Any notion of a slot referencing a card- connector goes out the window. Linux now provides a 'local' PCI database. However, if hot-swapping of PCI devices becomes a reality, this extra code may have limited utility. Nevertheless it is a good idea for fixed configurations that use modules because one doesn't run the risk of corrupting a running PCI bus to get the resource information necessary to install a new module. The invisibility of a physical connector may actually be good. This allows any PCI board to work in any PCI card-connector. Software that requires a particular card-connector is probably broken by design. If software needs someone to 'adjust' something on a particular board, hardware should provide an indication on the board (like a LED). --- Adjust the Contrabulator(tm) on the board with the flashing LED to obtain a pale blue flame... Press any key to test. RELEASE to DETONATE *** I have heard that there is a spec available on the Net . However, I just buy the latest books because the company has "plenty" of money and I like hard copies. Sombody else will probably tell you where. There is even a complete BIOS (several) on the Net. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Is anyone working on kernel support for IEEE-1355? -- http://www.1355.org/
It sounds like it might be useful in the embedded OS space. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FS corruption on 2.4.0-ac8
On Monday January 15, [EMAIL PROTECTED] wrote: > > > On Mon, 15 Jan 2001, Jure Pecar wrote: > > > > > There is something not that usual about my setup: i run raid1 /boot and > > raid5 root with one disk disconnected (its simply too loud...), so the > > array is in degraded mode all the time. Other hardware is more or less > > standard, p200 classic, 430vx board, adaptec2940u, 64mb ram. > > > > Is this a known problem? If it's not, please advise me on how to provide > > more usefull informations. > > Neil, > > This is the second report of corruption with RAID5. > > Do you know if any of your recent changes can be the reason? > Probably related. There is growing evidence of problems when accessing a degraded array, but I don't know if it is writing bad data, or reading incorrectly, or just getting the parity calculation wrong... I'll try to have a look, but with linux.conf.au coming up, it might not be very soon. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
a linux qos mailing list
Is there a linux qos mailing list? thanks, j.d. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FS corruption on 2.4.0-ac8
Jure, you write: > I was running 2.4.0test10pre5 happily for months and wanted to see how > things stand in the 'latest stuff'. Here's what i found: > > I compiled 2.4.0-ac8 with nearly the same .config as test10pre5 (with > latest gcc on rh7). Then i booted it and used X for some normal browsing > and mp3s. Performance was poor, responsivness also, even the mouse > stopped responding for a couple of seconds at a time, a lot of disk > trashing & so on. I deceided to boot test10 back, and there was a nasty > suprise: fsck found filesystem with errors, and LOTS of them ... i had > to hold down 'y' for almost 5 minutes ... :) > > Then i examined the logs for what would be the cause for this ... and > here's what 2.4.0-ac8 left in the logs: > > Jan 14 16:26:47 open kernel: ee_blocks: Freeing blocks not in datazone - > block = 979727457, count = 1 > Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): > ext2_free_blocks: Freeing blocks not in datazone - block = 1769096736, > count = 1 > Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): > ext2_free_blocks: Freeing blocks not in datazone - block = 842080300, > count = 1 > Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): > ext2_free_blocks: Freeing blocks not in datazone - block = 1851869728, > count = 1 > Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): > ext2_free_blocks: Freeing blocks not in datazone - block = 808464928, > count = 1 > ... > and so on for about 150 such lines in 3 seconds. These block numbers read as "ate: Fri, 12 Jan 200" (i.e. part of an email header) if you convert to 32-bit hex, then ascii. There was another report of corruption like this under 2.4.0 as well. > Is this a known problem? If it's not, please advise me on how to provide > more usefull informations. Actually, I thought there were problems in the test11? through test-13 kernels of this sort. I'm not sure exactly when it started, but a search of l-k should locate it. Depending on when last you fsck'd your filesystem, you may have already had some of these disk problems. However, there was another report recently on 2.4.0 that looked the same, and that user had just e2fsck'd his filesystem before booting 2.4.0 for the first time after running only 2.2, so it looks like a 2.4.0 bug. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Oops with 4GB memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Rainer Mager wrote: > Ok, now were making progress. I did as you said and have attached (really!) > the new parsed output. Now we have some useful information (I hope). I still > got lots of warnings on symbols (which I have edited out of the parsed file > for the sake of briefness). What's the next step? Wait for someone who has a clue about smbfs to find out the problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Oops with 4GB memory setting in 2.4.0 stable
Ok, now were making progress. I did as you said and have attached (really!)
the new parsed output. Now we have some useful information (I hope). I still
got lots of warnings on symbols (which I have edited out of the parsed file
for the sake of briefness). What's the next step?
--Rainer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marcelo Tosatti
> Sent: Tuesday, January 16, 2001 7:09 AM
> To: Rainer Mager
> Cc: [EMAIL PROTECTED]
> Subject: RE: Oops with 4GB memory setting in 2.4.0 stable
>
> >>EIP; f889e044<=
> Trace; f889d966
> Trace; c0140c10
> Trace; c0140e7c
> Trace; c0140f9e
> Trace; c0140e7c
>
> It seems the oops is happening in a module's function.
>
> You have to make ksymoops parse the oops output against a System.map which
> has all modules symbols. Load each module by hand with the insmod -m
> option ("insmod -m module.o") and _append_ the outputs to System.map.
>
> After that you can run ksymoops against this new System.map.
oops.parsed.edit
matroxfb on 2.4.0 / PCI: Failed to allocate...
Hi, all. I'm trying to get matroxfb running on a G400Max (dualhead). Of course, I have i2c bit-banging on and the relevant Matrox options turned on (as modules or compiled-in), and I don't see the expected `framebuffer: blah' after the `matroxfb: Matrox Millennium G400 MAX (AGP) detected'. I worry about some PCI initialization output (from dmesg): # PCI: Probing PCI hardware # Unknown bridge resource 0: assuming transparent # PCI: Using IRQ router VIA [1106/0686] at 00:07.0 # PCI: Cannot allocate resource region 0 of device 01:00.0 # PCI: Failed to allocate resource 0 for Matrox Graphics, Inc. MGA G400 AGP [...] That `device 01:00.0' is obviously the AGP MGA. 'dmesg' continues later with... # matroxfb: Matrox Millennium G400 MAX (AGP) detected # i2c-core.o: i2c core module # i2c-algo-bit.o: i2c bit algorithm module # i2c-core.o: driver maven registered. [...] ...and the loaded modules include... Module Size Used by matroxfb_crtc2 6928 0 (unused) matroxfb_maven 9552 0 (unused) i2c-matroxfb3632 0 (unused) i2c-algo-bit7392 0 [i2c-matroxfb] i2c-core 13072 0 [matroxfb_maven i2c-algo-bit] matroxfb_base 16848 0 [matroxfb_crtc2 i2c-matroxfb] matroxfb_DAC10645824 0 [matroxfb_crtc2 matroxfb_base] matroxfb_accel 8192 0 [matroxfb_crtc2 matroxfb_maven \ i2c-matroxfb matroxfb_base matroxfb_DAC1064] matroxfb_misc 13088 0 [matroxfb_crtc2 matroxfb_maven \ i2c-matroxfb matroxfb_base matroxfb_DAC1064 matroxfb_accel] agpgart13536 0 (unused) ...but... cmiller@canard:~$ cat /proc/fb cmiller@canard:~$ Ideas? Pointers? I'm available for questions and flames. - chad -- Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG) "Any technology distinguishable from magic is insufficiently advanced". First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: tcp no-ack bug can-rpt, w/script incl (this bugs 4 u)
> I have been trying to figure out > why linux tcp is failing to ack > properly in some situations. This is exactly the same problem I'm seeing with a Solaris box talking to my Linux box. It has a similar problem with Linux as well, but does not manifest as bad against a 2.2 kernel machine. Seems I was chasing down the wrong path with MSS and MTU strangeness, I tested this with ethereal as soon as I saw your post. No help from me, I'm afraid, but I can at least verify that you are not the only one seeing it. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Oops with 4GB memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Rainer Mager wrote:
> I knew that, I was just testing you all. ;-)
>>EIP; f889e044<=
Trace; f889d966
Trace; c0140c10
Trace; c0140e7c
Trace; c0140f9e
Trace; c0140e7c
It seems the oops is happening in a module's function.
You have to make ksymoops parse the oops output against a System.map which
has all modules symbols. Load each module by hand with the insmod -m
option ("insmod -m module.o") and _append_ the outputs to System.map.
After that you can run ksymoops against this new System.map.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Mon, 15 Jan 2001, Albert Cranford wrote:
> I have a working PA-2007 but use a small hard disk. Can I help.
[...]
> Detected 239.833 MHz processor.
[...]
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[...]
> hda: WDC AC2540F, ATA DISK drive
> hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
> hda: set_drive_speed_status: error=0x04 { DriveStatusError }
> hda: 1056384 sectors (541 MB) w/64KiB Cache, CHS=524/32/63, DMA
I have a FIC PA-2007 (the older one, with a 586A bridge instead of the 586B
of later FIC PA-2007 boards), running at 75MHz FSB (PCI bus runs at 37.5MHz,
so I suppose I should use idebus=37.5 if I were to try 2.4.x), and a Quantum
Fireball lct15 30MB.
It works flawlessly in UDMA mode 2 (although I have to force the drive to
UDMA mode 2 with -X66 before enabling dma, because the bogus beta BIOS I use
sets it to UDMA4 which is not supported by the 586A). Kernel is 2.2.18,
without the 2.4.x ide backport.
The lspci output is exactly the same as yours.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Oops with 4GB memory setting in 2.4.0 stable
I knew that, I was just testing you all. ;-)
\e hides his head in shame
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marcelo Tosatti
> Sent: Tuesday, January 16, 2001 6:47 AM
> To: Rainer Mager
> Cc: [EMAIL PROTECTED]
> Subject: Re: Oops with 4GB memory setting in 2.4.0 stable
>
>
>
>
> On Tue, 16 Jan 2001, Rainer Mager wrote:
>
> > Attached is my oops.txt and the result sent through
> ksymoops. The results
> > don't look particularly useful to me so perhaps I'm doing
> something wrong.
> > PLEASE tell me if I should parse this differently. Likewise, if there is
> > anything else I can do to help debug this, please tell me.
>
> It seems you forgot to attach oops.txt.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
oops.parsed
Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
f889e044
*pde =
Oops: 0002
CPU:1
EIP:0010:[]
EFLAGS: 00010246
eax: ebx: d5762800 ecx: 0400 edx: c19665fc
esi: d55be120 edi: ebp: d5764260 esp: d5505f1c
ds: 0018 es: 0018 ss: 0018
Process ls (pid: 865, stackpage=d5505000)
Stack: d5762800 d55be120 d5764260 d5764260 d55be120 f889d966 d55be120
d5762800 d5504000 d5764260 fffe fffb d5762800 d5764260 d55be120
d5764260 ba40 0006 c0140c10 d5764260 d5505fb0 c0140e7c
Call Trace: [] [] [] [] []
[]
Code: f3 ab e9 8b 00 00 00 90 8d 74 26 00 8b 44 24 14 c7 00 00 00
Segmentation fault
Re: MTRR type AMD Duron/intel ?
David Balazic <[EMAIL PROTECTED]> writes: > A recent 2.4.0 ( not the final , but close ) kernel prints this : > > mtrr: detected mtrr type: intel > > I have an AMD K7 Duron 700 CPU > > Is this correct ? Yes. The K7 supports MTRRs exactly according to the Intel specs, as opposed to the MTRR-like but somewhat different features that some other x86 CPUs implement. So while it may appear odd, it is correct. David Wragg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops with 4GB memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Rainer Mager wrote: > Attached is my oops.txt and the result sent through ksymoops. The results > don't look particularly useful to me so perhaps I'm doing something wrong. > PLEASE tell me if I should parse this differently. Likewise, if there is > anything else I can do to help debug this, please tell me. It seems you forgot to attach oops.txt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
tcp no-ack bug can-rpt, w/script incl (this bugs 4 u)
Tcp developers: (Alan Cox: you probably could fix in a minute)
I've been told that this is THE PLACE to contact
linux kernel developers. Ok, I've got a repeatable
bug that I've reported elsewhere to no avail. Hope
this is the place:
Includes 2 perl scripts to reproduce it and info about what
I see not working with tcpdump traces.
(i'm not a subscriber - to reach me use my email address)
thnx
et
from my prior posts:
Hi:
I have been trying to figure out
why linux tcp is failing to ack
properly in some situations.
I can easily reproduce this error
using 2 perl scripts. (see below) I
create a socket server in one
script, a client in another, start
sending, suspend the receiver and
wait 4 minutes. The socket will get
disconnected. It should not do
this, it should send an ack with a
window of 0, which it fails to do.
Both the client and the server can
be on the same system to easily see
the error.
To any developer who might be
listening - please help me find and
fix this problem.
Thanks
Eric
debugging info follows --
If I run the client from a windows
system, linux behaves properly,
sending acks/window 0, and when I
unsuspend the receiver, all
re-starts up in a few seconds.
When going linux to linux, it fails
almost always. When it does fail, I
see the sender trying to send a
large block (1-2k bytes) and when
no ack comes back the sender goes
into it's retransmit loop waiting
1,2,4... seconds. I also see the
retransmit count going up with:
/proc/net/tcp
When it fails, the last ack sent
back shows a window size of more
than 15000. Here is a sample:
21:48:23.376528 lo > 127.0.0.1.5000 > 127.0.0.1.1052: . 1:1(0) ack 1255213 win 18158
(DF)
21:48:23.379304 lo > 127.0.0.1.1052 > 127.0.0.1.5000: P 1255213:1255256(43) ack 1
win 31072 (DF)
21:48:23.384049 lo > 127.0.0.1.1052 > 127.0.0.1.5000: P 1255256:1257234(1978) ack 1
win 31072 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5444248 win 11616
(DF)
22:13:34.161979 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5451992 win 7744
(DF)
22:13:34.162322 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5459736 win 3872
(DF)
22:13:34.162553 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5463608 win 3872
(DF)
22:13:34.179785 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5467480 win 0
(DF)
22:13:34.379759 lo > 127.0.0.1.1053 > 127.0.0.1.5000: . 5467479:5467479(0) ack 1 win
31072 (DF)
22:13:34.379856 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5467480 win 0
(DF)
22:13:34.779762 lo > 127.0.0.1.1053 > 127.0.0.1.5000: . 5467479:5467479(0) ack 1 win
31072 (DF)
22:13:34.779852 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5467480 win 0
(DF)
22:13:35.579755 lo > 127.0.0.1.1053 > 127.0.0.1.5000: . 5467479:5467479(0) ack 1 win
31072 (DF)
22:13:35.579842 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5467480 win 0
(DF)
server resumed here.
22:18:33.572608 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5467480 win 3872
(DF)
22:18:33.572714 lo > 127.0.0.1.1053 > 127.0.0.1.5000: P 5467480:5471352(3872) ack 1
win 31072 (DF)
22:18:33.572910 lo > 127.0.0.1.5000 > 127.0.0.1.1053: . 1:1(0) ack 5471352 win 3872
(DF)
22:18:33.573007 lo > 127.0.0.1.1053 > 127.0.0.1.5000: P 5471352:5475224(3872) ack 1
win 31072 From two terminal windows:
>perl badserver.pl 5000
>perl badclient.pl
You will see for the server (hit control-z):
[1028]$ perl badserver.pl 5000
waiting for connection on port 5000
accept connection from 127.0.0.1, 1052
hello there /badclient.pl/ // // 1
hello there /badclient.pl/ // // 1001
hello there /badclient.pl/ // // 2001
hello there /badclient.pl/ // // 3001
---type control z ---
[1]+ Stopped perl badserver.pl 5000
You will see nothing for the client.
---badclient.pl
use IO::Socket;
$client = IO::Socket::INET->new("localhost:5000") or die $@;
$a = shift;
$b = shift;
$i=1;
while(1) {
print $client "hello there /$0/ /$a/ /$b/ $i\n";
$i++;
}
close($client);
---badserver.pl---
use IO::Socket;
use Socket;
$port = shift or die "usage: perl server port_number\n";
$server = IO::Socket::INET->new(
LocalPort =>$port,
Type => SOCK_STREAM,
Reuse=> 1,
Listen=> 10,
)
or die "cannot create server : $@\n";
print "waiting for connection on port $port\n";
while ($client = $server->accept()) {
$other = getpeername($client) or die "cannot get peer $!\n";
($port,$iaddr) = unpack_sockaddr_in($other);
$ip_addr = inet_ntoa($iaddr);
print "accept connection from $ip_addr, $port\n";
$i=0;
while( $_ = <$client> ) {
if($i%1000 == 0){print $_;}
$i++;
}
print "done with this connection\n";
}
close($server);
-
Re: Problems with bigblock support of fat
On Mon, 15 Jan 2001, Robert Reither wrote:
> I encounted really bad problems with 2048 Bytes/sec MO-Drive.
> I'm using an Olympus PowerMO 640.
> MO was formated with FAT32.
>
> i try to read a file from it (used : 'pico /mo/file.txt') ...
> And got a nice crash : Segmentation Fault
Even worse. Trying to read any file on a 2k hwblk FAT yields an oops
actually.
> OK, was easy to find this bug, fs/fat/cvf.c has a bug in bigblock_cvf struct
> the field with the read function was a NULL.
> I changed this to generic_file_read (like with default blocksize), and
> tested it. First seemed to work fine, but :
>
> If i write a file to an empty MO-Disk, the start-cluster is 2 in the
> table. But the real data was written to (and also read from)
> cluster 33 by linux !
The generic routines do not handle the (rather braindead) case of
hwblksize > logical blksize. FAT uses a logical block (sector/whatever
you like to name it) size of 512 byte, which obviously sucks. Now,
generic_file_read miscalculates the blocks it has to get, but in the same
way as generic_file_write, so two errors yield a working setup, but only
for data you wrote with a buggy kernel. You won't be able to access any
previously written data in this way.
A few days ago, I posted the below patch as a quick band-aid to get at
least the read() part back to a working state again. It also disables the
equally dysfunctional mmap() on 2k media. It ought to disable write() as
well, but I didn't bother. Just don't do it. It's probably best to use the
patch to backup your data and reformat your MOs with a sane fs. Run, don't
walk. ;-)
Regards,
Daniel.
--[snip]--
--- cvf.c.vanilla Mon Jan 1 22:46:20 2001
+++ cvf.c Mon Jan 1 23:31:23 2001
@@ -51,6 +51,9 @@
const char *buf,
size_t count,
loff_t *ppos);
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos);
+
struct cvf_format default_cvf = {
0, /* version - who cares? */
@@ -92,7 +95,7 @@
default_fat_access,
NULL,
default_fat_bmap,
- NULL,
+ bigblock_fat_file_read,
default_fat_file_write,
NULL,
NULL
--- file.c.vanilla Mon Jan 1 22:46:26 2001
+++ file.c Tue Jan 16 00:15:16 2001
@@ -4,6 +4,9 @@
* Written 1992,1993 by Werner Almesberger
*
* regular file handling primitives for fat-based filesystems
+ *
+ * 2001-1-1 Daniel Kobras <[EMAIL PROTECTED]>:
+ * Added quick&dirty read operation for large sector media.
*/
#define ASC_LINUX_VERSION(V, P, S) (((V) * 65536) + ((P) * 256) + (S))
@@ -114,6 +117,56 @@
return retval;
}
+/* This is a hack. No readahead and other fancy stuff, but hopefully enough
+ * to get MOs working again. [dk]
+ * FIXME: Not sure whether I got error checking right.
+ */
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos)
+{
+ struct inode *inode = filp->f_dentry->d_inode;
+ int phys, pos;
+ struct buffer_head *bh;
+ size_t to_go, done;
+ char *buf_start = buf;
+
+ /* Taken from 2.2 source. */
+ if (!S_ISREG(inode->i_mode) && !S_ISLNK(inode->i_mode))
+ return -EINVAL;
+
+ if (*ppos > inode->i_size || !count)
+ return 0;
+
+ if (inode->i_size - *ppos < count)
+ count = inode->i_size - *ppos;
+
+ pos = *ppos>>SECTOR_BITS;
+ to_go = SECTOR_SIZE - (*ppos&(SECTOR_SIZE-1));
+ goto _start;
+
+ do {
+ to_go = SECTOR_SIZE;
+_start:
+ phys = fat_bmap(inode, pos++);
+ if (!phys)
+ return -EIO;
+ bh = fat_bread(inode->i_sb, phys);
+ if (!bh)
+ return -EIO;
+ done = to_go > count ? count : to_go;
+ if (copy_to_user(buf, bh->b_data, done)) {
+ fat_brelse(inode->i_sb, bh);
+ return -EFAULT;
+ }
+ fat_brelse(inode->i_sb, bh);
+ buf += done;
+ *ppos += done;
+ } while ((count -= done));
+
+ return buf - buf_start;
+}
+
+
void fat_truncate(struct inode *inode)
{
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
--- inode.c.vanilla Tue Jan 2 00:36:18 2001
+++ inode.c Tue Jan 2 00:22:04 2001
@@ -820,6 +820,9 @@
inode->i_size = CF_LE_L(de->size);
inode->i_op = &fat_file_inode_operations;
inode->i_fop = &fat_file_operations;
+ /* FIXME: mmap is broken with large hwblocks! [dk] */
+ if (sb->s_blocksize > 512)
+ inode->i_fop->mmap = NULL;
inode->i_mapping->a_ops = &fat_aops;
MSDOS_I(inode)->mmu_private = inode->i_size;
}
-
To unsubscribe from this list: send the
Oops with 4GB memory setting in 2.4.0 stable
Hi all, I have a 100% reproducable bug in all of the 2.4.0 kernels including the latest stable one. The issue is that if I compile the kernel to support 4GB RAM (I have 1 GB) and then try to access a samba mount I get an oops. This ALWAYS happens. Usually after this the system is frozen (although the magic SYSREQ still works). If the system isn't frozen then any commands that access the disk will freeze. Fortunately GPM worked and I was able to paste the oops to a file via telnet. Attached is my oops.txt and the result sent through ksymoops. The results don't look particularly useful to me so perhaps I'm doing something wrong. PLEASE tell me if I should parse this differently. Likewise, if there is anything else I can do to help debug this, please tell me. --Rainer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Initio 9x00 SCSI driver status
I've been doing some work on the Initio 9100UW SCSI driver that is distributed with 2.4.0. I've fixed a couple of bugs and added /proc support to my copy of the source. Is there an active maintainer of this driver at present? Is there anything that tells what to do to add support for the new error handling code so it doesn't use scsi_old.c any more? I'm reading this via fa.linux.kernel so should pick up replies that way but email is fine too. Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops in 2.4.0 (fs corruption?)
Hi all, I have been running 2.4.0 for 8 days with no problem. Then standard RedHat cron job (slocate.cron) generated an oops: ksymoops 2.3.4 on i686 2.4.0. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0/ (default) -m /usr/src/linux/System.map (specified) Jan 15 04:02:06 cs865114-a kernel: Unable to handle kernel paging request at virtual address 4029e934 Jan 15 04:02:06 cs865114-a kernel: c0136f40 Jan 15 04:02:06 cs865114-a kernel: *pde = 03ede067 Jan 15 04:02:06 cs865114-a kernel: Oops: Jan 15 04:02:06 cs865114-a kernel: CPU:0 Jan 15 04:02:07 cs865114-a kernel: EIP:0010:[sys_newlstat+48/112] Jan 15 04:02:07 cs865114-a kernel: EFLAGS: 00010206 Jan 15 04:02:07 cs865114-a kernel: eax: 4029e900 ebx: c543bfa4 ecx: c9e2f920 edx: cebc98c0 Jan 15 04:02:07 cs865114-a kernel: esi: edi: 080662cc ebp: bae4 esp: c543bf9c Jan 15 04:02:07 cs865114-a kernel: ds: 0018 es: 0018 ss: 0018 Jan 15 04:02:07 cs865114-a kernel: Process slocate (pid: 22482, stackpage=c543b000) Jan 15 04:02:07 cs865114-a kernel: Stack: c543a000 080662d4 cebc98c0 cff36d40 0008 b25c b24c 0008 Jan 15 04:02:07 cs865114-a kernel:0001 c0108d63 080662cc baa4 0805dbc0 080662d4 080662cc bae4 Jan 15 04:02:07 cs865114-a kernel:006b 002b 002b 006b 400b21fd 0023 0202 ba88 Jan 15 04:02:07 cs865114-a kernel: Call Trace: [system_call+51/56] Jan 15 04:02:07 cs865114-a kernel: Code: 8b 40 34 85 c0 74 0a 52 ff d0 89 c6 83 c4 04 eb 02 31 f6 85 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 8b 40 34 mov0x34(%eax),%eax Code; 0003 Before first symbol 3: 85 c0 test %eax,%eax Code; 0005 Before first symbol 5: 74 0a je 11 <_EIP+0x11> 0011 Before first symbol Code; 0007 Before first symbol 7: 52push %edx Code; 0008 Before first symbol 8: ff d0 call *%eax Code; 000a Before first symbol a: 89 c6 mov%eax,%esi Code; 000c Before first symbol c: 83 c4 04 add$0x4,%esp Code; 000f Before first symbol f: eb 02 jmp13 <_EIP+0x13> 0013 Before first symbol Code; 0011 Before first symbol 11: 31 f6 xor%esi,%esi Code; 0013 Before first symbol 13: 85 00 test %eax,(%eax) === I tried to figure out what was the proble, and it looks like some sort of filesystem corruption in /dev/ida subdir. When I did 'ls /dev/ida' I somewhat similar oops: === ksymoops 2.3.4 on i686 2.4.0. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0/ (default) -m /usr/src/linux/System.map (specified) Jan 15 06:30:21 cs865114-a kernel: Unable to handle kernel paging request at virtual address 4029e934 Jan 15 06:30:21 cs865114-a kernel: c01372c0 Jan 15 06:30:21 cs865114-a kernel: *pde = 03151067 Jan 15 06:30:21 cs865114-a kernel: Oops: Jan 15 06:30:21 cs865114-a kernel: CPU:0 Jan 15 06:30:21 cs865114-a kernel: EIP:0010:[sys_lstat64+48/112] Jan 15 06:30:21 cs865114-a kernel: EFLAGS: 00010206 Jan 15 06:30:21 cs865114-a kernel: eax: 4029e900 ebx: c1e17fa4 ecx: c9e2f920 edx: cebc98c0 Jan 15 06:30:21 cs865114-a kernel: esi: edi: b8cc ebp: b8b4 esp: c1e17f9c Jan 15 06:30:21 cs865114-a kernel: ds: 0018 es: 0018 ss: 0018 Jan 15 06:30:21 cs865114-a kernel: Process ls (pid: 22596, stackpage=c1e17000) Jan 15 06:30:21 cs865114-a kernel: Stack: c1e16000 40107bec cebc98c0 cff36d40 0003 b46c b45c 0008 Jan 15 06:30:21 cs865114-a kernel:0001 c0108d63 b8cc 4013de70 40104420 40107bec b8cc b8b4 Jan 15 06:30:21 cs865114-a kernel:00c4 002b 002b 00c4 400b66ac 0023 0212 b858 Jan 15 06:30:21 cs865114-a kernel: Call Trace: [system_call+51/56] Jan 15 06:30:21 cs865114-a kernel: Code: 8b 40 34 85 c0 74 0a 52 ff d0 89 c6 83 c4 04 eb 02 31 f6 85 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 8b 40 34 mov0x34(%eax),%eax Code; 0003 Before first symbol 3: 85 c0 test %eax,%eax Code; 0005 Before first symbol 5: 74 0a je 11 <_EIP+0x11> 0011 Before first symbol Code; 0007 Bef
Re: FS corruption on 2.4.0-ac8
On Mon, 15 Jan 2001, Jure Pecar wrote: > Hi all, > > I was running 2.4.0test10pre5 happily for months and wanted to see how > things stand in the 'latest stuff'. Here's what i found: > > I compiled 2.4.0-ac8 with nearly the same .config as test10pre5 (with > latest gcc on rh7). Then i booted it and used X for some normal browsing > and mp3s. Performance was poor, responsivness also, even the mouse > stopped responding for a couple of seconds at a time, a lot of disk > trashing & so on. I deceided to boot test10 back, and there was a nasty > suprise: fsck found filesystem with errors, and LOTS of them ... i had > to hold down 'y' for almost 5 minutes ... :) > > Then i examined the logs for what would be the cause for this ... and > here's what 2.4.0-ac8 left in the logs: > > Jan 14 16:26:47 open kernel: ee_blocks: Freeing blocks not in datazone - > block = 979727457, count = 1 > Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): > ext2_free_blocks: Freeing blocks not in datazone - block = 1769096736, > count = 1 > Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): > ext2_free_blocks: Freeing blocks not in datazone - block = 842080300, > count = 1 > Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): > ext2_free_blocks: Freeing blocks not in datazone - block = 1851869728, > count = 1 > Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): > ext2_free_blocks: Freeing blocks not in datazone - block = 808464928, > count = 1 > ... > and so on for about 150 such lines in 3 seconds. > > There is something not that usual about my setup: i run raid1 /boot and > raid5 root with one disk disconnected (its simply too loud...), so the > array is in degraded mode all the time. Other hardware is more or less > standard, p200 classic, 430vx board, adaptec2940u, 64mb ram. > > Is this a known problem? If it's not, please advise me on how to provide > more usefull informations. Neil, This is the second report of corruption with RAID5. Do you know if any of your recent changes can be the reason? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
FS corruption on 2.4.0-ac8
Hi all, I was running 2.4.0test10pre5 happily for months and wanted to see how things stand in the 'latest stuff'. Here's what i found: I compiled 2.4.0-ac8 with nearly the same .config as test10pre5 (with latest gcc on rh7). Then i booted it and used X for some normal browsing and mp3s. Performance was poor, responsivness also, even the mouse stopped responding for a couple of seconds at a time, a lot of disk trashing & so on. I deceided to boot test10 back, and there was a nasty suprise: fsck found filesystem with errors, and LOTS of them ... i had to hold down 'y' for almost 5 minutes ... :) Then i examined the logs for what would be the cause for this ... and here's what 2.4.0-ac8 left in the logs: Jan 14 16:26:47 open kernel: ee_blocks: Freeing blocks not in datazone - block = 979727457, count = 1 Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): ext2_free_blocks: Freeing blocks not in datazone - block = 1769096736, count = 1 Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): ext2_free_blocks: Freeing blocks not in datazone - block = 842080300, count = 1 Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): ext2_free_blocks: Freeing blocks not in datazone - block = 1851869728, count = 1 Jan 14 16:26:47 open kernel: EXT2-fs error (device md(9,1)): ext2_free_blocks: Freeing blocks not in datazone - block = 808464928, count = 1 ... and so on for about 150 such lines in 3 seconds. There is something not that usual about my setup: i run raid1 /boot and raid5 root with one disk disconnected (its simply too loud...), so the array is in degraded mode all the time. Other hardware is more or less standard, p200 classic, 430vx board, adaptec2940u, 64mb ram. Is this a known problem? If it's not, please advise me on how to provide more usefull informations. -- Jure Pecar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 4G SGI quad Xeon - memory-related slowdowns
On 15 Jan 2001, Linus Torvalds wrote: > The performance problem is _probably_ due to the kernel having to > double-buffer the IO requests, coupled with bad MTRR settings (ie > memory above the 4GB range is probably marked as non-cacheable or > something, which means that you'll get really bad performance). the highmem related double-buffering alone on such a category of system is miniscule, compared to other costs of IO, and considering the expected bandwidth (20-30 MB/sec). the MTRR part could be a problem. > Not using the high memory will avoid the double-buffering, and will > also avoid using memory that isn't cached. If I'm right. > The hang still indicates that something is wrong in PAE-land, though. it's working just fine on all 4GB+ systems tested (including 32GB systems), Intel, Dell, Compaq boxes. So if it's a unique PAE bug, then it must be some boundary condition. Paul, here is the memory map of my 8GB system: BIOS-provided physical RAM map: BIOS-e820: 0009d400 @ (usable) BIOS-e820: 2c00 @ 0009d400 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 03ef8000 @ 0010 (usable) BIOS-e820: 7c00 @ 03ff8000 (ACPI data) BIOS-e820: 0400 @ 03fffc00 (ACPI NVS) BIOS-e820: ec00 @ 0400 (usable) BIOS-e820: 0140 @ fec0 (reserved) BIOS-e820: f000 @ 0001 (usable) and here are the MTRR settings: [root@m mingo]# cat /proc/mtrr reg00: base=0xf000 (3840MB), size= 256MB: uncachable, count=1 reg01: base=0x ( 0MB), size=4096MB: write-back, count=1 reg02: base=0x1 (4096MB), size=2048MB: write-back, count=1 reg03: base=0x18000 (6144MB), size=1024MB: write-back, count=1 reg04: base=0x1c000 (7168MB), size= 512MB: write-back, count=1 reg05: base=0x1e000 (7680MB), size= 256MB: write-back, count=1 i'd suggest using the mem=exact feature to force different type of memory maps. Eg. i'm using the following append= line to force a 800 MB setup: append="mem=exactmap mem=0x0009d800@0x mem=0x03ef8000@0x0010 mem=0x2bffe000@0x0400" such mem=exactmap lines can be constructed based on the BIOS output. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Bug in swapfs (2.4.0-ac9)
I think I've found a bug in swapfs: fstab: swapfs /dev/shmswapfs defaults 0 0 swapfs /tmpswapfs defaults 0 0 When I hit on a tar.gz file in Midnight Commander nothing happens. If I do a umonut /tmp and hit again it works as It should (I see the archived files). Nearly the same Problem with the Acrobat Reader pluin for Netscape. It shows only a blank page when /tmp is swapfs. I've noticed that it's possible to mount /tmp more than once. mount shows then [snip] swapfs on /dev/shm type swapfs (rw) swapfs on /tmp type swapfs (rw) swapfs on /tmp type swapfs (rw) swapfs on /tmp type swapfs (rw) swapfs on /tmp type swapfs (rw) The permissions for /tmp are rwxrwxrwt, and even -omode=777,exec didn't help. Any Ideas? -Gregor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ipppd == pppd? (was: Re: New features in Linux 2.4 - WonderfulWor...)
On 13 Jan 2001, Kai Henningsen wrote: > [EMAIL PROTECTED] (Joe Pranevich) wrote on 06.01.01 in ><[EMAIL PROTECTED]>: > > >much of the code, including a long awaited combination of the PPP > >layers from the ISDN layer and the serial device PPP layer, such as > > I've heard about that before, but I can find no hint about that in > Documentation/. The separate ipppd is still mentioned there. > > Plus, looking at the ISDN PPP sources also gives no hint. > > What's up? This info is just plain wrong. Unfortunately, ISDN syncPPP isn't using the generic PPP layer yet. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bug (isdn-subsystem?) in 2.4.0
On Mon, 15 Jan 2001, Ronny Buchmann wrote:
> i have the following problem with kernel 2.4.0 (also with -ac6):
>
> kernel BUG at slab.c:1095!
> invalid operand:
> CPU: 0
I could reproduce the problem, the appended patch fixes it here. Linus,
could you please apply this for 2.4.1?
> ..
>
> (if you need the other numbers or anything else, ask me, i can reproduce
> it easily)
A decoded oops would be nice the next time, see
/REPORTING-BUGS
However, you gave enough information for me to reproduce the problem, so
it's fine this time.
Thanks,
--Kai
--- linux-2.4.1-pre2/drivers/isdn/isdn_v110.c% Sun Aug 6 21:43:42 2000
+++ linux-2.4.1-pre2/drivers/isdn/isdn_v110.c Mon Jan 15 22:31:43 2001
@@ -102,7 +102,7 @@
int i;
isdn_v110_stream *v;
- if ((v = kmalloc(sizeof(isdn_v110_stream), GFP_KERNEL)) == NULL)
+ if ((v = kmalloc(sizeof(isdn_v110_stream), GFP_ATOMIC)) == NULL)
return NULL;
memset(v, 0, sizeof(isdn_v110_stream));
v->key = key;
@@ -134,7 +134,7 @@
v->b = 0;
v->skbres = hdrlen;
v->maxsize = maxsize - hdrlen;
- if ((v->encodebuf = kmalloc(maxsize, GFP_KERNEL)) == NULL) {
+ if ((v->encodebuf = kmalloc(maxsize, GFP_ATOMIC)) == NULL) {
kfree(v);
return NULL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Latency: allowing resheduling while holding spin_locks
On Sunday 14 January 2001 01:06, george anzinger wrote:
> Nigel Gamble wrote:
> > On Sat, 13 Jan 2001, Roger Larsson wrote:
> > > A rethinking of the rescheduling strategy...
> >
> > Actually, I think you have more-or-less described how successful
> > preemptible kernels have already been developed, given that your
> > "sleeping spin locks" are really just sleeping mutexes (or binary
> > semaphores).
> >
> > 1. Short critical regions are protected by spin_lock_irq(). The maximum
> > value of "short" is therefore bounded by the maximum time we are happy
> > to disable (local) interrupts - ideally ~100us.
> >
> > 2. Longer regions are protected by sleeping mutexes.
> >
> > 3. Algorithms are rearchitected until all of the highly contended locks
> > are of type 1, and only low contention locks are of type 2.
> >
> > This approach has the advantage that we don't need to use a no-preempt
> > count, and test it on exit from every spinlock to see if a preempting
> > interrupt that has caused a need_resched has occurred, since we won't
> > see the interrupt until it's safe to do the preemptive resched.
>
> I agree that this was true in days of yore. But these days the irq
> instructions introduce serialization points and, me thinks, may be much
> more time consuming than the "++, --, if (false)" that a preemption
> count implemtation introduces. Could some one with a knowledge of the
> hardware comment on this?
>
> I am not suggesting that the "++, --, if (false)" is faster than an
> interrupt, but that it is faster than cli, sti. Of course we are
> assuming that there is between the cli and the sti as there is
> between the ++ and the -- if (false).
>
The problem with counting scheme is that you can not schedule inside any
spinlock - you have to split them up. Maybe you will have to do that anyway.
But if your RT process never needs more memory - it should be quite safe.
The difference with a sleeping mutex is that it can be made lazier - keep it
in the runlist, there should be very few...
See first patch attempt.
(George, Nigel told me about your idea before I sent the previous mail. So
major influence comes from you. But I do not think that it is equivalent)
/RogerL
Note: changed email...
--- ./linux/kernel/sched.c.orig Sat Jan 13 19:19:20 2001
+++ ./linux/kernel/sched.c Sat Jan 13 23:27:13 2001
@@ -144,7 +144,7 @@
* Also, dont trigger a counter recalculation.
*/
weight = -1;
- if (p->policy & SCHED_YIELD)
+ if (p->policy & (SCHED_YIELD | SCHED_SPINLOCK))
goto out;
/*
@@ -978,7 +978,7 @@
read_lock(&tasklist_lock);
p = find_process_by_pid(pid);
if (p)
- retval = p->policy & ~SCHED_YIELD;
+ retval = p->policy & ~(SCHED_YIELD | SCHED_SPINLOCK);
read_unlock(&tasklist_lock);
out_nounlock:
@@ -1267,3 +1267,54 @@
atomic_inc(&init_mm.mm_count);
enter_lazy_tlb(&init_mm, current, cpu);
}
+
+void wakeup_spinlock_yielder(spinlock_t *lock)
+{
+ int need_resched = 0;
+ struct list_head *tmp;
+ struct task_struct *p;
+
+ /* I do not like this part...
+ * not SMP safe, the runqueue might change under us...
+ * can not use spinlocks...
+ * runlist might be long...
+ */
+ local_irqsave(&flags);
+ if (lock->spin) {
+ /* someone is "spinning" on it
+ * it has to have higher prio than this
+ * let go of ALL :-( spinning processes
+ */
+ lock->spin = 0;
+
+ list_for_each(tmp, &runqueue_head) {
+ p = list_entry(tmp, struct task_struct, run_list);
+ if (p->policy & SCHED_SPINLOCK) {
+p->policy &= ~SCHED_SPINLOCK;
+ }
+ }
+
+ need_resched = 1;
+ }
+ local_irqrestore(&flags);
+
+ /* all higher prio will get a chance to run... */
+ if (need_resched)
+ schedule_running();
+}
+
+void schedule_spinlock(spinlock_t *lock)
+{
+ while (test_and_set(lock->lock)) {
+ /* note: owner can not race here, it has lower prio */
+
+ lock->spinon = 1;
+ p->policy |= SCHED_SPINLOCK;
+ schedule_running();
+ /* will be released in priority order */
+ }
+}
+
+
+
+
--- ./linux/include/linux/sched.h.orig Sat Jan 13 19:25:53 2001
+++ ./linux/include/linux/sched.h Sat Jan 13 19:26:31 2001
@@ -119,6 +119,7 @@
* yield the CPU for one re-schedule..
*/
#define SCHED_YIELD 0x10
+#define SCHED_SPINLOCK 0x20
struct sched_param {
int sched_priority;
--- ./linux/include/linux/spinlock.h.orig Sat Jan 13 19:40:30 2001
+++ ./linux/include/linux/spinlock.h Sat Jan 13 21:51:14 2001
@@ -66,16 +66,37 @@
typedef struct {
volatile unsigned long lock;
+ ??? queue;
} spinlock_t;
#define SPIN_LOCK_UNLOCKED (spinlock_t) { 0 }
+void wakeup_spinlock_yielder(spinlock_t *lock);
+void schedule_spinlock(spinlock_t *lock);
+
#define spin_lock_init(x) do { (x)->lock = 0; } while (0)
#define spin_is_locked(lock) (test_bit(0,(lock)))
-#define spin_trylock(lock) (!test_and_set_bit(0,(lock)))
+#define spin_trylock(lock) (!test_and_set_bit(0,(lock))) /* fail handled */
+
+#define spin_lock(x) do {
+if (test_and_set(lock->lock)) \
+ schedule_spinlock(); /* kind of yield
Re: Total loss with 2.4.0 (release)
I had a similar experience. All I can say is windows 98 and ME seem to have it out for Linux drives running late 2.3.x and 2.4.0 test and release. I had windows completely fry my Linux drive and I lost everything. I had some old backups and was able to restore at least the majority of older stuff. Sorry and good luck. > Hi all, > > I managed to kill my dear files and if anyone can help I'd be very > thankful. The events leading to this were something like: > Happy system with 2.4.0-test9 -> update to 2.4.0 (release) -> works > nicely; no complaints of any kind (no crc errors or dma- disabling) -> > reboot -> play Diablo II for some time (win98) -> restart linux -> > VFS: cannot mount root. > I have two ext2 partitions plus root and one of them is on another disk > (same ide lead, however) and it survived with no errors. > > When I ran e2fsck (1.18) on root partition, in addition to having to > run it many times before succeeding (segfaulted sometimes), nothing was > left in the partition except lost+found with lots of > files. Valid superblock wasn't found at 0, but at 8193. > > I really don't get what would have caused this or how to cure it. I still > have my /home in need of repairing, but I won't be running fsck on it with > this good expectancy-of-recovery (I actually tried once with a backup on > another disk and it resulted two VERY old directoried, everything else was > lost...and found(?)). > > I also updated my machine from VIA MVP3 based K6II to VIA KT133 (with 868B > southbridge - ATA100, that is) based Duron, but linux (2.4.0-test9) worked > fine with both configurations. I think this might be some sort of DMA > problem. > > I read from kernel notes that ac1 fixes root umount handling. Might that > be connected with the symptoms I had? If anyone has any suggestions, > please post them. I would, at least, like to know how could I verify if > the filesystem is really messed (for example, overwritten with something > at the bus at the time) or if it's just some minor issue that confuses > fsck totally. > > -- Heikki Lindholm > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386/setup.c cpuinfo notsc
On Mon, 15 Jan 2001, H. Peter Anvin wrote: > Right, but I'd also like to see the global flags exported explicitly to > /proc/cpuinfo. That's desirable, but how would we fit it into the existing layout? Would it be feasible to put it into /proc/cpuflags, instead? Anyway, with all necessary code and structures in place it will be a one-liner or so to add, so I'll write the underlying code first. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MTRR type AMD Duron/intel ?
Followup to: <[EMAIL PROTECTED]> By author:Linus Torvalds <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Mon, 15 Jan 2001, Tobias Ringstrom wrote: > > > > Last time I checked this was issued for perfectly known and valid bridges > > that advertice no IO resources. Isn't it a bit silly to issue that > > warning for that case, or am I missing something? > > Ehh - so what do they bridge, then? > > I'd say that a bridge that doesn't seem to bridge any IO or MEM region, > yet has stuff behind it, THAT is the silly thing. Thus the "silly" > warning. > What kind of bridge? Depending on the kind of bridge, it could be a subtractive-decoding bridge; or it could be a Host Bridge, which normally advertise only the resources it needs for itself. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386/setup.c cpuinfo notsc
"Maciej W. Rozycki" wrote: > > On Mon, 15 Jan 2001, H. Peter Anvin wrote: > > > I would personally prefer to export the global flags separately from the > > per-CPU flags. Not only is it more correct, it would help catch these > > kinds of bugs!!! > > That's what I am going to do. Basically to recode cpu_has_* macros to > use global flags as that's the intuitive name and use a set of different > names for the SMP bootstrap code to access boot_cpu_data (possibly > boot_has_* or boot_cpu_has_*). > Right, but I'd also like to see the global flags exported explicitly to /proc/cpuinfo. -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386/setup.c cpuinfo notsc
On Mon, 15 Jan 2001, H. Peter Anvin wrote: > I would personally prefer to export the global flags separately from the > per-CPU flags. Not only is it more correct, it would help catch these > kinds of bugs!!! That's what I am going to do. Basically to recode cpu_has_* macros to use global flags as that's the intuitive name and use a set of different names for the SMP bootstrap code to access boot_cpu_data (possibly boot_has_* or boot_cpu_has_*). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Marcel Weber ] re:Adaptec AIC7xxx version 6.08BETA release
On Friday 12 January 2001 10:33, Marcel Weber wrote: > SuSE Linux 7.0, Kernel 2.4.0 > > Adaptec 3950U2 > Adaptec 2940 > > > Although the kernel is complaining about the following things: > > kernel: scsi0: PCI error Interrupt at seqaddr= 0x4e > kernel: scsi0: Data Parity Error Detected during address or write > data phase > ... > > This is compared to the original drivers already a incredible > change: Those freezed my system after some time (something that did > not happen before I upgraded from a K6-2 to a K6-2+: Apparently the > old driver is working with loops or something) > Hmm.. I start wondering if this is what I see too.. Both 2.2.18 and 2.4.0 hangs for some reason that I have not been able to trace down - Saturday I tried to remove all PCI cards but my 3dfx and AIC7xxx 00:0f.0 SCSI storage controller: Adaptec AHA-7850 (rev 01) Has some driver been ported between 2.2 and 2.4 series recently ? I have not seen this problem before... I will try the new driver too... /RogerL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386/setup.c cpuinfo notsc
On Mon, 15 Jan 2001, Hugh Dickins wrote: > That's how "notsc" used to behave, but since 2.4.0-test11 > "notsc" has left "tsc" in /proc/cpuinfo. setup.c has a bogus > "#ifdef CONFIG_TSC" which should be "#ifndef CONFIG_X86_TSC". Confirmed. > HPA, Maciej and I discussed that around 5 Dec 2000; but HPA > was of Andrea's persuasion, that we should not mask caps out > of (real CPU entries in) /proc/cpuinfo, so we made no change. The conclusion was to add something like common_cpu_data, which would be independent from boot_cpu_data. > In discussion we found a more worrying error in the SMP case: > boot_cpu_data is supposed to be left with those x86_capabilities > common to all CPUs, but the code to do so was unaware that > boot_cpu_data is overwritten in booting each CPU. Even if all > CPUs have the same features, I imagine the Linux-defined ones > (CXMMX, K6_MTRR, CYRIX_ARR, CENTAUR_MCR) were unintentionally > masked out of the final boot_cpu_data. It's not supposed. Another struct should be added. Boot_cpu_data is expected to be used during an early SMP boot only. That's the original semantics and it should be preserved, I think. The SMP code relies on it. > The patch below fixes both those issues, and also clears > "pse" from /proc/cpuinfo in the same way if "mem=nopentium". > Tempted to rename "tsc_disable" to "disable_x86_tsc", but resisted. Good spotting. > I think there are still anomalies in the Cyrix and Centaur TSC > handling - shouldn't dodgy_tsc() check Centaur too? shouldn't > we set X86_CR4_TSD wherever we clear X86_FEATURE_TSC? - but I > don't have those CPUs to test, I'm wary of disabling TSC since > finding RH7.0 installed on i686 needs rdtsc to run /sbin/init, > and even if they are wrong then "notsc" corrects the situation: > not 2.4.1 material. Yep, that needs glibc or whatever introduces rdtsc to be fixed. Thanks for the patch -- I'll see how to fit it within my point of view. I'm somewhat time-constrained these days, but I might be able to spend an hour or so on coding and testing this issue tonight. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 4G SGI quad Xeon - memory-related slowdowns
In article <[EMAIL PROTECTED]>, Paul Hubbard <[EMAIL PROTECTED]> wrote: > >We're having some problems with the 2.4.0 kernel on our SGI 1450, and >were hoping for some help. > The box is a quad Xeon 700/2MB, with 4GB of memory, ServerSet III HE >chipset, RH6.1 (slightly modified for local configuration) distribution. > >a) If we compile the kernel with no high memory support, /proc/meminfo >shows 1G of memory and everything works fine. Good. >b) If we compile for 4G of memory, /proc/meminfo shows about 3G, and >overriding the amount at the lilo prompt causes kernel panics at bootup. >However, other than missing a quarter of the memory, it works just >fine. 3GB is right - your last 1GB is above the 4GB mark, and it's mapped there explicitly so that you'll have space in the low 32 bits to map PCI devices etc (and things like the APIC, you get the idea). If you try to override it, you will very obviously crash, because if you tell Linux that you have 4GB of memory, Linux will think that you have 4GB of _contiguous_ memory, which is not true. The only way to use that last gigabyte is to enable support for memory > 4GB, and get the proper memory map _without_ any overrides that shows the proper holes for PCI space. Check your "dmesg" output under a working kernel for details - you'll see how the memory is laid out and reported by the e820 call.. >c) If we compile the kernel for 64G high memory (PAE mode), we see all >of the memory but have other problems: > i) mkefs -m0 on a 72GB Seagate SCSI disk runs very slowly (about >5MB/sec instead of 22-25) and the machine hangs after the format >completes. To be exact, the command prompt returns, but > ls or any other command will never return, and you have to reset >the box. This is a > showstopper for us! Sounds like a true-to-God bug. Possibly in the form of incorrect MTRR settings. Make sure you enable MTRR support. I do need more information on what seems to hang, and how it hangs. One of the pre-kernels will give you a nice stack backtrace for each process if you press control-scrolllock, and that might be useful. > ii) If I override the amount of memory via lilo, we still get the > hang, but performance actually improves! The performance problem is _probably_ due to the kernel having to double-buffer the IO requests, coupled with bad MTRR settings (ie memory above the 4GB range is probably marked as non-cacheable or something, which means that you'll get really bad performance). Not using the high memory will avoid the double-buffering, and will also avoid using memory that isn't cached. If I'm right. The hang still indicates that something is wrong in PAE-land, though. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ide-scsi not working in 2.4.0. Possible scsi subsystem problems?
Ok. Here's a question for anyone. I have a computer here that I'm trying to get IDE-SCSI to work on. It seems to be a complete dud from this point of view. System config: Dual P3-550, 256MB Ram Scsi card: Adaptec 2940U2W. 2 Seagate LVD drives connected Primary IDE slave: IDE CDRW Drive (Matshita) Secondary IDE Master: IDE CD Drom (CD-540E, Teac) When the driver for the SCSI Card loads, it goes through it's pases, detects the drives, and all is happy. I run modprobe (or insmod) ide-scsi, it comes up with the note in the kernel about the 2nd driver being loaded (dmesg), but nothing shows on the bus, and anything that tries to access the scsi bus sees ONLY the adaptec card. Now boot 2.2.16 (RedHat's 2.2.16-22 from RH 7.0), boot up, First thing I notice is that the HardDrives are not 'timing out'. If I boot 2.4.0, it sees the drives, but it has to reset them saying the command had timed out. Doesn't happen on 2.2.16. Also, when I modprobe the ide-scsi driver, it sees the bus, and detects 2 devices, namely the 2 cd drives. A bus scan reveals the 2 scsi busses, and sees all devices attached. I am running the default Modutils package (2.3.14-3). I will try grabbing Modutils 2.4.0 and see if that fixes it, if not then does anyone else have any ideas? Thanks in advance! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI scanner problem with all kernels since 2.3.42
Hi Doug,
On Tue, Jan 09, 2001 at 03:53:02PM -0500, Douglas Gilbert wrote:
> There is also a problem report with the SnapScan 1236 <--> aha152x
> combination also based on SANE 1.0.3 . This one is looking
> like an "uninitialized errno" bug fixed in SANE 1.0.4 .
This should be solved with the attached patch. As you might remember
it's the same problem we already discussed with Abel Deuring.
Normally there should be no need to use REQUEST SENSE from outside,
when the driver supports auto-sense. It should be wrong as devices are
required to clear the sense data after the first, automatically issued
REQUEST SENSE. BTW the new eh code requires low-level drivers to do
auto-sense. The driver assumed that these are wrong and ignores them.
This behaviour was adopted from the aha1542 driver.
But for the SnapScan REQUEST SENSE is not only used on CHECK CONDITION,
but also to request the warmup time. Therefore the REQUEST SENSE is
valid here and proves the assumption wrong for such devices.
Even more worse is that the driver returned SUCCESS instead of 0 on
REQUEST SENSE. That's plain wrong and apparently tells the mid-level
code not to queue any more commands.
The warmup time issue with the SnapScan (and maybe other devices) should
also apply to the aha1542 driver.
Juergen
--
Juergen E Fischer
diff -ur orig/linux/drivers/scsi/aha152x.c linux/drivers/scsi/aha152x.c
--- orig/linux/drivers/scsi/aha152x.c Fri Dec 29 23:35:47 2000
+++ linux/drivers/scsi/aha152x.cSun Jan 14 21:31:12 2001
@@ -1,6 +1,6 @@
/* aha152x.c -- Adaptec AHA-152x driver
* Author: Jürgen E. Fischer, [EMAIL PROTECTED]
- * Copyright 1993-1999 Jürgen E. Fischer
+ * Copyright 1993-2000 Jürgen E. Fischer
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -13,9 +13,13 @@
* General Public License for more details.
*
*
- * $Id: aha152x.c,v 2.3 2000/11/04 16:40:26 fischer Exp $
+ * $Id: aha152x.c,v 2.4 2000/12/16 12:53:56 fischer Exp $
*
* $Log: aha152x.c,v $
+ * Revision 2.4 2000/12/16 12:53:56 fischer
+ * - allow REQUEST SENSE to be queued
+ * - handle shared PCI interrupts
+ *
* Revision 2.3 2000/11/04 16:40:26 fischer
* - handle data overruns
* - extend timeout for data phases
@@ -932,6 +936,8 @@
printk(KERN_ERR "aha152x%d: catched software interrupt for unknown
controller.\n", HOSTNO);
HOSTDATA(shpnt)->swint++;
+
+ SETPORT(DMACNTRL0, INTEN);
}
@@ -1274,7 +1280,7 @@
SETPORT(SIMODE0, 0);
SETPORT(SIMODE1, 0);
- ok = request_irq(shpnt->irq, swintr, SA_INTERRUPT, "aha152x", shpnt);
+ ok = request_irq(shpnt->irq, swintr, SA_INTERRUPT|SA_SHIRQ, "aha152x",
+shpnt);
if (ok < 0) {
if (ok==-EINVAL)
printk(KERN_ERR "aha152x%d: bad IRQ %d.\n", HOSTNO,
shpnt->irq);
@@ -1308,6 +1314,8 @@
printk("failed.\n");
}
+ SETPORT(DMACNTRL0, INTEN);
+
printk(KERN_ERR "aha152x%d: IRQ %d possibly wrong. Please
verify.\n", HOSTNO, shpnt->irq);
registered_count--;
@@ -1319,13 +1327,12 @@
}
printk("ok.\n");
- SETPORT(DMACNTRL0, INTEN);
/* clear interrupts */
SETPORT(SSTAT0, 0x7f);
SETPORT(SSTAT1, 0xef);
- if (request_irq(shpnt->irq, intr, SA_INTERRUPT, "aha152x", shpnt) < 0)
{
+ if (request_irq(shpnt->irq, intr, SA_INTERRUPT|SA_SHIRQ, "aha152x",
+shpnt) < 0) {
printk(KERN_ERR "aha152x%d: failed to reassign interrupt.\n",
HOSTNO);
scsi_unregister(shpnt);
@@ -1469,12 +1476,14 @@
int aha152x_queue(Scsi_Cmnd *SCpnt, void (*done)(Scsi_Cmnd *))
{
+#if 0
if(*SCpnt->cmnd == REQUEST_SENSE) {
SCpnt->result = 0;
done(SCpnt);
- return SUCCESS;
+ return 0;
}
+#endif
return aha152x_internal_queue(SCpnt, 0, 0, 0, done);
}
diff -ur orig/linux/drivers/scsi/aha152x.h linux/drivers/scsi/aha152x.h
--- orig/linux/drivers/scsi/aha152x.h Mon Dec 11 22:19:02 2000
+++ linux/drivers/scsi/aha152x.hFri Jan 12 13:18:24 2001
@@ -2,7 +2,7 @@
#define _AHA152X_H
/*
- * $Id: aha152x.h,v 2.3 2000/11/04 16:41:37 fischer Exp $
+ * $Id: aha152x.h,v 2.4 2000/12/16 12:48:48 fischer Exp $
*/
#if defined(__KERNEL__)
@@ -27,7 +27,7 @@
(unless we support more than 1 cmd_per_lun this should do) */
#define AHA152X_MAXQUEUE 7
-#define AHA152X_REVID "Adaptec 152x SCSI driver; $Revision: 2.3 $"
+#define AHA152X_REVID "Adaptec 152x SCSI driver; $Revision: 2.4 $"
/* Initial value of Scsi_Host entry */
#define AHA152X { proc_name: "aha152x", \
Bonnie on NBD w/ memory pressure deadlocks (problem in wait_for_tcp_memory?)
running 2.4.0 with kdb patch [1.] Bonnie on NBD w/ memory pressure deadlocks (problem in wait_for_tcp_memory?) [2.] Full description This bug appears to be totally reproducable on different hardware and kernel versions. The conditions that create the problem: 2 machines (client, server) (both p4 1.4G) networked with 100Mb the server runs: ./nbd-server 8899 /dev/hda6 1937804k the client runs: ./nbd-client serverip 8899 /dev/nb5 mke2fs /dev/nb5 mount /dev/nb5 -t ext2 /mnt/nb5 ./Bonnie -d /mnt/nb5 -s 100 (nbd-client and nbd-server from http://atrey.karlin.mff.cuni.cz/~pavel/nbd/nbd.html) NBD seems to do fine with normal disk use, but when Bonnie is run with large file sizes it causes memory pressure and this triggers the problem being seen. Bonnie output: FILE '/mnt/nbd5/Bonnie.8776', ssize: 104857600 Writing with putc()...done Rewriting... [and here it hangs] What I think is going on: I compiled kdb into the kernel after unsuccessfully being able to figure it out by just looking at the source. Doing this seemed to confirm my suspicions about the cause but I was unable to figure out the exact problem. using kdb I found the backtraces of important processes in the client and server: Client -- pid 5: bdflush schedule+0x2d8 schedule+timeout+0x17 wait_for_tcp_memory+0x12e tcp_sendmsg+0x666 inet_sendmsg+0x40 sock_sendmsg+0x7a [nbd]nbd_xmit+0xda [nbd]nbd_send_req+0x8f [nbd]do_nbd_request+0x104 __make_request+0x5be generic_make_request+0xd7 submit_bh+0x58 ll_rw_block+0x12f flush_dirty_buffers+0x81 bdflush+0x7b kernel_thread+0x23 pid 8740: nbd_client schedule+0x2d8 __down+0x61 __down_failed+0xb [nbd].text.lock+0x19 [nbd]nbd_do_it+0x41 [nbd]nbd_ioctl+0x316 blkdev_ioctl+0x2c sys_ioctl+0x174 system_call+0x33 pid 8753: Bonnie schedule+0x2d8 __lock_page+0x8b lock_page+0x18 do_generic_file_read+0x29b generic_file_read+0x5d sys_read+0x91 system_call+0x33 Server -- pid 8431: nbd-server schedule+0x2d8 schedule_timeout+0x17 wait_for_tcp_memory+0x12e(0xc6ebe400, 0x7fff) tcp_sendmsg+0x666(0xc6ebe400,0xc60bdf7c, 0x1010) inet_sendmsg+0x40(0xc640aa04,0xc60bdf7c,0x1010, 0xc60bdf44, 0xc640aa04) sock_sendmsg+0x7a(0xc640aa04,0xc60bdf7c,0x1010) sock_write+0x8f(0xc7ebd00, 0xbfffa548, 0x1010, 0xc70ebd20) sys_write+0x95(0x4,0xbfffa548, 0x1010, 0x1010, 0xbfffa548) system_call+0x33 both machines are low in memory but have buffer memory still: server: mem total=126216 used=124504 free=1712 shared=0 buffers=109844 cached=4912 -/+ buffers/cache: 9748 116468 client: mem total=126216 used=124264 free=1952 shared=0 buffers= 29940 cached=15568 -/+ buffers/cache: 78756 47460 What I think is going on is the client is busy reading blocks from the server over nbd and dirtying them, eventually the buffer cache consumes all memory. This memory pressure causes bdflush to try to flush dirty buffers which requires it to send the blocks to the server. This does not complete because wait_for_tcp_memory never succeeds ?? (I am still a bit unsure of what is going on with wait_for_tcp_memory) Thus the client can not send any more requests because nbd is locked by bdflush which is trying to flush dirty buffers but appearently cannot. Also the server seems to be in the same wait_for_tcp_memory loop. I think if I understand better what is going on in wait_for_tcp_memory I will be closer to figureing out how to solve this problem. Any help would be appreciated, I have much more info if anything more is needed. Thank you very much, -jeff [3.] keywords: nbd, networking, low memory [4.] Linux version 2.4.0-kdb (raubitsj@jr-lnx) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Thu Jan 11 21:00:11 PST 2001 [5.] no oops [6.] this problem is 100% reproducable, seems to be reproducable on different hardware, w/ different kernel versions too [7.] Environment (this listing is limited, but can be provided if needed) cpuinfo: P4 1.4GHz 128MB ram modules: acenic, nbd --- Jeff Raubitschek Computer Engineer [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vmware 2.0.3, kernel 2.4.0 and a cdrom
On Sun, Jan 14 2001, Martin Maciaszek wrote:
> Since I installed Kernel 2.4.0 VMware is no longer able to
> recognize my cdrom drive. VMware shows a dialog box on power up
> with following content:
> [...]
> CDROM: '/dev/scd0' exists, but does not appear tobe a CDROM device.
>
> Error connecting the CDROM device
> [...]
>
> At the same time my syslog records the following message:
> Jan 13 21:49:57 nexus kernel: sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
>
> I tried 2.2.18 and VMware recognized the cdrom drive.
Could you try with this patch, so maybe we can get some hints as to what
is going on?
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
--- /opt/kernel/linux-2.4.0-ac9/drivers/scsi/sr_ioctl.c Fri Dec 29 23:07:22 2000
+++ drivers/scsi/sr_ioctl.c Mon Jan 15 22:14:59 2001
@@ -161,10 +161,10 @@
} else {
err = -EINVAL;
}
-#ifdef DEBUG
- print_command(sr_cmd);
- print_req_sense("sr", SRpnt);
-#endif
+ if (!quiet) {
+ print_command(sr_cmd);
+ print_req_sense("sr", SRpnt);
+ }
break;
default:
printk(KERN_ERR "sr%d: CDROM (ioctl) error, command: ",
target);
oracle 8.1.7 on 2.4.0?
Title: oracle 8.1.7 on 2.4.0? what is the status of oracle 8.1.7 on 2.4? Did the O_SYNC stuff ever get sorted out? Should I stick with 2.2.18?
Re: Is sendfile all that sexy?
In article <[EMAIL PROTECTED]>, Albert D. Cahalan <[EMAIL PROTECTED]> wrote: >Ingo Molnar writes: >> On Mon, 15 Jan 2001, Jonathan Thackray wrote: > >>> It's a very useful system call and makes file serving much more >>> scalable, and I'm glad that most Un*xes now have support for it >>> (Linux, FreeBSD, HP-UX, AIX, Tru64). The next cool feature to add to >>> Linux is sendpath(), which does the open() before the sendfile() all >>> combined into one system call. > >Ingo Molnar's data in a nice table: > >open/close 7.5756 microseconds >stat5.4864 microseconds >write 0.9614 microseconds >read1.1420 microseconds >syscall 0.6349 microseconds > >Rather than combining open() with sendfile(), it could be combined >with stat(). Note that "fstat()" is fairly low-overhead (unlike "stat()" it obviously doesn't have to parse the name again), so "open+fstat" is quite fine as-is. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
4G SGI quad Xeon - memory-related slowdowns
We're having some problems with the 2.4.0 kernel on our SGI 1450, and were hoping for some help. The box is a quad Xeon 700/2MB, with 4GB of memory, ServerSet III HE chipset, RH6.1 (slightly modified for local configuration) distribution. a) If we compile the kernel with no high memory support, /proc/meminfo shows 1G of memory and everything works fine. b) If we compile for 4G of memory, /proc/meminfo shows about 3G, and overriding the amount at the lilo prompt causes kernel panics at bootup. However, other than missing a quarter of the memory, it works just fine. c) If we compile the kernel for 64G high memory (PAE mode), we see all of the memory but have other problems: i) mkefs -m0 on a 72GB Seagate SCSI disk runs very slowly (about 5MB/sec instead of 22-25) and the machine hangs after the format completes. To be exact, the command prompt returns, but ls or any other command will never return, and you have to reset the box. This is a showstopper for us! ii) If I override the amount of memory via lilo, we still get the hang, but performance actually improves! At 1G, it's slow for a few seconds, and then runs fine. At 2G, it's slow, and when I tried to boot 3G I got an odd startup crash that I've not had time to replicate. Other notes: 1) SCSI is onboard Adaptec 39160 (aic7xxx driver, dual-channel) and we've tried different drives, cables, terminators, etc. 2) Other block I/O output (eg dd if=/dev/zero of=/dev/sdi bs=4M) also run very slowly 3) We are using vmstat 1 to monitor data rates 4) I tried the format with 2.4 prerelease, and the mkfs was very slow, and I got a SCSI reset at the end of the format. Perhaps this is related? 5) If necessary, we can easily load a different distribution on the machine if that might be part of the problem. If necessary, we can setup a login on the machine, or run whatever test code is necessary. Other than this, it's a pretty nice box to work on. Please reply to rjetton and phubbard at fnal.gov, thanks. -Paul -- Paul Hubbard [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386/setup.c cpuinfo notsc
Hugh Dickins wrote: > > That's how "notsc" used to behave, but since 2.4.0-test11 > "notsc" has left "tsc" in /proc/cpuinfo. setup.c has a bogus > "#ifdef CONFIG_TSC" which should be "#ifndef CONFIG_X86_TSC". > > HPA, Maciej and I discussed that around 5 Dec 2000; but HPA > was of Andrea's persuasion, that we should not mask caps out > of (real CPU entries in) /proc/cpuinfo, so we made no change. > > In discussion we found a more worrying error in the SMP case: > boot_cpu_data is supposed to be left with those x86_capabilities > common to all CPUs, but the code to do so was unaware that > boot_cpu_data is overwritten in booting each CPU. Even if all > CPUs have the same features, I imagine the Linux-defined ones > (CXMMX, K6_MTRR, CYRIX_ARR, CENTAUR_MCR) were unintentionally > masked out of the final boot_cpu_data. > > The patch below fixes both those issues, and also clears > "pse" from /proc/cpuinfo in the same way if "mem=nopentium". > Tempted to rename "tsc_disable" to "disable_x86_tsc", but resisted. > > I think there are still anomalies in the Cyrix and Centaur TSC > handling - shouldn't dodgy_tsc() check Centaur too? shouldn't > we set X86_CR4_TSD wherever we clear X86_FEATURE_TSC? - but I > don't have those CPUs to test, I'm wary of disabling TSC since > finding RH7.0 installed on i686 needs rdtsc to run /sbin/init, > and even if they are wrong then "notsc" corrects the situation: > not 2.4.1 material. > I would personally prefer to export the global flags separately from the per-CPU flags. Not only is it more correct, it would help catch these kinds of bugs!!! -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mmap()/VM problems in 2.4.0
On 15 Jan 2001, Zlatko Calusic wrote: > "Vlad Bolkhovitine" <[EMAIL PROTECTED]> writes: > > > Here is updated info for 2.4.1pre3: > > > > Size is MB, BlkSz is Bytes, Read, Write, and Seeks are MB/sec > > > > with mmap() > > > > File Block Num Seq ReadRand Read Seq Write Rand Write > > DirSize SizeThr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) > > --- -- --- --- --- --- --- --- > >. 1024 40962 1.089 1.24% 0.235 0.45% 1.118 4.11% 0.616 1.41% > > > > without mmap() > > > > File Block Num Seq ReadRand Read Seq Write Rand Write > > DirSize SizeThr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) > > --- -- --- --- --- --- --- --- > >. 1024 40962 28.41 41.0% 0.547 1.15% 13.16 16.1% 0.652 1.46% > > > > > > Mmap() performance dropped dramatically down to almost unusable level. Plus, > > system was unusable during test: "vmstat 1" updated results every 1-2 _MINUTES_! > > > > You need Marcelo's patch. Please apply and retest. My box thinks quite highly of that patch fwiw, but insists that he needs to apply Jens Axboes' blk patch first ;-) (Not because of tiobench) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] sendpath() support, 2.4.0-test3/-ac9
On 15 Jan 2001, Linus Torvalds wrote:
> int fd = open(..)
> fstat(fd..);
> sendfile(fd..);
> close(fd);
>
> is any slower than
>
> .. cache stat() in user space based on name ..
> sendpath(name, ..);
>
> on any real load.
just for kicks i've implemented sendpath() support. (patch against
2.4.0-test and sample code attached) It appears to work just fine here.
With a bit of reorganization in mm/filemap.c it was quite straightforward
to do.
Jonathan, is this what Zeus needs? If yes, it could be interesting to run
a simple benchmark to compare sendpath() to open()+sendfile()?
Ingo
--- linux/mm/filemap.c.orig Mon Jan 15 22:43:21 2001
+++ linux/mm/filemap.c Mon Jan 15 23:09:55 2001
@@ -39,6 +39,8 @@
* page-cache, 21.05.1999, Ingo Molnar <[EMAIL PROTECTED]>
*
* SMP-threaded pagemap-LRU 1999, Andrea Arcangeli <[EMAIL PROTECTED]>
+ *
+ * Started sendpath() support, (C) 2000 Ingo Molnar <[EMAIL PROTECTED]>
*/
atomic_t page_cache_size = ATOMIC_INIT(0);
@@ -1450,15 +1452,15 @@
return written;
}
-asmlinkage ssize_t sys_sendfile(int out_fd, int in_fd, off_t *offset, size_t count)
+/*
+ * Get input file, and verify that it is ok..
+ */
+static struct file * get_verify_in_file (int in_fd, size_t count)
{
- ssize_t retval;
- struct file * in_file, * out_file;
- struct inode * in_inode, * out_inode;
+ struct inode * in_inode;
+ struct file * in_file;
+ int retval;
- /*
-* Get input file, and verify that it is ok..
-*/
retval = -EBADF;
in_file = fget(in_fd);
if (!in_file)
@@ -1474,10 +1476,21 @@
retval = locks_verify_area(FLOCK_VERIFY_READ, in_inode, in_file,
in_file->f_pos, count);
if (retval)
goto fput_in;
+ return in_file;
+fput_in:
+ fput(in_file);
+out:
+ return ERR_PTR(retval);
+}
+/*
+ * Get output file, and verify that it is ok..
+ */
+static struct file * get_verify_out_file (int out_fd, size_t count)
+{
+ struct file *out_file;
+ struct inode *out_inode;
+ int retval;
- /*
-* Get output file, and verify that it is ok..
-*/
retval = -EBADF;
out_file = fget(out_fd);
if (!out_file)
@@ -1491,6 +1504,29 @@
retval = locks_verify_area(FLOCK_VERIFY_WRITE, out_inode, out_file,
out_file->f_pos, count);
if (retval)
goto fput_out;
+ return out_file;
+
+fput_out:
+ fput(out_file);
+fput_in:
+ return ERR_PTR(retval);
+}
+
+asmlinkage ssize_t sys_sendfile(int out_fd, int in_fd, off_t *offset, size_t count)
+{
+ ssize_t retval;
+ struct file * in_file, *out_file;
+
+ in_file = get_verify_in_file(in_fd, count);
+ if (IS_ERR(in_file)) {
+ retval = PTR_ERR(in_file);
+ goto out;
+ }
+ out_file = get_verify_out_file(out_fd, count);
+ if (IS_ERR(out_file)) {
+ retval = PTR_ERR(out_file);
+ goto fput_in;
+ }
retval = 0;
if (count) {
@@ -1524,6 +1560,56 @@
fput(in_file);
out:
return retval;
+}
+
+asmlinkage ssize_t sys_sendpath(int out_fd, char *path, off_t *offset, size_t count)
+{
+ struct file in_file, *out_file;
+ read_descriptor_t desc;
+ loff_t pos = 0, *ppos;
+ struct nameidata nd;
+ int ret;
+
+ out_file = get_verify_out_file(out_fd, count);
+ if (IS_ERR(out_file)) {
+ ret = PTR_ERR(out_file);
+ goto err;
+ }
+ ret = user_path_walk(path, &nd);
+ if (ret)
+ goto put_out;
+ ret = -EINVAL;
+ if (!nd.dentry || !nd.dentry->d_inode)
+ goto put_in_out;
+
+ memset(&in_file, 0, sizeof(in_file));
+ in_file.f_dentry = nd.dentry;
+ in_file.f_op = nd.dentry->d_inode->i_fop;
+
+ ppos = &in_file.f_pos;
+ if (offset) {
+ if (get_user(pos, offset))
+ goto put_in_out;
+ ppos = &pos;
+ }
+ desc.written = 0;
+ desc.count = count;
+ desc.buf = (char *) out_file;
+ desc.error = 0;
+ do_generic_file_read(&in_file, ppos, &desc, file_send_actor, 0);
+
+ ret = desc.written;
+ if (!ret)
+ ret = desc.error;
+ if (offset)
+ put_user(pos, offset);
+
+put_in_out:
+ fput(out_file);
+put_out:
+ path_release(&nd);
+err:
+ return ret;
}
/*
--- linux/arch/i386/kernel/entry.S.orig Mon Jan 15 22:42:47 2001
+++ linux/arch/i386/kernel/entry.S Mon Jan 15 22:43:12 2001
@@ -646,6 +646,7 @@
.long SYMBOL_NAME(sys_getdents64) /* 220 */
.long SYMBOL_NAME(sys_fcntl64)
.long SYMBOL_NAME(sys_ni_syscall) /* reserved for TUX
Re: mmap()/VM problems in 2.4.0
"Vlad Bolkhovitine" <[EMAIL PROTECTED]> writes:
> Here is updated info for 2.4.1pre3:
>
> Size is MB, BlkSz is Bytes, Read, Write, and Seeks are MB/sec
>
> with mmap()
>
> File Block Num Seq ReadRand Read Seq Write Rand Write
> DirSize SizeThr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
> --- -- --- --- --- --- --- ---
>. 1024 40962 1.089 1.24% 0.235 0.45% 1.118 4.11% 0.616 1.41%
>
> without mmap()
>
> File Block Num Seq ReadRand Read Seq Write Rand Write
> DirSize SizeThr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
> --- -- --- --- --- --- --- ---
>. 1024 40962 28.41 41.0% 0.547 1.15% 13.16 16.1% 0.652 1.46%
>
>
> Mmap() performance dropped dramatically down to almost unusable level. Plus,
> system was unusable during test: "vmstat 1" updated results every 1-2 _MINUTES_!
>
You need Marcelo's patch. Please apply and retest.
--- linux.orig/mm/vmscan.c Mon Jan 15 02:33:15 2001
+++ linux/mm/vmscan.c Mon Jan 15 02:46:25 2001
@@ -153,7 +153,7 @@
if (VALID_PAGE(page) && !PageReserved(page)) {
try_to_swap_out(mm, vma, address, pte,
page);
- if (--count)
+ if (!--count)
break;
}
}
--
Zlatko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
Ingo Molnar writes: > On Mon, 15 Jan 2001, Jonathan Thackray wrote: >> It's a very useful system call and makes file serving much more >> scalable, and I'm glad that most Un*xes now have support for it >> (Linux, FreeBSD, HP-UX, AIX, Tru64). The next cool feature to add to >> Linux is sendpath(), which does the open() before the sendfile() all >> combined into one system call. Ingo Molnar's data in a nice table: open/close 7.5756 microseconds stat5.4864 microseconds write 0.9614 microseconds read1.1420 microseconds syscall 0.6349 microseconds Rather than combining open() with sendfile(), it could be combined with stat(). Since the syscall would be new anyway, it could skip the normal requirement about returning the next free file descriptor in favor of returning whatever can be most quickly found. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i386/setup.c cpuinfo notsc
On Thu, 11 Jan 2001, Linus Torvalds wrote
(under Subject: Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"):
>
> We _want_ /proc/cpuinfo to reflect the fact that the kernel considers
> FSXR/XMM to not exist. That is true information, and is in fact something
> that install scripts etc can find extremely useful.
>
> [snip]
>
> Similarly, when we disable TSC, it's also telling user-land that this
> machine does not appear to have a working TSC for some reason. User-land
> applications may also care about the fact that TSC seems to skip time if
> the machine is idle etc (which was apparently the problem with some broken
> Cyrix chips).
That's how "notsc" used to behave, but since 2.4.0-test11
"notsc" has left "tsc" in /proc/cpuinfo. setup.c has a bogus
"#ifdef CONFIG_TSC" which should be "#ifndef CONFIG_X86_TSC".
HPA, Maciej and I discussed that around 5 Dec 2000; but HPA
was of Andrea's persuasion, that we should not mask caps out
of (real CPU entries in) /proc/cpuinfo, so we made no change.
In discussion we found a more worrying error in the SMP case:
boot_cpu_data is supposed to be left with those x86_capabilities
common to all CPUs, but the code to do so was unaware that
boot_cpu_data is overwritten in booting each CPU. Even if all
CPUs have the same features, I imagine the Linux-defined ones
(CXMMX, K6_MTRR, CYRIX_ARR, CENTAUR_MCR) were unintentionally
masked out of the final boot_cpu_data.
The patch below fixes both those issues, and also clears
"pse" from /proc/cpuinfo in the same way if "mem=nopentium".
Tempted to rename "tsc_disable" to "disable_x86_tsc", but resisted.
I think there are still anomalies in the Cyrix and Centaur TSC
handling - shouldn't dodgy_tsc() check Centaur too? shouldn't
we set X86_CR4_TSD wherever we clear X86_FEATURE_TSC? - but I
don't have those CPUs to test, I'm wary of disabling TSC since
finding RH7.0 installed on i686 needs rdtsc to run /sbin/init,
and even if they are wrong then "notsc" corrects the situation:
not 2.4.1 material.
Hugh
--- linux-2.4.1-pre3/arch/i386/kernel/setup.c Fri Jan 12 15:20:33 2001
+++ linux/arch/i386/kernel/setup.c Mon Jan 15 18:07:15 2001
@@ -148,6 +148,7 @@
static int disable_x86_serial_nr __initdata = 1;
static int disable_x86_fxsr __initdata = 0;
+static int disable_x86_pse __initdata = 0;
/*
* This is set up by the setup-routine at boot-time
@@ -550,6 +551,7 @@
if (!memcmp(from+4, "nopentium", 9)) {
from += 9+4;
clear_bit(X86_FEATURE_PSE,
&boot_cpu_data.x86_capability);
+ disable_x86_pse = 1;
} else if (!memcmp(from+4, "exactmap", 8)) {
from += 8+4;
e820.nr_map = 0;
@@ -1884,6 +1886,9 @@
return have_cpuid_p(); /* Check to see if CPUID now enabled? */
}
+static __u32 common_x86_capability[NCAPINTS] __initdata = {
+ 0x, 0x, 0x, 0x };
+
/*
* This does the hard work of actually picking apart the CPU stuff...
*/
@@ -2007,8 +2012,12 @@
* we do "generic changes."
*/
+ /* PSE disabled? */
+ if (disable_x86_pse)
+ clear_bit(X86_FEATURE_PSE, &c->x86_capability);
+
/* TSC disabled? */
-#ifdef CONFIG_TSC
+#ifndef CONFIG_X86_TSC
if ( tsc_disable )
clear_bit(X86_FEATURE_TSC, &c->x86_capability);
#endif
@@ -2043,16 +2052,13 @@
c->x86_capability[3]);
/*
-* On SMP, boot_cpu_data holds the common feature set between
-* all CPUs; so make sure that we indicate which features are
-* common between the CPUs. The first time this routine gets
-* executed, c == &boot_cpu_data.
+* On SMP, boot_cpu_data is to hold the feature set common
+* between all CPUs. But boot_cpu_data is rewritten by each CPU
+* as it boots, so overwrite that with common features each time.
*/
- if ( c != &boot_cpu_data ) {
- /* AND the already accumulated flags with these */
- for ( i = 0 ; i < NCAPINTS ; i++ )
- boot_cpu_data.x86_capability[i] &= c->x86_capability[i];
- }
+ for ( i = 0 ; i < NCAPINTS ; i++ )
+ boot_cpu_data.x86_capability[i] =
+ common_x86_capability[i] &= c->x86_capability[i];
printk("CPU: Common caps: %08x %08x %08x %08x\n",
boot_cpu_data.x86_capability[0],
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enable K7 nmi watchdog
On Mon, 15 Jan 2001 04:00:29 +0100, Petr Vandrovec wrote: >(1) You missed some zeros in MSR_K7_ definitions Oops :-( >(2) AMD's MSR are real 64bit (well, 47bit) values, so high >MSR dword must be set to -1, not to 0 Correct. That was a copy-paste error from the P6 code. When writing to a perfctr MSR, Intel P6 sign-extends bit 31. P5 and Pentium 4 [*], and AMD K7 don't sign-extend, so there one has to pass -1 in the high word. [*] P4? PIV? P15? NB? Oh why oh why couldn't they just have named the core P7 ... >(3) on my CPU performance register 0x76 counts who knows what... >This causes that when machine is idle, there is exactly one >NMI per second. When machine is loaded, NMI count/sec climbs >up to 100 NMIs per sec. I have no idea whether someone slows >clock down to 10MHz on hlt, or what happens. Maybe that they >removed this from documentation due to this. This also means >that on bootup check for NMI stuck probably passed only >due to pure luck - because of mdelay()/udelay() is implemented >as tight loop. The varying speed of this counter is unfortunate, but at least it doesn't stop completely. The NMI oopser should still trigger, although perhaps after a much longer delay. >Otherwise it works Great. Thanks. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Delay in authentication.gy
On Mon, 8 Jan 2001, Alan Cox wrote: > And have identical bad problems with auth failures. Right now I've given up > trying to make 2.4 and YP mix because my RH setup assumes NIS auth will fail > fast during boot up scripts and it doesnt. > > Unfortunately for the quickfix folks, Dave is right about needing to sort it, > and that means someone has to sort glibc to use the new interfaces I just compiled glibc 2.2.1 against the 2.4.0 kernel headers today. I went to the local console to login. I was expecting to go get a coffee after typing my password, but was pleasantly surprised to see the prompt waiting for me in no time at all. So the newest glibc seems to have the problem fixed for me now. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Slot Number Question
On Mon, 15 Jan 2001, Jack Hammer wrote: > My adapter configuration utility needs to instruct the user which physical > adapter needs attention ( when there may be multiple adapters in the system > ).My question is : How do I determine the ( machine ) slot number of a > PCI adapter ? > > In BIOS and other OS's this may be doneby examining the system's PCI > Routing Tables.I don't think I can get to those from Linux. > > PCI Devices are defined by BUS, DEVICE, and FUNCTION.In Linux there > is a function ( defined in pci.h near the end of the file ) called " > PCI_SLOT( devfn ) " but from what I can see this returns what PCI calls > the device. PCI device is not the machine's slot number. This function > even uses the encoded byte which is named devfn ( I assume from PCI > device and PCI function ) , but this function treats it as slot and > function. > > Any help is appreciated. Thanks in advance. According to the PCI Specifications, there is no such item as the 'slot' if what you refer to is the physical socket on a bus. The hardware vendor is free to put any 'device number' in any such slot as long as it is unique. This is done by asserting the target's IDSEL line when the target <15:11> bits are qualified. Both the PC BIOS and Linux may 'remember' these bits and Linux used to display these bits as: PCI devices found: Bus 0, device 0, function 0: Class 0600: PCI device 8086:7190 (rev 2). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe600 [0xe7ff]. Bus 0, device 1, function 0: Class 0604: PCI device 8086:7191 (rev 2). Master Capable. Latency=64. Min Gnt=128. Bus 0, device 4, function 0: ... the 'device' shown in /proc/pci. However, there are new problems relating to changes made in 2.4.0, which now provides incorrect information in /proc/pci: Class 0601: PCI device 8086:7110 (rev 2). Bus 0, device 4, function 1: Class 0101: PCI device 8086:7111 (rev 1). Master Capable. Latency=32. I/O at 0xd800 [0xd80f]. Bus 0, device 4, function 2: Class 0c03: PCI device 8086:7112 (rev 1). IRQ 12. Master Capable. Latency=32. I/O at 0xd400 [0xd41f]. Bus 0, device 4, function 3: Note I have 3 device #4 showing in my /proc/pci file, which of course is impossible. The meaning of 'device' seems to have been changed so one now has to include the function number as well???!! All of the device 4 listed above refer to the exact same device. It's the PIIX4 PCI/ISA bridge. In my case, the correct PCI devices are shown as: Device VendorType 0 Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge I/O memory : 0xe600->0xe7f7 1 Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge I/O memory : 0x40010100->0x470101ff I/O memory : 0x22a0d0e0->0x1fffdfef I/O memory : 0xe5e0e5f0->0xe5efe5ff I/O memory : 0xe5f0e600->0xe5ffe60f 4 Intel Corporation 82371AB PIIX4 ISA 9 S3 Inc.86c968 [Vision 968 VRAM] rev 0 IRQ 12 Pin 1 I/O memory : 0x1400->0x15ff 11 3Com Corporation 3c905B 100BaseTX [Cyclone] IRQ 10 Pin 1 I/O ports : 0xd000->0xd07e I/O memory : 0xe180->0xe180007f 12 BusLogic BT-946C (BA80C30), [MultiMaster 10] IRQ 11 Pin 1 I/O ports : 0xb800->0xb802 I/O memory : 0xe100->0xe1000fff This is obtained from a program that simply scans the PCI bus in the manner shown on page 345 of the PCI System Architecture, fourth edition, MindShare, Inc., ISBN 0-201-30974-2. In any case, there is no way to correlate the device number with a PC connector slot just as there is no way to find out which of the 4 INT lines go to these connectors. The BIOS vendor only knows for sure, and since BIOSes are not updated as often as boards, even the BIOS is often incorrect. I suggest you put a flashing LED on the board that needs attention. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
Followup to: <[EMAIL PROTECTED]> By author:Matti Aarnio <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > One thing about 'sendfile' (and likely 'sendpath') is that > current (hammered into running binaries -> unchangeable) > syscalls support only up to 2GB files at 32 bit systems. > > Glibc 2.2(9) at RedHat : > > #ifdef __USE_FILE_OFFSET64 > # error " cannot be used with _FILE_OFFSET_BITS=64" > #endif > > I do admit that doing sendfile() on some extremely large > file is unlikely, but still... > 2 GB isn't really that extremely large these days. This is an unpleasant limitation. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
Followup to: <[EMAIL PROTECTED]> By author:J Sloan <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Linus Torvalds wrote: > > > Of course, you may be right on wuftpd. It obviously wasn't designed with > > security in mind, other alternatives may be better. > > I run proftpd on all my ftp servers - it's fast, configurable > and can do all the tricks I need - even red hat seems to > agree that proftpd is the way to go. > > Visit any red hat ftp site and they are running proftpd - > > So, why do they keep shipping us wu-ftpd instead? > > That really frosts me. > proftpd is not what you want for an FTP server whose main function is *non-*anonymous access. It is very much written for the sole purpose of being a great FTP server for a large anonymous FTP site. If you're running a site large enough to matter, you can replace an RPM or two. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated zerocopy patches on kernel.org
* David S. Miller ([EMAIL PROTECTED]) wrote: > > Now against 2.4.1-pre2: > > ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p2-1.diff.gz Tried it with 2.4.1-pre3, didn't have any problem applying it, but when I rebooted the system it pretty much had no interest in talking TCP to anything. 2.4.1-pre3 alone has no problem. Should I give 2.4.1p2 a try with the zerocopy patch? I think that's my next step, but if it isn't likely to change anything.. The problem tended to be that a connection could reach the 'ESTABLISHED' point (in netstat), but then very little data would pass over the connection. ie; 'telnet somehost 25' would give me the SMTP HELO statement, but nothing I typed seemed to make it anywhere. Inbound and outbound ssh connections would reach 'ESTABLISHED', but then wouldn't make it to the point of prompting me for a password. Nothing apparent in any log files or anything. Info attached, more availible upon request. Stephen Linux version 2.4.1-pre2 (root@gw2-snowman) (gcc version 2.95.3 20010111 (prerelease)) #1 SMP Mon Jan 15 12:59:07 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0feec000 @ 0010 (usable) BIOS-e820: 3000 @ 0ffec000 (ACPI data) BIOS-e820: 0001 @ 0ffef000 (reserved) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. mapped APIC to e000 (01444000) Kernel command line: auto BOOT_IMAGE=Linux ro root=301 Initializing CPU#0 Detected 655.851 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1307.44 BogoMIPS Memory: 255292k/262064k available (1062k kernel code, 6384k reserved, 429k data, 200k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU0: AMD Athlon(tm) Processor stepping 00 per-CPU timeslice cutoff: 182.95 usecs. SMP motherboard not detected. Using dummy APIC emulation. Setting commenced=1, go go go PCI: PCI BIOS revision 2.10 entry at 0xf1010, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket DMI 2.3 present. 49 structures occupying 1371 bytes. DMI table at 0x000F27D0. BIOS Vendor: Award Software, Inc. BIOS Version: ASUS A7V ACPI BIOS Revision 1003 BIOS Release: 07/21/2000 System Vendor: System Manufacturer. Product Name: System Name. Version System Version. Serial Number SYS-1234567890. Board Vendor: ASUSTeK Computer INC.. Board Name: . Board Version: REV 1.xx. Asset Tag: Asset-1234567890. Starting kswapd v1.8 pty: 256 Unix98 ptys configured RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: enabling 8 loop devices Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:pio PDC20265: IDE controller on PCI bus 00 dev 88 PCI: Found IRQ 10 for device 00:11.0 PDC20265: chipset revision 2 PDC202
Re: MTRR type AMD Duron/intel ?
On Mon, 15 Jan 2001, Linus Torvalds wrote: > On Mon, 15 Jan 2001, Tobias Ringstrom wrote: > > > > Last time I checked this was issued for perfectly known and valid bridges > > that advertice no IO resources. Isn't it a bit silly to issue that > > warning for that case, or am I missing something? > > Ehh - so what do they bridge, then? > > I'd say that a bridge that doesn't seem to bridge any IO or MEM region, > yet has stuff behind it, THAT is the silly thing. Thus the "silly" > warning. I'm talking about bridges that bridge memory, but not io, which is quite common. (AGP bridges) I do not have my PCI book right now, but there are two registers, basically io_base and io_limit, and if io_limit == io_base-1, that means that no io is bridged. I still think its silly. ;-) /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The latest instance in the A20 farce
"Albert D. Cahalan" wrote: > > It looks like we let Microsoft fill the design guide void. > If you were to write "PC DESIGN GUIDE - For the Linux Operating > System" and a pile of test code, then there would be an > alternative to point people at. > > Complaining is pretty useless. I was thinking about this today. If we write a Linux design guide, even as a delta spec, does anyone think it will be listed to? -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MTRR type AMD Duron/intel ?
On Mon, Jan 15, 2001 at 11:52:12AM -0800, Linus Torvalds wrote: > On Mon, 15 Jan 2001, Tobias Ringstrom wrote: > > Last time I checked this was issued for perfectly known and valid bridges > > that advertice no IO resources. Isn't it a bit silly to issue that > > warning for that case, or am I missing something? > > Ehh - so what do they bridge, then? > > I'd say that a bridge that doesn't seem to bridge any IO or MEM region, > yet has stuff behind it, THAT is the silly thing. Thus the "silly" > warning. Like a cardbus controller without any cards in ? My IBM laptop reports that at the TI PCI1450 bridges, when I don't have anything plugged in. > Linus /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-x features ?
Pierre Rousselet writes: > 1) top (procps-2.0.7) gives me the messages : > 'bad data in /proc/uptime' > 'bad data in /proc/loadavg' > cat /proc/uptime > 1435.30 904.74 > cat /proc/loadavg > 0.01 0.21 0.29 1/17 19444 > What is wrong ? Which 2.4.0-x kernel, and how was procps compiled? (the broken gcc again perhaps?) You might as well get procps-010114.tar.gz (new just yesterday!) and compile it yourself. The top command seems to tolerate Red Hat's fixed gcc, which you should get if you are using Red Hat 7. http://www.cs.uml.edu/~acahalan/procps/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: patch:reiserfs 3.6.25 + LVM(Fix oops reiserfs filesystem)
On Saturday, January 13, 2001 11:41:51 PM -0800 hugang <[EMAIL PROTECTED]> wrote: [ patch ] Odd, the create_vi op should never be null, so the real fix is somewhere else. We'll look into this. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MTRR type AMD Duron/intel ?
On Mon, 15 Jan 2001, Tobias Ringstrom wrote: > > Last time I checked this was issued for perfectly known and valid bridges > that advertice no IO resources. Isn't it a bit silly to issue that > warning for that case, or am I missing something? Ehh - so what do they bridge, then? I'd say that a bridge that doesn't seem to bridge any IO or MEM region, yet has stuff behind it, THAT is the silly thing. Thus the "silly" warning. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MTRR type AMD Duron/intel ?
Tobias Ringstrom wrote: > > On Mon, 15 Jan 2001, David Balazic wrote: > > > It also reports something like : > > PCI chipset unknown : assuming transparent > > Are you sure it's not > > Unknown bridge resource 0: assuming transparent Might be, I don't remember the exact wording. -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
On Sat, Jan 13, 2001 at 12:01:04PM +1100, Andrew Morton wrote:
> Tim Wright wrote:
[...]
> > p_lock(lock);
> > retry:
> > ...
> > if (condition where we need to sleep) {
> > p_sema_v_lock(sema, lock);
> > /* we got woken up */
> > p_lock(lock);
> > goto retry;
> > }
> > ...
>
> That's an interesting concept. How could this actually be used
> to protect a particular resource? Do all users of that
> resource have to claim both the lock and the semaphore before
> they may access it?
>
Ahh, I thought I might have been a tad terse in my explanation. No, the
idea here is that the spinlock guards the access to the data structure we're
concerned about. The sort of code I was thinking about would be where we need
to allocate a data structure. We attempt to grab it from the freelist, and if
successful, then everything is fine. Otherwise, we need to sleep waiting for
some resources to be freed up. So we atomically drop the lock and sleep on
the allocation semaphore. The freeing-up path is also protected by the same
lock, and would do something like 'if (there are sleepers) wake(sleepers)'.
This wakes up the sleeper who grabs the spinlock and retries the alloc. The
result is no races, but we don't spin or hold the lock for a long time.
It doesn't have to be an allocation. The same idea works for e.g. protecting
access to "buffer cache" (not necessarily Linux) data, and then atomically
releasing the lock and sleeping waiting for an I/O to happen.
>
> There are a number of locks (such as pagecache_lock) which in the
> great majority of cases are held for a short period, but are
> occasionally held for a long period. So these locks are not
> a performance problem, they are not a scalability problem but
> they *are* a worst-case-latency problem.
>
Understood. Whether the above metaphor works depends on whether or not the
"holding for a long time" case fits this pattern i.e. at this stage,
I'm not sufficiently familiar with the Linux VM code. I'm in the process
of rectifying that problem :-)
Regards,
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Disk geometry changed after running linux
On Mon, Jan 15, 2001 at 07:54:47PM +0100, David Balazic wrote: > Is there a way to change the geometry from fdisk ? > I tried expert mode and 'set sectors' and 'set heads', > but after I exit fdisk with 'w' , it is unchanged. As you know, a disk does not have a geometry, but the location of a partition is described in linear and 3D coordinates, and translating between the two requires a geometry. Commands like % sfdisk -d /dev/hdf > hdf.pt % sfdisk /dev/hdf < hdf.pt suffice to make the translation uniform for the kernel's current idea of sectors, heads. If you don't like that idea, then -C,-H,-S options serve to tell sfdisk about the desired geometry. See sfdisk(8). [Save a copy of the old situation, and make the geometry so that Windows likes it. Linux is happy with every geometry.] Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MTRR type AMD Duron/intel ?
On Mon, 15 Jan 2001, David Balazic wrote: > It also reports something like : > PCI chipset unknown : assuming transparent Are you sure it's not Unknown bridge resource 0: assuming transparent (which is just about every kernel log I have seen...) Last time I checked this was issued for perfectly known and valid bridges that advertice no IO resources. Isn't it a bit silly to issue that warning for that case, or am I missing something? /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
On Mon, 15 Jan 2001, Jonathan Thackray wrote: > It's a very useful system call and makes file serving much more > scalable, and I'm glad that most Un*xes now have support for it > (Linux, FreeBSD, HP-UX, AIX, Tru64). The next cool feature to add to > Linux is sendpath(), which does the open() before the sendfile() all > combined into one system call. i believe the right model for a user-space webserver is to cache open file descriptors, and directly hash URLs to open files. This way you can do pure sendfile() without any open(). Not that open() is too expensive in Linux: m:~/lm/lmbench-2alpha9/bin/i686-linux> ./lat_syscall open Simple open/close: 7.5756 microseconds m:~/lm/lmbench-2alpha9/bin/i686-linux> ./lat_syscall stat Simple stat: 5.4864 microseconds m:~/lm/lmbench-2alpha9/bin/i686-linux> ./lat_syscall write Simple write: 0.9614 microseconds m:~/lm/lmbench-2alpha9/bin/i686-linux> ./lat_syscall read Simple read: 1.1420 microseconds m:~/lm/lmbench-2alpha9/bin/i686-linux> ./lat_syscall null Simple syscall: 0.6349 microseconds (note that lmbench opens a nontrivial path, it can be cheaper than this.) nevertheless saving the lookup can be win. [ TUX uses dentries directly so there is no file opening cost - it's pretty equivalent to sendpath(), with the difference that TUX can do security evaluation on the (held) file prior sending it - while sendpath() is pretty much a shot into the dark. ] Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
MTRR type AMD Duron/intel ?
A recent 2.4.0 ( not the final , but close ) kernel prints this : mtrr: detected mtrr type: intel I have an AMD K7 Duron 700 CPU Is this correct ? It also reports something like : PCI chipset unknown : assuming transparent I have a VIA KT133 chipset -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The latest instance in the A20 farce
H. Peter Anvin writes: > "Maciej W. Rozycki" wrote: >> On Wed, 10 Jan 2001, H. Peter Anvin wrote: >>> URRRK. I get a feeling these specs are either there to make life extra >>> difficult for programmers, because the people that design them are too >>> stupid to tie their own shoes, or because they want nothing but M$ >>> factory-installed to work. >> >> The page is titled "PC DESIGN GUIDE - For the Microsoft Windows >> Family of Operating Systems," so what do you expect? > > Kind of says it all, doesn't it? It looks like we let Microsoft fill the design guide void. If you were to write "PC DESIGN GUIDE - For the Linux Operating System" and a pile of test code, then there would be an alternative to point people at. Complaining is pretty useless. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Caches, page coloring, virtual indexed caches, and more
Ralf Baechle <[EMAIL PROTECTED]> writes: > On Mon, Jan 15, 2001 at 01:41:06AM -0700, Eric W. Biederman wrote: > > (Cc list truncated since probably not so many people do care ...) > > > shared mmap. This is the important one. Since we have a logical > > backing store this is easy to handle. We just enforce that the > > virtual address in a process that we mmap something to must match the > > logical address to VIRT_INDEX_BITS. The effect is the same as a > > larger page size with virtually no overhead. > > I'm told this is going to break software. Bad since it's otherwise it'd > be such a nice silver bullet solution. Heck if we wanted to we could even lie about PAGE_SIZE, and say it was huge. I'd have to have a clear example before I give it up that easily. mmap has never allowed totally arbitrary offsets, and mmap(MAP_FIXED) is highly discouraged so I'd like to see it. And on architectures that don't need this it should compile out with no overhead. > > > sysv shared memory is exactly the same as shared mmap. Except instead > > of a file offset you have an offset into the sysv segment. > > No, it's simpler in the MIPS case. The ABI guys were nice and did define > that the virtual addresses have to be multiple of 256kbyte which is > more than sufficient to kill the problem. If VIRT_INDEX_BITS == 18 and because you can only map starting at the beginning of a sysv shared memory segment this is exactly what my code boils down to. > > > mremap. Linux specific but pretty much the same as mmap, but easier. > > We just enforce that the virtual address of the source of mremap, > > and the destination of mremap match on VIRT_INDEX_BITS. > > Correct and as mremap doesn't take any address argument we won't break > any expecations on the properties of the returned address in mmap. > > > kmap is a little different. using VIRT_INDEX_BITS is a little > > subtle but should work. Currently kmap is used only with the page > > cache so we can take advantage of the page->index field. From page->index > > we can compute the logical offset of the page and make certain the > > page mapped with all VIRT_INDEX_BITS the same as a mmap alias. > > Yup. It gets somewhat tricker due to the page cache being in in KSEG0, > an memory area which is essentially like a 512mb page that is hardwired > in the CPU. It's preferable to stick with since it means we never take > any TLB faults for pages in the page cache on MIPS. Good. Then we don't need (at least for mips) to worry about this case. I was just thinking through the general case. > > kmap and the swap cache are a little different. Since index holds > > the location of a page on the swap file we'd have to make that index > > be the same for VIRT_INDEX_BITS as well. > > > > That's a possible solution; I'm not clear how bad the overhead would be. > > > Right now a virtual alias is a relativly rare event and we don't want the > > > common case of no virtual alias to make pay a high price. Or? > > > > I guess the question is how big would these logical pages need to be? > > Depending of the CPU 8kb to 32kb; the hardware supports page sizes 4kb, 16kb, > 64kb ... 16mb. If all you need is 32kb that is better than the 256K number I had in my head. Still as far as an application is concerned the results are the same as my silver bullet above. > > Answer big enough to turn your virtually indexed cache into a > > physically indexed cache. Which means they would have to be cache > > size. > > For above mentioned CPU versions which have 8kb rsp. 16kb per primary cache > we want 32kb as mentioned. > > > Increasing PAGE_SIZE a few bits shouldn't be bad but going up two > > orders of magnitude would likely skewer your swapping, and memory > > management performance. You'd just have way to few pages. > > > > But I have a better suggestion so see above. > > > O.k. this is scratched off my list of possible good ideas. Duh. This > > fails for exactly the same reason as increasing as increasing page > > size. at 256K cache and 4K PAGE_SIZE you'd need 256/4 = 64 different > > types of pages, fairly nasty. > > You say it; yet it seems like it could be part of a good solution. Just > forcefully allocating a single page by splitting a large page and before > that even swapping until we can actually allocate a higher order page is > bad. I totally agree. Larger pages don't suck but are unnecessary. At least I haven't been convinced otherwise yet. > > Hmm. This doesn't sound right. And this sounds like a silly way to > > use reverse mappings anyway, since you can do it up front in mmap and > > their kin. Which means you don't have to slow any of the page fault > > logic up. > > Then how do you handle something like: > > fd = open(TESTFILE, O_RDWR | O_CREAT, 664); > res = write(fd, one, 4096); > mmap(addr, PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); > mmap(addr + PAGE_SIZE, PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd
Re: [SOLVED + PATCH] Re: Anybody got 2.4.0 running on a 386 ?
On Mon, 15 Jan 2001, Robert Kaiser wrote: > > I finally found the reason why 386es have trouble booting the 2.4.0 kernel: Good job. > Pentiums are only lucky to not crash because they have a bigger TLB than 386s. Actually, with the 4M pages, it's not a question of luck any more - they just don't _have_ this bug, because on a machine with 4M pages the "cpu_has_pse" case handles this all and the buggy code is never actually entered. Which explains why you'd only see this on a 386 (and I suspect your TLB size explanation is what saved some i486-class machines, although later i486 machines will have PSE as well). Thanks, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problems with bigblock support of fat
I encounted really bad problems with 2048 Bytes/sec MO-Drive. I'm using an Olympus PowerMO 640. 230MB Media works fine, but if i try to use 640(2048B/S) medias i'm really in troubles. Looks quite the same as the problems i've reported for the 2.1.x kernels some time ago. (2.2.17/18 works fine 4 me). OK, what i did : Using kernel 2.4.0 on an Athlon TB 750 with 128 MB MO was formated with FAT32. i mounted the mo drive ... i try to read a file from it (used : 'pico /mo/file.txt') ... And got a nice crash : Segmentation Fault OK, was easy to find this bug, fs/fat/cvf.c has a bug in bigblock_cvf struct the field with the read function was a NULL. I changed this to generic_file_read (like with default blocksize), and tested it. First seemed to work fine, but : I could read/write a file now, but the written data was not compatible with DOS Systems (Tested under DOS6.22, WIN98SE) ! If i write a file to an empty MO-Disk, the start-cluster is 2 in the table. But the real data was written to (and also read from) cluster 33 by linux ! I already posted this report to the maintainer of the fat-fs(Gordon Chaffee) a month ago, but i did not get a response yet. (tested it with kernel -test8 and -test9) Robert Reither8925573 E754 (ja wirklich schon !!) TU-Vienna AUSTRIA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Slot Number Question
My adapter configuration utility needs to instruct the user which physical adapter needs attention ( when there may be multiple adapters in the system ).My question is : How do I determine the ( machine ) slot number of a PCI adapter ? In BIOS and other OS's this may be doneby examining the system's PCI Routing Tables.I don't think I can get to those from Linux. PCI Devices are defined by BUS, DEVICE, and FUNCTION.In Linux there is a function ( defined in pci.h near the end of the file ) called " PCI_SLOT( devfn ) " but from what I can see this returns what PCI calls the device. PCI device is not the machine's slot number. This function even uses the encoded byte which is named devfn ( I assume from PCI device and PCI function ) , but this function treats it as slot and function. Any help is appreciated. Thanks in advance. Jack L. Hammer RAID Client/Server Development IBM Personal Systems Group (919)-254-8665 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
