Re: What is up with Redhat 7.0?
On Mon, 2 Oct 2000 21:40:59 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Why didn't the package maintainer issue a formal release, if they really > thought it was the best thing for RedHat to be using Perhaps you're getting Redhat confused with Debian here. Redhat doesn't have package maintainers. It has 1,000 monkeys at 1,000 typewriters recreating the works of Shakespeare, a la "it was the best of times, it was the blurst of times" One reason I stopped running and recommending Redhat was the inferior quality of their packages. They'd ship half-complete, half-assed packages and it was concerned end-users who'd have to make their own RPMS and kindly make them available to the world, to fix the irritating stupid bugs in the default Redhat ones. Of course, some enlightened Redhat employee will no doubt tell me I should register bug reports about their packages through official channels blah blah blah which is no use when you do that and the bug reports are ignored for over six months while Redhat are off promoting themselves at one conference or another, arse-kissing for more shareholders while at the other end screwing over the people that put them into the position they could IPO in in the first place. There's noone responsible for a package, unlike Debian (the other extreme) where each package has a maintainer who is responsible for making sure that package is reliable, security-conscious and integrates well into the rest of the system. With RH you just submit bug reports to some tracking system and three revisions down the track somebody will get back from self-promotion at whatever conference and go "damn, there's a lot of bug reports, I might look at one or two then delete the rest" and maybe your bug is one of the lucky two, so you and the millions of other Redhat users don't have to manually fix it next time. That might not be quite how it works now (and for their sake, I hope not), but it sure looks that way from the outside, from the eyes of a former loyal customer. That, combined with the fact they somehow managed to get a hold of certain key kernel developers so stable linux kernel developments by their competitors don't get integrated into the stable kernel (eg, reiserfs & a better VM for 2.2, both sponsored in part or full by SuSE) really ticks me off as a person who cares more about a quality, useful Linux in general and not about generation of revenue for shareholders at the expense of all else. I'm not surprised Redhat 7.0 is full of bugs, everybody should know by now that you have to wait for 7.2 so the SuSE and Debian guys have time to fix some of the bugs in the initial release. BUGTRAQ is usually hard to ignore... Oh yeah, I posted these and a few other concerns not really worth repeating to this list for topic/breveties sake, to the appropriate channels @redhat three years ago and, surprise surprise, was ignored just like every other legitimate bug report or compalint. Maybe a public post when an obvious outcome of their problems they haven't addresed over this time becomes headlines might spur someone into action over there. I'd really really hate to see Redhat go under, which is the ultimate eventuality I feel if they continue down this course. Redhat do a lot of good things in other areas which is good for Linux as a whole. Unfortunately quality isn't one of them, neither is support. Erik, Bob, Mike.. guys.. please fix. For many people Redhat == Linux and we need to show that Linux == great, not Linux == mediocre. Make use of the community, eg Linuxcare might be a good choice to outsource support to so you can forget about that bit to some extent and concentrate on other bits. Just some suggestions, I'm trying to be constructive :) Cheers, -- Matt (speaking for myself, not my company) PS: Yes, Alan, I'm a paranoid loon, just like the many many other paranoid loons who have observed exactly the same things, said it out of concern for you and the other usually good guys there, and get labelled... - To unsubscribe from this list: send 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: Tux2 - evil patents sighted
IANAL That said, I would refer anyone interested in 'prior art' in patents to http://www.ipmall.fplc.edu/ipcorner/bp98/welch.htm especially the brief discussion on what 'prior art' is to the patent office. Also, for those who believe that similar concepts will void patents, I would suggest a search of the IP literature on the topic of 'narrowly defined.' As to whether or not Network Appliance's patents would hold up in court, I offer two contradictory opinions: Factoid: 90% of all patents are never challenged, while 80% of those that are are overturned. and "Going into court is throwing the dice." I will defer discussion of the 'evil' of patent law to some more appropriate forum. Marty - To unsubscribe from this list: send 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: What is up with Redhat 7.0?
On Mon, 2 Oct 2000, Marc Lehmann wrote: >Date: Mon, 2 Oct 2000 14:09:33 +0200 >From: Marc Lehmann <[EMAIL PROTECTED]> >To: Horst von Brand <[EMAIL PROTECTED]> >Cc: [EMAIL PROTECTED] >Content-Type: text/plain; charset=us-ascii >Subject: Re: What is up with Redhat 7.0? > >On Sun, Oct 01, 2000 at 09:33:31PM -0400, Horst von Brand ><[EMAIL PROTECTED]> wrote: >> > many others. >> >> What makes Debian's package management "reasonable" where others aren't? > >This *really* doesn't belong on linux-kernel. And severely biased groundless pointless Red Hat bashing does? -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- #[Mike A. Harris bash tip #1 - separate history files per virtual console] # Put the following at the bottom of your ~/.bash_profile [ ! -d ~/.bash_histdir ] && mkdir ~/.bash_histdir tty |grep "^/dev/tty[0-9]" >& /dev/null && \ export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre13: eepro100 debug tweaks
On Mon, Oct 02, 2000 at 02:16:56PM -0700, Chip Salzenberg wrote: > Patch: eepro100-speedo-debug-1 > From: Dragan Stancevic <[EMAIL PROTECTED]> > > Debugging tweaks for eepro100 driver: > * Add ioctl to adjust speedo_debug. > * Print diagnostic when Tx ring fills up. > * Adjust debugging level of interrupt diagnostics. These debug output adjustments don't really buy a lot. Dragan has a couple of real fixes which are in my working copy of the driver now. > * Eliminate compilation warning. [snip] > +/* > + * This might fix initialization problems. --Dragan > + */ > +#define USE_IO 1 > + Well, what about some assistance in really fixing the initialization problem? :-) I'm stuck with the experimental proof that the initialization goes south after flow control pause interrupt (which manages to happen with the flow control being explicitly disabled). Andrey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
TEST9-PRE9: CMD649 UDMA ATA Controller = irq timeout
Hello
all, Having some trouble setting up my new
CMD649 based UDMA 100 ATAcontroller under Linux. Every time DMA is
enabled a kernel error messagelike this is
displayed:
hde: timeout waiting for
DMA
ide_dmaproc: chipset supported ide_dma_timeout func only:
14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest
}
hde: DMA disabled I've altered the hardware
configuration/cables etc and tried a fewpatch levels with the latest being
TEST9-PRE9. Same type of errors withall
configurations. The help screen for CMD64X in the kernel
configuratordoesn't even include CMD649 (only CMD648 for example) so maybe
this thing istoo new for Linux support? Anyway, I'd be
happy to test any and allpatches sent my
way..===[Boot
Messages]Linux version 2.4.0-test9 (root@mach110) (gcc version
egcs-2.91.6619990314/Linux (egcs-1.1.2 release)) #1 Mon Oct 2
20:54:20 EDT 2000BIOS-provided physical RAM map: BIOS-e820:
0009fc00 @ (usable) BIOS-e820:
0400 @ 0009fc00 (reserved) BIOS-e820:
0001 @ 000f (reserved) BIOS-e820:
0001 @ (reserved) BIOS-e820:
09f0 @ 0010 (usable)On node 0 totalpages:
40960zone(0): 4096 pages.zone(1): 36864 pages.zone(2): 0
pages.Kernel command line: auto BOOT_IMAGE=test9c ro
root=306BOOT_FILE=/boot/vmlinuz-2.4-test9cInitializing
CPU#0Detected 200.456 MHz processor.Console: colour VGA+
80x25Calibrating delay loop... 399.77 BogoMIPSMemory: 159248k/163840k
available (1028k kernel code, 4204k reserved, 68kdata, 1 76k init, 0k
highmem)Dentry-cache hash table entries: 32768 (order: 6, 262144
bytes)Buffer-cache hash table entries: 8192 (order: 3, 32768
bytes)Page-cache hash table entries: 65536 (order: 6, 262144
bytes)Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)CPU:
Intel Pentium MMX stepping 03Checking 'hlt' instruction... OK.Intel
Pentium with F0 0F bug - workaround enabled.POSIX conformance testing by
UNIFIXPCI: PCI BIOS revision 2.10 entry at 0xfb300, last bus=0PCI: Using
configuration type 1PCI: Probing PCI hardwarePCI: Using IRQ router PIIX
[8086/7000] at 00:01.0Limiting direct PCI/PCI transfers.Linux NET4.0 for
Linux 2.4Based upon Swansea University Computer Society NET3.039NET4:
Unix domain sockets 1.0/SMP for Linux NET4.0.NET4: Linux TCP/IP 1.0 for
NET4.0IP Protocols: ICMP, UDP, TCPIP: routing cache hash table of 1024
buckets, 8KbytesTCP: Hash tables configured (established 16384 bind
16384)Starting kswapd v1.8pty: 256 Unix98 ptys configuredUniform
Multi-Platform E-IDE driver Revision: 6.31ide: Assuming 33MHz system bus
speed for PIO modes; override with idebus=xxPIIX4: IDE controller on PCI bus
00 dev 09PIIX4: chipset revision 1 ide0: BM-DMA at
0xf000-0xf007, BIOS settings: hda:pio, hdb:pioCMD649: IDE controller on PCI
bus 00 dev 60CMD649: chipset revision 1CMD649: not 100% native mode:
will probe irqs later ide1: BM-DMA at 0x7800-0x7807, BIOS
settings: hdc:pio, hdd:pio ide2: BM-DMA at 0x7808-0x780f,
BIOS settings: hde:pio, hdf:piohda: JTS Corp. CHAMP Model C1300-2AF, ATA
DISK drivehdb: , ATAPI CDROM drivehde: Maxtor 54098H8, ATA DISK
driveide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xxide0 at 0x1f0-0x1f7,0x3f6 on irq 14ide2 at 0x7000-0x7007,0x7402
on irq 11hda: 2546208 sectors (1304 MB) w/128KiB Cache, CHS=1263/32/63,
DMAhde: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=79406/16/63,
UDMA(100)hdb: ATAPI 23X CD-ROM drive, 120kB Cache, DMAUniform CD-ROM
driver Revision: 3.11Partition check: hda: hda1 hda2 < hda5 hda6
> hde:hde: timeout waiting for DMAide_dmaproc: chipset supported
ide_dma_timeout func only: 14hde: irq timeout: status=0x58 { DriveReady
SeekComplete DataRequest }hde: timeout waiting for DMAide_dmaproc:
chipset supported ide_dma_timeout func only: 14hde: irq timeout: status=0x58
{ DriveReady SeekComplete DataRequest }hde: timeout waiting for
DMAide_dmaproc: chipset supported ide_dma_timeout func only: 14hde: irq
timeout: status=0x58 { DriveReady SeekComplete DataRequest }spurious 8259A
interrupt: IRQ7.hde: timeout waiting for DMAide_dmaproc: chipset
supported ide_dma_timeout func only: 14hde: irq timeout: status=0x58 {
DriveReady SeekComplete DataRequest }hde: DMA disabledide2: reset:
success unknown partition tableFloppy drive(s): fd0 is 1.44MFDC
0 is a post-1991 82077Serial driver version 5.02 (2000-08-09) with
MANY_PORTS SHARE_IRQ SERIAL_PCIenabled3c59x.c:LK1.1.9 2 Sep
2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.38 $See
Documentation/networking/vortex.txteth0: 3Com PCI 3c905B Cyclone 100baseTx
at 0x6400, 00:50:04:81:65:22, IRQ 10 8K byte-wide RAM 5:3 Rx:Tx
split, autoselect/Autonegotiate interface. MII transceiver found at
address 24,
test9-pre8 -- Question: SMP not yet supported for Athlon systems?
Hi, Yesterday I reported a problem compiling with SMP enabled for an Athlon-targetted kernel. I wonder whether this is because there are no Athlon SMP systems out there, yet? If so, then if the architecture selected is Athlon, the SMP option should not be available when configuring the kernel tree. If there are SMP Athlon machines, would someone please follow up on this compile error? Thanks, 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/
[OT]: Brooks and the kernel wiki
Alexander also makes a simple wrong assumption in his comparison of software and hypertext documents: Software must be logically consistent and its writers highly inter-co-ordinated or it simply won't work; a rough and non-linear post-modern web-accessible document has no such internal communication requirement. When you write a screenplay like this, you get 3 academy award nominations; when you write software like this, you get a cubicle in Redmond. Oh, yes, I totally agree that it would be very nice to have tight coherence throughout the document, but it is not strictly required. Best regards. -- "The only thing that is not art is inattention." - Marcel Duchamp Gary Lawrence Murphy <[EMAIL PROTECTED]>: office voice/fax: 01 519 4222723 T(!c)Inc Business Innovation through Open Source http://www.teledyn.com M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net - To unsubscribe from this list: send 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 priorities...
Hello, On Sun, Oct 01, 2000 at 12:45:47PM -0700, LA Walsh wrote: > Forgive me if this has been asked before, but has there ever been any > thought of having a 'nice' value for disk accesses?. I was on a > server with 4 CPU's but only 2 SCSI disks. Many times I'll see 4 processes > on disk wait, 3 of them at a cpu-nice of 19 while the foreground processes > get bogged down by the lower priority processes due to disk contention. I'm considering how disk "bandwidth" use by users may be controlled, and some coding has been started. But it's not what may be announced as a break-through yet. The main problems are: - what to consider as the resource? (I'm inclined to account for the time the requests of the given "user" are served by the disk) - how to ensure an acceptable level of fairness in the case of considerable amount of "users" (more precisely, subjects of accounting)? I think, the question is not about ensuring bounds on latency, and the request order should be determined by dynamic priorities of users in a large degree. Best regards Andrey V. Savochkin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 kernel wiki for October
Alexander Viro wrote: > > On 2 Oct 2000, Gary Lawrence Murphy wrote: > > > No excuses. _Everyone_ has that kind of time to spare for Linux > > documentation. There are hundreds of competent engineers active on > > this mailing list. One day's worth of our collective linux-kernel > > effort, focussed precisely on illuminating some part of the code, > > would complete several chapters of text. A week's worth would fill > > a thousand pages. > > > > If everyone gives just _10_ _minutes_ a month, > > we can _completely_ document 2.4 by groundhog day. > > Sigh... Do a search on Brook's Law, will you? You lose because the project isn't late yet ;-) You, by the way, are one of the people who could help more than almost anybody. Just cutting and pasting your locks documentation would already be a big help. If you did put it in, it would go here: http://kernelbook.sourceforge.net:80/wiki/?KernelSubsystems -- Daniel - To unsubscribe from this list: send 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: test9-pre9
On Tue, Oct 03, 2000 at 11:07:36AM +0900, Tom Holroyd wrote: > Alpha DP264 (UP) > > ld ... -o vmlinux > drivers/char/char.o: In function `rs_sched_event': > serial.c(.text+0x10210): undefined reference to `barrier' > serial.c(.text+0x10214): undefined reference to `barrier' > serial.c(.text+0x1022c): undefined reference to `barrier' > serial.c(.text+0x10230): undefined reference to `barrier' > serial.c(.text+0x10244): undefined reference to `barrier' > drivers/char/char.o(.text+0x10248):serial.c: more undefined references to > `barrier' follow > > config attached. > > This error existed in -pre8, too, but I sent the message to rutgers... As suggested days ago by Ivan, one solution is: - diff -urN old/include/asm-alpha/bitops.h new/include/asm-alpha/bitops.h --- old/include/asm-alpha/bitops.h Mon Oct 2 21:50:50 2000 +++ new/include/asm-alpha/bitops.h Mon Oct 2 22:38:25 2000 @@ -2,6 +2,7 @@ #define _ALPHA_BITOPS_H #include +#include /* * Copyright 1994, Linus Torvalds. - SMP compiles fine with or without this. --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 kernel wiki for October
On 2 Oct 2000, Gary Lawrence Murphy wrote: > No excuses. _Everyone_ has that kind of time to spare for Linux > documentation. There are hundreds of competent engineers active on > this mailing list. One day's worth of our collective linux-kernel > effort, focussed precisely on illuminating some part of the code, > would complete several chapters of text. A week's worth would fill > a thousand pages. > > If everyone gives just _10_ _minutes_ a month, > we can _completely_ document 2.4 by groundhog day. Sigh... Do a search on Brook's Law, will you? - To unsubscribe from this list: send 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] 2.4.0-test9-pre9: i810_rng only compiles as module, also ..
starting with the new test9-pre9, the i810_rng driver will not compile as part of the kernel -- only a module (see below). also, and more importantly, i can not get the driver working on my i815-based (ASUS CUSL2) mainboard. the i815's 802 FWH should not be different than the 810/820. i really want to try to hack this out, since i have the board ... in the mean time, anyone have any ideas about the i815 and the i810_rng driver? results of 'make bzImage' with CONFIG_INTEL_RNG as a module: gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -march=i686 -fno-strict-aliasing -c -o i810_rng.o i810_rng.c i810_rng.c: In function `rng_enable': i810_rng.c:384: warning: dereferencing `void *' pointer i810_rng.c:384: request for member `uc' in something not a structure or union i810_rng.c:386: warning: dereferencing `void *' pointer i810_rng.c:386: request for member `uc' in something not a structure or union make[3]: *** [i810_rng.o] Error 1 -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.2.17 3Com bug
Hi, I always ran into a very similar problem using 3com cards in a dual-boot environment with Windows. The solution which I discovered; which may or may not apply here; is that the card retains some kind of settings information from the os you are rebooting from, so when you reboot right into the next os (without completely powering down first) the incorrect settings are retained, effectively preventing or severely hindering the nic from operating correctly. You might check if you experience the problem when you completely power down between reboots. Again, this may not apply here, but I thought it was worth mentioning since this plagued me for a long while before I realized the obvious solution. Regards, Jim Goins [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of hdcool Sent: Monday, October 02, 2000 6:18 PM To: [EMAIL PROTECTED] Subject: 2.2.17 3Com bug Hello, I ran RedHat 6.2 and tried all sorts of kernels.. no problem at all. I ran kernel 2.2.17 and everytime MS-Windows has booted(I run a dual-boot sys) my networkcard (eth0=dhcp=3c59x.o) doesn't want to connect to the internet. First I thought this was my isp his fault or my redhat was broken. But this problem stayed. Now, I run Debian 2.2 kernel 2.2.17 and I have the same problem. When Windows has booted and I want to get back into linux, I have to wait half an hour until my networkcard works again. Now, I haven't had this problem before with older kernels, not even with 2.4.0-testx I don't know what to about this, maybe it's not a bug at all but I don't trust it. Summary: problem: no dhcp-lease at boot(have to wait almos half an hour) module: 3c59x Thanks for reading my mail Yours sincerely hdcool - To unsubscribe from this list: send 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: test9-pre9
Alpha DP264 (UP) ld ... -o vmlinux drivers/char/char.o: In function `rs_sched_event': serial.c(.text+0x10210): undefined reference to `barrier' serial.c(.text+0x10214): undefined reference to `barrier' serial.c(.text+0x1022c): undefined reference to `barrier' serial.c(.text+0x10230): undefined reference to `barrier' serial.c(.text+0x10244): undefined reference to `barrier' drivers/char/char.o(.text+0x10248):serial.c: more undefined references to `barrier' follow config attached. This error existed in -pre8, too, but I sent the message to rutgers... Dr. Tom Holroyd "I am, as I said, inspired by the biological phenomena in which chemical forces are used in repetitious fashion to produce all kinds of weird effects (one of which is the author)." -- Richard Feynman, _There's Plenty of Room at the Bottom_ config.gz
Re: Tux2 - evil patents sighted
Alan Cox wrote: > Its also very unlikely Network Appliance would both responding to you. Its > not in their legal interest to admit lack of validity. Yes, I know the game, Unisys played it with gif. Wait until it's in widespread use then appear out of the woodwork and demand licence fees. It's called submarining. It's evil. People and corporations who do it are little better than thugs. Well, my part of this is to make it public before the obvious improvements end up being the subject of patent applications. I'm a designer and inventor, I do it for the satisfaction, and patents make me sick. I could have had lots of patents, I've been there first on many occasions. This is purely because I was born before somebody else, or happened to get access to a real computer before somebody else did. I got there first and high-graded the easy stuff. So what? I didn't create the things I found, they were already there. I just dug them up. They belong to everybody. Ideas are like antiquities. If I dig them up, I get paid for digging, yes, I could and should get paid very well, but I don't own those antiquities: there are laws against that. Why are we enlightened in that respect, and so barbaric when it comes to intangible ideas? Simple: the common man isn't aware of the problem. The solution is equally simple: we have to educate people. How I don't know. We have to remember, we're doing this to ourselves. We're being fooled into doing this to ourselves by the myth of the lone inventor striking it rich. People like that myth, it plays well and they'll justify it to the ends of the earth. Perhaps they will stop if they learn how much it is costing them. There, I feel better now. I've stated the problem, lets see if any good comes of it. I'll go back to work on my slides. -- Daniel - To unsubscribe from this list: send 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: Soft-Updates for Linux ?
Andreas Dilger wrote in part: > > Albert Cahalan write: > > The nice way to develop this code is with a block device that > > discards all writes after a timer goes off. This is nice, but a bit destructive for my likes. Hard and long to do multiple tests. Also, it misses one severe case: an inode overwritten with trash at the momemt of powerfail. > I made a patch to the loopback device which allows you to discard I/Os > going to disk. You can either activate it via an ioctl from user space, > or via a function call in the kernel. Neat. > You can also make reads fail, but this was not very useful for me, because > it caused the ASSERTs in ext3 to oops. Also the read "failures" are not > the same as the real thing, so it may not be a valid test. They only > return a zero'd page, rather than really causing a non-up-to-date page. I think read failures are the way to go. Non-destructive, and you can simulate the `fsck` by reading through an artificial /dev/dirty. The trick, of course, would be in writing /dev/dirty. You could do it by statistically examining the write buffer cache. Or you could do it by recording (journalling-ack!) all overwritten data prior to time T, (umount) and having /dev/dirty return the old inodes during fsck. For added fun, /dev/dirty could chose to 'read error' any selected inode like the superblock, or perhaps worse, /lib metadata. With this technique, using the real `fsck` in no-mod, output only mode, you could run quite a number of simulated crashes quickly. Maybe even Monte Carlo with enough RAM (1+GB) to load a reasonable sized fs in RAM. -- Robert -- Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
Date: Sat, 30 Sep 2000 15:07:49 +0100 (BST) From: Alan Cox <[EMAIL PROTECTED]> > If you don't like this, I suggest you send mail complaining to RedHat. > Customer complaints are going to be the only way that RH is going to be > influenced not to play games like this Remind me next time I get to deal with crap from VA customers because VA shipped unusable NFS patches and broken PIII FXSAVE code that I'd vetoed from RH kernels to send them your mail Ted. Talk about the pot calling the kettle black. I think you owe an apology We all ship buggy code from time to time, despite our best efforts to avoid it. And I certainly appreciate it when other people cover for mistakes I or my company makes. I try to do the same, such as when I had to cover for Debian users when they screwed up e2fsprogs during the a.out -> glibc transition. (Also, if I recall correctly, there was at least one case where a version of the busted PIII FXSAVE patch made it into a shipping RH kernel, and we had to remove it, but that's neither here nor there.) This is completely beside the point I was trying to make, though. I was trying to say that by having Red Hat ship weird snapshots of things which have ABI implications (such as some arbitrary snapshot of gcc with C++ ABI issues), or things which _might_ have ABI implications (such as the pre-release of glibc 2.2 (*) --- this hurts the Linux community. It makes life arbitrarily harder for other ISV's who need to be stable ABI so they can write to a standard Linux paltform. It also makes life harder for other distributions, who at least for the moment seem to think that they have to Red Hat binary compatible because their customers demand it. So the other distributions end up having to take the same arbitrary snapshot as what RH chose, which from the outside seems like it's done completely outside of the package author/maintainer's control. (i.e., Why didn't the package maintainer issue a formal release, if they really thought it was the best thing for RedHat to be using --- especially when the package maintainer in many cases is employed by Red Hat?) Certainly the LSB will hopefully solve many of these problems. Unfortunately, the LSB isn't ready yet. Getting more people to help work on the LSB would be a big help on that score. - Ted (*) I note Ulrich has yet to make a public statement guarateeing that there won't be any ABI compatibility problems between RH 7.0 and glibc 2.2. I am still hoping there won't be any (knock on wood) - To unsubscribe from this list: send 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: Tux2 - evil patents sighted
> patent restrictions. Unfortunately for Network Appliances, I developed > all the essential concepts they describe in 1989 (the RAID optimization > excepted, see below for what I think about that) and implemented them in > a production system. In other words, I've got prior art; their patents > are worthless. Furthermore, I developed the entire Tux2 design and Not neccessarily. It depends why they took them out. It is common in the US to patent something that you suspect isnt original just so nobody else patents it and attacks you (fun isnt it). And they may genuinely think they are original. Its also very unlikely Network Appliance would both responding to you. Its not in their legal interest to admit lack of validity. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Tux2 - evil patents sighted
Thomas Graichen forwarded me some interesting information from the freebsd-fsdevel list regarding 3 patents held by Network Appliance, Inc., Santa Clara, CA that seem to describe much of the mechanism that underlies Tux2. I haven't heard anything from any representative of Network Appliance, which I find very curious because they must certainly have heard of Tux2 by now. But of course when I do hear from them they will want something, and I will want them to FOAD. http://patent.womplex.ibm.com/details?=US05819292__ http://patent.womplex.ibm.com/details?=US05963962__ http://patent.womplex.ibm.com/details?=US06038570__ It is important that all technology used in GPL software be free of patent restrictions. Unfortunately for Network Appliances, I developed all the essential concepts they describe in 1989 (the RAID optimization excepted, see below for what I think about that) and implemented them in a production system. In other words, I've got prior art; their patents are worthless. Furthermore, I developed the entire Tux2 design and implemented most of it before I ever even heard of their software, much less their patents. And on top of that, other people also have prior art (check out Auragen, if you don't know what it is, ask Victor Yodaiken). OK, I sense there's going to be a fight, because Network Appliance is a profit-making corporation and they would be remiss if they didn't try to defend their IP. Did I mention that software patents are evil? Did I mention that software patents make people behave in evil ways? I'm not going to change my course at all, I'm determined to bring this better idea to Linux in a free and open way. I will continue to develop it until it's finished. Oh, and the phase tree algorithm is fundamentally superiour to their WAFL algorithm, as I will demonstrate next week in Atlanta. I invite anyone who's interested to email me and help out. Are you a patent lawyer that likes to work for free? *Especially you*, please email me. Now let me state my position on patents: - Patents are evil - Software patents are especially evil - Patents, and especially software patents, constitute nothing less than government-sponsored theft of property that properly belongs to humanity. - If we did not have any form of patent, humanity would be better off. - If we did not have any form of patent, the world economy would benefit. Yes, that means corporations too. - If we did not have any form of patent, *most voters would benefit* <-- pay close attention to this one - Patents are anti-capitalist: they interfere with the proper functioning of the market economy. Patents on business methods are already rearing their ugly head. - It's getting worse. If the current trend continues, you will soon see the life of patents being extended, you will see patents being granted in areas that were previously considered off-limits, and you will see countries outside the U.S. being pressured into supporting the patent system in various ways. - We can't change the world overnight, but we do already possess the power, if we excercise it, to send the laws that gave birth to software patents back into the cesspool they crawled out of. - In spite of the popular myth about the lone inventor who strikes it rich, the only real beneficiaries of patents are corporations. Yes, a few lone inventors strike it rich, but not enough to undo the damage done to humanity in general. Most lone inventors just get ripped off by people who prey on them and their dreams. - If all patents were to vanish today and never come back research in general would accelerate, not slow down. Linux is proof of that. - Lawyers built the patent system. Tim O'Rielly once asked a patent lawyer how he would feel if other lawyers could patent legal arguments and charge him money to use those arguments in court. Though he tried to twist out of answering that one, eventually he had to admit that he had no answer. This lawyer IIRC is the director of the U.S. Trade and Patent office. OK, I'll stop ranting now. I knew it was going to happen, and not only that, this is going to happen more and more until the evil patent system is uprooted and composted. Now, the specifc discussion: US patent 5,819,292 "Method for maintaining consistent states of a file system and for creating user-accessible read-only copies of a file system"; ApplDate 1993-06-03 <- Four years after I did my work. "A method is disclosed for maintaining consistent states of a file system. The file system progresses from one self-consistent state to another self-consistent state. The set of self-consistent blocks on disk that is rooted by a root inode is referred to as a consistency point. The root inode is stored in a file system information structure. To implement consistency points, new data is written to
test9-pre9
Noticeable: the IDE initialization, more VM work, and MD should work in every configuration. Famous last words. Linus - - pre9: - USB: documentation. - Yeah. MD/LVM should really be fixed this time. - SH architecture update - i810 RNG driver update - IDE-PCI: make sure we initialize the chipsets correctly - VIA IDE driver fixes - VM balancing, part 53761 of 798321 - SCHED_YIELD cleanups - pre8: - initialize to zero -> put it in the .bss instead - no extended dumb serial driver options, if no dumb serial driver - access() on a special file on a read-only filesystem is special. - DRM update - fix SCHED_YIELD problems. - quintela: fix the synchronous wait on kmem_cache_shrink(). This should fix the mmap02 lockup. - syncppp got lost in the Makefile reshuffle. Unlose it. - firewire update - flock blocking list fix - correct watchdog initialization order - USB-storage: reset fixes. Race condition fixes. - USB: fix freeing already free'd device. - minix truncate fixes - USB: pack only the relevant subset, not the whole descriptor (so as to not create extra unaligned fields). - nfsfh: DCACHE_NFSD_DISCONNECTED checking typo - dquota silly bugfix - sound updates (get rid of check_region, check request_region() instead) - scsihosts boottime parameter passing - avoid double init of MD - eicon ISDN driver update - fix Cyrix MTRR thinko - toshiba driver 2.4.x update - Makefile subdirectory traversal cleanup and documentation - cciss typos from bad merge fixed - cdrom driver oops fix for CONFIG_SYSCTL=y CONFIG_PROC_FS=n - coda initialization - we already did the module_init, no need for the extra double init. - pre7: - USB: remember to release the kernel lock and other updates.. - recognize the k6 model 13: it's a K6-2+ mobile processor. - file locking deadlock detection bugfix.. - NFSv3 is not really really experimental any more. - don't raise privileges when re-trying a failed NFS RPM request - alpha cross-compile fixes.. - sound init cleanups - shm statistics bugfix. - nfsd: mark us as a O_LARGEFILE case, so that the VFS allows the full 64-bit access.. - fix up ac97 codec initialization - Ingo: clean up VM handling, improve balancing. - add SGI PCI ID's. - export the new lock copy/init functions - cs4281 sound driver - official Compaq CISS driver. - pre6: - TUN/TAP driver: use proper device number (misc device, minor=200). - teach st.c about some SCSI tapes that really aren't SCSI tapes (OnStream) - samba 2.2 needs leases for efficient file sharing. They are kind of like file locks with async IO notification. - broadcast I/O APIC interrupt MP-tables are legal.. - alpha RTC year magic again.. - careful memory ordering by Andrea.. - make the scsi-generic module work properly again. - file locking fixes - update atp ISA net driver - VIA IDE driver bugfixes - more linux-2.2 driver sync-ups - new PCI ids - emu10k stereo sound fix. - makefile documentation update - USB uhci updates - networking updates - codafs fixups - VM UP deadlock fix - Add Camino chipset ID to eepro100 driver. - pre5: - Make SCSI initialization order be same as before. - fix cardbus bridge resources.. - don't disallow Onstream ide-scsi devices - byteorder: use statement expressions instead of macros, to avoid argument re-use. - codafs update - more USB updates - _fput/__fput are no longer used. - ixj telephony driver fixes - pmac SCSI driver init update - Andries: net device name allocation as in 2.2.x - sis900 driver update - more drivers synced to Alan's 2.2.x changes - pre4: - continued SCSI cleanup - more USB updates - pre3: - USB updates - NFS over TCP - handle TCP socket writability right.. - NFS cache coherency across file locking fix - floppy: we'd better hold the io_request_lock when playing with "CURRENT". - acenic driver update - ARM update (including ARM drivers) - adfs correct dentry operations - netfilter update - networking updates (iipv6 works non-modular etc) - Sync up with Alans 2.2.x driver changes - SCSI initialization - move over to the modular case. No more double initialization. - block_prepare_write and block_truncate_page: if the page is up-to-date, then so are the buffer heads inside it once they are mapped.. - uninitialized == zero. Remove extra initializers. - pre2: - scsi fixes - network updates - PCI bridge scanning fix: assign numbers properly - sparc updates - Riel VM update - disallow re-mounting same filesystem in same place multiple times. Too confusing. And /etc/mtab gets strange. - PPC updates (including PPC-related drivers
Re: BUG & OOPS REPORT: /proc/scsi/ entries not properly cleaned up
Following up yet some more with myself... is anyone actually looking at this stuff? I can provide even more information if desired, but I'd really like to know that at least one person who understands this code is looking at it Anyway, I managed to get a better OOPS trace. Here it is: ksymoops 0.7c on i586 2.4.0-test9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9/ (default) -m /boot/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Reading Oops report from the terminal Unable to handle kernel paging request at virtual address d38c2010 c0145032 *pde = 01594063 Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: d38c2000 ebx: cf93f0a0 ecx: c1466fc0 edx: 0023 esi: c6c1a360 edi: cf93f0f4 ebp: ffea esp: c8be7ef0 ds: 0018 es: 0018 ss: 0018 Process ls (pid: 11563, stackpage=c8be7000) Stack: c7f81360 c49c17e0 c0146a9c c144b800 1190 cf93f0a0 fff4 c7f81360 c49c17e0 c49c1834 c0137083 c49c17e0 c7f81360 c8be7f68 c9f0f013 c01377c4 c7f812e0 c8be7f68 c9f0f000 c8be7fa4 Call Trace: [] [] [] [] [] [] [] Code: ff 40 10 8b 43 24 80 48 14 18 66 8b 43 08 25 00 f0 ff ff 66 >>EIP; c0145032<= Trace; c0146a9c Trace; c0137083 Trace; c01377c4 Trace; f27a545f Trace; c0137daa <__user_walk+3a/54> Trace; c0134a71 Trace; c010a413 Code; c0145032 <_EIP>: Code; c0145032<= 0: ff 40 10 incl 0x10(%eax) <= Code; c0145035 3: 8b 43 24 movl 0x24(%ebx),%eax Code; c0145038 6: 80 48 14 18 orb$0x18,0x14(%eax) Code; c014503c a: 66 8b 43 08 movw 0x8(%ebx),%ax Code; c0145040 e: 25 00 f0 ff ffandl $0xf000,%eax Code; c0145045 13: 66 00 00 addb %al,(%eax) 1 warning issued. Results may not be reliable. This is under the same test scenario as before -- load ide-scsi, unload ide-scsi, ls /proc/scsi It's interesting to note that 'cat /proc/scsi/scsi' works just fine -- only getting the directory listing seems to be broken, not the actual reading of files. Again, this was collected on 2.4.0-test9-pre7 -- but the behavior is the same for 2.4.0-test9-pre9. Matt On Sun, Oct 01, 2000 at 06:32:38PM -0700, Matthew Dharm wrote: > Just to follow-up to my own post, I have some more datapoints... > > The bug definatley seems to be in either the SCSI layer or the procfs > layer. The behavior is the same if I use either ide-scsi or usb-storage, > which are the only two SCSI modules I can test. > > Matt > > On Fri, Sep 29, 2000 at 03:19:23PM -0700, Matthew Dharm wrote: > > I'm using 2.4.0-test9-pre7 and have a _very_ reproducable OOPS with the > > SCSI layer. Everything relevant is compiled as a module (except for the > > /proc support). > > > > The test scenario is this: > > (1) Boot the machine > > (2) modprobe ide-scsi (note this autoloads scsi_mod but nothing else) > > (3) rmmod ide-scsi > > (4) ls /proc/scsi > > Then the OOPS happens. > > > > If, instead of step (4), I instead re-modprobe ide-scsi again, then an 'ls > > /proc/scsi/' will show (without an immediate OOPS): > > > > [root@zen mdharm]# ls /proc/scsi/ > > ide-scsi/ ide-scsi/ scsi > > > > No, the double ide-scsi entry isn't a typo -- this is what ls reports as > > being there. > > > > The OOPS case is decoded via ksymoops below. My intuition suggests that > > this is related to the fact that /proc seems to always be busy (and > > therefore not umountable) at shutdown. > > > > I'm more than willing to test patches that might fix the problem. > > > > Sep 29 15:05:01 zen kernel: Unable to handle kernel paging request at > > virtual address d38c2010 > > Sep 29 15:05:01 zen kernel: c0145032 > > Sep 29 15:05:01 zen kernel: *pde = 01594063 > > Sep 29 15:05:01 zen kernel: Oops: 0002 > > Sep 29 15:05:01 zen kernel: CPU:0 > > Sep 29 15:05:01 zen kernel: EIP:0010:[proc_get_inode+150/264] > > Sep 29 15:05:01 zen kernel: EFLAGS: 00010286 > > Sep 29 15:05:01 zen kernel: eax: d38c2000 ebx: cf687520 ecx: c1466fc0 edx: >0023 > > Sep 29 15:05:01 zen kernel: esi: cd990340 edi: cf687574 ebp: ffea esp: >cd99def0 > > Sep 29 15:05:01 zen kernel: ds: 0018 es: 0018 ss: 0018 > > Sep 29 15:05:01 zen kernel: Process ls (pid: 705, stackpage=cd99d000) > > Sep 29 15:05:01 zen kernel: Stack: cda17ec0 cd9901c0 c0146a9c c144b800 1190 >cf687520 fff4 cda17ec0 > > Sep 29 15:05:01 zen
Re: RTL8139 still doesn't work for me
On Mon, 2 Oct 2000, Marcelo Tosatti wrote: > > I'm running 2.2.17 with the rtl8139 fix from 2.2.18pre, and after about > > two hours of normal operation (no crashes, no fs corruption -- Thanks > > Jeff) the network suddenly stops responding. Calling "ifconfig" (just > > looking at the stats) sometimes cures the problem, taking all interfaces > > down and back up works everytime. > Have you tried "8139too" driver in 2.2.18pre? Not yet, will do in two hours (gee, I like my 486)... Thanks, Simon -- PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
Hi, On Mon, 2 Oct 2000, Rik van Riel wrote: > On Sun, 1 Oct 2000, Linus Torvalds wrote: > > > - pre8: > > - quintela: fix the synchronous wait on kmem_cache_shrink(). > > This should fix the mmap02 lockup. > > It probably doesn't. People will want to apply my patch > (on http://www.surriel.com/patches/) to -test9-pre8 to > see if that really makes the box solid. just repeated the tests wich caused deadlocks on my UP-box (192M RAM, 500M swap) using 2.4.0-t9p8 + 2.4.0-t9p7-vmpatch. All tests done in single-user (why? - see below): - mmap002: no deadlock anymore - swptst (provided by Mark Galbraith - basically ipc001 with shmget() +friends replaced by anonymous mmap()): no deadlocks anymore - boot with mem=8M und doing (several simultaneous) dd's if=/dev/urandom of=/dev/null with bs=10M: fine too - boot with mem=8M and make bzImage: works too so far for the good news - however, there is some bad too as I still have 3 "box lockup" situations. The first one (not covered here) is at IDE-initialization when booting and needs more investigantion. The other 2 are VM-related: * deadlock in initscripts (even for runlevel 2). SysRq shows idle_task being the only one ever getting the CPU when deadlocked. I think I'll have to hack my initscripts to analyze this step by step to provide more information, if I'm the only one, hanging there. * Following a suggestion from Jeff Garzik to save the disk from heavy trashing during my mem=8M test, I've tried to use a ramdisk for swapping - Yes, I know, this is pretty stupid in normal use and might even be illegal (i.e. not expected to work by design). Anyway, I've tried it and was working when used as a swapdevice (size=64M, bs=4k). Added with priority 0 and the normal swap partition kept for fallback with prio=-1. No problems. It did even gracefully swapoff the ramdisk while it was already filled and the box was swapping to disk. To make thinks even more stupid, I've tried a second thing: create an ext2-fs (bs=4k) on the ramdisk, mount it, and use a swapfile on top of it. This deadlocks (with kswapd being current forever) at the very moment the swapfile ist filled and swapping has to go to the fallback raw swap partition. As already said, I wouldn't be surprised, if swapping to rd were broken. But swapping to a rd-partition appears solid while a rd-based swapfile deadlocks. Could the difference be explained somehow or might it indicate some deadlock path due to VM-fs interaction not covered otherwise - so far? More comments: 2.4.0-t9p8 + 2.4.0-t9p7-vmpatch appears to be a big step in the right direction. What did impress me most, was the performance boost: make bzImage with mem=8M needed about 2h to complete - whereas for t9p7 it was 6-7h! According to vmstat the difference goes in parallel with CPU-utilisation (u/s/i=10/30/60 for t9p8, was something like 2/8/90 for t9p7). Haven't tried other combinations (vanilla t9p8 or t9p7+t9p7-vmpatch f.e.) Waiting for Rik's next patch recently announced to look for the initscript issue - if it's still there then. Regards Martin - To unsubscribe from this list: send 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] Make linux logo centered, add margins, etc. for 2.2.17
Mohammad A. Haque provided enlightenment: >>Why does fbcon_show_logo() have a loop that looks at smp_num_cpus? > For every CPU you have you see one more Tux (blush) I should have figured that out for myself. You know, a different, or at least more comprehensive patch will be needed for machines with more than 8 processors, depending on screen resolution, since 8 Tux will overflow a 640 pixel wide screen. Of course, most of those machines won't be using framebuffer consoles at VGA resolutions... still... Yes, on SMP boxes the original design would be better. My patch is actually intended for embedded systems where you want a big, user-friendly logo on the screen instead of the console boot messages. Thanks for the tip. I'll change the patch. Actually, now that I understand that bit, I realize that a much better way to do it is to add x_start up there, for (x=x_start; x < smp_num_cpus * ..., rather than separately for each different version of the drawing loops. Torrey [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RTL8139 still doesn't work for me
On Tue, 3 Oct 2000, Simon Richter wrote: > Hi, > > I'm running 2.2.17 with the rtl8139 fix from 2.2.18pre, and after about > two hours of normal operation (no crashes, no fs corruption -- Thanks > Jeff) the network suddenly stops responding. Calling "ifconfig" (just > looking at the stats) sometimes cures the problem, taking all interfaces > down and back up works everytime. Have you tried "8139too" driver in 2.2.18pre? - To unsubscribe from this list: send 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] Make linux logo centered, add margins, etc. for 2.2.17
For every CPU you have you see one more Tux Torrey Hoffman wrote: > Note that using large logos can dramatically increase the size of > your zImage kernel. Also I'm not 100% confident the patch is correct, > as I'm not a kernel guru (yet). (Why does fbcon_show_logo() have a > loop that looks at smp_num_cpus?) > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: eepro100 debug, take 2
This time, it checks for CAP_NET_ADMIN before adjusting the debug
level. (Duh)
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c2000/09/06 19:54:42 1.4
+++ linux/drivers/net/eepro100.c2000/10/02 22:44:12 1.4.8.2
@@ -1,4 +1,2 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
@@ -40,4 +38,9 @@
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
@@ -1148,6 +1151,4 @@ static void speedo_show_state(struct net
{
struct speedo_private *sp = (struct speedo_private *)dev->priv;
- long ioaddr = dev->base_addr;
- int phy_num = sp->phy[0] & 0x1f;
int i;
@@ -1176,4 +1177,8 @@ static void speedo_show_state(struct net
#if 0
+ {
+ long ioaddr = dev->base_addr;
+ int phy_num = sp->phy[0] & 0x1f;
+
for (i = 0; i < 16; i++) {
/* FIXME: what does it mean? --SAW */
@@ -1182,4 +1187,5 @@ static void speedo_show_state(struct net
dev->name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
@@ -1509,5 +1515,5 @@ static void speedo_interrupt(int irq, vo
outw(status & 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug > 4)
+ if (speedo_debug > 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev->name, status);
@@ -1932,4 +1938,11 @@ static int speedo_ioctl(struct net_devic
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5: /* Set speedo debug level */
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+ speedo_debug = *(int *)rq->ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev->name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
@@ -1971,4 +1984,8 @@ static void set_rx_mode(struct net_devic
* set again later. */
sp->rx_mode = -1;
+ if(speedo_debug < 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp->cur_tx[%d], sp->dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev->name, sp->cur_tx, sp->dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send 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] Make linux logo centered, add margins, etc. for 2.2.17
This is a patch to linux-2.2.17.
As you all probably know, the current framebuffer driver (fbcon.c)
displays an 80x80 pixel penguin logo at the top left of the screen.
This patch modifies fbcon.c to display the linux logo centered
horizontally, with optional margins (LOGO_MARGIN) above and below.
The boot console displays in the remaining space.
It also cleans up the code a little to move the LOGO_W and LOGO_H
defines to the linux_logo.h header file, where they ought to be.
I have successfully used this code to display a large (472x320) logo
with the vesa framebuffer on i386 during boot. That only requires
replacing the include/linux/linux_header.h file.
This patch is currently untested on anything else, and I would be
interested in bug reports.
Note that using large logos can dramatically increase the size of
your zImage kernel. Also I'm not 100% confident the patch is correct,
as I'm not a kernel guru (yet). (Why does fbcon_show_logo() have a
loop that looks at smp_num_cpus?)
Anyway, if you find this interesting, you may also like to know that
I have updated the "glogo" gimp plugin, (which is GPL'ed and copyright
(C) 1998 Jens Ch. Restemeier <[EMAIL PROTECTED]>) to support:
- this modified linux_logo.h header format
- logos of variable size, instead of just 80x80 pixels
- gimp 1.1.26
If you want my version of glogo, just ask me. If this patch is
considered for inclusion in the official kernel, when I've recovered
from the shock I'll try to coordinate with with Jens Restemeier to
keep the "official" glogo up to date.
This is my first submission to the Linux Kernel mailing list. If
I've done anything incorrectly, please gently correct me so I can
get it right next time.
This patch was created in /usr/src with the command:
diff -u -r linux-2.2.17 linux
and can be applied in /usr/src/linux with the command
patch -p1 < ../linux_logo.patch
Thanks!
Torrey Hoffman
[EMAIL PROTECTED]
[EMAIL PROTECTED]
diff -u -r -x *.o -x *.flags -x *.depend linux-2.2.17/drivers/video/fbcon.c
linux/drivers/video/fbcon.c
--- linux-2.2.17/drivers/video/fbcon.c Mon Sep 4 10:39:22 2000
+++ linux/drivers/video/fbcon.c Mon Oct 2 08:50:46 2000
@@ -30,7 +30,9 @@
* Jakub Jelinek ([EMAIL PROTECTED])
*
* Random hacking by Martin Mares <[EMAIL PROTECTED]>
- *
+ *
+ * Small changes for arbitrary size, centered logos with margins
+ * by Torrey Hoffman ([EMAIL PROTECTED])
*
* The low level operations for the various display memory organizations
are
* now in separate source files.
@@ -107,10 +109,6 @@
# define DPRINTK(fmt, args...)
#endif
-#define LOGO_H 80
-#define LOGO_W 80
-#define LOGO_LINE (LOGO_W/8)
-
struct display fb_display[MAX_NR_CONSOLES];
static int logo_lines;
static int logo_shown = -1;
@@ -522,7 +520,7 @@
int cnt;
int step;
- logo_lines = (LOGO_H + fontheight(p) - 1) / fontheight(p);
+ logo_lines = (LOGO_H + LOGO_MARGIN + LOGO_MARGIN + fontheight(p) -
1) / fontheight(p);
q = (unsigned short *)(conp->vc_origin + conp->vc_size_row *
old_rows);
step = logo_lines * old_cols;
for (r = q - logo_lines * old_cols; r < q; r++)
@@ -1957,7 +1955,10 @@
/* Return if the frame buffer is not mapped */
if (!fb)
return 0;
-
+
+/* Center the linux logo horizontally */
+int x_start = (p->var.xres - LOGO_W) / 2;
+
/* Set colors if visual is PSEUDOCOLOR and we have enough colors, or
for
* DIRECTCOLOR */
if ((p->visual == FB_VISUAL_PSEUDOCOLOR && depth >= 4) ||
@@ -2015,7 +2016,7 @@
for (x = 0; x < smp_num_cpus * (LOGO_W + 8) &&
x < p->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
-
+
#if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
if (p->visual == FB_VISUAL_DIRECTCOLOR) {
@@ -2032,12 +2033,13 @@
/* have at least 8 bits per color */
src = logo;
bdepth = depth/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
- dst = fb + y1*line + x*bdepth;
+ for( y1 = LOGO_MARGIN; y1 < LOGO_H + LOGO_MARGIN; y1++ ) {
+ dst = fb + y1*line + (x + x_start) * bdepth;
for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
val = (*src << redshift) |
(*src << greenshift) |
(*src << blueshift);
+
if (bdepth == 4 && !((long)dst & 3)) {
/* Some cards require 32bit access */
*(u32 *)dst = val;
@@ -2058,8 +2060,8 @@
unsigned int pix;
src = linux_logo16;
bdepth = (depth+7)/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
- dst = fb + y1*line + x*bdepth;
+ for( y1 = LOGO_MARGIN; y1 <
Re: 2.4.0-test9-pre8, usb, unresolved symbols
On Mon, Oct 02, 2000 at 11:18:49PM +0200, f5ibh wrote: > > Hi, > > Randy wrote : > > All of the missing symbols are in usb.o (usbcore.o module or > > usbdrv.o in-kernel). Is usbcore.o loaded or do you have > > /etc/modules.conf setup to load it automatically? > > Did you run depmod after 'make modules_install' ? > > I've a Debian 2.2 system. With Debian, I use the "make-kpkg" command to build > the kernel in a Debian package. I ALWAYS use the same process to compile > kernel. Then, I install the new kernel with dpkg as any .deb package ... I think > I've built 100's of them now. depmod reports the same error : > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o > depmod: *** Unresolved symbols in >/lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o Is your modutils package the most recent one? Did this same thing happen for 2.4.0-test8? Can you send me / the list your .config? thanks, greg k-h -- greg@(kroah|wirex).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/
get_empty_filp
Hello All, I am seeing a bug in get_empty_filp (fs/file_table.c) where files_stat.nr_free_files is out of sync with respect to the actual number of elements in free_list. More precicely, for some reason, free_list became empty (free_list.next and free_list.prev pointed back to free_list) but files_stat.nr_free_files was 180. So the code list_entry(free_list.next...) returned a bad pointer (in this case a pointer to free_list) and the memset in the get_empty_filp overwrote the files_lock. As far as I can see, one way this can happen is if in _fput, the list_del and list_add routines took the *file off of teh free_list and put it back on the free_list, causing the statement files_stat.nr_free_files++ to be out of sync. My question is... can anyone call _fput where the *file parameter is already on the free_list? Thanks Lee __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RTL8139 still doesn't work for me
Hi, I'm running 2.2.17 with the rtl8139 fix from 2.2.18pre, and after about two hours of normal operation (no crashes, no fs corruption -- Thanks Jeff) the network suddenly stops responding. Calling "ifconfig" (just looking at the stats) sometimes cures the problem, taking all interfaces down and back up works everytime. The problem does not occur if I route all traffic via the other network card (this is how the box runs now), otherwise same setup. I have both IPv4 and IPv6 running (directly on the network interface, without tunneling). Any ideas? Simon -- PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! # # Automatically generated make config: don't edit # # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Processor type and features # # CONFIG_M386 is not set CONFIG_M486=y # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M686 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_1GB=y # CONFIG_2GB is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # # Loadable module support # # CONFIG_MODULES is not set # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_QUIRKS=y CONFIG_PCI_OPTIMIZE=y CONFIG_PCI_OLD_PROC=y # CONFIG_MCA is not set # CONFIG_VISWS is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_BINFMT_JAVA is not set # CONFIG_PARPORT is not set # CONFIG_APM is not set # CONFIG_TOSHIBA is not set # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_VIA82C586 is not set # CONFIG_BLK_DEV_CMD646 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_IDE_CHIPSETS is not set # # Additional Block Devices # CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_PARIDE_PARPORT=y # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_DEV_HD is not set # # Networking options # CONFIG_PACKET=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_FIREWALL=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_NETLINK=y CONFIG_NETLINK_DEV=y # CONFIG_IP_TRANSPARENT_PROXY is not set # CONFIG_IP_MASQUERADE is not set # CONFIG_IP_ROUTER is not set CONFIG_NET_IPIP=y # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set CONFIG_IP_ALIAS=y # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # # (it is safe to leave these untouched) # # CONFIG_INET_RARP is not set CONFIG_SKB_LARGE=y CONFIG_IPV6=y CONFIG_IPV6_EUI64=y # CONFIG_IPV6_NO_PB is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_BRIDGE is not set # CONFIG_LLC is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # CONFIG_CPU_IS_SLOW is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # SCSI support # # CONFIG_SCSI is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_SCSI is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=y # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is
[ANNOUNCE] Powertweak 0.1.17
I just uploaded 0.1.17 of Powertweak to http://powertweak.sourceforge.net This fixes a bug where changing from a 2.4 kernel back to a 2.2 kernel would cause hangs. Development on this tree has stopped (asides bugfixes like this one), as work is being done on the 0.99.x tree in CVS (more info same URL as above). The first release of the new tree will follow sometime real soon. regards, Dave. -- | Dave Jones <[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: 2.4.0-test9-pre8, usb, unresolved symbols
Well, let's see. linux/drivers/Makefile did change for test9-pre8. That's one possibility. Are you building USB core support in-kernel or as a module? (Maybe provide your .config file, or at least the CONFIG_USB_xxx portion of it.) Thanks, ~Randy > From: f5ibh [mailto:[EMAIL PROTECTED]] > > Randy wrote : > > All of the missing symbols are in usb.o (usbcore.o module or > > usbdrv.o in-kernel). Is usbcore.o loaded or do you have > > /etc/modules.conf setup to load it automatically? > > Did you run depmod after 'make modules_install' ? > > I've a Debian 2.2 system. With Debian, I use the "make-kpkg" > command to build > the kernel in a Debian package. I ALWAYS use the same process > to compile > kernel. Then, I install the new kernel with dpkg as any .deb > package ... I think > I've built 100's of them now. depmod reports the same error : > > depmod: *** Unresolved symbols in > /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o > depmod: *** Unresolved symbols in > /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o > > I use the following in my modules.conf to load automatically > all the usb related > stuff when starting 'gpm'. This works with the previous > test9-prex patches. > > # USB mouse > #-- > alias char-major-13 mousedev > > post-install input modprobe -k hid > post-install hid modprobe -k usb-uhci > > --- - To unsubscribe from this list: send 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: Soft-Updates for Linux ?
Ralf Baechle wrote: > > On Sun, Oct 01, 2000 at 10:21:34AM -0500, Robert Redelmeier wrote: > > You boys and girls don't try this at home on Linux! The ext2 fsck is horrible > > after a powerfail, and I've lost superblocks and had to re-install :( . > > There is actually some indication that part of the corruption people observe > after powerfails is caused by hardware scribbling junk data over the disk > in the very last moment when power levels in the system are already so low > that memory is already starting to fail while I/O hardware is still doing > their best to write junk data to the disk. These days powerfails are rare > and so it's easy to attribute that to something else. It would must be so easy to inhibit the write head on losing the power-good signal, or perhaps trying to hang in there until the end of the current write. ??There is a power-good signal on a PC isn't there?? So, which drives don't do this (so I can be sure not to buy one) and which do? Tux2 deals with the possibility of a bad write in the last block by checkpointing each new metaroot and writing it to a location different from the last one (wy far away). This assumes that only the last block written has a chance of getting random scribbles in it. If it's possible to get random scribbles in places other than the last block, the only reasonable solution I can think of is throwing away the drive. I'd be happy if someone would point me at some low-level engineering info along these lines so I can really get down and dirty in my analysis. I tend to take a programmer's view of these things and assume that the logical way is the way they've actually been designed, but that's just isn't always the case. > Maybe it's time to implement support for power fail / power return interrupts > where supported by hardware. At least on Indy that gives you ~ 10ms to > stop whatever is going on before power finally fails. With Tux2 all you need is an iret there. -- Daniel - To unsubscribe from this list: send 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: Login prompt auto-regen
I got this part from LSB. We were having some problems with Red Hat 6.2, but we have tracked it down. Jeff Igmar Palsenberg wrote: > > On Mon, 2 Oct 2000, Jeff V. Merkey wrote: > > > > > Alan, > > > > Your mail server is getting errors at address <[EMAIL PROTECTED]>. I am > > seeing "connection deferred" and relaying denied. Where are the scripts > > in 6.X RedHat that auto-regne the RedHat Login prompt? > > You probably mean the cat >> in /etc/rc.d/rc.local > > Regards, > > Igmar > > - > To unsubscribe from this list: send 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: hdparm -d 1 fail test9-pre8
On Mon, 2 Oct 2000, Jeff Garzik wrote: I know that you are still pissed at me but do not do end runs around me. That is not cool, and you do not know where things are going. Heck, I keep changing my mind on stuff as I design it. I would be more appreciative if you at least sent it to me since I am the one that has to clean up issues that I do not get to see. > On Mon, 2 Oct 2000, Mike Galbraith wrote: > > In order for hdparm -d 1 to work in test9-pre8, I had to reverse > > this change. (Without being able to enable dma, performance here > > is muy el-stinko;-) Is enabling dma manually now forbidden? (or > > am I maybe missing something else?) > > If this change broke your DMA enabling, I think there are other bugs > lurking in the code... No you disable the enable of the device and it kicked out to legacy mode. > Can you provide a "diff -u " of dmesg, output, with, and without the > change below? > > Jeff > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.8: Fix IDE...
No kidding, it is scheduled for a RAPE and BURN for a redesign for 2.5.
Until then do not make changes that cause problems with 'class' code ID's.
Cheers,
On Mon, 2 Oct 2000, Jeff Garzik wrote:
> Linus,
>
> Ug. Why do I feel like the IDE "driver" is code layered upon code
> layered upon code, through the ages, with nary a cleanup in between?
>
> My previous patch was a fix, but (brown paper bag time) standard IDE
> devices no longer called chipset init. People either had no IDE, or
> were stuck in legacy mode. This fixes it.
>
> The IDE layer is in serious need of a cleanup though, IMHO...
>
> With this tested patch full functionality should be restored, without
> reverting to the previously-crazy code found in test9-pre7 and before.
>
> Jeff
>
>
>
>
> Index: drivers/ide/ide-pci.c
> ===
> RCS file: /usr/jgarzik/cvslan/linux_2_3/drivers/ide/ide-pci.c,v
> retrieving revision 1.1.1.9
> diff -u -r1.1.1.9 ide-pci.c
> --- drivers/ide/ide-pci.c 2000/10/02 08:32:44 1.1.1.9
> +++ drivers/ide/ide-pci.c 2000/10/02 18:28:10
> @@ -493,6 +493,7 @@
> byte tmp = 0;
> ide_hwif_t *hwif, *mate = NULL;
> unsigned int class_rev;
> + int pci_class_ide;
>
> #ifdef CONFIG_IDEDMA_AUTO
> autodma = 1;
> @@ -538,7 +539,8 @@
>* Can we trust the reported IRQ?
>*/
> pciirq = dev->irq;
> - if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {
> + pci_class_ide = ((dev->class >> 8) == PCI_CLASS_STORAGE_IDE);
> + if (!pci_class_ide) {
> printk("%s: not 100%% native mode: will probe irqs later\n", d->name);
> /*
>* This allows offboard ide-pci cards the enable a BIOS,
> @@ -548,11 +550,17 @@
>*/
> pciirq = (d->init_chipset) ? d->init_chipset(dev, d->name) :
>ide_special_settings(dev, d->name);
> } else if (tried_config) {
> - printk("%s: will probe irqs later\n", d->name);
> + printk(KERN_INFO "%s: will probe irqs later\n", d->name);
> pciirq = 0;
> } else if (!pciirq) {
> - printk("%s: bad irq (%d): will probe later\n", d->name, pciirq);
> - pciirq = 0;
> + if (pci_class_ide) {
> + /* this is the normal path for most IDE devices */
> + if (d->init_chipset)
> + pciirq = d->init_chipset(dev, d->name);
> + else
> + printk(KERN_INFO "%s standard IDE storage device
>detected\n", d->name);
> + } else
> + printk(KERN_WARNING "%s: bad irq (0): will probe later\n",
>d->name);
> } else {
> if (d->init_chipset)
> (void) d->init_chipset(dev, d->name);
>
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18pre13: eepro100 debug tweaks
According to Alan Cox: > > + case SIOCDEVPRIVATE+5: > > + speedo_debug = *(int *)rq->ifr_data; > > + printk(KERN_DEBUG "%s: set debug level to [%d].\n", > > + dev->name, speedo_debug); > > + return 0; > > Surely that should check for root ? Now see, this is why peer review is a Good Thing. :-/ Yes, of course it should check for root. (I'm dunce-for-a-day for not seeing that immediately.) -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send 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: SA_INTERRUPT
Hi, On Mon, 2 Oct 2000, Andrea Arcangeli wrote: > > When that is done, please don't call __sti() directly and use some macro > > that can be overridden by the architectures. > > What do you have in mind while making this suggestion? The irq highlevel layer > is pretty much architectural indipendent. Just run a diff between the irq.c in > the IA32 and alpha ports. Also what about the drivers that are just using > __sti() at the start of the irq handler right now? m68k uses interrupt levels, so an interrupt with a higher priority can interrupt another interrupt with a lower priority. To make things more interesting several m68k machines don't have a seperate external interrupt controller, so they rely on that the interrupt level isn't lowered during an interrupt (the ide driver has an ide__sti() because of this). I can imagine that newer lowend embedded targets have similiar problems (on the other end I'm just looking at the s390 interrupt code which looks also interesting). bye, Roman - To unsubscribe from this list: send 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: hdparm -d 1 fail test9-pre8
On Mon, 2 Oct 2000, Mike Galbraith wrote:
> Greetings,
>
> In order for hdparm -d 1 to work in test9-pre8, I had to reverse
> this change. (Without being able to enable dma, performance here
> is muy el-stinko;-) Is enabling dma manually now forbidden? (or
> am I maybe missing something else?)
>
> diff -urN linux-2.4.0-test9-pre7/drivers/ide/ide-pci.c
>linux-2.4.0-test9-pre8/drivers/ide/ide-pci.c
> --- linux-2.4.0-test9-pre7/drivers/ide/ide-pci.c Sun Jul 30 06:30:13 2000
> +++ linux-2.4.0-test9-pre8/drivers/ide/ide-pci.c Mon Oct 2 10:11:36 2000
> @@ -538,7 +538,7 @@
>* Can we trust the reported IRQ?
>*/
> pciirq = dev->irq;
> - if ((dev->class & ~(0xfa)) != ((PCI_CLASS_STORAGE_IDE << 8) | 5)) {
> + if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {
Why are we changing the enable code?
If you are not a registered device in the list and you do not report with
a storage class of 0x0101, then you do not get enabled, period.
This is going to break a whole bunch of cards and systems.
So undo this nonsense and stop dorking up the cards.
Sheesh the chipset folks are making ATA hosts that report as
SCSI0x0100
EIDE0x0101
RAID0x0104
MASS0x0180
Do not mess with ID clas signatures! Please!
> printk("%s: not 100%% native mode: will probe irqs later\n", d->name);
> /*
>* This allows offboard ide-pci cards the enable a BIOS,
>
> >From dmesg:
> 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 39
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c596b IDE UDMA66 controller on pci0:7.1
> ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:pio
> hda: IBM-DJNA-352030, ATA DISK drive
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> hdc: MATSHITADVD-ROM SR-8583A, ATAPI CDROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 39876480 sectors (20417 MB) w/1966KiB Cache, CHS=2482/255/63, UDMA(33)
> hdc: ATAPI 32X DVD-ROM drive, 512kB Cache, DMA
>
> please cc [EMAIL PROTECTED], as [EMAIL PROTECTED] is nothing but a
> mail black-hole. (provider must be trying to trim his customer base:)
>
> -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/
>
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Login prompt auto-regen
On Mon, 2 Oct 2000, Jeff V. Merkey wrote: > > Alan, > > Your mail server is getting errors at address <[EMAIL PROTECTED]>. I am > seeing "connection deferred" and relaying denied. Where are the scripts > in 6.X RedHat that auto-regne the RedHat Login prompt? You probably mean the cat >> in /etc/rc.d/rc.local Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18pre13: Small patches from Andrea
> I suppose I should let Andrea submit these, but he has such a huge > patch collection (thank you!) that I thought it might be useful to > pick out some of the smaller ones that would be less controversial > for inclusion in the main kernel. Im intentionally avoiding these right now. The 2.2.18 kernel has a very large amount of updates to drivers/extra functionality. I don't want to mix any of that with core internal changes of any kind. The VM fixes in paticular look good but would be an invitation to disaster to merge this release. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: Small patches from Andrea
I suppose I should let Andrea submit these, but he has such a huge
patch collection (thank you!) that I thought it might be useful to
pick out some of the smaller ones that would be less controversial
for inclusion in the main kernel.
* nanosleep-4
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
* tsc-calibration-non-compile-time-1
TSC calibration must be dynamic and not a compile time thing because
gettimeofday is dynamic and it depends on the TSCs to be in sync.
* IO-wait-2
Avoid spurious unplug of the I/O queue.
* buf-run_task_queue
Avoid spurious unplug of the I/O queue. (again!)
* account-failed-buffer-tries-1
Account also for failed buffer tries during shrink_mmap.
* overcommit-1
Make sure to not understimate the available memory (the cache and
buffers may be under the min percent).
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Tag: KERNEL-2-2-18-PRE11-PATCH-6
Patch: nanosleep-4
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
Index: linux/arch/alpha/kernel/time.c
diff -u linux/arch/alpha/kernel/time.c:1.2 linux/arch/alpha/kernel/time.c:1.2.6.1
--- linux/arch/alpha/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/alpha/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -339,8 +339,22 @@
irq_handler = timer_interrupt;
if (request_irq(TIMER_IRQ, irq_handler, 0, "timer", NULL))
panic("Could not allocate timer IRQ!");
+ do_get_fast_time = do_gettimeofday;
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* Use the cycle counter to estimate an displacement from the last time
* tick. Unfortunately the Alpha designers made only the low 32-bits of
@@ -389,13 +403,11 @@
#endif
usec += delta_usec;
- if (usec >= 100) {
- sec += 1;
- usec -= 100;
- }
tv->tv_sec = sec;
tv->tv_usec = usec;
+
+ timeval_normalize(tv);
}
void
Index: linux/arch/i386/kernel/time.c
diff -u linux/arch/i386/kernel/time.c:1.2 linux/arch/i386/kernel/time.c:1.2.6.1
--- linux/arch/i386/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/i386/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -239,6 +239,20 @@
#endif
+/* FIXME: should be inline but gcc is buggy and breaks */
+static void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -259,13 +273,10 @@
usec += xtime.tv_usec;
read_unlock_irqrestore(_lock, flags);
- while (usec >= 100) {
- usec -= 100;
- sec++;
- }
-
tv->tv_sec = sec;
tv->tv_usec = usec;
+
+ timeval_normalize(tv);
}
void do_settimeofday(struct timeval *tv)
Index: linux/arch/ppc/kernel/time.c
diff -u linux/arch/ppc/kernel/time.c:1.2 linux/arch/ppc/kernel/time.c:1.2.14.1
--- linux/arch/ppc/kernel/time.c:1.2Thu Jul 6 22:41:19 2000
+++ linux/arch/ppc/kernel/time.cWed Sep 27 23:55:48 2000
@@ -147,6 +147,19 @@
hardirq_exit(cpu);
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution.
*/
@@ -161,10 +174,7 @@
#ifndef __SMP__
tv->tv_usec += (decrementer_count - get_dec())
* count_period_num / count_period_den;
- if (tv->tv_usec >= 100) {
- tv->tv_usec -= 100;
- tv->tv_sec++;
- }
+ timeval_normalize(tv);
#endif
restore_flags(flags);
}
Index: linux/include/linux/time.h
diff -u linux/include/linux/time.h:1.1 linux/include/linux/time.h:1.1.14.1
--- linux/include/linux/time.h:1.1 Thu Jul 6 22:04:59 2000
+++
Re: [PATCH] 2.2.18pre13: eepro100 debug tweaks
> + case SIOCDEVPRIVATE+5: > + speedo_debug = *(int *)rq->ifr_data; > + printk(KERN_DEBUG "%s: set debug level to [%d].\n", > + dev->name, speedo_debug); > + return 0; Surely that should check for root ? > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18pre13: USB tweak for VAIO
On Mon, Oct 02, 2000, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> Patch: usbdock-1
> From: Geoff Harrison <[EMAIL PROTECTED]>
>
> Allow short report frames via USB ... apparently they are normal for
> some Sony VAIOs when docked.
This is actually a hack to get a specific PS/2 to USB device to work.
The reports that get sent back are short by one byte which doesn't seem
to cause problems, but apparentely are illegal per the spec.
The cause and real fix are still under investigation.
> Index: linux/drivers/usb/hid.c
> diff -u linux/drivers/usb/hid.c:1.2 linux/drivers/usb/hid.c:1.2.2.1
> --- linux/drivers/usb/hid.c:1.2 Wed Sep 27 23:44:24 2000
> +++ linux/drivers/usb/hid.c Thu Sep 28 11:51:32 2000
> @@ -1096,10 +1096,12 @@
> return;
> }
>
> +#if 0
> if (len < ((report->size - 1) >> 3) + 1) {
> dbg("report %d is too short, (%d < %d)", report->id, len,
>((report->size - 1) >> 3) + 1);
> return;
> }
> +#endif
>
> for (n = 0; n < report->maxfield; n++)
> hid_input_field(device, report->field[n], data);
JE
-
To unsubscribe from this list: send 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: Inter-device-driver communication?
> pointers mostly point to buffers of about 1-8KB. Since the kernel is > monolothic, I don't expect there to be a need to translate virtual addresses. Correct > As for how often, these calls are made probably as much as 50 times a second, > but irregularly. One of the drivers involved is attached to the VM, so it will > need to pass data along as often as the VM is called. Just declare some kind of shared structure or pointer and EXPORT_SYMBOL them to the other driver. You can write wrapper functions if you want to be neat but thats your choice - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.2.18pre13: USB tweak for VAIO
How about not running your kernel at KERN_DEBUG level <7> ?
That would also eliminate this message.
~Randy
> -Original Message-
> From: Chip Salzenberg [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 02, 2000 2:12 PM
> To: Alan Cox
> Cc: Linux Kernel
> Subject: [PATCH] 2.2.18pre13: USB tweak for VAIO
>
>
> Patch: usbdock-1
> From: Geoff Harrison <[EMAIL PROTECTED]>
>
> Allow short report frames via USB ... apparently they are normal for
> some Sony VAIOs when docked.
>
> Index: linux/drivers/usb/hid.c
> diff -u linux/drivers/usb/hid.c:1.2 linux/drivers/usb/hid.c:1.2.2.1
> --- linux/drivers/usb/hid.c:1.2 Wed Sep 27 23:44:24 2000
> +++ linux/drivers/usb/hid.c Thu Sep 28 11:51:32 2000
> @@ -1096,10 +1096,12 @@
> return;
> }
>
> +#if 0
> if (len < ((report->size - 1) >> 3) + 1) {
> dbg("report %d is too short, (%d < %d)",
> report->id, len, ((report->size - 1) >> 3) + 1);
> return;
> }
> +#endif
>
> for (n = 0; n < report->maxfield; n++)
> hid_input_field(device, report->field[n], data);
>
> --
> Chip Salzenberg - a.k.a. -
> <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re:2.4.0-test9-pre8, usb, unresolved symbols
Hi, Randy wrote : > All of the missing symbols are in usb.o (usbcore.o module or > usbdrv.o in-kernel). Is usbcore.o loaded or do you have > /etc/modules.conf setup to load it automatically? > Did you run depmod after 'make modules_install' ? I've a Debian 2.2 system. With Debian, I use the "make-kpkg" command to build the kernel in a Debian package. I ALWAYS use the same process to compile kernel. Then, I install the new kernel with dpkg as any .deb package ... I think I've built 100's of them now. depmod reports the same error : depmod: *** Unresolved symbols in /lib/modules/2.4.0-test9/kernel/drivers/usb/hid.o depmod: *** Unresolved symbols in /lib/modules/2.4.0-test9/kernel/drivers/usb/usb-uhci.o I use the following in my modules.conf to load automatically all the usb related stuff when starting 'gpm'. This works with the previous test9-prex patches. # USB mouse #-- alias char-major-13 mousedev post-install input modprobe -k hid post-install hid modprobe -k usb-uhci --- Regards Jean-Luc - To unsubscribe from this list: send 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] 2.2.18pre13: eepro100 debug tweaks
Patch: eepro100-speedo-debug-1
From: Dragan Stancevic <[EMAIL PROTECTED]>
Debugging tweaks for eepro100 driver:
* Add ioctl to adjust speedo_debug.
* Print diagnostic when Tx ring fills up.
* Adjust debugging level of interrupt diagnostics.
* Eliminate compilation warning.
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c:1.4Wed Sep 6 12:54:42 2000
+++ linux/drivers/net/eepro100.cThu Sep 28 01:07:37 2000
@@ -1,5 +1,3 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
NOTICE: this version of the driver is supposed to work with 2.2 kernels.
@@ -39,6 +37,11 @@
Honor PortReset timing specification.
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
"eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin
<[EMAIL PROTECTED]> and others\n";
@@ -1147,8 +1150,6 @@
static void speedo_show_state(struct net_device *dev)
{
struct speedo_private *sp = (struct speedo_private *)dev->priv;
- long ioaddr = dev->base_addr;
- int phy_num = sp->phy[0] & 0x1f;
int i;
/* Print a few items for debugging. */
@@ -1175,12 +1176,17 @@
(unsigned)sp->rx_ringp[i]->status : 0);
#if 0
+ {
+ long ioaddr = dev->base_addr;
+ int phy_num = sp->phy[0] & 0x1f;
+
for (i = 0; i < 16; i++) {
/* FIXME: what does it mean? --SAW */
if (i == 6) i = 21;
printk(KERN_DEBUG "%s: PHY index %d register %d is %4.4x.\n",
dev->name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
}
@@ -1508,7 +1514,7 @@
FCP and ER interrupts --Dragan */
outw(status & 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug > 4)
+ if (speedo_debug > 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev->name, status);
@@ -1931,6 +1937,11 @@
mdio_write(ioaddr, data[0], data[1], data[2]);
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5:
+ speedo_debug = *(int *)rq->ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev->name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
}
@@ -1970,6 +1981,10 @@
/* The Tx ring is full -- don't add anything! Hope the mode will be
* set again later. */
sp->rx_mode = -1;
+ if(speedo_debug < 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp->cur_tx[%d], sp->dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev->name, sp->cur_tx, sp->dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre13: Small patches
Here's a brace of small patches that ought to be OK for 2.2.18.
adTHANKSvance for consideration
1. Fix fencepost error in ioremap's page reservation logic.
(I think the broken logic was added to support AGP.)
Index: linux/arch/i386/mm/ioremap.c
--- linux/arch/i386/mm/ioremap.c:1.2Fri Sep 1 19:03:09 2000
+++ linux/arch/i386/mm/ioremap.cThu Sep 28 00:34:40 2000
@@ -117,7 +117,7 @@
temp_addr = __va(phys_addr);
temp_end = temp_addr + (size - 1);
- for(i = MAP_NR(temp_addr); i < MAP_NR(temp_end); i++) {
+ for(i = MAP_NR(temp_addr); i <= MAP_NR(temp_end); i++) {
if(!PageReserved(mem_map + i))
return NULL;
}
2. Fix linear RAID to work even with blocks smaller than 1K.
(From Anton Altparmakov <[EMAIL PROTECTED]>)
In linux/drivers/block/linear.c:linear_map(), change:
*rsector=(block-(tmp_dev->offset)) << 1;
to:
*rsector=((block - tmp_dev->offset) << 1) + (*rsector & 1);
3. Trivial patch to fs/vfat/namei.c to avoid a compile-time warning.
Index: linux/fs/vfat/namei.c
--- linux/fs/vfat/namei.c:1.2 Fri Sep 1 19:03:16 2000
+++ linux/fs/vfat/namei.c Thu Sep 28 00:53:55 2000
@@ -676,7 +676,8 @@
i += 4;
} else {
int llen;
- nls->char2uni(ip, , op, op+1);
+ nls->char2uni((unsigned char *)ip,
+ , op, op+1);
op += 2;
ip += llen;
i += llen;
4. Config option controlling default behavior of kernels that enable
boot-time IP-Config.
* If CONFIG_IP_PNP_AUTO is set, the default is to do IP-Config at
boot time. Disable it with "ip=off".
* If CONFIG_IP_PNP_AUTO is not set, the default is *not* to do
IP-Config at boot time. Override with "ip=on", "ip=dhcp", etc.
Index: linux/net/ipv4/Config.in
diff -u linux/net/ipv4/Config.in:1.2 linux/net/ipv4/Config.in:1.2.8.1
--- linux/net/ipv4/Config.in:1.2Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/Config.inThu Sep 28 00:42:00 2000
@@ -22,6 +22,9 @@
bool ' RARP support' CONFIG_IP_PNP_RARP
# not yet ready..
# bool ' ARP support' CONFIG_IP_PNP_ARP
+ if [ "$CONFIG_IP_PNP_DHCP" = "y" -o "$CONFIG_IP_PNP_BOOTP" = "y" -o
+"$CONFIG_IP_PNP_RARP" = "y" ]; then
+bool ' Auto DHCP/BOOTP/RARP at boot' CONFIG_IP_PNP_AUTO
+ fi
fi
if [ "$CONFIG_FIREWALL" = "y" ]; then
bool 'IP: firewalling' CONFIG_IP_FIREWALL
Index: linux/net/ipv4/ipconfig.c
diff -u linux/net/ipv4/ipconfig.c:1.2 linux/net/ipv4/ipconfig.c:1.2.8.1
--- linux/net/ipv4/ipconfig.c:1.2 Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/ipconfig.c Thu Sep 28 00:42:00 2000
@@ -87,7 +87,13 @@
* Public IP configuration
*/
-int ic_enable __initdata = 0; /* IP config enabled? */
+int ic_enable __initdata = /* IP config enabled? */
+#ifdef CONFIG_IP_PNP_AUTO
+ 1
+#else
+ 0
+#endif
+;
/* Protocol choice */
static int ic_proto_enabled __initdata = 0
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send 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] 2.2.18pre13: USB tweak for VAIO
Patch: usbdock-1
From: Geoff Harrison <[EMAIL PROTECTED]>
Allow short report frames via USB ... apparently they are normal for
some Sony VAIOs when docked.
Index: linux/drivers/usb/hid.c
diff -u linux/drivers/usb/hid.c:1.2 linux/drivers/usb/hid.c:1.2.2.1
--- linux/drivers/usb/hid.c:1.2 Wed Sep 27 23:44:24 2000
+++ linux/drivers/usb/hid.c Thu Sep 28 11:51:32 2000
@@ -1096,10 +1096,12 @@
return;
}
+#if 0
if (len < ((report->size - 1) >> 3) + 1) {
dbg("report %d is too short, (%d < %d)", report->id, len,
((report->size - 1) >> 3) + 1);
return;
}
+#endif
for (n = 0; n < report->maxfield; n++)
hid_input_field(device, report->field[n], data);
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
On Mon, Oct 02, 2000 at 03:26:39PM +0200, Christoph Hellwig wrote: > On Mon, Oct 02, 2000 at 08:01:14AM -0500, Jeff Garzik wrote: > > > Christoph Hellwig sent me a better patch, with Cc: to Linus, so I hope this > > > will be fixed in test9. > > > > *nudge* Here's hoping that one of you guys will post the patch, since > > it's quite useful and I don't see it on lkml Otherwise it might be > > Tuesday (test9-final) before everyone else gets the fix Ok, yet another fix, this time it's the toplevel Makefile. --- Makefile~ Fri Sep 29 20:46:16 2000 +++ MakefileMon Oct 2 21:15:05 2000 @@ -176,7 +176,7 @@ DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.o DRIVERS-$(CONFIG_ACPI_INTERPRETER) += drivers/acpi/acpi.o -DRIVERS-$(CONFIG_BLK_DEV_MD) += drivers/md/mddev.o +DRIVERS-$(CONFIG_MD) += drivers/md/mddev.o DRIVERS += $(DRIVERS-y) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
On Sun, Oct 01, 2000 at 09:14:49PM -0700, Linus Torvalds wrote:
>
> Last pre-kernel - I'll do the real test9 before I fly off to Germany on
> Tuesday.
>
> Linus
> ---
> - pre8:
> - initialize to zero -> put it in the .bss instead
This patch was inspired by a comment from Jeff Garzik. It should
be correct (famous last words!) and consists of trivial changes
to the affected files to correct __initdata and pointers to
strings. Thus the crosspost to the maintainers, Linus and
l-k. That being said, I sure hope it is correct :)
--- linux-240-test9-pre8-clean/drivers/acorn/net/etherh.c Mon Oct 2 22:33:40
2000
+++ linux/drivers/acorn/net/etherh.cMon Oct 2 21:14:35 2000
@@ -67,7 +67,7 @@
MODULE_AUTHOR("Russell King");
MODULE_DESCRIPTION("i3 EtherH driver");
-static char *version __initdata =
+static char version[] __initdata =
"etherh [500/600/600A] ethernet driver (c) 2000 R.M.King v1.07\n";
#define ETHERH500_DATAPORT 0x200 /* MEMC */
--- linux-240-test9-pre8-clean/drivers/block/xd.c Mon Oct 2 22:29:44 2000
+++ linux/drivers/block/xd.cMon Oct 2 22:06:20 2000
@@ -116,7 +116,7 @@
};
static struct hd_struct xd_struct[XD_MAXDRIVES << 6];
-static int xd_sizes[XD_MAXDRIVES << 6], xd_access[XD_MAXDRIVES] = { 0, 0 };
+static int xd_sizes[XD_MAXDRIVES << 6], xd_access[XD_MAXDRIVES];
static int xd_blocksizes[XD_MAXDRIVES << 6];
extern struct block_device_operations xd_fops;
@@ -141,12 +141,12 @@
static DECLARE_WAIT_QUEUE_HEAD(xd_wait_int);
static DECLARE_WAIT_QUEUE_HEAD(xd_wait_open);
static u_char xd_valid[XD_MAXDRIVES] = { 0,0 };
-static u_char xd_drives = 0, xd_irq = 5, xd_dma = 3, xd_maxsectors;
-static u_char xd_override __initdata = 0, xd_type = 0;
+static u_char xd_drives, xd_irq = 5, xd_dma = 3, xd_maxsectors;
+static u_char xd_override __initdata, xd_type __initdata;
static u_short xd_iobase = 0x320;
-static int xd_geo[XD_MAXDRIVES*3] __initdata = { 0,0,0,0,0,0 };
+static int xd_geo[XD_MAXDRIVES*3] __initdata;
-static volatile int xdc_busy = 0;
+static volatile int xdc_busy;
static DECLARE_WAIT_QUEUE_HEAD(xdc_wait);
static struct timer_list xd_timer, xd_watchdog_int;
--- linux-240-test9-pre8-clean/drivers/net/acenic.c Mon Oct 2 22:33:48 2000
+++ linux/drivers/net/acenic.c Mon Oct 2 22:10:33 2000
@@ -393,22 +393,22 @@
#define DEF_TRACE 0
#define DEF_STAT (2 * TICKS_PER_SEC)
-static int link[ACE_MAX_MOD_PARMS] = {0, };
-static int trace[ACE_MAX_MOD_PARMS] = {0, };
-static int tx_coal_tick[ACE_MAX_MOD_PARMS] = {0, };
-static int rx_coal_tick[ACE_MAX_MOD_PARMS] = {0, };
-static int max_tx_desc[ACE_MAX_MOD_PARMS] = {0, };
-static int max_rx_desc[ACE_MAX_MOD_PARMS] = {0, };
-static int tx_ratio[ACE_MAX_MOD_PARMS] = {0, };
+static int link[ACE_MAX_MOD_PARMS];
+static int trace[ACE_MAX_MOD_PARMS];
+static int tx_coal_tick[ACE_MAX_MOD_PARMS];
+static int rx_coal_tick[ACE_MAX_MOD_PARMS];
+static int max_tx_desc[ACE_MAX_MOD_PARMS];
+static int max_rx_desc[ACE_MAX_MOD_PARMS];
+static int tx_ratio[ACE_MAX_MOD_PARMS];
static int dis_pci_mem_inval[ACE_MAX_MOD_PARMS] = {1, 1, 1, 1, 1, 1, 1, 1};
-static const char __initdata *version =
+static char version[] __initdata =
"acenic.c: v0.47 09/18/2000 Jes Sorensen, [EMAIL PROTECTED]\n"
"http://home.cern.ch/~jes/gige/acenic.html\n";
-static struct net_device *root_dev = NULL;
+static struct net_device *root_dev;
-static int probed __initdata = 0;
+static int probed __initdata;
#ifdef NEW_NETINIT
--- linux-240-test9-pre8-clean/drivers/net/rrunner.cMon Oct 2 22:28:48 2000
+++ linux/drivers/net/rrunner.c Mon Oct 2 21:14:35 2000
@@ -102,7 +102,7 @@
* stack will need to know about I/O vectors or something similar.
*/
-static const char __initdata *version = "rrunner.c: v0.22 03/01/2000 Jes Sorensen
([EMAIL PROTECTED])\n";
+static char version[] __initdata = "rrunner.c: v0.22 03/01/2000 Jes Sorensen
+([EMAIL PROTECTED])\n";
static struct net_device *root_dev = NULL;
--- linux-240-test9-pre8-clean/drivers/net/3c505.c Mon Oct 2 22:33:48 2000
+++ linux/drivers/net/3c505.c Mon Oct 2 21:14:35 2000
@@ -130,15 +130,15 @@
#define INVALID_PCB_MSG(len) \
printk(invalid_pcb_msg, (len),filename,__FUNCTION__,__LINE__)
-static char *search_msg __initdata = "%s: Looking for 3c505 adapter at address
%#x...";
+static char search_msg[] __initdata = "%s: Looking for 3c505 adapter at address
+%#x...";
-static char *stilllooking_msg __initdata = "still looking...";
+static char stilllooking_msg[] __initdata = "still looking...";
-static char *found_msg __initdata = "found.\n";
+static char found_msg[] __initdata = "found.\n";
-static char *notfound_msg __initdata = "not found (reason = %d)\n";
+static char notfound_msg[] __initdata = "not found (reason = %d)\n";
-static char *couldnot_msg __initdata = "%s: 3c505 not found\n";
+static char couldnot_msg[] __initdata = "%s: 3c505 not
Re: Login prompt auto-regen
Thanks Jeff "Mike A. Harris" wrote: > > On Mon, 2 Oct 2000, Jeff V. Merkey wrote: > > >Date: Mon, 02 Oct 2000 13:35:47 -0600 > >From: Jeff V. Merkey <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Content-Type: text/plain; charset=us-ascii > >Subject: Login prompt auto-regen > > > > > >Alan, > > > >Your mail server is getting errors at address <[EMAIL PROTECTED]>. I am > >seeing "connection deferred" and relaying denied. Where are the scripts > >in 6.X RedHat that auto-regne the RedHat Login prompt? > > In Red Hat, /etc/rc.d/rc.local regen's the /etc/issue and > /etc/issue.net files at boot time. > > -- > Mike A. Harris - Linux advocate - Open source advocate > Computer Consultant - Capslock Consulting > Copyright 2000 all rights reserved > -- > > Be up to date on nerd news and stuff that matters: http://slashdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Login prompt auto-regen
On Mon, 2 Oct 2000, Jeff V. Merkey wrote: >Date: Mon, 02 Oct 2000 13:35:47 -0600 >From: Jeff V. Merkey <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=us-ascii >Subject: Login prompt auto-regen > > >Alan, > >Your mail server is getting errors at address <[EMAIL PROTECTED]>. I am >seeing "connection deferred" and relaying denied. Where are the scripts >in 6.X RedHat that auto-regne the RedHat Login prompt? In Red Hat, /etc/rc.d/rc.local regen's the /etc/issue and /etc/issue.net files at boot time. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Be up to date on nerd news and stuff that matters: http://slashdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Inter-device-driver communication?
** Reply to message from Jeff Garzik <[EMAIL PROTECTED]> on Mon, 2 Oct 2000 15:31:59 -0500 (CDT) > You must describe -what- is being communicated, -how much- data is being > communicated, and -how often- communication occurs before we can help > suggest a method of driver<->driver communication. Ok, let me try again! The primary communication needs to be high-speed above all else. The amount of data that needs to be sent is rather small, typically just a small structure. However, there will be plenty of pointers in these structures, and these pointers mostly point to buffers of about 1-8KB. Since the kernel is monolothic, I don't expect there to be a need to translate virtual addresses. As for how often, these calls are made probably as much as 50 times a second, but irregularly. One of the drivers involved is attached to the VM, so it will need to pass data along as often as the VM is called. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ReiserFS PATCH] fs/Makefile changes in pre8
Hiya all. The fs/Makefile changes in pre8 mean that the newest reiserfs patch won't cleanly apply any more (meaning that reiserfs doesn't get built). The following patch appears to fix it here---can someone check that it's correct, and if so can the reiserfs maintainers modify their patch accordingly? --- linux/fs/Makefile.orig Mon Oct 2 21:27:28 2000 +++ linux/fs/Makefile Mon Oct 2 21:28:41 2000 @@ -60,6 +60,7 @@ subdir-$(CONFIG_ADFS_FS) += adfs subdir-$(CONFIG_DEVPTS_FS) += devpts subdir-$(CONFIG_SUN_OPENPROMFS)+= openpromfs +subdir-$(CONFIG_REISERFS_FS) += reiserfs obj-$(CONFIG_BINFMT_AOUT) += binfmt_aout.o -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-2.2] Bonding Driver Enhancements + Security fix
Willy TARREAU wrote:
>
> Hello Thomas !
>
> I've slightly enhanced the bonding code :
> - MII link checking with automatic slave enabling/disabling :
> Now the bond interface monitors all its MII-compliant slaves
> and disables the ones which have a dead link, and enables those
> which have a good one. The link check time defaults to 1 second
> but I've seen no overhead even at 30 ms.
>
> - slave release is now possible with a running bond
> - SMP-safe enslave/release/check/stats/xmit
> - fix a security bug which allowed anybody to enslave any active interface,
> thus making a local denial of service.
> - fix a potential infinite loop in bond_xmit() if no slave is useable.
>
> It now works very well for me, and the removal of a link becomes
> completely transparent now. On monday, I'll trunk it to an alteon switch.
>
> I've stressed the enslave/release code during "ping -f" and links up/down,
> but triggered absolutely no problem. I think it's stable enough to include it
> in 2.2.18 (Alan CC'ed for this). I'd like Constantine to test it on his servers
> because it should do exactly what he needed, and send us his feedback.
>
Ok, I have several things, since work is being done on this..
rename bond_xmit to bond_xmit_roundrobin, so bond_xmit_xor can be
implemented, and used if desired. bond_xmit_xor is what cisco
etherchannel/sun trunking really uses, not round robin.
Remove the variable counters from the xmit loop.. Make it more like:
(from the 2.4 bonding driver)
start = slave = bond
do {
if (slave == bond)
continue;
if (blah..blah)
do xmit()
return 0;
}
} while ((slave=slave->next) != start_at);
kfree(skb);
return 0;
This simplifies the transmit path; and bonding is cpu intensive already!
I'd also like to get the help included.. see attached patch for that!
--
+--
Thomas Davis| PDSF Project Leader
[EMAIL PROTECTED] |
(510) 486-4524 | "Only a petabyte of data this year?"
diff -ruN linux-2.2.17-RAID/Documentation/Configure.help
linux/Documentation/Configure.help
--- linux-2.2.17-RAID/Documentation/Configure.help Tue Sep 19 17:18:27 2000
+++ linux/Documentation/Configure.help Mon Oct 2 13:32:41 2000
@@ -4901,6 +4901,28 @@
time, you need to compile this driver as a module. Instead of
'dummy', the devices will then be called 'dummy0', 'dummy1' etc.
+Bonding driver support
+CONFIG_BONDING
+ Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
+ Channels together. This is called 'Etherchannel' by Cisco,
+ 'Trunking' by Sun, and 'Bonding' in Linux.
+
+ If you have two ethernet connections to some other computer, you can
+ make them behave like one double speed connection using this driver.
+ Naturally, this has to be supported at the other end as well, either
+ with a similar Bonding Linux driver, a Cisco 5500 switch or a
+ SunTrunking SunSoft driver.
+
+ This is similar to the EQL driver, but it merges Ethernet segments
+ instead of serial lines.
+
+ For more information, please see Documentation/networking/bonding.txt.
+
+ If you want to compile this as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want),
+ say M here and read Documentation/modules.txt. The module will be
+ called bonding.o.
+
SLIP (serial line) support
CONFIG_SLIP
Say Y if you intend to use SLIP or CSLIP (compressed SLIP) to
Re: Inter-device-driver communication?
On Mon, 2 Oct 2000, Timur Tabi wrote: > ** Reply to message from Jeff Garzik <[EMAIL PROTECTED]> on > > For driver<->driver communication, it is totally dependent on what you > > need to communicate. It could be something as simple as a small, shared > > module protected by a spinlock, or something more complex. Really task > > dependent.. > > The communication would be like an ioctl, but to me, ioctls are something that > processes send to drivers, not something that drivers send to other drivers. I > just wanted to know if sending an ioctl from one driver to another was common, > and if not, what the alternative is. > > For example, under OS/2, drivers communicate amongst themselves by something > known as an IDC. There is a kernel API for getting the IDC entry point of > another driver, which is really nothing more than a pointer. The calling > driver just sets up his stack and/or registers, and just makes a call to the > IDC entry point as if it were a normal function. There is no kernel > involvement in this call, and so the calling convention, etc is completely > defined by the callee. I think you misunderstand... there are many ways for Linux drivers to communicate between one another. There is no one standard way, because no one standard way can cover all situations. You must describe -what- is being communicated, -how much- data is being communicated, and -how often- communication occurs before we can help suggest a method of driver<->driver communication. In other words, the method of driver communication is part of your design, not a piece of existing kernel API. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: st0 errors
On Thu, Sep 28, 2000 at 10:55:58AM -0500, Michael J. Dikkema wrote: > Whenever I try to read from my tape drive, it gives this error.. and tar > can't get anything off. Does anyone know what this means? > > st0: Error 2603 (sugg. bt 0x20, driver bt 0x26, host bt 0x3). I've got similar problems with my tape, I wonder if there is this has a common cause. What is the type of your tape drive? Ralf - To unsubscribe from this list: send 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: Soft-Updates for Linux ?
On Sun, Oct 01, 2000 at 10:21:34AM -0500, Robert Redelmeier wrote: > As an experiment, I pulled the plug towards the end of 5 FreeBSD kernel > compiles (SMP `make -j4`). In all cases, the fsck upon restart was minor, > just freeing inodes. In four of the cases, `make` just picked up where > it left off, and finished the kernel compile, losing only ~40 seconds work! > In one case, a `make clean` had to be done because something was incomplete. > > You boys and girls don't try this at home on Linux! The ext2 fsck is horrible > after a powerfail, and I've lost superblocks and had to re-install :( . There is actually some indication that part of the corruption people observe after powerfails is caused by hardware scribbling junk data over the disk in the very last moment when power levels in the system are already so low that memory is already starting to fail while I/O hardware is still doing their best to write junk data to the disk. These days powerfails are rare and so it's easy to attribute that to something else. I'm now using ext2 since '93 or so and I haven't ever lost a complete filesystem. In fact in practice it's amazing how resistant ext2 is to extreme data corruption such as caused by the good old problem of the kernel and ext2utils having different ideas of the bitfield endianess ... Maybe it's time to implement support for power fail / power return interrupts where supported by hardware. At least on Indy that gives you ~ 10ms to stop whatever is going on before power finally fails. Ralf - To unsubscribe from this list: send 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: Inter-device-driver communication?
On Mon, 2 Oct 2000, Timur Tabi wrote: > Could someone tell me what is the preferred method of having two drivers > communicate with each other? I know a driver can send an ioctl to another > driver, but since both drivers exist in kernel space, and the kernel is > monolithic, I figured that direct calls from one driver to another is not only > possible but common. > Also, is it possible for one driver to load another driver? Would that require > kerneld, or is there a more direct procedure? Unfortunately this question is a bit too high level... You can certain have one driver load another via modprobe (grep for CONFIG_KMOD), but if both drivers will be required, module dependencies might simply pull in one of the drivers automatically. For driver<->driver communication, it is totally dependent on what you need to communicate. It could be something as simple as a small, shared module protected by a spinlock, or something more complex. Really task dependent.. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17 3Com bug
Hello, I ran RedHat 6.2 and tried all sorts of kernels.. no problem at all. I ran kernel 2.2.17 and everytime MS-Windows has booted(I run a dual-boot sys) my networkcard (eth0=dhcp=3c59x.o) doesn't want to connect to the internet. First I thought this was my isp his fault or my redhat was broken. But this problem stayed. Now, I run Debian 2.2 kernel 2.2.17 and I have the same problem. When Windows has booted and I want to get back into linux, I have to wait half an hour until my networkcard works again. Now, I haven't had this problem before with older kernels, not even with 2.4.0-testx I don't know what to about this, maybe it's not a bug at all but I don't trust it. Summary: problem: no dhcp-lease at boot(have to wait almos half an hour) module: 3c59x Thanks for reading my mail Yours sincerely hdcool - To unsubscribe from this list: send 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: SA_INTERRUPT
On Mon, Oct 02, 2000 at 09:45:36PM +0200, Roman Zippel wrote: > When that is done, please don't call __sti() directly and use some macro > that can be overridden by the architectures. What do you have in mind while making this suggestion? The irq highlevel layer is pretty much architectural indipendent. Just run a diff between the irq.c in the IA32 and alpha ports. Also what about the drivers that are just using __sti() at the start of the irq handler right now? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Inter-device-driver communication?
Could someone tell me what is the preferred method of having two drivers communicate with each other? I know a driver can send an ioctl to another driver, but since both drivers exist in kernel space, and the kernel is monolithic, I figured that direct calls from one driver to another is not only possible but common. Also, is it possible for one driver to load another driver? Would that require kerneld, or is there a more direct procedure? -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problems with 2.4.0-test8
Rik van Riel wrote: > > On Mon, 2 Oct 2000, Petko Manolov wrote: > > Richard Polton wrote: > > > > I am using 2.4.0-test8 on an i686 laptop. I find that netscape-4.72 > > > keeps locking up. I am not able to kill the process at all (without > > > a reboot, and SysRQ cannot do a sync on the partition it is running > > > in either). I have been advised that RvR's memory patches will fix > > > this but I have yet to try. (This behaviour also can be seen with > > > ppp-2.4.0, which is a trifle irritating 8-) > > > > I have the same kind of problems with 2.4.0-test8, test-9-pre[678]. > > > > I'd thought it is due to bug in my (usb pegasus) driver which i used > > most of the time. But i got the same crash with eepro100 which is > > considered to be fairly solid. > > > > The bug appears when netscape tries to switch the windows or open new > > one. I'm afraid the newest RvR's MM code is not so stable. > > You may want to try my latest patch ;) > > I have known about these problems for about 2 weeks, but > was away at conferences so couldn't create a clean enough > patch to send to Linus ;( > > http://www.surriel.com/patches/ > > regards, > > Rik > -- Actually, I think this particular problem in -test8 was with buffer.c for which DaveM submitted a patch some time ago. Check your logs for: kernel BUG at ll_rw_blk.c:711 -- === -- Tim - To unsubscribe from this list: send 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: sigtimedwait with a zero timeout
James Antill wrote: > If you want to return imediatley (and there might not be data) the > answer given is usually... > > sigqueue( ... ); > sigwaitinfo( ... ); > > If the above will still schedule, then Linus might be more likely to > take a patch (I'd guess that he'd look at sigtimedwait() to be like > sleep() in most other cases though). If you mean that I can work around the problem by forcing a pending entry with a known tag and then poll with sigtimedwait/sigwaitinfo until I see this tag then it is doable, but I don't see the good in in this when a) sigtimedwait is documented in at least SUSV2 to return immediately with an error if the queue is emtpy and the timeout is zero b) As shown it is quite easily patchable (a simple if, and a few lines rearranged to fit the if) c) It is pure overhead, while the patch is close to no overhead: one added comparisation for the codepath when a timeout is selected, which in the context is nothing. -- Henrik Nordstrom - To unsubscribe from this list: send 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: SA_INTERRUPT
Hi, On Sun, 1 Oct 2000, Andrea Arcangeli wrote: > Comments? When that is done, please don't call __sti() directly and use some macro that can be overridden by the architectures. bye, Roman - To unsubscribe from this list: send 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] fs/Makefile error in test9pre8 (dquot.o left behind)
Hi. When I compile a test9pre8 kernel with quota support I get a lot of link errors regarding quota stuff. The patch below fixes this by correcting what seems to be a mailer/mime error: --- linux-240test9-pre8-clean/fs/Makefile Mon Oct 2 21:07:54 2000 +++ linux/fs/Makefile Mon Oct 2 21:43:56 2000 @@ -17,7 +17,7 @@ filesystems.o ifeq ($(CONFIG_QUOTA),y) -obj=ADy += dquot.o +obj-y += dquot.o else obj-y += noquot.o endif -- Rasmus([EMAIL PROTECTED]) "An intellectual is someone whose mind watches itself." -- Albert Camus (1913-1960) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.9.8: Fix IDE...
> My previous patch was a fix, but (brown paper bag time) standard IDE > devices no longer called chipset init. People either had no IDE, or > were stuck in legacy mode. This fixes it. This fixes the bootup oops with 2.4.0-test9-pre8 i reported on lkml an hour or 2 ago. b <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] linux/net/arp.c, fixes IP/hw type collision, removes unused code
Would you guys please look this over and say yes or no for Linus. I've
posted this as a fix for several people several times and not gotten any
responses from the top dogs. There are no complaints about it, it's in
the form Alexey wants and fixes the arp problem. The second portion of
the patch removes the %s, "*" for the mask as the mask isn't implemented
in this area and I'm told it won't be.
current broken implementation (eth0 works, this is an example, other
types of devices yield the below):
$ cat /proc/net/arp
IP address HW type Flags HW address
Mask Device
208.179.0.1930x1 0x2 00:E0:98:70:1E:AF
*eth0
fixed version:
$ cat /proc/net/arp
IP address HW type Flags HW address
Mask Device
208.179.0.1930x1 0x2 00:E0:98:70:1E:AF
*eth0
-d
--
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas Jefferson [1742-1826], 3rd US President
--- net/ipv4/arp.c.orig Fri Aug 4 18:18:49 2000
+++ net/ipv4/arp.c Sat Sep 23 12:47:03 2000
@@ -65,6 +65,7 @@
* clean up the APFDDI & gen. FDDI bits.
* Alexey Kuznetsov: new arp state machine;
* now it is in net/core/neighbour.c.
+ * David Ford : More fixes cleaning up the proc output
*/
/* RFC1122 Status:
@@ -1025,6 +1026,7 @@
char hbuffer[HBUFFERLEN];
int i,j,k;
const char hexbuf[] = "0123456789ABCDEF";
+ char abuf[16];
size = sprintf(buffer,"IP address HW type Flags HW address
Mask Device\n");
@@ -1063,20 +1065,15 @@
}
#endif
- {
- char tbuf[16];
- sprintf(tbuf, "%u.%u.%u.%u",
NIPQUAD(*(u32*)n->primary_key));
-
- size = sprintf(buffer+len, "%-16s 0x%-10x0x%-10x%s",
- tbuf,
- hatype,
- arp_state_to_flags(n),
- hbuffer);
-
- size += sprintf(buffer+len+size,
-" %-8s %s\n",
-"*", dev->name);
- }
+ size = sprintf(buffer+len, "%-16s 0x%-10x0x%-10x%s",
+ in_ntoa2(*(u32*)n->primary_key, abuf),
+ hatype,
+ arp_state_to_flags(n),
+ hbuffer);
+
+ size += sprintf(buffer+len+size,
+ " *%-16s\n",
+ dev->name);
read_unlock(>lock);
@@ -1099,15 +1096,15 @@
struct net_device *dev = n->dev;
int hatype = dev ? dev->type : 0;
- size = sprintf(buffer+len,
- "%u.%u.%u.%u0x%-10x0x%-10x%s",
- NIPQUAD(*(u32*)n->key),
+ size = sprintf(buffer+len, "%-16s 0x%-10x0x%-10x%s",
+ in_ntoa2(*(u32*)n->key, abuf),
hatype,
ATF_PUBL|ATF_PERM,
"00:00:00:00:00:00");
+
size += sprintf(buffer+len+size,
-" %-17s %s\n",
-"*", dev ? dev->name : "*");
+ " *%-16s\n",
+ dev ? dev->name : "*");
len += size;
pos += size;
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard
Login prompt auto-regen
Alan, Your mail server is getting errors at address <[EMAIL PROTECTED]>. I am seeing "connection deferred" and relaying denied. Where are the scripts in 6.X RedHat that auto-regne the RedHat Login prompt? Thanks Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4 kernel wiki for October
The October 2000 Kernel Wiki Challenge is ... "The most misunderstood part about in Linux 2.4 is " 1) Fill in the blanks, short and sweet, in your own words. 2) Go to http://kernelbook.sourceforge.net/wiki/?KernelWiki find the appropriate subsection of the Wiki covering your area of expertise. 3) Click the "Edit this Page" link 4) Plunk your October KernelWiki response into the text box. 5) Click "Save" and get back to your happy hacking. It's painless. All I want is 10 minutes of your time. You know you know the answers, and if you don't, you know the proper questions to ask. I don't know how I can make it any easier. 10 minutes, 15 tops. No excuses. _Everyone_ has that kind of time to spare for Linux documentation. There are hundreds of competent engineers active on this mailing list. One day's worth of our collective linux-kernel effort, focussed precisely on illuminating some part of the code, would complete several chapters of text. A week's worth would fill a thousand pages. If everyone gives just _10_ _minutes_ a month, we can _completely_ document 2.4 by groundhog day. What do you win? Do it right, and you might cause that "transmission of light" that nets you some assistance in your kernel hacking. WARNING: I am going to persist in nagging you to participate, but no more than once a month ;) Put me in your kill file if you will but if KernelWiki is ignored or abused, it dies. I leave it at the mercy of the court. If you have more than 15 minutes to spare and you are interested in what it is that I'm up to with this Wiki thing, you are invited to read http://kernelbook.sourceforge.net/wiki/?KernelWikiWhy http://kernelbook.sourceforge.net/wiki/?KernelWikiPolicies http://kernelbook.sourceforge.net/wiki/?HowToUseWiki -- Gary Lawrence Murphy <[EMAIL PROTECTED]> TeleDynamics Communications Inc Business Innovations Through Open Source Systems: http://www.teledyn.com "Computers are useless. They can only give you answers."(Pablo Picasso) - To unsubscribe from this list: send 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: Meaning of blk_size
Hi, On Mon, 2 Oct 2000, Andries Brouwer wrote: > These days I have as background activity the construction > of the corresponding patch for 2.4. Maybe we can start 2.5 > without these arrays and with large device numbers. I started something like this a few months ago, I was at the point to boot a usermode kernel till the fsck, which failed. Currently I have no time to continue it, as there is more important work pending. But I didn't create a generic kdev_t, I changed the block device part to use a bdev_t, I also started a few cleanups that make e.g. the partition stuff a bit easier. On the other hand it breaks of course every block device driver. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: PPPD CRASH
Please don't post attachments except for unique documents such as program sources. On Mon, 2 Oct 2000, Lucien Rocha wrote: |[2.] The problem is described in 5., i only got this problem with this |new kernel. Before i upgrade i was using kernel 2.2.14cl and ppp runs |nice, but i got problems with sound VIA-chipset(like in docs), then, i |decided to upgrade, with this kernel(2.2.17) my sound works fine, but ppp |crashs, i´ve tried to compile the kernel 2.2.16 and got problems with ppp |too... | |[4.] Linux krypton 2.2.17 #9 Sun Oct 1 11:24:29 BRST 2000 i586 unknown | [5.] Sep 25 11:35:56 krypton kernel: Lucent Modem driver version |4.27.5.66 with MANY_PORTS MULTIPORT SHARE_IRQ enabled My guess is that this is the problem. You may get help here but I wouldn't bet on it, these drivers are almost always distributed as binary modules. A module built for one kernel isn't likely to work with another kernel. Even if you have the source and compile it after installing a new kernel source tree there is a high probability that it still won't work. Try contacting the folks that produced the Lucent driver. Or better, get a real modem. Drivers for Winmodems and their relatives are usually not made by folks that are willing to contribute the source to become a part of the kernel source. In such cases you are unlikely to get help from anyone except, rarely, from the creators of the drivers themselves. --- Clifford Kite Not a guru. (tm) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
CD slowdown
#include I two Pioneer DVD U04S (SCSI) 10x DVD 40xCD. When i want to play CD-Rs they are "loud". So i searched for a "slowdown" Programm on freshmeat and fount "cdrom_speed.c". The problem is that the drive seems to ignore the speed changes and spins the CDR with full speed. Kernel is 2.2.17, HA is an adaptec 7895. (Drives are Pioneer DVD U04S) Is there something i can do? Or do i have to change the drives with U03S ones. (Which are nearly noiseless) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send 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: Running SPEC SFS 2.0 on Linux
On Mon, 2 Oct 2000, Samar Sharma wrote:
>
> Does anyone have experience with running SPEC SFS 2.0 on kernel 2.4 ?
>
> Specifically, I am looking for the values in C.vendor and M.vendor files.
>
attached. Enjoy.
Regards,
Tigran
#!/bin/sh
#
##
#
# @(#)C.solaris2 2.197/10/23
#
# Specify vendor specific command paths and commands for the LADDIS tools
#
# The variables: PASSWD_FILE, FSTAB_FILE, GROUP_FILE, HOSTNAME_CMD, RSH_CMD
# allow you to specify the LADDIS client command for use in running the
# Remote Client Setup Utilities the clients.
#
# The default command/path options are implied if no values are assigned to
# the variables. The variables and their meaning are as follows:
#
# PASSWD_FILE- Name of the client's passwd file.
# FSTAB_FILE - Name of the client's fstab file.
# GROUP_FILE - Name of the client's group file.
# HOSTNAME_CMD - Client's hostname command.
# RSH_CMD- Client's rsh command.
# SHELL - Client's bourne shell (/bin/sh or /bin/sh5).
# AWK_CMD- Client's awk command (/bin/sh -> awk or /bin/sh5 -> nawk).
# PS_CMD - Client's ps command.
# ECHO - The echo command.
# ECHO_NONL - The echo command used for questions that no newline is
# needed. This is used in conjunction with the parameter
# NONL. The options are: ECHO_NONL="echo -n" with NONL="" or
# ECHO_NONL="echo" with NONL="\c".
# NONL - The no newline option for the echo command.
#
#
PASSWD_FILE="/etc/passwd"
FSTAB_FILE="/etc/fstab"
GROUP_FILE="/etc/group"
HOSTNAME_CMD="uname -n"
RSH_CMD="rsh"
SHELL="/bin/sh"
AWK_CMD="awk"
PS_CMD="ps -ef"
ECHO="echo"
ECHO_NONL="echo"
NONL="\c"
#
export PASSWD_FILE FSTAB_FILE GROUP_FILE SHELL
export HOSTNAME_CMD RSH_CMD
export AWK_CMD PS_CMD ECHO NONL
#
# @(#)M.solaris22.1 97/10/23
#
# SUN Solaris 2.x specific Makefile wraper
#
# usage examples:
# make -f M.solaris2
# make -f M.solaris2 run
MACHID = linux
# C compiler and library options for compiling the benchmark programs.
# This example enables SAR within the benchmark for UNIX System VR4
# EXTRA_CFLAGS = -DSAR
CC=gcc
OPT = -O
#CFLAGS = -v -Xc -D__sparc -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1
CFLAGS = -v -DNO_T_TYPES -Dfds_bits=__fds_bits
LDFLAGS =
#EXTRA_CFLAGS = -DPORTMAP -DHAVE_INTTYPES
EXTRA_CFLAGS = -DPORTMAP
EXTRA_LDFLAGS =
EXTRA_LINTFLAGS=
LIBS=-lm
EXTRA_LIBS =
#
# If the server requires the client to be bound to a reserved port add this
#RESVPORT_MOUNT=-DRESVPORT
RESVPORT_MOUNT=
#
# SUN SunOS definitions
# For Solaris 2.X (SunOS 5.X) or later
OSTYPE = -DSVR4
#
STD_TGTS = all install clean clobber lint
$(STD_TGTS):
@make MACHID="${MACHID}" CC="${CC}" CFLAGS="${CFLAGS}" \
LDFLAGS="${LDFLAGS}" EXTRA_CFLAGS="${EXTRA_CFLAGS}" \
EXTRA_LDFLAGS="${EXTRA_LDFLAGS}" EXTRA_LIBS="${EXTRA_LIBS}" \
LIBS="${LIBS}" OSTYPE="${OSTYPE}" OPT="${OPT}" \
EXTRA_LINTFLAGS="${EXTRA_LINTFLAGS}" \
RESVPORT_MOUNT="${RESVPORT_MOUNT}" $@
Running SPEC SFS 2.0 on Linux
Does anyone have experience with running SPEC SFS 2.0 on kernel 2.4 ? Specifically, I am looking for the values in C.vendor and M.vendor files. Thanks. Samar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux 2.2.18pre15
Bug squash number three. ARM, Alpha and x86 should be completely sorted for the loops_per_sec change. S/390 merge yet to be done. PPC and Sparc still won't build. Alan Stuff left to do for 2.2.18final - loops_per_jiffy for non x86, Alpha, ARM - Merge the S/390 stuff and make S/390 build again - Fix the megaraid (revert if need be) The S/390 stuff shouldnt touch the mainstream so from hereon in its simply a case of squashing bugs as they pop out until its ready to be 2.2.18. 2.2.18pre15 o Default msdos behaviour to old (small) letters (me) | An option 'big' goes with 'small' o Fix define collision in cpqfc (Arjan van de Ven) o Fix case where scripts/kwhich isnt executable (me) o Alpha FPU divide fix(Richard Henderson) o Add ADMtek985 to the tulip list (J Katz) o Lose excess ymfpci debugging(Rob Landley) o Fix i2c bus id clash(Russell King) o Update the ARM vidc driver (Russell King) o Update the ARM am79c961a driver (Russell King) o Fix parport_pc build with no PCI(Russell King) o Fix ARM memzero (Russell King) o Update ARM for __init and __setup (Russell King) o Update ARM to loops_per_jiffy (Russell King) o Remove arm ecard debug messages (Russell King) o Fix ARM makefiles (Russell King) o Fix iph5526 driver to use mdelay(Arjan van de Ven) o Fix epca, dtlk, aha152x loops_per_sec bits (Philipp Rumpf) o Fix smp tlb invalidate and bogomip printing (Philipp Rumpf) o Fix NLS warnings(Arjan van de Ven) o Fix wavfront conversion to loops_per_jiffies(me) o Fix an audio problem and a sanyo changer(Jens Axboe) problem o Fix include bug with divert (me) | Alternate fix to Willy Tarreau's o Fix Alpha for loops_per_jiffy (Willy Tarreau) 2.2.18pre14 o Reorder attributes in drm to work with gcc272 (me) o GNU cross compilers are foo-bar-gcc (Russell King) o Add extra strange pcnet32 ident (Willy Tarreau) o Since no vendor can get which right.. use a (Miquel van Smoorenburg) shell script instead | Please nobody tell me this fails in some bash version! o Should be using bash not bash2 (escaped debug) (Petri Kaukasoina) o spin_unlock_irq wrong debug mode printk (Willy Tarreau) o Fix pcxx for the loops changes (Arjan van de Ven) o Fix ov511/via-rhine name clash (Arjan van de Ven) o Fix bridge compile with loops_per_sec change(Mitch Adair) o 8139too driver added(Jeff Garzik) 2.2.18pre13 o Change udelay to use loops_per tick (Philipp Rumpf) | Otherwise we bomb out at 2GHz which isnt far enough | away with 1.4/1.6GHz stuff due out RSN o Fix drivers using big delays to use mdelay (me) o Fix drivers that used loops_per_sec (Philipp Rumpf, me) o Fix yamaha PCI sound SMP bug(Arjan van de Ven) o Change to preferred USB init fix(David Rees) o Fix rio fix (Arjan van de Ven) o Catch the VT but no mouse case in init/main.c (Arjan van de Ven) o Fix the 'which' compiler stuff (Horst von Brand, Peter Samuelson) | Can someone verify for me this works on Slackware and | on Caldera ? o Add devfs include. Devfs wont be going into 2.2 (Richard Gooch) but this again makes it easier to do 2.2/2.4 drivers. 2.2.18pre12 o Fix cyrix MTRR handling bug (IIZUKA Daisuke) o Fix ymfpci poll (me, Arjan) o Update radio-maestro, add Configure.help(Adam Tla/lka> o Fix rio/generic serial build bug(Marcelo Tossati) o USB build bug fix (Arjan van de Ven) o Fix missing ac97_codec.c return value (Arjan van de Ven) o Fix several warnings(Arjan van de Ven) o Made the PS/2 reconnect behaviour optional (me) | Its now 'psaux-reconnect' on the boot line o Allow for newer Hauppauge with 4 ports (Krischan Jodies) o Switch sound drivers from library to object (Arjan van de Ven) o Kill the not working ac97 lock on the 810 (me) o Automatically select older compilers for kernel builds on Debian and RH
Re: PIDs limited to 15 significant bits
On Sun, Oct 01, 2000 at 10:48:41PM -0400, Albert D. Cahalan wrote: > I see you don't remember the original post. It argued in > favor of a large PID space "because the output of ps wouldn't > look nice otherwise"!!! (the poster wanted output sorted by > start time without using --sort=start to ask for it) Why not use 32-bit PIDs in the kernel, but make the number at which they wrap a configurable option? That way, most users can keep the numbers small for ease of management, and people who really need 100,000 processes can have them. -- Adam Sampson [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/
PATCH 2.4.0.9.8: Fix IDE...
Linus,
Ug. Why do I feel like the IDE "driver" is code layered upon code
layered upon code, through the ages, with nary a cleanup in between?
My previous patch was a fix, but (brown paper bag time) standard IDE
devices no longer called chipset init. People either had no IDE, or
were stuck in legacy mode. This fixes it.
The IDE layer is in serious need of a cleanup though, IMHO...
With this tested patch full functionality should be restored, without
reverting to the previously-crazy code found in test9-pre7 and before.
Jeff
Index: drivers/ide/ide-pci.c
===
RCS file: /usr/jgarzik/cvslan/linux_2_3/drivers/ide/ide-pci.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 ide-pci.c
--- drivers/ide/ide-pci.c 2000/10/02 08:32:44 1.1.1.9
+++ drivers/ide/ide-pci.c 2000/10/02 18:28:10
@@ -493,6 +493,7 @@
byte tmp = 0;
ide_hwif_t *hwif, *mate = NULL;
unsigned int class_rev;
+ int pci_class_ide;
#ifdef CONFIG_IDEDMA_AUTO
autodma = 1;
@@ -538,7 +539,8 @@
* Can we trust the reported IRQ?
*/
pciirq = dev->irq;
- if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {
+ pci_class_ide = ((dev->class >> 8) == PCI_CLASS_STORAGE_IDE);
+ if (!pci_class_ide) {
printk("%s: not 100%% native mode: will probe irqs later\n", d->name);
/*
* This allows offboard ide-pci cards the enable a BIOS,
@@ -548,11 +550,17 @@
*/
pciirq = (d->init_chipset) ? d->init_chipset(dev, d->name) :
ide_special_settings(dev, d->name);
} else if (tried_config) {
- printk("%s: will probe irqs later\n", d->name);
+ printk(KERN_INFO "%s: will probe irqs later\n", d->name);
pciirq = 0;
} else if (!pciirq) {
- printk("%s: bad irq (%d): will probe later\n", d->name, pciirq);
- pciirq = 0;
+ if (pci_class_ide) {
+ /* this is the normal path for most IDE devices */
+ if (d->init_chipset)
+ pciirq = d->init_chipset(dev, d->name);
+ else
+ printk(KERN_INFO "%s standard IDE storage device
+detected\n", d->name);
+ } else
+ printk(KERN_WARNING "%s: bad irq (0): will probe later\n",
+d->name);
} else {
if (d->init_chipset)
(void) d->init_chipset(dev, d->name);
-
To unsubscribe from this list: send 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: TODO list for new VM (oct 2000)
On Mon, 2 Oct 2000, Rik van Riel wrote: > On Mon, 2 Oct 2000, Linus Torvalds wrote: > > > Why do you apparently ignore the fact that page-out write-back > > performance is horribly crappy because it always starts out > > doing synchronous writes? > > Because it is fixed in the patch I mailed yesterday? One small warning though. Please don't apply that patch yet because I fixed 3 more small problems today. I'll send you an updated patch... - the compile warnings are fixed - in try_to_free_pages(), we forgot to set PF_MEMALLOC in current->flags (oops) - in grow_buffers(), in case we cannot get a buffer head, we must unlock the page A patch against 2.4.0-test9-pre8 with these 3 changes will be on its way once I've tested it a bit... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Meaning of blk_size
On Mon, Oct 02, 2000 at 07:11:52PM +0200, Daniel Phillips wrote: > One more question that has probably been asked a lot: why are the > various fields of a device splatted across half a dozen tables instead > of being collected together in a struct and accessed through one table? Yes, this has been asked a lot. I did this a few times. Half of the work was the introduction of the kdev_t opaque type - the patch was around 1.3.20. I am very glad this happened - it was a lot of work, determining for all integers in the kernel whether they held a device value or not. Today the kernel is seven times as large and such a change would be next to impossible. The other half increased in magnitude in the past five years. It is what you suggest: have a kdev_t that is a pointer to a struct that contains the fields that today live in these arrays. device size is a 64-bit bytecount, so no granularity problems. These days I have as background activity the construction of the corresponding patch for 2.4. Maybe we can start 2.5 without these arrays and with large device numbers. 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: Oops at bootup with 2.4.0-test9-pre8
> --test9-pre8 blows up at boot, somewhere around the ALI5X3 init. > > Here's the oops, with ksymoops decode. Copied by hand, > hope it's correct: Darn. Made 3 typos in transcription: ALI5X3: IDE controller on PCI buss 00 dev 78 ^ Process swapper (pid: 2, stackpage=c133d000) ^ should be "pid: 1" Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 0d 5b 5e ^ should be "9d" - Here's the corrected oops, with ksymoops decode: = ALI5X3: IDE controller on PCI bus 00 dev 78 ALI5X3: chipset revision 193 ALI5X3: bad irq (0): will probe later Unable to handle kernel paging request at virtual address 0010 printing eip c0178539 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010002 eax: ebx: 0002 ecx: edx: c133df3f esi: 005e edi: cbfec400 ebp: esp: c133def8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c133d000) Stack: c133df3f c020db96 005e c133df3f cbfec400 004b 004a cbfec400 004b c133df3f 01f0 c0258200 03f4 0246 4a0001f0 c020e6fe c0258200 c0214844 cbfec400 c024ccbc 8e00 Call Trace: [] [] Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 9d 5b 5e ksymoops 2.3.4 on i586 2.4.0-test9pre7. Options used -v ./vmlinux (specified) -K (specified) -L (specified) -O (specified) -m ./System.map (specified) Unable to handle kernel paging request at virtual address 0010 c0178539 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: ebx: 0002 ecx: edx: c133df3f esi: 005e edi: cbfec400 ebp: esp: c133def8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c133d000) Stack: c133df3f c020db96 005e c133df3f cbfec400 004b 004a cbfec400 004b c133df3f 01f0 c0258200 03f4 0246 4a0001f0 c020e6fe c0258200 c0214844 cbfec400 c024ccbc 8e00 Call Trace: [] [] Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 9d 5b 5e >>EIP; c0178397<= Trace; c0107007 Trace; c0108cec Code; c0178397 <_EIP>: Code; c0178397<= 0: 8b 41 10 mov0x10(%ecx),%eax <= Code; c017839a 3: 8b 40 30 mov0x30(%eax),%eax Code; c017839d 6: 52push %edx Code; c017839e 7: 56push %esi Code; c017839f 8: 51push %ecx Code; c01783a0 9: 8b 00 mov(%eax),%eax Code; c01783a2 b: ff d0 call *%eax Code; c01783a4 d: 83 c4 0c add$0xc,%esp Code; c01783a7 10: 53push %ebx Code; c01783a8 11: 9dpopf Code; c01783a9 12: 5bpop%ebx Code; c01783aa 13: 5epop%esi - To unsubscribe from this list: send 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: TODO list for new VM (oct 2000)
On Mon, 2 Oct 2000, Linus Torvalds wrote: > Why do you apparently ignore the fact that page-out write-back > performance is horribly crappy because it always starts out > doing synchronous writes? Because it is fixed in the patch I mailed yesterday? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TODO list for new VM (oct 2000)
Why do you apparently ignore the fact that page-out write-back performance is horribly crappy because it always starts out doing synchronous writes? I pointed out previously in a private email that page_launder() must be buggy as it stands now, you seem to have ignored that part (and the test-program that shows 1MB/s writeout speeds due to it) completely. The whole _point_ of the new VM was performance. Without that, the new VM is pointless, and discussing TODO features is equally pointless. 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/
Oops at bootup with 2.4.0-test9-pre8
--test9-pre8 blows up at boot, somewhere around the ALI5X3 init. Here's the oops, with ksymoops decode. Copied by hand, hope it's correct: ALI5X3: IDE controller on PCI buss 00 dev 78 ALI5X3: chipset revision 193 ALI5X3: bad irq (0): will probe later Unable to handle kernel paging request at virtual address 0010 printing eip c0178539 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010002 eax: ebx: 0002 ecx: edx: c133df3f esi: 005e edi: cbfec400 ebp: esp: c133def8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 2, stackpage=c133d000) Stack: c133df3f c020db96 005e c133df3f cbfec400 004b 004a cbfec400 004b c133df3f 01f0 c0258200 03f4 0246 4a0001f0 c020e6fe c0258200 c0214844 cbfec400 c024ccbc 8e00 Call Trace: [] [] Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 0d 5b 5e ksymoops 2.3.4 on i586 2.4.0-test9pre7. Options used -v ./vmlinux (specified) -K (specified) -L (specified) -O (specified) -m ./System.map (specified) Unable to handle kernel paging request at virtual address 0010 c0178539 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: ebx: 0002 ecx: edx: c133df3f esi: 005e edi: cbfec400 ebp: esp: c133def8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 2, stackpage=c133d000) Stack: c133df3f c020db96 005e c133df3f cbfec400 004b 004a cbfec400 004b c133df3f 01f0 c0258200 03f4 0246 4a0001f0 c020e6fe c0258200 c0214844 cbfec400 c024ccbc 8e00 Call Trace: [] [] Code: 8b 41 10 8b 40 30 52 56 51 8b 00 ff d0 83 c4 0c 53 0d 5b 5e >>EIP; c0178397<= Trace; c0107007 Trace; c0108cec Code; c0178397 <_EIP>: Code; c0178397<= 0: 8b 41 10 mov0x10(%ecx),%eax <= Code; c017839a 3: 8b 40 30 mov0x30(%eax),%eax Code; c017839d 6: 52push %edx Code; c017839e 7: 56push %esi Code; c017839f 8: 51push %ecx Code; c01783a0 9: 8b 00 mov(%eax),%eax Code; c01783a2 b: ff d0 call *%eax Code; c01783a4 d: 83 c4 0c add$0xc,%esp Code; c01783a7 10: 53push %ebx Code; c01783a8 11: 0d 5b 5e 00 00or $0x5e5b,%eax /proc/pci : PCI devices found: Bus 0, device 0, function 0: Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 4). Master Capable. Latency=64. Non-prefetchable 32 bit memory at 0xd800 [0xdfff]. Bus 0, device 1, function 0: PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 4). Master Capable. Latency=64. Min Gnt=8. Bus 0, device 3, function 0: Bridge: Acer Laboratories Inc. [ALi] M7101 PMU (rev 0). Bus 0, device 7, function 0: ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] (rev 195). Bus 0, device 10, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] (rev 17). IRQ 12. Master Capable. Latency=24. I/O at 0xb800 [0xb87f]. Non-prefetchable 32 bit memory at 0xd680 [0xd680007f]. Bus 0, device 15, function 0: IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev 193). Master Capable. Latency=32. Min Gnt=2.Max Lat=4. I/O at 0xb400 [0xb40f]. Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc Rage 128 RF (rev 0). IRQ 11. Master Capable. Latency=64. Min Gnt=8. Prefetchable 32 bit memory at 0xe400 [0xe7ff]. I/O at 0xd800 [0xd8ff]. Non-prefetchable 32 bit memory at 0xd780 [0xd7803fff]. /proc/cpuinfo : processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 9 model name : AMD-K6(tm) 3D+ Processor stepping: 1 cpu MHz : 449.000148 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow bogomips: 894.57 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
TODO list for new VM (oct 2000)
[MM TODO list, updated for october 2000] --- Here is the TODO list for the new VM. The only thing really needed for 2.4 is the OOM handler and a fix for the highmem deadlock. The page->mapping->flush() callback is really wanted by the journaling filesystem folks. The rest are mostly extra's that would be nice; these things won't be pushed for inclusion except if it turns out to be really trivial to implement, high performance on the cases they're supposed to affect and their influence is highly localised... (sorry folks, but for 2.4 I'll be really conservative) ---> TODO list for the new VM <--- for kernel 2.4, necessary: - out of memory handling [integrate the OOM killer, 10 minutes work] - fix the highmem deadlock, where the swapper cannot create low memory bounce buffers OR swap out low memory because it has consumed all resources [old bug, already reported with 2.4.0-test6, probably before] for kernel 2.4, really wanted: - page->mapping->flush() callback in page_launder(), for easier integration with journaling filesystems and maybe the network filesystems [about 30 minutes of work on the VM side] for kernel 2.4, wanted: - maybe rebalance the swapper a bit ... we do page aging now so maybe refill_inactive_scan() / shm_swap() and swap_out() need to be rebalanced a bit for kernel 2.5:(maybe available as patch for 2.4 ???) - physical->virtual reverse mapping, so we can do much better page aging with less CPU usage spikes - better IO clustering for swap (and filesystem) IO - move all the global VM variables, lists, etc. into the pgdat struct for better NUMA scalability - (maybe) some QoS things, as far as they are major improvements with minor intrusion - thrashing control, maybe process suspension with some forced swapping ? - include Ben LaHaise's code, which moves readahead to the VMA level, this way we can do streaming swap IO, complete with drop_behind() regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre8 on SPARC build failure
This PCI stuff was discussed before... pcic.c: At top level: pcic.c:39: redefinition of `pcibios_present' /usr/src/linux-2.4.0-test/include/linux/pci.h:562: `pcibios_present' previously defined here make[1]: *** [pcic.o] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.0-test/arch/sparc/kernel' make: *** [_dir_arch/sparc/kernel] Error 2 -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
On 2 Oct 2000, Christoph Rohland wrote: > the shm swapping still kills the machine(8GB mem) the machine > with somthing like '__alloc_pages failed order 0'. > > When I do the same stresstest with mmaped file in ext2 the > machine runs fine but the processes do not do anything and > vmstat/ps lock up on these processes. This may be a highmem bounce-buffer creation deadlock. Do your tests work if you use only 800 MB of RAM ? Shared memory swapping on my 64 MB test machine seems to work fine (albeit a bit slow). regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: iounmap() - can't always unmap memory I've mappedt
** Reply to message from Alan Cox <[EMAIL PROTECTED]> on Mon, 2 Oct 2000 17:18:59 +0100 (BST) > > Anyway, my original question has not yet been answered: why is it that I can > > ioremap() any physical page by simply setting one bit, but I cannot always > > iounmap() it? Why can't iounmap() simply undo what ioremap() did? > > The fact you can doesn't mean you should. You need to be sole owner of that > page before you can fiddle with the reserved bit. You were not sole owner Ok, is there a way around this? After all, mapping a page I don't own doesn't really mean anything in the kernel, because all pages, whether or not I own them, are already mapped! phys_to_virt works on any physical address. What I want to do is use iounmap_nocache() to access the memory in an uncached manner, and that's what I do. Would it be possible to reassign the ioremap()'d memory to some other physical page that I _do_ own, and then call iounmap? I have no problem doing all of this stuff in Windows 2000, so I'm surprised that it's so difficult in Linux. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Meaning of blk_size
Andries Brouwer wrote: > On Mon, Oct 02, 2000 at 02:33:20AM +0200, Daniel Phillips wrote: > > On Mon, 02 Oct 2000, Andries Brouwer wrote: > > > > [you sounded as if you noticed a discrepancy somewhere - so I expected: > > > foo.c uses this in line 123 but bar.c uses that in line 666.] > > > > No, I'm just trying to understand the meaning of the "+ 1" in ll_rw_block.c, > > generic_make_request: > > > > unsigned long maxsector = (blk_size[major][MINOR(bh->b_rdev)] << 1) + 1; > > blk_size[][] gives a block count > blk_size[][]<<1 gives a sector count > > but if the device had an odd number of sectors, the sector count > is one larger than twice the block count. > > (thus, this is not the precisely correct test; the knowledge about > the number of sectors lives in the dev->sizes array; here we only > have a rough check) OK, it's a discrepancy. This is the test used in generic_make_request. Devices with 512 byte blocks will be able to access one sector past the blk_size. I wasn't expecting that and that's why I was so confused by it. The deep problem is the size should be expressed in units of dev_block_size, not bogosectors. *** pauses for a moment and wonders what a nice filesystem developer is doing in a place like this I have no doubt I'm beating on a horse that has been beaten on many times in the past. I'll suggest the obvious: there should be a device table, dev_block_bits[MAX_BLKDEV], initialized by default to 9's. Then at our leisure we can change over the drivers one by one to use the real device block size instead of bogosectors and finally kill that ugly duck. The new improved code will be more efficient because it will get rid of a lot of multiply/divides by 512. Some device size limitations will go away. It will certainly be easier to read. One more question that has probably been asked a lot: why are the various fields of a device splatted across half a dozen tables instead of being collected together in a struct and accessed through one table? Now I'll get out of here and go back to my filesystem. I was checking the wrong thing in my valid_block function anyway, I should have been checking against the blocks count in the superblock: #define valid_block(sb, i) \ (i < sb->u.ext2_sb.s_blocks_per_group * sb->u.ext2_sb.s_groups_count) -- Daniel - To unsubscribe from this list: send 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: test9-pre7 doesn't recognize HiSax ISDN card
On Mon, Oct 02, 2000 at 12:08:10AM +0200, Pierfrancesco Caci wrote: > > The subject tells everything: > ... > > 28x481 23:49:14 penny kernel: fb0: MATROX VGA frame buffer device > Oct 1 23:49:14 penny kernel: pty: 512 Unix98 ptys configured > Oct 1 23:49:14 penny kernel: ISDN subsystem Rev: 1.111/1.93/1.135/1.77/1.21/1.5 > Oct 1 23:49:14 penny kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31 > > Is there something that is changed and that I should know ? > Nothing so far I know, seems HiSax was not selected or compiled as module. -- Karsten Keil SuSE Labs ISDN 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: PROBLEM: 2.2.17 hangs when attempting to mount atapi cdrom Teac CD-540E
On Mon, Oct 02 2000, Serge Gavrilov wrote: > [1.] 2.2.17 hangs when attempting to mount atapi cdrom Teac CD-540E > > [2.] My kernel was compiled with flags > > CONFIG_BLK_DEV_IDEPCI=y > CONFIG_BLK_DEV_IDEDMA=y > CONFIG_IDEDMA_AUTO=y > > My cdrom Teac CD-540E supports UDMA mode2. > When I try to mount /cdrom kernel hangs. > If I invoke > > hdparm -d0 /dev/hdc > > and invoke "mount /cdrom" after, then everything is OK. What IDE chipset? Note that not all of them support DMA with ATAPI at the moment. And also note that even if your CD-ROM claims to support UDMA, it doesn't necessarily mean that it does in reality... -- * 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/
buffer_head.b_blocknr is unsigned long, not int
Throughout linux/fs/buffer.c, the struct buffer_head member b_blocknr has integer values put into it, while it's defined to be an unsigned long in fs.h. For architectures where sizeof(int) != sizeof(long), calls to bread() could potentially do the wrong thing if the disk has more than 2^41 blocks (2 TB or more, depending on block size). Before hunting down all the places where b_blocknr gets an integer put in it, and making a patch, I thought I'd ask first if there's a good reason why it's done this way. In a few places, values such as -1 and -1000 are put there as dummy values, so don't hurt anything. Are there other reasons? Thanks, Matt Domsch Dell Enterprise Systems Group Linux Development Team - To unsubscribe from this list: send 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: problems with 2.4.0-test8
On Mon, 2 Oct 2000, Petko Manolov wrote: > Richard Polton wrote: > > I am using 2.4.0-test8 on an i686 laptop. I find that netscape-4.72 > > keeps locking up. I am not able to kill the process at all (without > > a reboot, and SysRQ cannot do a sync on the partition it is running > > in either). I have been advised that RvR's memory patches will fix > > this but I have yet to try. (This behaviour also can be seen with > > ppp-2.4.0, which is a trifle irritating 8-) > > I have the same kind of problems with 2.4.0-test8, test-9-pre[678]. > > I'd thought it is due to bug in my (usb pegasus) driver which i used > most of the time. But i got the same crash with eepro100 which is > considered to be fairly solid. > > The bug appears when netscape tries to switch the windows or open new > one. I'm afraid the newest RvR's MM code is not so stable. You may want to try my latest patch ;) I have known about these problems for about 2 weeks, but was away at conferences so couldn't create a clean enough patch to send to Linus ;( http://www.surriel.com/patches/ regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17 crashing like mad on me - oops included
Hello, I've subscribed to the list for quite a while, and I sincerely hope this is the correct place to report this particular problem. If not, I apologize and ask that someone point me in the correct direction. Since I would rather include too much information than too little, I'll include a brief description of the hardware, the distro, and the problem, followed by a printout of the oops. The machine: SMP dual PII/400 Supermicro P6DBU 256MB PC-100 in 4 sticks of 64MB ea. Adaptec 2940UW TNT2 Ultra 32MB AGP (2) Intel PRO/100 PCI NICs PCI es1370 sound LinTV card (bttv) 300w Antec PSU APC 500 PS backup Mandrake 7.1, expert install, chose everything, and went with ReiserFS (love those speedy boots). This box ran very well for weeks. The box itself is hand-built, and has run well for a year or so under various Linux distros. When 2.2.17 was released, I immediately went and pulled the 2.2.17 kernel, and the 3.5.24 reiserfs patch. Patched, config'd, built. Started having terrible lockups. Closing Netscape would do it almost every time. I removed all Netscape from the machine. Mozilla (latest nightly) would crash it on opening up a child window. I started having massive corruption of data streams. For instance, when opening up *.tar.gz files, or checking RAR archives, etc. md5 would come up with inconsistent results (!). Files corrupted (but only ones that had been "touched"/manipulated. Samba would happily take down the machine. All of these are hard locks, requiring manual reboots. Rebuilt the kernel several times. Pulled fresh source, fresh patch (now at 3.5.26), reapplied, copied old .config over and did 'make oldconfig', and on others just simply redid the config from scratch. All of these in just about every way there is to arrange 9 books on a shelf. Chose modules, chose built-in, on and on ad nauseum. I surely did not want to post to this list without at least doing my homework. I have other mission-critical boxen that I have held off of the 2.2.17 upgrade until I'm comfortable that this is just a problem specific to this machine or my stupidity. This is the only SMP box I have, the others are UP. The following was taken from my /var/messages log. I appreciate any/all feedback, because this is just quite simply driving me crazy. Most un-Linuxish behavior. :( >Oct 2 11:22:58 omega kernel: <3>kmem_free: Bad obj addr (objp=ccc58280, >name=size-32) >Oct 2 11:22:58 omega kernel: <1>Unable to handle kernel NULL pointer dereference at >virtual address >Oct 2 11:22:58 omega kernel: <1>current->tss.cr3 = 0f533000, %%cr3 = 0f533000 >Oct 2 11:22:58 omega kernel: <1>*pde = >Oct 2 11:22:58 omega kernel: <4>Oops: 0002 >Oct 2 11:22:58 omega kernel: <4>CPU:1 >Oct 2 11:22:58 omega kernel: <4>EIP:0010:[kfree+410/460] >Oct 2 11:22:58 omega kernel: <4>EFLAGS: 00010202 >Oct 2 11:22:58 omega kernel: <4>eax: 0039 ebx: c080 ecx: 004a edx: >0002 >Oct 2 11:22:58 omega kernel: <4>esi: ccc58280 edi: 0202 ebp: esp: >ca955ecc >Oct 2 11:22:58 omega kernel: <4>ds: 0018 es: 0018 ss: 0018 >Oct 2 11:22:58 omega kernel: <4>Process smbd (pid: 624, process nr: 31, >stackpage=ca955000) >Oct 2 11:22:58 omega kernel: <4>Stack: ccd58b00 ca682860 a54eebaa >0011 cc29b404 ca955f68 >Oct 2 11:22:58 omega kernel: <4> 0040 c0136071 ccc58280 ca682860 ca71001a > ccd58b00 ca58c8a0 >Oct 2 11:22:58 omega kernel: <4> fffe ca71 08124d60 b75c > ca8e4e40 ca955f78 >Oct 2 11:22:58 omega kernel: <4>Call Trace: [prune_dcache+229/312] >[shrink_dcache_parent+23/48] [lookup_dentry+365/504] [vfs_rmdir+254/308] >[sys_rmdir+201/320] [common_interrupt+24/32] [system_call+52/64] >Oct 2 11:22:58 omega kernel: <4> [stext+43/164] >Oct 2 11:22:59 omega kernel: <4>Code: c7 05 00 00 00 00 00 00 00 00 eb 1d 89 f6 83 >c4 f8 56 68 82 -- Brad Felmey - To unsubscribe from this list: send 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: Soft-Updates for Linux ?
Albert Cahalan write: > Robert Redelmeier writes: > > Daniel Phillips wrote in part: > > >> One thing to keep in mind in all of this is: nobody is testing the > >> reliability of their journalling or any other kind of filesystem just by > >> running it. To test these things you have to crash/interrupt the system > >> *a lot*. Otherwise, you are just fooling yourself and everybody else. > >> How many crashes does it take to find that one little window of > >> vulnerability that comes up every 10,000 crashes normally but suddenly > >> starts coming up every time just because your customer uses their system > >> a different way? You're doing the right thing by crash-testing it, now > >> instead of doing it 5 times do it 1,000 times. Here's one of my > >> favorite tests: unzip a kernel source tree and wait until the disk light > >> goes out. A second or so after it comes on again (kflushd) hit the > >> reset button. > > > > Good idea. I certainly believe in stressing hardware (see .sig), > > but I'm not sure this test is rigorous enough. The problem is > > the reset button is only connected to the CPU and the hard disk > > will probably continue to write out sectors from it's hw buffer. > > OTOH, I don't like the idea of pulling the plug too often. It's > > very hard on the hardware. I'd expect a mechanical disk failure > > before 10,000 cycles. > > The nice way to develop this code is with a block device that > discards all writes after a timer goes off. I made a patch to the loopback device which allows you to discard I/Os going to disk. You can either activate it via an ioctl from user space, or via a function call in the kernel. You can also make reads fail, but this was not very useful for me, because it caused the ASSERTs in ext3 to oops. Also the read "failures" are not the same as the real thing, so it may not be a valid test. They only return a zero'd page, rather than really causing a non-up-to-date page. I used it quite a bit when developing the orphan code for ext3, and for testing journal integration in InterMezzo. You can use it for testing a loopback file, or loopback mount a block device, but as with regular loopback devices, there is a 2GB limit. I posted it to fsdevel a few months ago, but I have also uploaded it to: ftp://ftp.stelias.com/pub/adilger/loopdiscard-2.2.16.patch ftp://ftp.stelias.com/pub/adilger/loop_discard.c The loop_discard.c program simply calls the ioctl to enable or disable I/O on the specific loop device. Unconfiguring the loop device also resets the I/O status. 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: test9-pre8 doesn't compile Reiserfs-3.6.17
On 2000-10-02 Claudius Link wrote: >With me that was a simple makefile problem >linux/fs/Makefile >changed quit a bit. So you have to add the line > subdir-$(CONFIG_REISERFS_FS)+= reiserfs >somewhere (for example after "subdir-$(CONFIG_JFFS_FS) += jffs") >then it works fine. Right, thanks. Here is a tested little patchlet: diff -u linux/fs/Makefile.orig linux/fs/Makefile --- linux/fs/Makefile.orig Mon Oct 2 10:27:34 2000 +++ linux/fs/Makefile Mon Oct 2 09:59:03 2000 @@ -60,6 +60,7 @@ subdir-$(CONFIG_ADFS_FS) += adfs subdir-$(CONFIG_DEVPTS_FS) += devpts subdir-$(CONFIG_SUN_OPENPROMFS)+= openpromfs +subdir-$(CONFIG_REISERFS_FS) += reiserfs obj-$(CONFIG_BINFMT_AOUT) += binfmt_aout.o With kind regards, Steven Cole - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix for VM test9-pre7
Hi Rik, the shm swapping still kills the machine(8GB mem) the machine with somthing like '__alloc_pages failed order 0'. When I do the same stresstest with mmaped file in ext2 the machine runs fine but the processes do not do anything and vmstat/ps lock up on these processes. Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
