Re: scsi vs ide performance on fsync's
On Mon, 5 Mar 2001, Linus Torvalds wrote: > Well, it's fairly hard for the kernel to do much about that - it's almost > certainly just IDE doing write buffering on the disk itself. No OS > involved. I am pushing for WC to be defaulted in the off state, but as you know I have a bigger fight than caching on my hands... > I don't know if there is any way to turn of a write buffer on an IDE disk. You want a forced set of commands to kill caching at init? Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
On Tue, 6 Mar 2001, Jonathan Morton wrote: > It's pretty clear that the IDE drive(r) is *not* waiting for the physical > write to take place before returning control to the user program, whereas > the SCSI drive(r) is. Both devices appear to be performing the write Wrong, IDE does not unplug thus the request is almost, I hate to admit it SYNC and not ASYNC :-( Thus if the drive acks that it has the data then the driver lets go. > immediately, however (judging from the device activity lights). Whether > this is the correct behaviour or not, I leave up to you kernel hackers... Seagate has a better seek profile than ibm. The second access is correct because the first one pushed the heads to the pre-seek. Thus the question is were is the drive leaving the heads when not active? It does not appear to be in the zone 1 region. > IMHO, if an application needs performance, it shouldn't be syncing disks > after every write. Syncing means, in my book, "wait for the data to be > committed to physical media" - note the *wait* involved there - so syncing > should only be used where data integrity in the event of a system failure > has a much higher importance than performance. I have only gotten the drive makers in the past 6 months to committee to actively updating the contents of the identify page to reflect reality. Thus if your drive is one of those that does a stress test check that goes: "this bozo did not really mean to turn off write caching, renabling " Cheers, Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
>I don't know if there is any way to turn of a write buffer on an IDE disk. hdparm has an option of this nature, but it makes no difference (as I reported). It's worth noting that even turning off UDMA to the disk on my machine doesn't help the situation - although it does slow things down a little, it's not "slow enough" to indicate that the drive is behaving properly. Might be worth running the test on some of my other machines, with their diverse collection of IDE controllers (mostly non-UDMA) and disks. >Of course, whether you should even trust the harddisk is another question. I think this result in itself would lead me *not* to trust the hard disk, especially an IDE one. Has anybody tried running this test with a recent IBM DeskStar - one of the ones that is the same mech as the equivalent UltraStar but with IDE controller? I only have SCSI and laptop IBMs here - all my desktop IDE drives are Seagate. However I do have one SCSI Seagate, which might be worth firing up for the occasion... -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 ext2 filesystem corruption ? (was 2.4.2: What happened ? (No such file or directory))
Maybe I should give details about my hardware. The system was
installed 5 months ago, and this is the first problem.
I used 2.2.16 stock Kernel from Slackware 7.1
2.2.17
2.2.18
2.4.0
2.4.1
And the only problem was with 2.4.2.
FYI, I'm not using hdparm or changing the BIOS to use UDMA 66.
It'd fail with 2.4.1 and 2.4.2 (CRC errors), so the setting
is AUTO and it's using UDMA 33.
And please note that this machine is fine, but I actually only
open 2 consoles and run GNU screen. No XFree86, and only a few
applications running.
If needed, my /var/log/dmesg is at
http://members.nbci.com/pervalidus/dmesg-2.4.2.txt
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 ext2 filesystem corruption ? (was 2.4.2: What happened ? (No such file or directory))
For what it's worth, I was able to completely screw up my root FS using redhat's Fisher beta kernel (2.2.18 + stuff). I did this by running a bad hdparm command while running a full GNOME desktop: (This was not a good idea...and I know, and knew that...but) hdparm -X34 -d1 -u1 /dev/hda (As found here: http://www.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html?page=2 HD is a 40GB 7200 RPM Western Digital drive. (ATA-100 I believe) that I just got from Fry's a few days ago... fdisk was sort of able to recover most of the file system by booting off of the CD in rescue mode and running fsck on /dev/hda, but many files were not what they said they were, ie /sbin/ifup was some other binary... Some files turned into directories it seems Sorry for the lame bug report, but I'm scared to try it again, and I didn't realize the complexity of the problem when I simply powered down my machine with the HD light on solid... Thanks, Ben -- Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com Author of ScryMUD: scry.wanfear.com (Released under GPL) http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loop stuck in -D state
On Mon, 5 Mar 2001, Richard B. Johnson wrote: > On Mon, 5 Mar 2001, Mike Galbraith wrote: > > > Are you saying that the initrd is broken again as well? (having > > trouble understanding the problem.. don't see why you need the > > loop device or rather how its being busted is connected to your > > [interpolation] difficulty in creating a new initrd) > > > > -EAGAIN ;-) > > > > The initial RAM disk image is created using the loop device. You > can create a RAM disk image for initrd by using the ram device. > However, that doesn't work once the system has been booted off > it (try it, be ready for a complete hang). That's news to me. My test images were created without using the loop device, and my box boots just fine. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
> From: "David S. Miller" <[EMAIL PROTECTED]> > Date: Mon, 5 Mar 2001 20:53:21 -0800 (PST) >[...] > Gerard Roudier wrote for the sym53c8xx driver the exact thing > UHCI/OHCI need for this. Thanks for the hint. *** Anyways, is this the end of the discussion regarding my patch? If it goes in, then fine. If not, fine too... Just let me know so that I can close the bug properly. Manfred said plainly "usb-uhci is broken", Alan kinda manuevered around my small problem, Dave Brownell looks unconvinced. So? -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
On Tue, 6 Mar 2001, Douglas Gilbert wrote: > > > On the other hand, it's also entirely possible that IDE is just a lot > > better than what the SCSI-bigots tend to claim. It's not all that > > surprising, considering that the PC industry has pushed untold billions of > > dollars into improving IDE, with SCSI as nary a consideration. The above > > may just simply be the Truth, with a capital T. > > What exactly do you think fsync() and fdatasync() should > do? If they need to wait for dirty buffers to get flushed > to the disk oxide then multiple reported IDE results to > this thread are defying physics. Well, it's fairly hard for the kernel to do much about that - it's almost certainly just IDE doing write buffering on the disk itself. No OS involved. The kernel VFS and controller layers certainly wait for the disk to tell us that the data has been written, there's no question about that. But it's also not at all unlikely that the disk itself just lies. I don't know if there is any way to turn of a write buffer on an IDE disk. I do remember that there were some reports of filesystem corruption with some version of Windows that turned off the machine at shutdown (using software power-off as supported by most modern motherboards), and shut down so fast that the drives had not actually written out all data. Whether the reports were true or not I do not know, but I think we can take for granted that write buffers exist. Now, if you really care about your data integrity with a write-buffering disk, I suspect that you'd better have an UPS. At which point write buffering is a valid optimization, as long as you trust the harddisk itself not to crash even if the OS were to crash. Of course, whether you should even trust the harddisk is another question. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Possible Bug? 2.2.18
running 2.2.18 on a AMD486DX4 - 120 with 34Mb Ram running RH6.2 I obtained
these errors while trying to copy files from a burnt CD.
Mar 6 10:13:33 lefty kernel: hdb: command error: status=0x51 { DriveReady
SeekComplete Error }
Mar 6 10:13:33 lefty kernel: hdb: command error: error=0x54
Mar 6 10:13:33 lefty kernel: end_request: I/O error, dev 03:40 (hdb),
sector 140520
Mar 6 10:13:33 lefty kernel: ATAPI device hdb:
Mar 6 10:13:34 lefty kernel: Error: Illegal request -- (Sense key=0x05)
Mar 6 10:13:34 lefty kernel: Illegal mode for this track or incompatible
medium -- (asc=0x64, ascq=0x00)
Mar 6 10:40:57 lefty kernel: hdb: command error: status=0x51 { DriveReady
SeekComplete Error }
Mar 6 10:40:57 lefty kernel: hdb: command error: error=0x54
Mar 6 10:40:57 lefty kernel: ATAPI device hdb:
Mar 6 10:40:57 lefty kernel: Error: Illegal request -- (Sense key=0x05)
Mar 6 10:40:57 lefty kernel: Illegal mode for this track or incompatible
medium -- (asc=0x64, ascq=0x00)
The system locked hard with the drive light on, not accepting commands via
telnet. I plugged in a Keyboard and Monitor and line after line of:
hdb: Missed Interupt (As close as i can get via memory).
Holding Ctrl+Alt+SysRq responded in what looked like the screen switching
between a login screen and the afformentioned error messages.
Please cc replies to [EMAIL PROTECTED]
Adrian Levi.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Linus Torvalds wrote: > Well, it's entirely possible that the mid-level SCSI layer is doing > something horribly stupid. Well it's in good company as FreeBSD 4.2 on the same hardware returns the same result (including IDE timings that were too fast). My timepeg analysis showed that the SCSI disk was consuming the time, not any of the SCSI layers. > On the other hand, it's also entirely possible that IDE is just a lot > better than what the SCSI-bigots tend to claim. It's not all that > surprising, considering that the PC industry has pushed untold billions of > dollars into improving IDE, with SCSI as nary a consideration. The above > may just simply be the Truth, with a capital T. What exactly do you think fsync() and fdatasync() should do? If they need to wait for dirty buffers to get flushed to the disk oxide then multiple reported IDE results to this thread are defying physics. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2 ext2 filesystem corruption ? (was 2.4.2: What happened ? (No such file or directory))
Hi. After a reboot I had to manually run fsck (sulogin from
sysinit script) since there were failures.
In my second (and problematic) boot with 2.4.2 I used the
option mount --bind in my sysinit script to mount the old /dev
in /dev-old before devfs was mounted, so I could get rid of all
entries that were still there (I removed most before building a
Kernel with devfs support).
For some reason I couldn't remove /dev-old/hdd2. It reported
can't state file. Note that I never used /dev/hdd*, since I
only use hda and hdc, but am sure it was OK with 2.4.0 (mc
reported an error when I accessed /dev-old, what never happened
before), the last time I used a Kernel without devfs support.
If you read my old thread, you should notice various
applications couldn't access (or rename ?) files. It happened
after ~8h of idle time. It was OK at 5:58, when I last ran cvs
and killed pppd, but failed at ~14:30, when multilog (from
daemontools) had to do something to a full dnscache log file (I
was online).
I'm not sure 2.4.2 is the culprit. I just hope it's the last
time. There were no errors when I first booted with this Kernel
(I was using 2.4.1), and my first uptime was ~6 days (~23 with
2.4.1). Also there were no errors when I booted 2.4.2 for the
second time.
BTW, /lost+found contains hdd2:
brw-r-1 root disk 22, 66 May 8 1995 #518878
The other partitions (/home/ftp/pub and /usr/local/src) have no
problems.
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.4.3 and new aic7xxx
This is just to report on a the behavior of this driver. I've a dual channel Adaptec 7895 controller. The adapter BIOS is configured to boot from devices in channel B. I boot from a disk connected to channel B and when the kernel loads the driver the disks from channel A are seen first, resulting in the drive names changing from, say sda to sdb. This does not happen with 2.2.18 or 2.4.2. Is there an option to reverse the order? I saw some of the options in the code, but none about this. In any case, booting halts since the root file system can't be mounted. It didn't fry my disks, either :) -- Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() alignment
Alan Cox wrote: > > > > It might be worth asking the question if larger blocks are more > > > aligned? > > > > OK, I'll bite... > > Are larger blocks more aligned? > > Only get_free_page() > I wonder if it would be practical/reasonable to guarantee better alignment for larger allocations (at least for sizes that are powers of two); especially 8- and 16-byte alignment is sometimes necessary. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How-To for PPPoE in v2.4.x?
[EMAIL PROTECTED] wrote: > Is there a How-To for getting the Linux v2.4.x PPPoE support to work? > I've searched for info but have mostly found sketchy references on getting > PPPoE to work with the v2.2 kernel. > I have been using PPPoE in the 2.4.0 kernel for about 2 months now. It's very nice. I used http://www.math.uwaterloo.ca/~mostrows/ just grab the tarball and compile. I bet it will work under 2.4.2 also. > > My system is running RedHat v6.2 and the v2.4.2 Linux kernel. I've built > PPP and PPPoE support into the kernel and I've installed the v2.4.0 PPP > software. I've got the /dev/ppp created by the RedHat installation and I > see "pppoe" in the /proc/drivers list of drivers. > > I've got a (PCMCIA-based) NIC that I know works as a plain non-PPPoE > device under v2.4.x. > > So what do I do now? Do I have to patch pppd to utilize the kernel's > new PPPoE support? Do I have to create a /dev/pppoe devnode? > > While I have a lot of experience with Ethernet networking on Linux, I am a > total PPP (let alone PPPoE) newbie. Please be gentle. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
Russell King writes: > A while ago, I looked at what was required to convert the OHCI driver > to pci_alloc_consistent, and it turns out that the current interface is > highly sub-optimal. It looks good on the face of it, but it _really_ > does need sub-page allocations to make sense for USB. > > At the time, I didn't feel like creating a custom sub-allocator just > for USB, and since then I haven't had the inclination nor motivation > to go back to trying to get my USB mouse or iPAQ communicating via USB. > (I've not used this USB port for 3 years anyway). Gerard Roudier wrote for the sym53c8xx driver the exact thing UHCI/OHCI need for this. I think people are pissing their pants over the pci_alloc_consistent interface for no reason. It gives PAGE
Re: scsi vs ide performance on fsync's
On Tue, 6 Mar 2001, Jonathan Morton wrote: > > It's pretty clear that the IDE drive(r) is *not* waiting for the physical > write to take place before returning control to the user program, whereas > the SCSI drive(r) is. This would not be unexpected. IDE drives generally always do write buffering. I don't even know if you _can_ turn it off. So the drive claims to have written the data as soon as it has made the write buffer. It's definitely not the driver, but the actual drive. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Console driver and printing
Hi, I would like to know if know if there is any support for printing in the console driver. I mean, can the console receive from an application an mc4/mc5 sequence as defined in a terminfo entry and print what was sent in between? If so is there any way to configure the device to which the data would be sent? I hope I do not abuse this list by posting this question here, but I couldn't find any information anywhere else. If I can't print through the console, would anybody have any experience about configuring an xterm (which can print, I tested it) to use a cp437 (IBM) encoding? I've always managed to find everything myself, but I'm running short on time and this is the last problem before installing linux in 50 to 100 stores, so I could use a little help :-) Nicolas Cadou - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2-ac12
In article <[EMAIL PROTECTED]>, Scott M. Hoffman <[EMAIL PROTECTED]> wrote: > > It may not be related, but out of five boot attempts, only one got past >the IDE driver stage(ie, below from 2.4.2 : > VP_IDE: IDE controller on PCI bus 00 dev 39 > VP_IDE: chipset revision 16 > VP_IDE: not 100% native mode: will probe irqs later > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > VP_IDE: VIA vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1 > ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA > ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA) > > I've had 2.4.2 running great for the past 10 days. Need any more info? I'd love to hear anything you can come up with. What's the next step in your boot process, ie what's the part that normally shows up but doesn't with 2.4.2-ac12? Is this using IDE-SCSI, for example? One thing that both 2.4.3-pre3 and -ac12 do is to not have allocate a result buffer for TEST_UNIT_READY. I don't see why that should matter, but can you try un-doing the patch to "scsi_error.c" and see if that makes a difference. I'm worried about this report, and the buslogic corruption thing.. Justin: there's another "2.4.3-pre2 corrupts all disks on a buslogic controller" report. The interesting part is that 2.4.3-pre2 doesn't actually contain any buslogic changes. The only generic-scsi changes were yours. Ideas? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sk_buff in 2.4.0
In the patch by David S. Miller, copy_from_user() is still there (Line
14360 in zerocopy-2.4.0-1.diff). So which copy is reduced? Can anyone
explain kindly.
thanks
sourav
On Mon, 5 Mar 2001, Albert D. Cahalan wrote:
> > My question is: Is the state of the art same in 2.4.0, ie. is
> > protocol header and data still has to reside contiguously? Or header and
> > data may be non-contiguous and the driver does scatter/gather.
> >
> > I am starting off in 2.4.0 , plz. help.
>
> See the zero-copy patches by David S. Miller on ftp.kernel.org in
> his personal directory. If I remember right, the name of the
> directory is: /pub/linux/kernel/people/davem
>
> These patches are now in Alan Cox's patch sets. (the "ac" kernels)
n> You may find Alan Cox's stuff in his personal directory ("alan") at
> the same FTP site.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
bug report on Linux 2.4.0
I submit this report with two configurations: 2.4.0.4 has been running perfect while 2.4.0.5 caused compilation problems recorded in the report. Ko-Jen Shih Middletown, NJ ld -m elf_i386 -r -o sched.o sch_generic.o make[3]: Leaving directory `/root/linux-2.4.0/linux/net/sched' make[2]: Leaving directory `/root/linux-2.4.0/linux/net/sched' make -C unix make[2]: Entering directory `/root/linux-2.4.0/linux/net/unix' make all_targets make[3]: Entering directory `/root/linux-2.4.0/linux/net/unix' gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o af_unix.o af_unix.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o garbage.o garbage.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o sysctl_net_unix.o sysctl_net_unix.c rm -f unix.o ld -m elf_i386 -r -o unix.o af_unix.o garbage.o sysctl_net_unix.o make[3]: Leaving directory `/root/linux-2.4.0/linux/net/unix' make[2]: Leaving directory `/root/linux-2.4.0/linux/net/unix' make all_targets make[2]: Entering directory `/root/linux-2.4.0/linux/net' gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o socket.o socket.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-DEXPORT_SYMTAB -c netsyms.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o sysctl_net.o sysctl_net.c rm -f network.o ld -m elf_i386 -r -o network.o socket.o core/core.o ethernet/ethernet.o 802/802.o sched/sched.o ipv4/ipv4.o ipv4/netfilter/netfilter.o unix/unix.o netlink/netlink.o packet/packet.o netsyms.o sysctl_net.o make[2]: Leaving directory `/root/linux-2.4.0/linux/net' make[1]: Leaving directory `/root/linux-2.4.0/linux/net' make CFLAGS="-D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 " -C ipc make[1]: Entering directory `/root/linux-2.4.0/linux/ipc' make all_targets make[2]: Entering directory `/root/linux-2.4.0/linux/ipc' gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o util.o util.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o msg.o msg.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o sem.o sem.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o shm.o shm.c rm -f ipc.o ld -m elf_i386 -r -o ipc.o util.o msg.o sem.o shm.o make[2]: Leaving directory `/root/linux-2.4.0/linux/ipc' make[1]: Leaving directory `/root/linux-2.4.0/linux/ipc' make CFLAGS="-D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 " -C lib make[1]: Entering directory `/root/linux-2.4.0/linux/lib' make all_targets make[2]: Entering directory `/root/linux-2.4.0/linux/lib' gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o errno.o errno.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o ctype.o ctype.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o string.o string.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -m arch=i586-c -o vsprintf.o vsprintf.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -m arch=i586-c -o brlock.o brlock.c gcc -D__KERNEL__ -I/root/linux-2.4.0/linux/include -Wal
Re: Linux 2.4.3
In article <[EMAIL PROTECTED]>, Richard B. Johnson <[EMAIL PROTECTED]> wrote: > >I -- S T R O N G L Y -- suggest that nobody use this kernel with >a BusLogic SCSI controller until this problem is fixed. Ho humm.. Anybody who has any ideas or input, please holler. There are no actual BusLogic controller changes in the current 2.4.3-pre kernels at all, so there's something else going on. There's a new aic7xxx driver there - did you enable support for that? I wonder if there could be some inter-action: the aic7xxx driver tries to probe every PCI SCSI controller because they are basically hard to ID any other way (no single vendor/id combination, or even a simple pattern). But it has some rather careful internal logic to filter out all non-aic7xxx controllers, so this really doesn't look likely. If you didn't compile aic7xxx in, the only other SCSI change (apart from a lot of spelling fixes in comments etc) is some trivial error handling, like changing scsi_test_unit_ready to not have a result buffer (because it doesn't have a result except for the regular sense buffer). Which again certainly shouldn't be able to matter at all. Ideas? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2-ac12
On Mon, 5 Mar 2001, Richard B. Johnson wrote: > > Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results > in **MASSIVE** file-system destruction. I have (had) all SCSI > disks, using the BusLogic controller. > > There is something **MAJOR** going on BAD, BAD, BAD, even disks > that were not mounted got trashed. > > I -- S T R O N G L Y -- suggest that nobody use this kernel with > a BusLogic SCSI controller until this problem is fixed. > > This is being sent from another machine, not on the list (actually > from home where I am trying to see what happened -- I brought all > 4 of my disks home). It looks like some kind of a loop. I have > a pattern written throughout one of the disks. > > Cheers, > > Dick Johnson It may not be related, but out of five boot attempts, only one got past the IDE driver stage(ie, below from 2.4.2 : VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1 ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA) I've had 2.4.2 running great for the past 10 days. Need any more info? Scott Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
I've run the test on my own system and noted something interesting about
the results:
When the write() call extended the file (rather than just overwriting a
section of a file already long enough), the performance drop was seen, and
it was slower on SCSI than IDE - this is independent of whether IDE had
hardware write-caching on or off. Where the file already existed, from an
immediately-prior run of the same benchmark, both SCSI and IDE sped up to
the same, relatively fast speed.
These runs are for the following code, writing 2000 blocks of 4096 bytes each:
fd = open("tst.txt", O_WRONLY | O_CREAT, 0644);
for (k = 0; k < NUM_BLKS; ++k) {
write(fd, buff + (k * BLK_SIZE), BLK_SIZE);
fdatasync(fd);
}
close(fd);
IDE: Seagate Barracuda 7200rpm UDMA/66
first run: 1.98 elapsed
second and further runs:0.50 elapsed
SCSI: IBM UltraStar 1 rpm Ultra/160
first run: 23.57 elapsed
second and further runs:0.55 elapsed
If the test file is removed between runs, all show the longer timings.
HOWEVER if I modify the benchmark to use 2000 blocks of *20* bytes each,
the timings change.
IDE: Seagate Barracuda 7200rpm UDMA/66
first run: 1.46 elapsed
second and further runs:1.45 elapsed
SCSI: IBM UltraStar 1 rpm Ultra/160
first run: 18.30 elapsed
second and further runs:11.88 elapsed
Notice that the time for the second run of the SCSI drive is almost exactly
one-fifth of a minute, and remember that 2000 rotations / 1 rpm = 1/5
minute. IOW, the SCSI drive is performing *correctly* on the second run of
the benchmark. The poorer performance on the first run *could* be
attributed to writing metadata interleaved with the data writes. The
better performance on the second run of the first benchmark can easily be
attributed to the fact that the drive does not need to wait an entire
revolution before writing the next block of a file, if that block arrives
quickly enough (this is a Duron, so it darn well arrives quickly).
It's pretty clear that the IDE drive(r) is *not* waiting for the physical
write to take place before returning control to the user program, whereas
the SCSI drive(r) is. Both devices appear to be performing the write
immediately, however (judging from the device activity lights). Whether
this is the correct behaviour or not, I leave up to you kernel hackers...
IMHO, if an application needs performance, it shouldn't be syncing disks
after every write. Syncing means, in my book, "wait for the data to be
committed to physical media" - note the *wait* involved there - so syncing
should only be used where data integrity in the event of a system failure
has a much higher importance than performance.
--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-END GEEK CODE BLOCK-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: 3c509 2.4.2-ac12 compilation fails
Alan Cox wrote:
>
> > /me begins to download and merge ac12...
>
> It built for me too
Found it -- 3c509 bug of a different sort. You don't notice if
CONFIG_ISAPNP is a module... only if its built into the kernel. That
code is not conditional on CONFIG_ISAPNP_MODULE, only CONFIG_ISAPNP.
Attached are the compilation fixes -- should apply to 2.4.3-pre2 or
2.4.2-ac12 ok.
The patch does not address the larger issue of CONFIG_ISAPNP versus
CONFIG_ISAPNP_MODULE... That will have to be visited for several
drivers I think, and its not a 2-second obvious fix like the attached
patch (which needs to be applied anyway).
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
Index: drivers/net/3c509.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/3c509.c,v
retrieving revision 1.1.1.22.2.1
diff -u -r1.1.1.22.2.1 3c509.c
--- drivers/net/3c509.c 2001/03/05 00:39:14 1.1.1.22.2.1
+++ drivers/net/3c509.c 2001/03/06 03:05:53
@@ -327,7 +327,7 @@
irq = idev->irq_resource[0].start;
if (el3_debug > 3)
printk ("ISAPnP reports %s at i/o 0x%x, irq %d\n",
- el3_isapnp_adapters[i].name, ioaddr, irq);
+ (char*) el3_isapnp_adapters[i].driver_data,
+ioaddr, irq);
EL3WINDOW(0);
for (j = 0; j < 3; j++)
el3_isapnp_phys_addr[pnp_cards][j] =
Index: drivers/net/3c515.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/3c515.c,v
retrieving revision 1.1.1.22.2.1
diff -u -r1.1.1.22.2.1 3c515.c
--- drivers/net/3c515.c 2001/03/05 00:39:14 1.1.1.22.2.1
+++ drivers/net/3c515.c 2001/03/06 03:05:54
@@ -474,7 +474,7 @@
irq = idev->irq_resource[0].start;
if(corkscrew_debug)
printk ("ISAPNP reports %s at i/o 0x%x, irq %d\n",
- corkscrew_isapnp_adapters[i].name,ioaddr, irq);
+ (char*)
+corkscrew_isapnp_adapters[i].driver_data, ioaddr, irq);
if ((inw(ioaddr + 0x2002) & 0x1f0) != (ioaddr & 0x1f0))
continue;
Re: Linux 2.4.3
"Richard B. Johnson" wrote: > > Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results ... > I -- S T R O N G L Y -- suggest that nobody use this kernel with > a BusLogic SCSI controller until this problem is fixed. > > This is being sent from another machine, not on the list (actually > from home where I am trying to see what happened -- I brought all > 4 of my disks home). It looks like some kind of a loop. I have > a pattern written throughout one of the disks. > Have you been able to recover any kernel messages or oops? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel support for hot-plugging PCI adapters
Duane Grigsby wrote: > Any plans to add support or is there support in the 2.4 kernel for > hot-plugging a PCI adapter? It may be in the sources already, but I can't > seem to locate it. Any help would be appreciated. For devices, the support is already there. See Documentation/pci.txt. Look for 'probe', 'id_table', etc. I don't think there is support in the current tree for a controller that supports physical hotplugging of PCI adapters, yet. Compaq has a driver outside the tree to do such a thing (needing only very minor kernel patches), see http://opensource.compaq.com -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
On Tue, 6 Mar 2001, Alan Cox wrote: > > Yuck. Build-dependency on libdb-dev is not pretty. What is it used for, > > anyway? Assembler in need of libdb. Mind boggleth... > > Could it perhaps be persuaded to use Tridge's tdb, which at < 1000 lines could > simply be included with it... Alan, AFAICS they never remove entries, they only do adds and lookups by string key and they keep the whole thing in memory all the time. Oh, and they don't give it too hard use, to put it mildly. IOW, I'm pretty sure that even a LRU list will be sufficient. Hash definitely will be enough. Any *db is an overkill here - it's a symbol table, for fsck sake... Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.3
Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results in **MASSIVE** file-system destruction. I have (had) all SCSI disks, using the BusLogic controller. There is something **MAJOR** going on BAD, BAD, BAD, even disks that were not mounted got trashed. This is (was) a 400MHz SMP machine with 256 Mb of RAM. I don't know what else to say, since I have nothing to mount. I can "get back" but it will take several days. I have to install a minimum system then restore everything from tapes. I -- S T R O N G L Y -- suggest that nobody use this kernel with a BusLogic SCSI controller until this problem is fixed. This is being sent from another machine, not on the list (actually from home where I am trying to see what happened -- I brought all 4 of my disks home). It looks like some kind of a loop. I have a pattern written throughout one of the disks. Cheers, Dick Johnson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
On Mon, 5 Mar 2001, Jeremy Hansen wrote: > > Right now I'm running 2.4.2-ac11 on both machines and getting the same > results: > > SCSI: > > [root@orville /root]# time /root/xlog file.out fsync > > real0m21.266s > user0m0.000s > sys 0m0.310s > > IDE: > > [root@kahlbi /root]# time /root/xlog file.out fsync > > real0m8.928s > user0m0.000s > sys 0m6.700s > > This behavior has been noticed by others, so I'm hoping I'm not just crazy > or that my test is somehow flawed. > > We're using MySQL with Berkeley DB for transaction log support. It was > really confusing when a simple ide workstation was out performing our > Ultra160 raid array. Well, it's entirely possible that the mid-level SCSI layer is doing something horribly stupid. On the other hand, it's also entirely possible that IDE is just a lot better than what the SCSI-bigots tend to claim. It's not all that surprising, considering that the PC industry has pushed untold billions of dollars into improving IDE, with SCSI as nary a consideration. The above may just simply be the Truth, with a capital T. (And "bonnie" is not a very good benchmark. It's not exactly mirroring any real life access patterns. I would not be surprised if the SCSI driver performance has been tuned by bonnie alone, and maybe it just sucks at everything else) Maybe we should ask whether somebody like lnz is interested in seeing what SCSI does wrong here? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Mon, 5 Mar 2001, Robert Read wrote: > On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote: > > > > And what does POSIX say about "#!/bin/sh\r" ? > > In other words: should the kernel look for the interpreter between the ! > > and the newline, or [the first space or newline] or the first whitespace? > > > > IMHO, the first whitespace. Which means that "#!/bin/sh\r" should invoke > > /bin/sh. (though it is junk). > > > > The line terminator, '\n', is what terminates the interpreter. White > space (in this case, only ' ' and '\t') is used to seperate the > arguments to the interpreter. This allows scripts to pass args to > intepreters, as in #!/usr/bin/per -w or #!/usr/bin/env perl -w > > So is '\r' a line terminator? For Linux, no. Should '\r' seperate > arguments? No, that would be very strange. > For research, I suggest a look at getopt(3) or whatever it's called. The command line args are seperated into chunks based upon what got seperated into argv[1][n], delimited by (hold my breath) white-space. Of course, it's not getopt(), but "makeopt()" that we are looking for. ...Whatever chopped up those command-line arguments in the first place. If __that__ corresponds so POSIX rules, then whatever follows must also comply. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
> May be. But it's not a reason to use the _OBSOLETE_ library. At least the > current one should be used... > > Here comes the patch to use current libdb-3... Not all vendors ship db3. I'm not sure its a stunning improvement, but its the right first step. Will apply - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE trouble under 2.2.19pre16 with Hedrick's IDE patch
Shane Wegner wrote:
>
> Hi,
>
> Whenever I write a substantial amount of data (200mb) to
> disk, I get these messages. The disks lock for about 10
> seconds and then come back for about 10 seconds again.
> This continues until the data is successfully written.
>
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> hde: DMA disabled
It looks like you have set your drive for a dma mode it doesn't support.
HTH
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
On 2 Mar 2001, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Jeremy Hansen <[EMAIL PROTECTED]> wrote: > > > >The SCSI adapter on the raid array is an Adaptec 39160, the raid > >controller is a CMD-7040. Kernel 2.4.0 using XFS for the filesystem on > >the raid array, kernel 2.2.18 on ext2 on the IDE drive. The filesystem is > >not the problem, as I get almost the exact same results running this on > >ext2 on the raid array. > > Did you try a 2.4.x kernel on both? Finally got around to working on this. Right now I'm running 2.4.2-ac11 on both machines and getting the same results: SCSI: [root@orville /root]# time /root/xlog file.out fsync real0m21.266s user0m0.000s sys 0m0.310s IDE: [root@kahlbi /root]# time /root/xlog file.out fsync real0m8.928s user0m0.000s sys 0m6.700s This behavior has been noticed by others, so I'm hoping I'm not just crazy or that my test is somehow flawed. We're using MySQL with Berkeley DB for transaction log support. It was really confusing when a simple ide workstation was out performing our Ultra160 raid array. Thanks -jeremy > 2.4.0 has a bad elevator, which may show problems, so please check 2.4.2 > if the numbers change. Also, "fsync()" is very different indeed on 2.2.x > and 2.4.x, and I would not be 100% surprised if your IDE drive does > asynchronous write caching and your RAID does not... That would not show > up in bonnie. > > Also note how your bonnie file remove numbers for IDE seem to be much > better than for your RAID array, so it is not impossible that your RAID > unit just has a _huge_ setup overhead but good throughput, and that the > IDE numbers are better simply because your IDE setup is much lower > latency. Never mistake throughput for _speed_. > > Linus > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- this is my sig. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() alignment
> > It might be worth asking the question if larger blocks are more > > aligned? > > OK, I'll bite... > Are larger blocks more aligned? Only get_free_page() Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
On Tue, 6 Mar 2001, Alan Cox wrote:
> > On Mon, 5 Mar 2001, Alexander Viro wrote:
> >
> > New Adaptec driver does not build. It won't. People, can anyone
> enlighten me
> > why do we use a user space library for a kernel driver at all?
>
> aicasm is an assembler for the aic7xxx risc instruction code, not part
> of
> the driver
May be. But it's not a reason to use the _OBSOLETE_ library. At least the
current one should be used...
Here comes the patch to use current libdb-3...
=== Cut ===
diff -urN linux-2.4.2ac12.orig/drivers/scsi/aic7xxx/aicasm/Makefile
linux-2.4.2ac12/drivers/scsi/aic7xxx/aicasm/Makefile
--- linux-2.4.2ac12.orig/drivers/scsi/aic7xxx/aicasm/Makefile Mon Mar 5 18:05:06
2001
+++ linux-2.4.2ac12/drivers/scsi/aic7xxx/aicasm/MakefileMon Mar 5 18:06:46
+2001
@@ -8,7 +8,7 @@
SRCS= ${GENSRCS} ${CSRCS}
CLEANFILES= ${GENSRCS} ${GENHDRS} y.output
# Override default kernel CFLAGS. This is a userland app.
-AICASM_CFLAGS:= -I/usr/include -ldb1
+AICASM_CFLAGS:= -I/usr/include -ldb
YFLAGS= -d
NOMAN= noman
diff -urN linux-2.4.2ac12.orig/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c
linux-2.4.2ac12/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c
--- linux-2.4.2ac12.orig/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.cMon Mar 5
18:05:06 2001
+++ linux-2.4.2ac12/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c Mon Mar 5 18:06:32
+2001
@@ -36,7 +36,7 @@
#include
#ifdef __linux__
-#include
+#include
#else
#include
#endif
=== Cut ===
---
Sergey Kubushin Sr. Unix Administrator
CyberBills, Inc.Phone: 702-567-8857
874 American Pacific Dr,Fax:702-567-8808
Henderson, NV, 89014
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
> At the time, I didn't feel like creating a custom sub-allocator just > for USB, and since then I haven't had the inclination nor motivation > to go back to trying to get my USB mouse or iPAQ communicating via USB. > (I've not used this USB port for 3 years anyway). > > I'd be good to get it done "properly" at some point though. Something like struct pci_pool *pci_alloc_consistent_pool(int objectsize, int align) pci_alloc_pool_consistent(pool,.. pci_free_pool_consistent(pool,.. ?? Where the pool allocator does page grabbing and chaining > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
> Yuck. Build-dependency on libdb-dev is not pretty. What is it used for, > anyway? Assembler in need of libdb. Mind boggleth... Could it perhaps be persuaded to use Tridge's tdb, which at < 1000 lines could simply be included with it... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
> On Mon, 5 Mar 2001, Alexander Viro wrote: > > New Adaptec driver does not build. It won't. People, can anyone enlighten me > why do we use a user space library for a kernel driver at all? aicasm is an assembler for the aic7xxx risc instruction code, not part of the driver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: continous hard disk trashing and error messages - 2.4.2-ac5
> For the kernel 2.4.2 with the patch 2.4.2-ac5 patch, I have been getting continous
>hard disk trashing and the following errors in the /var/log/messages. I increased the
>console log level to avoid the messages. Please see below a sample set
> Mar 5 12:15:59 amitc-linux mount: mount: can't open /etc/mtab for writing:
>Input/output error
Well for once in a while I dont think this is going to be the kernel
> Mar 5 12:16:04 amitc-linux kernel: hda: read_intr: status=0x59 { DriveReady
>SeekComplete DataRequest Error }
> Mar 5 12:16:04 amitc-linux kernel: hda: read_intr: error=0x40 { UncorrectableError
>}, LBAsect=25133118, sector=3670215
uncorrectable error is a bad block on the disk. At least unless something very
odd is happening
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [jford@tusc.net: LUNA: Megaraid problems]
> Works great with kernel 2.2.16. Worked great up to kernel 2.3.99-test8 or > so. However under the current 2.4.x kernels (2.4.0, 2.4.1, 2.4.2) I get > the following message: Please test 2.4.2ac12. That has a much cleaned up megaraid.c 1.14g in it. I'd like feedback before handing it on to Linus. Im using it here on a kernel build disk with no problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to ymfpci from ALSA 0.99
> From: Alan Cox <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] (Peter Zaitcev)
> Date: Mon, 5 Mar 2001 20:46:32 -0500 (EST)
> > -static unsigned long int DspInst[] = {
> > +static unsigned long DspInst[YDSXG_DSPLENGTH / 4] = {
> > 0x0081, 0x01a4, 0x000a, 0x002f,
> > 0x00080253, 0x01800317, 0x407b, 0x843f,
>
> This seems wrong (actually I suspect its a continuation of wrongness. What
> about 64bit platforms - u32 maybe ?)
It will work on 64 bits, only use 2 times more memory for the storage.
Should be safe to change to int or u32.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to ymfpci from ALSA 0.99
> -static unsigned long int DspInst[] = {
> +static unsigned long DspInst[YDSXG_DSPLENGTH / 4] = {
> 0x0081, 0x01a4, 0x000a, 0x002f,
> 0x00080253, 0x01800317, 0x407b, 0x843f,
This seems wrong (actually I suspect its a continuation of wrongness. What
about 64bit platforms - u32 maybe ?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3c509 2.4.2-ac12 compilation fails
> /me begins to download and merge ac12... It built for me too - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel support for hot-plugging PCI adapters
Any plans to add support or is there support in the 2.4 kernel for hot-plugging a PCI adapter? It may be in the sources already, but I can't seem to locate it. Any help would be appreciated. Thanks, Duane Grigsby - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Looking for best resource for device driver programmers
[Steven Friedrich] > The questions I have are difficult to research because so little info > exists about 2.4 design philosophy. I guess the ORA "Linux Device Drivers" 2nd edition is due out Real Soon Now. It will cover 2.4. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How-To for PPPoE in v2.4.x?
Is there a How-To for getting the Linux v2.4.x PPPoE support to work? I've searched for info but have mostly found sketchy references on getting PPPoE to work with the v2.2 kernel. My system is running RedHat v6.2 and the v2.4.2 Linux kernel. I've built PPP and PPPoE support into the kernel and I've installed the v2.4.0 PPP software. I've got the /dev/ppp created by the RedHat installation and I see "pppoe" in the /proc/drivers list of drivers. I've got a (PCMCIA-based) NIC that I know works as a plain non-PPPoE device under v2.4.x. So what do I do now? Do I have to patch pppd to utilize the kernel's new PPPoE support? Do I have to create a /dev/pppoe devnode? While I have a lot of experience with Ethernet networking on Linux, I am a total PPP (let alone PPPoE) newbie. Please be gentle. :-) Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: continous hard disk trashing and error messages - 2.4.2-ac5
On Mon, 5 Mar 2001, Amit Chaudhary wrote:
> For the kernel 2.4.2 with the patch 2.4.2-ac5 patch, I have been getting continous
>hard disk trashing and the following errors in the /var/log/messages. I increased the
>console log level to avoid the messages. Please see below a sample set
> Mar 5 12:15:59 amitc-linux mount: mount: can't open /etc/mtab for writing:
>Input/output error
> Mar 5 12:16:04 amitc-linux kernel: hda: read_intr: status=0x59 { DriveReady
>SeekComplete DataRequest Error }
> Mar 5 12:16:04 amitc-linux kernel: hda: read_intr: error=0x40 { UncorrectableError
>}, LBAsect=25133118, sector=3670215
> Mar 5 12:16:04 amitc-linux kernel: end_request: I/O error, dev 03:06 (hda), sector
>3670215
> Mar 5 12:16:04 amitc-linux kernel: EXT2-fs error (device ide0(3,6)):
>ext2_write_inode: unable to read inode block - inode=230017, block=458776
hmmm. I had the same things from vanilla 2.4.2 on my laptop but luckily it
wiped out non essential stuff. I migrated back to 2.2.18.
I assumed it must be something stupid that I am doing but I have yet to
find it.
details - ext2fs main partition went awol. Had to manual fsck with much of
the above happening and lost+found filled up with stuff. anything else on
request. Still hoping its something stupid my end but doesn't appear to be
DMA stuf... I don't know.
have fun,
pub 1024D/A9D75E73 2000-05-30 Stephen Coast (SteveC) <[EMAIL PROTECTED]>
[expires:2001-05-30] www.fractalus.com/steve/ <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() alignment
On Mon, Mar 05, 2001 at 04:15:36PM -0800, H. Peter Anvin wrote: > > So, to summarise (for 32-bit CPUs): > > > > o Alan Cox & Manfred Spraul say 4-byte alignment is guaranteed. > > > > o If you need larger alignment, you need to alloc a larger space, > >round as necessary, and keep the original pointer for kfree() > > > > Maybe I'll just use get_free_pages, since it's a 64KB chunk that > > I need (and it's only a once-off). > > > > It might be worth asking the question if larger blocks are more > aligned? OK, I'll bite... Are larger blocks more aligned? Later, Kenn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch to ymfpci from ALSA 0.99
Hello:
the patch does not fix the buzzing, but it does not hurt either.
And the way we loaded the microcode before was seriously wrong.
Please look.
-- Pete
diff -ur -X dontdiff linux-2.4.2/drivers/sound/ymfpci.c
linux-2.4.2-p3/drivers/sound/ymfpci.c
--- linux-2.4.2/drivers/sound/ymfpci.c Fri Feb 16 16:02:37 2001
+++ linux-2.4.2-p3/drivers/sound/ymfpci.c Mon Feb 26 23:56:53 2001
@@ -2185,8 +2149,8 @@
ymfpci_writew(codec, YDSXGR_GLOBALCTRL, ctrl & ~0x0007);
/* setup DSP instruction code */
- for (i = 0; i < YDSXG_DSPLENGTH; i++)
- ymfpci_writel(codec, YDSXGR_DSPINSTRAM + i, DspInst[i >> 2]);
+ for (i = 0; i < YDSXG_DSPLENGTH / 4; i++)
+ ymfpci_writel(codec, YDSXGR_DSPINSTRAM + (i << 2), DspInst[i]);
switch (codec->pci->device) {
case PCI_DEVICE_ID_YAMAHA_724F:
@@ -2201,11 +2165,11 @@
if (ver_1e) {
/* setup control instruction code */
- for (i = 0; i < YDSXG_CTRLLENGTH; i++)
- ymfpci_writel(codec, YDSXGR_CTRLINSTRAM + i, CntrlInst1E[i >>
2]);
+ for (i = 0; i < YDSXG_CTRLLENGTH / 4; i++)
+ ymfpci_writel(codec, YDSXGR_CTRLINSTRAM + (i << 2),
+CntrlInst1E[i]);
} else {
- for (i = 0; i < YDSXG_CTRLLENGTH; i++)
- ymfpci_writel(codec, YDSXGR_CTRLINSTRAM + i, CntrlInst[i >>
2]);
+ for (i = 0; i < YDSXG_CTRLLENGTH / 4; i++)
+ ymfpci_writel(codec, YDSXGR_CTRLINSTRAM + (i << 2),
+CntrlInst[i]);
}
ymfpci_enable_dsp(codec);
diff -ur -X dontdiff linux-2.4.2/drivers/sound/ymfpci_image.h
linux-2.4.2-p3/drivers/sound/ymfpci_image.h
--- linux-2.4.2/drivers/sound/ymfpci_image.hSun Dec 3 23:58:10 2000
+++ linux-2.4.2-p3/drivers/sound/ymfpci_image.h Mon Feb 26 23:44:52 2001
@@ -1,7 +1,7 @@
#ifndef _HWMCODE_
#define _HWMCODE_
-static unsigned long int DspInst[] = {
+static unsigned long DspInst[YDSXG_DSPLENGTH / 4] = {
0x0081, 0x01a4, 0x000a, 0x002f,
0x00080253, 0x01800317, 0x407b, 0x843f,
0x0001483c, 0x0001943c, 0x0005d83c, 0x1c3c,
@@ -12,7 +12,7 @@
0x, 0x, 0x, 0x
};
-static unsigned long int CntrlInst[] = {
+static unsigned long CntrlInst[YDSXG_CTRLLENGTH / 4] = {
0x07, 0x240007, 0x0C0007, 0x1C0007,
0x060007, 0x72, 0x20, 0x030040,
0x007104, 0x004286, 0x030040, 0x000F0D,
@@ -791,7 +791,7 @@
// 04/09 creat
// 04/12 stop nise fix
// 06/21 WorkingOff timming
-static unsigned long int CntrlInst1E[] = {
+static unsigned long CntrlInst1E[YDSXG_CTRLLENGTH / 4] = {
0x07, 0x240007, 0x0C0007, 0x1C0007,
0x060007, 0x72, 0x20, 0x030040,
0x007104, 0x004286, 0x030040, 0x000F0D,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
Since the intention of fsync and fdatasync seems to be to write dirty fs buffers to persistent storage (i.e. the "oxide") then the best time is not necessarily the objective. Given the IDE times that people have been reporting, it is very unlikely that any of those IDE disks were really doing 2000 discrete IO operations involving waiting for the those buffers to be written to the "oxide". [Reason: it should take at least 2000 revolutions of the disk to do it, since most of the 4KB writes are going to the same disk address as the prior write.] As it stands, the Linux SCSI subsystem has no mechanism to force a disk cache write through. The SCSI WRITE(10) command has a Force Unit Access bit (FUA) to do exactly that, but we don't use it. Do the fs/block layers flag they wish buffers written to the oxide?? The measurements that showed SCSI disks were taking a lot longer with the "xlog" test were more luck than good management. Here are some tests that show an IDE versus SCSI "xlog" comparison are very similar between FreeBSD 4.2 and lk 2.4.2 on the same hardware: # IBM DCHS04U SCSI disk 7200 rpm <> [root@free /var]# time /root/xlog tst.txt real0m0.043s [root@free /var]# time /root/xlog tst.txt fsync real0m33.131s # Quantum Fireball ST3.2A IDE disk 3600 rpm <> [root@free dos]# time /root/xlog tst.txt real0m0.034s [root@free dos]# time /root/xlog tst.txt fsync real0m5.737s # IBM DCHS04U SCSI disk 7200 rpm <> [root@tvilling extra]# time /root/xlog tst.txt 0:00.00elapsed 125%CPU [root@tvilling spare]# time /root/xlog tst.txt fsync 0:33.15elapsed 0%CPU # Quantum Fireball ST3.2A IDE disk 3600 rpm <> [root@tvilling /root]# time /root/xlog tst.txt 0:00.02elapsed 43%CPU [root@tvilling /root]# time /root/xlog tst.txt fsync 0:05.99elapsed 69%CPU Notes: FreeBSD doesn't have fdatasync() so I changed xlog to use fsync(). Linux timings were the same with fsync() and fdatasync(). The xlog program crashed immediately in FreeBSD; it needed some sanity checks on its arguments. One further note: I wrote: > [snip] > So writing more data to the SCSI disk speeds it up! > I suspect the critical point in the "20*200" test is > that the same sequence of 8 512 byte sectors are being > written to disk 200 times. BTW That disk spins at > 15K rpm so one rotation takes 4 ms and it has a > 4 MB cache. A clarification: by "same sequence" I meant written to the same disk address. If the 4 KB lies on the same track, then a delay of one disk revolution would be expected before you could write the next 4 KB to the "oxide" at the same address. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() alignment
Followup to: <[EMAIL PROTECTED]> By author:Kenn Humborg <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Sun, Mar 04, 2001 at 11:41:12PM +0100, Manfred Spraul wrote: > > > > > > Does kmalloc() make any guarantees of the alignment of allocated > > > blocks? Will the returned block always be 4-, 8- or 16-byte > > > aligned, for example? > > > > > > > 4-byte alignment is guaranteed on 32-bit cpus, 8-byte alignment on > > 64-bit cpus. > > So, to summarise (for 32-bit CPUs): > > o Alan Cox & Manfred Spraul say 4-byte alignment is guaranteed. > > o If you need larger alignment, you need to alloc a larger space, >round as necessary, and keep the original pointer for kfree() > > Maybe I'll just use get_free_pages, since it's a 64KB chunk that > I need (and it's only a once-off). > It might be worth asking the question if larger blocks are more aligned? -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() alignment
On Sun, Mar 04, 2001 at 11:41:12PM +0100, Manfred Spraul wrote: > > > > Does kmalloc() make any guarantees of the alignment of allocated > > blocks? Will the returned block always be 4-, 8- or 16-byte > > aligned, for example? > > > > 4-byte alignment is guaranteed on 32-bit cpus, 8-byte alignment on > 64-bit cpus. So, to summarise (for 32-bit CPUs): o Alan Cox & Manfred Spraul say 4-byte alignment is guaranteed. o If you need larger alignment, you need to alloc a larger space, round as necessary, and keep the original pointer for kfree() Maybe I'll just use get_free_pages, since it's a 64KB chunk that I need (and it's only a once-off). Thanks for your advice. Later, Kenn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USAGI IPv6 patches
Hello, I wondered if there are any long term plans to merge the USAGI IPv6 kernel patches into Linux? See http://www.linux-ipv6.org/> Background: Currently, if my sources on debian-ipv6 are correct, it is not possible to create a IPv6 server that is not broken, as getaddrinfo returns both IPv4 and IPv6 addresses, but the bind operation will only succeed on the IPv6 address. The suggested work around at the moment is to ignore the error returned by bind, but I consider that to be broken, because the error might be important. The only solution we have all agreed to (so far) on debian-ipv6 is to use the USAGI patches (which IIRC modify getaddr to return only IPv6 addresses in the above situation), however, other Debian developers are reluctant to require anything that is "non-standard" in the main kernel. Hence my question... -- Brian May <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3c509 2.4.2-ac12 compilation fails
Greg Louis wrote:
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.2ac12/include -Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
> -march=i686-c -o 3c509.o 3c509.c
> 3c509.c: In function 'el3_probe':
> 3c509.c:330: structure has no member named 'name'
hrm, I wonder if a patch got dropped before I sent it to Alan. It not
only compiles locally, but works on my router at home :)
> --- drivers/net/3c509.c~Mon Mar 5 17:41:37 2001
> +++ drivers/net/3c509.c Mon Mar 5 17:52:57 2001
> @@ -326,8 +326,8 @@
> return -EBUSY;
> irq = idev->irq_resource[0].start;
> if (el3_debug > 3)
> - printk ("ISAPnP reports %s at i/o 0x%x, irq %d\n",
> - el3_isapnp_adapters[i].name, ioaddr, irq);
> + printk ("ISAPnP reports %d at i/o 0x%x, irq %d\n",
> + el3_isapnp_adapters[i].card_device, ioaddr,
That should be s/name/driver_data/...
/me begins to download and merge ac12...
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
Sergey Kubushin wrote: > I _DO_ know what db1 stands for. And we do _NOT_ have db1 in our > distribution, KSI Linux. And we are _NOT_ going to build the obsolete > library with all the accompanied development stuff just to be able to make > some tool required to build exactly ONE kernel driver. It was a nightmare to > get rid of TREE incompatible libdbs so it doesn't make any sence to get that > mess back in. It's just plain braindead to do something like this. Occam was > right and this is plain stupid. Well, it sounds like you're not going to be using that driver, then :) You do what ya gotta do... -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
On 03.06 Sergey Kubushin wrote: > On Mon, 5 Mar 2001, J . A . Magallon wrote: > > > What that line does is to build a tool (aicasm) to generate the ucode > > that > > is built into the kernel (afaik, it is a kind of assembler from a > > language > > to AIC sequencer code). That is, the tool uses db1 (as mkdep.c uses > > glibc) > > but once you have generated the sequencer instructions, that is what is > > built > > into the kernel, not the tool (aicasm). > > It's very nice... Now one should have not only special kgcc to build the > kernel, but also the obsolete library with all the development stuff > installed... Is it sane? > What I dunno is why the h... is needed to rebuild the code everytime you build a kernel. Just ship the ucode and remove the aicasm subtree from kernel. Perhaps mrproper makes things too clean, and just should leave there the sequencer code. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac11 #1 SMP Sat Mar 3 22:18:57 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ramfs & a_ops->truncatepage()
I'm looking at this part of 2.4.2-ac8:
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux-2.4.0/mm/filemap.c
linux.ac/mm/filemap.c
--- linux-2.4.0/mm/filemap.cWed Jan 3 02:59:45 2001
+++ linux.ac/mm/filemap.c Thu Jan 11 17:26:55 2001
@@ -206,6 +206,9 @@
if (!page->buffers || block_flushpage(page, 0))
lru_cache_del(page);
+ if (page->mapping->a_ops->truncatepage)
+ page->mapping->a_ops->truncatepage(page);
+
/*
* We remove the page from the page cache _after_ we have
* destroyed all buffer-cache references to it. Otherwise some
--
Does anyone know who proposed these changes as part of
ramfs enhancements? Basically, we have a very similar
operation in XFS, but would like the call to truncatepage
be _before_ the call to block_flushpage(). As far as ramfs
is concerned, such a change would be a no-op since ramfs doesn't
have page->buffers. Is this correct?
thanks,
ananth.
--
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
On Mon, Mar 05, 2001 at 02:52:24PM -0800, David Brownell wrote: > I didn't see that thread. I agree, pci_alloc_consistent() already has > a signature that's up to the job. The change you suggest would need > to affect every architecture's implementation of that code ... which > somehow seems not the best solution at this time. Needless to say that USB is currently broken for the architectures that need pci_alloc_consistent. A while ago, I looked at what was required to convert the OHCI driver to pci_alloc_consistent, and it turns out that the current interface is highly sub-optimal. It looks good on the face of it, but it _really_ does need sub-page allocations to make sense for USB. At the time, I didn't feel like creating a custom sub-allocator just for USB, and since then I haven't had the inclination nor motivation to go back to trying to get my USB mouse or iPAQ communicating via USB. (I've not used this USB port for 3 years anyway). I'd be good to get it done "properly" at some point though. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
On Mon, 5 Mar 2001, Jeff Garzik wrote: > Amazingly you've hit one of the few problems caused by something > outside > the kernel tree. db v1.85 has been superceded by db2 and db3. db1 is > where the "original" Berkeley db stuff now lives. Apparently aicasm > needs db 1. > > So, update your packages, or create the proper symlinks if you've > already got db1 installed in some other location. I _DO_ know what db1 stands for. And we do _NOT_ have db1 in our distribution, KSI Linux. And we are _NOT_ going to build the obsolete library with all the accompanied development stuff just to be able to make some tool required to build exactly ONE kernel driver. It was a nightmare to get rid of TREE incompatible libdbs so it doesn't make any sence to get that mess back in. It's just plain braindead to do something like this. Occam was right and this is plain stupid. --- Sergey Kubushin Sr. Unix Administrator CyberBills, Inc.Phone: 702-567-8857 874 American Pacific Dr,Fax:702-567-8808 Henderson, NV, 89014 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3c509 2.4.2-ac12 compilation fails
gcc -D__KERNEL__ -I/usr/src/linux-2.4.2ac12/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-march=i686-c -o 3c509.o 3c509.c
3c509.c: In function 'el3_probe':
3c509.c:330: structure has no member named 'name'
make[3]: *** [3c509.o] Error 1
make[3]: Leaving directory /usr/src/linux-2.4.2ac12/drivers/net'
This works, though it's not as informative as what was intended:
--- drivers/net/3c509.c~Mon Mar 5 17:41:37 2001
+++ drivers/net/3c509.c Mon Mar 5 17:52:57 2001
@@ -326,8 +326,8 @@
return -EBUSY;
irq = idev->irq_resource[0].start;
if (el3_debug > 3)
- printk ("ISAPnP reports %s at i/o 0x%x, irq %d\n",
- el3_isapnp_adapters[i].name, ioaddr, irq);
+ printk ("ISAPnP reports %d at i/o 0x%x, irq %d\n",
+ el3_isapnp_adapters[i].card_device, ioaddr,
+irq);
EL3WINDOW(0);
for (j = 0; j < 3; j++)
el3_isapnp_phys_addr[pnp_cards][j] =
--
| G r e g L o u i s | gpg public key: |
| http://www.bgl.nu/~glouis | finger [EMAIL PROTECTED] |
PGP signature
Re: Linux 2.4.2ac12
On Mon, 5 Mar 2001, J . A . Magallon wrote: > What that line does is to build a tool (aicasm) to generate the ucode > that > is built into the kernel (afaik, it is a kind of assembler from a > language > to AIC sequencer code). That is, the tool uses db1 (as mkdep.c uses > glibc) > but once you have generated the sequencer instructions, that is what is > built > into the kernel, not the tool (aicasm). It's very nice... Now one should have not only special kgcc to build the kernel, but also the obsolete library with all the development stuff installed... Is it sane? --- Sergey Kubushin Sr. Unix Administrator CyberBills, Inc.Phone: 702-567-8857 874 American Pacific Dr,Fax:702-567-8808 Henderson, NV, 89014 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
On Mon, 5 Mar 2001, J . A . Magallon wrote: > > On 03.05 Sergey Kubushin wrote: > > On Mon, 5 Mar 2001, Alexander Viro wrote: > > > > New Adaptec driver does not build. It won't. People, can anyone enlighten me > > why do we use a user space library for a kernel driver at all? > > > > gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c > > -o aicasm > > What that line does is to build a tool (aicasm) to generate the ucode that > is built into the kernel (afaik, it is a kind of assembler from a language > to AIC sequencer code). That is, the tool uses db1 (as mkdep.c uses glibc) > but once you have generated the sequencer instructions, that is what is built > into the kernel, not the tool (aicasm). Yuck. Build-dependency on libdb-dev is not pretty. What is it used for, anyway? Assembler in need of libdb. Mind boggleth... Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
Sergey Kubushin wrote: > === Cut === > make -C aic7xxx modules > make[3]: Entering directory >`/tmp/build-kernel/usr/src/linux-2.4.2ac12/drivers/scsi/aic7xxx' > make -C aicasm > make[4]: Entering directory >`/tmp/build-kernel/usr/src/linux-2.4.2ac12/drivers/scsi/aic7xxx/aicasm' > gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o >aicasm > aicasm_symbol.c:39: db1/db.h: No such file or directory Amazingly you've hit one of the few problems caused by something outside the kernel tree. db v1.85 has been superceded by db2 and db3. db1 is where the "original" Berkeley db stuff now lives. Apparently aicasm needs db 1. So, update your packages, or create the proper symlinks if you've already got db1 installed in some other location. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: d_add on negative dentry?
On Tue, 6 Mar 2001, Urban Widmark wrote: > > Is it valid to call d_add on a negative dentry? > (or on a dentry that is already linked in d_hash, but all negative > dentries are, right?) Not all of them. It _is_ legal to do d_add() on a negative dentry. Doing that for hashed dentries is a bug. Use d_instantiate() instead. Cheers, Al PS: as for the patch, better make it d_instantiate(...); if (!hashed) d_rehash(...); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
d_add on negative dentry?
Is it valid to call d_add on a negative dentry?
(or on a dentry that is already linked in d_hash, but all negative
dentries are, right?)
I'm guessing it isn't because I think that is how I can get my machine to
hang in d_lookup, looping on a corrupt d_hash list.
The problem can be reproduced like this. /mnt/smb is a smbfs mount of
/mnt/samba/export from a samba server on localhost.
/mnt/smb% ls
aa
/mnt/smb% rm aa
/mnt/smb% touch /mnt/samba/export/aa
/mnt/smb% ls
ls: aa: No such file or directory
And shortly after it will lock up completely.
My printk's tell me that a negative dentry is still hashed since d_hash is
non-empty. d_add calls d_instantiate and d_rehash, the later adds it to a
d_hash list without first removing it. But it was already linked so now 2
extra dentries are also pointing to this dentry. And it is then no longer
a list ...
The attached patch fixes things for me. Comments?
Oh, and I *think* ncpfs has the same problem. But that's just from reading
the code.
/Urban
diff -urN -X exclude linux-2.4.2-ac11-orig/fs/smbfs/cache.c
linux-2.4.2-ac11-smbfs/fs/smbfs/cache.c
--- linux-2.4.2-ac11-orig/fs/smbfs/cache.c Thu Feb 22 20:52:03 2001
+++ linux-2.4.2-ac11-smbfs/fs/smbfs/cache.c Mon Mar 5 23:48:12 2001
@@ -167,6 +167,7 @@
struct inode *newino, *inode = dentry->d_inode;
struct smb_cache_control ctl = *ctrl;
int valid = 0;
+ int hashed = 0;
ino_t ino = 0;
qname->hash = full_name_hash(qname->name, qname->len);
@@ -181,9 +182,11 @@
newdent = d_alloc(dentry, qname);
if (!newdent)
goto end_advance;
- } else
+ } else {
+ hashed = 1;
memcpy((char *) newdent->d_name.name, qname->name,
newdent->d_name.len);
+ }
if (!newdent->d_inode) {
smb_renew_times(newdent);
@@ -191,7 +194,10 @@
newino = smb_iget(inode->i_sb, entry);
if (newino) {
smb_new_dentry(newdent);
- d_add(newdent, newino);
+ if (hashed)
+ d_instantiate(newdent, newino);
+ else
+ d_add(newdent, newino);
}
} else
smb_set_inode_attr(newdent->d_inode, entry);
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
> > And mm/slab.c changes semantics when CONFIG_SLAB_DEBUG > > is set: it ignores SLAB_HWCACHE_ALIGN. That seems more like > > the root cause of the problem to me! > > HWCACHE_ALIGN does not guarantee a certain byte alignment. And > additionally it's not even guaranteed that kmalloc() uses that > HWCACHE_ALIGN. > Uhci is broken, not my slab code ;-) If so, the slab code docs/specs are broken too ... I just checked in my development tree (2.4.2-ac7 plus goodies) and what's written is that HWCACHE_ALIGN is to "Align the objects in this cache to a hardware cacheline." Which contradicts what you just wrote; it's supposed to always align, not do so only when convenient. Clearly, something in mm/slab.c needs to change even if it's just changing the spec for kmem_cache_create() behavior. > I'd switch to pci_alloc_consistent with some optimizations to avoid > wasting a complete page for each DMA header. (I haven't seen Johannes > patch, but we discussed the problem 6 weeks ago and that proposal was > the end of the thread) I didn't see that thread. I agree, pci_alloc_consistent() already has a signature that's up to the job. The change you suggest would need to affect every architecture's implementation of that code ... which somehow seems not the best solution at this time. Perhaps we should have different functions for pci consistent alloc at the "hardware" level (what we have now) and at the "slab" level. That's sort of what Johannes' patch did, except it was specific to that one driver rather than being a generic utility. Of course, I'd rather that such a generic package have all the debug support (except broken redzoning :-) that the current slab code does. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
On 03.05 Sergey Kubushin wrote: > On Mon, 5 Mar 2001, Alexander Viro wrote: > > New Adaptec driver does not build. It won't. People, can anyone enlighten me > why do we use a user space library for a kernel driver at all? > > gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c > -o aicasm What that line does is to build a tool (aicasm) to generate the ucode that is built into the kernel (afaik, it is a kind of assembler from a language to AIC sequencer code). That is, the tool uses db1 (as mkdep.c uses glibc) but once you have generated the sequencer instructions, that is what is built into the kernel, not the tool (aicasm). -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac11 #1 SMP Sat Mar 3 22:18:57 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
On Mon, 5 Mar 2001, Alexander Viro wrote: New Adaptec driver does not build. It won't. People, can anyone enlighten me why do we use a user space library for a kernel driver at all? === Cut === make -C aic7xxx modules make[3]: Entering directory `/tmp/build-kernel/usr/src/linux-2.4.2ac12/drivers/scsi/aic7xxx' make -C aicasm make[4]: Entering directory `/tmp/build-kernel/usr/src/linux-2.4.2ac12/drivers/scsi/aic7xxx/aicasm' gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or directory make[4]: *** [aicasm] Error 1 make[4]: Leaving directory `/tmp/build-kernel/usr/src/linux-2.4.2ac12/drivers/scsi/aic7xxx/aicasm' make[3]: *** [aicasm/aicasm] Error 2 make[3]: Leaving directory `/tmp/build-kernel/usr/src/linux-2.4.2ac12/drivers/scsi/aic7xxx' make[2]: *** [_modsubdir_aic7xxx] Error 2 make[2]: Leaving directory `/tmp/build-kernel/usr/src/linux-2.4.2ac12/drivers/scsi' make[1]: *** [_modsubdir_scsi] Error 2 make[1]: Leaving directory `/tmp/build-kernel/usr/src/linux-2.4.2ac12/drivers' make: *** [_mod_drivers] Error 2 === Cut === --- Sergey Kubushin Sr. Unix Administrator CyberBills, Inc.Phone: 702-567-8857 874 American Pacific Dr,Fax:702-567-8808 Henderson, NV, 89014 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Mon, Mar 05, 2001 at 10:05:36PM +0100, Pozsar Balazs wrote:
> On Mon, 5 Mar 2001, Robert Read wrote:
> > On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
> > >
> > > And what does POSIX say about "#!/bin/sh\r" ?
> > > In other words: should the kernel look for the interpreter between the !
> > > and the newline, or [the first space or newline] or the first whitespace?
> > >
> > > IMHO, the first whitespace. Which means that "#!/bin/sh\r" should invoke
> > > /bin/sh. (though it is junk).
> >
> > The line terminator, '\n', is what terminates the interpreter. White
> > space (in this case, only ' ' and '\t') is used to seperate the
> ^
> > arguments to the interpreter.
>
>
> The last little tiny thing that bothers me: why? Why only ' ' and '\t' _in
> this case_? As someone mentioned, even isspace() returns whitespace.
>
> A possible answer (that i can think of), is that those ar the whitespaces,
> which are in IFS (as said previously), taking out us from kernel-space
> into userspace. But imho we shouldn't define another set whitespace for
> this case, can't we just use what isspace() says?
And isspace('\n') is also true. At question here is not the
definition of whitespace. The question is, what is the definition of
a command line? What characters are valid command line seperators?
robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Loop stuck in -D state
On Mon, 5 Mar 2001, Jeff Garzik wrote: >... > > 2.4.3-pre2 should be the one to test... it should include the latest > loop fixes.. > For what I've tested, 2.4.3-pre2 works fine with the loop device. David Gómez "The question of whether computers can think is just like the question of whether submarines can swim." -- Edsger W. Dijkstra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problems installing the kernel 2.4 (fwd)
On Mon, 5 Mar 2001, Tania Gomes Ramos wrote: Have you updated your modutils? Maybe that's why it's not working your network adapter. If you didn't, take a look at /usr/src/linux/Documentation/Changes to find out with versions do you need to run a 2.4 kernel. > > >First of all, thanks for helping me... >I have noticed that after I have installed the new version > of kernel (2.4.2),I am having some problems... After compiling > everything, and making the make install_modules, I have the message that > there is nothing to be done in the directories... But, ok, it creates > the modules directorie. But... >First of all, > 1) -- now, trying to acess the network is impossible ... the > ifconfig just shows "lo" and the ethernets no... but, they were > configured in the lilo in the same way they were configured with > the old kernel. You can see the configuration in the lilo: > (there are two partitions, and I have installed the new kernel in > the partition altres) > > image= ../boot/vmlinuz.ip6 > label=lr > append ="ether=5,0x300,eth0 ether=10, 0x210, eth1" > initrd=..boot/initrd-2.2.12-20.img > root=/dev/hda1 > read-only > > image= ../boot/vmlinuz-2.4.2 > label=altres > append ="ether=5,0x300,eth0 ether=10, 0x210, eth1" > #initrd=..boot/initrd-2.2.12-20.img > root=/dev/hdc1 > read-only > > Well, I put a comment in front of initrd because I didnt find > this file *.img of the new kernel... > > I havent changed anything else, and my computer cant see the > network in the partition altres, but in the other one,it is > possible. > > 2)The other problem is: > After installing it, this partition (the only one which > has version 2.4) cant reboot or halt. It starts to do that, > but it always stops at the message: > INIT: there is no more process left in this runlevel. > so,I always have to reset the computer... > > Do you know why it is happening? And what could I do to fix it?? > > Thank you, > Tania Ramos > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > David Gómez "The question of whether computers can think is just like the question of whether submarines can swim." -- Edsger W. Dijkstra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2ac12
It appears that with 2.4.2-ac12, we now have more than 2000 kernel configuration options. Using the options_linux script which I posted earlier today, I get the following: [steven@spc linux]$ sh scripts/options_linux | wc -l 2008 Compare to 2.2.18: [root@spc linux-2.2.18]# sh scripts/options_linux | wc -l 1466 And for vanilla 2.4.2: [root@spc linux-2.4.2]# sh scripts/options_linux | wc -l 1928 Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
continous hard disk trashing and error messages - 2.4.2-ac5
Hi,
For the kernel 2.4.2 with the patch 2.4.2-ac5 patch, I have been getting continous
hard disk trashing and the following errors in the /var/log/messages. I increased the
console log level to avoid the messages. Please see below a sample set
Mar 5 12:15:59 amitc-linux mount: mount: can't open /etc/mtab for writing:
Input/output error
Mar 5 12:16:04 amitc-linux kernel: hda: read_intr: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Mar 5 12:16:04 amitc-linux kernel: hda: read_intr: error=0x40 { UncorrectableError },
LBAsect=25133118, sector=3670215
Mar 5 12:16:04 amitc-linux kernel: end_request: I/O error, dev 03:06 (hda), sector
3670215
Mar 5 12:16:04 amitc-linux kernel: EXT2-fs error (device ide0(3,6)):
ext2_write_inode: unable to read inode block - inode=230017, block=458776
On a restart I have to do a manual fsck, that was some pretty drastic results incl.
removing directories from /var, removing /tmp, etc.
I went through the archives and tried smartctl. That has not given any problems yet.
e2fsprogs is 1.19
The systems is basically unusable right now. Please email me if anyone knows where the
problem might be?
Thanks and Regards
Amit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0 parisc PCI support
Ivan Kokshaysky wrote: > On Fri, Mar 02, 2001 at 11:32:35AM -0800, Grant Grundler wrote: > > Code in parisc-linux CVS (based on 2.4.0) does boot on my OB800 > > (133Mhz Pentium), C3000, and A500 with PCI-PCI bridge support > > working. I'm quite certain PCI-PCI bridge configuration (ie BIOS > > didn't configure the bridge) support was broken. > > I believe it isn't. ;-) It works on various alphas including > configurations with chained PCI-PCI bridges. Ok. I overlooked the changes in arch/alpha/kernel/pci.c:pcibios_fixup_bus(). (As you know, things changed alot between -test10 and -test12) > Some comments on the patch: > > > +** If I/O or MEM ranges are overlapping, that's a BIOS bug. > > No. As we reallocate everything, it is quite possible that we'll > have temporary overlaps during setup with resources allocated > by BIOS. I'm not sure if it is harmful though. The other part of the comment I added was: +** Disabling *all* devices is bad. Console, root, etc get +** disabled this way. I can't debug with *all* devices disabled. Normally, the whole point of resource mgt is to (a) avoid overlaps and (b) reflect the state of the HW. I thought the arch specific code was responsible for setting the HW state and resource mgt state congruent. If the arch/alpha code wants everything reallocated anyway, why not have the arch code disable the HW during the bus walk in pcibios_fixup_bus() before calling pci_assign_unassigned_resources()? (I'm looking at 2.4.0 linux/arch/alpha/kernel/pci.c:common_init_pci() ) FYI, under PDC PAT (eg A500), unused devices are left in the "power on" state (which AFAIK, implies disabled). > > +#ifdef __hppa__ > > +/* XXX FIXME > > +** PCI_BRIDGE_CONTROL and PCI_COMMAND programming need to be revisited > > +** to support FBB. Make all this crud "configurable" by the arch specific > > +** (ie "PCI BIOS") support and the ifdef __hppa__ crap can go away then. > > +*/ > > Agreed. Something like pcibios_set_bridge_control(). possibly...I have another problem I wanted to solve - FBB support. I think generic Fast Back-Back support wants a new field in struct pci_bus (u32 bridge_ctl) to save and manage the FBB state (and SERR/PERR). Arch support would need a way to initialize bridge_ctl *before* pci_do_scan_bus() is called to indicate FBB is or is not supported by the parent PCI bus controller (either HBA or PCI-PCI Bridge). Originally I was thinking of seperating the "root" bus allocation from pci_scan_bus(). But calling pcibios_set_bridge_control() before the bus walk would work too if it passes struct pci_bus * as the parameter. And that could allow arch specific control over SERR/PERR bits as well. In pcibios_fixup_bus(), the arch code could check FBB state to see if it should be enabled on that HBA or not. Ideally, generic code would fully handle FBB for PCI-PCI secondary busses. Perhaps the FBB test could be in pci_setup_bridge() but I'm not sure if that would work for all arches (ie not sure off hand which uses pci_setup_bridge()). [ deleted code changes in drivers/pci/setup-bus.c:pbus_assign_resources() driver/pci/setup-res.c:pdev_sort_resources() ] > This change totally breaks PCI allocation logic. > Probably you assign PCI-PCI bridge windows in arch specific code - why? I think my change in pdev_sort_resources() permitted it to occur in generic code. parisc HBA code only calls request_resources for resources assigned by firmware to the HBA. > The only thing you need is to set up the root bus resources > properly and generic code will do the rest. hmmm...Code in alpha's pcibios_fixup_bus() modifies PCI-PCI Bridge resources. It wouldn't if your statement were literally true. I reversed the two changes in my tree to see what breaks on A500: | lba version TR4.0 (0x5) found at 0xfed3c000 | lba_fixup_bus(0x18b4b780) bus 48 sysdata 0x18b4a800 | lba_fixup_bus() LBA I/O Port [3/3]/100 | lba_fixup_bus() LBA LMMIO [fb00/fb7f]/200 | lba_fixup_bus(0x18b4b880) bus 49 sysdata 0x18b4a800 | lba_fixup_bus(0x18b4b980) bus 50 sysdata 0x18b4a800 | PCI: Failed to allocate resource 0 for 31:04.0 | PCI: Failed to allocate resource 0 for 31:04.1 [ I have a 4-port 100BT card and a 2-port 100BT/896 SCSI "combo" card installed in bus 48 - both have PCI-PCI bridges. No resources are available for any devices under either PPB. ] ... | tulip: eth1: I/O region (0xfffd@0x31000) unavailable, aborting ... | sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 320 | sym53c896-6: ID 7, Fast-40, Parity Checking | sym53c896-6: on-chip RAM at 0xfb10 | CACHE TEST FAILED: reg dstat-sstat2 readback . | CACHE INCORRECTLY CONFIGURED. ... Should I try to follow alpha's pcibios_fixup_bus() and add the code following (linux 2.4.0, arch/alpha/kernel/pci.c line 256) /* This is a bridge. Do not care how it's initialized, ju
Re: [OFFTOPIC] Hardlink utility - reclaim drive space
On Mon, Mar 05, 2001 at 07:17:18PM +, Padraig Brady wrote:
> Hmm.. useful until you actually want to modify a linked file,
> but then your modifying the file in all "merged" trees.
Use emacs, because you can configure it to do something
appropriate with linked files. But for those of us addicted
to vi, the attached wrapper script is pretty cool, too.
dave...
#!/bin/bash
#
# copy-on-write wrapper for hard linked files
# Copyright 2000 David A. Schleef <[EMAIL PROTECTED]>
#
# Please send me any improvments you make to this script. I just
# wrote it as a quick and dirty hack.
linkedfiles=
for each in $*
do
case $each in
-*)
# ignore
;;
*)
if [ -f "$each" ];then
nlinks=$(stat $each|grep Links|sed 's/.*Links:
\(.*\)\{1\}/\1/')
if [ $nlinks -gt 1 ];then
#echo unlinking $each
linkedfiles="$linkedfiles $each"
mv $each $each.orig
cp $each.orig $each
fi
fi
;;
esac
done
/usr/bin/vim $*
for each in $linkedfiles
do
if cmp $each $each.orig &>/dev/null
then
#echo relinking $each
rm $each
mv $each.orig $each
fi
done
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
> And mm/slab.c changes semantics when CONFIG_SLAB_DEBUG > is set: it ignores SLAB_HWCACHE_ALIGN. That seems more like > the root cause of the problem to me! > HWCACHE_ALIGN does not guarantee a certain byte alignment. And additionally it's not even guaranteed that kmalloc() uses that HWCACHE_ALIGN. Uhci is broken, not my slab code ;-) > I think that the pci_alloc_consistent patch that Johannes sent >by for "uhci.c" would be a better approach. Though I'd like >to see that be more general ... say, making mm/slab.c know >about such things. Add a simple abstraction, and that should >be it -- right? :-) I looked at it, and there are 2 problems that make it virtually impossible to integrate kmem_cache_alloc() with pci memory alloc without a major redesign: * pci_alloc_consistent returns 2 values, kmem_cache_alloc() only one. This one would be possible to work around. * the slab allocator heavily relies on the 'struct page' structure, but it's not guaranteed that it exists for pci_alloced memory. I'd switch to pci_alloc_consistent with some optimizations to avoid wasting a complete page for each DMA header. (I haven't seen Johannes patch, but we discussed the problem 6 weeks ago and that proposal was the end of the thread) -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: anti-spam regexps
On Mon, 5 Mar 2001 [EMAIL PROTECTED] wrote: > >I think I could even setup something where we keep the > >anti-spam regexps in a publicly accessible CVS tree (with > >of course a nice script to automatically generate the > >majordomo.cf). > > Cool. Sooner or later, some fun-loving script-kiddie will put suse.de > or redhat.com or debian.org in this automatically generated thing. > > Ah, the fun of automatisms. ;-) Of course anonymous CVS access will be read-only ... Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [jford@tusc.net: LUNA: Megaraid problems]
Consider trying the megaraid driver megaraid.[ch] in 2.4.2-ac11 and above. It's v1.14g-ac. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
I've used 82c686a at UDMA66 on MSI 694D with WD418000 and standard UDMA66 18" cables quite successfully. David Riley wrote: > Alan Cox wrote: > > 2.4.2-ac12 > > o Update VIA IDE driver to 3.21 (Vojtech Pavlik) > > |No UDMA66 on 82c686 > > Um... Does that include 686a? 82c686a is supposed to handle UDMA66... > Or is it a corruption issue again? UDMA66 seems to work fine on > mine... No corruptions yet. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Mon, 5 Mar 2001, John Kodis wrote: > On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote: > > > Somebody must have missed the boat entirely. Unix does not, never > > has, and never will end a text line with '\r'. > > Unix does not, never has, and never will end a text line with ' ' (a > space character) or with \t (a tab character). Yet if I begin a shell > script with '#!/bin/sh ' or '#!/bin/sh\t', the training white space is > striped and /bin/sh gets exec'd. Since \r has no special significance > to Unix, I'd expect it to be treated the same as any other whitespace > character -- it should be striped, and /bin/sh should get exec'd. umm, last i checked a carriage return wasn't whitespace... space, horizontal tab, vertical tab, form feed constitute whitespace IIRC... Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mad16 C924 detection
Patch is replacing 7 levels of nested ifs with something
readable. Against 2.4 kernels. I have posted this one already once,
trying again.
The driver doesn't support C924 in both PnP and non-PnP modes as it
claims. It looks like part of the code got lost or was not finished. This
patch makes it more clear what's going on. There are many places in the
driver with two different paths for C924, only one is ever used.
Pavel Rabel
--- drivers/sound/mad16.c.old Wed Nov 15 20:18:57 2000
+++ drivers/sound/mad16.c Thu Nov 16 23:07:44 2000
@@ -462,72 +462,80 @@
DDB(printk("Detect using password = 0xE5\n"));
- if (!detect_mad16())/* No luck. Try different model */
- {
- board_type = C928;
+ if (detect_mad16()) {
+ return 1;
+ }
+
+ board_type = C928;
- DDB(printk("Detect using password = 0xE2\n"));
+ DDB(printk("Detect using password = 0xE2\n"));
- if (!detect_mad16())
- {
- board_type = C929;
-
- DDB(printk("Detect using password = 0xE3\n"));
-
- if (!detect_mad16())
- {
- if (inb(PASSWD_REG) != 0xff)
- return 0;
-
- /*
-* First relocate MC# registers to 0xe0e/0xe0f,
disable password
-*/
-
- outb((0xE4), PASSWD_REG);
- outb((0x80), PASSWD_REG);
-
- board_type = C930;
-
- DDB(printk("Detect using password = 0xE4\n"));
-
- for (i = 0xf8d; i <= 0xf93; i++)
- DDB(printk("port %03x = %02x\n", i,
mad_read(i)));
-if(!detect_mad16()) {
-
- /* The C931 has the password reg at F8D */
- outb((0xE4), 0xF8D);
- outb((0x80), 0xF8D);
- DDB(printk("Detect using password = 0xE4 for
C931\n"));
-
- if (!detect_mad16()) {
- board_type = C924;
- c924pnp++;
- DDB(printk("Detect using password = 0xE5 (again),
port offset -0x80\n"));
- if (!detect_mad16()) {
- c924pnp=0;
- return 0;
- }
-
- DDB(printk("mad16.c: 82C924 PnP detected\n"));
- }
- }
- else
- DDB(printk("mad16.c: 82C930 detected\n"));
- } else
- DDB(printk("mad16.c: 82C929 detected\n"));
- } else {
- unsigned char model;
+ if (detect_mad16())
+ {
+ unsigned char model;
- if (((model = mad_read(MC3_PORT)) & 0x03) == 0x03) {
- DDB(printk("mad16.c: Mozart detected\n"));
- board_type = MOZART;
- } else {
- DDB(printk("mad16.c: 82C928 detected???\n"));
- board_type = C928;
- }
+ if (((model = mad_read(MC3_PORT)) & 0x03) == 0x03) {
+ DDB(printk("mad16.c: Mozart detected\n"));
+ board_type = MOZART;
+ } else {
+ DDB(printk("mad16.c: 82C928 detected???\n"));
+ board_type = C928;
}
+ return 1;
+ }
+
+ board_type = C929;
+
+ DDB(printk("Detect using password = 0xE3\n"));
+
+ if (detect_mad16())
+ {
+ DDB(printk("mad16.c: 82C929 detected\n"));
+ return 1;
+ }
+
+ if (inb(PASSWD_REG) != 0xff)
+ return 0;
+
+ /*
+* First relocate MC# registers to 0xe0e/0xe0f, disable password
+*/
+
+ outb((0xE4), PASSWD_REG);
+ outb((0x80), PASSWD_REG);
+
+ board_type = C930;
+
+ DDB(printk("Detect using password = 0xE4\n"));
+
+ for (i = 0xf8d; i <= 0xf93; i++)
+ DDB(printk("port %03x = %02x\n", i, mad_read(i)));
+
+if(detect_mad16()) {
+ DDB(printk("mad16.c: 82C930 detected\n"));
+ return 1;
}
- return 1;
+
+ /* The C931 has the password reg at F8D */
+ outb((0xE4), 0xF8D);
+ outb((0x80), 0xF8D);
+ DDB(printk("Detect using password = 0xE4 for C931\n
Re: Question about IRQ_PENDING/IRQ_REPLAY
>We have about 12 interrupt controllers we end up using on PPC. I'm >suspicious of any effort to base Linux/PPC generic interrupt control code >paths on a software architecture that's been tested with 3. More to the >point, we get ASIC's that roll in a standard interrupt controller and add >some "improvements" at the same time. Well, I personally don't see what would be a problem... Of course, the current i386 irq.c cannot be re-used completel "as is". The bit of code that gets the actual irq number has to be arch specific. But most of the locking issues are completely platform neutral. I personally see that code as a good framework that provides many features that may or may not be neccessary depending on the level of brokenness of a given interrupt controller. >As for SMP, I'm sure x86 has seen a lot more testing. I'm not going to >sacrifice time-tested stability so we can look just like x86 and get clean >SMP locking. We've lost stability already because of some PPC folks' >excitement at getting us to behave like x86 in irq.c. We lost stability ? Hrm... If we had ever a problem with SMP, it was in the openpic code, and apparently, due to a HW bug. I don't think the new irq.c code in itself caused us to lose stability. I actually do think it improved the locking, and so, stability. >As for a generic irq.c, as a guiding light, I'm all for it. It'll >certainly help work with RTLinux. It'll also help new architectures by >giving them a snap-together port construction kit. I'm still not going to >sacrifice stability in the short-term for this nice feature in the >long-run. I'm pretty sure we agree on this. Well, we have been running this new irq.c which I partially based on i386 for some monthes now, and had enough time to iron out most problems. Again, all the stability problems we had so far were related to the openpic implementation, I don't remember seeing one stability problem reported so far that was related to irq.c. And I've been running a couple of dual G4s without much trouble for some time now. We do (did ?) have a problem with irq distribution on SMP with openpic. I'm not sure we yet know exactly why, according to both you and IBM people, we are running over an HW bug of the openpic core. I see nothing in irq.c that can cause this. On the other hand, the new irq.c brings the irq depth handling, the ability to call enable/disable from within the handler (I've been wanting that for some time for the PMU driver), proper spinlock'ing, etc... And last, but not least, consistent semantics of enable/disable irq exposed to drivers (especially things like disable_irq() actually waiting for that irq to be completed on any other CPU). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about IRQ_PENDING/IRQ_REPLAY
>And I seriously doubt that PPC SMP irq handling has gotten _nearly_ the >amount of testing and hard work that the x86 counterpart has. Things >like support for CPU affinity, per-irq spinlocks, etc etc. Some of those are the reason I moved part of the x86 irq.c code to PPC indeed. >Now, I'm not saying that irq.c would necessarily work as-is. It probably >doesn't support all the things that other architectures might need (but >with three completely different irq controllers on just standard PCs >alone, I bet it supports most of it), and I know ia64 wants to extend it >to be more spread out over different CPU's, but most of the high-level >stuff probably _can_ and should be fairly common. And I think they are. One thing is that if made "common", do_IRQ have to be split into an arch-specific function that retrives the irq_number (and does the ack on some controller), and the actual "dispatch" function that does all the flags game and calls the handler. I've slightly extended it using the IRQ_PERCPU flag to prevent IRQ_INPROGRESS from ever beeing set (a bit hackish but I wanted that for IPIs since they use ordinary irq_desc structures for us in most cases). Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can Linux 2.4.x boot from UDMA-100 disk ?
I am doing this very thing on linux 2.2.18. My kernel has both the hd.c and ide.c drivers installed. I had to specify ide0=0x1f0 to the kernel to prevent the kernel's hd.c driver from remapping the first two drives to hda/hdb. With the ide0 setting the kernel preserves the true partition mapping. My boot partition is on /dev/hde and my root is on /dev/hdg. Since my UDMA 100 controller is an addon controller I had to instruct my system's BIOS to specify boot order as ATA/SCSI, and to boot from "SCSI" rather than HDD0. -J. Bryan O'Sullivan wrote: > y> Would it be possible to boot kernel 2.4.x from the UDMA/100 drive? > > Yes. > > y> in http://www.linux-ide.org/ultra100.html it is not mentioned if > y> the patches can help with boot. > > You shouldn't need Andre's patches. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[jford@tusc.net: LUNA: Megaraid problems]
I have a machine with a built-in Adaptec aic7xxx card and a Megaraid PCI card. My system (raid 5) boots off the Megaraid. For this to work I compiled the Megaraid module into the kernel while the aic7xxx loads as a module. dmesg shows the following: megaraid: v107 (December 22, 1999) megaraid: found 0x101e:0x9010:idx 0:bus 0:slot 14:func 0 scsi0 : Found a MegaRAID controller at 0x7810, IRQ: 10 megaraid: [UF80:1.61] detected 1 logical drives scsi0 : AMI MegaRAID UF80 254 commands 16 targs 3 chans 8 luns scsi : 1 host. scsi0: scanning channel 1 for devices. scsi0: scanning channel 2 for devices. scsi0: scanning channel 3 for devices. scsi0: scanning virtual channel for logical drives. Vendor: MegaRAID Model: LD0 RAID5 34712R Rev: UF80 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 3, id 0, lun 0 scsi : detected 1 SCSI generic 1 SCSI disk total. Works great with kernel 2.2.16. Worked great up to kernel 2.3.99-test8 or so. However under the current 2.4.x kernels (2.4.0, 2.4.1, 2.4.2) I get the following message: scsi subsystem driver rev 1.0 megaraid: v107 (Dec 22, 1999) megaraid: found 0x101e: 0x9010: in 00:0e.0 scsi0: found a megaraid controller at 0x7810, irq 10 megaraid: couldn't register I/O register requested_modules[scsi_hostadapter] root fs not found (repeat above 2 more time) VFS - cannot open boot device 806 or 08:06 which makes sense - can't register device, can open device. The only difference I've been able to find between the working and non-working kernels is the "SCSI Subsystem Driver Rev 1.0" line. So, what direction should I go? Anyone have any pointers? Tia. -- James LUNA-LIST help: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] To email the list keeper:[EMAIL PROTECTED] LUNA-LIST Web Site: http://luna.huntsville.al.us/lunalist.htm>
Re: Linux 2.4.2ac12
Alan Cox wrote: > 2.4.2-ac12 > o Update VIA IDE driver to 3.21 (Vojtech Pavlik) > |No UDMA66 on 82c686 Um... Does that include 686a? 82c686a is supposed to handle UDMA66... Or is it a corruption issue again? UDMA66 seems to work fine on mine... No corruptions yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS in 2.2.18-14mdk RAID code
I recieved this oops after rearranging my SMP system to include a large
(>100GB) raid5 array and copying approximately 15GB to it. The array
was still synchronizing at the time.
Motherboard is MSI 694D. RAID array in question is attached to the
Promise 20265 chipset. No drives were attached to the VIA
IDE controller.
Anyone knowledgable have any ideas? I have not seen this since.
[jsilva@tetsuo jsilva]$ uname -a
Linux tetsuo.concentric.net 2.2.18-14mdksmp #1 SMP Thu Feb 22 19:02:28
CET 2001 i686 unknown
[jsilva@tetsuo jsilva]$ cat /proc/ide/pdc202xx
PDC20265 Chipset.
--- General Status
-
Burst Mode : enabled
Host Mode: Normal
Bus Clocking : 66 External
IO pad select: 10 mA
Status Polling Period: 7
Interrupt Check Status Polling Delay : 15
--- Primary Channel Secondary Channel
-
enabled enabled
66 Clocking enabled enabled
Mode MASTER Mode MASTER
FIFO Empty FIFO Empty
--- drive0 - drive1 drive0 --
drive1 --
DMA enabled:yes yes yes yes
DMA Mode: UDMA 4 UDMA 4 UDMA 4UDMA
4
PIO Mode: PIO 4PIO 4 PIO 4PIO 4
[jsilva@tetsuo jsilva]$ cat /proc/ide/hde/model
IBM-DTLA-307045
[jsilva@tetsuo jsilva]$ cat /proc/ide/hd?/model
Pioneer DVD-ROM ATAPIModel DVD-114 0203
CREATIVEDVD-ROM DVD2240E 03/18/98
IBM-DTLA-307045
IBM-DTLA-307045
IBM-DTLA-307045
IBM-DTLA-307045
[jsilva@tetsuo jsilva]$
[jsilva@tetsuo jsilva]$ cat /OOPS
Oops:
CPU: 0
EIP: 0010:[]
EFLAGS: 00010206
eax: dc7456f0 ebx: 07d000ab ecx: 0004 edx: 0871010a
ds: 0018 es:0018 ss:0018
Process raid5d (pid: 595, process nr: 10, stackpage=cfcf5000)
Stack: c0ad6aac 0003 c013c07a e00a7883 dc7456c0
0001
c0ad6a00 cad4e000 c0ad6a00 caf42e00 c0ad6a00 03cf c0ad6aac
c0ad6a4c
0004 e00a79fc c0ad6a00 c0adca00 caf42e00
03cf
Call Trace: [] [] [] []
[] [] []
[]
Code: 8b 02 85 45 fc 74 f0 8b 02 a8 20 74 0a 85 ff 75 e6 bf 01 00
[jsilva@tetsuo jsilva]$ cat /OOPS.out
ksymoops 2.3.7 on i686 2.2.18-14mdksmp. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.18-14mdksmp/ (default)
-m /boot/System.map (specified)
Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list
not found in System.map. Ignoring ksyms_base entry
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: dc7456f0 ebx: 07d000abecx: 0004 edx: 0871010a
ds: 0018 es:0018 ss:0018
Process raid5d (pid: 595, process nr: 10, stackpage=cfcf5000)
Stack: c0ad6aac 0003 c013c07a e00a7883 dc7456c0
0001
c0ad6a00 cad4e000 c0ad6a00 caf42e00 c0ad6a00 03cf
c0ad6aac c0ad6a4c
0004 e00a79fc c0ad6a00 c0adca00 caf42e00
03cf
Call Trace: [] [] [] []
[] [] []
[]
Code: 8b 02 85 45 fc 74 f0 8b 02 a8 20 74 0a 85 ff 75 e6 bf 01 00
>>EIP; c0116c59 <__wake_up+31/7c> <=
Trace; c0130c7a
Trace; e00a7783 <[raid5]complete_stripe+c7/18c>
Trace; e00a79fc <[raid5]handle_stripe+15c/cf4>
Trace; c01909fc
Trace; c010c815 <__global_restore_flags+25/44>
Trace; e00a88a7 <[raid5]raid5d+b7/10c>
Trace; c0198a58
Trace; c010903b
Code; c0116c59 <__wake_up+31/7c>
<_EIP>:
Code; c0116c59 <__wake_up+31/7c> <=
0: 8b 02 mov(%edx),%eax <=
Code; c0116c5b <__wake_up+33/7c>
2: 85 45 fc test %eax,0xfffc(%ebp)
Code; c0116c5e <__wake_up+36/7c>
5: 74 f0 je fff7 <_EIP+0xfff7>
c0116c50 <__wake_up+28/7c>
Code; c0116c60 <__wake_up+38/7c>
7: 8b 02 mov(%edx),%eax
Code; c0116c62 <__wake_up+3a/7c>
9: a8 20 test $0x20,%al
Code; c0116c64 <__wake_up+3c/7c>
b: 74 0a je 17 <_EIP+0x17> c0116c70
<__wake_up+48/7c>
Code; c0116c66 <__wake_up+3e/7c>
d: 85 ff test %edi,%edi
Code; c0116c68 <__wake_up+40/7c>
f: 75 e6 jnefff7 <_EIP+0xfff7>
c0116c50 <__wake_up+28/7c>
Code; c0116c6a <__wake_up+42/7c>
11: bf 01 00 00 00mov$0x1,%edi
1 warning issued. Results may not be reliable.
[jsilva@tetsuo jsilva]$
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at h
problems installing the kernel 2.4 (fwd)
First of all, thanks for helping me... I have noticed that after I have installed the new version of kernel (2.4.2),I am having some problems... After compiling everything, and making the make install_modules, I have the message that there is nothing to be done in the directories... But, ok, it creates the modules directorie. But... First of all, 1) -- now, trying to acess the network is impossible ... the ifconfig just shows "lo" and the ethernets no... but, they were configured in the lilo in the same way they were configured with the old kernel. You can see the configuration in the lilo: (there are two partitions, and I have installed the new kernel in the partition altres) image= ../boot/vmlinuz.ip6 label=lr append ="ether=5,0x300,eth0 ether=10, 0x210, eth1" initrd=..boot/initrd-2.2.12-20.img root=/dev/hda1 read-only image= ../boot/vmlinuz-2.4.2 label=altres append ="ether=5,0x300,eth0 ether=10, 0x210, eth1" #initrd=..boot/initrd-2.2.12-20.img root=/dev/hdc1 read-only Well, I put a comment in front of initrd because I didnt find this file *.img of the new kernel... I havent changed anything else, and my computer cant see the network in the partition altres, but in the other one,it is possible. 2)The other problem is: After installing it, this partition (the only one which has version 2.4) cant reboot or halt. It starts to do that, but it always stops at the message: INIT: there is no more process left in this runlevel. so,I always have to reset the computer... Do you know why it is happening? And what could I do to fix it?? Thank you, Tania Ramos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] ncpfs (was Re: [acme@conectiva.com.br: Re: mke2fs /dev/...)
On 5 Mar 01 at 15:05, [EMAIL PROTECTED] wrote: > > What is the current version of ncpfs, and where can it be found? The most > recent I could find (at www.ibiblio.org) was ncpfs-2.2.0 which dates back to May > 1998, and I ran into the problem with select when trying to compile it on a > current system. I got it to work by compiling it on an old 2.0.x box that I > haven't upgraded in several years, then moved it to my 2.4.x system. It's been > working fine for several months, but I'd like to be able to compile it on a > current system without hacking the source. Current released version is 2.2.0.18 and is available from Debian (and maybe RedHat and others) and from its primary site ftp://platan.vc.cvut.cz/pub/linux/ncpfs/latest. Latest beta version is 2.2.0.19.pre42, and is avaialble from ftp://platan.vc.cvut.cz/private/ncpfs (and is packaged in experimental Debian, AFAIK). 2.2.0.19 supports TCP mode of NCP, while 2.2.0.18 supports UDP/IPX only. 2.2.0.18 compiles on libc5/glibc2.x, while 2.2.0.19 currently compiles on glibc2.2 only. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12
On Mon, 5 Mar 2001, Alan Cox wrote: > o Fix binfmt_misc (and make the proc handling (Al Viro) > |a filesystem - > |mount -t binfmt_misc none /proc/sys/fs/binfmt_misc One comment: probably the best way to maintain backwards compatibility for people who used binfmt_misc as a module would be the following: post-install binfmt_misc /bin/mount -t binfmt_misc none /proc/sys/fs/binfmt_misc pre-remove binfmt_misc /bin/umount /proc/sys/fs/binfmt_misc in the /etc/modules.conf. Then insmod binfmt_misc and rmmod binfmt_misc will have the same effect as they used to do. However, the Right Thing(tm) is a) let mount do insmod (not the other way round) b) use less idiotic mountpoint (binfmt_misc is sysctl-related, so it got no business being under /proc/sys). BTW, the new code in fs/binfmt_misc.c can be considered as a demo on how to turn drivers into filesystems... Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
> And what does POSIX say about "#!/bin/sh\r" ? Nothing at all. The #! construction is not part of any standard right now. The implementation is messy - different operating systems do vaguely similar things, but all details differ. Linux can do whatever it wants. Of course it helps portability if we stay close to what other OSs do. There is some discussion at http://www.cwi.nl/~aeb/std/hashexclam-1.html Additions and corrections welcome. In this particular case I have no strong opinion, but would not object to removing the '\r'. The standard defines whitespace in the POSIX locale, as one or more s (s and s), s, s, s, and s. Some systems strip the #! line for trailing whitespace, some don't. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [acme@conectiva.com.br: Re: mke2fs /dev/loop0]
What is the current version of ncpfs, and where can it be found? The most recent I could find (at www.ibiblio.org) was ncpfs-2.2.0 which dates back to May 1998, and I ran into the problem with select when trying to compile it on a current system. I got it to work by compiling it on an old 2.0.x box that I haven't upgraded in several years, then moved it to my 2.4.x system. It's been working fine for several months, but I'd like to be able to compile it on a current system without hacking the source. Wayne "Petr Vandrovec" <[EMAIL PROTECTED]> on 03/05/2001 05:41:47 AM To: "Holluby IstvBetan [EMAIL PROTECTED]" <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec) Subject: Re: [[EMAIL PROTECTED]: Re: mke2fs /dev/loop0] On 5 Mar 01 at 12:27, Holluby Istv ßn istvan.holluby wrote: > On Wed, 28 Feb 2001, Arnaldo Carvalho de Melo wrote: > > The problem was simply, that I couldn't cd to a directory. > "File exist, but couldn't be stat-ed" or something similar was the > message. Reasonable recent kernels should display ':' instead of unknown characters on ncpfs. Of course it requires that codepage->unicode translation table does not contain disallowed translations. > > Can you be more specific? ncpfs should (and AFAIK does) compile out > > of the box > > On glibc-2.2.2 header files of select changed. So it does not > compile cleanly. If I remember well, a define called number_of_open or > similar was also missing. I am not sure in it thou. It might have been > some other program. You are using some really old ncpfs. Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Mon, 5 Mar 2001, Robert Read wrote: > On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote: > > > > And what does POSIX say about "#!/bin/sh\r" ? > > In other words: should the kernel look for the interpreter between the ! > > and the newline, or [the first space or newline] or the first whitespace? > > > > IMHO, the first whitespace. Which means that "#!/bin/sh\r" should invoke > > /bin/sh. (though it is junk). > > The line terminator, '\n', is what terminates the interpreter. White > space (in this case, only ' ' and '\t') is used to seperate the ^ > arguments to the interpreter. The last little tiny thing that bothers me: why? Why only ' ' and '\t' _in this case_? As someone mentioned, even isspace() returns whitespace. A possible answer (that i can think of), is that those ar the whitespaces, which are in IFS (as said previously), taking out us from kernel-space into userspace. But imho we shouldn't define another set whitespace for this case, can't we just use what isspace() says? (okay, I'm not for this '\r' thingy, I just want to see the reasons.) -- Balazs Pozsar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usb-storage log verbosity
Umm.. all the printk's are inclosed with the ifdef, courtsey of a little bit of #define magic. I use it all the time (after all, I'm the maintainer), and when I want it to shut up, it shuts up. Are you sure you recompiled and installed properly? Re-ran 'make dep'? I've had reports of this before -- every one of them was solved by a proper recompilation. Matt On Mon, Mar 05, 2001 at 04:55:02PM +0100, J . A . Magallon wrote: > Hi, > > I have recently started to use an USB cd toaster and have a little problem. > Writer is driven by usb-storage and scsi-cdrom and scsi-generic drivers. > Burning works fine. > > The problem is that the usb-storage module spits so many info-debug > messages (even if I configured no debug in kernel config) that after > a cd burn I end up with a 25 MB file in /var/log/messages and other 25MB > in /var/log/kernel/info, so it fills my / partition. > > If someone know a fast way to shut up usb-storage, I'll be gratefull. > If not, I will try to make a patch to enclose all that printk's into > #ifdef CONFIG_USB_STORAGE_DEBUG. > > -- > J.A. Magallon $> cd pub > mailto:[EMAIL PROTECTED] $> more beer > > Linux werewolf 2.4.2-ac11 #1 SMP Sat Mar 3 22:18:57 CET 2001 i686 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver We've made a business out of making money from annoying and stupid people. I think you fall under that category. -- Chief User Friendly, 7/11/1998 PGP signature
Re: Question about IRQ_PENDING/IRQ_REPLAY
We have about 12 interrupt controllers we end up using on PPC. I'm suspicious of any effort to base Linux/PPC generic interrupt control code paths on a software architecture that's been tested with 3. More to the point, we get ASIC's that roll in a standard interrupt controller and add some "improvements" at the same time. As for SMP, I'm sure x86 has seen a lot more testing. I'm not going to sacrifice time-tested stability so we can look just like x86 and get clean SMP locking. We've lost stability already because of some PPC folks' excitement at getting us to behave like x86 in irq.c. As for a generic irq.c, as a guiding light, I'm all for it. It'll certainly help work with RTLinux. It'll also help new architectures by giving them a snap-together port construction kit. I'm still not going to sacrifice stability in the short-term for this nice feature in the long-run. I'm pretty sure we agree on this. } Most of arch/i386/kernel/irq.c should really be fairly generic, and the } fact is that a lot of the issues are a lot more subtle than most people } really end up realizing. I got really tired of seeing the same old SMP } problems that had long since been fixed on x86 show up on other } architectures. } } So the plan is to have at least a framework for allowing other } architectures to use a common irq.c if they want to. Probably not force } it down peoples throats, because this is an area where the differences } can be _so_ large that it might not be worth it for everybody. But I } seriously doubt that PPC is all that different. } } And I seriously doubt that PPC SMP irq handling has gotten _nearly_ the } amount of testing and hard work that the x86 counterpart has. Things } like support for CPU affinity, per-irq spinlocks, etc etc. } } Now, I'm not saying that irq.c would necessarily work as-is. It probably } doesn't support all the things that other architectures might need (but } with three completely different irq controllers on just standard PCs } alone, I bet it supports most of it), and I know ia64 wants to extend it } to be more spread out over different CPU's, but most of the high-level } stuff probably _can_ and should be fairly common. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 broke in-kernel ide_cs support
On Mon, 5 Mar 2001 08:14:42, Pavel Machek <[EMAIL PROTECTED]> wrote: > > I do not yet know details, but it worked in 2.4.1 and it does not work > now: > > Mar 5 09:12:05 bug cardmgr[69]: initializing socket 1 > Mar 5 09:12:05 bug cardmgr[69]: socket 1: ATA/IDE Fixed Disk > Mar 5 09:12:05 bug cardmgr[69]: module //pcmcia/ide_cs.o not > available > Mar 5 09:12:06 bug cardmgr[69]: get dev info on socket 1 failed: > Resource temporarily unavailable > Pavel > ((Module not available is okay, it should be compiled into kernel)) /etc/pcmcia/config refers to ide_cs but module is ide-cs. I've edited /etc/pcmcia/config and changed all ide_cs to ide-cs and it works. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 broke in-kernel ide_cs support
In article <[EMAIL PROTECTED]> you wrote: > Hi! > I do not yet know details, but it worked in 2.4.1 and it does not work > now: > Mar 5 09:12:05 bug cardmgr[69]: initializing socket 1 > Mar 5 09:12:05 bug cardmgr[69]: socket 1: ATA/IDE Fixed Disk > Mar 5 09:12:05 bug cardmgr[69]: module //pcmcia/ide_cs.o not > available That is correct. the module is called ide-cs.o and has been for a long time. You must have lost your symlink :) It's better to change the /etc/pcmcia files to use ide-cs though, as that actually has a chance of working. (and works for me very well) Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.2ac12
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.2-ac12 o Move the pci_enable_device for cardbus (David Hinds) o Add Sony MSC-U01N to the unusual devices(Marcel Holtmann) o Final smc-mca fixups - should now work (James Bottomley) o Document kernel string/mem* functions (Tim Waugh) | and I added a memcpy warning o Update VIA IDE driver to 3.21 (Vojtech Pavlik) |No UDMA66 on 82c686, fix /proc and udma on |686b, fix dma disables o Allow sleeping in ctrl-alt-del callbacks(Andrew Morton) |Fix i2o, dac960, watchdog, gdth hangs on exit o Fix binfmt_misc (and make the proc handling (Al Viro) |a filesystem - |mount -t binfmt_misc none /proc/sys/fs/binfmt_misc o Update the ACI support for sound/radio stuff(Robert Siemer) o Add RDS support to miroRadio(Robert Siemer) o Remove serverworks handling. The BIOS is our(me) best (and right now only) hope for that chip o Tune the vm behavioru a bit more(Mike Galbraith) o Update PAS16 documentation (Thomas Molina) o Reiserfs tools recommended are now 0d not 0b(Steven Cole) o Wan driver small fixes (Jeff Garzik) o Net driver fixes for 3c503, 3c509, 3c515, (Jeff Garzik) 8139too, de4x5, defxx, dgrs, dmfe, eth16i, ewrk3, natsemi, ni5010, pci-skeleton, rcpci45, sis900, sk_g16, smc-ultra, sundance, tlan, via-rhine, winbond-840, yellowfin, wavelan_cs tms380tr o Trim 3K off the aha1542 driver size (Andrzej Krzysztofowicz) o Trim 1K off qlogicfas (Andrzej Krzysztofowicz) o Fix openfirmware/mm boot on ppc (Cort Dougan) o Fix topdir handling in Makefile (Keith Owens) o Minor fusion driver updates (Steve Ralston) o Merge Etrax cris updates(Bjorn Wesen) o Clgen fb copyright update (Jeff Garzik) o AGP linkage fix (Jeff Garzik) o Update visor driver to work with minijam(Arnim Laeuger) o Fix a usb devio return code (Dan Streetman) o Resync a few other net device changes with the submits Jeff sent to Linus (Jeff Garzik) o Add missing md export symbol(Mohammad Haque) 2.4.2-ac11 o Fix NLS Config.in (David Weinehall) o Sort out one escaped revert from the megaraid (me) update o Resync with Linux 2.4.3pre1 | Except tulip the network driver changes have | been used to replace the existing ones o Fix parport case where a reader could get stuck (Tim Waugh) o Add ALi15x3 to the list of isa dma hangs(Angelo Di Filippo) o Fix nasty bug in IPX routing of netbios frames (Arnaldo Carvalho de Melo) o Misc code cleanups (Keith Owens) o Updated 3c527 driver(Richard Proctor) o Further tulip updates (Jeff Garzik) o i810_rng fixes (FIPS test, regions) (Jeff Garzik) o Further cs89x0 cleanups (Andrew Morton) o Further USB hub updates (Dave Brownell) o Mall USB resource cleanup (Jeff Garzik) o Resync hp100 changes from Jeff Garzik (Jeff Garzik) o PCI documentation update(Tim Waugh) o Fix irda crash (Jean Tourrilhes) o PPC updates (Cort Dougan) o Resync dmfe, hamachi, pci-skeleton and winbond (Jeff Garzik) 2.4.2-ac10 o Add ZF-Logic watchdog driver(Fernando Fuganti) o Add devfs support to USB printers (Mark McClelland) o Fix baud rate handling on keyspan (Paul Mackerras) o USB documentation update(Dave Brownell) o Fix disconnect leak (Randy Dunlap) o ARM constants/fixes (Russell King) o Includes for integrator ARM architecture(Russell King) o Update NLS descriptions to be clearer (Pablo Saratxaga) o Add iso-8859-13 (latvian/lithuanian)(Pablo Saratxaga) iso-8859-4, cp1251 (windows cyrillic), cp1255 (windows hebrew), and some alises o Merge 1.14 Megaraid driver (Venkatesh Ramamurthy) o Reapply other fixes this version dropped(me) o Reformat and clean up ifdefs in 1.14 Megaraid (me) o I/O
sk_buff in 2.4.0
Hi, As far as I understand, in 2.2.x networking code the protocol header and data used to reside in a contiguous region in memory(pointed to by the head, data, tail, end of sk_buff struct), ie skb->data is the starting point and skb->tail is the ending point. | | | | skb->data --|-- | | | | | | | | | | | skb->tail --|---| | | And the device drivers used to transfer from skb->data to skb->tail(==skb->len). My question is: Is the state of the art same in 2.4.0, ie. is protocol header and data still has to reside contiguously? Or header and data may be non-contiguous and the driver does scatter/gather. I am starting off in 2.4.0 , plz. help. -- sourav SOURAV SENMSc(Engg.) CSA IISc BANGALORE URL : www2.csa.iisc.ernet.in/~sourav ROOM NO : N-78 TEL :(080)309-2454(HOSTEL) (080)309-2906 (COMP LAB) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Index of Kernel Configuration Options
I'm not currently on the lkml list here, so I apologize if my cut and past reply messes up someone's threaded mail reader. AJF75 wrote: >Does anyone know whereabouts I could go to get an index of all >configurations options (i.e. drivers, etc.) that are available in the >latest Linux kernel? I am waiting on a kernel mode driver for my USB >digital camera, but I don't want to go ahead and download the full 24Mb >just to find out if the support is available yet. Here is a script which will print out all the kernel configuration options found in config.in or Config.in files. If you put this script in the scripts directory, run it with sh scripts/options_linux (suggested name). It should be run from the top of the tree, e.g. /usr/src/linux. For example, to find all the USB options, sh scripts/options_linux | grep USB Due to tab/space munging, I'll have to attach the script. Hope this helps. Of course, you'll still have to get the whole kernel, which is what you were trying to avoid in the first place. ;) Steven options_linux
