Re: alpha iommu fixes
On Sun, May 20, 2001 at 04:40:13AM +0200, Andrea Arcangeli wrote: I was only talking about when you get the pci_map_sg failed because you have not 3 but 300 scsi disks connected to your system and you are writing to all them at the same time allocating zillons of pte, and one of your drivers (possibly not even a storage driver) is actually not checking the reval of the pci_map_* functions. You don't need a pte memleak to trigger it, even regardless of the fact I grown the dynamic window to 1G which makes it 8 times harder to trigger than in mainline. I think you're too pessimistic. Don't mix disks and controllers -- SCSI adapter with 10 drives attached is a single DMA agent, not 10 agents. If you're so concerned about Big Iron, go ahead and implement 64-bit PCI support, it would be right long-term solution. I'm pretty sure that high-end servers use mostly this kind of hardware. Oh, well. This doesn't mean that I'm disagreed with what you said. :-) Driver writers must realize that pci mappings are limited resources. Ivan. - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]
Getting a list of all ioctls in the tree, along with types of their arguments would be a great start. Anyone willing to help with that? % man 2 ioctl_list gives a very outdated list. Collecting the present list is trivial but time-consuming. If anyone does I would be happy if he also sent me an updated ioctl_list.2 Andries [PS I released man-pages-1.36 a few days ago] - 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: no ioctls for serial ports? [was Re: LANANA: To PendingDeviceNumberRegistrants]
On Sun, 20 May 2001 [EMAIL PROTECTED] wrote:
Getting a list of all ioctls in the tree, along with types of their arguments
would be a great start. Anyone willing to help with that?
% man 2 ioctl_list
gives a very outdated list. Collecting the present list is trivial
but time-consuming. If anyone does I would be happy if he also
sent me an updated ioctl_list.2
Andries, I wouldn't call it trivial. Consider the following:
default:
if ((cmd ~(_IOC_SIZEMASK _IOC_SIZESHIFT)) ==
JSIOCGNAME(0)) {
int len;
if (!dev-name) return 0;
len = strlen(dev-name) + 1;
if (len _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
if (copy_to_user((char *) arg, dev-name, len)) return
-EFAULT;
return len;
}
Real-world example. From drivers/input/joydev.c::joydev_ioctl(). And it's far
from the worst ones - just one I'm currently looking at.
We have ~180 first-order ioctl() methods. Several (my guess would be 8--15)
subsystems of the second order and hell knows how many instances in each
of them. And I'm afraid that we have some third-order families. Each instance
of each family got some ioctls in it. I think that we have several thousands
of these beasts. And that's several thousands of undocumented system calls
hidden in bowels of sys_ioctl(). Undocumented == for most of them we have
no information of argument types, which arguments are in-, out- or in-out,
which contain pointers to other userland structures, etc.
-
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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Russell King wrote: I still see read()/write() being a pass any crap interface. The implementer of the target for read()/write() will probably still be a driver which will need to decode what its given, whether its in ASCII or binary. And driver writers are already used to writing ioctl-like interfaces. You _are_ missing the point. write() doesn't have that history of wild abuse. It's easier to whack the driver writer's balls for abusing it. I'm more than willing to play Narn Bat Squad and I'm pretty sure that I'm not alone at that. - 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: no ioctls for serial ports? [was Re: LANANA: To Pending Device Num
[EMAIL PROTECTED] (Pavel Machek) wrote on 19.05.01 in [EMAIL PROTECTED]: I think that plan9 uses something different -- they have ttyS0 and ttyS0ctl. This would leave us with problem how do I get handle to ttyS0ctl when I only have handle to ttyS0? I've seen this question several times in this thread. I haven't seen the obvious answer, though. Have a new system call: ctlfd = open_device_control_fd(fd); If fd is something that doesn't have a control interface (say, it already is a control filehandle), this returns an appropriate error code. This has another benefit, in that you can get control descriptors for stuff that doesn't currently have a filename (but does have ioctls), such as network sockets. MfG Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4-ac11 network drivers cleaning
On Sat, 19 May 2001 17:58:49 -0400, Jeff Garzik [EMAIL PROTECTED] wrote: Finally, I don't know if I mentioned this earlier, but to be complete and optimal, version strings should be a single variable 'version', such that it can be passed directly to printk like printk(version); Nit pick. That has random side effects if version contains any '%' characters. Make it It should not. I see no reason for a literal % in the version string. printk(%s\n, version); Not quite as optimal but safer. It is simpler to remove the %s from version. I don't think any of them require it. If one add a % he should know what he is doing. -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] tel. (0-58) 347 14 61 Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On 20 May 2001, Kai Henningsen wrote: I've seen this question several times in this thread. I haven't seen the obvious answer, though. Have a new system call: ctlfd = open_device_control_fd(fd); If fd is something that doesn't have a control interface (say, it already is a control filehandle), this returns an appropriate error code. It may have several. Which one? FWIW, I think that mixing network and device ioctls is a bad idea. These groups are very different and we'd be better off dealing with changes in them separately. For devices... I'd say that fpath(2) (same type as getcwd(2)) would be a good way to deal with that. Or fpath(3) - implemented via readlink(2) on /proc/self/fd/n. - 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: alpha iommu fixes
On Sun, May 20, 2001 at 04:12:34PM +0400, Ivan Kokshaysky wrote: On Sun, May 20, 2001 at 04:40:13AM +0200, Andrea Arcangeli wrote: I was only talking about when you get the pci_map_sg failed because you have not 3 but 300 scsi disks connected to your system and you are writing to all them at the same time allocating zillons of pte, and one of your drivers (possibly not even a storage driver) is actually not checking the reval of the pci_map_* functions. You don't need a pte memleak to trigger it, even regardless of the fact I grown the dynamic window to 1G which makes it 8 times harder to trigger than in mainline. I think you're too pessimistic. Don't mix disks and controllers -- I'm not pessimistic, I'm fairly relaxed also with a 512Mbyte dynamic window (that's why I did the change in first place) and I agree that it should take care of hiding all those bugs on 99% of hardware configurations, but OTOH I don't want things to work by luck and I'd prefer if the real bugs gets fixed as well eventually. SCSI adapter with 10 drives attached is a single DMA agent, not 10 agents. you can do simultaneous I/O to all the disks, so you will keep those dma entries for the SG for each disk in-use at the same time. If you're so concerned about Big Iron, go ahead and implement 64-bit PCI support, it would be right long-term solution. I'm pretty sure that high-end servers use mostly this kind of hardware. Certainly 64bit pci is supported but that doesn't change the fact you can as well have 32bit devices on those boxes. Oh, well. This doesn't mean that I'm disagreed with what you said. :-) Driver writers must realize that pci mappings are limited resources. Exactly. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]
Andries, I wouldn't call it trivial. I am a mathematician. Definition of trivial in this case: No intelligence required, just patience and careful work. - 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: alpha iommu fixes
[ cc'ed to l-k ] DMA-mapping.txt assumes that it cannot fail. DMA-mapping.txt is wrong. Both pci_map_sg and pci_map_single failed if they returned zero. You either have to drop the skb or to try again later if they returns zero. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
Andrea Arcangeli wrote:
[ cc'ed to l-k ]
DMA-mapping.txt assumes that it cannot fail.
DMA-mapping.txt is wrong. Both pci_map_sg and pci_map_single failed if
they returned zero. You either have to drop the skb or to try again later
if they returns zero.
Well this is news to me. No drivers understand this.
How long has this been the case? What platforms?
For netdevices at least, the pci_map_single() call is always close
to the site of the skb allocation. So what we can do is to roll
them together and use the existing oom-handling associated with alloc_skb(),
assuming the driver has it...
static inline struct sk_buff *pci_alloc_skb(
int length, int gfp_mask, int reserve,
pci_dev *pdev, dma_addr_t *dma_addr, int direction, int irq)
{
struct sk_buff *skb = alloc_skb(length + 16, gfp_mask);
if (skb) {
skb_reserve(ret, 16 + reserve);
*dma_addr = pci_map_single(pdev, skb-tail, size - reserve, direction);
if (*dma_addr == 0) {
if (irq)
dev_kfree_skb_irq(skb);
else
dev_kfree_skb(skb);
skb = 0;
}
}
return skb;
}
Sticky, but a lot of it will be compiled away.
-
-
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: no ioctls for serial ports? [was Re: LANANA: To Pending Device Num
On Sunday 20 May 2001 15:40, Alexander Viro wrote: ctlfd = open_device_control_fd(fd); If fd is something that doesn't have a control interface (say, it already is a control filehandle), this returns an appropriate error code. It may have several. Which one? That's why I proposed using multi-stream files. With a syscall like fd2 = open_substream(fd, somename) you could have several control streams and also be prepared if you want to support multi-stream filesystems like NTFS in the future... BTW: how does this work in NT? Do you first open a file and then fork it like in my example, do they have a special open for substreams or is the substream always encoded in the filename? bye... - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, 20 May 2001, Tim Jansen wrote: That's why I proposed using multi-stream files. With a syscall like fd2 = open_substream(fd, somename) You also have streams thay are related to many device nodes at once. Sorry. you could have several control streams and also be prepared if you want to support multi-stream filesystems like NTFS in the future... Let's _not_ bring that into this thread, OK? - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: On 20 May 2001, Kai Henningsen wrote: I've seen this question several times in this thread. I haven't seen the obvious answer, though. Have a new system call: ctlfd = open_device_control_fd(fd); If fd is something that doesn't have a control interface (say, it already is a control filehandle), this returns an appropriate error code. It may have several. Which one? Can you explain better this? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Mon, May 21, 2001 at 12:05:20AM +1000, Andrew Morton wrote: Andrea Arcangeli wrote: [ cc'ed to l-k ] DMA-mapping.txt assumes that it cannot fail. DMA-mapping.txt is wrong. Both pci_map_sg and pci_map_single failed if they returned zero. You either have to drop the skb or to try again later if they returns zero. Well this is news to me. No drivers understand this. Yes, almost all drivers are buggy. How long has this been the case? What platforms? Always and all platforms. Just think about this, you have 2^32 of bus address space, and you theoritically can start I/O for more than 2^32 of phys memory, see? Whatever platform it is it will never be able to guarantee all mappings to succeed. For netdevices at least, the pci_map_single() call is always close to the site of the skb allocation. So what we can do is to roll them together and use the existing oom-handling associated with alloc_skb(), assuming the driver has it... Fine. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, 20 May 2001, Abramo Bagnara wrote: It may have several. Which one? Can you explain better this? Example: console. You want to be able to pass font changes. I'm less than sure that putting them on the same channel as, e.g., keyboard mapping changes is a good idea. We can do it, but I don't see why it's natural thing to do. Moreover, you already have /dev/vcsn and /dev/vcsan. Can you explain what's the difference between them (per-VC channels) and keyboard mapping (also per-VC)? Face it, we _already_ have more than one side band. Moreover, we have channels that are not tied to a particular device - they are for a group of them. Example: setting timings for IDE controller. Sure, we can just say open /dev/hda instead of /dev/hda5, but then we are back to the find related file problem you tried to avoid. - 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: RTL8139 difficulties in 2.2, not in 2.4
On Sun, 20 May 2001, Matthias Andree wrote: eth1: Transmit timeout, status 0c 0005 media 18. It looks like I found a workaround which may help you debugging, if new questions arise, please ask. Willing to help so this issue can be resolved for Linux 2.2.20. 1. I'm compiling my eth drivers as modules. 2. I alias eth0 to 3c59x and eth1 to either 8139too or rtl8139 (doesn't matter); my rtl8139 is the current version 1.13 from scyld.com 3. after X has come up, I issue ifconfig eth1 down; rmmod rtl8139 (or 8139too, depending on what modules.conf says) 4. I do ifconfig eth1 up (pppoe with Deutsche Telekom AG doesn't require IP, just raw ethernet) 5. I launch pppd which runs pppoe, the problems are gone. I haven't yet checked if after this procedure, 3D graphics work out, I don't have current NVidia drivers here, just plain XFree 4.0.3 as packaged by SuSE. - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: On Sun, 20 May 2001, Abramo Bagnara wrote: It may have several. Which one? Can you explain better this? Example: console. You want to be able to pass font changes. I'm less than sure that putting them on the same channel as, e.g., keyboard mapping changes is a good idea. We can do it, but I don't see why it's natural thing to do. Moreover, you already have /dev/vcsn and /dev/vcsan. Can you explain what's the difference between them (per-VC channels) and keyboard mapping (also per-VC)? Face it, we _already_ have more than one side band. This does not imply it's necessarily a good idea. We are comparing echo 9600 /proc/self/fd/0/speed (or /dev/ttyS0/speed) echo 8 /proc/self/fd/0/bits (or /dev/ttyS0/bits) with echo -e speed 9600\nbits 8 /proc/self/fd/0/ioctl (or /dev/ttyS0/ioctl). My personal preference goes to the latter, but it's a matter of taste (and convention choice) (echo -n keymap ; cat keymap) /dev/tty1/ioctl (echo -n font ; cat font) /dev/tty1/ioctl This seems ugly to you? Moreover, we have channels that are not tied to a particular device - they are for a group of them. Example: setting timings for IDE controller. Sure, we can just say open /dev/hda instead of /dev/hda5, but then we are back to the find related file problem you tried to avoid. It does not seems appropriate to permit to change IDE timings using an handle to a partition... nor it seems very safe under a permissions point of view. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG ? and questions
Hello My name is Calin I have a Cx 486/66 with 12 Megs of ram AST computer gcc 2.95.3, glibc 2.1.3, make 3.79.1 binutils 2.11 ?? Problems: 1. When I try to run multiple (2) compilations on a 2.4.4 kernel usually one of them dies -- if it's gcc - signal 11 , if it's sh or rarely make - segmentation fault. It is not a hardware problem (with kernel 2.2.x it does not do this and I have a cooler on my cpu) 2. I compiled a kernel 2.4.3 with XFS and sound as a module (I use alsa sound driver), and when I try to insmod soundcore.o it says about some unresolved symbols (one of them is printk ) I don't have this problem with any of the originals 2.4.x kernels (downloaded from kernel.org) Questions: 1. I have a vlb system and the kernel does not report an IDE controler I presume there is one. Is there a way to find out what type it is because a read about buggy 486 motherboards and I want to be sure that mine is not (It does not seems to be -- I have my system from about a year and a half and I have no problems ) 2. I saw in .config in the root of kernel tree #CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set ; the same for IBM, Maxtor etc. If I set this will be any performance inprovements ? 3. I noticed that if I compile RTC in the kernel my system runs smootly ? Is this just an illusion ? Sorry for bothering you Sorry if the questions are silly Bye __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, 20 May 2001, Abramo Bagnara wrote: Face it, we _already_ have more than one side band. This does not imply it's necessarily a good idea. We are comparing echo 9600 /proc/self/fd/0/speed (or /dev/ttyS0/speed) echo 8 /proc/self/fd/0/bits (or /dev/ttyS0/bits) with echo -e speed 9600\nbits 8 /proc/self/fd/0/ioctl (or /dev/ttyS0/ioctl). How about reading from them? You are forcing restriction that may make sense in some cases, but doesn't look good for everything. Moreover, we have channels that are not tied to a particular device - they are for a group of them. Example: setting timings for IDE controller. Sure, we can just say open /dev/hda instead of /dev/hda5, but then we are back to the find related file problem you tried to avoid. It does not seems appropriate to permit to change IDE timings using an handle to a partition... nor it seems very safe under a permissions point of view. However, we _do_ allow that. Right now. And yes, I agree that we should go to separate file for that. And we are right back to finding a related file. It's not a function of descriptor. Sorry. Just as with /dev/tty1 - /dev/vcs1 and its ilk. - 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: CML2 design philosophy heads-up
David Woodhouse [EMAIL PROTECTED]: The dependencies in CML1 are (supposed to be) absolute - the 'advisory' dependencies you're adding are arguably a useful feature, but please don't make it possible to confuse the two, and please do make sure it's possible to disable the latter form. I don't understand this request. I have no concept of `advisory' dependencies. What are you talking about? Is my documentation horribly unclear? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Both oligarch and tyrant mistrust the people, and therefore deprive them of arms. --Aristotle - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, May 20, 2001 at 10:45:07AM -0400, Alexander Viro wrote:
On Sun, 20 May 2001, Abramo Bagnara wrote:
It may have several. Which one?
Can you explain better this?
Example: console. You want to be able to pass font changes. I'm
less than sure that putting them on the same channel as, e.g.,
keyboard mapping changes is a good idea. We can do it, but I don't
see why it's natural thing to do. Moreover, you already have
/dev/vcsn and /dev/vcsan. Can you explain what's the difference
between them (per-VC channels) and keyboard mapping (also per-VC)?
Face it, we _already_ have more than one side band.
Wouldn't it be natural to
write(fd, control type)
write(fd, control information)
read(fd, reply)
Only one control file for all controls a device understands
Moreover, we have channels that are not tied to a particular device -
they are for a group of them. Example: setting timings for IDE controller.
Sure, we can just say open /dev/hda instead of /dev/hda5, but then we
are back to the find related file problem you tried to avoid.
If the IDE controller is a device we can control, it should have a device
file and a control device file.
Problem solved, AFAICS.
Controlling an IDE controller by writing to a device that's hanging on one
of it's busses is a hack, IMO.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
On Sun, 20 May 2001 11:18:56 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: David Woodhouse [EMAIL PROTECTED]: The dependencies in CML1 are (supposed to be) absolute - the 'advisory' dependencies you're adding are arguably a useful feature, but please don't make it possible to confuse the two, and please do make sure it's possible to disable the latter form. I don't understand this request. I have no concept of `advisory' dependencies. What are you talking about? Is my documentation horribly unclear? People read documentation? No chance. Some people have got it into their heads that the Aunt Tillie method of configuration will be the only one allowed. They do not realise that this is the novice method, experts can still do what they like. For dwm's advisory dependencies, read novice mode, and of course it can be overridden by people who know what they are doing. - 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/
question: permission checking for network filesystem
Hi, I'm trying to impelemnt a lightweight network filesystem and ran into trouble implementing lookup, permissions and open. The protocol requires me to specify open mode in it's open command. The open mode has 4 bits: read, write, append and execute. But I can't tell execution from read in file_operations-open. I could send the open command from the inode_operations-permission, but this does not solve the problem, as I can't find weather to count the new file descriptor as reader or executer (I have to know that when closing the file). The server always checks permission on the actual request, so I can't open the file for reading, when it should be open for execution. Could anyone see a solution other than adding a flags to open mode (say O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec and sys_uselib? I don't like the idea of pathing vfs for this. If it has to be patched, what kind of patch has a chance to get into 2.4 series kernel? There is another thing with lookup. The protocol allows looking up and opening a file in one command. Unfortunately there are some file-type checks between i_ops-lookup and f_ops-open that force me to wait on the lookup to finish before I can open. I think these checks could be done by simply having the f_ops-open set correctly (thinks like not opening directory for write). But I do not expect these to change before 2.5, right? Thanks in advance. Bulb - Jan Hudec `Bulb' [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
[EMAIL PROTECTED] said: I don't understand this request. I have no concept of `advisory' dependencies. What are you talking about? Is my documentation horribly unclear? By 'dependency' I refer to the case where the value of one symbol is derived entirely from, or the range of possible values is limited by, the value of another symbol. There are differing reasons for this, which should be treated entirely separately. On one hand you have dependencies which are present to make life easier for Aunt Tillie, by refraining from confusing her with strange questions to which the answer is _probably_ 'no'. Like the question of whether she has an IDE controller on her MVME board. One the other hand, you have the dependencies present in the existing CML1 configuration, which are _absolute_ dependencies - which specify for example that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc. These dependencies are there to prevent you from enabling combinations of options which are utterly meaningless, and usually won't even compile. The former type of dependency should^HMUST be optional. Those who know what they're doing will want to turn them off. I see a lot of boards based on some reference design or other but with a few tweaks and added or removed devices - that's what the reference designs are there for; after all. By making a distinction between the two types of dependency in the configuration language, you can pander to Aunt Tillie without actually getting on the tits of those who don't wish to be arbitrarily restricted from enabling support for the device they _know_ is present because they just soldered it to the blinkin' circuit board. :) -- dwmw2 - 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: CML2 design philosophy heads-up
David Woodhouse [EMAIL PROTECTED]: On one hand you have dependencies which are present to make life easier for Aunt Tillie, by refraining from confusing her with strange questions to which the answer is _probably_ 'no'. Like the question of whether she has an IDE controller on her MVME board. One the other hand, you have the dependencies present in the existing CML1 configuration, which are _absolute_ dependencies - which specify for example that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc. These dependencies are there to prevent you from enabling combinations of options which are utterly meaningless, and usually won't even compile. There are no `advisory' dependencies in CML2. They're all absolute. What you call an `advisory' dependency would be simulated by having a policy symbol for Aunt Tillie mode and writing constraints like this: require AUNT_TILLIE implies FOO = BAR This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING policy symbols, as hooks for doing things like this. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a No one who's seen it in action can say the phrase government help without either laughing or crying. - 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: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote: I'm not sure why that helps. I didn't put it in as a trick or anything though. I put it in because it didn't seem like a good idea to ever have more cleaned pages than free pages at a time when we're yammering for help.. so I did that and it helped. The rationale for this is easy: free pages is wasted memory, clean pages is hot, clean cache. The best state a cache can be in. Regards Ingo Oeser -- To the systems programmer, users and applications serve only to provide a test load. - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, 20 May 2001, [iso-8859-1] Jakob Østergaard wrote: Face it, we _already_ have more than one side band. Wouldn't it be natural to write(fd, control type) write(fd, control information) read(fd, reply) Only one control file for all controls a device understands That's one of the ways to do it. However, it's less than ideal when you want to mix access to such channels. Again, look at font and screen contents of VC. You can force everything into that model. It even makes sense for many cases. Not all of them, though and any solution for the rest will handle the special case. Example of such solution (_not_ for sockets - they are very different) readlink() on /proc/self/fd/n, then replace everything past the last /. BTW, that way you can bind a device into chroot jail, but leave some subset of channels out of it. Or all of them. Just don't bind the side channels there. Moreover, we have channels that are not tied to a particular device - they are for a group of them. Example: setting timings for IDE controller. Sure, we can just say open /dev/hda instead of /dev/hda5, but then we are back to the find related file problem you tried to avoid. If the IDE controller is a device we can control, it should have a device file and a control device file. Problem solved, AFAICS. Sure, but the same logics applies to /proc/self/fd/n/ioctl. Yes, sometimes you need to figure out the name of related file. Depends on situation. Saying that we have one very special related file that corresponds to current ioctls looks rather bogus. - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
Alexander Viro wrote: On Sun, 20 May 2001, Abramo Bagnara wrote: Face it, we _already_ have more than one side band. This does not imply it's necessarily a good idea. We are comparing echo 9600 /proc/self/fd/0/speed (or /dev/ttyS0/speed) echo 8 /proc/self/fd/0/bits (or /dev/ttyS0/bits) with echo -e speed 9600\nbits 8 /proc/self/fd/0/ioctl (or /dev/ttyS0/ioctl). How about reading from them? You are forcing restriction that may make sense in some cases, but doesn't look good for everything. exec 3/dev/ttyS0/ioctl exec 43 echo speed 3 cat 4 exec 3- exec 4- Can you make a counter example where this doesn't look good? Moreover, we have channels that are not tied to a particular device - they are for a group of them. Example: setting timings for IDE controller. Sure, we can just say open /dev/hda instead of /dev/hda5, but then we are back to the find related file problem you tried to avoid. It does not seems appropriate to permit to change IDE timings using an handle to a partition... nor it seems very safe under a permissions point of view. However, we _do_ allow that. Right now. And yes, I agree that we should go to separate file for that. And we are right back to finding a related file. I'd prefer to make what you often call a crapectomy: no IDE timing change using a partition handle. It's something like to permit that on a LVM handle, it's stupid... About tty and vcs split: there the problem is more subtle and it's related to a missing separation of keyboard and screen. After to have done this choice (i.e. to have the some behaviour of serial port) someone has realized that to read from console screen it's a sensible action (to fetch current content). This is the typical case where to have /dev/tty1/ioctl does not substitute to have another device for console screen reading. Note that it's a *different* device (different permission, etc.). -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
[EMAIL PROTECTED] said: There are no `advisory' dependencies in CML2. They're all absolute. What you call an `advisory' dependency would be simulated by having a policy symbol for Aunt Tillie mode and writing constraints like this: require AUNT_TILLIE implies FOO = BAR This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING policy symbols, as hooks for doing things like this. Excellent. Then I apologise for not reading the documentation. After the discussion of MAC and SCSI config options many moons ago in this thread, I was left with the impression that the constraints which were being objected to were not dependent upon a NOVICE mode, but were unconditional. Was this merely a mistake in the conversion of the ruleset? Do you have a policy that the default behaviour should be similar to that of CML1, or at least that such behaviour should be available through one of the modes? If not, please consider doing so. -- dwmw2 - 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: LANANA: To Pending Device Number Registrants
At 3:37 AM -0600 2001-05-20, Eric W. Biederman wrote: Jonathan Lundell [EMAIL PROTECTED] writes: At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote: Jeff Garzik's ethtool extension at least tells me the PCI bus/dev/fcn, though, and from that I can write a userland mapping function to the physical location. I don't see how PCI bus/dev/fcn lets you do that. I know from system documentation, or can figure out once and for all by experimentation, the correspondence between PCI bus/dev/fcn and physical locations. Jeff's extension gives me the mapping between eth# and PCI bus/dev/fcn, which is not otherwise available (outside the kernel). Just a second let me reenumerate your pci busses, and change all of the bus numbers. Not that this is a bad thought. It is just you need to know the tree of PCI busses/bridges up to the root on the machine in question. Yes, you do. And it's true that renumbering is problematical; I hadn't thought of all the implications. Say, you have a system with hot-plug slots on two buses, and someone hot-plugs a card with a bridge (fairly common; most dual/quad Ethernet boards have a bridge). If the buses were numbered densely to begin with, they're going to have to be renumbered above the point that the new bridge was added. Phooey. Well, it can still be done, but it's a bit more complicated than the bus/dev/fcn-to-location map I was imagining. You'd have to describe the topology of the built-in buses, and dynamically make the correspondences. As you say, know the tree, by topology, not bus numbers. -- /Jonathan Lundell. - 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: LANANA: To Pending Device Number Registrants
At 2:16 AM +1200 2001-05-21, Chris Wedgwood wrote: On Sat, May 19, 2001 at 10:36:14AM -0700, Jonathan Lundell wrote: I know from system documentation, or can figure out once and for all by experimentation, the correspondence between PCI bus/dev/fcn and physical locations. Jeff's extension gives me the mapping between eth# and PCI bus/dev/fcn, which is not otherwise available (outside the kernel). Won't work with hotplug PCI (consider plugging in something with a bridge). It's true that hotplug devices make it more complicated, but I think the result can be achieved by describing the correspondence topologically rather than as a simple b/d/f-to-location table. -- /Jonathan Lundell. - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, 20 May 2001, Abramo Bagnara wrote: How about reading from them? You are forcing restriction that may make sense in some cases, but doesn't look good for everything. exec 3/dev/ttyS0/ioctl exec 43 echo speed 3 cat 4 exec 3- exec 4- Can you make a counter example where this doesn't look good? If in your opinion it looks good... Again, you are forcing the policy decision on a lot of interfaces. For no good reason, AFAICS. However, we _do_ allow that. Right now. And yes, I agree that we should ^^ go to separate file for that. And we are right back to finding a related file. I'd prefer to make what you often call a crapectomy: no IDE timing change using a partition handle. It's something like to permit that on a LVM handle, it's stupid... Sigh... Sure, but so is the magic way to get ioctl descriptor by file descriptor. They are two separate files. End of story. Yes, they are related - provided by the same driver. Look, emulating ioctl(2) via write(2) is _not_ the goal. We will have to keep that syscall, for binary compatibility reasons if nothing else. We can start fixing the applications that use Linux-only ioctls (and that pretty much means that we'll have to leave the networking ones alone for quite a while). What _is_ interesting is a sane API that could be used instead of the current mess with device ioctls. There's only one reason to go for fs/n/ioctl scheme - mass conversion of applications with little to no thinking. Not going to happen. Simply because you'll need to switch arguments in many of these cases. About tty and vcs split: there the problem is more subtle and it's related to a missing separation of keyboard and screen. After to have done this choice (i.e. to have the some behaviour of serial port) someone has realized that to read from console screen it's a sensible action (to fetch current content). This is the typical case where to have /dev/tty1/ioctl does not substitute to have another device for console screen reading. Note that it's a *different* device (different permission, etc.). And your ioctl is different from that because...? I can certainly see good reasons to restrict user to some subsets functionality provided by ioctls - BTW, one more reason why multiple related channels are good. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG ? and questions
I have a Cx 486/66 with 12 Megs of ram AST computer gcc 2.95.3, glibc 2.1.3, make 3.79.1 binutils 2.11 ?? Problems: 1. When I try to run multiple (2) compilations on a 2.4.4 kernel usually one of them dies -- if it's gcc - signal 11 , if it's sh looks like an out-of-memory (OOM) kill. Check your log files. (var/log/messages but can vary on some distributions) 12 MB of RAM is not enough for Kernel 2.4.4 and several gcc runs, as some gcc optimizations have complexity of O(n^2) or higher. greetings Christian Bornträger - 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: alpha iommu fixes
On Sun, May 20, 2001 at 03:49:58PM +0200, Andrea Arcangeli wrote: they returned zero. You either have to drop the skb or to try again later if they returns zero. BTW, pci_map_single is not a nice interface, it cannot return bus address 0, so once we start the fixage it is probably better to change the interface as well to get either the error or the bus address via a pointer passed to the function. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
Andrea Arcangeli wrote: On Sun, May 20, 2001 at 03:49:58PM +0200, Andrea Arcangeli wrote: they returned zero. You either have to drop the skb or to try again later if they returns zero. BTW, pci_map_single is not a nice interface, it cannot return bus address 0, so once we start the fixage it is probably better to change the interface as well to get either the error or the bus address via a pointer passed to the function. Would it not be sufficient to define a machine-specific macro which queries it for error? On x86 it would be: #define BUS_ADDR_IS_ERR(addr) ((addr) == 0) I can't find *any* pci_map_single() in the 2.4.4-ac9 tree which can fail, BTW. - - 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/
start_thread question...
I'm implementing start_thread for the VAX port and am wondering does start_thread have to return to load_elf_binary? I'm working on the init thread and what is happening is it is returning the whole way back to the execve caller .. which I know shouldn't happen. so I suppose what I'm looking for is the point where the user space code gets control... is it when the registers are set in the start_thread? if so how does start_thread return On the VAX we have to call a return from interrupt to get to user space and I'm trying to figure out where this should happen... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person - 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: alpha iommu fixes
On Mon, May 21, 2001 at 02:21:18AM +1000, Andrew Morton wrote: Andrea Arcangeli wrote: Would it not be sufficient to define a machine-specific macro which queries it for error? On x86 it would be: #define BUS_ADDR_IS_ERR(addr) ((addr) == 0) that would be more flexible at least, however not mixing the error with a potential bus address still looks cleaner to me. I can't find *any* pci_map_single() in the 2.4.4-ac9 tree which can fail, BTW. I assume you mean that no one single caller of pci_map_single is checking if it failed or not (because all pci_map_single can fail). Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5pre2aa1 panic during boot
The attached .config file created a working kernel for 2.4.2. Now, with the one compiled from 2.4.5pre2aa1, it only gives kernel panic during boot with the following message: Kernel panic: Attempted to kill the idel task In idle task -- not syncing This happened on LX164 with AlphaBIOS running SuSE-7.0, gcc-2.95.2-136. Almost identical .config file created a working kernel for UP2000 SMP. So, what is wrong with LX164? Should I dump this old ALpha now? Andrea told us that he will not care for anything compiled with gcc-2.95 or version lower than that. However, it seems that this kernel panic has anything to do with gcc-2.95. Anyway, gcc-2.95 is still the official release of gcc. Even SuSE-7.1 has this version only. I wish SuSE puts something higher than 2.95 in their web site somewhere. Best regards, Hugh # # Automatically generated make config: don't edit # CONFIG_ALPHA=y # CONFIG_UID16 is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # General setup # # CONFIG_ALPHA_GENERIC is not set # CONFIG_ALPHA_ALCOR is not set # CONFIG_ALPHA_XL is not set # CONFIG_ALPHA_BOOK1 is not set # CONFIG_ALPHA_AVANTI is not set # CONFIG_ALPHA_CABRIOLET is not set # CONFIG_ALPHA_DP264 is not set # CONFIG_ALPHA_EB164 is not set # CONFIG_ALPHA_EB64P is not set # CONFIG_ALPHA_EB66 is not set # CONFIG_ALPHA_EB66P is not set # CONFIG_ALPHA_EIGER is not set # CONFIG_ALPHA_JENSEN is not set CONFIG_ALPHA_LX164=y # CONFIG_ALPHA_MIATA is not set # CONFIG_ALPHA_MIKASA is not set # CONFIG_ALPHA_NAUTILUS is not set # CONFIG_ALPHA_NONAME is not set # CONFIG_ALPHA_NORITAKE is not set # CONFIG_ALPHA_PC164 is not set # CONFIG_ALPHA_P2K is not set # CONFIG_ALPHA_RAWHIDE is not set # CONFIG_ALPHA_RUFFIAN is not set # CONFIG_ALPHA_RX164 is not set # CONFIG_ALPHA_SX164 is not set # CONFIG_ALPHA_SABLE is not set # CONFIG_ALPHA_TAKARA is not set # CONFIG_ALPHA_TITAN is not set # CONFIG_ALPHA_WILDFIRE is not set CONFIG_ISA=y CONFIG_EISA=y # CONFIG_SBUS is not set # CONFIG_MCA is not set CONFIG_PCI=y CONFIG_ALPHA_EV5=y CONFIG_ALPHA_CIA=y CONFIG_ALPHA_PYXIS=y # CONFIG_ALPHA_SRM is not set CONFIG_DISCONTIGMEM=y CONFIG_NUMA=y CONFIG_NUMA_SCHED=y # CONFIG_ALPHA_LARGE_VMALLOC is not set CONFIG_PCI_NAMES=y # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_NET=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_BINFMT_EM86 is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_RAM is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set CONFIG_BLK_DEV_LVM=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set CONFIG_NET_FASTROUTE=y # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_COMMERIAL is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_ISAPNP is not set #
Re: alpha iommu fixes
Andrea Arcangeli wrote: I can't find *any* pci_map_single() in the 2.4.4-ac9 tree which can fail, BTW. I assume you mean that no one single caller of pci_map_single is checking if it failed or not (because all pci_map_single can fail). No. Most of the pci_map_single() implementations just use virt_to_bus()/virt_to_phys(). Even sparc64's fancy iommu-based pci_map_single() always succeeds. - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
Obviously there has to be some standard base with which to work, especially for computer language keywords as these can't be converted due to name clashes. What would be cool is to pick a better base language than English that everyone would have to learn to use computers. This is especially important for opensource as it would greatly ease the operation of the collective brain. Something easily parseable would be an obvious criterion and would allow us to interact with computers by voice(-recognition) with no ambiguity, etc. etc... tada: http://www.lojban.org/ will everything be changed over in the 2.5 timeframe? :-) Padraig. Ingo Oeser wrote: On Sat, May 19, 2001 at 11:34:48AM -0700, Linus Torvalds wrote: [Reasons] So the English is bad argument is a complete non-argument. Jepp, I have to agree. English is used more or less as an communication protocol in computer science and for operating computers. Once you know how to operate an computer in English, you can operate nearly every computer in the world, because they have English as default locale. Let's not repeat Babel please :-( PS: English is neither mine, nor Linus native language. Why do the English natives complain instead of us? ;-) off topic side note And be glad that's not German, that has this role. English sentences are WAY easier to parse by computers, because it doesn't use much suffixes and prefixes on words and has very few exceptions. Also these exceptions are eleminated from command languages WITHOUT influencing readability and comprehensability. /off topic side note Regards Ingo Oeser - 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: alpha iommu fixes
On Mon, May 21, 2001 at 02:54:16AM +1000, Andrew Morton wrote: No. Most of the pci_map_single() implementations just use virt_to_bus()/virt_to_phys(). [..] then you are saying that on the platforms without an iommu the pci_map_* cannot fail, of course, furthmore even a missing pci_unmap cannot trigger an iommu address space leak on those platforms. That has nothing to do with the fact pci_map_single can fail or not, the device drivers are not architectural specific. [..] Even sparc64's fancy iommu-based pci_map_single() always succeeds. Whatever sparc64 does to hide the driver bugs you can break it if you pci_map 4G+1 bytes of phyical memory. Otherwise it means it's sleeping or looping inside the pci_map functions which would break things in another manner. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: start_thread question...
On Sun, 20 May 2001, Dave Airlie wrote: I'm implementing start_thread for the VAX port and am wondering does start_thread have to return to load_elf_binary? I'm working on the init thread and what is happening is it is returning the whole way back to the execve caller .. which I know shouldn't happen. start_thread() doesnt do what one would intuitively think it does. start_thread() simply prepares the new task's register set to be ready to start user-space (which task is the current task as well, so certain current CPU registers might have to be manually bootstrapped as well), but start_thread() does not actually start execution of user-space code yet. (a more correct name for start_thread() would be prepare_user_thread().) so I suppose what I'm looking for is the point where the user space code gets control... is it when the registers are set in the start_thread? if so how does start_thread return execution starts when the process returns from sys_execve(). By that time we have already changed pagetables and other context information, dropped basically everything from the previous context - without actually doing a context-switch. In fact sys_execve() has an implicit context-switch, without ever changing the kernel-stack though. On the VAX we have to call a return from interrupt to get to user space and I'm trying to figure out where this should happen... this is how it happens on x86 too. Basically you start the new binary by returning from an syscall that has bootstrapped all userspace context - this approach should work on any architecture. (because every architecture has to be able to execute user-space code after syscalls.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]
Alexander Viro [EMAIL PROTECTED] writes: [...] We have ~180 first-order ioctl() methods. Several (my guess would be Hehe. I suppose you already know about the way strace (@sourceforge) kind of automatically tries to figure out the args for the common ones? [...] -- http://ape.n3.net - 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: alpha iommu fixes
Andrea Arcangeli wrote: On Sun, May 20, 2001 at 03:49:58PM +0200, Andrea Arcangeli wrote: they returned zero. You either have to drop the skb or to try again later if they returns zero. BTW, pci_map_single is not a nice interface, it cannot return bus address 0, who says? A value of zero for the mapping is certainly an acceptable value, and it should be handled by drivers. In fact its an open bug in a couple net drivers that they check the mapping to see if it is non-zero... -- Jeff Garzik | Do you have to make light of everything?! Building 1024| I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes. - 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/
Background to the argument about CML2 design philosophy
Those of you who have become confused about the current argument over CML2 should read this... David Woodhouse [EMAIL PROTECTED]: After the discussion of MAC and SCSI config options many moons ago in this thread, I was left with the impression that the constraints which were being objected to were not dependent upon a NOVICE mode, but were unconditional. Was this merely a mistake in the conversion of the ruleset? Do you have a policy that the default behaviour should be similar to that of CML1, or at least that such behaviour should be available through one of the modes? If not, please consider doing so. They were unconditional. It looks like a recap of history is in order. Until very recently, like ten days ago, I had a policy of altering the CML1 behavior as little as possible while I got CML2 up and running. Some change had been inevitable because of the move to a single-apex menu tree, but I tried to hold that to a minimum. But I have reached a point where the configurator codebase is stable and works as a drop-in install on top of a stock kernel tree. I'm not even getting requests for UI tweaks any more. So the CML2 engine is essentially done (modulo the occasional minor bugfix). This made it time to start thinking about tuning the rulesfile to make configuration easier. At the same time, I was dealing with another problem; missing entries in Configure.help. When I got handed the maintainer's baton, there were 547 of these. I have written outright over 300 new ones; Steven Cole and I have collected another 50 or so. To reduce the problem further, I looked for symbols with missing entries that I could turn into derivations, eliminating their questions and the requirement for a help entry. (A CML2 derivation is like a CML1 define; it's a formula that sets a symbol from the value of other symbols without user input.) The first candidates I found were questions associated with built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Sun3x, and with built-in facilities on the MVME147 single-board computer. So I wrote derivations that looked like this: # These were separate questions in CML1. They enable on-board peripheral # controllers in single-board computers. derive MVME147_NET from MVME147 NET_ETHERNET derive MVME147_SCC from MVME147 SERIAL derive MVME147_SCSI from MVME147 SCSI derive MVME16x_NET from MVME16x NET_ETHERNET derive MVME16x_SCC from MVME16x SERIAL derive MVME16x_SCSI from MVME16x SCSI derive BVME6000_NET from BVME6000 NET_ETHERNET derive BVME6000_SCC from BVME6000 SERIAL derive BVME6000_SCSI from BVME6000 SCSI # These were separate questions in CML1 derive MAC_SCC from MAC SERIAL derive MAC_SCSI from MAC SCSI derive SUN3_SCSI from (SUN3 | SUN3X) SCSI By doing this I killed two birds with one stone -- got rid of some holes in Configure.help and (more importantly) moved the configuration experience away from low-level, hardware-oriented questions towards where I think it ought to be. That is, you specify a platform and the services you want and the ruleset computes the low-level facilities to be linked in. This represented a change in the design philosophy of the ruleset, not something I wanted to do without input from the developers and port managers. So I broadcast CML2 design philosophy heads up. After some back-and-forthing about the technical facts, several things emerged: 1. The Mac derivations were half-right. The MAC_SCC one is good but Macs can have either of two different SCSI controllers. I fixed that with help from Ray Knight, who maintains the 68K Mac port. 2. Nobody had a problem with the SUN3_SCSI derivation. 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. (I missed these possibilities when I wrote the derivations.) I used case 3 to explore a touchy question about design philosophy, which is really what caused all hell to break loose. The question is this: holding down configuration complexity is a good thing, but supporting all hardware configurations that are conceivably possible is also a good thing. How should we trade these good things off against one another? The MVME situation is an almost perfect test case, because while breaking the assumption behind that derivation is physically possible it would be a rather perverse thing to do. The VME147 is an old design, dating from 1988; it's long since been superseded by MPCxxx SBCs based on the PowerPC that have a better processor, lower power consumption, and more on-board peripheral hardware. IDE/ATAPI didn't exist during most of its design lifetime, and the only way anyone is ever going to hook an outboard device to one of these puppies again is if some hacker pulls a dusty one off a shelf for some garage project. So
tcp_mem problem
the system with problem is using kernel 2.4.2 on an P200 with 64mb ram. It has about 20 users that use the box... (ftp, telnet, lynx, bitchx,...). the problem is when the parameter tcp_mem HIGH gets exeded after about a day of use! Then the box is going from the net and its not awailable. I tried to tune the system with adding more in proc tcp_mem but the problem is still there the box only lasts for bout 2h longer. and i get this in messages kernel: TCP: too many of orphaned sockets It looks like my system is not droping closed sockets? David - 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: [RFC][PATCH] Re: Linux 2.4.4-ac10
Mike Galbraith [EMAIL PROTECTED] writes: Hi, On Fri, 18 May 2001, Stephen C. Tweedie wrote: That's the main problem with static parameters. The problem you are trying to solve is fundamentally dynamic in most cases (which is also why magic numbers tend to suck in the VM.) Magic numbers might be sucking some performance right now ;-) [snip] I like your patch, it improves performance somewhat and makes things more smooth and also code is simpler. Anyway, 2.4.5-pre3 is quite debalanced and it has even broken some things that were working properly before. For instance, swapoff now deadlocks the machine (even with your patch applied). Unfortunately, I have failed to pinpoint the exact problem, but I'm confident that kernel goes in some kind of loop (99% system time, just before deadlock). Anybody has some guidelines how to debug kernel if you're running X? Also in all recent kernels, if the machine is swapping, swap cache grows without limits and is hard to recycle, but then again that is a known problem. -- Zlatko - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5pre2aa1 panic during boot
On Mon, May 21, 2001 at 01:59:25AM +0900, root wrote: Andrea told us that he will not care for anything compiled with gcc-2.95 or version lower than that. I said I don't care about bugreport of alpha kernel crashes if the _alpha_ kernel was compiled with gcc 2.95.*. 2.95 is fine on the x86, but it's broken on the alpha. In short: x86 2.4 kernels - use 2.95.[34] or egcs 1.1.2 (I use 2.95.4 from the gcc_2_95_branch of CVS) alpha 2.4 kernel- use egcs 1.1.2 or 2.96 with some houndred of patches (I personally still use the egcs 1.1.2) However, it seems that this kernel panic has anything to do with gcc-2.95. Please try to reproduce with egcs 1.1.2 to be sure. Anyway, gcc-2.95 is still the official release of gcc. Even SuSE-7.1 has this version only. I wish SuSE puts x86 and alpha are completly different issues with regard to the compiler. I never heard of problems with 2.95.4 on x86 and I would never replace 2.95.4 from the gcc_2_95_branch for the latest 2.96 on my x86 boxes, I'd instead try again gcc 3.0 after the inline asm fixes for += constranints on local variables are done. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Sun, May 20, 2001 at 01:16:25PM -0400, Jeff Garzik wrote: Andrea Arcangeli wrote: On Sun, May 20, 2001 at 03:49:58PM +0200, Andrea Arcangeli wrote: they returned zero. You either have to drop the skb or to try again later if they returns zero. BTW, pci_map_single is not a nice interface, it cannot return bus address 0, who says? A value of zero for the mapping is certainly an acceptable value, and it should be handled by drivers. this is exactly why I'm saying pci_map_single currently is ugly in declaring a retval of 0 as an error, because as you also explicitly said above bus address 0 is perfectly valid bus adress, so my whole point is that I'd prefer to change the API of pci_map_single to notify of faliure not returning 0 like it does right now in 2.4.5pre3 and all previous 2.4 kernels but via a parameter, so bus address zero returns a valid bus address as it should be just now (but it isn't right now). In fact its an open bug in a couple net drivers that they check the mapping to see if it is non-zero... if a driver is catching the faluire of pci_map_single by checking if the bus address returned is zero such driver is one of the few (or the only one) correct driver out there. As it stands right now a bus address of 0 means pci_map_single failed. For pci_map_sg if it returns zero it means it failed too. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Sun, 20 May 2001, Ivan Kokshaysky wrote: On Sun, May 20, 2001 at 04:40:13AM +0200, Andrea Arcangeli wrote: I was only talking about when you get the pci_map_sg failed because you have not 3 but 300 scsi disks connected to your system and you are writing to all them at the same time allocating zillons of pte, and one of your drivers (possibly not even a storage driver) is actually not checking the reval of the pci_map_* functions. You don't need a pte memleak to trigger it, even regardless of the fact I grown the dynamic window to 1G which makes it 8 times harder to trigger than in mainline. I think you're too pessimistic. Don't mix disks and controllers -- SCSI adapter with 10 drives attached is a single DMA agent, not 10 agents. If you're so concerned about Big Iron, go ahead and implement 64-bit PCI support, it would be right long-term solution. I'm pretty sure that high-end servers use mostly this kind of hardware. Oh, well. This doesn't mean that I'm disagreed with what you said. :-) Driver writers must realize that pci mappings are limited resources. The IOMMU code allocation strategy is designed to fail due to fragmentation as everything that performs contiguous allocations of variable quantities. I may add a test of pci_map_* return code in the sym53c8xx driver, but the driver will panic on failure. It is not acceptable to consider such kind of failure as a normal situation (returning some ?_BUSY status to the SCSI driver) for the following reasons: - IOs may be reordered and break upper layers assumptions. - Spurious errors and even BUS resets may happen. For now, driver methods that are requested to queue IOs are not allowed to wait for resources. Anyway, the pci_map_* interface is unable to wait. There are obviously ways to deal gracefully with such resource lack, but the current SCSI layer isn't featured for that. For example, a freeze/unfreeze mechanism as described in CAM can be implemented in order not to reorder IOs, and some mechanism (callback, resource wait, etc...) must be added to restart the operation when resource is likely to be available. IMO, the only acceptable fix in the current kernel is to perform IOMMU PTE allocations of a fixed quantity at a time, as limiting SG entry to fit in a single PAGE for example. Gérard. PS: May-be I should look how *BSD's handles IOMMUs. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 del_timer_sync oops in schedule_timeout
On Sat, 19 May 2001, Jacob Luna Lundberg wrote: This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in. Unable to handle kernel paging request at virtual address 78626970 this appears to be some sort of DMA-corruption or other memory scribble problem. hexa 78626970 is ASCII pibx, which shows in the direction of some sort of disk-related DMA corruption. we havent had any similar crash in del_timer_sync() for ages. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Ingo Oeser wrote: On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote: I'm not sure why that helps. I didn't put it in as a trick or anything though. I put it in because it didn't seem like a good idea to ever have more cleaned pages than free pages at a time when we're yammering for help.. so I did that and it helped. The rationale for this is easy: free pages is wasted memory, clean pages is hot, clean cache. The best state a cache can be in. Sure. Under low load, cache is great. Under stress, keeping it is not an option though ;-) We're at or beyond capacity and moving at a high delda V (people yammering for help). If you can recognize and kill the delta rapidly by dumping that which you are going to have to dump anyway, you save time getting back on your feet. (my guess as to why dumping clean pages does measurably help in this case) -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: Background to the argument about CML2 design philosophy
Thankyou for the clarification. [EMAIL PROTECTED] said: I used case 3 to explore a touchy question about design philosophy, which is really what caused all hell to break loose. The question is this: holding down configuration complexity is a good thing, but supporting all hardware configurations that are conceivably possible is also a good thing. How should we trade these good things off against one another? I think you already have the mechanism required to answer this - in NOVICE mode you disallow the strange choices, in EXPERT mode you allow them. Embedded boards are a special case in this respect - people add all manner of strange crap to the reference designs - believe me, I've seen the ways in which they can fuck it up and yet still they manage to amaze me sometimes. And because of the multitude of ways in which the monkeys who glue together these boards can fuck it up, often you really really want to ignore the on-board Ethernet, for example, and use the PCMCIA card you plugged in, because they actually managed to route the PCMCIA interrupt to an IRQ line, not a GPIO pin. [EMAIL PROTECTED] said: So the real question here is whether it is ever acceptable to say that a possible configuration is just silly and ruleset will ignore it, in order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is yes, sometimes is that on rare occasions like this one you might have to haul out a text editor to tweak something in your config. As I said earlier, there are two main cases which should be considered entirely separately. There are the cases which are insane, and which won't ever work, or probably even compile. Those should be hard-coded off in the ruleset and it should not be possible to enable them without hacking. For the cases where we just want to make life simpler for the users, the constraints should be dependent on the user mode. In NOVICE mode you hide them, in EXPERT mode you make them available. The current (CML1) solution has problems, and it only provides real support for a small range of people at the hacker end of the spectrum. Making CML2 useful for a far wider range of people is a laudable goal. But please take care to ensure that the set of people for whom CML2 is useful is a strict superset of those for whom CML1 was useful. In particular, please don't strive to make Aunt Tillie happy on the one occasion on which she configures her kernel at a cost of rendering CML2 less useful for those for whom kernel configuration is an every-day task. Once weighted appropriately, that tradeoff is particularly easy to decide upon. If you ever find yourself seriously suggesting that a developer would need to ditch CML2 and hack the config files directly in order to compile support for, for example, the DiskOnChip he just dropped into the DIL socket in his Ethernet card, then I would suggest that you have made a wrong choice somewhere down the road. Please backtrack and reconsider an earlier decision before you're eaten by a grue. We already have a distinction between config options which it's sensible to ask the user, and options for which you have to hack #defines in the source code. The options which I have put into drivers/mtd/Config.in are there because I _wanted_ the user to see them. The options which are hidden in the code are there because I made the opposite decision. There is a reasonably well-defined boundary for such things already, and it's found all over the kernel. Adding a new, higher boundary for Aunt Tillie is just fine - but please don't _move_ the existing one that most of us care about. -- dwmw2 - 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][CFT] selective nosuid/noexec/nodev
Folks, patch below (_completely_ untested) is a backport of
a neat stuff from namespace-patch.
It does (OK, is supposed to do) the following: make noexec, nosuid
and nodev properties of vfsmount, not superblock.
In other words, different instances of the same fs may differ in
these flags.
It has quite a few lovely uses. Example:
I'm sick and tired of a little skript k1dd13 wannabe (who happens to be
a son of $BIG_BOSS and thus is a holy cow). I want to make his $HOME
noexec (all public writable places already are). I don't want to
bother with giving him a partition of his own and I don't want to screw
normal users.
Solution:
mount --bind /home/little_wanker /home/little_wanker
mount -o remount,noexec /home/little_wanker
Opposite examples (selectively allowing exec or suid on subtrees of
fs that is otherwise noexec/nosuid) are along the same lines. We can
even do it for individual files ;-)
More serious applications may be in situations when we want to set a
chroot environment with selective (or global, for that matter)
removal/allowing suid/exec/dev without messing everything else.
Patch is pretty straightforward - in call cases when we did
IS_NOSUID(), etc. we have relevant struct vfsmount, so we can check
-mnt_flags instead of -s_flags. do_mount() separates these flags
from the rest and does the (obvious) right thing. That, and we have
to look both at -mnt_sb-s_flags and -mnt_flags when we read from
/proc/mounts.
You are welcome to play with it ;-) Its equivalent works fine
in full namespace patch. This is a backport, and all I promise is
that it builds. Help with testing is welcome.
Al
diff -urN S5-pre4/arch/sparc64/solaris/fs.c S5-pre4-noexe/arch/sparc64/solaris/fs.c
--- S5-pre4/arch/sparc64/solaris/fs.c Thu Feb 22 06:47:53 2001
+++ S5-pre4-noexe/arch/sparc64/solaris/fs.c Sun May 20 12:50:36 2001
@@ -406,21 +406,21 @@
u32 f_filler[16];
};
-static int report_statvfs(struct inode *inode, u32 buf)
+static int report_statvfs(struct vfsmount *mnt, struct inode *inode, u32 buf)
{
struct statfs s;
int error;
struct sol_statvfs *ss = (struct sol_statvfs *)A(buf);
- error = vfs_statfs(inode-i_sb, s);
+ error = vfs_statfs(mnt-mnt_sb, s);
if (!error) {
- const char *p = inode-i_sb-s_type-name;
+ const char *p = mnt-mnt_sb-s_type-name;
int i = 0;
int j = strlen (p);
if (j 15) j = 15;
if (IS_RDONLY(inode)) i = 1;
- if (IS_NOSUID(inode)) i |= 2;
+ if (mnt-mnt_flags MNT_NOSUID) i |= 2;
if (put_user (s.f_bsize, ss-f_bsize) ||
__put_user (0, ss-f_frsize) ||
__put_user (s.f_blocks, ss-f_blocks) ||
@@ -440,21 +440,21 @@
return error;
}
-static int report_statvfs64(struct inode *inode, u32 buf)
+static int report_statvfs64(struct vfsmount *mnt, struct inode *inode, u32 buf)
{
struct statfs s;
int error;
struct sol_statvfs64 *ss = (struct sol_statvfs64 *)A(buf);
- error = vfs_statfs(inode-i_sb, s);
+ error = vfs_statfs(mnt-mnt_sb, s);
if (!error) {
- const char *p = inode-i_sb-s_type-name;
+ const char *p = mnt-mnt_sb-s_type-name;
int i = 0;
int j = strlen (p);
if (j 15) j = 15;
if (IS_RDONLY(inode)) i = 1;
- if (IS_NOSUID(inode)) i |= 2;
+ if (mnt-mnt_flags MNT_NOSUID) i |= 2;
if (put_user (s.f_bsize, ss-f_bsize) ||
__put_user (0, ss-f_frsize) ||
__put_user (s.f_blocks, ss-f_blocks) ||
@@ -482,7 +482,7 @@
error = user_path_walk((const char *)A(path),nd);
if (!error) {
struct inode * inode = nd.dentry-d_inode;
- error = report_statvfs(inode, buf);
+ error = report_statvfs(nd.mnt, inode, buf);
path_release(nd);
}
return error;
@@ -496,7 +496,7 @@
error = -EBADF;
file = fget(fd);
if (file) {
- error = report_statvfs(file-f_dentry-d_inode, buf);
+ error = report_statvfs(file-f_vfsmnt, file-f_dentry-d_inode, buf);
fput(file);
}
@@ -512,7 +512,7 @@
error = user_path_walk((const char *)A(path), nd);
if (!error) {
struct inode * inode = nd.dentry-d_inode;
- error = report_statvfs64(inode, buf);
+ error = report_statvfs64(nd.mnt, inode, buf);
path_release(nd);
}
unlock_kernel();
@@ -528,7 +528,7 @@
file = fget(fd);
if (file) {
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
On 20 May 2001, Zlatko Calusic wrote: Mike Galbraith [EMAIL PROTECTED] writes: Hi, On Fri, 18 May 2001, Stephen C. Tweedie wrote: That's the main problem with static parameters. The problem you are trying to solve is fundamentally dynamic in most cases (which is also why magic numbers tend to suck in the VM.) Magic numbers might be sucking some performance right now ;-) [snip] I like your patch, it improves performance somewhat and makes things more smooth and also code is simpler. Thanks for the feedback. Positive is nice.. as is negative. Anyway, 2.4.5-pre3 is quite debalanced and it has even broken some things that were working properly before. For instance, swapoff now deadlocks the machine (even with your patch applied). I haven't run into that. Unfortunately, I have failed to pinpoint the exact problem, but I'm confident that kernel goes in some kind of loop (99% system time, just before deadlock). Anybody has some guidelines how to debug kernel if you're running X? Serial console and kdb or kgdb if you have two machines.. or uml? Also in all recent kernels, if the machine is swapping, swap cache grows without limits and is hard to recycle, but then again that is a known problem. This one bugs me. I do not see that and can't understand why. -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: Linux 2.4.4 folks
Hi Peter. I've trying to move some of my servers to 2.4.4 kernel from 2.2.x. Everything goes fine, notable perfomance increase occures, but the problem is I'm really often touch the following problem: __alloc_pages: 1-order allocation failed. __alloc_pages: 1-order allocation failed. __alloc_pages: 1-order allocation failed. __alloc_pages: 1-order allocation failed. __alloc_pages: 1-order allocation failed. This message may also show 1-order, 0-order, 3-order failures (only one type at the time). This problems also appeared then I tried to use 2.4.1-2.4.3 kernels. This sometimes leads to system hang, sometimes some processes gets unkillable (even by kill -9) and in some cases I do not see any bad results from this, but still this does not looks the right thing to happen. The problem is the systems this happens on are not short of memory. Here is the free output for the system I had this happened this morning: rat:~ # free Mem: 10286281025820 2808 0 9340 332412 -/+ buffers/cache: 684068 344560 Swap: 2097136 02097136 Does anyone has any ideas about this problem ? I'm not up to date with the 2.4 series at the moment, but... Looking at the figures you're showing, this looks like you have 1024M of RAM. It used to be necessary to recompile the kernel if you had more than (going from memory) 976M of RAM, where you had to change a configuration option to select 2G of paging space instead of the default 3G thereof, and this looks suspiciously like this problem to me. Can anybody confirm whether this limitation still applies? Best wishes from Riley. - 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: start_thread question...
[EMAIL PROTECTED] said: I'm implementing start_thread for the VAX port and am wondering does start_thread have to return to load_elf_binary? I'm working on the init thread and what is happening is it is returning the whole way back to the execve caller .. which I know shouldn't happen. Ingo answered that specific question (and that had me puzzled for a while, too :-), but, in the future, you might want to look at UML if you have similar questions. All this stuff works, and it's implemented in terms of the system calls that we all know and love, so you don't have to learn about a totally different piece of hardware in order to figure out what's going on. Jeff - 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: Background to the argument about CML2 design philosophy
1. The Mac derivations were half-right. The MAC_SCC one is good but Macs can have either of two different SCSI controllers. I fixed that with help from Ray Knight, who maintains the 68K Mac port. If I understand the philosophy correctly, it is still possible to specify additional cards for those Macs which have PCI slots. If so, absolutely fine - I can shove my Adaptec 19160 into my G4 and have it work just as well as it currently does in my Athlon. One caveat though - not all Macs have SCSI controllers, and not all that do even have one of the two standard ones. The Blue and White G3, the iMac, the PowerBook G3 Firewire and later models on these lines all lack a built-in SCSI controller, but many could have one added via PCI or CardBus slots. The PowerBooks 5300 and 190 (and possibly others) use some non-standard P.O.S. hanging off the NuBus, which even mkLinux doesn't know how to drive. However, in these situations, disabling the extra drivers is usually not critical unless you're running low on space somewhere. At that point, you enable the Are you insane? module outlined below... 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. (I missed these possibilities when I wrote the derivations.) ...and then someone else mentioned the possibility of f*x0r3d hardware. In this case, I would say this *isn't* a kernel-configuration issue but one of being able to disable the drivers for the malfunctioning hardware. If I have a PCMCIA controller that reboots the machine as soon as the driver tries to switch it on, I should be able to send a command-line parameter to the kernel which tells it to switch it off *at run-time*. And iff I'm running with hardware which is so f*x0r3d that that isn't enough, I'd either fix the hardware or hack the config files. I don't see the problem. I think the MVME derivations are *perfectly* sensible - if the reference board and most (read: virtually all) derivatives have those features, turn them on by all means. To satisfy some others, you might want to say Hey, these guys might want to *explicitly turn off* some of this stuff - so provide an option under Are you insane? which presents all the derived symbols and allows the hackers to manually turn stuff off. -- from: Jonathan Chromatix Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] make drivers/block/ps2esdi.c compile (2.4.4)
Hi.
The following trivial patch against 2.4.4(-ac11) makes ps2esdi compile.
--- linux-244-ac10-clean/drivers/block/ps2esdi.cSat May 19 21:06:29 2001
+++ linux-244-ac10/drivers/block/ps2esdi.c Sun May 20 14:47:04 2001
@@ -953,10 +953,10 @@
break;
}
if(ending != -1) {
- spin_lock_irqsave(io_request_lock, flags);
+ spin_lock_irqsave(io_request_lock, flags);
end_request(ending);
do_ps2esdi_request(BLK_DEFAULT_QUEUE(MAJOR_NR));
- spin_unlock_irqrestore(io_request_lock, flags);
+ spin_unlock_irqrestore(io_request_lock, flags);
}
} /* handle interrupts */
--
Regards,
Rasmus([EMAIL PROTECTED])
The difference between theory and practice is that, in theory, there is
no difference between theory and practice. -- Anonymous
-
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: add page argument to copy/clear_user_page
On Sun, 20 May 2001, Paul Mackerras wrote: The patch below adds a page * argument to copy_user_page and clear_user_page. If you add the page argument, why leave the old arguments lingering there at all? They only create confusion, and add no information. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 del_timer_sync oops in schedule_timeout
On Sun, 20 May 2001, Ingo Molnar wrote: Unable to handle kernel paging request at virtual address 78626970 this appears to be some sort of DMA-corruption or other memory scribble problem. hexa 78626970 is ASCII pibx, which shows in the direction of some sort of disk-related DMA corruption. we havent had any similar crash in del_timer_sync() for ages. Ahh. Thanks then, I'll go look hard at the disk in that box. :) -Jacob -- Only when work uses up all energy and people are too tired to enjoy the persuit of their passions are they ready to be reduced to the passively receptive state suitable for television. - ``The Hacker Ethic'' by Pekka Himanen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 del_timer_sync oops in schedule_timeout
On Sun, 20 May 2001, Jacob Luna Lundberg wrote: Unable to handle kernel paging request at virtual address 78626970 this appears to be some sort of DMA-corruption or other memory scribble problem. hexa 78626970 is ASCII pibx, which shows in the direction of some sort of disk-related DMA corruption. we havent had any similar crash in del_timer_sync() for ages. Ahh. Thanks then, I'll go look hard at the disk in that box. :) not necesserily the disk. it can be any sort of overheating or other thermal noise (unlikely), or SCSI/IDE cable problem (likely), or driver problem (likely too). Disk faults typically show very different symptoms. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mail admin notice my 2 cents
I would have never signed up for this list, or any other if it didn't give me at least a few hours worth of email bouncing neither myself, or usa.net is up 24/7/365, and i wouldn't expect that everyone has a dedicated email server, for almost any list. plus I have had many problems with the @home's email servers, if I relied on them I would probibly have been kicked off quite some time ago. well thats my 2cents Richard Reynolds [EMAIL PROTECTED] On Sun, 20 May 2001, Matti Aarnio wrote: Date: Sun, 20 May 2001 22:05:45 +0300 From: Matti Aarnio [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: Shawn Starr [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Mail admin notice On Sun, May 20, 2001 at 06:28:24AM -0400, Mike A. Harris wrote: On Sun, 20 May 2001, Shawn Starr wrote: My emails may bounce between 3AM - 8AM Est time, @Home is doing some fiber upgrades and i dont have a second MX server (as I am the domain/dns/mail etc). There is 3d+ some hours grace period during which vger doesn't need to be able to feed email to destination system, BUT AFTER THAT STARTS BOUNCING. (To linux-kernel-owner, NOT to the list itself!) Alan Cox was awhile back offline for 2-3 days, and was amazed that trans-atlantic connection can feed email at full bandwidth of his network connection (512k, or whatever that was..) Please bear with bounces until then. If you are unconnected for more than that 3d+, THEN you will be removed. For few hours that is no problem. Begin connected to the network for few hours every day is no problem either, but then you would most likely have backup MX server, and issue an ETRN request for your domain there when you reconnect. You're saying that you consider it acceptable to bounce email to 5000 to 1 people, possibly thousands of messages? And that you knew it may occur in advance? I would think the responsible thing to do would be to unsubscribe from the mailing list temporarily until your problem is solved. Anything less is purely apathetic on your part. Mike. Don't suggest something of which you apparently know nothing about. /Matti Aarnio -- co-postmaster of vger.kernel.org. - 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/ ,'' '', Richard Reynolds ( 0 0 )La Mesa , Ca oOOo-(_)-oOO___ E-Mail: [EMAIL PROTECTED] IRC: Dalnet #!rsr, rsman --- If you are not an intended reciepient of this message, please accept my appologies, If you recieve more than 1 message that you feel you were not intended to recieve Please feel free to E-Mail me at [EMAIL PROTECTED] So that I can be certain you do not recieve further E-Mails from this address. - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
Davem, check the last thing, please. On Sun, 20 May 2001, Alexander Viro wrote: On Sun, 20 May 2001, Linus Torvalds wrote: How about moratorium on new ioctls in the meanwhile? Whatever we do in fs/ioctl.c, it _will_ take time. Ehh.. Telling people don't do that simply doesn't work. Not if they can do it easily anyway. Things really don't get fixed unless people have a certain pain-level to induce it to get fixed. Umm... How about the following: you hit delete on patches that introduce new ioctls, I help to provide required level of pain. Deal? It still doesn't work. That only makes people complain about my fascist tendencies. See the thread about device numbers, where Alan just says ok, I'll do it without Linus then. The whole point of open source is that I don't have that kind of power. I can only guide, but the most powerful guide is by guiding the _design_, not micro-managing. BTW, -pre4 got new bunch of ioctls. On procfs, no less. I know. David has zero taste. Davem, why didn't you just make new entries in /proc/bus/pci and let people do mmap(/proc/bus/pci//mem) instead of having idiotic ioctl's to set this is a IO handle and this is a MEM handle? This particular braindamage is not too late to fix.. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
If it had been a manufacturer in most respectable areas of business they'd be recalling and reissuing components, and paying for the end resllers to notify each customer This is consumer hardware. Consumer products are optimized for a good buzzword count per $ ratio. Everything else is secondary. Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits' Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4-ac11 network drivers cleaning
printk(%s\n, version); Not quite as optimal but safer. I disagree. Don't work around an escape bug in a version string, fix it... A % in a version string might be quite reasonable. You are asking to have an accident by avoiding it. If you want to fight over 4 bytes, then add a single constant %s\n, and #define putk() from it - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
waitqueue problem on 2.4.3
Hy to all !
I am experiencing big problems using wait queues in a device driver
(module)
on kernel 2.4.3-20mdk (gcc version 2.96).
I dont know if this is the right place to ask for - but its my last hope...
The device driver i write is for a measuring device connected to parallel
port-
so i'm using the parport and parport_pc modules with exclusice access to
the
parallel port. Communication with the device works perfectly with one
exception - i cant use waitqueues - it doesnt matter in which was i try it
(i noticed there were changes to waitqueues in 2.4 kernels)...
the first approach using waitqueues looks like this :
hshppm.c: (the driver)
/* ... */
static DECLARE_WAIT_QUEUE_HEAD( hshppm_isr_digital_wq );
/* ... */
static int device_open( struct inode *inode, struct file *file )
{
/* ... */
init_waitqueue_head(hshppm_isr_digital_wq);
/* ... */
}
/* ... */
static ssize_t device_read( struct file *file,
char *buffer,
size_t length,
loff_t *offset)
{
/* ... */
interruptible_sleep_on( hshppm_isr_digital_wq );
/* ... */
}
/* ... */
/* the ISR for the INTs on the parallel port */
/* called from parport_generic_irq() */
void hshppm_isr( int irq, void *handle, struct pt_regs *regs )
{
/* ... */
wake_up_interruptible( hshppm_isr_digital_wq )
/* ... */
}
When I run this code and execute the read() from userland it does a
segfault
when the module executes the interruptible_sleep_on() - a kernel oops is
recorded in the
log:
May 20 21:01:40 ofen kernel: Unable to handle kernel NULL pointer
dereference at virtual address 003d
May 20 21:01:40 ofen kernel: printing eip:
May 20 21:01:40 ofen kernel: c0111c4b
May 20 21:01:40 ofen kernel: pgd entry cae5:
May 20 21:01:40 ofen kernel: pmd entry cae5:
May 20 21:01:40 ofen kernel: ... pmd not present!
May 20 21:01:40 ofen kernel: Oops:
May 20 21:01:40 ofen kernel: CPU:0
May 20 21:01:40 ofen kernel: EIP:0010:[sleep_on+35/88]
May 20 21:01:40 ofen kernel: EIP:0010:[c0111c4b]
May 20 21:01:40 ofen kernel: EFLAGS: 00210086
May 20 21:01:40 ofen kernel: eax: cb53e000 ebx: 00200286 ecx:
00200246 edx: 0039
May 20 21:01:40 ofen kernel: esi: ce071720 edi: 0804b225 ebp:
cb53ff5c esp: cb53ff48
May 20 21:01:40 ofen kernel: ds: 0018 es: 0018 ss: 0018
May 20 21:01:40 ofen kernel: Process dev_test1 (pid: 1842,
stackpage=cb53f000)
May 20 21:01:40 ofen kernel: Stack: ffea cb53e000 cb53e000
c0111554 cb53ff9c e8be7232 e8becaf8
May 20 21:01:40 ofen kernel:e8beb383 e8becadc d6fd4000 d5e75960
40016000 001a ffea d5e75960
May 20 21:01:40 ofen kernel:001a bfffeee8 ffea ce071720
0001 b698 c012dca6 ce071720
May 20 21:01:40 ofen kernel: Call Trace: [process_timeout+0/72]
[e8be7232] [e8becaf8] [e8beb383] [e8becadc] [sys_read+142/196]
[system_call+51/64]
May 20 21:01:40 ofen kernel: Call Trace: [c0111554] [e8be7232]
[e8becaf8] [e8beb383] [e8becadc] [c012dca6] [c0106f23]
May 20 21:01:40 ofen kernel:
May 20 21:01:40 ofen kernel: Code: 8b 42 04 8d 4d f8 89 48 04 8d 4a 04 89
4d fc 89 45 f8 8d 4d
i did the init_waitqueue_head() in device_open() when the device is openend
from userland - so this
should not happen...
i tested the above also with the init_waitqueue_head() omitted in
device_open() - cause the
kernel api changes documented in
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.4.html
say i doesnt need it.
The second approach i tested look like this:
hshppm.c: (the driver)
/* ... */
static DECLARE_WAIT_QUEUE_HEAD( hshppm_isr_digital_wq );
/* ... */
static int device_open( struct inode *inode, struct file *file )
{
/* ... */
init_waitqueue_head(hshppm_isr_digital_wq);
/* ... */
}
/* ... */
static ssize_t device_read( struct file *file,
char *buffer,
size_t length,
loff_t *offset)
{
/* ... */
unsigned long flags;
DECLARE_WAITQUEUE (wait, current);
wq_write_lock_irqsave((hshppm_isr_digital_wq.lock), flags);
wait.flags = 0;
__add_wait_queue(hshppm_isr_digital_wq, wait);
wq_write_unlock_irqrestore((hshppm_isr_digital_wq.lock), flags);
current-state = TASK_INTERRUPTIBLE;
schedule();
current-state = TASK_RUNNING;
wq_write_lock_irqsave((hshppm_isr_digital_wq.lock), flags);
__remove_wait_queue(hshppm_isr_digital_wq, wait);
wq_write_unlock_irqrestore((hshppm_isr_digital_wq.lock), flags);
/* ... */
}
/* ... */
/* the ISR for the INTs on the parallel port */
/* called from parport_generic_irq() */
void hshppm_isr( int irq, void *handle, struct pt_regs *regs )
{
/* ... */
wake_up_interruptible( hshppm_isr_digital_wq )
/* ... */
Re: const __init
On Sunday 20 May 2001 21:51, Geert Uytterhoeven wrote: Since a while include/linux/init.h contains the line * Also note, that this data cannot be const. Why is this? Because const data will be put in a different section? Yes, and gcc3 errors on these constructs, cause it cannot decide if the data should be put into a .data or .rodata section. Dunno if it's worth to create a __initconstdata/__initrodata though, but it would be easy implement I guess. drivers/video/aty128fb.c Fixed in bk 2_4. Franz. - 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: Background to the argument about CML2 design philosophy
Jonathan Morton [EMAIL PROTECTED]: One caveat though - not all Macs have SCSI controllers, and not all that do even have one of the two standard ones. I know. But these derivations are only for the old 68K macs, which don't have PCI. Closed issue. 3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. ...and then someone else mentioned the possibility of f*x0r3d hardware. In this case, I would say this *isn't* a kernel-configuration issue but one of being able to disable the drivers for the malfunctioning hardware. But the other side is going to ask: suppose you're memory-limited (quite likely on older SBCs) and don't want to pay the core cost of drivers you won't use? I don't really think we can duck this question by talking about boot-time parameters. I think the MVME derivations are *perfectly* sensible - if the reference board and most (read: virtually all) derivatives have those features, turn them on by all means. That's my gut feeling, too. But a lot of people insist that the only right way is totally fine-grained control, even in weird edge cases like this one. To satisfy some others, you might want to say Hey, these guys might want to *explicitly turn off* some of this stuff - so provide an option under Are you insane? which presents all the derived symbols and allows the hackers to manually turn stuff off. Interesting thought... -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 - 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: const __init
On Sun, 20 May 2001, Jeff Garzik wrote:
Geert Uytterhoeven wrote:
Since a while include/linux/init.h contains the line
* Also note, that this data cannot be const.
Why is this? Because const data will be put in a different section?
Causes a section type conflict build error, at least on x86.
On m68k I only saw section type conflict errors when using __init while it
should have been __initdata.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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: tcp_mem problem
On Sun, May 20, 2001 at 07:33:15PM +0200, David Osojnik wrote: the system with problem is using kernel 2.4.2 on an P200 with 64mb ram. It has about 20 users that use the box... (ftp, telnet, lynx, bitchx,...). the problem is when the parameter tcp_mem HIGH gets exeded after about a day of use! Then the box is going from the net and its not awailable. I tried to tune the system with adding more in proc tcp_mem but the problem is still there the box only lasts for bout 2h longer. and i get this in messages kernel: TCP: too many of orphaned sockets It looks like my system is not droping closed sockets? You can check by using netstat -tan Normally the message is harmless; when it happens the closed sockets are RST instead of being closed properly. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sqrt in kernel?
hi, is there a sqrt function in the kernel? any other math functions? i tried finding/grepping around, and found some various arch-specific stuff for fpu emulation... is there a general sqrt function? is there a single file to look through with the various math functions? thanks, -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
David Woodhouse [EMAIL PROTECTED]: I think you already have the mechanism required to answer this - in NOVICE mode you disallow the strange choices, in EXPERT mode you allow them. That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Sigh... -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action. -- George Washington, in a speech of January 7, 1790 - 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: tcp_mem problem
the system with problem is using kernel 2.4.2 on an P200 with 64mb ram. It has about 20 users that use the box... (ftp, telnet, lynx, bitchx,...). the problem is when the parameter tcp_mem HIGH gets exeded after about a day of use! Then the box is going from the net and its not awailable. I tried to tune the system with adding more in proc tcp_mem but the problem is still there the box only lasts for bout 2h longer. and i get this in messages kernel: TCP: too many of orphaned sockets It looks like my system is not droping closed sockets? On Sunday 20 May 2001 22:26, you wrote: You can check by using netstat -tan Normally the message is harmless; when it happens the closed sockets are RST instead of being closed properly. -Andi But why is the server going down when that message apheres in the log?... No one can telnet to the computer, ssh, web is not awailabe... And the message gets repeted all the time. The only thing to do is to reset the server. Well I dont know what else to do. netstat -tan doesnt show anything wrong. David - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. Having too many such modes would be a horrible mess, I agree. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Of course there are such cases. The criterion is that the code does not compile or if it did, it could never be expected to work - like SCSI drivers without SCSI generic, or PCI devices without CONFIG_PCI. This is the major criterion which has defined the dependencies already in the config files. You want to add a new mode which hides some of the more esoteric options. That's fine. So do so, and then we have two modes. It's still not an unmaintainable mess. If having even two modes is going to be too troublesome, then keep the one we have. You can try to simplify it later by encouraging individual maintainers to hide stuff behind CONFIG_*_ADVANCED options. But keep that strictly separate from the CML2 discussion. -- dwmw2 - 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: Background to the argument about CML2 design philosophy
On Sun, May 20, 2001 at 04:47:00PM -0400, Eric S. Raymond wrote: In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. It doesn't compile/link would be a good one. It requires subsystem FOO to operate is another (think about IDE DMA drivers and the IDE subsystem, or NIC drivers vs CONFIG_NET) A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Somehow the current overhead isn't that high. You might argue that the current Config.in is broken given my definition. That is fixable with a day of work; I've been doing so on a regular basis with the tooling I wrote for automatic testing of this. Maybe it would be possible to separate hard dependencies like the current system has with the soft ones one needs for entry-level configtools. Or maybe it needs 2 files for that.. CML1 style (style, maybe not syntax) ones and the newstyle info. I liked the suggestion where the automatic derivations got turned into manual ones for expert mode... I haven't tried CML2 yet (I've yet to find a suitable .deb of Python2 for my Debian Potato playbox) so I don't know if that is actually possible, or that it requires some redesign. Greetings, Arjan van de Ven - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Mike Galbraith wrote: Also in all recent kernels, if the machine is swapping, swap cache grows without limits and is hard to recycle, but then again that is a known problem. This one bugs me. I do not see that and can't understand why. To throw away dirty and dead swapcache (its done at swap writepage()) pages page_launder() has to run into its second loop (launder_loop = 1) (meaning that a lot of clean cache has been thrown out already). We can short circuit this dead swapcache pages by cleaning them in the first page_launder() loop. Take a look at the writepage() patch I sent to Linus a few days ago. - 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: sqrt in kernel?
On Sun, May 20, 2001 at 04:33:20PM -0400, Robert M. Love wrote: hi, is there a sqrt function in the kernel? any other math functions? No. (Assuming FP math sqrt function is your interest.) If you do scaled integers (fractions, with 2^n denominator), you can do newton iteration for sqrt nicely. i tried finding/grepping around, and found some various arch-specific stuff for fpu emulation... is there a general sqrt function? is there a single file to look through with the various math functions? Yes. Userspace. ( math.h ) As a rule: NO FP MATH IS ALLOWED IN THE KERNEL! Now the question: Why do you think you need FP math ? If your case is non-fast-path, you may do complete state save before, and restore after your FP code. In some cases even the fast-paths carry FP/MMX code, but those are cases where the save/restore overhead becomes negligible for all of the other processing that is going on. thanks, -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] /Matti Aarnio - 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: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Mike Galbraith wrote: On 20 May 2001, Zlatko Calusic wrote: Also in all recent kernels, if the machine is swapping, swap cache grows without limits and is hard to recycle, but then again that is a known problem. This one bugs me. I do not see that and can't understand why. Could it be because we never free swap space and never delete pages from the swap cache ? Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] util-linux-2.11c released
After man-pages-1.36 and kbd-1.06 today util-linux-2.11c. - 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: const __init
On Sun, May 20, 2001 at 09:51:04PM +0200, Geert Uytterhoeven wrote: Appendix: here's the list of affected source files: arch/arm/kernel/setup.c Thanks for pointing it out. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: const __init
On Sun, May 20, 2001 at 05:34:48PM -0400, Jeff Garzik wrote: This might be a very valid point... (let me know if the following test is flawed) It is imho. [jgarzik@rum tmp]$ cat sectest.c #include linux/module.h #include linux/init.h static const char version[] __initdata = foo; static char version2[] __initdata = bar; [jgarzik@rum tmp]$ gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-c -o sectest.o sectest.c [jgarzik@rum tmp]$ No section type conflict appears. Now it SHOULD conflict on these binutils, but doesn't on mine (2.9.5) ;-) It is decided to put it into .data.init as expected. AFAIK const is only a promise to the compiler, that we write this data ONCE and read only after this initial write. So the decision on the section is implementation defined. What I don't understand is, why GCC overrides our explicit override (done by setting the section attribute explicitly). I would consider this a BUG in GCC. I don't understand, why we support this BUG... Maybe some GCC people can enlighten me, why GCC ignores such overrides, that are for the cases where we DO KNOW BETTER than GCC, what section is correct. Regards Ingo Oeser -- To the systems programmer, users and applications serve only to provide a test load. - 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: [LV] start_thread question...
Okay I think I've gotten it solved most of the way, we weren't calling execve via the system call interface, so once I made it go via the system call and I fill out pc, sp and psl registers in start_thread, it seems to go further.. Thanks for all the help... Dave. On Sun, 20 May 2001, Kenn Humborg wrote: On Sun, May 20, 2001 at 05:24:48PM +0100, Dave Airlie wrote: I'm implementing start_thread for the VAX port and am wondering does start_thread have to return to load_elf_binary? I'm working on the init thread and what is happening is it is returning the whole way back to the execve caller .. which I know shouldn't happen. so I suppose what I'm looking for is the point where the user space code gets control... is it when the registers are set in the start_thread? if so how does start_thread return On the VAX we have to call a return from interrupt to get to user space and I'm trying to figure out where this should happen... I haven't got time to look at this in detail, but you could probably do it by frobbing the saved registers that will be restored by the ret_from_syscall in entry.S. Do you have a pt_regs *regs function argument at the right point? If so, it should point to these saved registers. Later, Kenn -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person - 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: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sat, 19 May 2001, Mike Galbraith wrote:
@@ -1054,7 +1033,7 @@
if (!zone-size)
continue;
- while (zone-free_pages zone-pages_low) {
+ while (zone-free_pages zone-inactive_clean_pages) {
struct page * page;
page = reclaim_page(zone);
if (!page)
What you're trying to do with this change ?
-
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: waitqueue problem on 2.4.3
I can't see anything immediately wrong with your code - make sure you're compiling against the source for the kernel you're running, with the same options enabled. In general, though, you shouldn't be using any of the sleep_on() functions if you care about the fact that you'll miss wakeup events. -- dwmw2 - 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: permission checking for network filesystem
Hi I'm trying to impelemnt a lightweight network filesystem and ran into trouble implementing lookup, permissions and open. The protocol requires me to specify open mode in it's open command. The open mode has 4 bits: read, write, append and execute. But I can't tell execution from read in file_operations-open. I could send the open command from the inode_operations-permission, but this does not solve the problem, as I can't find weather to count the new file descriptor as reader or executer (I have to know that when closing the file). The idea of opening files for read and opening files for execution is bogus and you should fix the protocol, not add more crap to your implementation. There are two ways how you can implement security in network file system: 1. you expect that users have not root access on the client machine and you check permissions on client (like in NFS). In this case the 'x' and 'r' bits are checked on the client and you don't have to care about them in protocol. 2. you expect that users have root access on client machine and you check permissions on the server. In this case users can read executed files anyway. The server always checks permission on the actual request, so I can't open the file for reading, when it should be open for execution. It seems that you are implementing case 2 of the above. If you are checking permissions on server, read/execute have no security meaning. Client can send 'execute' request and then store data somwhere to file. Opening for 'execute' won't enhance your security. Could anyone see a solution other than adding a flags to open mode (say O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec and sys_uselib? I don't like the idea of pathing vfs for this. Send always 'open for read' and ignore 'open for execute'. And also remember that having file without read permission and with execute permission makes sence only for suid programs. User can read the file via /proc/pid/mem or attach debugger to the process... Mikulas - 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: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] said: Maybe it would be possible to separate hard dependencies like the current system has with the soft ones one needs for entry-level configtools. Actually, the current system has both types. As well as the hard dependencies, we also have stuff like CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. These things have already been set up in the way that developers prefer it. CML2 allows us to be more flexible than we were before, and that can be a good thing when used in moderation. But please, for the sake of the sanity of all concerned, do things one at a time. Provide for merging into 2.5 a set of rules which reproduce the existing CML1 behaviour in this respect. Eric, if you want to make further changes later to introduce new 'modes' for kernel configuration, that's an entirely separate issue. Please don't confuse the issue by trying to do it at the same time as introducing CML2. CONFIG_AUNT_TILLIE does not require CML2. CML2 does not require CONFIG_AUNT_TILLIE. Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing behaviour of config options to make that the default, until we've settled the discussion about CML2. -- dwmw2 - 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/
Proxim Symphony wireless drivers
Hi, I am using Proxim Symphony Wireless LAN card on one of my systems with kernel 2.2.19. I may reinstall with a different Linux distro and upgrade to kernel 2.4. The Proxim Symphony Wireless LAN site (http://www.komacke.com) has disappeared. Does anyone know where I can find drivers for Linux for this product? TIA. -- Subba Rao [EMAIL PROTECTED] http://members.home.net/subba9/ GPG public key ID 27FC9217 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Patch for sbus makefile bug
On Sun, 20 May 2001 11:47:38 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: Somebody failed to track a module name change. -obj-$(CONFIG_BBC_I2C) += bbc.o +obj-$(CONFIG_BBC_I2C) += bbc_i2c.o bbc-objs := bbc_i2c.o bbc_envctrl.o The module is bbc.o, bbc_i2c.o is a sub-object of bbc.o, the selection is correct (2.4.5-pre4). - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
90% of drivers contain code written by stupid gits. From: Alan Cox I think thats a very arrogant and very mistaken view of the problem. 90% of the driver are written by people who are - Copying from other drivers - Using the existing API's to make their job easy - Working to timescales - Just want it to work I'll be the first to admit there is some ugliness in my driver. Some originates from accepted methods when the driver originated. (points 1 and 2 above) Some comes from doing new things with only the existing infrastructure, because changing the infrastructure is deemed too intrusive. (points 3 and 4 above) Stable infrastructure is good, but sometimes ugliness results. Some is the result of genuine mistakes (people who have written nothing but perfect code flame away). I fix these as they are found through use and review, and the code improves. (I *really do* want my driver to work!) As new facilities and guidelines are made available, I *gladly* and *gratefully* use them, and the code improves. Calling driver writers stupid and devising punitive measures to 'cause them pain' seems less useful. Paul Fulghum [EMAIL PROTECTED] Microgate Corporation http://www.microgate.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Paul Fulghum wrote: I'll be the first to admit there is some ugliness in my driver. So will anyone here regarding his or her code. Count me in, BTW. Could you reread the posting you are refering to? - 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: alpha iommu fixes
On Sun, May 20, 2001 at 04:05:18PM +0400, Ivan Kokshaysky wrote: Ok. What do you think about reorg like this: basically leave the old code as is, and add if (is_pyxis) alpha_mv.mv_pci_tbi = cia_pci_tbi_try2; else tbia test ... Seems good. 21174 docs confirm that (though in a very low voice ;-) : The 21174 may hang with TBIA=3. Mmm. Tasty. :-) r~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
Eric == Eric S Raymond [EMAIL PROTECTED] writes: Eric The first candidates I found were questions associated with Eric built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Eric Sun3x, and with built-in facilities on the MVME147 single-board Eric computer. So I wrote derivations that looked like this: [snip derive rules] Eric # These were separate questions in CML1 derive MAC_SCC from MAC Eric SERIAL derive MAC_SCSI from MAC SCSI derive SUN3_SCSI from Eric (SUN3 | SUN3X) SCSI Eric By doing this I killed two birds with one stone -- got rid of Eric some holes in Configure.help and (more importantly) moved the Eric configuration experience away from low-level, hardware-oriented Eric questions towards where I think it ought to be. That is, you Eric specify a platform and the services you want and the ruleset Eric computes the low-level facilities to be linked in. And you suddenly imposed decisions on people. Wether or not you are an expert it is reasonable to expect that you want to use modules just as it is just as reasonable to expect that you do not. In some cases you want your Ethernet as a module in some case you want the low level SCSI driver but not the SCSI mid layer. Eric After some back-and-forthing about the technical facts, several Eric things emerged: Eric 1. The Mac derivations were half-right. The MAC_SCC one is good Eric but Macs can have either of two different SCSI controllers. I Eric fixed that with help from Ray Knight, who maintains the 68K Mac Eric port. Eric 2. Nobody had a problem with the SUN3_SCSI derivation. Did you ever get an ACK on it or no answer? Eric 3. The MVME derivations are correct *if* (and only if) you agree Eric to ignore the possibility that somebody could want to ignore the Eric onboard hardware, plug outboard disk or Ethernet cards into the Eric VME-bus connector, and do something like running SCSI-over-ATAPI Eric to the outboard device. (I missed these possibilities when I Eric wrote the derivations.) Or wants to use modules. And yes Aunt Tillie might want to do so, if the person who sold her her Linux CD provided a bunch of scripts for packing up things in a specific way. Eric The MVME situation is an almost perfect test case, because while Eric breaking the assumption behind that derivation is physically Eric possible it would be a rather perverse thing to do. The VME147 Eric is an old design, dating from 1988; it's long since been Eric superseded by MPCxxx SBCs based on the PowerPC that have a Eric better processor, lower power consumption, and more on-board Eric peripheral hardware. IDE/ATAPI didn't exist during most of its Eric design lifetime, and the only way anyone is ever going to hook Eric an outboard device to one of these puppies again is if some Eric hacker pulls a dusty one off a shelf for some garage project. Bt wrong. The MVME cards are still heavily used in control systems and similar places. It's the only place where m68k usage is not dying for real. Eric So far, I have to say I'm disappointed in the quality of the Eric debate. Almoist nobody seems to want to think about this Eric tradeoff globally, as a systems design issue. Instead, I'm Eric hearing a lot of reflexive chuntering that we have to do things Eric a certain way because we've always done them a certain way, and Eric who am I to even dare *think* about raising different Eric possibilities? So far the introduction of CML2 has been overly disppointing, from day one it's been 'I have this great idea and since I think it's great, you obviously have to think so as well'. Now I take it the derived rules are still only enforced under the 'novice' option, though you haven't exactly made that clear in the discussion (nor did you do so when you initially brought it up). Jes - 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: Background to the argument about CML2 design philosophy
David Woodhouse [EMAIL PROTECTED]: Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing behaviour of config options to make that the default, until we've settled the discussion about CML2. What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. The engine is working. Why is it not yet time to discuss ruleset design and modes? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in Phila. Independent Gazetteer, August 20, 1789 - 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] ppc xconfig 2.2.5-pre4
Hi, The following patch fixes ppc xconfig potential problem introduced in 2.4.5-pre4. Andrzej *** diff -uNr linux-2.4.5-pre4/arch/ppc/config.in linux-pre4/arch/ppc/config.in --- linux-2.4.5-pre4/arch/ppc/config.in Mon May 21 03:17:02 2001 +++ linux-pre4/arch/ppc/config.in Mon May 21 03:22:51 2001 @@ -135,7 +135,8 @@ define_bool CONFIG_PCI $CONFIG_PCI_QSPAN else if [ $CONFIG_APUS = y ]; then - bool 'PCI for Permedia2' CONFIG_PCI + bool 'PCI for Permedia2' CONFIG_PCI_PERMEDIA + define_bool CONFIG_PCI $CONFIG_PCI_PERMEDIA else define_bool CONFIG_PCI y fi -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. Math., Technical University of Gdansk - 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: alpha iommu fixes
On Sun, May 20, 2001 at 06:07:17PM -0700, David S. Miller wrote: Andrea Arcangeli writes: [..] Even sparc64's fancy iommu-based pci_map_single() always succeeds. Whatever sparc64 does to hide the driver bugs you can break it if you pci_map 4G+1 bytes of phyical memory. Which is an utterly stupid thing to do. Please construct a plausable situation where this would occur legally and not be a driver bug, given the maximum number of PCI busses and slots found on sparc64 and the maximum _concurrent_ usage of PCI dma space for any given driver (which isn't doing something stupid). Assume I have a dozen of PCI cards that does DMA using SG tables that can map up to some houndred mbytes of ram each, so I can just program the cards to start the dma on those houndred mbyte of ram, most of the time the I/O is not simulaneous, but very rarely it happens to be simultaneous and in turn it tries to pci_map_sg more than 4G of physical ram. After that sparc64 iommu code will say bye bye and the machine will crash because the nic driver is not checking for pci_map_single faliures. I don't see why the above scenario should be classified as stupid. such pci_map_* API and the device drivers have to be generic. It's like if you say me that there's no need to check for alloc_pages(GFP_ATOMIC) faliures in the device drivers because all machines you are using have 256G of ram and you never use all the physical ram with your workloads. I would never buy such an argument. Furthmore currently (2.4.5pre3) on alpha you only need to ask the iommu to map more than 128mbyte of ram to crash (I increased it to 512mbyte at least, Jay said my first patch that increased it to 1G is risky because some device gets confused by bus addresses at around -1M and we keep the dynamic window above 3G, 512M should still be enough to cover 99% of hardware configurations I agree on that but this is not a good excuse to left all device drivers buggy just because those bugs doesn't trigger in all the hardware configurations out there). Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Sun, May 20, 2001 at 06:01:40PM -0700, David S. Miller wrote: Andrea Arcangeli writes: Well this is news to me. No drivers understand this. Yes, almost all drivers are buggy. No, the interface says that the DMA routines may not return failure. The alpha returns a faliure since day zero of iommu support, the sparc64 has too otherwise it's even more buggy than alpha when the machine runs out of pci virtual address space. If you want to change the DMA api to act some other way, then fine please propose it, but do not act as if today they have to act this way because that is simply not true. About the pci_map_single API I'd like if bus address 0 would not be the indication of faluire, mainly on platforms without an iommu that's not nice, x86 happens to get it right only because the physical page zero is reserved for completly other reasons. so we either add a err parameter to the pci_map_single, or we define a per-arch bus address to indicate an error, either ways are ok from my part. Andrea - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: ali noautodma, and Alpha AXP
The hardware: UP1000 Alpha, with ALI M1543C IDE. Fujitsu 2GB udma33
drive, I think. ATAPI UDMA CDROM.
The problem: 2.2.15 (as packaged with MDK 7.1 for Alpha) works fine.
2.4.current, both ac tree and linus tree, fail to work at all. I've
tried all combinations I can think of, for: with and without the
alim15xx.c driver, with/out IDEDMA, with/out IDEDMA on auto, with/out
ide=nodma on cmdline.
2.2.x gives the message DMA disabled (BIOS), and tunes the drives for
PIO.
2.4.x, even with nodma, tunes the hard drive and CDROM drive for
udma. All hard drive accesses fail with hda: lost interrupt and hdc:
lost interrupt. With the attached patch, it no longer appears to tune
the drives for UDMA, but I still get lost interrupt messages and no
usable drives.
--
Jeff Garzik | Do you have to make light of everything?!
Building 1024| I'm extremely serious about nailing your
MandrakeSoft | step-daughter, but other than that, yes.
Index: linux_2_4/drivers/ide/alim15x3.c
diff -u linux_2_4/drivers/ide/alim15x3.c:1.1.1.49
linux_2_4/drivers/ide/alim15x3.c:1.1.1.49.6.1
--- linux_2_4/drivers/ide/alim15x3.c:1.1.1.49 Thu May 17 10:12:07 2001
+++ linux_2_4/drivers/ide/alim15x3.cSun May 20 16:16:52 2001
@@ -679,19 +679,21 @@
hwif-drives[0].autotune = 1;
hwif-drives[1].autotune = 1;
hwif-speedproc = ali15x3_tune_chipset;
-#ifndef CONFIG_BLK_DEV_IDEDMA
- hwif-autodma = 0;
- return;
-#endif /* CONFIG_BLK_DEV_IDEDMA */
+#ifdef CONFIG_BLK_DEV_IDEDMA
if ((hwif-dma_base) (m5229_revision = 0x20)) {
/*
* M1543C or newer for DMAing
*/
hwif-dmaproc = ali15x3_dmaproc;
- if (!noautodma)
- hwif-autodma = 1;
+ hwif-autodma = 1;
}
+
+ if (noautodma)
+ hwif-autodma = 0;
+#else
+ hwif-autodma = 0;
+#endif /* CONFIG_BLK_DEV_IDEDMA */
}
void __init ide_dmacapable_ali15x3 (ide_hwif_t *hwif, unsigned long dmabase)
Re: 2.4.4 del_timer_sync oops in schedule_timeout
Ingo Molnar wrote: On Sat, 19 May 2001, Jacob Luna Lundberg wrote: This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in. Unable to handle kernel paging request at virtual address 78626970 this appears to be some sort of DMA-corruption or other memory scribble problem. hexa 78626970 is ASCII pibx, which shows in the direction of some sort of disk-related DMA corruption. It could be timer-list corruption. Someone released some memory which had a live timer in it. The memory got recycled and then the timer list traversal fell over it. There was a convincing report of this a few weeks back on a system which didn't have any unusual drivers in it. It was inconclusive. That system was SMP, so it could have been a timer deletion race. This bug is so damn hard to track down that it may be worth putting some special walk-the-timer-lists code inside kfree()+SLAB_POISON. - - 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/
