Re: net: prevent of emerging cross-namespace symlinks patches for 3.14
On 14/01/15 22:07, Greg KH wrote: For networking patches, can you cc: netdev and get an ack from the networking maintainer for me to be able to apply them? Done, and sorry for the sta...@kernel.org bounce. Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
net: prevent of emerging cross-namespace symlinks patches for 3.14
When running 'lxc' on the latest -stable kernel, 3.14.28, I'm seeing these errors: Jan 14 17:47:16 lxc2 kernel: [ 10.704890] WARNING: CPU: 0 PID: 3209 at fs/sys fs/dir.c:52 sysfs_warn_dup+0x8c/0xb0() Jan 14 17:47:16 lxc2 kernel: [ 10.704892] sysfs: cannot create duplicate filename '/devices/virtual/net/eth0.104/upper_eth0' Jan 14 17:47:16 lxc2 kernel: [ 10.704954] CPU: 0 PID: 3209 Comm: lxc-autostart Not tainted 3.14.28-xsserver #1 I did not see these errors in 3.12. This was fixed in 3.17 by: net: prevent of emerging cross-namespace symlinks https://github.com/torvalds/linux/commit/4c75431ac3520631f1d9e74aa88407e6374dbbc4 net: fix creation adjacent device symlinks https://github.com/torvalds/linux/commit/7ce64c79c4decdeb1afe0bf2f6ef834b382871d1 These patches apply cleanly to 3.14.28. I think this should go into 3.14-stable. Thanks, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does init start with any open files?
In article you write: >When the init process is created on system startup, does it have any >open file descriptors? If so, where do they point? 0, 1 and 2, which are connected to the console. Boot a kernel with "init=/bin/bash" and see for yourself. Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT to md raid 6 is slow
On 08/20/2012 01:34 AM, Stan Hoeppner wrote: I'm glad you jumped in David. You made a critical statement of fact below which clears some things up. If you had stated it early on, before Miquel stole the thread and moved it to LKML proper, it would have short circuited a lot of this discussion. Which is: I'm sorry about that, that's because of the software that I use to follow most mailinglist. I didn't notice that the discussion was cc'ed to both lkml and l-r. I should fix that. Thus my original statement was correct, or at least half correct[1], as it pertained to md/RAID6. Then Miquel switched the discussion to md/RAID5 and stated I was all wet. I wasn't, and neither was Dave Chinner. I was simply unaware of this md/RAID5 single block write RMW shortcut Well, all I tried to say is that a small write of, say, 4K, to a raid5/raid6 array does not need to re-write the whole stripe (i.e. chunksize * nr_disks) but just 4K * nr_disks, or the RMW variant of that. Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT to md raid 6 is slow
On 08/17/2012 09:31 AM, Stan Hoeppner wrote: On 8/16/2012 4:50 PM, Miquel van Smoorenburg wrote: I did a simple test: * created a 1G partition on 3 seperate disks * created a md raid5 array with 512K chunksize: mdadm -C /dev/md0 -l 5 -c $((1024*512)) -n 3 /dev/sdb1 /dev/sdc1 /dev/sdd1 * ran disk monitoring using 'iostat -k 5 /dev/sdb1 /dev/sdc1 /dev/sdd1' * wrote a single 4K block: dd if=/dev/zero bs=4K count=1 oflag=direct seek=30 of=/dev/md0 Output from iostat over the period in which the 4K write was done. Look at kB read and kB written: Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sdb1 0.60 0.00 1.60 0 8 sdc1 0.60 0.80 0.80 4 4 sdd1 0.60 0.00 1.60 0 8 As you can see, a single 4K read, and a few writes. You see a few blocks more written that you'd expect because the superblock is updated too. I'm no dd expert, but this looks like you're simply writing a 4KB block to a new stripe, using an offset, but not to an existing stripe, as the array is in a virgin state. So it doesn't appear this test is going to trigger RMW. Don't you need now need to do another write in the same stripe to to trigger RMW? Maybe I'm just reading this wrong. That shouldn't matter, but that is easily checked ofcourse, by writing some random random data first, then doing the dd 4K write also with random data somewhere in the same area: # dd if=/dev/urandom bs=1M count=3 of=/dev/md0 3+0 records in 3+0 records out 3145728 bytes (3.1 MB) copied, 0.794494 s, 4.0 MB/s Now the first 6 chunks are filled with random data, let write 4K somewhere in there: # dd if=/dev/urandom bs=4k count=1 seek=25 of=/dev/md0 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 0.10149 s, 40.4 kB/s Output from iostat over the period in which the 4K write was done: Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sdb1 0.60 0.00 1.60 0 8 sdc1 0.60 0.80 0.80 4 4 sdd1 0.60 0.00 1.60 0 8 Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT to md raid 6 is slow
On 16-08-12 1:05 PM, Stan Hoeppner wrote: On 8/15/2012 6:07 PM, Miquel van Smoorenburg wrote: Ehrm no. If you modify, say, a 4K block on a RAID5 array, you just have to read that 4K block, and the corresponding 4K block on the parity drive, recalculate parity, and write back 4K of data and 4K of parity. (read|read) modify (write|write). You do not have to do I/O in chunksize, ehm, chunks, and you do not have to rmw all disks. See: http://www.spinics.net/lists/xfs/msg12627.html Dave usually knows what he's talking about, and I didn't see Neil nor anyone else correcting him on his description of md RMW behavior. Well he's wrong, or you're interpreting it incorrectly. I did a simple test: * created a 1G partition on 3 seperate disks * created a md raid5 array with 512K chunksize: mdadm -C /dev/md0 -l 5 -c $((1024*512)) -n 3 /dev/sdb1 /dev/sdc1 /dev/sdd1 * ran disk monitoring using 'iostat -k 5 /dev/sdb1 /dev/sdc1 /dev/sdd1' * wrote a single 4K block: dd if=/dev/zero bs=4K count=1 oflag=direct seek=30 of=/dev/md0 Output from iostat over the period in which the 4K write was done. Look at kB read and kB written: Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sdb1 0.60 0.00 1.60 0 8 sdc1 0.60 0.80 0.80 4 4 sdd1 0.60 0.00 1.60 0 8 As you can see, a single 4K read, and a few writes. You see a few blocks more written that you'd expect because the superblock is updated too. Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: O_DIRECT to md raid 6 is slow
In article you write: >It's time to blow away the array and start over. You're already >misaligned, and a 512KB chunk is insanely unsuitable for parity RAID, >but for a handful of niche all streaming workloads with little/no >rewrite, such as video surveillance or DVR workloads. > >Yes, 512KB is the md 1.2 default. And yes, it is insane. Here's why: >Deleting a single file changes only a few bytes of directory metadata. >With your 6 drive md/RAID6 with 512KB chunk, you must read 3MB of data, >modify the directory block in question, calculate parity, then write out >3MB of data to rust. So you consume 6MB of bandwidth to write less than >a dozen bytes. With a 12 drive RAID6 that's 12MB of bandwidth to modify >a few bytes of metadata. Yes, insane. Ehrm no. If you modify, say, a 4K block on a RAID5 array, you just have to read that 4K block, and the corresponding 4K block on the parity drive, recalculate parity, and write back 4K of data and 4K of parity. (read|read) modify (write|write). You do not have to do I/O in chunksize, ehm, chunks, and you do not have to rmw all disks. >Parity RAID sucks in general because of RMW, but it is orders of >magnitude worse when one chooses to use an insane chunk size to boot, >and especially so with a large drive count. If you have a lot of parallel readers (readers >> disks) then you want chunk sizes of about 2*mean_read_size, so that for each read you just have 1 seek on 1 disk. If you have just a few readers (readers disks) that read really large blocks then you want a small chunk size to keep all disks busy. If you have no readers and just writers and you write large blocks, then you might want a small chunk size too, so that you can write data+parity over the stripe in one go, bypassing rmw. Also, 256K or 512K isn't all that big nowadays, there's not much latency difference between reading 32K or 512K.. >Recreate your array, partition aligned, and manually specify a sane >chunk size of something like 32KB. You'll be much happier with real >workloads. Aligning is a good idea, and on modern distributions partitions, LVM lv's etc are generally created with 1MB alignment. But using a small chunksize like 32K? That depends on the workload, but in most cases I'd advise against it. Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
In article <[EMAIL PROTECTED]>,
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
>On Jan 3 2008 13:43, [EMAIL PROTECTED] wrote:
>>
>>hi !
>>
>>i was wondering how to make kernel messages appear on /dev/ttyS0
>without a reboot, i.e. kernelparam "console=ttyS0"
>
>The solution is simple... the following piece of code is inside
>opensuse-10.3/src/sysvinit-2.86-115.src.rpm#showconsole-1.08.tar.bz2#showconsole-1.08/blogd.c
>
>(void)ioctl(0, TIOCCONS, NULL); /* Undo any current map if any */
>if (ioctl(pts, TIOCCONS, NULL) < 0)
>error("can not set console device to %s: %s\n", ptsname,
>strerror(errno));
>
>so I suppose that's it. Write up a new program that calls the ioctl
>on a tty, and you should be done. IOW:
TIOCCONS only works for pseudo terminals.
Besides, it only redirects stuff you send to /dev/console. It
doesn't change what devices printk() prints to. Currently there
is no way to change that on a running kernel.
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/
[PATCH] dpt_i2o: don't set DMA_64BIT_MASK [was: Re: [stable] broken dpt_i2o in 2.6.23 (was: ext2 check page: bad entry in directory) (fwd)]
According to Greg KH: > So, what should be added to 2.6.23-stable then? And, can I get a real > changelog entry for it? This is suitable for both 2.6.23.x and 2.6.24-rc5 : linux-2.6-dpt_i2o-no-dma64.patch The dpt_i2o driver can't handle 64 bit DMA addresses, so do not let it set pci_set_dma_mask(pDev, DMA_64BIT_MASK) . Signed-off-by: Miquel van Smoorenburg <[EMAIL PROTECTED]> diff -ruN linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c linux-2.6.23.9/drivers/scsi/dpt_i2o.c --- linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c 2007-11-26 18:51:43.0 +0100 +++ linux-2.6.23.9/drivers/scsi/dpt_i2o.c 2007-12-12 13:21:05.0 +0100 @@ -905,8 +905,7 @@ } pci_set_master(pDev); - if (pci_set_dma_mask(pDev, DMA_64BIT_MASK) && - pci_set_dma_mask(pDev, DMA_32BIT_MASK)) + if (pci_set_dma_mask(pDev, DMA_32BIT_MASK)) return -EINVAL; base_addr0_phys = pci_resource_start(pDev,0); -- 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: broken dpt_i2o in 2.6.23 (was: ext2 check page: bad entry in directory) (fwd)
On Wed, 2007-12-12 at 03:38 -0800, Andrew Morton wrote: > On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I'd like to let you now that my boxes are running a 32-bit kernel, so > > the 64-bit-uncleanliness shouldn't apply to my boxes; however, > > > > http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch > > > > fixed the issue on my testbox. > > > > I took a clean 2.6.23, applied patch, recompiled the kernel, reboot: works. > > What a huge patch :( > > We already reverted the offening patch so I assume that 2.6.24-rc5 is > working for you? > > I guess we need to look at restoring "dpt_i2o: convert to SCSI hotplug > model" and then absorbing what Miquel has done there. This was just a patch I had lying around, if it worked it would confirm my suspicion, which it has. The minimal patch which is suitable for 2.6.23-stable and 2.6.24 would be the attached one-liner. The "dpt_i2o: convert to SCSI hotplug model" patch could be restored then. (if the list eats the attachment, it's also available here: http://www.miquels.cistron.nl/linux/linux-2.6.23+24-dpt_i2o-dma64.patch ) Anders, does this one-liner patch work for you ? Mike. diff -ruN linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c linux-2.6.23.9/drivers/scsi/dpt_i2o.c --- linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c 2007-11-26 18:51:43.0 +0100 +++ linux-2.6.23.9/drivers/scsi/dpt_i2o.c 2007-12-12 13:21:05.0 +0100 @@ -905,8 +905,7 @@ } pci_set_master(pDev); - if (pci_set_dma_mask(pDev, DMA_64BIT_MASK) && - pci_set_dma_mask(pDev, DMA_32BIT_MASK)) + if (pci_set_dma_mask(pDev, DMA_32BIT_MASK)) return -EINVAL; base_addr0_phys = pci_resource_start(pDev,0);
Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
On Tue, 2007-12-11 at 15:40 +0100, Miquel van Smoorenburg wrote: > I just noticed the same bug when I tried to update a 2.6.18 server to > 2.6.23.9 .. also tried 2.6.24-rc4. The symptom I'm seeing is that init > segfaults, or can't be found .. anyway, driver/fs errors. > > In the kernel config, under "processor type and features", I disabled > "64GB memory" support (changed to 4GB) and I also disabled "64 bit > Memory and IO resources" and the problem went away. Do you by any chance > happen to have those features enabled ? > > The dpt_i2o driver is not 64-bit clean, it happens to work with > PAE/64-bit dma in earlier kernels but that might be by chance. Perhaps > the different initialization ordering exposes the problem. > > I got the 64-bit dpt_i2o driver from Adaptec some time ago, and I have > added 64-bit support to the 2.6.23.1 dpt_i2o driver based on that > driver. I intended to submit it for 2.6.25 or so ... if I have some time > later today or tomorrow I'll try that next to see if that makes a > difference. I just recompiled 2.6.23.9 with the 64 bit patch for dpt_i2o and now it boots just fine. The patch is here: http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch It's not the final version - it needs a few cleanups before it can be submitted, but perhaps you can test if it also works for you. 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: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory) (fwd)
On Fri, 2007-11-30 at 11:34 +0100, Anders Henke wrote: > Am 30.11.2007 schrieb FUJITA Tomonori: > > > > > According to the 2.6.23-rc1 short-form changelog, there is > > > > > one major edit on the dpt_i2o driver: > > > > > > > > > > FUJITA Tomonori > > > > > > > > > > [SCSI] dpt_i2o: convert to use the data buffer accessors > > > > > > > > > > Stephen Rothwell > > > > > dpt_i2o depends on virt_to_bus > > > > > > > > > > Fujita, would you please take a look at this? > > > > > > In between, I've ruled out that the static assignment isn't > source of the problem. And due to some manually made "make clean" which > didn't clean enough, I've also pointed out the wrong patch - sorry, > Fujita, definitely the right one which breaks my boxes is the dpt_i2o patch > from 2.6.23-rc2 to 2.6.23-rc3 (7 kb in Size) from Matthew Wilcox. > > commit 55d9fcf57ba5ec427544fca7abc335cf3da78160 > Author: Matthew Wilcox <[EMAIL PROTECTED]> > Date: Mon Jul 30 15:19:18 2007 -0600 > > [SCSI] dpt_i2o: convert to SCSI hotplug model I just noticed the same bug when I tried to update a 2.6.18 server to 2.6.23.9 .. also tried 2.6.24-rc4. The symptom I'm seeing is that init segfaults, or can't be found .. anyway, driver/fs errors. In the kernel config, under "processor type and features", I disabled "64GB memory" support (changed to 4GB) and I also disabled "64 bit Memory and IO resources" and the problem went away. Do you by any chance happen to have those features enabled ? The dpt_i2o driver is not 64-bit clean, it happens to work with PAE/64-bit dma in earlier kernels but that might be by chance. Perhaps the different initialization ordering exposes the problem. I got the 64-bit dpt_i2o driver from Adaptec some time ago, and I have added 64-bit support to the 2.6.23.1 dpt_i2o driver based on that driver. I intended to submit it for 2.6.25 or so ... if I have some time later today or tomorrow I'll try that next to see if that makes a difference. 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: F_DUPFD_CLOEXEC implementation
In article <[EMAIL PROTECTED]>, Denys Vlasenko <[EMAIL PROTECTED]> wrote: >Hi Ulrich, > >On Friday 28 September 2007 18:34, Ulrich Drepper wrote: >> One more small change to extend the availability of creation of >> file descriptors with FD_CLOEXEC set. Adding a new command to >> fcntl() requires no new system call and the overall impact on >> code size if minimal. > >Tangential question: do you have any idea how userspace can >safely do nonblocking read or write on a potentially-shared fd? > >IIUC, currently it cannot be done without races: > >old_flags = fcntl(fd, F_GETFL); >...other process may change flags!... >fcntl(fd, F_SETFL, old_flags | O_NONBLOCK); >read(fd, ...) >...other process may see flags changed under its feet!... >fcntl(fd, F_SETFL, old_flags); > >Can this be fixed? This is for sockets, right ? Just use revc() instead of read(). n = recv(filedesc, buffer, buflen, MSG_DONTWAIT); .. is equivalent to setting O_NONBLOCK. See "man recv". 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: 2.6.22-rc2 and libata/shutdown
In article <[EMAIL PROTECTED]> you write: >Hello Damien, people... > >Damien Wyart wrote: >> Hello, >> >> After trying 2.6.22-rc2, I noticed the warning message from libata about >> upgrading shutdown(8). First, I have two SATA disks, and get the warning for >> only one of them. Second, I double-checked the source of shutdown for my >> distro (Debian unstable), and do not see anything related to issueing >> STANDBYNOW. > >The warning is pretty important, and you can check it at > >http://linux-ata.org/shutdown.html > >I have been checking the sysvinit sources and I cannot see the portions >on scanning SCSI or SATA >disks. I only see the IDE scanning and standby-related code at >src/hddown.c. Does anybody know >how in the world are the SATA disks put to sleep in userspace? Standard sysvinit doesn't do this, but many distributions have patched it so that it does. Debian has patched it as well; if you unpack the debian sources you won't see it right away though. The extra patches are applied by the build process, patches are under debian/ 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: Routing 600+ vlan's via linux problems (looks like arp problems)
In article <[EMAIL PROTECTED]> you write: >Its a Juniper M7i >It comes default with a 5400 rpm laptop 2.5" harddrive but now we >bought a more robust "server" 2.5" harddrive. It still barfs on the OS >install, so the linux is doing all the job now. Will get a juniper guy >to come and fix :) > >As a side note, i'm starting to wonder if it was worth the $20k when i >could just have a linux machine to do the job with a clone for backup >;) Well, the features and esp. the JunOS cli are worth a lot. And if you need to route more than say 3 gbit/s, PC hardware just won't cut it. Then again, if you like the CLI, don't need to route more than 1 gbit/s, and don't need to do fancy stuff like MPLS, QoS or shaping, there's always solutions like http://www.vyatta.com/ 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: [PATCH 0/5] fallocate system call
In article <[EMAIL PROTECTED]> you write: >On May 02, 2007 18:23 +0530, Amit K. Arora wrote: >> On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote: >> > On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote: >> > >> > > For FA_ALLOCATE, it's supposed to change the file size if we >> > > allocate past EOF, right? >> > >> > I would argue no. Use truncate for that. >> >> The patch I posted for ext4 *does* change the filesize after >> preallocation, if required (i.e. when preallocation is after EOF). >> I may have to change that, if we decide on not doing this. > >I think I'd agree - it may be useful to allow preallocation beyond EOF >for some kinds of applications (e.g. PVR preallocating live TV in 10 >minute segments or something, but not knowing in advance how long the >show will actually be recorded or the final encoded size). I have an application (diablo dreader) where the header-info database basically consists of ~40.000 files, one for each group (it's more complicated that that, but never mind that now). If you grow those files randomly by a few hundred bytes every update, the filesystem gets hopelessly fragmented. I'm using XFS with preallocation turned on, and biosize=18 (which makes it preallocate in blocks of 256KB), and a homebrew patch that leaves the preallocated space on disk preallocated even if the file is closed .. and it helps enormously. 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: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
In article <[EMAIL PROTECTED]> you write: >I was actually _really_ hoping that somebody would come along and tell >everybody that this whole journal-logging is stupid, and that it's just >better to not ever re-write blocks on disk, but instead write to new >blocks with version numbers (and not re-use old blocks until new versions >are stable on disk). > >There was even somebody who did something like that for a PhD thesis, I >forget the details (and it apparently died when the thesis was presumably >accepted ;). If you mean tux2, it died because of patent issues: http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html 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: [QUESTION] file access time in millisecond?
In article <[EMAIL PROTECTED]>, Jeff Chua <[EMAIL PROTECTED]> wrote: >On 12 Feb 2007 10:02:28 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > >> > stat() returns time in seconds, >> >> Not correct (at least for glibc stat). It supports nanoseconds these days, >> although not all file systems (including ext3) do yet. > >I'm using gcc-3.4.5, and glibc-2.3.6. Don't think 2.3.6 stat() support >that ... at least the man page doesn't indicate so. Check out /usr/include/bits/stat.h My glibc-2.3.2 (debian stable) has the nanoseconds stuff right there, even though it isn't mentioned in the stat.2 manpage or the info pages. 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: cfq performance gap
In article <[EMAIL PROTECTED]>, Chen, Kenneth W <[EMAIL PROTECTED]> wrote: >Miquel van Smoorenburg wrote on Wednesday, December 13, 2006 1:57 AM >> Chen, Kenneth W <[EMAIL PROTECTED]> wrote: >> >This rawio test plows through sequential I/O and modulo each small record >> >over number of threads. So each thread appears to be non-contiguous within >> >its own process context, overall request hitting the device are sequential. >> >I can't see how any application does that kind of I/O pattern. >> >> A NNTP server that has many incoming connections, handled by >> multiple threads, that stores the data in cylic buffers ? > >Then whichever the thread that dumps the buffer content to the storage >will do one large contiguous I/O. In this context, "cyclic buffer" means "large fixed-size file" or "disk partition", and when the end of that file/partition is reached, writing resumes at the start (wraps around, starts the next cycle). Each thread writes an article to disk, which can differ in size from 1K to 1M. The writes all together are sequential, but the writes from one thread are definitely not. This is a real-world example - I have written software that does exactly this, multithreaded versions of INN exist that with CNFS storage does exactly this, and Diablo does something comparable (only it uses processes instead of threads). 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: cfq performance gap
In article <[EMAIL PROTECTED]>, Chen, Kenneth W <[EMAIL PROTECTED]> wrote: >This rawio test plows through sequential I/O and modulo each small record >over number of threads. So each thread appears to be non-contiguous within >its own process context, overall request hitting the device are sequential. >I can't see how any application does that kind of I/O pattern. A NNTP server that has many incoming connections, handled by multiple threads, that stores the data in cylic buffers ? 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: [PATCH] emit logging when a process receives a fatal signal
In article <[EMAIL PROTECTED]>, Oleg Verych <[EMAIL PROTECTED]> wrote: >On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote: >> > > > I found that sometimes processes disappear on some heavily used system >> > > > of mine without any logging. So I've written a patch against 2.6.18.2 >> > > > which emits logging when a process emits a fatal signal. >> > > Why not to patch default signal handlers in glibc, to have not only >> > > stderr, but syslog, or /dev/kmsg copy of fatal messages? >> > Afaik when a proces gets shot because of a segfault, also the libraries >> > it used are shot so to say. iirc some of the more fatal signals are >> > handled directly by the kernel. > >Kernel sends signals, no doubt. > >Then, who you think prints that "Killed" or "Segmentation fault" >messages in *stderr*? >[Hint: libc's default signal handler (man 2 signal).] There is no such thing as a "libc default signal handler". [Hint: waitpid (man 2 waitpid).] 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: Multi-threaded IO performance regression on 2.6 kernel?
In article <[EMAIL PROTECTED]>, Xie, Bill <[EMAIL PROTECTED]> wrote: >All, > >I am testing the multi-threaded IO performance on Opteron servers. > >I use dd as the test tools. The single dd can reach 60MBps for single disk. > >on 2.6.5 kernel, If dd numbers exceed the CPU numbers, vmstat bi reduced >to 20MBps. > >on 2.4.21 kernel, multi-threaded IO performance works fine, even I run >40 dd command at same time. > >Does anybody experienced similar issue also? First, use a more recent kernel, 2.6.11.x or 2.6.12.x. Then try if changing the I/O scheduler (/sys/block/sda/queue/scheduler) to deadline or cfq makes a difference. I'm using 2.6.11.x and the cfq scheduler on most servers right now. 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: a 15 GB file on tmpfs
In article <[EMAIL PROTECTED]>, Erik Mouw <[EMAIL PROTECTED]> wrote: >On Wed, Jul 20, 2005 at 02:16:36PM +0200, Bastiaan Naber wrote: >> I have a 15 GB file which I want to place in memory via tmpfs. I want to do >> this because I need to have this data accessible with a very low seek time. > >That should be no problem on a 64 bit architecture. > >AFAIK you can't use a 15 GB tmpfs on i386 because large memory support >is basically a hack to support multiple 4GB memory spaces (some VM guru >correct me if I'm wrong). I'm no VM guru but I have a 32 bit machine here with 8 GB of memory and 8 GB of swap: # mount -t tmpfs -o size=$((12*1024*1024*1024)) tmpfs /mnt # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 19228276 1200132 17051396 7% / tmpfs 12582912 0 12582912 0% /mnt There you go, a 12 GB tmpfs. I haven't tried to create a 12 GB file on it, though, since this is a production machine and it needs the memory .. So yes that appears to work 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: Instruction Tracing for Linux
In article <[EMAIL PROTECTED]>, Adnan Khaleel <[EMAIL PROTECTED]> wrote: >Thanks for your suggestions. I have been working with Simics, SimNow and >Bochs. I've had mixed luck with all of them. Although Simics should be >the most promising, I've really had >an uphill struggle with it especially when it comes to x86-64. I've been >playing around with Bochs and most likely will end up using that but it >has its drawbacks as well. > >Even if I can't trace the kernel, is there anything available for just >the user space stuff? You might be able to get valgrind or cachegrind to do what you need.. 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: reiser4 plugins
In article <[EMAIL PROTECTED]>, David Masover <[EMAIL PROTECTED]> wrote: >Markus Törnqvist wrote: >> Anyway, I don't really like the metafs thing. >> >> To access the data, you still need to refactor userspace, >> so that's not a real advantage. Doing lookups from /meta >> all the time, instead of in the file-as-dir-whatever... > >I don't really see the disadvantage. > >Also, metafs means much less of a fight to get people to adopt the whole >meta concept, because it can be done in a POSIX-compliant way which >doesn't break tar. > >File-as-dir is nice if you're using meta files, but it causes lots of >unexpected weirdness. I don't think metafs costs us much in >performance, and with one or two shell scripts, it wouldn't cost us that >much efficiency on the commandline. file-as-dir is an innovation. Metafs is an ugly compromise. 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: [PATCH x86_64] Live Patching Function on 2.6.11.7
In article <[EMAIL PROTECTED]>, Takashi Ikebe <[EMAIL PROTECTED]> wrote: >Chris Wedgwood wrote: >> On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:> >> >>>To takeover the application status, connection type >>>communications(SOCK_STREAM) are need to be disconnected by close(). >>>Same network port is not allowed to bind by multiple processes >> >> >> AF_UNIX socket with SCM_RIGHTS >> >hmm.. most internet base services will use TCPv4 TCPv6 SCTP... >AF_UNIX can not use as inter-nodes communication. No, Chris means filedescriptor passing. You can pass any existing open filedescriptor to another process using an AF_UNIX socket. For example, the existing running process creates a UNIX socket in /var/run/mysocket that the new process can connect() to. The processes can then not only exchange all kinds of information, the old process can even send open filedescriptors over to the new process without closing/re-opening. See "man 7 unix", ANCILLARY MESSAGES -> SCM_RIGHTS ANCILLARY MESSAGES Ancillary data is sent and received using sendmsg(2) and recvmsg(2). For historical reasons the ancillary message types listed below are specified with a SOL_SOCKET type even though they are PF_UNIX specific. To send them set the cmsg_level field of the struct cmsghdr to SOL_SOCKET and the cmsg_type field to the type. For more information see cmsg(3). SCM_RIGHTS Send or receive a set of open file descriptors from another pro- cess. The data portion contains an integer array of the file descriptors. The passed file descriptors behave as though they have been created with dup(2). 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: Adaptec 2010S i2o + x86_64 doesn't work
On Fri, 2005-04-15 at 15:52 +0100, Alan Cox wrote: > On Mer, 2005-04-13 at 17:03, Miquel van Smoorenburg wrote: > > I have a supermicro dual xeon em64t system, X6DH8-XG2 motherboard, > > 4 GB RAM, with an Adaptec zero raid 2010S i2o controller. In 32 > > bits mode it runs fine, both with the dpt_i2o driver and the > > generic i2o_block driver using kernel 2.6.11.6. > > Does it work if you drop the box to 2Gbytes ? I tried 2.6.9 with 4GB and it didn't make any difference. However, I removed 2 GB from the box as Alan sugggested and now the box comes up just fine with a 64-bit 2.6.11.6 kernel! I've put the 4GB back, and booted with the kernel "mem=2048" command line option - that also works, the i2o_block driver sees the adaptec controller just fine. And I just booted it with "mem=3840M" and that works too. So the problem appears to be 4 GB memory in 64 bit mode, on this box. 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/
Adaptec 2010S i2o + x86_64 doesn't work
I have a supermicro dual xeon em64t system, X6DH8-XG2 motherboard,
4 GB RAM, with an Adaptec zero raid 2010S i2o controller. In 32
bits mode it runs fine, both with the dpt_i2o driver and the
generic i2o_block driver using kernel 2.6.11.6.
In 64 bits mode however the dpt_i2o driver isn't supported, so
you have to use the generic i2o layer. But that doesn't work
either - sometimes when booting the partition table is detected,
sometimes it isn't. If it isn't, then fdisk /dev/i2o/hda works
but shows an empty disk (while there definitely are partitions
present).
In both cases doing a dd if=/dev/i2o/hda of=/dev/null crashes
the system.
According to http://i2o.shadowconnect.com/ , it should work.
I've upgraded the BIOS and firmware of the mobo and controller to
the latest versions - doesn't help. Can someone suggest what to
try next ?
Bootlog:
I2O subsystem v$Rev$
i2o: max drivers = 8
i2o: Checking for PCI I2O controllers...
ACPI: PCI interrupt :02:01.0[A] -> GSI 24 (level, low) -> IRQ 24
i2o: I2O controller found on bus 2 at 8.
iop0: PCI I2O controller
BAR0 at 0xD820 size=1048576
BAR1 at 0xDB00 size=16777216
iop0: using write combining MTRR
iop0: Installed at IRQ 24
iop0: Activating I2O controller...
iop0: This may take a few minutes if there are many devices
iop0: HRT has 1 entries of 16 bytes each.
Adapter 0012: <7>TID :[<7>H<7>P<7>C<7>*<7>]:<7>PCI 1: Bus 1 Device 22
Function 0<7>
iop0: Controller added
I2O Configuration OSM v$Rev$
I2O Block Device OSM v$Rev$
block-osm: New device detected (TID: 205)
i2o/hda: unknown partition table
I2O ProcFS OSM v$Rev$
Kernel panic:
general protection fault: [1] SMP
CPU 3
Modules linked in: ipv6 af_packet i2c_i801 i2c_core hw_random ehci_hcd uhci_hcd
piix e1000 ide_disk ide_cd ide_core cdrom unix
Pid: 0, comm: Not tainted 2.6.11.6
RIP: 0010:[] {kmem_cache_free+36}
RSP: :8100062fbdc8 EFLAGS: 00010092
RAX: 0003 RBX: 02d083c728244403 RCX: 8100062d0f00
RDX: RSI: 81013ddc9bd8 RDI: 8100062a5780
RBP: 81013ddc9bd8 R08: 0002 R09: 0005
R10: R11: 8015070d R12: 81013e933318
R13: 81013fdc8be8 R14: 81013fe02480 R15: 8100bfd9
FS: () GS:8046b280() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 557ec000 CR3: 00013df12000 CR4: 06e0
Process (pid: 0, threadinfo , task 810006280030)
Stack: 0092 8100bfd9 81013ddc9bd8 80286dd2
81013fdc8be8 8100bfd9 8100062d0e40
8100062ce800 8027de7c
Call Trace: {cfq_put_request+172}
{__blk_put_request+135}
{end_that_request_last+243}
{i2o_block_reply+674}
{i8042_timer_func+0}
{i2o_driver_dispatch+95}
{i2o_pci_interrupt+102}
{handle_IRQ_event+41}
{__do_IRQ+244} {do_IRQ+67}
{ret_from_intr+0}
{mwait_idle+86}
{cpu_idle+58}
Code: 8b 03 3b 43 04 73 04 89 c0 eb 0a 48 89 de e8 08 03 00 00 8b
RIP {kmem_cache_free+36} RSP
<1>Unable to handle kernel NULL pointer dereference at 0018 RIP:
{resched_task+15}
PGD 13d8b7067 PUD 13da18067 PMD 0
Oops: [2] SMP
CPU 3
Modules linked in: ipv6 af_packet i2c_i801 i2c_core hw_random ehci_hcd uhci_hcd
piix e1000 ide_disk ide_cd ide_core cdrom unix
Pid: 0, comm: Not tainted 2.6.11.6
RIP: 0010:[] {resched_task+15}
RSP: :8100062fbbc0 EFLAGS: 00010002
RAX: 8049e5c0 RBX: 0001 RCX: 206e87834500
RDX: 206e RSI: RDI: 810006280030
RBP: 8100062fbbc0 R08: 81013f1c7b40 R09: 0001
R10: R11: R12: 810005636520
R13: R14: 81013fe02480 R15: 0003
FS: () GS:8046b280() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 0018 CR3: 00013df12000 CR4: 06e0
Process (pid: 0, threadinfo , task 810006280030)
Stack: 8100062fbc00 8012a5aa 81013fe02480 80340467
8100062fbd18 81013fe02480 8100bfd9
8100062fbd18 801175ed
Call Trace: {scheduler_tick+115}
{smp_apic_timer_interrupt+61}
{show_stack+260}
{apic_timer_interrupt+99}
{oops_end+40} {oops_end+33}
{die+59} {do_general_protection+268}
{error_exit+0} {mempool_free_slab+0}
{kmem_cache_free+36}
{cfq_put_request+172}
{__blk_put_request+135}
{end_that_request_last+243}
{i2o_block_reply+674}
{i8042_timer_func+0}
{i2o_driver_dispatch+95}
{i2o_pci_interrupt+102}
{handle_IRQ_event+41} {__do_IRQ+244}
{do_IRQ+67} {ret_from_intr+0}
{mwait_idle+86} {cpu_idle+58}
Code: 8b 56 18 48 c1 e2 07 48 03 82 08 b1 46 80 0f b6 00 84 c0 3e
RIP {resched_task+15} RSP
CR2: 0018
Re: [PATCH] CON_CONSDEV bit not set correctly on last console
In article <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]> wrote: >Greg Edwards <[EMAIL PROTECTED]> wrote: >> >> According to include/linux/console.h, CON_CONSDEV flag should be set on >> the last console specified on the boot command line: >> >> 86 #define CON_PRINTBUFFER (1) >> 87 #define CON_CONSDEV (2) /* Last on the command line */ >> 88 #define CON_ENABLED (4) >> 89 #define CON_BOOT(8) >> >> This does not currently happen if there is more than one console specified >> on the boot commandline. Instead, it gets set on the first console on the >> command line. This can cause problems for things like kdb that look for >> the CON_CONSDEV flag to see if the console is valid. >> >> Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next >> preferred console at unregister time if the console being unregistered >> currently has that bit set. >> >> Example (from sn2 ia64): >> >> elilo vmlinuz root= console=ttyS0 console=ttySG0 >> >> in this case, the flags on ttySG console struct will be 0x4 (should be >> 0x6). >> >> Attached patch against bk fixes both issues for the cases I looked at. It >> uses selected_console (which gets incremented for each console specified >> on the command line) as the indicator of which console to set CON_CONSDEV >> on. When adding the console to the list, if the previous one had >> CON_CONSDEV set, it masks it out. Tested on ia64 and x86. > >The `console=a console=b' behaviour seem basically random to me :(. And it >gets re-randomised on a regular basis. Well, on the other hand the last registered console is the one that connects to /dev/console and that has never changed afaik (and it shouldn't, many setups rely on it). 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/
syslogd hang / livelock (was: 2.6.10-rc3, syslogd hangs then processes get stuck in schedule_timeout)
References: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103392 http://lkml.org/lkml/2004/12/21/208 http://lkml.org/lkml/2004/11/2/17 At Tue, 21 Dec 2004 16:39:43 -0800 (PST) Chris Stromsoe wrote: > I'm still seeing this problem. It repeats every week or week and a half, > usually after logs have been rotated and a dvd has been written. syslogd > stops writing output, then everything that does schedule_timeout() hangs, > the process table fills, and everything grinds to a halt. > > If the problem is detected early enough, syslogd can be manually killed > and restarted, unwedging everything and returning everything to normal > operation. I'm seeing the same problem here, and it is not a kernel bug. I'm only Cc'ing this to linux-kernel so that it shows up in the archives, since there have been postings about the same thing in the past. There are 2 issues here: 1. syslogd hangs sometimes when running under a 2.6 kernel. This is because syslogd set up a timer, called by alarm() every 20 minutes by default, which writes a "MARK" entry in one of the logfiles to show that syslogd is still alive. That code calls ctime(), which is not re-entrant - and recent glibcs __libc_lock() around ctime() calls, which doesn't do anything on a 2.4 kernel, but uses a futex on a 2.6 kernel. So if syslogd happens to be inside ctime() in the main routine, SIGALRM hits, and ctime() is called again, syslogd locks up. A sysrq-T trace will show it hanging in futex_wait. 2. syslog() uses blocking AF_UNIX SOCK_DGRAM sockets. When an application calls syslog(), and syslogd is not responding and the socket buffers get full, the app will hang in connect() or send(). This is different from BSD, where send() will return ENOBUFS in this case. Try killall -STOP syslogd, then generate some syslog traffic (say with while :; do logger hello; done) and try to ssh into the system - no go. Everything that uses syslog() hangs. Solutions: 1. syslogd Run syslogd with the -m0 option so that it won't do MARKing. The real solution is to fix syslogd to use ctime_r, or better, to just let the ALRM handler set a flag and do the MARK logging in the main loop. 2. syslog() Arguably syslog() shouldn't hang like it does now. But making it non-blocking could lead to information loss - a hacker generating lots of bogus syslog messages so that real messages get lost. On the other hand, she can do that anyway and fill up the disk which gives a similar (although more noticable) effect. I'm not sure how or if this should be fixed. 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: 2.6.11: iostat values broken ?
On Mon, 21 Mar 2005 23:09:42, Andrew Morton wrote: > "Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote: > > > > I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I > > use "iostat -k -x 2" to see live how busy the disks are. But > > I don't believe that Linux optimizes things so much that a disk > > can be 1849.55% busy :) > > > > (you'll have to stretch out your xterm to be able to read this): > > > > Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s > > avgrq-sz avgqu-sz await svctm %util > > hda 0.00 50.00 0.00 18.180.00 545.45 0.00 272.73 > > 30.00 2.35 129.00 86.25 156.82 > > hdc 0.00 45.45 77.27 31.82 3927.27 618.18 1963.64 309.09 > > 41.67 6.27 57.42 38.42 419.09 > > hdd 4.55 0.00 63.64 0.00 68.180.0034.09 0.00 > > 1.07 1.11 17.43 17.43 110.91 > > hde477.27 0.00 45.45 0.00 522.730.00 261.36 0.00 > > 11.50 0.408.90 8.90 40.45 > > hdg 18.18 70154.55 22.73 172.73 40.91 70727.2720.45 35363.64 > > 362.07 1010.36 1127.72 94.63 1849.55 > > > > With 2.6.9, %util never came above 100% (and that was indeed "fully loaded". > > I have systems with a comparable load running 2.6.10 and 2.6.11-rc3-bk4 > > that also don't show this behaviour (but those are SCSI, not IDE). > > > > I use CFQ, but changing that to deadline doesn't make a difference. > > > > Mike, did you ever get to the bottom of this? Still happening in 2.6.12-rc1? Sortof... (I already posted this before:) the siimage.c driver was broken for me with 2.6.11. Lots of IDE warning messages to /dev/console @ 9600 baud also makes things slow and weird. I couldn't find what caused this, though, there weren't much (if any) changes in siimage.c so it must have been something different. Perhaps the IRQ changes. I moved to sata_sil.c and everything now works fine. I tried sata_sil around 2.6.5 or so, and it was very unstable, but I was pleasantly surprised to see that the new SATA code has come a long way. So I still don't know what the _actual_ problem was, but the solution is "use libata instead of the old IDE driver". As "make menuconfig" tells you something similar it's probably an acceptable solution. 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: Devices/Partitions over 2TB
In article <[EMAIL PROTECTED]>, Berkley Shands <[EMAIL PROTECTED]> wrote: >I have not found any documentation of efforts to overcome the 2TB >partition limit, config LBD bool "Support for Large Block Devices" depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH help Say Y here if you want to attach large (bigger than 2TB) discs to your machine, or if you want to have a raid or loopback device bigger than 2TB. Otherwise say N. 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: 2.6.11: iostat values broken, or IDE siimage driver ?
In article <[EMAIL PROTECTED]>, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote: >In article <[EMAIL PROTECTED]>, >Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote: >>I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I >>use "iostat -k -x 2" to see live how busy the disks are. But >>I don't believe that Linux optimizes things so much that a disk >>can be 1849.55% busy :) > >Perhaps this is the cause: > >Mar 2 19:55:25 hdg: sata_error = 0x, watchdog = 0, >siimage_mmio_ide_dma_test_irq >Mar 2 19:55:26 quantum last message repeated 12 times >hdg: sata_error = 0x, watchdog = 0, siimage_mmio_ide_dma_test_irq I just recompiled and reconfigured with libata sata_sil.c instead of ide siimage.c, and now everything just works fine. I just noticed this in dmesg: ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to [EMAIL PROTECTED] ** so I can fix the driver. .. so perhaps that might causing siimage.c to break, but this being a production server now catching up with a backlog I can't try it right away. 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: 2.6.11: iostat values broken, or IDE siimage driver ?
In article <[EMAIL PROTECTED]>, Rick Lindsley <[EMAIL PROTECTED]> wrote: >Mike -- where did you get your iostat from? There's a couple of different >flavors out there and it may not make a difference but just in case ... Debian, sysstat+5.0.6-4 I know about the iostat problems - there were 32/64 bit issues, etc - but those have been solved in this version. Also the exact same iostat works fine on 2.6.10 and 2.6.11-rc3 kernels. 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: 2.6.11: iostat values broken, or IDE siimage driver ?
In article <[EMAIL PROTECTED]>, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote: >I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I >use "iostat -k -x 2" to see live how busy the disks are. But >I don't believe that Linux optimizes things so much that a disk >can be 1849.55% busy :) > The stats also show 10-30 MB/sec writes to the disks, which make no sense at all. The system feels very slow and (being a usenet news server) can only keep up with about 8 mbit/sec (so it should in this case write 1 MB/sec to all disks combined). Perhaps this is the cause: Mar 2 19:55:25 hdg: sata_error = 0x, watchdog = 0, siimage_mmio_ide_dma_test_irq Mar 2 19:55:26 quantum last message repeated 12 times hdg: sata_error = 0x, watchdog = 0, siimage_mmio_ide_dma_test_irq Mar 2 19:55:57 quantum last message repeated 172 times Mar 2 19:56:58 quantum last message repeated 551 times Mar 2 19:57:59 quantum last message repeated 517 times Mar 2 19:59:00 quantum last message repeated 608 times .. etc etc .. I have a serial console attached, so that probably explains why the system feels so slow when it is spewing these errors (but it doesn't explain the weird iostat values, or does it ?) This is the config: ICH5-SATA: not 100%% native mode: will probe irqs later ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: Maxtor 6Y080L0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: Maxtor 6Y080M0, ATA DISK drive hdd: Maxtor 6Y080M0, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 SiI3112 Serial ATA: IDE controller at PCI slot :03:03.0 ACPI: PCI interrupt :03:03.0[A] -> GSI 19 (level, low) -> IRQ 19 SiI3112 Serial ATA: chipset revision 2 SiI3112 Serial ATA: 100%% native mode on irq 19 ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: Maxtor 6Y080M0, ATA DISK drive ide2 at 0xf8802e80-0xf8802e87,0xf8802e8a on irq 19 Probing IDE interface ide3... hdg: Maxtor 6Y080M0, ATA DISK drive ide3 at 0xf8802ec0-0xf8802ec7,0xf8802eca on irq 19 Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 hda3 < hda5 hda6 hda7 > hdc: max request size: 128KiB hdc: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(33) hdc: cache flushes supported hdc: hdc1 hdc2 hdd: max request size: 128KiB hdd: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(33) hdd: cache flushes supported hdd: hdd1 hde: max request size: 64KiB hde: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63 hde: cache flushes supported hde: hde1 hdg: max request size: 64KiB hdg: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63 hdg: cache flushes supported hdg:<4>hdg: sata_error = 0x, watchdog = 0, siimage_mmio_ide_dma_test_irq hdg1 I've now rebooted to 2.6.9 and that kernel runs 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/
2.6.11: iostat values broken ?
I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I use "iostat -k -x 2" to see live how busy the disks are. But I don't believe that Linux optimizes things so much that a disk can be 1849.55% busy :) (you'll have to stretch out your xterm to be able to read this): Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s avgrq-sz avgqu-sz await svctm %util hda 0.00 50.00 0.00 18.180.00 545.45 0.00 272.7330.00 2.35 129.00 86.25 156.82 hdc 0.00 45.45 77.27 31.82 3927.27 618.18 1963.64 309.0941.67 6.27 57.42 38.42 419.09 hdd 4.55 0.00 63.64 0.00 68.180.0034.09 0.00 1.07 1.11 17.43 17.43 110.91 hde477.27 0.00 45.45 0.00 522.730.00 261.36 0.0011.50 0.408.90 8.90 40.45 hdg 18.18 70154.55 22.73 172.73 40.91 70727.2720.45 35363.64 362.07 1010.36 1127.72 94.63 1849.55 With 2.6.9, %util never came above 100% (and that was indeed "fully loaded". I have systems with a comparable load running 2.6.10 and 2.6.11-rc3-bk4 that also don't show this behaviour (but those are SCSI, not IDE). I use CFQ, but changing that to deadline doesn't make a difference. 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: Network speed Linux-2.6.10
In article <[EMAIL PROTECTED]>, Lee Revell <[EMAIL PROTECTED]> wrote: >On Tue, 2005-03-01 at 12:20 -0800, Ben Greear wrote: >> What happens if you just don't muck with the NIC and let it auto-negotiate >> on it's own? > >This can be asking for trouble too (auto negotiation is often buggy). >What if you hard set them both to 100/full? If you do that you also need to force the switchports to full duplex. Lots of switches default to half-duplex without auto-negotiation. 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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)
In article <[EMAIL PROTECTED]>, Helge Hafting <[EMAIL PROTECTED]> wrote: >Bernd Petrovitsch wrote: >>This would be a win (especially if the numbers are tweked to tune this) >>with a relatively small effort. >>However for real dependencies and parallelism you want the info similar >>to creat a Makefile from it (i.e. the explicit dependency from service X >>to service Y). As a consequence you can get rid of the numbers (since >>they are not needed any more). >> >Now that is a really good idea. Init could simply run "make -j init2" to >enter runlevel 2. A suitable makefile would list all dependencies, and >of course the targets needed for "init2", "init3" and so on. It's not too hard to script it using 'tsort', either. The hard part is getting all the dependencies of the scripts right. And once you've done that, to _keep_ them right. Now how do you implement that on a Debian system that is package-wise somewhere between potato and sarge ... (yes, I've encountered those). Solveable, not trivial. 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: Pipes and fd question. Large amounts of data.
In article <[EMAIL PROTECTED]>, Oded Shimon <[EMAIL PROTECTED]> wrote: >I have implemented this, but it has a major disadvantage - every 'write()' >only write 4k at a time, never more, because of how non-blocking pipes are >done. at 20,000 context switches a second, this method reaches barely 10mb a >second, if not less. If you're using pipe(), you might want to try socketpair() instead. You can setsockopt() SO_RCVBUF and SO_SNDBUF to large values if you want. 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: Make pipe data structure be a circular list of pages, rather
In article <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> wrote: > >On Sat, 15 Jan 2005, Alan Cox wrote: >> >> Alan Cox (the other Alan Cox not me) > >Oh no! You guys are multiplying! http://www.imdb.com/name/nm0184893/ 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: O_DIRECT! or O_DIRECT?
In article <[EMAIL PROTECTED]>, Stephen C. Tweedie <[EMAIL PROTECTED]> wrote: >Hi, > >On Wed, Jul 04, 2001 at 06:27:13PM +, Miquel van Smoorenburg wrote: >> >> Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL)) > >What for? The kernel already optimises readahead and writebehind for >sequential files. Yes, but I really do mean like in madvise(). >If you want to provide specific extra hints to the kernel, then things >like O_UNCACHE might be more appropriate to instruct the kernel to >explicitly remove the cached page after IO completes (to avoid the VM >overhead of maintaining useless cache). That would provide a definite >improvement over normal IO for large multimedia-style files or for >huge copies. But what part of the normal handling of sequential files >would O_SEQUENTIAL change? Good handling of sequential files should >be the default, not an explicitly-requested feature. exactly what I meant, since that is what MADV_SEQUENTIAL seems to do: linux/mm/filemap.c: * MADV_SEQUENTIAL - pages in the given range will probably be accessed * once, so they can be aggressively read ahead, and * can be freed soon after they are accessed. /* * Read-ahead and flush behind for MADV_SEQUENTIAL areas. Since we are * sure this is sequential access, we don't need a flexible read-ahead * window size -- we can always use a large fixed size window. */ static void nopage_sequential_readahead(struct vm_area_struct * vma, O_SEQUENTIAL perhaps is the wrong name. I'd like to see this so I can run tar to backup a machine during the day (if tar used this flag, ofcourse) without performance going down the drain because of cache pollution. 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: O_DIRECT! or O_DIRECT?
In article <[EMAIL PROTECTED]>, Stephen C. Tweedie <[EMAIL PROTECTED]> wrote: >For these reasons, buffered IO is often faster than O_DIRECT for pure >sequential access. The downside it its greater CPU cost and the fact >that it pollutes the cache (which, in turn, causes even _more_ CPU >overhead when the VM is forced to start reclaiming old cache data to >make room for new blocks.) Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL)) 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: Cosmetic JFFS patch.
In article <[EMAIL PROTECTED]>, Tommy Reynolds <[EMAIL PROTECTED]> wrote: >Linus Torvalds <[EMAIL PROTECTED]> was pleased to say: > >> If they are shut off, then where's the drumming? Because if people start >> making copyright printk's normal, I will make "quiet" the default. > >Amen. This is like editing a program to remove the "harmless" compiler warning >messages. If I don't get a useless message, I don't have to decide to ignore >it. Describing what's happening is OK; don't gush. Yep - a driver should print out that it loaded and what hardware it found. Nothing else. You know what I hate? Debugging stuff like BIOS-e820, zone messages, dentry|buffer|page-cache hash table entries, CPU: Before vendor init, CPU: After vendor init, etc etc, PCI: Probing PCI hardware, ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc That's stuff that noone cares about. If the system fails to boot boot it with a debug flag. If it does boot, _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: Why can't I ptrace init (pid == 1) ?
In article <[EMAIL PROTECTED]>, Helge Hafting <[EMAIL PROTECTED]> wrote: >richard offer wrote: >> >> In arch/i386/kernel/ptrace.c there is the following code ... >> >> ret = -EPERM; >> if (pid == 1) /* you may not mess with init */ >> goto out_tsk; >> >> What is the rationale for this ? Is this a real security decision or >> an implementation detail (bad things will happen). > >I don't know why they did it, but ptracing init is definitely a added >security risk. If an intruder can't take over init, then a smart >init can fight back. Of course most inits aren't that smart, but >at least they can log problems and such. The intruder can't prevent >that because init cannot be killed except by booting (which is >noticeable), >and it cannot be taken over with ptrace. ptrace could otherwise >be used to make init exec some other init that doesn't do the >logging. You can exec another init anyway. Call 'telinit u' and init will re-exec itself, so that's not tne reason. The reason right now is I think that ptrace mucks around with sibling relations and since init is a special 'father of all processes' (or is that mother?) that would get the system into trouble real soon. 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: serial console problems under 2.4.4/5
In article <[EMAIL PROTECTED]>, Narayan Desai <[EMAIL PROTECTED]> wrote: >>>>>> "Mike" == Miquel van Smoorenburg <[EMAIL PROTECTED]> writes: > >Mike> In article <[EMAIL PROTECTED]>, >Mike> Narayan Desai <[EMAIL PROTECTED]> wrote: >>> Hi. I have started having serial console problems in the last bunch >>> of kernel releases. I have tried various 2.4.4 and 2.4.5 ac kernels >>> (up to and including 2.4.5-ac4) and the problem has persisted. The >>> problem is basically that serial console doesn't recieve. > >Mike> The serial driver now pays attention to the CREAD bit. Sysvinit >Mike> clears it, so that's where it goes wrong. > >Mike> I don't think this change should have gone into a 'stable' >Mike> kernel version. 2.5.0 would have been fine, not 2.4.4 Okay it was 2.4.3 when it went in >How would I go about resetting this so that serial console worked >again? thanks... Fix sysvinit. Oh and all getty programs etc - everything that mucks around with termios. Alternatively revert the change to drivers/char/serial.c See also http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg42426.html Oh *ahem* I just read the entire thread again and I remembered it wrong. It's not the CREAD handling perse, it's something else that has changed that caused this, but it appears that a solution hasn't been found yet. Except for fixing all user-space programs. Sysvinit, agetty, busybox etc etc Okay so ignore my earlier comments. Sorry. 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: serial console problems under 2.4.4/5
In article <[EMAIL PROTECTED]>, Narayan Desai <[EMAIL PROTECTED]> wrote: >Hi. I have started having serial console problems in the last bunch of >kernel releases. I have tried various 2.4.4 and 2.4.5 ac kernels (up >to and including 2.4.5-ac4) and the problem has persisted. The problem >is basically that serial console doesn't recieve. The serial driver now pays attention to the CREAD bit. Sysvinit clears it, so that's where it goes wrong. I don't think this change should have gone into a 'stable' kernel version. 2.5.0 would have been fine, not 2.4.4 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: IDE Performance lack !
In article <00c701c0e6d8$2b28ea40$4aa6b3d0@Toshiba>, Jaswinder Singh <[EMAIL PROTECTED]> wrote: >I am not able to understand why Linux read and/or write harddisk after some >time (after few hours ) , harddisk read/write leds keep on glowing for few >minutes , even though nobody working on it and machine is in idle state. Are you sure it is idle. It might be running something from cron- say 'updatedb' or similar. That will cause a lot of disk i/o, and _ofcourse_ performance will be bad then - the machine is doing a lot of other things. It might also be that you don't have enough memory and the machine is swapping itself to death. Running netscape or mozilla perhaps? These are known to blow themselves up to 50-100 MB (!). That will cause the exact symptoms you're seeing. >>Have you tried 2.2.x ? >> > >yes i am taking about 2.2.12 . 2.2.12 is old. In my experience, 2.2.19 is the first really good 2.2 kernel. Especially in low-memory situations like you might be experiencing.. >And in my 2.4.2 :- 2.4.2 isn't all that good either.. 2.4.x doesn't have VM sorted out just yet >and when my machine becomes normal i got :- >9.07 MB/sec Sounds about right for a non-UDMA disk. >But my problem is why linux boxes do not response for few seconds >(sometimes) and especially during telnet/ssh it looks more worst and looks >similar to Microsoft Windows :( >there is problem in scheduling or what ? Try 2.2.19 Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
According to Kurt Roeckx: > On Tue, Apr 10, 2001 at 11:20:24PM +0000, Miquel van Smoorenburg wrote: > > The "-1" means > > "all processes except me". That means init will get hit with > > SIGTERM occasionally during shutdown, and that might cause > > weird things to happen. > > -1 mean everything but init. > > From the manpage: Oh. OK, so this is yet another special case for init - forget to check those. Sorry about that (hey it's 01:53 here, I should be in bed). Yet I still think it'd be a better idea to use RT signals, see my other message in this thread. 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: Let init know user wants to shutdown
In article <9b04fo$9od$[EMAIL PROTECTED]>, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote: >SIGTERM is a bad choise. Right now, init ignores SIGTERM. For >good reason; on some (many?) systems, the shutdown scripts >include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means >"all processes except me". That means init will get hit with >SIGTERM occasionally during shutdown, and that might cause >weird things to happen. > >Perhaps SIGUSR1 ? In the immortal words of Max Headroom, t-t-talking to myself ;) In fact, the kernel should probably use a real-time signal with si_code set to 1 for ctrl-alt-del, 2 for the powerbutton etc. It should first check if process 1 (init) installed a handler for that real-time signal. If not, it should use the old signals (SIGINT for ctrl-alt-del, SIGWINCH for kbrequest). 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: Let init know user wants to shutdown
In article <[EMAIL PROTECTED]>,
Pavel Machek <[EMAIL PROTECTED]> wrote:
>Hi!
>
>Init should get to know that user pressed power button (so it can do
>shutdown and poweroff). Plus, it is nice to let user know that we can
>read such event. [I hunted bug for few hours, thinking that kernel
>does not get the event at all].
>
>Here's patch to do that. Please apply,
Not so hasty ;)
>+ printk ("acpi: Power button pressed!\n");
>+ kill_proc (1, SIGTERM, 1);
SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
good reason; on some (many?) systems, the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
"all processes except me". That means init will get hit with
SIGTERM occasionally during shutdown, and that might cause
weird things to happen.
Perhaps SIGUSR1 ?
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: build -->/usr/src/linux
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>Miquel van Smoorenburg wrote:
>> .. but there should be a cleaner way to get at the CFLAGS used
>> to compile the kernel.
>
>There is a way though I'd not call it clean. Here is an extract from
Do you think something like this is the correct approach? If it
was part of the official kernel you could write a Makefile like this:
KSRC = /lib/modules/`uname -r`/build
include $(KSRC)/include/config.mak
CFLAGS := $(CFLAGS) $(MODFLAGS)
module.c: module.h
--- linux-2.2.19.orig/Makefile Mon Apr 9 13:01:37 2001
+++ linux-2.2.19/Makefile Mon Apr 9 13:20:21 2001
@@ -325,7 +325,8 @@
MODFLAGS += -DMODVERSIONS -include $(HPATH)/linux/modversions.h
endif
-modules: include/config/MARKER $(patsubst %, _mod_%, $(SUBDIRS))
+modules: include/config/MARKER $(patsubst %, _mod_%, $(SUBDIRS)) \
+ include/linux/config.mak
$(patsubst %, _mod_%, $(SUBDIRS)) : include/linux/version.h
$(MAKE) -C $(patsubst _mod_%, %, $@) CFLAGS="$(CFLAGS) $(MODFLAGS)"
MAKING_MODULES=1 modules
@@ -380,6 +381,31 @@
@exit 1
endif
+include/linux/config.mak: ./Makefile
+ @echo "VERSION = $(VERSION)" > .mak
+ @echo "PATCHLEVEL = $(PATCHLEVEL)" >> .mak
+ @echo "SUBLEVEL = $(SUBLEVEL)" >> .mak
+ @echo "EXTRAVERSION = $(EXTRAVERSION)" >> .mak
+ @echo "ARCH = $(ARCH)" >> .mak
+ @echo "HOSTCC = $(HOSTCC)" >> .mak
+ @echo "HOSTCFLAGS = $(HOSTCFLAGS)" >> .mak
+ @echo "CROSS_COMPILE= $(CROSS_COMPILE)" >> .mak
+ @echo "AS = $(AS)" >> .mak
+ @echo "LD = $(LD)" >> .mak
+ @echo "CC = $(CC)" >> .mak
+ @echo "CPP = $(CPP)" >> .mak
+ @echo "AR = $(AR)" >> .mak
+ @echo "NM = $(NM)" >> .mak
+ @echo "STRIP= $(STRIP)" >> .mak
+ @echo "OBJCOPY = $(OBJCOPY)" >> .mak
+ @echo "OBJDUMP = $(OBJDUMP)" >> .mak
+ @echo "MAKE = $(MAKE)" >> .mak
+ @echo "GENKSYMS = $(GENKSYMS)" >> .mak
+ @echo "CFLAGS = $(CFLAGS)" >> .mak
+ @echo "AFLAGS = $(AFLAGS)" >> .mak
+ @echo "MODFLAGS = $(MODFLAGS)" >> .mak
+ @mv -f .mak $@
+
clean: archclean
rm -f kernel/ksyms.lst include/linux/compile.h
rm -f core `find . -name '*.[oas]' ! \( -regex '.*lxdialog/.*' \
@@ -398,6 +424,7 @@
mrproper: clean archmrproper
rm -f include/linux/autoconf.h include/linux/version.h
+ rm -f include/linux/config.mak
rm -f drivers/net/hamradio/soundmodem/sm_tbl_{afsk1200,afsk2666,fsk9600}.h
rm -f drivers/net/hamradio/soundmodem/sm_tbl_{hapn4800,psk4800}.h
rm -f drivers/net/hamradio/soundmodem/sm_tbl_{afsk2400_7,afsk2400_8}.h
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: build -->/usr/src/linux
In article <[EMAIL PROTECTED]>, Marvin Stodolsky <[EMAIL PROTECTED]> wrote: >Thanks for responding. But I would still like to understand what the >functionality is of the build --> /usr/src/linuc. Is it dispensable, >once the module tree has been installed? It's needed for modules that are distributed sperately, so that they can use cc -I /lib/modules/`uname -r`/build/include Or even l=`pwd` cd /lib/modules/`uname -r`/build make $l/module.o .. but there should be a cleaner way to get at the CFLAGS used to compile the kernel. 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: OOM killer???
In article <[EMAIL PROTECTED]>, Martin Dalecki <[EMAIL PROTECTED]> wrote: >Plase change to 100 to 500 - this would make it consistant with >the useradd command, which starts adding new users at the UID 500 "the" useradd command? Which distribution ? 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: Kernel 2.4.1 on RHL 6.2
According to Alan Cox: > > Note! You only have to have those symlinks on broken systems such > > as Redhat. > > < 7.0. > 7.0 or higher keeps the glibc includes out of /usr/src I stand corrected. Thanks. Mike. -- Go not unto the Usenet for advice, for you will be told both yea and nay (and quite a few things that just have nothing at all to do with the question). -- seen in a .sig somewhere - 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 2.4.1 on RHL 6.2
In article <[EMAIL PROTECTED]>,
Stephen "M." Williams <[EMAIL PROTECTED]> wrote:
>Make sure you have the following symlinks in your /usr/include
>directory, assuming you're on an x86 machine:
>
>asm -> /usr/src/linux/include/asm-i386/
>linux -> /usr/src/linux/include/linux/
Note! You only have to have those symlinks on broken systems such
as Redhat.
Sane systems such as Debian have a copy of the kernel header files
that the C library was compiled against in /usr/include/{linux,asm}
instead of symlinks to the kernel source. Do not play the symlink
trick on those systems.
Before this turns into a flamewar: this has been discussed 20 or
so times before, and both Linus and the glibc developers agree
that you a distribution should do the latter. The headers you use
to compile userland binaries should be the same as the C library
was compiled against.
If you need to compile a standalone module use -I/usr/src/linux/include
Mike.
--
Go not unto the Usenet for advice, for you will be told both yea and nay (and
quite a few things that just have nothing at all to do with the question).
-- seen in a .sig somewhere
-
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: Unmounting and ejecting the root fs on shutdown.
In article <[EMAIL PROTECTED]>, Per Erik Stendahl <[EMAIL PROTECTED]> wrote: >Mounting a ramdisk for / is doable (I think) but kludgy since you have >to symlink or mount so many subdirectories. Right now I only have /var >in a ramdisk (and why _WHY_ is /etc/mtab located in /etc and not >in /var??). If /var is on a seperate partition, how are you going to access it if /var hasn't been mounted yet ? Mike. -- I live the way I type; fast, with a lot of mistakes. - 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 problems
In article <[EMAIL PROTECTED]>, Janez Vrenjak <[EMAIL PROTECTED]> wrote: >> Generally its indicative of hardwae when you get dcache corruption especially >> with late 2.2, but it might be more complex. Does the box pass memtest86 ? > >I'm not shure what memtest86 is ... http://www.google.com/search?q=memtest86 Mike. -- I live the way I type; fast, with a lot of mistakes. - 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: ECN: Clearing the air (fwd)
In article <[EMAIL PROTECTED]>, James Sutherland <[EMAIL PROTECTED]> wrote: >On Sun, 28 Jan 2001, jamal wrote: >> The internet is a form of organized chaos, sometimes you gotta make >> these type of decisions to get things done. Imagine the joy _most_ >> people would get flogging all firewall admins who block all ICMP. > >Blocking out ICMP doesn't bother me particularly. I know they should be >selective, but it doesn't break anything essential. It breaks Path MTU Discovery. If you have a link somewhere in your network (not at an endpoint, or TCP MSS will take care of it) that has an MTU < 1500, you cannot reach hotmail and a lot of other sites either currently. It _does_ break essential things. Daily. I would get a lot of joy from flogging all firewall admins who block all ICMP. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: routing between different subnets on same if.
In article <[EMAIL PROTECTED]>, Paul Jakma <[EMAIL PROTECTED]> wrote: >On Sat, 27 Jan 2001, Miquel van Smoorenburg wrote: > >> Did you enable forwarding with echo 1 > /proc/sys/net/ipv4/ip_forward ? >> > >yes. the machine already routes correctly between the 2 subnets and >the internet which is on a seperate interface. i also disabled >/proc/sys/net/ipv4/conf/all/send_redirects, to no avail. What about /proc/sys/net/ipv4/conf/*/rp_filter ? Should be zero for the 192.* interface(s), I think. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: routing between different subnets on same if.
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote: >On Sat, 27 Jan 2001, Paul Jakma wrote: > >> On Sat, 27 Jan 2001 [EMAIL PROTECTED] wrote: >> >> > Hi Paul, >> > >> > I just think you might look for aliasing on your linux box. >> >> i have the aliasing, the aliased machine can ping IP's on both >> subnets. The machine is supposed to be a router though and clients on >> both subnets are setup to use it as their default router.. but it >> doesn't route... it notices that both IP's are on the same link and so >> just sends ICMP redirects. which doesn't help. :( >> >> i need linux to completely route between 2 IP's even though they are >> on the same link. Did you enable forwarding with echo 1 > /proc/sys/net/ipv4/ip_forward ? >did you install routed on the linux machine ? Routed is a daemon which speaks RIP to other routers. That isn't needed at all in this case. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
In article <[EMAIL PROTECTED]>, Randal, Phil <[EMAIL PROTECTED]> wrote: >Because if we do try to force it, the response which will come >back won't be "Linux is wonderful, it conforms to the standards". >It will be "Linux sucks, we can't connect to xyz.com with it (or >we can't connect because to xyz.com they run it)". Who cares? Linux sucks, I can't connect to xyz.com with it because it requires MSIE Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre7
In article <[EMAIL PROTECTED]>, Pete Zaitcev <[EMAIL PROTECTED]> wrote: >> o Fix kwhich versus old bash (Pete Zaitcev) > >DaveM pointed out that it fixes a non-problem. >I stepped on a bug with an obscure kernel, I think it >was 2.2.18-pre3, which called kwhich with several arguments. >Current kernels call kwhich with one argument at a time, >so they are not affected. Yes, but I think it simply puts something right that might be wrong or at least less portable. So it's correct. Also calling kwhich with multiple arguments was actually the idea behind the script. Oh well, as long as it works ... Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >At this point you have to ask 'why is vlan4001 an interface'. Would it not >be cleaner to add the vlan id to the entries in the list of addresses per >interface ? Not all the world is IP - what if you want to bridge between an ATM ELAN (LANE) and a VLAN? Note that different ATM ELANs also show up as seperate interfaces. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre3
In article <[EMAIL PROTECTED]>, Richard B. Johnson <[EMAIL PROTECTED]> wrote: >alias kwhich='type -path' in ~./bashrc should fix. Hmm? Smells like a stupid bug to me. The script is called as: CCFOUND :=$(shell $(CONFIG_SHELL) scripts/kwhich kgcc gcc272 cc gcc) So how can bash ever decide to replace scripts/kwhich (OBVIOUSLY a call to a non-internal command) with an alias or builtin? Are you sure this is in fact the bug? Couldn't it be the games with IFS in the scripts/kwhich script? Try this patch: --- linux-2.2.19pre3/scripts/kwhich.origTue Dec 19 23:16:52 2000 +++ linux-2.2.19pre3/scripts/kwhich Fri Dec 22 19:02:47 2000 @@ -7,7 +7,7 @@ exit 1 fi -IFS=: +IFS=":$IFS" for cmd in $* do for path in $PATH Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 asm-alpha/system.h has a problem
In article <[EMAIL PROTECTED]>, Timur Tabi <[EMAIL PROTECTED]> wrote: >** Reply to message from Peter Samuelson <[EMAIL PROTECTED]> on Mon, 18 Dec >2000 09:03:00 -0600 (CST) >> Not a compiler bug, a source bug of assuming a C header file can be >> included by a C++ program. The right solution, as always, is to make a >> copy of the header (assuming you really do need it) and edit the copy >> as necessary. > >That just creates more maintenance problems. What if the kernel header file >changes? Then he'll have to change his copy as well. He'll forever need to >check changes in that kernel header file, or risk having an obscure bug that's >otherwise hard to track. No, in fact that is the desired behaviour. If the kernel include files change, chances are very big that the source of the utility (or library) needs adjustments as well. In fact if you simply recompile the old source with the new header files you might get unwanted and unexpected behaviour, whereas if you recompile with the older header defs you'll simply use an advertized api that might not be the latest but works Mike. -- RAND USR 16514 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
In article <[EMAIL PROTECTED]>, Peter Samuelson <[EMAIL PROTECTED]> wrote: >[Miquel van Smoorenburg] >> In fact, the 2.2.18 kernel already puts a 'build' symlink in >> /lib/modules/`uname -r` that points to the kernel source, >> which should be sufficient to solve this problem.. almost. >> >> It doesn't tell you the specific flags used to compile the kernel, >> such as -m486 -DCPU=686 > >Sure it does. > > make -C /lib/modules/`uname -r`/build modules SUBDIRS=$(pwd) Excellent. Is there any way to put his in a Makefile? Mike. -- RAND USR 16514 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TIOCGDEV ioctl
According to Alexander Viro: > OK, I can see the point of finding out where the console is redirected > to. How about the following: > > /proc/sys/vc -> /dev/tty > /proc/sys/console -> where the hell did we redirect it or >vc if there's no redirect right now > Will that be OK with you? Well, I'd prefer the ioctl, but I can see the general direction the kernel is heading to: get rid of numeric ioctls and sysctl()s and put all that info under /proc. However /proc/sys only contains directories now, it would look kindof ugly to put 2 symlinks in there directly. Oh well. Mike. -- RAND USR 16514 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote: >On 15 Dec 2000, Miquel van Smoorenburg wrote: > >> I think /lib/modules/`uname -r`/ should contain a script that >> reproduces the CFLAGS used to compile the kernel. > >However it happens, the necessary information THAT I KNOW OF is: >0) The kernel headers under linux/include >1) The state information generated by running make configure ; make dep ; >make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg >configure which does the same thing but adds packaging-specific metadata. That state info is in ARCH, CFLAGS, CC and include/linux/autoconf.h >A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r` >will not always work, because: >0) The destination may not even exist (if the kernel has been installed >onto another machine) Yes but in that case, how are you going to compile a module without the kernel headers anyway. If you compiled a kernel on one machine and you know that you want to be able to compile modules on the second machine you need to copy over /usr/src/linux-x.y.z/include as well. >1) The destination has no metadata or has the WRONG metadata (if I've just >compiled and installed 2.4.0-test11 on my i386, then am now building same >for my sun4c) As I said the kconfig script should do some simple sanity checks- compare version and architecture at least. >I have been recently told that a full copy of kernel headers and metadata >in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman >who informed me of this hasn't yet shown why. Because lots of use have a small root file system of just 30 MB ? Hmm, but as soon as you start thinking about cross-compiles etc you need more and more state - like CROSS_COMPILE, AS, LD, CPP, AR, NM etc etc. Yuck. It would probably be better to put all that info in /usr/src/linux/Config.make, and use the current "build" symlink. A module makefile would then look like this: #! /usr/bin/make -f # You might want to point BUILD somewhere else. BUILD = /lib/modules/$(shell uname -r)/build include $(BUILD)/Config.make module.o: $(CC) $(CFLAGS) -c module.c Ah yes, this is probably a much better approach then a kconfig script Mike. -- RAND USR 16514 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TIOCGDEV ioctl
In article <[EMAIL PROTECTED]>, James Simmons <[EMAIL PROTECTED]> wrote: >Based on fgconsole.c. I just threw it together in a few minutes. >/* > * consolewhat.c - Prints which VC /dev/console is. > */ You're confusing /dev/console and /dev/tty0. /dev/console might be associated with /dev/ttyS0 or /dev/lp1 Mike. -- RAND USR 16514 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TIOCGDEV ioctl
According to Alexander Viro: > On Fri, 15 Dec 2000, Linus Torvalds wrote: > > > Please instead do the same thing /dev/tty does, namely a sane interface > > that shows it as a symlink in /proc (or even in /dev) > > There you go... (/proc/tty/console -> /dev/tty; may very well The current VT (fg_console) and /dev/console are 2 different things ... /dev/console might be /dev/ttyS1. Besides to get at fg_console we already have ioctl(/dev/tty0, TIOCLINUX, 12) There is currently no way to find out with what device /dev/console is associated. Why is that needed? For example, I wrote a program 'bootlogd' that opens /dev/console and a pty pair, uses TIOCCONS to redirect console messages to the pty pair so they can be logged. However one would like to write those messages to the _actual_ console as well, but there is no way to find out what the real console is. For this application a ioctl is better than a /proc symlink since it would be started before /proc is even mounted. Mike. -- RAND USR 16514 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
In article <[EMAIL PROTECTED]>, LA Walsh <[EMAIL PROTECTED]> wrote: >It was at that >point, the externally compiled module "barfed", because like many modules, >it expected, like many externally compiled modules, that it could simply >access all of it's needed files through /usr/include/linux which it gets >by putting /usr/include in it's path. I've seen commercial modules like >vmware's kernel modules use a similar system where they expect >/usr/include/linux to contain or point to headers for the currently running >kernel. vmware asks you nicely where are the running kernels include files [/usr/src/linux/include" > And then compiles the modules with -I/path/to/include/files In fact, the 2.2.18 kernel already puts a 'build' symlink in /lib/modules/`uname -r` that points to the kernel source, which should be sufficient to solve this problem.. almost. It doesn't tell you the specific flags used to compile the kernel, such as -m486 -DCPU=686 > So at that point it becomes what we should name it under >/usr/include/linux. Should it be: >1) "/usr/include/linux/sys" (my preference) /usr should be static. It could be a read-only NFS mount. Putting system dependant configuration info here (which a /usr/include/linux/sys symlink *is*) is wrong. I think /lib/modules/`uname -r`/ should contain a script that reproduces the CFLAGS used to compile the kernel. That way, you not only get the correct -I/path/to/kernel/include but the other compile-time flags (like -m486 etc) as well. # sh /lib/modules/`uname -r`/kconfig --cflags -D__KERNEL__ -I/usr/src/linux-2.2.18pre24/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 Standard module Makefile that will _always_ work: #! /usr/bin/make -f CC = $(shell /lib/modules/`uname -r`/kconfig --cc) CFLAGS = $(shell /lib/modules/`uname -r`/kconfig --cflags) module.o: $(CC) $(CFLAGS) -c module.c Flags could be: --check Consistency check - are the header files there and does include/linux/version.h match --ccOutputs the CC variable used to compile the kernel (important now that we have gcc, kgcc, gcc272) --arch Outputs the ARCH variable --cflagsOutputs the CFLAGS --include-path Outputs just the path to the include files Generating and installing this 'kconfig' script as part of "make modules_install" is trivial, and would solve all problems. Well as far as I can see, ofcourse, I might have missed something.. Mike. -- RAND USR 16514 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >> Yes, but 2.96 is also binary incompatible with all non-redhat distro's. >> And since redhat is _the_ distro that commercial entities use to >> release software for, this was very arguably a bad move. > >Except you conveniently ignore a few facts Doesn't everyone. I should have included a smiley with as comment that I was only half-joking. Anyway this is the kernel list, and as such this is becoming off-topic. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
In article <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]> wrote: >On 15 Dec 2000, Miquel van Smoorenburg wrote: > >> In article <[EMAIL PROTECTED]>, >> LA Walsh <[EMAIL PROTECTED]> wrote: >> >Which works because in a normal compile environment they have /usr/include >> >in their include path and /usr/include/linux points to the directory >> >under /usr/src/linux/include. >> >> No, that a redhat-ism. > >Not even all versions of redhat do that. If that has been fixed recently, that is a very Good Thing (tm). Now if in 2.5 /include/net would be moved to /linux/net so that user-level code that uses can be compiled with -I/usr/src/some/kernel/42.42/include/ I'd be even happier Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
In article <[EMAIL PROTECTED]>,
LA Walsh <[EMAIL PROTECTED]> wrote:
>Which works because in a normal compile environment they have /usr/include
>in their include path and /usr/include/linux points to the directory
>under /usr/src/linux/include.
No, that a redhat-ism.
Sane distributions simply include a known good copy of
/usr/src/linux/include/{asm,linux} verbatim in their libc6-dev package.
Debian has done that for a long, long time.
Several core glibc developers use Debian, are even Debian developers...
Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
In article <[EMAIL PROTECTED]>, Bernhard Rosenkraenzer <[EMAIL PROTECTED]> wrote: >The same thing is true of *any* gcc release. >For example, C++-ABI wise, 2.95.x is incompatible BOTH with egcs 1.1.x >_and_ the upcoming 3.0 release. Yes, but 2.96 is also binary incompatible with all non-redhat distro's. And since redhat is _the_ distro that commercial entities use to release software for, this was very arguably a bad move. There's simply no excuse. It's too obvious. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre25
According to Alan Cox: > > my server currently works with that patch, but I'm sure it won't boot anymore > > if I apply this 2.2.18pre25 alone. > > Some days I don't know why I bother Bad day, Alan? ;) > > just in case, here it is again. > It doesnt even apply Hmm, it did apply for me. Do newer versions of patch have the -l option on by default? Anyway. I just threw together a testmachine with a megaraid card. With 2.2.18pre18, it doesn't boot. With 2.2.18pre18 + Willy's patch, it does boot. And with 2.2.18pre25 without any extra patches, it magically works. So I took the plunge and compiled 2.2.18pre25 on the production machine with the megaraid. And well, it's coming up as I write this. I see that another patch _has_ been applied between pre18 and pre25 that tooks out some forward/backwards-compat logic with LINUX_VERSION_CODE magic (beneath /* Read the base port and IRQ from PCI */). And reading the patch, it makes sense. It probably does about the same as Willy's patch, but the "right" way by using pci_resource_start() which the one in pre18 only did for kernels > 2.3.0 So, it looks like pre25 has a working megaraid driver. Thanks Alan. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre25
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >So I figure this is it for 2.2.18, subject to evidence to the contrary Megaraid still needs fixing. I sent you the patch twice, so have other people, but it still isn't fixed. The megaBase &= PCI_BASE_ADDRESS_MEM_MASK; ... megaBase &= PCI_BASE_ADDRESS_IO_MASK; is removed by the 2.2.18 version (read the patch) and that breaks older megaraid cards. Existing megaraid system with 2.2.x kernels WILL break with 2.2.18 Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: All INNOMINATE linux-list feeds are now killed...
In article <[EMAIL PROTECTED]>, Juri Haberland <[EMAIL PROTECTED]> wrote: >Rik van Riel wrote: >> >> Could you make it a one-way list this time? >> These two-way lists always give horrible problems >> and I would hate to killfile all of innominate ;) > >Allright, I think we have choice :-/ >Sorry again... At ftp://ftp.cistron.nl/pub/people/miquels/software/cistron-m2n-1.36.tar.gz you'll find some gatewaying software that is unidirectional, yet bidirectional ;) It works by marking the groups as moderated. A posting to the group will be sent by mail to the moderator, which is a script that checks and rewrites the news message, and sends it to the list. That way it's almost impossible for loops to get created. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
In article <[EMAIL PROTECTED]>, Rogier Wolff <[EMAIL PROTECTED]> wrote: >Paul Jakma wrote: >> perhaps linux-mips is just different? or i386 serial-console is >> incorrect? > >No. serial console on i386 doesn't and should not block. >We're constantly using serial consoles here, so I really think I've >seen this work... . It can block. Funny, no message on this list has been quite right ;) /dev/console can block /dev/ttyS0 can block printk() never blocks init(8) reads the tty settings from /etc/ioctl.save at startup. After it leaves single user mode it writes that file again. So mods made in single user mode are saved to /etc/ioctl.save. Every time init executes a program, it restores the console settings to those from /etc/ioctl.save. [Perhaps I should rip that stuff out] However a getty on /dev/ttyS0 which you usually have running in runlevels [12345789] can change the tty settings and they will take effect immidiately. So if you run a getty that turns on hardware handshaking (like mgetty) - you're fscked. The only things in which /dev/console is special are: - it's an alias for the current console - it's always opened with O_NOCTTY Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial Console
In article <[EMAIL PROTECTED]>, Steve Hill <[EMAIL PROTECTED]> wrote: >I'm building boxes with the console set to /dev/ttyS0. However, I can't >guarantee that there will always be a term plugged into the serial >port. If there is no term on the port, eventually the buffer fills and >any processes that write to the console (i.e. init) block. Is there some >option somewhere to stop this happening (i.e. either ignoring the >flow-control or just allowing the buffer to overflow)? Offtopic, but anyway .. Sure, turn flow control off. You'll probably have to configure this on the getty process that runs on ttyS0 Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] no RLIMIT_NPROC for root, please
In article <[EMAIL PROTECTED]>, Frank v Waveren <[EMAIL PROTECTED]> wrote: >On Tue, Nov 28, 2000 at 09:58:14PM +, Alan Cox wrote: >> > Because you want to be able to `kill `? >> > And if you are over-limits you can't? >> Wrong. limit is a shell built in > >I assume you mean kill is a shell builtin. Depending on your shell. :-). No. Think about it. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre22
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >Bugs to go: PS/2 mouse detection And probably Megaraid still. I'll try to test it this week, after Tuesday though. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] megaraid driver update for 2.4.0-test10
In article <[EMAIL PROTECTED]>, dalecki <[EMAIL PROTECTED]> wrote: >This is a multi-part message in MIME format. >1. Merge the most current version (aka: 1.08) of the > MegaRAID driver from AMI in to the most current kernel > (2.4.0-test10 and friends). The latest is 1.11a or something. The 1.08 one has *bugs*. At least if it's the same from the 2.2.18preX series. And even that one has still patches outstanding because it doesn't work Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Used space in bytes
In article <8uf21i$ro7$[EMAIL PROTECTED]>, H. Peter Anvin <[EMAIL PROTECTED]> wrote: >Report a block size (really allocation unit size) st_blocks == 1? If you mean st_blksize, well: The value st_blocks gives the size of the file in 512-byte blocks. The value st_blksize gives the "preferred" block size for efficient file system I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify- rewrite.) Telling programs 'please use 1-byte r/w buffers' is probably a bad idea. Mike. -- People get the operating system they deserve. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre20 MEGARAID hang
In article <[EMAIL PROTECTED]>,
Brian Marsden <[EMAIL PROTECTED]> wrote:
>2.2.18pre20 (still) hangs on boot when it gets to the part where it
>detects the MEGARAID card.
Hmm, I got a patch from AMI that fixed it for me for 2.2.18pre18.
That patch wasn't applied as-is, though Alan said a megaraid fix was
applied to 2.2.18pre19. I didn't have a chance to test pre19 or pre20
yet, though, since I can only test it on a production machine that
now runs OK with pre18+fix, the test machine lays on someones desk
in a lot of parts at the moment ;)
Anyway. Here's a patch that ``upgrades'' the 2.2.18pre20 megaraid.c
to the 2.2.18pre18 + AMI patch version that I have. Please let
us know if it makes any difference.
[and, if you can, and this patch works, try to remove parts of the
patch until you find exactly what it is that makes it work]
--- linux-2.2.18pre20/drivers/scsi/megaraid.c Thu Nov 9 14:35:23 2000
+++ linux-2.2.18pre18-mega/drivers/scsi/megaraid.c Thu Nov 9 21:49:50 2000
@@ -9,7 +9,7 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
- * Version : 1b08b
+ * Version : v1.11a
*
* Description: Linux device driver for AMI MegaRAID controller
*
@@ -179,7 +179,9 @@
* I) Version number changed from 1.10c to 1.11
* II)DCMD_WRITE_CONFIG(0x0D) command in the driver changed from
* scatter/gather list mode to direct pointer mode..
- *
+ *
+ * Version 1.11a
+ * Initlization bug fixed
* BUGS:
* Some older 2.1 kernels (eg. 2.1.90) have a bug in pci.c that
* fails to detect the controller as a pci device on the system.
@@ -194,7 +196,7 @@
#define CRLFSTR "\n"
#define IOCTL_CMD_NEW 0x81
-#define MEGARAID_VERSION "v1.11 (Aug 23, 2000)"
+#define MEGARAID_VERSION "v1.11a (Oct 24, 2000)"
#define MEGARAID_IOCTL_VERSION 108
#include
@@ -1842,8 +1844,8 @@
while ((pdev = pci_find_device (pciVendor, pciDev, pdev))) {
#ifdef DELL_MODIFICATION
-if (pci_enable_device(pdev))
- continue;
+if (pci_enable_device(pdev))
+ continue;
#endif
pciBus = pdev->bus->number;
pciDevFun = pdev->devfn;
@@ -1889,7 +1891,11 @@
"megaraid: to protect your data, please upgrade your
firmware to version\n"
"megaraid: 3.10 or later, available from the Dell
Technical Support web\n"
"megaraid: site at\n"
+#ifdef DELL_MODIFICATION
"http://support.dell.com/us/en/filelib/download/index.asp?fileid=2940\n");
+#else
+
+"http://support.dell.com/us/en/filelib/download/index.asp?fileid=2489\n");
+#endif
continue;
}
}
@@ -1914,16 +1920,32 @@
megaIrq = pdev->irq;
#else
-megaBase = pci_resource_start (pdev, 0);
+#ifdef DELL_MODIFICATION
+megaBase = pci_resource_start (pdev, 0);
+#else
+megaBase = pdev->resource[0].start;
+#endif
megaIrq = pdev->irq;
#endif
pciIdx++;
-if (flag & BOARD_QUARTZ)
- megaBase = (long) ioremap (megaBase, 128);
-else
- megaBase += 0x10;
+#ifdef DELL_MODIFICATION
+if (flag & BOARD_QUARTZ)
+ megaBase = (long) ioremap (megaBase, 128);
+else
+ megaBase += 0x10;
+#else
+if (flag & BOARD_QUARTZ) {
+
+ megaBase &= PCI_BASE_ADDRESS_MEM_MASK;
+ megaBase = (long) ioremap (megaBase, 128);
+}
+else {
+ megaBase &= PCI_BASE_ADDRESS_IO_MASK;
+ megaBase += 0x10;
+}
+#endif
/* Initialize SCSI Host structure */
host = scsi_register (pHostTmpl, sizeof (mega_host_config));
@@ -2087,8 +2109,7 @@
remove_proc_entry("config", megaCfg->controller_proc_dir_entry);
remove_proc_entry("mailbox", megaCfg->controller_proc_dir_entry);
for (i = 0; i < numCtlrs; i++) {
-char buf[12];
-memset(buf,0,12);
+char buf[12] ={0};
sprintf(buf,"%d",i);
remove_proc_entry(buf,mega_proc_dir_entry);
}
--
People get the operating system they deserve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Where did kgcc go in 2.4.0-test10 ?
According to Jeff Garzik: > Miquel van Smoorenburg wrote: > > By default Debian comes > > with gcc 2.95.2 which compiles current 2.2.x and 2.4.x kernels just > > fine. > > Linux-Mandrake 7.2 doesn't seem to be missing gcc patches that > Debian has... and in our testing we've found that some drivers are > still miscompiled by gcc 2.95.2+fixes. I'm not so sure you are correct > here... Really? Interesting! I'm not claiming I am completely correct, I'm just stating what seems to be current Debian policy. Can you tell me what drivers are miscompiled by 2.95.2, I'd appreciate that. Mike. -- People get the operating system they deserve. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where did kgcc go in 2.4.0-test10 ?
In article <[EMAIL PROTECTED]>, David S. Miller <[EMAIL PROTECTED]> wrote: > Date: Wed, 1 Nov 2000 23:57:34 +0100 > From: Kurt Garloff <[EMAIL PROTECTED]> > > kgcc is a redhat'ism. > >Debian has it too. Not quite. Debian does have an completely optional gcc272 package. It is _not_ installed as kgcc (the binary is called gcc272) and you don't _have_ to compile your kernels with it. It is an optional package and you have to actively select and install it. By default Debian comes with gcc 2.95.2 which compiles current 2.2.x and 2.4.x kernels just fine. At least I haven't used gcc272 for kernels for at least a year now (I think, first egcs, then gcc 2.95) and on all the servers I administer (and that's quite a few) gcc 2.95 hasn't caused any problems. Mike. -- People get the operating system they deserve. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Looking for better 2.2-based VM (do_try_to_free_pages fails, machine hangs)
In article <[EMAIL PROTECTED]>, Yann Dirson <[EMAIL PROTECTED]> wrote: >Using a 2.2.17 kernel I often experience problems where I get messages like >"VM: do_try_to_free_pages failed for ", and the machine hangs >until the VM can recover, which sometimes takes too long for me to wait. I >suppose that the problem is similar sometimes when I get a frozen system >under X, but can't see the kernel messages then. I'm seeing the same on some machines. Running several instances of bonnie on a dual SMP Intel with a DAC 1164 raid controller would kill the machine in a few hours. However it has been running several bonnies now without a hitch for 2 days, on 2.2.18pre18 Mike. -- People get the operating system they deserve. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: DELL PERC/Megaraid RAID driver in Linux 2.2.18pre17 hang
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>Yep - known problem. AMI have one more pre patch to sort it our Im going back
>to the older driver
I've tried the AMI patch and it appears to work. I'm now running
2.2.18pre18 + fix to ideprobe.c + ami megaraid fix and it looks OK
Here's the patch.
--- linux-2.2.18pre11/drivers/scsi/megaraid.c Fri Sep 29 15:29:31 2000
+++ megaraid/megaraid.c Wed Oct 25 11:40:51 2000
@@ -9,7 +9,7 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
- * Version : 1b08b
+ * Version : v1.11a
*
* Description: Linux device driver for AMI MegaRAID controller
*
@@ -179,7 +179,9 @@
* I) Version number changed from 1.10c to 1.11
* II)DCMD_WRITE_CONFIG(0x0D) command in the driver changed from
* scatter/gather list mode to direct pointer mode..
- *
+ *
+ * Version 1.11a
+ * Initlization bug fixed
* BUGS:
* Some older 2.1 kernels (eg. 2.1.90) have a bug in pci.c that
* fails to detect the controller as a pci device on the system.
@@ -194,7 +196,7 @@
#define CRLFSTR "\n"
#define IOCTL_CMD_NEW 0x81
-#define MEGARAID_VERSION "v1.11 (Aug 23, 2000)"
+#define MEGARAID_VERSION "v1.11a (Oct 24, 2000)"
#define MEGARAID_IOCTL_VERSION 108
#include
@@ -1842,8 +1844,8 @@
while ((pdev = pci_find_device (pciVendor, pciDev, pdev))) {
#ifdef DELL_MODIFICATION
-if (pci_enable_device(pdev))
- continue;
+if (pci_enable_device(pdev))
+ continue;
#endif
pciBus = pdev->bus->number;
pciDevFun = pdev->devfn;
@@ -1889,7 +1891,11 @@
"megaraid: to protect your data, please upgrade your
firmware to version\n"
"megaraid: 3.10 or later, available from the Dell
Technical Support web\n"
"megaraid: site at\n"
+#ifdef DELL_MODIFICATION
"http://support.dell.com/us/en/filelib/download/index.asp?fileid=2940\n");
+#else
+
+"http://support.dell.com/us/en/filelib/download/index.asp?fileid=2489\n");
+#endif
continue;
}
}
@@ -1914,16 +1920,32 @@
megaIrq = pdev->irq;
#else
-megaBase = pci_resource_start (pdev, 0);
+#ifdef DELL_MODIFICATION
+megaBase = pci_resource_start (pdev, 0);
+#else
+megaBase = pdev->resource[0].start;
+#endif
megaIrq = pdev->irq;
#endif
pciIdx++;
-if (flag & BOARD_QUARTZ)
- megaBase = (long) ioremap (megaBase, 128);
-else
- megaBase += 0x10;
+#ifdef DELL_MODIFICATION
+if (flag & BOARD_QUARTZ)
+ megaBase = (long) ioremap (megaBase, 128);
+else
+ megaBase += 0x10;
+#else
+if (flag & BOARD_QUARTZ) {
+
+ megaBase &= PCI_BASE_ADDRESS_MEM_MASK;
+ megaBase = (long) ioremap (megaBase, 128);
+}
+else {
+ megaBase &= PCI_BASE_ADDRESS_IO_MASK;
+ megaBase += 0x10;
+}
+#endif
/* Initialize SCSI Host structure */
host = scsi_register (pHostTmpl, sizeof (mega_host_config));
@@ -2087,8 +2109,7 @@
remove_proc_entry("config", megaCfg->controller_proc_dir_entry);
remove_proc_entry("mailbox", megaCfg->controller_proc_dir_entry);
for (i = 0; i < numCtlrs; i++) {
- char buf[12];
- memset(buf,0,12);
+ char buf[12] ={0};
sprintf(buf,"%d",i);
remove_proc_entry(buf,mega_proc_dir_entry);
}
Mike.
--
People get the operating system they deserve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre18
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>2.2.18pre18
>o Fix rtc_lock for ide-probe, and hd.c(Richard Johnson)
I need this to get it to compile:
--- linux-2.2.18pre18.orig/drivers/block/ide-probe.cSun Oct 29 13:02:39 2000
+++ linux-2.2.18pre18/drivers/block/ide-probe.c Sun Oct 29 14:26:20 2000
@@ -45,6 +45,8 @@
#include "ide.h"
+extern spinlock_t rtc_lock;
+
static inline void do_identify (ide_drive_t *drive, byte cmd)
{
int bswap = 1;
Mike.
--
People get the operating system they deserve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux's implementation of poll() not scalable?
In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> struct event {
> unsigned long id; /* file descriptor ID the event is on */
> unsigned long event;/* bitmask of active events */
> };
> int bind_event(int fd, struct event *event);
Shouldn't there also be a way to add non-filedescriptor based events
into this, such as "child exited" or "signal caught" or shm things?
Or should there simply be ways to make those events available
through filedescriptors anyway? Then you'd get /dev/events - open it, tell
it what kind of event you want to bind to the fd, pass it to bind_event,
read a struct event_info from it when there's something to read.
Just a random thought. Ignore if not appropriate.
Mike.
--
Q: How many ears do Trekkies have?
A: Three; the left ear, the right ear, and the final front ear.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: raid2 patches for 2.2.x
In article <[EMAIL PROTECTED]>, Wakko Warner <[EMAIL PROTECTED]> wrote: >Something higher than the one for kernel 2.2.11 I found it once, but I can't >find it again. (and people.redhat.com isn't accepting http connections) ftp://ftp..kernel.org/pub/linux/kernel/people/mingo/ Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MIME QP encoded good/bad ...
In article <[EMAIL PROTECTED]>, Matti Aarnio <[EMAIL PROTECTED]> wrote: > Yes Linus, ASCII is fine, but then the ENTIRE MESSAGE must be > in 7-bit ASCII only. A single 8-bit char anywhere makes worlds > of difference to the rules. (E.g. 8-bit char in .signature > may force QP encoding of the entire message.) So, what do you think of http://pobox.com/~djb/docs/8bit/06.txt http://pobox.com/~djb/docs/8bit/08.txt Mike "QP must die". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre12 fix for some distros
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >I'll play with the proposed which based fixes first, unless you have clever >ideas ? Include a script in scripts/kwhich that tells you the path to a certain binary. Below is a simple implementation. If you condense it you can even include it in the Makefile verbatim, though a seperate script seems cleaner to me. % ./kwhich unknowncc gcc272 gcc cc /usr/bin/gcc272 #! /bin/sh # kwhich 1.0 (C) 2000 Miquel van Smoorenburg # This program is GPLed if [ $# -lt 1 ] then echo "Usage: $0 cmd [cmd..]" >&2 exit 1 fi IFS=: for cmd in $* do for path in $PATH do if [ -x "$path/$cmd" ] then echo "$path/$cmd" exit 0 fi done done echo "$*: not found" >&2 exit 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 megaraid driver broken [was: Re: Linux 2.2.18pre11]
According to Miquel van Smoorenburg:
> The megaraid driver in 2.2.18 doesn't work with MegaRaid 434 cards.
> I've tried it on 2 different systems. Using 2.2.18pre11 with the
> megaraid.[ch] from 2.2.17 works just fine.
>
> I've only been able to test with SMP systems though - perhaps this is
> a uniprocessor / SMP problem ?
Right, I've now booted a non-smp kernel - same problem still.
Magic sysrq tells me that the kernel is stuck at 0xc01ca3b9, which
in my kernel is megaIssueCmd()
Disassembling the kernel and comparing it with the source code,
it turns out that it's stuck in
while (mbox->numstatus == 0xFF);
Now megaIssueCmd() was changed in the 2.2.18 patch, and this is
the part that seems to be responsible for it (see below).
Alan, can you forward this to the maintainer, or tell me from whom
you got the 2.2.18 patch so I can forward this to them ?
@@ -1261,10 +1519,18 @@
if (megaCfg->flag & BOARD_QUARTZ) {
mbox->mraid_poll = 0;
mbox->mraid_ack = 0;
+ mbox->numstatus = 0xFF;
+ mbox->status = 0xFF;
WRINDOOR (megaCfg, phys_mbox | 0x1);
- while ((cmdDone = RDOUTDOOR (megaCfg)) != 0x10001234);
- WROUTDOOR (megaCfg, cmdDone);
+ while (mbox->numstatus == 0xFF);
+ while (mbox->status == 0xFF);
+ while (mbox->mraid_poll != 0x77);
+ mbox->mraid_poll = 0;
+ mbox->mraid_ack = 0x77;
+
+/* while ((cmdDone = RDOUTDOOR (megaCfg)) != 0x10001234);
+ WROUTDOOR (megaCfg, cmdDone);*/
if (pScb) {
mega_cmd_done (megaCfg, pScb, mbox->status);
Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
In article <3776575819.970144217@[10.10.1.2]>, Martin J. Bligh <[EMAIL PROTECTED]> wrote: >> When I was researching the use of ORBS and MAPS a few weeks >> back, my first thought was that the DUL would unfairly block Linux >> users running Sendmail. Looks like that's true. > >Just give sendmail a smart_host of your ISP's mail server. In theory >I guess this slows thing down, and yes it's a pain, but on the other >hand, it works. It speeds things up in a lot of cases. What if the destination host is down? What if the destination host is in Zimbabwe connected through a 9600 baud modem? Much easier to transfer your mail full speed to the ISPs smarthost and let it care about all that. And unreliable ISP SMTP servers? Hard to imagine, as 99.5% of the userbase undoubtedly uses that SMTP server and I can't believe that a reasonable ISP randomly drops email messages. That being said you should never get bounces when posting to the Linux kernel mailing list, since it isn't you who delivers all that mail to the endusers, but the majordomo running on vger or one of the exploders. The SMTP envelope from address should also be set to majordomo@vger, so I can't see how you would get hundreds of ORBS and DUL bounces ... &^%*& fscking out-of-office replies, yes (they should reinstate hanging for that ...) Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 megaraid driver broken [was: Re: Linux 2.2.18pre11]
In article <8qvfae$j52$[EMAIL PROTECTED]>, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote: >In article <[EMAIL PROTECTED]>, >Alan Cox <[EMAIL PROTECTED]> wrote: >>2.2.18pre11 >[..] >>o Fix inia100/megaraid define clash (Arjan van de Ven) >[..] > >The megaraid driver in 2.2.18 doesn't work with MegaRaid 434 cards. Note that it wasn't 2.2.18pre11 that broke megaraid. The first 2.2.18pre kernel I tried was 2.2.18pre5 which already had this problem (see <[EMAIL PROTECTED]> posted on Tue, 12 Sep 2000 14:10:56 +0200) Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 megaraid driver broken [was: Re: Linux 2.2.18pre11]
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >2.2.18pre11 [..] >o Fix inia100/megaraid define clash (Arjan van de Ven) [..] The megaraid driver in 2.2.18 doesn't work with MegaRaid 434 cards. I've tried it on 2 different systems. Using 2.2.18pre11 with the megaraid.[ch] from 2.2.17 works just fine. I've only been able to test with SMP systems though - perhaps this is a uniprocessor / SMP problem ? Excerpt from the bootlog of 2.2.18pre11 vanilla: [normal bootup] megaraid: v1.11 (Aug 23, 2000) megaraid: found 0x8086:0x1960:idx 0:bus 0:slot 11:func 1 scsi0 : Found a MegaRAID controller at 0xd0002000, IRQ: 18 [hangs indefinitely] And from the bootlog of 2.2.18pre11 with the 2.2.17 megaraid.[ch] : [normal bootup] megaraid: v107 (December 22, 1999) megaraid: found 0x8086:0x1960:idx 0:bus 0:slot 11:func 1 scsi0 : Found a MegaRAID controller at 0xd0002000, IRQ: 18 megaraid: [GH8E:1.44] detected 2 logical drives scsi0 : AMI MegaRAID GH8E 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 RAID1 17365R Rev: GH8E Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 3, id 0, lun 0 Vendor: MegaRAID Model: LD1 RAID1 17365R Rev: GH8E Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 3, id 0, lun 1 scsi : detected 2 SCSI disks total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 35563520 [17365 MB] [17.4 GB] SCSI device sdb: hdwr sector= 512 bytes. Sectors= 35563520 [17365 MB] [17.4 GB] [etc etc] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with 2.4.0-test9-pre6 seems to be SHM
In article <[EMAIL PROTECTED]>, safemode <[EMAIL PROTECTED]> wrote: >One more little complaint.. why doesn't vger replace the FROM to >[EMAIL PROTECTED] like any other sane mailing list ... i >keep going to Reply and not sending to the list. At least add a >reply-to tag like the proftpd mailing list has if you want to keep the >FROM tag as the original sender. The linux-kernel mailing list is the sane one, the other ones aren't. See http://www.unicom.com/pw/reply-to-harmful.html for an explanation Mike. -- Q: What is the one true indent width? A: 42. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Booting into /bin/bash
According to Richard B. Johnson:
> I'm checking on it now. Here's a strace with setsid() ahead, same
> problem:
Yes, sessions, process groups, and controlling ttys are weird
and hard to understand. And probably braindamaged as well, if
not, it's what they cause anyway ;)
If you want to forcibly get a controlling tty:
/* Make sure we do not have a controlling tty. */
ioctl(0, TIOCNOTTY, 0);
close(0);
close(1);
close(2);
/* Become session leader */
setsid();
/* Open tty which will become new controlling tty. */
open("/dev/tty1", O_RDWR);
dup(0);
dup(0);
/* Just to be sure, force controlling tty, in case /dev/tty1
was the ctty for another process. Only root may do this! */
ioctl(0, TIOCSCTTY, 1);
Mike.
--
Deadlock, n.:
Deceased rastaman.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
