Re: New topic (PowerPC Linux PCI HELL)
On 18 Sep, this message from Gérard Roudier echoed through cyberspace:
>> > All I wanted was a function that allows the driver to decide that which
>> > needs to be enabled.
>> >
>> > pci_enable_device(struct pci_dev *dev, byte enable_mask)
>> >
>> > This would allow drivers to enable that which it needs and not weird out
>> > the hardware that does not like all of this extra fluff.
>>
>> Sounds not too daft
>>
>> static inline int pci_enable_device(struct pci_device *dev)
>> {
>> return pci_enable_device_features(USE_IO|USE_MM);
>> }
(snip)
> And what about other features ?
> I mean:
> - Bus Master
> - Memory Write and Invalidate
> - Parity Error response
This should probably be handled in arch-dependant code. So make a
pci_enable_device() per arch. The point beeing that only this code has a
chance to know some of the details of the PCI implementation on this
platform/arch. Bus master and MemWI don't hurt, but I guess enabling
parity can halt the bus. So you want to be careful... So:
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(~ENABLE_NONE);
}
and let pci_enable_device_features() chose which features make sense/are
safe.
Michel
-
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes|Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Timeout during booting up non-DMA hard-disks
On some motherboards the IRQs are shared by PCI slots, look out for that.
More importantly, if two or more PCI slots share the same Bus Master
Control Signal you are asking for trouble(assuming you are using both
slots)
[EMAIL PROTECTED]
On Mon, 18 Sep 2000, Terence Ang wrote:
> Dear All,
>
> Platforms
> ==
> Linux 2.2.17 with ide & raid patches.
>
> Problems
>
> We recently purchased an IDE Card (HPT370 chipsets) and connected two 540MB hard
> disks (PIO 3) to it.
>
> During booting up, the hard disks could be recognized. However, it wait a long
> time before proceeding the loading of the resources such as eth0, httpd.
>
> The followings are displayed during boot up:
> ...
> hde:hde: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hde: irq timeout: status=0x5a { DriveReady SeekComplete DataRequest Index }
> hde: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hde: irq timeout: status=0x5a { DriveReady SeekComplete DataRequest Index }
> hde: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hde: irq timeout: status=0x5a { DriveReady SeekComplete DataRequest Index }
> hde: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hde: irq timeout: status=0x5a { DriveReady SeekComplete DataRequest Index }
> hde: DMA disabled
> ide2: reset: success
> hde1
> ...
>
> Grateful for anyone's assistance.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: BPF in the kernel
kjh63 <[EMAIL PROTECTED]> writes: > > How Linux Kernel and BPF relate to each other: > > > > a) linux has BPF (I don't think so). It has LSF, the Linux Socket Filter. > > b) Linux has own equivalent of BPF (part of NAT?) Yes, the LSF. > > c) linux does not have anything like BPF BPF opcodes works on LSF. LSF has some extensions to BSF, like fetching which interface the packet came from. > > d) something else (if so, then what?) > > a) The Documentation/networking/filters.txt may say so but i dont think so > either: > > [root@localhost networking]# ls -al /dev/bpf0 > ls: /dev/bpf0: No such file or directory > [root@localhost networking]# cd /dev/ > [root@localhost /dev]# sh MAKEDEV bpf0 > MAKEDEV: don't know how to make device "bpf0" LSF does not work with devices nodes, it works with setsockopt: struct bpf_program bpfp; /* Fill bpfp */ setsockopt(SOL_SOCKET, SO_ATTACH_FILTER, , sizeof(bpfp)); > How can I make ethereal (or libpcap) work with LSF? Last time I checked libpcap was emulating BPF in user space. Which is bad of course because all packets are copied... Ideally, libpcap should be extended to support the LPFisms. A LSF filtering some ethernet traffic does not have to be bound to an interface. You can filter all the packets coming in. I can send you an example if you need so. Phil. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
Hello, On Mon, 18 Sep 2000, Andi Kleen wrote: > > SI_SIGIO is not generated from kernel. The same is for the > > other SI_ consts < 0 not defined with __SI_CODE. > > Ok, then you have already broken binary compatibility between 2.2 and 2.4 Looking in the old kernels, it seems the binary compatibility was broken in 2.3.21 when si_code returns POLL_xxx events just like mentioned in "The Single UNIX ® Specification, Version 2", xsh/signal.h.html and not SI_SIGIO. SI_SIGIO in si_code for 2.2 does not return any information about the events. I even see that Redhat maintains patch against 2.2 to backport the POLL_xxx events from 2.3. Not sure after the changes in 2.4.0-test1. Anyway, 2.2 looks unusable for me and I don't see other way this problem to be fixed. The binary compatibility is impossible to exist. The applications can support the both ways: the old SI_SIGIO and the new POLL_xxx events (recompiled after test1) in si_code. The next step is somebody to implement event merging and to allow receiving of many events with one call. For the next kernels. Regards -- Julian Anastasov <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: relocation truncated to fit: R_386_PC32
On Mon, 18 Sep 2000 21:28:20 -0700, "Armand" <[EMAIL PROTECTED]> wrote: >drivers/char/char.o(.text.lock+0x66a): relocation truncated to fit: >R_386_PC32 text.exit >make: *** [vmlinux] Error 1 > >I've upgraded to modutils-2.3.16-1 with Caldera OpenLinux LTP running on Nothing to do with modutils. Some code marked ___exit is doing a lock or semaphore operation. The .text.lock code is trying to call back to section text.exit but text.exit is discarded when building the kernel. for i in drivers/char/*.o do objdump -S -r -j .text.lock $i | egrep -B 8 'file format|text\.exit' done will list the name of each .o file in drivers/char and pull out any references from the .text.lock section back to text.exit. Report which .o file has a reference to text.exit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Rik's VM contains a deadlock somewhere
Hi Linus,
please, check carefully Rik's VM patch, it definitly contains a
deadlock, which can be seen on low-memory computers. Try mem=8m. I
wasn't able to use any Rik patch since against -test8 (-t8-vmpatch{2,4},
-test9-pre{1,2}). It boots fine(mem=16m), but then stalls begin for some
time and for infinitive time at last. I told Rik about it, he tried to
fix but wasn't successful.
With mem=8m it couldn't finish init scripts even.
--
Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
relocation truncated to fit: R_386_PC32
Hello, I end up getting this error when I make bzImage: drivers/char/char.o(.text.lock+0x66a): relocation truncated to fit: R_386_PC32 text.exit make: *** [vmlinux] Error 1 I've upgraded to modutils-2.3.16-1 with Caldera OpenLinux LTP running on a SuperMicro P6DNF with dual Pentium II Overdrive processors and the updated BIOS. I have been able to previously compile 2.4.0-test7-pre4. Any suggestions? TIA, Armand - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
BPF in the kernel
> How Linux Kernel and BPF relate to each other: > > a) linux has BPF (I don't think so). > b) Linux has own equivalent of BPF (part of NAT?) > c) linux does not have anything like BPF > d) something else (if so, then what?) a) The Documentation/networking/filters.txt may say so but i dont think so either: [root@localhost networking]# ls -al /dev/bpf0 ls: /dev/bpf0: No such file or directory [root@localhost networking]# cd /dev/ [root@localhost /dev]# sh MAKEDEV bpf0 MAKEDEV: don't know how to make device "bpf0" How can I make ethereal (or libpcap) work with LSF? Thanks Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with cscope and 2.4-test8 source file
Rusty writes:
> In message <[EMAIL PROTECTED]> you write:
>> * Mark Salisbury <[EMAIL PROTECTED]> [000918 07:32]:
>>> the source file linux/fs/hpfs/super.c
>>>
>>> from kernel version 2.4-test8 causes cscope to core dump during
>>> the database generation phase.
>>>
>>> the problem is the extremely long printk() string starting on
>>> line 280 in the function static inline void hpfs_help(void){}
>
> printk has a 1024 character limit. This printk must be broken up anyway.
No other filesystem driver has a built-in man page. HPFS is already
documented in mount.8, so there is no need to use kernel memory to
store additional documentation.
Of course, cscope still looks like a security hazard. One just needs
to sneak a buffer-overflow exploit patch past Linus. I'll guess that
this can be fixed by building cscope with flex in place of lex, not
that I've actually looked at the source though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, 18 Sep 2000, Olivier Galibert wrote: > On Mon, Sep 18, 2000 at 05:51:43PM -0700, Linus Torvalds wrote: > > Why would this not have happened for a module? > > > > I agree that the thing looks fishy. But this is not new code, and it has > > worked previously. What changed? > > Maybe nobody ever insmod'ed a module for a scsi device they don't > have? No, that's not it - the way most distributions do SCSI auto-detection is to load modules until they succeed. At least I _think_ that's what they do. That's what I'd do if I were a distribution maker. Anyway, I fixed this one up (untested), and fixed another thing that would cause modules to not get the version information correctly, and made a pre4. Whatever the cause for it not having been noticed before, it was a bug. And it should be gone. Good. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, Sep 18, 2000 at 05:51:43PM -0700, Linus Torvalds wrote: > Why would this not have happened for a module? > > I agree that the thing looks fishy. But this is not new code, and it has > worked previously. What changed? Maybe nobody ever insmod'ed a module for a scsi device they don't have? OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with cscope and 2.4-test8 source file
In message <[EMAIL PROTECTED]> you write:
> * Mark Salisbury <[EMAIL PROTECTED]> [000918 07:32]:
> > the source file linux/fs/hpfs/super.c
> >
> > from kernel version 2.4-test8 causes cscope to core dump during the database
> > generation phase.
> >
> > the problem is the extremely long printk() string starting on line 280 in t
he
> > function static inline void hpfs_help(void){}
printk has a 1024 character limit. This printk must be broken up anyway.
Rusty.
--
Hacking time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
Tigran Aivazian <[EMAIL PROTECTED]> said:
[...]
> did you try this patch?
>
> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> +++ work/drivers/pci/pci.cMon Sep 18 13:12:20 2000
> @@ -714,7 +714,7 @@
>* We need to blast all three values with a single write.
>*/
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> - if (!is_cardbus) {
> + if (is_cardbus) {
> /* Now we can scan all subordinate buses... */
> max = pci_do_scan_bus(child);
> } else {
No changes, same:
Linux PCMCIA Card Services 3.1.20
options: [pci] [cardbus] [pm]
Yenta IRQ list 04b0, PCI irq11
Socket status: 3007
Yenta IRQ list 04b0, PCI irq11
Socket status: 3020
cs: cb_alloc(bus 20): vendor 0x10b7, device 0x5257
PCI: Failed to allocate resource 0 for PCI device 10b7:5257
PCI: Failed to allocate resource 1 for PCI device 10b7:5257
PCI: Failed to allocate resource 2 for PCI device 10b7:5257
PCI: Failed to allocate resource 6 for PCI device 10b7:5257
PCI: Device 14:00.0 not available because of resource collisions
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre3: sit tunnel problems
ifconfig sit0 up tunnel ::206.123.31.102 SIOCSIFDSTADDR: No buffer space available Anyone know why it does this? I can't seem to find any documentation on that error... Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, 18 Sep 2000, David S. Miller wrote:
>
> The problem is that regardless of the tpnt->present setting, the
> MOD_DEC_USE_COUNT must occur.
>
>And again, why did this not show up with modules?
>
> I have no idea, I'm just the messenger in this case :-)
Hey, I didn't shoot you, I just want somebody from the SCSI camp to say
something.
Can you test whether changing the
if (tpnt->present)
return;
to a
if (tpnt->present) {
.. indent the linked list code and the remove_proc_entry stuff ..
}
fixes the oops for you?
> The boot logs looked something like (note the request_module messages,
> wheee...):
That "request_module[]: Root fs not mounted" message is going to get a lot
more common (and actually get removed) - there's a lot of stuff where we
want to exec a user mode helper, but where the bootup case is special. So
igore that - it's going away, by virtue of making the printk() disappear
;)
> SCSI device sdb: hdwr sector= 512 bytes. Sectors= 4194995 [2048 MB] [2.0 GB]
> sdb: sdb1 sdb2 sdb3
> ...
> scsi : 2 hosts.
>
> And precisely here is where the OOPS was seen.
Yeah, it's just after the ESP case, getting ready to do the ncr case..
Which will be silent due to not having any controller - until it oopses on
you.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: KERNELBASE
On Tue, 19 Sep 2000, Tulika Pradhan wrote: > can i use change the value of KERNELBASE from 0xc000 to 0x ? > does this cause any problems ? I'm pretty sure setting KERNELBASE to 0x000 leaves no room at all for user space, which would suck. Unless you plan on hacking a lot of other things, I don't think that would be useful (for a limited domain of the word useful). -MB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ISAPNP using an invalid IRQ, 2.4.0-test7
Jaroslav Kysela wrote:
>
> On Tue, 29 Aug 2000, M.H.VanLeeuwen wrote:
>
> > With default BIOS settings, IRQ 5 is unavailable for ISA yet
> > it is being assigned by the ne.c driver and NFS root system
> > doesn't finish booting.
> >
> > Is this a driver problem or a ISAPNP problem?
>
> It is general IRQ manager problem. ISA PnP code cannot determine which
> interrupts cannot be used. I think that we need some next layer between
> IO APIC control code and Plug & Play routines to exchange this information
> to prevent allocation of a free but unuseable IRQ for ISA PnP devices.
>
> Jaroslav
>
Jaroslav,
This patch is a first approximation to the above problem, can U look it over?
Basically, it discards any unusable IO_APIC IRQs from the list of IRQs that
ISA PNP is trying to allocate from - but only if IO_APIC IRQs are available.
This works for none APIC systems as well since io_apic_irqs s/b zero if
APIC's don't exist.
Comments?
Martin
--- /home/mhvl/linux.orig/drivers/pnp/isapnp.c Tue Jul 25 20:25:14 2000
+++ isapnp.cMon Sep 18 21:28:39 2000
@@ -33,10 +33,10 @@
#include
#include
#include
-#include
#include
#include
#include
+#include
LIST_HEAD(isapnp_cards);
LIST_HEAD(isapnp_devices);
@@ -1598,6 +1598,8 @@
if (irq < 0 || irq > 15)
return 1;
+ if (!IO_APIC_IRQ(irq) && io_apic_irqs)
+ return 1;
for (i = 0; i < 16; i++) {
if (isapnp_reserve_irq[i] == irq)
return 1;
--- /home/mhvl/linux.orig/drivers/pnp/isapnp_proc.c Wed Jul 12 23:58:43 2000
+++ isapnp_proc.c Wed Sep 13 22:39:47 2000
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
struct isapnp_info_buffer {
char *buffer; /* pointer to begin of buffer */
@@ -448,7 +449,7 @@
isapnp_printf(buffer, "%sIRQ ", space);
for (i = 0; i < 16; i++)
- if (irq->map & (1
KERNELBASE
can i use change the value of KERNELBASE from 0xc000 to 0x ? does this cause any problems ? tulika _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] (long) network interface changes
On Mon, 18 Sep 2000, David S. Miller wrote: >Date: Mon, 18 Sep 2000 21:31:17 -0400 (EDT) >From: jamal <[EMAIL PROTECTED]> > >My testing with the included scheme (#ifdef RAND_LIE) indicates >that fairness infact goes up; however, the overall throughput when >only one interface is utilizing the system goes down under heavy to >moderate congestion. I am including it here as a way to highlight >the problem. I think there could be better ways to do this. Code >is included and can be turned on by defining RAND_LIE in dev.c > > Why not keep a counter per-device. > > This counter is an atomic_t and initially zero. > > When a packet is given to netif_rx and becomes part of the backlog > this counter is incremented. > > When a packet leaves the backlog, this same counter is decremented. > > You can use this counter to approximate queue percentages per-device > and use this to decide who gets the little white lies. > Questions are whether this will be cheaper than calling net_random() What you describe is _exactly_ one of the schemes we discussed. Maintaining that device state info is cheap. You will need to consider the arrival rates, so you would sample the (same way we do in the patch) and maintain the average queue-contrib, per-device. The elegance required is in deciding the per-device quotas dynamically incase some devices is not using up its quota. Another scheme would be to do per-device queues ... soft-irq does a RR We need to experiment, show some numbers. That code exposes the problem and gives a less than optimal solution since no per-device state is maintained. > occaisionally and actually more interesting would be a scheme which > did not hurt the single interface case. :-( > The dynamic sharing of the per-device quoatas would help. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0test9-pre2 and pre1 wont boot
On Sun, Sep 17, 2000 at 06:14:11PM -0700, Christoph Lameter wrote: > With both version I get the "booting linux" message and then the first > line of the kernel messages. Then its dead. Have tried to change the kernel > configuration but to no avail. The problem was that the cputype was set to Pentium Pro. A new cputype K6 was introduced recently it seems And if you configure your kernel for Pentium Pro and boot it on an K6 then it hangs Not good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: uid
2.4 does indeed use 32-bit integers for uid and gid in all places, with the exception of BSD process accounting (for now). Quota should work fine with UIDs >65535; however, you can not use the full 32 bits of UID due to the format of the quota file. (you should be fine with hundreds of thousands or even millions of UIDs) To use 32-bit UIDs, you'll need to use a version of glibc with the proper kernel support. You do not need to recompile existing glibc software. The current development version of glibc (2.2, available only in CVS for the moment) has 32-bit UID support; you can also download a patched version of glibc 2.1 from here: http://eltopo.engin.umich.edu/caenlinux/6.1/i386/RedHat/RPMS/ with source here: http://eltopo.engin.umich.edu/caenlinux/6.1/SRPMS/SRPMS/ Sorry, everything I have at the moment is in RedHat 6.x compatible RPM format only. You can pull apart the source RPM to get the glibc patch out. I also have a patched version of linux 2.2.16 with 32-bit UID support compatible with 2.4 at the above URLs. Tracy: tar should work okay, I think; by default it uses textual user names instead of numeric UIDs. -Chris Wing [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: umount report "busy" on r/o remount of root filesystem
I seem to be able to reliably reproduce it as well. Let me know if I can be of any help. On Mon, Sep 18, 2000 at 03:38:28PM +0200, Udo A. Steinberg wrote: > This should probably be added to the 2.4.x bug-list. Since Pavel > seems to be able to constantly reproduce it, it should be possible to > track the problem down with his help. PGP signature
Re: [BUG] That bloody /usr/local busy back again
I finally had a chance to try it out under 2.2.17... no hint of a problem there. So presumably it is a 2.4.0-testX kernel issue. I don't know what apt-move does which triggers it, but it seems to do it quite reliably. On Sun, Sep 17, 2000 at 12:13:14PM -0500, Gregory T. Norris wrote: > Do you have an apt-move mirror on that filesystem, by any chance? I > see the same thing on an ext2 partition, which I've been able to > verify is *definately* related to apt-move. I haven't yet filed a > bug report, because I need to try it out under 2.2.17 first. PGP signature
Re: [PATCH] Re: SCSI scanning
On Mon, 18 Sep 2000, David S. Miller wrote:
>
> Did you try to boot these kernels containing scsi devices you
> don't have? I don't see how it could work (actually I do, see
> below).
Hmm..
Why would this not have happened for a module?
I agree that the thing looks fishy. But this is not new code, and it has
worked previously. What changed?
> Anyways, the code at the end of scsi_unregister_host should rather
> be something like:
>
> if (tpnt->present) {
> remove_proc_entry(tpnt->proc_name, proc_scsi);
> return;
> }
Umm, reading the code it looks more like the proper test would be
if (!tpnt->present)
return;
because if "present == 0", then the host not only won't have had the proc
entry added, it also won't have been added to the "scsi_hosts" list - so
the "remove the adapter from the linked list" step is the wrong way around
too. No?
(That linked list implementation, btw, is the worst possible list
implementation I have ever seen. Ugh).
And again, why did this not show up with modules?
Curious.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: GCC proposal for "@" asm constraint
> The reload of the address of `p' isn't necessary and gcc is wrong in > generating it. p is a constant embedded into the .text section ... It's perhaps not optimal, however I'm not sure that it's wrong. In any case if you can supply a small standalone test case (i.e. preprocessed source code) I'll take a quick look at things. I take it that you haven't tried the current gcc sources? -- John - | Feith Systems | Voice: 1-215-646-8000 | Email: [EMAIL PROTECTED] | |John Wehle| Fax: 1-215-540-5495 | | - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH/RFC] (long) network interface changes
I apologize for the over 10K email.. consider this documentation ;-> This is cross-posted to l-k; i would prefer the discussions on netdev or cc netdev (i am not subscribed to l-k) This is a port against 2.4.0-test8 based on the OLS presentation i made "Fast Forwarding the Bird" available at: http://robur.slu.se/Linux/net-development/jamal/FF-html/ There are lotsa improvements since OLS in a collaboration involving Robert Olsson and myself. Current snapshot is available via ftp from: ftp://robur.slu.se:/pub/Linux/net-development/FF-bird-current.tgz This includes a patched tulip driver; tested only on a DEC21143-based 4-port cards. This RFC at: ftp://robur.slu.se:/pub/Linux/net-development/README-FF To make things interesting robur.slu.se is currently running these patches. Acknowledgements - 1) Alexey Kuznetsov : Without his FF and FC these thoughts might never have been born. Alexey is still involved whenever time permits. 2) Robert Olsson : Many insights and current partner-in-crime 3) Donald Becker : Well thought network driver design. - Test updates September/2000: - Robert Olson and I decided after the OLS that we were going to try to hit the 100Mbps(148.8Kpps) routing peak by year end. I am afraid the bar has been raised. Robert is already hitting with 2.4.0-test7 ~148Kpps with a ASUS CUBX motherboard carrying PIII 700 MHZ coppermine with about 65% CPU utilization. With a single PII based Dell machine i was able to get a consistent value of 110Kpps. So the new goal is to go to about 500Kpps ;-> (maybe not by year end, but surely by that next random Linux hacker conference) A sample modified tulip driver (hacked by Alexey for 2.2 and mod'ed by Robert and myself over a period of time) is supplied as an example on how to use the feedback values. General blurb - To begin, i have to say that forwarding 100Mbps of 64byte packets is _not_ a problem at all in Linux; Alexey's Fast Forwarding does a fine job. FF, like in routers is _not_ subjected to Firewalling (eg CISCO Fast routing). So the challenge was to try and do it without FF turned on so we could do firewalling. ** Very important to note: Although the tests and improvements were for packet forwarding, the technique used applies for servers under a heavy load. System congestion is moved down to the hardware therefore alleviating the system overload. I believe we could have done better with the mindcraft tests with these changes in 2.2 (and HW FC turned on). [Fact is, HW FC was there but i suppose no-one knew you could use Alexey's hacked version of the Tulip ;->] The changes proposed below are transparent to drivers that dont use them. It is however highly encouraged they take advantage of the supplied interface. This does not break anything in 2.4. It is a clean patch. - This is a first cut, hopefully discussions will ensue and maybe a revision of the patch. In particular of interest are the recent weird requirements by the X.25 code. Refer to thread on l-k "Re: Q: sock output serialization" Henner, hoping to hear from you. - I intend on submitting this patch for inclusion in 2.4 since it is non-intrusive. I suspect there will be about one more revision. *** Proposed changes: Change 1) - netif_rx() now returns a value to the driver (change from void). The queue is divided into 4 configurable threshold regions: *no congestion zone *low congestion zone *moderate congestion *A high congestion zone. *A drop zone where packets are dropped. (the configuration interface is via /proc/sys/net/core/) A positive value (different for each of the regions) implies that the packet was successfully queued whereas a negative value implies it was dropped. The default congestion threshold values are based on engineering experimentation and not on theoretical scientific proofs. There are probably better ways of drawing up the associated thresholds. I would like to add that the HW FC feature is _a neccessary requirement_ to complement this. Maybe i should say this complements HW FC. If a driver keeps sending packets up to netif_rx() even when its been given feedback to stop, HW FC kicks in and the device is shut up; "sent to its room" so to speak. So the HW FC is considered the "when all else fails" rule. A separate document will describe how to use HW FC for driver authors. I think it should be a *mandantory* interface to drivers. The netif_rx() feedback helps the driver get 2 insights: i) understand the fate of the packets it sent up the stack. No point in continuing to blast packets to the stack when they are being dropped. (which happens today) ii) smartly gauge the congestion level on the stack and adjust the rate at which packets are being sent to the stack to reduce overall system load. A scheme which moves the congestion away from the system and onto the driver is considered a bonus. The tulip does this in two ways
Re: /proc/sys/vm/freepages not writable.
In article <[EMAIL PROTECTED]> you wrote: > How about taking a decaying average (loadavg style) of the peak allocation-free why? I think it is not a bad thing if you have some kind of setting like "irq heavy system" <-> "applicaion heavy system" even in NT you hve this slider. The current problem we have with linux that it is hard to tune cause the parameters are bad documented because theay change so often does not mean that parameter tuning is a bad thing in itself. I am used to increase freepages on my routers and i know that this is robust and i know that i am right with it.. and now average will kill of my atomic buffers while updatedb is running on those servers. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre3 bluesmoke patches
Patches for bluesmoke against 2.4.0-test9-pre3.
arch/i386/kernel/traps.c still contains
asmlinkage void reserved(void);
DO_ERROR(18, SIGSEGV, "reserved", reserved)
With a definition of reserved in entry.S. Vector 18 is now used for
machine check, lines removed.
Most C routines called from entry.S are called do_xxx where xxx is the
asm routine name, bluesmoke uses mcheck_fault. Also all routines
called from error_code have two parameters but bluesmoke does not
declare them. mcheck_fault renamed to do_machine_check and the
standard parameters added, consistency is good.
Index: 0-test9-pre3.1/arch/i386/kernel/traps.c
--- 0-test9-pre3.1/arch/i386/kernel/traps.c Tue, 19 Sep 2000 10:36:07 +1100 kaos
(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3 644)
+++ 0-test9-pre3.1(w)/arch/i386/kernel/traps.c Tue, 19 Sep 2000 11:49:02 +1100 kaos
+(linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3 644)
@@ -92,7 +92,6 @@ asmlinkage void general_protection(void)
asmlinkage void page_fault(void);
asmlinkage void coprocessor_error(void);
asmlinkage void simd_coprocessor_error(void);
-asmlinkage void reserved(void);
asmlinkage void alignment_check(void);
asmlinkage void spurious_interrupt_bug(void);
asmlinkage void machine_check(void);
@@ -312,7 +311,6 @@ DO_ERROR(10, SIGSEGV, "invalid TSS", inv
DO_ERROR(11, SIGBUS, "segment not present", segment_not_present)
DO_ERROR(12, SIGBUS, "stack segment", stack_segment)
DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN, get_cr2())
-DO_ERROR(18, SIGSEGV, "reserved", reserved)
asmlinkage void do_general_protection(struct pt_regs * regs, long error_code)
{
Index: 0-test9-pre3.1/arch/i386/kernel/entry.S
--- 0-test9-pre3.1/arch/i386/kernel/entry.S Tue, 19 Sep 2000 10:36:07 +1100 kaos
(linux-2.4/A/c/3_entry.S 1.1.2.2.2.2.1.4 644)
+++ 0-test9-pre3.1(w)/arch/i386/kernel/entry.S Tue, 19 Sep 2000 11:59:19 +1100 kaos
+(linux-2.4/A/c/3_entry.S 1.1.2.2.2.2.1.4 644)
@@ -381,11 +381,6 @@ ENTRY(coprocessor_segment_overrun)
pushl $ SYMBOL_NAME(do_coprocessor_segment_overrun)
jmp error_code
-ENTRY(reserved)
- pushl $0
- pushl $ SYMBOL_NAME(do_reserved)
- jmp error_code
-
ENTRY(double_fault)
pushl $ SYMBOL_NAME(do_double_fault)
jmp error_code
@@ -416,7 +411,7 @@ ENTRY(page_fault)
ENTRY(machine_check)
pushl $0
- pushl $ SYMBOL_NAME(mcheck_fault)
+ pushl $ SYMBOL_NAME(do_machine_check)
jmp error_code
ENTRY(spurious_interrupt_bug)
Index: 0-test9-pre3.1/arch/i386/kernel/bluesmoke.c
--- 0-test9-pre3.1/arch/i386/kernel/bluesmoke.c Tue, 19 Sep 2000 10:36:07 +1100 kaos
(linux-2.4/c/d/7_bluesmoke. 1.1 644)
+++ 0-test9-pre3.1(w)/arch/i386/kernel/bluesmoke.c Tue, 19 Sep 2000 11:42:50 +1100
+kaos (linux-2.4/c/d/7_bluesmoke. 1.1 644)
@@ -11,7 +11,7 @@
static int banks = 0;
-void mcheck_fault(void)
+void do_machine_check(struct pt_regs * regs, long error_code)
{
int recover=1;
u32 alow, ahigh, high, low;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: GCC proposal for "@" asm constraint
On Mon, Sep 18, 2000 at 07:53:04PM -0400, John Wehle wrote:
> What version of gcc? Recently some work was done to improve the handling of
> constant memory.
I'm using 2.95.2 19991024.
Take this small testcase:
#include
int * p;
spinlock_t lock = SPIN_LOCK_UNLOCKED;
extern void dummy(int, int);
myfunc() {
int a, b;
spin_lock();
a = *p;
spin_unlock();
spin_lock();
b = *p;
spin_unlock();
dummy(a,b);
}
If I compile it with:
gcc -O2 -D__SMP__ -I ~/kernel/devel/2.2.18pre9aa1/include/ -S p.c
where 2.2.18pre9aa1 is the current spinlock implementation without
the "memory" clobber and with the __dummy trick I get:
.file "p.c"
.version"01.01"
gcc2_compiled.:
.globl lock
.data
.align 4
.typelock,@object
.sizelock,4
lock:
.long 0
.text
.align 16
.globl myfunc
.typemyfunc,@function
myfunc:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
#APP
1: lock ; btsl $0,lock
jc 2f
.section .text.lock,"ax"
2: testb $1,lock
jne 2b
jmp 1b
.previous
#NO_APP
movl p,%eax
^^^
movl (%eax),%edx
#APP
lock ; btrl $0,lock
1: lock ; btsl $0,lock
jc 2f
.section .text.lock,"ax"
2: testb $1,lock
jne 2b
jmp 1b
.previous
#NO_APP
movl (%eax),%eax
#APP
lock ; btrl $0,lock
#NO_APP
addl $-8,%esp
pushl %eax
pushl %edx
call dummy
movl %ebp,%esp
popl %ebp
ret
.Lfe1:
.sizemyfunc,.Lfe1-myfunc
.comm p,4,4
.ident "GCC: (GNU) 2.95.2 19991024 (release)"
If now I repeat the same after applying this patch to the
kernel tree that I was inlining:
--- 2.2.18pre9aa1/include/asm-i386/spinlock.h.~1~ Mon Sep 18 04:56:28 2000
+++ 2.2.18pre9aa1/include/asm-i386/spinlock.h Tue Sep 19 03:04:56 2000
@@ -173,12 +173,12 @@
#define spin_lock(lock) \
__asm__ __volatile__( \
spin_lock_string \
- :"=m" (__dummy_lock(lock)))
+ :"=m" (__dummy_lock(lock)) : : "memory")
#define spin_unlock(lock) \
__asm__ __volatile__( \
spin_unlock_string \
- :"=m" (__dummy_lock(lock)))
+ :"=m" (__dummy_lock(lock)) : : "memory")
#define spin_trylock(lock) (!test_and_set_bit(0,(lock)))
I then get this assembler:
.file "p.c"
.version"01.01"
gcc2_compiled.:
.globl lock
.data
.align 4
.typelock,@object
.sizelock,4
lock:
.long 0
.text
.align 16
.globl myfunc
.typemyfunc,@function
myfunc:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
#APP
1: lock ; btsl $0,lock
jc 2f
.section .text.lock,"ax"
2: testb $1,lock
jne 2b
jmp 1b
.previous
#NO_APP
movl p,%eax
^^^
movl (%eax),%edx
#APP
lock ; btrl $0,lock
1: lock ; btsl $0,lock
jc 2f
.section .text.lock,"ax"
2: testb $1,lock
jne 2b
jmp 1b
.previous
#NO_APP
movl p,%eax
^^^
movl (%eax),%eax
#APP
lock ; btrl $0,lock
#NO_APP
addl $-8,%esp
pushl %eax
pushl %edx
call dummy
movl %ebp,%esp
popl %ebp
ret
.Lfe1:
.sizemyfunc,.Lfe1-myfunc
.comm p,4,4
.ident "GCC: (GNU) 2.95.2 19991024 (release)"
The diff between the generated asms:
--- p.s.default-spinlocks Tue Sep 19 03:10:14 2000
+++ p.s.memory Tue Sep 19 03:10:29 2000
@@ -39,6 +39,7 @@
jmp 1b
.previous
#NO_APP
+ movl p,%eax
movl (%eax),%eax
#APP
lock ; btrl $0,lock
The reload of the address of `p' isn't necessary and gcc is wrong in generating
it. p is a constant embedded into the .text section and set at link time, the
only way to change it would be if the assembler that declares "memory" as
clobber would be self modifying the code itself and gcc should assume nothing
about self modifying code instead (none bit of IA32 linux is self modifying).
The above reload are just wasted CPU cycles that we're little worried to waste.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
On Mon, Sep 18, 2000 at 08:04:21PM +0200, Julian Anastasov wrote: > > Hello, > > Everything looks good after test1 except the extra > '<< 16' in __SI_CODE. > > SI_SIGIO is not generated from kernel. The same is for the > other SI_ consts < 0 not defined with __SI_CODE. Ok, then you have already broken binary compatibility between 2.2 and 2.4 -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
In article <[EMAIL PROTECTED]> you wrote: > (1) An in-kernel resident lump, providing very basic services: > * file-change notification this is interesting for other stuff too, i think irix has an interface for that, i think its an ioctl? > * unicode string handling/conversion (steal/share from NTFS) are you sure this needs to be done in the kernel? if you wat to steal the sourcecode of the ntfs driver do it, but why would u wat to share object code for that? > * simple RPC mechanism for building certain services in userspace what is that? message passing? in kernel space? > (2) A partial basic Win32 implementation (modulable): > * basic Win32 syscalls, eg: CreateMutexA/W > * _no_ GDI calls actuelly kCGI is there? Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
Please kill this thread. Linus has stated he does not want a kernel debugger in the standard kernel. As the maintainer of kdb I accept that decision and will maintain kdb outside the kernel. Any other discussion is just noise. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[not a bug] apm resume and return to vc/1
'twas user error, apmd does it. mea culpa. -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
RE: Availability of kdb
Gene did the instruction set architecture along with some others. I think he was also involved in the i/o architecture. -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED]] Sent: Monday, September 18, 2000 4:59 PM To: Marty Fouts Cc: 'Malcolm Beattie'; [EMAIL PROTECTED] Subject: RE: Availability of kdb Gene Amdahl I think... On Mon, 18 Sep 2000, Marty Fouts wrote: > I think that more people quote Brooks than have read him and that more > people know him from the Mythical Man Month than from the POO. > > He wasn't, by the way, the principle architect of OS/360; he was the manager > of the 360 development organization. I will email a monster cookie to the > first person who correctly identifies the original architect of OS/360. > > And yes, if Linus manages to learn some new lesson from Linux and writes a > book about it of the endurance of MMM, I'll be shown wrong in my assertion > about his being remembered. > > By the way, my favorite part of the anniversary edition of MMM is Brooks' > apology to Gries about being wrong about information hiding. > > -Original Message- > From: Malcolm Beattie [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 18, 2000 3:22 AM > To: [EMAIL PROTECTED] > Subject: Re: Availability of kdb > > Marty Fouts writes: > > Here's another piece of free advice, worth less than you paid for it: in > 25 > > years, only the computer history trivia geeks are going to remember you, > > just as only a very small handful of us now remember who wrote OS/360. > > You mean like Fred Brooks who managed the development of OS/360, had > some innovative ideas about how large software projects should be run, > whose ideas clashed with contemporary ones, who became a celebrity? > You don't spot any parallels there? He whose book "Mythical Man Month" > with "No Silver Bullet" and "The Second System Effect" are quoted > around the industry decades later? And you think that's only a small > handful of people? > > --Malcolm > > -- > Malcolm Beattie <[EMAIL PROTECTED]> > Unix Systems Programmer > Oxford University Computing Services > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > -- -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Date:Mon, 18 Sep 2000 15:58:02 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
The SCSI stuff is pretty straightforward, and it works for me (and
I also built a kernel with all regular x86-capable SCSI drivers
included, so the others got at least that level of testing). But
there are some non-x86 scsi drivers out there etc, so give it a
whirl.
Did you try to boot these kernels containing scsi devices you
don't have? I don't see how it could work (actually I do, see
below).
Look at drivers/scsi/scsi.c:scsi_unregister_host, near the
end we have code like this:
if (tpnt->present)
return;
...
remove_proc_entry(tpnt->proc_name, proc_scsi);
Compare this to the code in scsi_register_host which explicitly
does not create the procfs nodes if tpnt->present == 0.
Is this another case of ix86 not trapping NULL pointer derefernces
during bootup? I got it on Sparc in strlen of tpnt->proc_name
as a result of this remove_proc_entry() call. Is there some way
to make ix86 start trapping on NULL pointers earlier in the boot
sequence so these kinds of bugs don't live very long?
Anyways, the code at the end of scsi_unregister_host should rather
be something like:
if (tpnt->present) {
remove_proc_entry(tpnt->proc_name, proc_scsi);
return;
}
...
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Availability of kdb
Gene Amdahl I think... On Mon, 18 Sep 2000, Marty Fouts wrote: > I think that more people quote Brooks than have read him and that more > people know him from the Mythical Man Month than from the POO. > > He wasn't, by the way, the principle architect of OS/360; he was the manager > of the 360 development organization. I will email a monster cookie to the > first person who correctly identifies the original architect of OS/360. > > And yes, if Linus manages to learn some new lesson from Linux and writes a > book about it of the endurance of MMM, I'll be shown wrong in my assertion > about his being remembered. > > By the way, my favorite part of the anniversary edition of MMM is Brooks' > apology to Gries about being wrong about information hiding. > > -Original Message- > From: Malcolm Beattie [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 18, 2000 3:22 AM > To: [EMAIL PROTECTED] > Subject: Re: Availability of kdb > > Marty Fouts writes: > > Here's another piece of free advice, worth less than you paid for it: in > 25 > > years, only the computer history trivia geeks are going to remember you, > > just as only a very small handful of us now remember who wrote OS/360. > > You mean like Fred Brooks who managed the development of OS/360, had > some innovative ideas about how large software projects should be run, > whose ideas clashed with contemporary ones, who became a celebrity? > You don't spot any parallels there? He whose book "Mythical Man Month" > with "No Silver Bullet" and "The Second System Effect" are quoted > around the industry decades later? And you think that's only a small > handful of people? > > --Malcolm > > -- > Malcolm Beattie <[EMAIL PROTECTED]> > Unix Systems Programmer > Oxford University Computing Services > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > -- -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
On Mon, Sep 18, 2000 at 03:41:11PM -0700, John Byrne wrote:
> 1.) Any decision on what the bigger dev_t will be? 16-bit major and
> 16-bit minor, for example?
My old code does something like this:
major = (dev >> 32);
minor = (dev & 0x);
if (!major) {
major = (dev >> 16);
minor = (dev & 0x);
if (!major) {
major = (dev >> 8);
minor = (dev & 0xff);
}
}
In other words: If the whole thing is 16-bit, there is an 8-8
split. If the whole thing is 32-bit, there is a 16-16 split.
Etc.
This allows all the old device numbers to stay.
The present isofs code uses a similar algorithm.
In principle of course a device number is a structureless number,
but mknod needs it in two components, and ls lists it in two
components. Otherwise the partition does not play a role.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: GCC proposal for "@" asm constraint
> I read the asm produced by some of some of my testcases. The current spinlock > implementation seems to do exactly the _right_ thing in practice and nothing > more. "memory" was instead causing reloads of constant addresses into registers > and stuff that shouldn't be necessary (I was infact wondering about the reason > of those suprious loads also in my first email). What version of gcc? Recently some work was done to improve the handling of constant memory. -- John - | Feith Systems | Voice: 1-215-646-8000 | Email: [EMAIL PROTECTED] | |John Wehle| Fax: 1-215-540-5495 | | - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Availability of kdb
I think that more people quote Brooks than have read him and that more people know him from the Mythical Man Month than from the POO. He wasn't, by the way, the principle architect of OS/360; he was the manager of the 360 development organization. I will email a monster cookie to the first person who correctly identifies the original architect of OS/360. And yes, if Linus manages to learn some new lesson from Linux and writes a book about it of the endurance of MMM, I'll be shown wrong in my assertion about his being remembered. By the way, my favorite part of the anniversary edition of MMM is Brooks' apology to Gries about being wrong about information hiding. -Original Message- From: Malcolm Beattie [mailto:[EMAIL PROTECTED]] Sent: Monday, September 18, 2000 3:22 AM To: [EMAIL PROTECTED] Subject: Re: Availability of kdb Marty Fouts writes: > Here's another piece of free advice, worth less than you paid for it: in 25 > years, only the computer history trivia geeks are going to remember you, > just as only a very small handful of us now remember who wrote OS/360. You mean like Fred Brooks who managed the development of OS/360, had some innovative ideas about how large software projects should be run, whose ideas clashed with contemporary ones, who became a celebrity? You don't spot any parallels there? He whose book "Mythical Man Month" with "No Silver Bullet" and "The Second System Effect" are quoted around the industry decades later? And you think that's only a small handful of people? --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Unix Systems Programmer Oxford University Computing Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
On Mon, Sep 18, 2000 at 08:56:58PM +0200, Jamie Lokier wrote: [...making SI_FROMUSER exclude SI_ASYNCIO and SI_TIMER...] I haven't checked, but I suspect that would break the glibc user space implementations. Overall the concept of kernel reserved numbers doesn't make too much sense as a API because there is always a legitimate need to emulate it in userspace when you have appropiate credentials. It is just a convenient hack to bypass the credentials checking in signal sending for some cases. > > It'll break programs that try to send SI_SIGIO (=-5) signals from userspace, > > but I think that is ok. > > Actually rt_sigqueueinfo has this test hard-coded in it: > > if (info.si_code >= 0) > return -EPERM; > > with a comment "not even root is allowed to send signals from the > kernel". Changing SI_FROMUSER won't affect this. My patch of course changed this line to if (!SI_FROMUSER()), you probably missed that hunk.. There are two approaches: break the programs that expect to parse si_code in signals/sigwaitinfo or break the program that use sigqueueinfo() with arbitary values. I would have expected that the second one is less painless, but it turned out someone already took the first approach for SIGIO in 2.4 by turning si_code into a bastardized si_band (which I don't quite follow, because si_band already exists) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Availability of kdb
Then I suggest you skip the one paragraph at the beginning of my comment that wasn't appropriately diplomatic and read the portion that you snipped. It contains a wee bit of wisdom. -Original Message- From: Tigran Aivazian [mailto:[EMAIL PROTECTED]] Sent: Monday, September 18, 2000 1:36 AM To: Marty Fouts Cc: 'Larry McVoy'; 'Linus Torvalds'; Oliver Xymoron; Daniel Phillips; Kernel Mailing List Subject: RE: Availability of kdb On Sun, 17 Sep 2000, Marty Fouts wrote: > I've probably debugged more operating systems under more varied environments > than nearly anyone here, having brought up a new OS, compiler, and CPU yea yea yea, if you are so good then you should be concentrating on giving your goodness and wisdom and experience to us and not boast about it. For to give is more blessed than receive. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
This will probaly fix a bunch of scsi problems in tytso's list at linux24.sourceforge.net. Could people please verify this and send him a note. Thanks. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The INN/mmap bug
Andreas Dilger wrote: > > Daniel writes: > > Alexander Viro wrote: > > > On Mon, 18 Sep 2000, Andreas Dilger wrote: > > > > This may actually be a problem in the future... what about shared access > > > > block devices like FCAL or a distributed filesystem? It has to be > > > > possible for pages to become non-uptodate in a sane way. > > > > > > So what the heck do you do when something modifies mmaped page when you > > > get the change of on-disk one? Say it, writer is notified that write had > > > been completed, sends packet to you and you flip a bit on a page that > > > happens to be mmaped on the place where write had happened. > > > > > > Write-through-pagecache is OK, but write straight to disk bypassing the > > > cache? Welcome to the fun with aliases... > > > > Yes, I think that's one rule we can write down right now: to update a > > block on disk you have to go through the buffer. Not going through > > the buffer is about the same as accessing a semaphore-protected > > resource without bothering with the semaphore. > > What I'm getting at is that the local system didn't make the change at all, > so there is _no way_ to make the write go through the local cache. > The write to disk happens on a remote system. The only thing that happens > on the local system is that it gets a message that a buffer is invalid. > > You don't want to have to re-send each buffer to each system that ever > read it. It is much better to simply invalidate the cache, and only if > the client accesses it again will it be re-read. > > It should be possible to mark a page non-uptodate, so that the next time > it is accessed locally it will re-read the _new_ data from disk. Think > of the fs "revalidate" method. Yes, this is a cache coherency protocol. I should have said you have to go through the *buffer head*, it's what I meant. You can't just invalidate the buffer any time you want, you have to wait until there are no readers/writers first. Ooh, my head hurts, I was just trying to write a simple filesystem extension and now I'm getting sucked into distributed filesystems... *** goes back to hunting down tailmerge races -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The INN/mmap bug
Linus Torvalds wrote: > > On Mon, 18 Sep 2000, Alexander Viro wrote: > > That's what makes me unhappy about the current situation + obvious > > fixes. It works, but the proof is... well, not pretty. > > Oh, agreed. I think we should clean up the code. I looked at it yesterday, > and it didn't look all that horribly bad, but I lost interest It is horribly bad, just not unmanageably horribly bad. > I don't know if it is worth doing before 2.4.x, as the current code certainly > should work with the small changes already proposed. Emphatically agreed. The buffer/cache states are in need of repair, that's pretty obvious. Getting them to where they are seen to be correct will take some time and will hit a lot of code. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GCC proposal for "@" asm constraint
On Mon, Sep 18, 2000 at 03:39:50PM -0700, Linus Torvalds wrote: > Have you looked at the code it generates? Quite sad, really. I read the asm produced by some of some of my testcases. The current spinlock implementation seems to do exactly the _right_ thing in practice and nothing more. "memory" was instead causing reloads of constant addresses into registers and stuff that shouldn't be necessary (I was infact wondering about the reason of those suprious loads also in my first email). Said that I heard that some recent gcc miscompiles the kernel and we also have to always compile with -fno-strict-aliasing. I think gcc developers should comment about this issue. If they say the __dummy way is still going to be safe for some gcc release, we can skip those spurious loads caused by the "memory" clobber. From the email I received from Richard Henderson in this thread it seems they prefer that the kernel doesn't relys on those __dummy just now (and they have the rights to complain because that's a kernel bug). Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
"J. Dow" wrote:
>
> Jeff et al who might prefer a kernel debugger,
>
> One should note that when a person or critter is backed into a corner
> and pressured hard enough that he makes an "over my dead body"
> level statement more pressure is likely to solidify the position rather
> than change it. In the case of a critter it is tied up with survival. With a
> person it is often tied up with "face". At this point Linus has been led
> to making a very strong negative comment about kernel debuggers.
> He is pretty much in a position now that "demands" he not change that
> opinion lest he appear to be a weak leader. We were all foolish to
> back him into a corner.
>
> I see an image of a penguin. He is wearing a bandana around his
> forehead and cammie's for clothes. He is armed with an impressive
> array of things which carve and cut and things which go bang and
> boom and make holes in other things. He is glariing over the top of
> a foxhole filled with even more such tools screaming, "You'll have that
> kernel debugger in my main Linux build over my cold dead body!"
>
> Now, who makes the cartoon for that one? (And if the penguin had
> a superficial resemblance to Linus it'd be DELIGHTFUL!)
I think Linus statements are sincere about his development philosophy,
and I have a hard time accepting this characterization of his motives.
>From what I have heard from several folks who have worked with him for
many years, he has espoused this view relative to kernel debuggers for a
long time.
Jeff
>
> {^_-}Joanne "A crazed maniac herself" Dow, [EMAIL PROTECTED]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Ok, there's a test9-pre3 there now.. The SCSI stuff is pretty straightforward, and it works for me (and I also built a kernel with all regular x86-capable SCSI drivers included, so the others got at least that level of testing). But there are some non-x86 scsi drivers out there etc, so give it a whirl. Basic approach: remove all #ifdef MODULE, and get rid of the hosts.c hardcoded listing of SCSI devices - let SCSI controller drivers do their own initialization. Linus - pre1: - USB: OHCI controller unlink and bandwidth reclamation fixes - USB: storage update - sparc64: register window race. Non-deadlock rwlocks. - name clash in hamradio/pi2.c and hamradio/pt.c - epic100 credits, 8139too driver update, sr.c initcalls - acenic update - NFS sillyrename fixups - mktime(). Do it just once - not 16 times. - misc small fixes to random drivers by Tigran - IDE driver picks up master/slave relationships on its own. - truncate unmapped/uptodate case handled correctly - don't do notifier locking at low level: higher levels do (or should do) this already. - ACPI interpreter updates (and file renames - making this part big) - SysKonnect gigabit driver update - 3c59x driver update - pcmcia debounce logic. Ugh. - MM balancing (Rik Riel) - pre2: - "extern inline" -> "static inline". It doesn't matter right now, but it's proactive for future gcc versions. - various net drvr updates and fixes - more initcall updates - PPC updates (including PPC-related drivers etc) - disallow re-mounting same filesystem in same place multiple times. Too confusing. And /etc/mtab gets strange. - Riel VM update - sparc updates - PCI bridge scanning fix: assign numbers properly - network updates - scsi fixes - pre3: - uninitialized == zero. Remove extra initializers. - block_prepare_write and block_truncate_page: if the page is up-to-date, then so are the buffer heads inside it once they are mapped.. - SCSI initialization - move over to the modular case. No more double initialization. - Sync up with Alans 2.2.x driver changes - networking updates (iipv6 works non-modular etc) - netfilter update - adfs correct dentry operations - ARM update (including ARM drivers) - acenic driver update - floppy: we'd better hold the io_request_lock when playing with "CURRENT". - NFS cache coherency across file locking fix - NFS over TCP - handle TCP socket writability right.. - USB updates - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel 2.4.0-test8
Attached, for possible inclusion in the Linux kernel, is a patch for the
Linux-2.4.0-test8 kernel that causes core dumps to output appropriate
information for multithreaded programs for use by gdb. Currently only ELF
files are supported but other formats can easily add their own functions
to support this feature if desired.
Affected Files:
fs/binfmt_elf.c
fs/exec.c
include/linux/binfmts.h
include/linux/sysctl.h
kernel/sysctl.c
Summary of the changes:
To opt out the changes we made to the dumping of elf cores, we added an
integer named dumptcores into the proc interface. This integer is located
at /proc/sys/kernel/dumptcores
We added a function pointer named tcore_dump to the end of the binfmt
structure.
In the initialization of the elf_binfmt structure, we initialize
tcore_dump to point at elf_tcore_dump. Due to the C specification, the
initializations that do not set this function pointer set it to NULL.
We added a tcore_list_node structure that holds the thread-specific
information that we will output.
We added several list mainpulating functions to operate on that list.
We added a check in do_coredump to see if tcore_dump exists-if so, we call
it.
We added the function elf_tcore_dump which grabs the registers and other
pertinant information from current, and stores them on a linked list for
later use.
We modified the elf_core_dump procedure so that it creates a new PT_NOTE
section in the core and outputs all of the thread-specific information to
that section.
Usage:
echo 1 > /proc/sys/kernel/dumptcores to turn on multithreaded elf core
dumping. Any other number will result in the previous style of core
dumps. The default value of this number is 0.
Turning it on at any time does not pose a problem but, once enabled, if
it is turned off a memory leak may occur if a multithreaded program was
currently dumping a core. Therefore once enabled it should not be
disabled.
After this, run gdb as normal on any core files and all the thread
information will be available to you through the "thread" commands
inside gdb.
Tests:
We tested this patch on programs with several hundred threads running
concurrently. It was also tested by Spinway, Inc. on some
of their code.
Please respond to us with any suggestions/comments about this patch.
Jason Villarreal ([EMAIL PROTECTED])
John Jones ([EMAIL PROTECTED])
diff -b -r -u linux/fs/binfmt_elf.c linux-changed/fs/binfmt_elf.c
--- linux/fs/binfmt_elf.c Tue Jul 11 15:43:45 2000
+++ linux-changed/fs/binfmt_elf.c Thu Jul 27 14:45:03 2000
@@ -9,6 +9,16 @@
* Copyright 1993, 1994: Eric Youngdale ([EMAIL PROTECTED]).
*/
+/*
+ * Added support for dumping multithreaded cores.
+ *
+ * John Jones (jjones @cs.ucr.edu)
+ * Jason Villarreal ([EMAIL PROTECTED])
+ * University of California, Riverside
+ *
+ * Supported by funding from Spinway Inc.
+ */
+
#include
#include
@@ -39,6 +49,13 @@
#include
+/* Forward declarations used for multithreaded core dump */
+struct tcore_list_node;
+
+static void append_tcore(struct tcore_list_node* to_append);
+static void remove_tcore(struct tcore_list_node* to_remove);
+static int elf_tcore_dump(long signr, struct pt_regs* regs);
+
static int load_elf_binary(struct linux_binprm * bprm, struct pt_regs * regs);
static int load_elf_library(struct file*);
extern int dump_fpu (struct pt_regs *, elf_fpregset_t *);
@@ -64,7 +81,7 @@
#define ELF_PAGEALIGN(_v) (((_v) + ELF_EXEC_PAGESIZE - 1) & ~(ELF_EXEC_PAGESIZE - 1))
static struct linux_binfmt elf_format = {
- NULL, THIS_MODULE, load_elf_binary, load_elf_library, elf_core_dump,
ELF_EXEC_PAGESIZE
+ NULL, THIS_MODULE, load_elf_binary, load_elf_library, elf_core_dump,
+ELF_EXEC_PAGESIZE, elf_tcore_dump
};
static void set_brk(unsigned long start, unsigned long end)
@@ -965,6 +982,38 @@
#define DUMP_SEEK(off) \
if (!dump_seek(file, (off))) \
goto end_coredump;
+
+/*
+ This is the variable that can be set in proc to determine if we want to
+dump a multithreaded core or not. A value of 1 means yes while any
+other value means no.
+
+It is located at /proc/sys/kernel/dumptcores
+*/
+
+int dumptcores = 0;
+
+/* This is the head and tail of a linked list of tcores (thread
+specific information)
+*/
+
+struct tcore_list_node *tcore_head = NULL, *tcore_tail = NULL;
+
+/* We also need a lock for the linked list in case two people are
+ dumping the core at the same time */
+
+spinlock_t tcore_lock = SPIN_LOCK_UNLOCKED;
+
+/* Here is the actual tcore structure */
+
+struct tcore_list_node
+{
+ struct elf_prstatus info;
+ struct tcore_list_node *next;
+ struct tcore_list_node *prev;
+};
+
+
/*
* Actual dumper
*
@@ -972,6 +1021,7 @@
* and then they are actually written out. If we run out of core limit
* we just truncate.
*/
+
static int elf_core_dump(long signr, struct pt_regs
Re: The INN/mmap bug
Daniel writes: > Alexander Viro wrote: > > On Mon, 18 Sep 2000, Andreas Dilger wrote: > > > This may actually be a problem in the future... what about shared access > > > block devices like FCAL or a distributed filesystem? It has to be > > > possible for pages to become non-uptodate in a sane way. > > > > So what the heck do you do when something modifies mmaped page when you > > get the change of on-disk one? Say it, writer is notified that write had > > been completed, sends packet to you and you flip a bit on a page that > > happens to be mmaped on the place where write had happened. > > > > Write-through-pagecache is OK, but write straight to disk bypassing the > > cache? Welcome to the fun with aliases... > > Yes, I think that's one rule we can write down right now: to update a > block on disk you have to go through the buffer. Not going through > the buffer is about the same as accessing a semaphore-protected > resource without bothering with the semaphore. What I'm getting at is that the local system didn't make the change at all, so there is _no way_ to make the write go through the local cache. The write to disk happens on a remote system. The only thing that happens on the local system is that it gets a message that a buffer is invalid. You don't want to have to re-send each buffer to each system that ever read it. It is much better to simply invalidate the cache, and only if the client accesses it again will it be re-read. It should be possible to mark a page non-uptodate, so that the next time it is accessed locally it will re-read the _new_ data from disk. Think of the fs "revalidate" method. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
"H. Peter Anvin" wrote: > > Followup to: <[EMAIL PROTECTED]> > By author:John Byrne <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Anyway, one of the things I was hoping to find out by going to > > linux-kernel was if there was anything other than devfs in the offing: > > such a larger dev_t. So if anyone wants to chime in on things other than > > devfs, I'd certainly like to hear about it. > > > > A larger dev_t is a "must have" item for 2.5. > > -hpa A couple of last details (sorry for being such a slug in following up): 1.) Any decision on what the bigger dev_t will be? 16-bit major and 16-bit minor, for example? 2.) Are there any plans to try to change the user dev_t to an opaque type? Grepping through the Redhat distribution's application sources reveals several things that compare major numbers determine the type of the device. (Some explictly hardcoded; others use the constants in linux/major.h, but compare several majors for IDE/SCSI.) To me, this kind of explicit knowledge compiled into applications is something to be avoided; even when there are relatively few applications that do this. Of course, there is a strong argument for KISS, here: most of these applications should work with a simple recompilation and the need for multiple majors will be reduced once the bigger dev_t is introduced. Thanks, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>
> Marty,
>
> I think they said they could care less about kernel debuggers. Just go
> write one, use Keith's or ours or whatever, and do what you want with
> your Linux development -- Linus doesn't seem to care if you just make a
> fork of Linux or someone else does with a debugger for your projects.
> These guys have been debugging and developing their OS over the internet
> for a long time, their debugging methods seem more tied to their
> "telepathic repore" with each other and some very solid and studious
> skills at reviewing code rapidly and a thorough understanding of it.
> They also have the luxury of taking the world at their own pace with
> Linux evolution and have stated no desire to change their philosophy.
Jeff et al who might prefer a kernel debugger,
One should note that when a person or critter is backed into a corner
and pressured hard enough that he makes an "over my dead body"
level statement more pressure is likely to solidify the position rather
than change it. In the case of a critter it is tied up with survival. With a
person it is often tied up with "face". At this point Linus has been led
to making a very strong negative comment about kernel debuggers.
He is pretty much in a position now that "demands" he not change that
opinion lest he appear to be a weak leader. We were all foolish to
back him into a corner.
I see an image of a penguin. He is wearing a bandana around his
forehead and cammie's for clothes. He is armed with an impressive
array of things which carve and cut and things which go bang and
boom and make holes in other things. He is glariing over the top of
a foxhole filled with even more such tools screaming, "You'll have that
kernel debugger in my main Linux build over my cold dead body!"
Now, who makes the cartoon for that one? (And if the penguin had
a superficial resemblance to Linus it'd be DELIGHTFUL!)
{^_-}Joanne "A crazed maniac herself" Dow, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: GCC proposal for "@" asm constraint
On Tue, 19 Sep 2000, Andrea Arcangeli wrote: > > I think we can remove all the __dummy stuff and put the "memory" in such asm > statements. > > Comments? Have you looked at the code it generates? Quite sad, really. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Cannot boot with 2.4.0-test8&9-pre1 (even with gcc 2.7.3)
linux:~ # gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs gcc version 2.7.2.3 But no luck :( still hangs on "Booting Linux...". I've rpmmed -e gcc 2.95 from a Suse 6.4 and installed the gcc 2.7.3 from suse 6.3 It compiles fine, so I think there's another problem :) The .config is the same of the previous mail. Yuri -- "I bambini nascono per essere felici" Jose' Marti' -- Vuoi sempre essere informato su quello che faccio? Iscriviti nella lista degli Amici di Yuri: http://www.alfa.it/mailman/listinfo/amici-yuri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GCC proposal for "@" asm constraint
On Fri, Sep 08, 2000 at 01:41:05PM +0200, Jamie Lokier wrote: > Casting via __dummy is there so that the "m" (or "=m") memory constraint > will make that operand refer to the actual object in memory, and not a > copy (in a different area of memory). Are you really sure gcc could pass a copy even when I specify "memory" in the clobber list? My point is that "memory" could also mean that the address where gcc is taking the _copy_ could be clobbered by the asm itself as side effect and so gcc shouldn't allowed to assume anything and it should first copy the result value of the previous actions to its real final location before starting up any asm that clobbers "memory". I think the "memory" clobber should be enough to ensure that the address used with the .*m constraints refers to the real backend of the memory passed as parameter to the inline asm. I think we can remove all the __dummy stuff and put the "memory" in such asm statements. Comments? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Torben Mathiasen wrote: > It just hit me when I touched the send button (yeah right!). I'm basicly > compiling the same kernel right now. > Glad we got that in place, otherwise it would have been a long wasted night 8). > And just to follow up on my own mail, this patch works great. This has to be one of the cleanest module conversions I've seen in a while. Although it _will_ require a minor change to all of the scsi drivers, the scsi_module.c implementation helps a lot. At first I was sceptical about the scsi subsytem structure, but it turns out this _is_ what made it possible to do it cleanly, so kudos to Eric. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, 18 Sep 2000, Mr. James W. Laferriere wrote: > Oh God , I hope this doesn't mean what I think it might ? > Please tell me I am stil going to be able to 'Statically' compile > in the drivers of my choosing ? Tia , JimL This discussion is about using one initialization scheme for compiled-in and modules (the one currently used by modules), not about modules-only. c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, 18 Sep 2000, Torben Mathiasen wrote: > On Mon, Sep 18 2000, Linus Torvalds wrote: > > And think about it - if this part didn't work, then loadable SCSI modules > > would never have worked. And every single distribution I know of basically > > depends on SCSI drivers being loadable modules, because there are just too > > effing many of them ;) Oh God , I hope this doesn't mean what I think it might ? Please tell me I am stil going to be able to 'Statically' compile in the drivers of my choosing ? Tia , JimL ...snip... ++ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ufs fs at 2.2.x and 2.4.x
On Mon, 18 Sep 2000, Elmer Joandi wrote: > 1. First - it mounted a ufs but showed nothing long time to find the > 44bsd senseless > option. Sigh... Would you prefer six-seven fs types? You see, 4.4 UFS != Slowlaris UFS. And no, FreeBSD implementation is not happy with it either. > 2. ok, linux up, samba and MS Windows Nx100MB profiles copying by few > users. > After a while - MS tells me : media is read-only what a hell. > going to command line - the partition IS now readonly Internal error in driver => remount read-only (alternatives: warn and keep going; just panic). How about syslog? > 3. -o remount,rw : disk full (not really) ... well, doh - basically you've been in panic() situation and you wonder that part of kernel that was responsible is for fsckup is, well, fscked up? > It would be nice, if for 2.4 there would be mandatory printk for expermiental printk is a overkill, but config _does_ keep r/w UFS under "exeprimental" (2.4 at least) > and non-production modules. > So after a year someone would not try to use that stuff on production system. Well, the better way is to fix the bloody thing... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The INN/mmap bug
Alexander Viro wrote: > > On Mon, 18 Sep 2000, Andreas Dilger wrote: > > > Alexander writes: > > > * uptodate pages should never become non-uptodate. > > > uptodate .. pages ... never have data _older_ than on disk > > > > This may actually be a problem in the future... what about shared access > > block devices like FCAL or a distributed filesystem? It has to be > > possible for pages to become non-uptodate in a sane way. > > So what the heck do you do when something modifies mmaped page when you > get the change of on-disk one? Say it, writer is notified that write had > been completed, sends packet to you and you flip a bit on a page that > happens to be mmaped on the place where write had happened. > > Write-through-pagecache is OK, but write straight to disk bypassing the > cache? Welcome to the fun with aliases... Yes, I think that's one rule we can write down right now: to update a block on disk you have to go through the buffer. Not going through the buffer is about the same as accessing a semaphore-protected resource without bothering with the semaphore. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ufs fs at 2.2.x and 2.4.x
Alexander Viro wrote: > Looks like I'm taking care of the UFS for a while. Yes, 2.4 is currently > broken. 2.2.16, migrated FreeBSD to Linux on production system this weekend. Dreamed that I just leave ufs there without copying the stuff. 1. First - it mounted a ufs but showed nothing long time to find the 44bsd senseless option. 2. ok, linux up, samba and MS Windows Nx100MB profiles copying by few users. After a while - MS tells me : media is read-only what a hell. going to command line - the partition IS now readonly 3. -o remount,rw : disk full (not really) It would be nice, if for 2.4 there would be mandatory printk for expermiental and non-production modules. So after a year someone would not try to use that stuff on production system. elmer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: An elevator algorithm (patch)
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> > The only disadvantage I can see is that the new patch doesn't handle
> > consecutive insertions in O(1) time, but then again, the pre-latency
>
> We can still do that by trivially fixing a bit your code. You should first
> check if the new inserted request is over the last in the current queue before
> entering the tmp1/tmp2 logic.
Yes this can be done, but it will affect where requests are inserted.
Suppose the queue currently contains:
100 200 300 400 10 20 30
If request 150 is to be inserted, then with my previous patch it will
be inserted between 100 and 200, but with the proposed change it will
instead be inserted at the end. This is good for latency because there
will be less reordering, but potentially harmfull for streaming
performance because the total disk head traveling distance increases.
Anyway, I tested a new patch with your suggestion, and indeed this
change doesn't seem to cause too many extra seeks. I set the r/w
latencies to 1000/5000, and the iozone and Bonnie test produced almost
the same values as before.
I also noted that I could (almost) play an mp3 file with a 48Kb
buffer during "cp /dev/zero tmpfile". There is one rather large
skip a few seconds after the copy starts, but after that there are
only small occasional skips. I also ran iozone while playing the mp3,
and there were no major sound skips, and iozone only ran 7% slower
than without mpg123 running.
Thanks again for you comments. Here is the new patch:
--- linux-2.4.0-test8/drivers/block/elevator.c.orig Sun Sep 17 00:05:03 2000
+++ linux-2.4.0-test8/drivers/block/elevator.c Mon Sep 18 22:40:53 2000
@@ -34,20 +34,57 @@
struct list_head *real_head,
struct list_head *head, int orig_latency)
{
- struct list_head *entry = real_head;
- struct request *tmp;
+ struct list_head *last = real_head->prev;
+ struct list_head *insert_after = last;
+ struct list_head *entry;
+ struct request *tmp1, *tmp2;
+ int do_insert;
req->elevator_sequence = orig_latency;
- while ((entry = entry->prev) != head) {
- tmp = blkdev_entry_to_request(entry);
- if (IN_ORDER(tmp, req))
+ if (last == head)
+ goto out;
+
+ entry = last;
+ tmp1 = blkdev_entry_to_request(entry);
+ if (IN_ORDER(tmp1, req))
+ goto out;
+ do {
+ tmp2 = tmp1;
+ entry = entry->prev;
+ tmp1 = blkdev_entry_to_request(entry);
+ if (!tmp2->elevator_sequence)
break;
- if (!tmp->elevator_sequence)
+ do_insert = 0;
+ if (entry == real_head) {
+ /*
+* Since we don't know were the disk head is
+* currently located, we can not really know
+* if the request should be inserted here. The
+* best bet is probably not to insert the
+* request here, because otherwise the
+* elevator would be unfair to sectors at the
+* end of the disk.
+*/
+ } else if (IN_ORDER(tmp1, tmp2)) {
+ if (IN_ORDER(tmp1, req) && IN_ORDER(req, tmp2))
+ do_insert = 1;
+ } else {
+ if (IN_ORDER(tmp1, req) || IN_ORDER(req, tmp2))
+ do_insert = 1;
+ }
+ if (do_insert) {
+ insert_after = entry;
+ do {
+ entry = entry->next;
+ tmp1 = blkdev_entry_to_request(entry);
+ tmp1->elevator_sequence--;
+ } while (entry != last);
break;
- tmp->elevator_sequence--;
- }
- list_add(>queue, entry);
+ }
+ } while (entry != head);
+out:
+ list_add(>queue, insert_after);
}
int elevator_linus_merge(request_queue_t *q, struct request **req,
--
Peter Österlund Email: [EMAIL PROTECTED]
Sköndalsvägen 35[EMAIL PROTECTED]
S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919
Sweden Phone: +46 8 942647
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, 18 Sep 2000, Torben Mathiasen wrote: > > What about the case when scsi is compiled into the kernel with one or > more host adapters? We have to initialize those right away. Actually, we don't. It's really equivalent to just having two or more modules. >Please > explain what you did with all the host initialization (spin-up, etc.) > in scsi_dev_init. It's all gone. Look at the module paths. They all do the same thing, except there it's nicely per-controller. It's just hidden in scsi_module.c: the scsi_register_module() thing will do it all for you. So when yu remove the #ifdef MODULE logic from the controller driver code, the spin-up and scanning still gets done - without any global help from scsi_dev_init() at all. And think about it - if this part didn't work, then loadable SCSI modules would never have worked. And every single distribution I know of basically depends on SCSI drivers being loadable modules, because there are just too effing many of them ;) I'll make a test9-pre3 so that you can synch up, but I need to integrate all the 2.2.x stuff that Alan sent me yesterday first ;) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with cscope and 2.4-test8 source file
Mark Salisbury writes:
> the source file linux/fs/hpfs/super.c
>
> the problem is the extremely long printk() string starting on line 280 in the
> function static inline void hpfs_help(void){}
>
> simply breaking up this printk up into several smaller printk's solves the
> problem.
Looking at this printk makes me think that this is better off in the man
page than in the kernel... Maybe you should just submit a patch which
removes the whole hpfs_help() function, and updates the mount(8) man page...
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, 18 Sep 2000, Eric Youngdale wrote: > > What is the primary objective here - getting rid of #ifdef MODULE, or is > it removing redundant code for the two paths? Or both? Both. As you probably saw, it really started out from fixing this silly bug that was introduced by mistake some time ago - which was due to both the module init and the "built-in" init code kicking in. The fact that it wasn't clear which happened where is really for me the driving force here - I'd like to avoid the same bug cropping up in half a year when somebody cleans up some low-level driver init. Oh, and getting rid of the init list in hosts.c is a nice bonus. It just goes away automatically if you look at the module init path instead ;) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ioremap & Co i386 -> sparc64
Date:Mon, 18 Sep 2000 16:11:37 +0200 From: Florian Lohoff <[EMAIL PROTECTED]> This is all Kernel 2.2.17 ioremap is buggy on sparc64 in 2.2.x, but fixing it would break a lot of drivers. See drivers/net/sk98lin/skge.c, grep for __sparc__, for how to deal with this problem. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at ll_rw_blk.c:711!
[NB. following may not be relevant as seen on box with known upper 32MB of 128MB DIMM faulty and not in use via mem=96MB] Oops obtained when exiting Staroffice 5.2. Relevant procs left in unkillable state :- F S UIDPID PPID CLS PRI ADDR SZ WCHAN STIME TTY TIME CMD 144 Z root 4 1 - 30 - 0 do_exi 19:38 ?00:00:00 [kupdate ] 000 D mike 3925 1 - 30 - 25091 wait_o 21:28 tty3 00:00:58 /usr/local/office52/program/soffice.bin 444 Z mike 3943 3925 - 30 - 0 do_exi 21:28 tty3 00:00:00 [soffice.bin ] gcc version 2.95.2 19991024 (release) ksymoops 2.3.4 on i686 2.4.0-test8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /boot/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Sep 18 21:42:39 duncodin kernel: invalid operand: Sep 18 21:42:39 duncodin kernel: CPU:0 Sep 18 21:42:39 duncodin kernel: EIP:0010:[__make_request+159/1452] Sep 18 21:42:39 duncodin kernel: EFLAGS: 00010286 Sep 18 21:42:39 duncodin kernel: eax: 001f ebx: c05f6540 ecx: edx: Sep 18 21:42:39 duncodin kernel: esi: c05f6540 edi: c11cfd78 ebp: 0001 esp: c11c9f34 Sep 18 21:42:39 duncodin kernel: ds: 0018 es: 0018 ss: 0018 Sep 18 21:42:39 duncodin kernel: Process kupdate (pid: 4, stackpage=c11c9000) Sep 18 21:42:39 duncodin kernel: Stack: c01d9265 c01d9502 02c7 c05f6540 0001 0020 001e8480 Sep 18 21:42:39 duncodin kernel:c11cfd90 c11cfd88 0002 c01517e7 00fe Sep 18 21:42:39 duncodin kernel:c01523cc c11cfd78 0001 c05f6540 c05f6540 0001 c11c9fd0 Sep 18 21:42:40 duncodin kernel: Call Trace: [tvecs+42909/49816] [tvecs+43578/49816] [blk_get_queue+55/72] [generic_make_request+272/284] [ll_rw_block+347/460] [flush_dirty_buffers+130/180] [tvecs+13678/49816] Sep 18 21:42:40 duncodin kernel: Code: 0f 0b 83 c4 0c 66 8b 4e 14 31 c0 8a 46 15 8b 14 85 c0 8c 26 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: 66 8b 4e 14 mov0x14(%esi),%cx Code; 0009 Before first symbol 9: 31 c0 xor%eax,%eax Code; 000b Before first symbol b: 8a 46 15 mov0x15(%esi),%al Code; 000e Before first symbol e: 8b 14 85 c0 8c 26 00 mov0x268cc0(,%eax,4),%edx 1 warning issued. Results may not be reliable. -- Mike CivilHome : [EMAIL PROTECTED] Broadmayne, Dorset, UKWork : [EMAIL PROTECTED] +44 (0)1305 853644 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with cscope and 2.4-test8 source file
* Mark Salisbury <[EMAIL PROTECTED]> [000918 07:32]:
> I use cscope version 13.7 (on solaris 2.6)
There is an open sourced version of cscope released under a BSD license at
http://cscope.sourceforge.net/ ...
> the source file linux/fs/hpfs/super.c
>
> from kernel version 2.4-test8 causes cscope to core dump during the database
> generation phase.
>
> the problem is the extremely long printk() string starting on line 280 in the
> function static inline void hpfs_help(void){}
I just tried it with the open sourced cscope, and it works on that line
just fine. It (the cscope) still needs a little work in some areas, but
it seems fairly decent to me.
> simply breaking up this printk up into several smaller printk's solves the
> problem.
You can submit a kernel patch if you think it'll get accepted... it's
a trivial enough hack... but no guarantees.
> I guess this is only a problem if you use cscope, but I thought you all would
> like to know..
Try using the open source cscope... this isn't a bug there, and if you
do run into any, you can always email me (or submit to cscope's
sourceforge site) patches to it.
Good luck. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Eric Youngdale wrote: > What is the primary objective here - getting rid of #ifdef MODULE, or is > it removing redundant code for the two paths? Or both? > > I am just trying to get a handle on what is driving this. Well the code clean-up came as a pleasent side effect of removing ifdef MODULE. But now it seems Linus has done it without this. I think this is okay, as it gives us a _nice_ working scsi layer back, on which we can build our cleanup. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Linus Torvalds wrote: > Actually, hold off a moment. > > It turns out that the MODULE case does all the right things, for all the > obvious reasons. I'm running a kernel that has the #ifdef MODULE stuff > just removed, and it seems to be a rather easy approach. It really only > required making a few things static (the init routines would clash > otherwise), and removing a lot of #ifdef MODULE. > > (And removing some code that was enabled only for non-modules). > > It looks very straightforward. > What about the case when scsi is compiled into the kernel with one or more host adapters? We have to initialize those right away. Please explain what you did with all the host initialization (spin-up, etc.) in scsi_dev_init. You could also just send me a diff, and I'll take a look. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTIC S reserved bits
On Mon, Sep 18, 2000 at 11:31:09AM -0500, [EMAIL PROTECTED] wrote: > This patch prevents scsi_ioctl_send_command() from overwriting the SEND > DIAGNOSTICS (Drive Self Test) reserved bits in cmd[1], as found in SCSI-3. > Code provided by Michael Landrus of Dell. > > Comments are requested. If there are no objections, Linus and Alan please > apply. > Below are patches to kernels 2.2.18-pre8 and 2.4.0-test9-pre1. > -cmd[1] = ( cmd[1] & 0x1f ) | (dev->lun << 5); > +if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND DIAGNOSTICS > reserved bits > + cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5); I am a bit surprised: why only SEND DIAGNOSTICS? If I am not mistaken SCSI-1 used this 3-bit LUN field in all commands, and SCSI-2 still does, but the standard says: 7.2.2 Logical unit number ... NOTICE: The logical unit number field is included in the command descriptor block for compatibility with some SCSI-1 devices. This field may be reclaimed in SCSI-3. and SCSI-3 calls these bits "reserved", for all commands, also for SEND DIAGNOSTICS. So: (i) I don't see what is special with SEND DIAGNOSTICS. Maybe for SCSI-3 the lun should never be inserted. (ii) On the other hand, for SCSI-1 the lun should always be inserted. Once these bits really get used again (are there already examples of a new use?) I suppose we should introduce a new SCSI3_IOCTL_SEND_COMMAND instead of changing SCSI_IOCTL_SEND_COMMAND. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status/TODO Page
>> Network block device seems broken by block device changes (In sec. 11. To Check) FWIW... I have a set of Pentium Pro machines connected by 100 MBit ethernet. I've been testing the bonnie I/O benchmark over nbd. Using 2.4 kernels up to test6, bonnie would hang when using backing files 100MB and larger. Using the test8 kernel, bonnie seems to work fine. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
What is the primary objective here - getting rid of #ifdef MODULE, or is it removing redundant code for the two paths? Or both? I am just trying to get a handle on what is driving this. -Eric - Original Message - From: "Linus Torvalds" <[EMAIL PROTECTED]> To: "Torben Mathiasen" <[EMAIL PROTECTED]> Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, September 18, 2000 4:43 PM Subject: Re: [PATCH] Re: SCSI scanning > > > On Mon, 18 Sep 2000, Torben Mathiasen wrote: > > > > Thanks a lot. I've started to do the basics, like getting all subsystems to work > > with the module_init/exit stuff. This of course leds to some rewriteting/restructuring > > of the scsi layer. Nothing major though. > > Actually, hold off a moment. > > It turns out that the MODULE case does all the right things, for all the > obvious reasons. I'm running a kernel that has the #ifdef MODULE stuff > just removed, and it seems to be a rather easy approach. It really only > required making a few things static (the init routines would clash > otherwise), and removing a lot of #ifdef MODULE. > > (And removing some code that was enabled only for non-modules). > > It looks very straightforward. > > Linus > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Sun, Sep 17, 2000 at 08:40:33PM -0700, Larry McVoy wrote: > On Sun, Sep 17, 2000 at 02:33:40PM -0700, Marty Fouts wrote: > I'm sort of in the middle. I know BitKeeper very well, and it's actually > a larger wad of code than the kernel if you toss out the device drivers. > About the only thing I ever want a debugger for is a stacktrace back. If > you give me that, I usually don't need anything else; and in general, you There are debuggers that do other stuff too? I gotta read the adb manual some day. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech USB Wingman Force Joystick...
On Mon, Sep 18, 2000 at 04:39:36PM -0400, Johannes Erdfelt wrote: > Are you getting any oops'? I ran into a problem where with some devices, > it would oops on open. Nah... It turned out to be something REALLY obvious. I was missing the joydev module. Someone else already pointed it out to me. The module isn't sitting in the /lib/modules/.../kernel/drivers/char/joystick directory with the joystick drivers, it's over in the .../input/ directory where I missed it. :-> > JE Thanks! Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
lest people start shouting at me...
The philosphy behind this patch is:
There are two ways to turn a "guess" into a "fix":
a) to understand why it works
or
b) to make sure it fixes the problem for everyone on the planet and
doesn't break anything...
This time b) seemed easier :)
Regards,
Tigran
On Mon, 18 Sep 2000, Tigran Aivazian wrote:
> On Mon, 18 Sep 2000, Derek Wildstar wrote:
>
> > On 18 Sep 2000, Alex Romosan wrote:
> >
> > I get the same thing with a Xircon realport 10/100/modem card. Works
> > great in test9-pre1 and test8.
> >
> > -dwild
> >
>
> did you try this patch?
>
> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
> +++ work/drivers/pci/pci.cMon Sep 18 13:12:20 2000
> @@ -714,7 +714,7 @@
>* We need to blast all three values with a single write.
>*/
> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
> - if (!is_cardbus) {
> + if (is_cardbus) {
> /* Now we can scan all subordinate buses... */
> max = pci_do_scan_bus(child);
> } else {
>
>
> Regards,
> Tigran
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, 18 Sep 2000, Torben Mathiasen wrote: > > Thanks a lot. I've started to do the basics, like getting all subsystems to work > with the module_init/exit stuff. This of course leds to some >rewriteting/restructuring > of the scsi layer. Nothing major though. Actually, hold off a moment. It turns out that the MODULE case does all the right things, for all the obvious reasons. I'm running a kernel that has the #ifdef MODULE stuff just removed, and it seems to be a rather easy approach. It really only required making a few things static (the init routines would clash otherwise), and removing a lot of #ifdef MODULE. (And removing some code that was enabled only for non-modules). It looks very straightforward. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: uid
Yes, 2.4 has 32bit uid/gid support. No, 2.2 doesn't, but there is a patch from http://www.engin.umich.edu/caen/systems/Linux. You'll probably have to do some work to fit the patches into the latest 2.2 kernels though, as they're no longer being maintained in leu of 2.4. In addition to running a 2.4 kernel, you'll also need to hack up glibc to recognize the new syscalls the kernel provides for 32bit uid/gid support. It's claimed that glibc 2.2 will have this, but you'll have to wait until it is released. I hacked 2.1.3 with satisfactory results. If you use quotacheck from quota-x.x.tar.gz and you enable the direct ext2 support stuff, you'll have to hack it up to properly reassemble uids/gids. The same applies to debugfs from e2progs-x.y.tar.gz, and any other utility which accesses the ext2 filesystem directly - as opposed to using standard filesystem routines. If you're interested in process accounting, be aware that the accounting file format is still mired with 16bit uids/gids. Fortunately this one is trivial to fix, as long as you don't mind abandoning your old accounting files. I think the 2.2->2.4 transition would be a great time to make the switch, officially. Be aware that other utilities that deal with uids/gids may break. Tar is one of them. The tar format specifies 16bit uids/gids. Patching tar may not be wise if you're going to share the tarballs with other systems. ELF core files also suffers this problem. I'm sure I left out others. --- Tracy Stenvik University Computing Services 354843. University of Washington email: [EMAIL PROTECTED] voice: (206) 685-3344 On Mon, 18 Sep 2000, octave klaba wrote: > Hi, > I read that the hard limit of the number of the users on > 2.2.x is 65000 and on 2.4.x it will be more. > I just wonder if it is true and if we have to wait for 2.4.x > to have more that 65000 users with kernel's quota management ? > > Thanks > Octave > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
On Mon, 18 Sep 2000, Derek Wildstar wrote:
> On 18 Sep 2000, Alex Romosan wrote:
>
> I get the same thing with a Xircon realport 10/100/modem card. Works
> great in test9-pre1 and test8.
>
> -dwild
>
did you try this patch?
--- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
+++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000
@@ -714,7 +714,7 @@
* We need to blast all three values with a single write.
*/
pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
- if (!is_cardbus) {
+ if (is_cardbus) {
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech USB Wingman Force Joystick...
On Mon, Sep 18, 2000, Michael H. Warfield <[EMAIL PROTECTED]> wrote: > Hello all... > > No joy with this joystick and I'm not sure what I'm doing wrong. > > I just received a Logitech USB Wingman Force Joystick. I have > the iforce module compiled and loaded and the it recognizes the USB > joystick. > > /var/log/message: > > Sep 18 15:09:32 alcove kernel: usb.c: USB new device connect, assigned device number >7 > Sep 18 15:09:32 alcove kernel: input3: I-Force joystick/wheel on usb1:7.0 > Sep 18 15:09:45 alcove kernel: usb.c: USB disconnect on device 7 > Sep 18 15:10:28 alcove kernel: usb.c: USB new device connect, assigned device number >7 > Sep 18 15:10:28 alcove kernel: input3: I-Force joystick/wheel on usb1:7.0 > > /proc/bus/usb/devices: > > T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 7 Spd=12 MxCh= 0 > D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=046d ProdID=c281 Rev= 1.00 > S: Manufacturer=Logitech > S: Product=Wingman Force > C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=iforce > E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl= 8ms > E: Ad=01(O) Atr=03(Int.) MxPS= 32 Ivl= 4ms > > Trouble is "jstest /dev/js0" says no such device. > > My RedHat 6.2 system initially had the following js devices: > > c 15 0 js0 > c 15 1 js1 > c 15 2 js2 > c 15 3 js3 > > I was also getting these errors in /var/log/messages: > > Sep 18 14:51:52 alcove modprobe: modprobe: Can't locate module char-major-15 > > The file linux/Documentation/joystick.txt says to use 13, 0-3, > so I changed it to this: > > c 13 0 js0 > c 13 1 js1 > c 13 2 js2 > c 13 3 js3 > > Still no go, but at least I'm not getting the modprobe errors now. > My USB mouse on c 13, 63 is working like a charm. > > This is with kernel 2.4.0-test8 > > So, I assume that I'm still missing something obvious here. What? > > Any thoughts anyone? Are you getting any oops'? I ran into a problem where with some devices, it would oops on open. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [linux-usb-devel] Logitech USB Wingman Force Joystick...
> Hello all... > > No joy with this joystick and I'm not sure what I'm doing wrong. > > I just received a Logitech USB Wingman Force Joystick. I have > the iforce module compiled and loaded and the it recognizes the USB > joystick. > ... > Trouble is "jstest /dev/js0" says no such device. > ... > Still no go, but at least I'm not getting the modprobe > errors now. > My USB mouse on c 13, 63 is working like a charm. > > This is with kernel 2.4.0-test8 > > So, I assume that I'm still missing something obvious > here. What? > > Any thoughts anyone? > > Mike Hi Mike, Thoughts are cheap. Well, I guess (these) devices are too, but I don't have one (yet). No, you're not doing anything wrong. That'd be too easy to fix. We've known about this problem for several weeks now. AFAIK it first showed up at the USB PlugFest in early August (2.4.0-test4 or -test5). I told Vojtech about it but we haven't tracked it down yet. I have a USB gamepad on order. It exhibited the same problem at the PlugFest, so I hope to be able to track it down soon. I'll log this in the Status/TODO list. Thanks, ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
On Mon, Sep 18 2000, Eric Youngdale wrote: > Historical. SCSI was made modular very early on when the modules > technology was pretty primative. As time has gone on, the two > initialization paths have converged, and now they are essentially redundant. > Thats understandable. > The one thing that is different in the module/non-module case is for the > case of SCSI compiled into the kernel, you need to look at the list of > compiled-in host adapters. Unless of course you are cleaning that up as > well. I haven't seen the threads that got this work started, and it is only > in reading this morning's messages that I see the rationale for all these > changes in the first place. There are a couple of ways of addressing this, > some better than others, and some are more work than others. I can give you > assistance and ideas if you want. > Thanks a lot. I've started to do the basics, like getting all subsystems to work with the module_init/exit stuff. This of course leds to some rewriteting/restructuring of the scsi layer. Nothing major though. It seems I can't avoid some of the ifdef MODULE stuff in the initialization routines in scsi.c, exactly because of the issues you mention (init builtin host adapters when scsi is also builtin) Let me know if you have any hints as what should be looked at while we are at it. I'll send you a patch soon for your comments. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2-fs error and geometry walk ... ???
On Mon, Sep 18, 2000 at 04:50:55AM -0700, Andre Hedrick wrote: [ext2 errors and fdisk complaints on 2.4.0test8, patched?] Andre, (i) Geometry does not play any role in the functioning of Linux - it is only a matter to LILO and fdisk. So, if you meet a strange geometry, then that is surprising, but cannot cause other errors. Of course it is possible that the same bug causes both ext2 errors and a strange geometry report. (ii) You find exactly the same fdisk oddities, and exactly the same ext2 errors on each of four disks. This sounds more like a programming than like a hardware error, although of course I do not know what kind of hardware setup you use. So, perhaps you should explain what you do. If this is an unpatched vanilla 2.4.0test8 then I am surprised. But if it is a patched version I would prefer to blame the patch. > ext2_readdir: bad entry in directory #2: rec_len % 4 != 0 - offset=0, inode=2, >rec_len=14, name_len=1 > > This did not happen in the past. Do you have a reproducible situation, with a kernel that functions and a kernel that fails? Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB input drivers moved and updated for 2.2.18-pre9
Hi, This patch against 2.2.18-pre9 moves the USB input drivers into the same directory structure that they are in for 2.4.x, and it also updates the drivers to their latest versions. This patch was done by Franz Sirl (thanks Franz for doing this!) I've included it in two forms here: usb-input-2.2.18-pre9.diff.gz : a single patch that does everything needed. usb-input-2.2.18-pre9-multiple.tar.gz : A three patch sequence that accomplishes the same thing, but in clean steps (first move the drivers, then patch them, and then patch them again.) Thanks, greg k-h -- greg@(kroah|wirex).com usb-input-2.2.18-pre9.diff.gz usb-input-2.2.18-pre9-multiple.tar.gz
Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work
On 18 Sep 2000, Alex Romosan wrote: I get the same thing with a Xircon realport 10/100/modem card. Works great in test9-pre1 and test8. -dwild > i have the same problem with the same setup. from the logs, it looks > like this is due to a PCI resource allocation conflict: > > Sep 17 15:56:33 prospero cardmgr[6838]: initializing socket 1 > Sep 17 15:56:33 prospero cardmgr[6838]: socket 1: 3Com 3CCFE575B/3CXFE575B Fast >EtherLink XL > Sep 17 15:56:33 prospero kernel: cs: cb_alloc(bus 5): vendor 0x10b7, device 0x5157 > Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 0 for PCI device >10b7:5157 > Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 1 for PCI device >10b7:5157 > Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 2 for PCI device >10b7:5157 > Sep 17 15:56:33 prospero kernel: PCI: Failed to allocate resource 6 for PCI device >10b7:5157 > Sep 17 15:56:33 prospero kernel: PCI: Device 05:00.0 not available because of >resource collisions > Sep 17 15:56:33 prospero kernel: eth0: 3Com PCI 3CCFE575BT Cyclone CardBus at 0x0, ><3>PCI: Device 05:00.0 not available because of resource collisions > Sep 17 15:56:33 prospero kernel: 3c59x: vortex_probe1 fails. Returns -5 > > after i suspended the laptop and started again i got this: > > Sep 18 11:36:47 prospero cardmgr[6838]: shutting down socket 1 > Sep 18 11:36:47 prospero cardmgr[6838]: executing: 'modprobe -r 3c575_cb' > Sep 18 11:36:49 prospero kernel: cs: cb_alloc(bus 5): vendor 0x, device 0x > Sep 18 11:36:49 prospero kernel: PCI: device 05:00.0 has unknown header type 7f, >ignoring. > Sep 18 11:36:49 prospero kernel: PCI: No IRQ known for interrupt pin ? of device >05:00.0. Please try using pci=biosirq. > Sep 18 11:36:52 prospero kernel: cs: cb_free(bus 5) > Sep 18 11:36:52 prospero cardmgr[6838]: executing: 'modprobe -r cb_enabler' > Sep 18 11:36:59 prospero cardmgr[6838]: initializing socket 1 > Sep 18 11:36:59 prospero cardmgr[6838]: socket 1: Anonymous Memory > Sep 18 11:36:59 prospero cardmgr[6838]: executing: 'modprobe memory_cs' > Sep 18 11:36:59 prospero cardmgr[6838]: + modprobe: Can't locate module memory_cs > Sep 18 11:36:59 prospero cardmgr[6838]: modprobe exited with status 255 > Sep 18 11:36:59 prospero cardmgr[6838]: module >/lib/modules/2.4.0-test9/pcmcia/memory_cs.o not available > > it looks like the pcmcia daemon is really confused (pci=biosirq didn't > make any difference in the past). test9-pre1 worked fine (well, i > still had to do 'ifconfig eth0 up' by hand). > > --alex-- > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote: > > Ok. I think we're getting to the point where there are no major known > bugs. That means that as of the final 2.4.0-test9 I will no longer accept > any patches that don't have a critical problem (as defined by Teds list) > associated with them. > > So when you send me a patch, either bug Ted to mark the issue as > "critical" first, or pay me money. It's that easy. I have been doing some testing just to see how well the new VM stuff works. I think I have found a bug in both test9-pre1 and test9-pre2. If I boot my machine (400MHz AMD-K6 3D+, 128M Ram, IDE disks, 512M swap) with mem=48M added to the LILO command line and try and build mozilla, the machine will eventually die. I can still ping it, but I cant connect to the http or sshd servers, I cant get anything to show up on the monitor, and the disk does not make any noise. After I reboot (and fsck :-<), the logs do not contain any information about what happened. If I run test8 instead of one of the test9 kernels then everything seems to work. If I dont limit the memory to 48M then the test9 kernels work fine. I am attaching the script that I use to build mozilla just in case anyone wants to try and reproduce this. Thanks, Jim #!/bin/sh CMD="/home/jlnance/src/19980429/mozilla/configure --disable-tests --enable-nspr-autoconf" UNAMER=`uname -r` if [ ! -d $UNAMER ]; then mkdir $UNAMER; fi for x in 1 2 3 4; do TFILE=$UNAMER/time.$x if [ -f $TFILE ]; then echo $TFILE exists. Skipping continue fi echo -n "starting" date echo -n "erasing " rm -rf nbt/* date echo -n "configuring " (cd nbt; exec $CMD) > log 2>&1 date echo -n "building" csh -c "time sh -c \"exec make -s -C nbt >>log 2>&1\"" >$TFILE 2>&1 date echo done
[patch] Fixes for VIA driver
Hi!
While developing the next versions, I found two 'obvious bugs' in the
2.1 version. They are not very harmful. The attached patch fixes them.
--
Vojtech Pavlik
SuSE Labs
--- linux/drivers/ide/via82cxxx.c.old Mon Sep 18 22:10:10 2000
+++ linux/drivers/ide/via82cxxx.c Mon Sep 18 22:13:29 2000
@@ -1,5 +1,5 @@
/*
- * $Id: via82cxxx.c,v 2.1 2000/08/29 01:34:60 vojtech Exp $
+ * $Id: via82cxxx.c,v 2.1a 2000/09/18 22:10:60 vojtech Exp $
*
* Copyright (c) 2000 Vojtech Pavlik
*
@@ -140,8 +140,8 @@
{ XFER_MW_DMA_1, "MDMA1", 45, 80, 50, 150, 0 },
{ XFER_MW_DMA_0, "MDMA0", 60, 215, 215, 480, 0 },
- { XFER_SW_DMA_0, "SDMA0", 60, 120, 120, 240, 0 },
- { XFER_SW_DMA_0, "SDMA0", 90, 240, 240, 480, 0 },
+ { XFER_SW_DMA_2, "SDMA2", 60, 120, 120, 240, 0 },
+ { XFER_SW_DMA_1, "SDMA1", 90, 240, 240, 480, 0 },
{ XFER_SW_DMA_0, "SDMA0",120, 480, 480, 960, 0 },
{ XFER_PIO_5, "PIO5", 20, 50, 30, 100, 0 },
@@ -214,7 +214,7 @@
via_print("BM IDE Status Register Read Retry: %s", (t & 8) ? "on" : "off" );
pci_read_config_byte(dev, VIA_MISC_2, );
- sprintf(p, "Interrupt Steering Swap: %s", (t & 64) ? "on" : "off");
+ via_print("Interrupt Steering Swap:%s", (t & 64) ? "on" : "off");
pci_read_config_byte(dev, VIA_MISC_3, );
via_print("Max DRDY Pulse Width: %s%s", via_control3[(t &
0x03)], (t & 0x03) ? "PCI clocks" : "");
Re: New topic (PowerPC Linux PCI HELL)
On Mon, 18 Sep 2000, Alan Cox wrote:
> > All I wanted was a function that allows the driver to decide that which
> > needs to be enabled.
> >
> > pci_enable_device(struct pci_dev *dev, byte enable_mask)
> >
> > This would allow drivers to enable that which it needs and not weird out
> > the hardware that does not like all of this extra fluff.
>
> Sounds not too daft
>
> static inline int pci_enable_device(struct pci_device *dev)
> {
> return pci_enable_device_features(USE_IO|USE_MM);
> }
Should be worded as "Respond to IO", "Respond to Memory" transactions,
given the explicit PCI context.
And what about other features ?
I mean:
- Bus Master
- Memory Write and Invalidate
- Parity Error response
Etc ...
Are they considered as misfeatures ? ;-)
> and then just go and turn the existing enable_device into enable_device_Features ?
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: The INN/mmap bug
On Mon, 18 Sep 2000, Alexander Viro wrote:
> >
> > but should instead be
> >
> > static int make_buffer_uptodate(struct page *page, struct buffer_head * bh)
> > {
> > if (Page_Uptodate(page)) {
> ^^^
> > set_bit(BH_Uptodate, >b_state);
> > return;
> > }
> > ll_rw_block(READ, 1, );
> > }
>
> > Forget about your "stage 1" and "stage 2" complications. They shouldn't
> ^^
> > exist.
>
> Erm...
No, but that's just because you _think_ about the problem the wrong way
around.
If you think about it like the above, it's not a "stage" at all. It's just
part of getting the buffer to be up-to-date.
Very logical, very simple, no "fscking mess" at all.
That's my argument. You're trying to make it a problem. It's not. It's
something new with the page cache, yes - the fact that the page cache
drives the logic means that the buffer "uptodate" logic is different, but
if you think about it some, you'll realize that that's actually just a
natural outgrowth of the fact that the buffer cache is slaved to the page
cache these days.
It's not a "stage 2". It's a basic fact of life - we don't care _how_ the
page got to be up-to-date, because for all we know there are other ways to
get it to be up-to-date than your "stage 1".
For example, a recvfile() implementation could mark the page up-to-date by
virtue of getting the information off the network. No "stage 1" or "stage
2" there at all: the make_buffer_uptodate() logic does _not_ mean that we
lost the buffers from "stage 1", it might equally well mean that we got
the page up-to-date through some other means.
Just change how you think about the problem, and suddenly it's not a mess,
it's a design.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
> reproduce the exact kernel configuration of my running 2.2.14 system > and a 2.2.17 kernel. (It would be extremely useful to have a pointer > to a tool which would duplicate the configs rather than going through > the manual process of configuring the kernel build). cp .config new_kernel_dir cd new_kernel_dir make menuconfig make dep; make clean; make bzImage Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: The INN/mmap bug
That's to fs/buffer.c, generic_file_write() part will go
separately (it's a separate bug actually - if copy_from_user() in
generic_file_write() fails we mark page as not-uptodate; if memory
pressure will drop the buffer_heads attempts to read will blow the page
contents away).
Linus, does this look OK with you?
--- buffer.cMon Sep 18 18:56:29 2000
+++ buffer.c.newMon Sep 18 19:11:06 2000
@@ -1495,6 +1495,8 @@
err = get_block(inode, block, bh, 1);
if (err)
goto out;
+ if (Page_Uptodate(page))
+ mark_buffer_uptodate(bh, 1);
if (buffer_new(bh)) {
unmap_underlying_metadata(bh);
if (block_end > to)
@@ -1600,8 +1602,10 @@
continue;
if (!buffer_mapped(bh)) {
- if (iblock < lblock)
- get_block(inode, iblock, bh, 0);
+ if (iblock < lblock) {
+ if (get_block(inode, iblock, bh, 0))
+ continue;
+ }
if (!buffer_mapped(bh)) {
if (!kaddr)
kaddr = kmap(page);
@@ -1789,7 +1793,11 @@
/* Hole? Nothing to do */
if (buffer_uptodate(bh))
goto unlock;
- get_block(inode, iblock, bh, 0);
+ err = get_block(inode, iblock, bh, 0);
+ if (err)
+ goto unlock;
+ if (Page_Uptodate(page))
+ mark_buffer_uptodate(bh, 1);
/* Still unmapped? Nothing to do */
if (!buffer_mapped(bh))
goto unlock;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.0/2.2 Bug: SIGTRAP lost
If a process executes an int3 (breakpoint) instruction while
another process is attaching to it, the SIGTRAP can be lost. This bug
is present in 2.4.0-test8 and 2.2.14.
Below is a program that demonstrates this behavior. It forks a
child that repeatedly executes an int3 and handles the SIGTRAP. The
parent repeatedly attaches and detaches to the child. Eventually the
SIGTRAP generated by the int3 is lost, and the child falls through (to
the fprintf).
Vic Zandy
#include
#include
#include
#include
#include
long int dptrace(enum __ptrace_request req, pid_t pid,
void *addr, void *data)
{
int rv;
rv = ptrace(req, pid, addr, data);
if (0 > rv) {
perror("ptrace");
exit(1);
}
return rv;
}
void do_trace(int pid)
{
while (1) {
dptrace(PTRACE_ATTACH, pid, 0, 0);
waitpid(pid, 0, 0);
dptrace(PTRACE_DETACH, pid, 0, 0);
}
}
void handler(int sig, struct sigcontext uap)
{
uap.eip--;
}
void do_int3()
{
struct sigaction sa;
sa.sa_handler = (void (*)(int)) handler;
sigemptyset(_mask);
sa.sa_flags = 0;
sigaction(SIGTRAP, , NULL);
asm("int3"); /* Should loop here */
fprintf(stderr, "Bug triggered\n");
}
int main(int argc, char *argv[])
{
int pid;
pid = fork();
if (pid)
do_trace(pid);
else
do_int3();
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patchlet] Update help for COMX
On Mon, Sep 18, 2000 at 08:47:55PM +0100, Alan Cox wrote: > > The drivers/net/wan/comx.c #errors if it is compiled in a kernel > > without procfs support. The following patch updates the documentation > > to state this. I have cc'ed the maintainer so he can comment. > > It does really need procfs, but I'd say its better to put them depenancy > in the Config.in if you can do it ? I have proposed this in the past but Arjan van de Ven opinioned that since the config choice for procfs is after the COMX choice (thus nulling your COMX option silently if you deselect procfs) the correct thing would be the documentation patch. I am inclined to agree with him (hence my submitted patch) bit if you and/or Linux feels otherwise I can fix the config.in, no problem. -- Regards, Rasmus([EMAIL PROTECTED]) I've always found profanity to be refuge of the inarticulate motherfucker. --Anonymous - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
Hi! > Ok. I think we're getting to the point where there are no major known > bugs. That means that as of the final 2.4.0-test9 I will no longer accept > any patches that don't have a critical problem (as defined by Teds list) > associated with them. > So when you send me a patch, either bug Ted to mark the issue as > "critical" first, or pay me money. It's that easy. Does PCMCIA work for you? I get reliable (and fatal) oops whenever I plug or unplug PCMCIA card at runtime (at least ne2k and ide cause same oops). This is toshiba satellite 4030cdt. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patchlet] Update help for COMX
> The drivers/net/wan/comx.c #errors if it is compiled in a kernel > without procfs support. The following patch updates the documentation > to state this. I have cc'ed the maintainer so he can comment. It does really need procfs, but I'd say its better to put them depenancy in the Config.in if you can do it ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Hardware performance counter overflow
Hi, I've noticed that there are quite a few hardware performance counter patches (which allow access to things like the Pentium Model Specific Registers for gathering profiling info) floating around, including Rabbit (http://www.scl.ameslab.gov/Projects/Rabbit/), Richard Gooch's patches, and PAPI (very cool and portable, IMHO). But I haven't seen any of these that supports delivering interrupts when counters overflow (the last version of PAPI that I saw provides high-level emulation of this on Linux/x86, but it's not really accurate enough for serious work). Is there any other patch that supports overflows on Linux/x86, or is it work that still needs to be done? Monitoring these overflows is the trick behind large parts of Intel's VTune and SGI's SpeedShop, and I'd love to see a profiler like this come to Linux. Basically, I'm a student and I think it would be an interesting project, but I don't want to re-invent the wheel unnecessarily. Thanks a lot! --JRZ PS Please CC me at [EMAIL PROTECTED] with any replies, if you don't mind. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Logitech USB Wingman Force Joystick...
Hello all... No joy with this joystick and I'm not sure what I'm doing wrong. I just received a Logitech USB Wingman Force Joystick. I have the iforce module compiled and loaded and the it recognizes the USB joystick. /var/log/message: Sep 18 15:09:32 alcove kernel: usb.c: USB new device connect, assigned device number 7 Sep 18 15:09:32 alcove kernel: input3: I-Force joystick/wheel on usb1:7.0 Sep 18 15:09:45 alcove kernel: usb.c: USB disconnect on device 7 Sep 18 15:10:28 alcove kernel: usb.c: USB new device connect, assigned device number 7 Sep 18 15:10:28 alcove kernel: input3: I-Force joystick/wheel on usb1:7.0 /proc/bus/usb/devices: T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 7 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c281 Rev= 1.00 S: Manufacturer=Logitech S: Product=Wingman Force C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=iforce E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl= 8ms E: Ad=01(O) Atr=03(Int.) MxPS= 32 Ivl= 4ms Trouble is "jstest /dev/js0" says no such device. My RedHat 6.2 system initially had the following js devices: c 15 0 js0 c 15 1 js1 c 15 2 js2 c 15 3 js3 I was also getting these errors in /var/log/messages: Sep 18 14:51:52 alcove modprobe: modprobe: Can't locate module char-major-15 The file linux/Documentation/joystick.txt says to use 13, 0-3, so I changed it to this: c 13 0 js0 c 13 1 js1 c 13 2 js2 c 13 3 js3 Still no go, but at least I'm not getting the modprobe errors now. My USB mouse on c 13, 63 is working like a charm. This is with kernel 2.4.0-test8 So, I assume that I'm still missing something obvious here. What? Any thoughts anyone? Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre2 fails to compile (ATI Rage 128 drm)
make[4]: Entering directory `/disks/hdb/src/kernel/linux/drivers/char/drm' gcc -D__KERNEL__ -I/disks/hdb/src/kernel/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -march=i686 -fno-strict-aliasing-DEXPORT_SYMTAB -c r128_drv.c In file included from r128_drv.c:33: drmP.h:74: compat-pre24.h: No such file or directory r128_drv.c: In function `r128_lock': r128_drv.c:683: structure has no member named `priority' r128_drv.c:683: `DEF_PRIORITY' undeclared (first use in this function) r128_drv.c:683: (Each undeclared identifier is reported only once r128_drv.c:683: for each function it appears in.) r128_drv.c: In function `r128_unlock': r128_drv.c:730: structure has no member named `priority' r128_drv.c:730: `DEF_PRIORITY' undeclared (first use in this function) make[4]: *** [r128_drv.o] Error 1 make[4]: Leaving directory `/disks/hdb/src/kernel/linux/drivers/char/drm' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/disks/hdb/src/kernel/linux/drivers/char/drm' make[2]: *** [_subdir_drm] Error 2 make[2]: Leaving directory `/disks/hdb/src/kernel/linux/drivers/char' make[1]: *** [_subdir_char] Error 2 make[1]: Leaving directory `/disks/hdb/src/kernel/linux/drivers' make: *** [_dir_drivers] Error 2 Tiesitkö, että Sunpoint.netin käyttäjät voivat lukea sähköpostinsa myös WAP-puhelimella. http://www.sunpoint.net/SunAds/click.htm?mode=footer==http%3A%2F%2Fwww.sunpoint.net%2Fwap%2F - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
"Dunlap, Randy" <[EMAIL PROTECTED]> said: [] > > Good thing I promised Ted to bring another bottle of > > that Brazillian liquor to the next event we meet ;) > Rik, does it have to be Brazilian liquor? > I still have patches for 2.4.0-final also. You'd have to ask Ted... BTW folks, please don't overdo this "exotic liquor for patch urgencies" swap: If Ted is over the edge, he won't do anything about it. ;-) On a more serious note: What about documentation patches? 'perl scripts/checkhelp.pl $(find . -name "[Cc]onfig.in")' counts 301 help texts missing in 2.2.18pre9 and 238 in 2.4.0-test9-pre2... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patchlet] Minor cleanup in mm/filemap.c (2.4.0-t9p2)
Hi.
The following patch cleans up some minor stuff in mm/filemap.c:
o transmorphs tsk->state=XX -> __set_task_state
o removes the wait argument to filemap_write_page (it is not used)
and cleans up the two places filemap_write_page is called.
o cleans up some comments.
--- linux-240test9-pre2-clean/mm/filemap.c Sun Sep 17 19:38:03 2000
+++ linux/mm/filemap.c Mon Sep 18 21:03:24 2000
@@ -491,7 +491,7 @@
run_task_queue(_disk);
schedule();
} while (PageLocked(page));
- tsk->state = TASK_RUNNING;
+ __set_task_state(tsk, TASK_RUNNING);
remove_wait_queue(>wait, );
}
@@ -1450,8 +1450,7 @@
}
static int filemap_write_page(struct file *file,
- struct page * page,
- int wait)
+ struct page * page)
{
/*
* If a task terminates while we're swapping the page, the vma and
@@ -1471,7 +1470,7 @@
extern void wakeup_bdflush(int);
int filemap_swapout(struct page * page, struct file * file)
{
- int retval = filemap_write_page(file, page, 0);
+ int retval = filemap_write_page(file, page);
wakeup_bdflush(0);
return retval;
}
@@ -1518,7 +1517,7 @@
pgoff, page->index, address, vma->vm_start, vma->vm_pgoff);
}
lock_page(page);
- error = filemap_write_page(vma->vm_file, page, 1);
+ error = filemap_write_page(vma->vm_file, page);
UnlockPage(page);
page_cache_free(page);
return error;
@@ -2118,7 +2117,7 @@
if (!tmp)
return error;
- /* (end - start) is # of pages, and also # of bytes in "vec */
+ /* (end - start) is # of pages, and also # of bytes in vec */
remaining = (end - start),
error = 0;
@@ -2157,9 +2156,9 @@
* return values:
* zero- success
* -EFAULT - vec points to an illegal address
- * -EINVAL - addr is not a multiple of PAGE_CACHE_SIZE,
+ * -EINVAL - start is not a multiple of PAGE_CACHE_SIZE,
* or len has a nonpositive value
- * -ENOMEM - Addresses in the range [addr, addr + len] are
+ * -ENOMEM - Addresses in the range [start, start + len] are
* invalid for the address space of this process, or
* specify one or more pages which are not currently
* mapped
--
Regards,
Rasmus([EMAIL PROTECTED])
What a terrible thing to have lost one's mind. Or not to have a mind
at all. How true that is.
-- Vice President Dan Quayle winning friends while
speaking to the United Negro College Fund
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: The INN/mmap bug
On Mon, 18 Sep 2000, Alexander Viro wrote: > Except that the only reason why check for page being uptodate is correct > is that for such pages we are guaranteed that buffer ring will not be > dropped when page contatins data newer than on disk. Ugh. Translation: The only reason why the simple check for page being uptodate is enough to avoid killing data with bogus rereads is that for pages that are NOT uptodate we are guaranteed that buffer ring will not be dropped when data in page is newer than on disk. Sorry. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
