Re: 2.2.18pre16 and USB_UHCI_ALT
On Wed, Oct 18, 2000 at 11:02:27PM -0700, Greg KH wrote: > On Wed, Oct 18, 2000 at 10:47:16PM -0700, David Rees wrote: > > > > This is on a Tyan Trinity 1598 Socket 7 motherboard. No hubs of any sort. > > No external hubs? Then why is the hub driver seeing both a 2 port root > hub, and a 4 port "normal" hub? Does this motherboard have more than 2 > external USB connectors on it? > > Odd. Well, according to /proc/pci there's two USB controllers: Bus 0, device 7, function 2: USB Controller: VIA Technologies VT 82C586 Apollo USB (rev 6). Medium devsel. IRQ 10. Master Capable. Latency=32. I/O at 0xd400 [0xd401]. Bus 0, device 7, function 3: USB Controller: VIA Technologies VT 82C586 Apollo USB (rev 6). Medium devsel. IRQ 10. Master Capable. Latency=32. I/O at 0xd800 [0xd801]. -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre16 and USB_UHCI_ALT
On Wed, Oct 18, 2000 at 10:47:16PM -0700, David Rees wrote: > > This is on a Tyan Trinity 1598 Socket 7 motherboard. No hubs of any sort. No external hubs? Then why is the hub driver seeing both a 2 port root hub, and a 4 port "normal" hub? Does this motherboard have more than 2 external USB connectors on it? Odd. > I'll give the usb-uhci driver in 2.2.18pre17 another shot tonight. Let me know how it goes. greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre16 and USB_UHCI_ALT
On Wed, Oct 18, 2000 at 10:51:05PM -0700, Greg KH wrote: > On Wed, Oct 18, 2000 at 08:21:53AM -0700, David Rees wrote: > > > > Nothing else odd changed. Here's the boot sequence and messages which > > repeated endlessly after booting 2.2.18pre16 with the usb-uhci driver: > > This kinda looks like you have a flaky hub. It is a self powered hub? > If so, try making it a external powered hub if you can. > Or is this the root hub on a laptop? This is on a Tyan Trinity 1598 Socket 7 motherboard. No hubs of any sort. I'll give the usb-uhci driver in 2.2.18pre17 another shot tonight. -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre16 and USB_UHCI_ALT
On Wed, Oct 18, 2000 at 08:21:53AM -0700, David Rees wrote: > > Nothing else odd changed. Here's the boot sequence and messages which > repeated endlessly after booting 2.2.18pre16 with the usb-uhci driver: This kinda looks like you have a flaky hub. It is a self powered hub? If so, try making it a external powered hub if you can. Or is this the root hub on a laptop? thanks, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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: AMD CPU misdetection?
> model name : AMD-K6(tm) 3D processor > Shouldn't it be K6-2? nope A plain K6: model : AMD-K6tm w/ multimedia extensions A K6-2: model name : AMD-K6(tm) 3D processor A K6-3: model name : AMD-K6(tm) 3D+ Processor A K6-2+: model name : AMD-K6(tm)-III Processor This isn't done by linux; as far as I know these strings are on the chip and set by AMD. It tends to be confusing, but the value you get is proper for your chip. Vince [who has to parse these all properly in linux_logo] - 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] usb-core.c removal
On Wed, Oct 18, 2000 at 10:03:34PM -0700, Greg KH wrote: > > This should solve the versioned modules with a USB core compiled into > the kernel problem that people were having. Actually, that isn't completely true, as the Makefile still has the same problem as before. Keith's comments get us closer, but still not quite there. The patch doesn't solve the versioned symbol problem directly, sorry. But it still a good idea anyway :) I'll look into the Makefile stuff more tomorrow. thanks, greg k-h -- greg@(kroah|wirex).com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8, usb, unresolved symbols
On Thu, Oct 19, 2000 at 10:45:36AM +1100, Keith Owens wrote: > On Wed, 18 Oct 2000 13:47:40 -0700, > Randy Dunlap <[EMAIL PROTECTED]> wrote: > >Keith Owens wrote: > >> +obj-$(CONFIG_USB) += usbcore.o usb.o > > > >We still need your help. Using this usb/Makefile change gives > >me errors on all (?) exported symbols when I try to build all > >of USB into the kernel. Example (one of many): > > > >usbcore.o: In function `usb_set_address': > >usbcore.o(.text+0x1b90): multiple definition of `usb_set_address' > >usb.o(.text+0x1b90): first defined here > > Remove usb.o from the list of objects that make up usbcore. I don't think that would work, for if the USB core code is compiled as a module, then usb.o has to be part of usbcore.o, or am I missing something here? greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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-core.c removal
Hi,
Here's the patch that removes usb-core.c and moves its functions into
usb.c. It's against 2.4.0-test10-pre4.
This should solve the versioned modules with a USB core compiled into
the kernel problem that people were having.
Thanks,
greg k-h
--
greg@(kroah|wirex).com
diff -Naur -X dontdiff linux-2.4.0-test10-pre4/drivers/usb/Makefile
linux-2.4.0-test10-pre4-greg/drivers/usb/Makefile
--- linux-2.4.0-test10-pre4/drivers/usb/MakefileTue Oct 3 23:44:23 2000
+++ linux-2.4.0-test10-pre4-greg/drivers/usb/Makefile Wed Oct 18 21:56:43 2000
@@ -21,7 +21,7 @@
# Multipart objects.
list-multi := usbcore.o
-usbcore-objs := usb.o usb-debug.o usb-core.o hub.o
+usbcore-objs := usb.o usb-debug.o hub.o
# Optional parts of multipart objects.
diff -Naur -X dontdiff linux-2.4.0-test10-pre4/drivers/usb/usb-core.c
linux-2.4.0-test10-pre4-greg/drivers/usb/usb-core.c
--- linux-2.4.0-test10-pre4/drivers/usb/usb-core.c Tue Oct 3 23:44:24 2000
+++ linux-2.4.0-test10-pre4-greg/drivers/usb/usb-core.c Wed Dec 31 16:00:00 1969
@@ -1,53 +0,0 @@
-/*
- * driver/usb/usb-core.c
- *
- * (C) Copyright David Waite 1999
- * based on code from usb.c, by Linus Torvalds
- *
- * The purpose of this file is to pull any and all generic modular code from
- * usb.c and put it in a separate file. This way usb.c is kept as a generic
- * library, while this file handles starting drivers, etc.
- *
- */
-
-#include
-#include
-#include
-#include
-
-/*
- * USB core
- */
-
-int usb_hub_init(void);
-void usb_hub_cleanup(void);
-int usb_major_init(void);
-void usb_major_cleanup(void);
-
-
-/*
- * Cleanup
- */
-
-static void __exit usb_exit(void)
-{
- usb_major_cleanup();
- usbdevfs_cleanup();
- usb_hub_cleanup();
-}
-
-/*
- * Init
- */
-
-static int __init usb_init(void)
-{
- usb_major_init();
- usbdevfs_init();
- usb_hub_init();
-
- return 0;
-}
-
-module_init(usb_init);
-module_exit(usb_exit);
diff -Naur -X dontdiff linux-2.4.0-test10-pre4/drivers/usb/usb.c
linux-2.4.0-test10-pre4-greg/drivers/usb/usb.c
--- linux-2.4.0-test10-pre4/drivers/usb/usb.c Tue Oct 3 23:44:24 2000
+++ linux-2.4.0-test10-pre4-greg/drivers/usb/usb.c Wed Oct 18 21:58:32 2000
@@ -26,6 +26,7 @@
#include
#include /* for in_interrupt() */
#include
+#include
#ifdef CONFIG_USB_DEBUG
@@ -47,6 +48,9 @@
0;
#endif
+extern int usb_hub_init(void);
+extern void usb_hub_cleanup(void);
+
/*
* Prototypes for the device driver probing/loading functions
*/
@@ -2028,6 +2032,32 @@
return _bus_list;
}
#endif
+
+
+/*
+ * Init
+ */
+static int __init usb_init(void)
+{
+ usb_major_init();
+ usbdevfs_init();
+ usb_hub_init();
+
+ return 0;
+}
+
+/*
+ * Cleanup
+ */
+static void __exit usb_exit(void)
+{
+ usb_major_cleanup();
+ usbdevfs_cleanup();
+ usb_hub_cleanup();
+}
+
+module_init(usb_init);
+module_exit(usb_exit);
/*
* USB may be built into the kernel or be built as modules.
PGP signature
Removal of get/put_module_symbol, 2.4
I started work on the removal of get/put_module_symbol and immediately hit problems, these functions are not being used the way we thought. Instead of being used as weak linkage from one module to another, people are using get_module_symbol in kernel code to decide if a module needs to be loaded and, once loaded, to extract symbols from the module. In other words, the dependency chain now goes kernel->module instead of module->kernel. IMNSHO this is wrong and should be removed ASAP. It is confusing, it runs the risk of circular dependencies, it hard codes function names into kernel code instead of letting each module define its own interfaces, each new module requires changes to kernel code. Most of the existing code will not work with symbol versions. get_module_symbol() is in the wrong place and has the wrong interface to pick up versioned symbols. AFAICT all of the uses of get_module_symbol(), with the possible exception of agp support, are being used because people were too lazy to create register_xxx interfaces. Instead of the module registering itself on load like almost every other module, the lookup work is pushed back onto the kernel. This is not a clean interface. Unless somebody can come up with a good reason why they absolutely need get_module_symbol(), it will be removed. Sources that only need to know if an existing function has already been loaded (e.g. agsupport.c needs to know if agp_free_memory has been loaded) will be replaced with weak external references. Sources that issue request_module() then use get_module_symbol() to look inside the module will be changed to use a registration system, as almost every module already does. This will affect mtd, agp and 8390. - 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/
AMD CPU misdetection?
Kernel == 2.2.17 CPU == AMD K6-2 350 Clock set to 300Mhz 2 root@asdf:~# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor ^^ Shouldn't it be K6-2? stepping: 12 cpu MHz : 300.684 cache size : 64 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow bogomips: 599.65 -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Be up to date on nerd news and stuff that matters: http://slashdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Transferring data between user and kernel space...
Hi all, I would like to transfer a huge buffer (say 128k) from user space to kernel space and return the result in the same buffer so that the user can access the processed data from that... since these pages passed from the user spcae may be fragmented how do i make them contiguous from user space.. and what functions should i use to copy data from this user space buffer to kernel... will copy_from_user do this job.. and for retuning it should i use copy_to_user i would like to avoid copying the same data to and fro from user space is there any other method to do this... could someone send detailed info about this samples /links will be really helpful any help appreciated... thanks azad - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2 generating odd TCP resets?
> Looks like the application on the Linux system is issuing a close() on
> the socket before reading all of the available data. That always
> causes a RST to be sent.
Here's some stripped down code to generate bogus (I think) TCP
resets on 2.2.14-17.
The RST is generated when the server closes the socket, but there
is NO data pending on the socket.
On linux run
./st
on windows run
./st 10.0.70.5
(or whatever).
The windows box should return an error on read after linux
generates the RST. The code can be compiled with cygwin.
Is there any reason this should fail? It does not fail when
talking to a linux host. The only obvious difference is windows
generates two ACK's of the server's FIN.
#include
#include
#include
#include
#include
#define LEN 100
int main(int argc, char *argv[])
{
struct sockaddr_in sin;
int len, fd;
char buff[LEN];
len = sizeof (sin);
sin.sin_family = AF_INET;
sin.sin_port = htons (5000);
if (argc > 1) { /* client side */
int n, count = 0;
printf("client\n");
sin.sin_addr.s_addr = inet_addr(argv[1]);
fd = socket (AF_INET, SOCK_STREAM, 0);
if (fd < 1) { perror("socket"); exit(0); }
while (connect (fd, (struct sockaddr *) , len)) {
usleep(1);
perror("connect");
}
printf("connected to server\n");
shutdown(fd, 1);
usleep(200);
while (count < LEN) {
n = read(fd, buff, 100);
if (n < 0) {
printf("error on read\n");
break;
}
count += n;
}
if (count == LEN) printf("read ok\n");
/*printf("read %s\n", buff); */
close(fd);
} else { /* server side */
int i, new_fd;
int on = 1;
printf("server\n");
sin.sin_addr.s_addr = INADDR_ANY;
fd = socket (AF_INET, SOCK_STREAM, 0);
setsockopt (fd, SOL_SOCKET, SO_REUSEADDR, , sizeof (on));
if (fd < 1) {
perror("serv socket");
exit(0);
}
if (bind (fd, (struct sockaddr *), len) < 0
||listen (fd, 1) < 0) {
perror("bind/listen");
close(fd);
exit(0);
}
new_fd = accept (fd, 0, 0);
if (new_fd < 0) { perror("accept"); exit(0); }
close(fd);
usleep(100);
shutdown (new_fd, 0);
fcntl (new_fd, F_SETFL, 1);
for (i = 0; i < LEN; ++i) buff[i] = i%256;
write(new_fd, buff, LEN);
close(new_fd);
printf("socket closed\n");
usleep(1000);
printf("server exiting\n");
}
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: bind() allowed to non-local addresses
Followup to: <[EMAIL PROTECTED]> By author:"David S. Miller" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > How about first finding out why their buggy JRE detects whether an > address is local by trying to bind() to it :-) > > Really, when an application feeds a specific address into bind() it > must have good reason for selecting it. All I want to know in this > specific instance, is why Sun's JRE is sending non-local addresses > into bind(), that's all. > autofs uses the following algorithm to determine if an address is local: connect to it as the remote end using a datagram socket (so there isn't any actual network traffic). If the LOCAL address (which is picked by the system) and the REMOTE address (the address under test) are identical afterwards, the address is local. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] vmscan.c:102 on 2.4.0-test10p4
Hi Just had the following happening right after booting into the fresh kernel. Started X, and after firing up StarOffice, everything stopped responding. I could switch back to a vc, and use Alt+SysRq to at least sync/unmount the fs. Registers showed: SysRq: Show Regs EIP: 0010:[acpi_idle+819/864] EFLAGS: 00200246 EAX: 00f47a65 EBX: c02c ECX: 00f47a65 EDX: 4008 ESI: 4008 EDI: c02c EBP: e000 DS: 0018 ES: 0018 CR0: 8005003b CR2: 080c5b08 CR3: 04471000 CR4: 0090 The actual oops: kernel BUG at vmscan.c:102! invalid operand: CPU:0 EIP:0010:[recalculate_vm_stats+25/32] EFLAGS: 00013286 eax: 001c ebx: 0001e800 ecx: edx: esi: c11c66c0 edi: 06aec045 ebp: c0fd94a4 esp: c12ede88 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 2, stackpage=c12ed000) Stack: c0252c85 c0252e44 0066 0001 0010 4012a000 c0fd94a4 40129000 4012b000 c012918d c5a0ec80 c7e27780 40129000 c0fd94a4 0004 c0fd5400 4012b000 4012b000 c0fd5400 0301 c01303ba c4c0eb40 01cf c012a023 Call Trace: [tvecs+6717/45816] [tvecs+7164/45816] [swap_out_vma+77/432] [bread+106/112] [refill_inactive_scan+67/240] [refile_buffer+5/16] [__bforget+11/96] [bread+18/112] [swap_out_vma+284/432] [swap_out+94/384] [refill_inactive+147/400] [refill_inactive+338/400] [do_try_to_free_pages+110/144] [refill_inactive+384/400] [kernel_thread+11/64] Code: 0f 0b 83 c4 0c 83 e7 02 74 16 6a 68 68 44 2e 25 c0 68 85 2c And ksymoops: 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: 83 e7 02 and$0x2,%edi Code; 0008 Before first symbol 8: 74 16 je 20 <_EIP+0x20> 0020 Before first symbol Code; 000a Before first symbol a: 6a 68 push $0x68 Code; 000c Before first symbol c: 68 44 2e 25 c0push $0xc0252e44 Code; 0011 Before first symbol 11: 68 85 2c 00 00push $0x2c85 'free' gives: total used free sharedbuffers cached Mem:126460 52588 73872 0 3104 31088 -/+ buffers/cache: 18396 108064 Swap: 128516 0 128516 Please tell me if anything is missing from the above. Best regards, Dewet Diener - 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/
Any use of the network layer lock system . BIG . Sorry .
Hello All , on a compaq proliant 6000, 4 ppro 200Mhz 512k cpu's, 4.3Gb seagate system drive attached to onboard 53c875 ctrlr, Smart Array 2/P, 392Mb, 4 18.Gb seagate st118273 raid 5, Digital DE500(tulip), 3.5 Floppy, ide cdrom . since I have upgraded from 2 cpu's to 4 cpu's I get system hangs when trying to anything on the network , a ping , even of its local ip . I can (sometimes) get it to just start reboot with crtl-alt-del & then it'll just squeal . Other times it is hard hard locked not even responding to c/r at the login prompt . Although it does sometimes respond to pings (sort of) from off system . ie: 120 packets transmitted, 86 packets received, 28% packet loss round-trip min/avg/max = 0.5/12.1/1000.6 ms I have played with swapping in and out differant cpu's to see if one of them is the culprit , no luck . I even tried a differant ether card , having heard of troubles with some of the cards . Anyone have any thoughts ? Tia , JimL ++ | James W. Laferriere | System Techniques | Give me VMS | | NetworkEngineer | 25416 22nd So | Give me Linux | | [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | ++ -- Versions installed: (if some fields are empty or looks -- unusual then possibly you have very old versions) Slackware-7.1.0 Linux cp6000 2.4.0-test9 #1 SMP Fri Oct 13 16:36:57 PDT 2000 i686 unknown Kernel modules 2.3.11 Gnu C 2.7.2.3 Binutils 2.9.1.0.25 Make version 3.79 Linux C Library 6 -libc-2.1.3 Dynamic Linker (ld.so) 1.9.9 Linux C++ Library Notfound Procps 2.0.6 Mount 2.10l Net-tools 1.55 Sh-utils 2.0 Flex 2.5.4 E2fsprogs 1.18 arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 00F 0F 000 0 01139 02 00F 0F 000 0 01131 03 00F 0F 000 0 01141 04 00F 0F 000 0 01149 05 00F 0F 110 0 01151 06 00F 0F 000 0 01159 07 00F 0F 000 0 01161 08 00F 0F 000 0 01169 09 00F 0F 110 0 01171 0a 00F 0F 110 0 01179 0b 00F 0F 000 0 01181 0c 00F 0F 000 0 01189 0d 000 00 100 0 00000 0e 00F 0F 000 0 01191 0f 00F 0F 000 0 01199 IRQ to pin mappings: IRQ0 -> 2 IRQ1 -> 1 IRQ3 -> 3 IRQ4 -> 4 IRQ5 -> 5 IRQ6 -> 6 IRQ7 -> 7 IRQ8 -> 8 IRQ9 -> 9 IRQ10 -> 10 IRQ11 -> 11 IRQ12 -> 12 IRQ13 -> 13 IRQ14 -> 14 IRQ15 -> 15 done. calibrating APIC timer ... . CPU clock speed is 199.9870 MHz. . host bus clock speed is 66.6622 MHz. cpu: 0, clocks: 22, slice: 133324 CPU0 cpu: 2, clocks: 22, slice: 133324 cpu: 3, clocks: 22, slice: 133324 cpu: 1, clocks: 22, slice: 133324 CPU1 CPU2 CPU3 checking TSC synchronization across CPUs: passed. Setting commenced=1, go go go mtrr: your CPUs had inconsistent fixed MTRR settings mtrr: probably your BIOS does not setup all CPUs PCI: PCI BIOS revision 2.10 entry at 0xf0070, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: i440KX/GX host bridge 00:19.0: secondary bus 00 PCI: i440KX/GX host bridge 00:1a.0: secondary bus 01 PCI: Device 00:78 not found by BIOS PCI: Device 00:a0 not found by BIOS PCI: Device 00:c8 not found by BIOS PCI: Device 00:d0 not found by BIOS Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) IPv4 over IPv4 tunneling driver early initialization of device tunl0 is deferred GRE over IPv4 tunneling driver early initialization of device gre0 is deferred Linux IP multicast router 0.06 plus PIM-SM IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver early initialization of device sit0 is deferred Registered PPPoX v0.5 Registered PPPoE v0.5 Initializing RT netlink socket Starting kswapd v1.8 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: enabling 8 loop devices Uniform Multi-Platform E-IDE driver Revision: 6.31 ide:
Re: mapping user space buffer to kernel address space
Linus Torvalds wrote:
> Anyway, I didn't realize you were talking about the sound drivers use of
> remap_page_range(). That's not the original reason for remap_page_range()
> at all, and in fact it's the _ugly_ way to do things. It's simple and it
> works, but it's not pretty.
>
> Quite frankly, the way I'd conceptually prefer people do these kinds of
> DMA buffers etc is to just have a "nopage()" function, and let that
> nopage() function just fill in the page from the DMA buffer directly. This
> would work fine, and would get rid of all the playing with PG_reserved
> etc.
Well coolio. Would somebody be up for sanity checking my audio mmap
code (attached)? It doesn't look too hard at all to get the audio
drivers doing the correct thing.
Converting to this was easy... my driver hardcodes the buffer size at
PAGE_SIZE. Since Via audio uses scatter-gather DMA, all I need to do in
'nopage' is get the virtual page number for the vma, and use that as a
direct index into the scatter-gather array.
Since this code works in my local tests, my two concerns at this point
are correct vma->vm_pgoff treatment, and correct vm_flags/vm_file usage.
Jeff
--
Jeff Garzik| The difference between laziness and
Building 1024 | prioritization is the end result.
MandrakeSoft |
#ifdef VIA_SUPPORT_MMAP
static struct page * via_mm_nopage (struct vm_area_struct * vma,
unsigned long address, int write_access)
{
struct via_info *card = vma->vm_private_data;
struct via_channel *chan = >ch_out;
unsigned long pgoff;
int rd, wr;
DPRINTK ("ENTER, start %lXh, ofs %lXh, pgoff %ld, addr %lXh, wr %d\n",
vma->vm_start,
address - vma->vm_start,
(address - vma->vm_start) >> PAGE_SHIFT,
address,
write_access);
assert (VIA_DMA_BUF_SIZE == PAGE_SIZE);
if (address > vma->vm_end) {
DPRINTK ("EXIT, returning NOPAGE_SIGBUS\n");
return NOPAGE_SIGBUS; /* Disallow mremap */
}
if (!card) {
DPRINTK ("EXIT, returning NOPAGE_OOM\n");
return NOPAGE_OOM; /* Nothing allocated */
}
/* XXX what about vma->vm_pgoff? */
pgoff = (address - vma->vm_start) >> PAGE_SHIFT;
rd = card->ch_in.is_mapped;
wr = card->ch_out.is_mapped;
#ifndef VIA_NDEBUG
{
unsigned long max_bufs = VIA_DMA_BUFFERS;
if (rd && wr) max_bufs *= 2;
/* via_dsp_mmap() should ensure this */
assert (pgoff < max_bufs);
}
#endif
/* if full-duplex (read+write) and we have two sets of bufs,
* then the playback buffers come first, sez soundcard.c */
if (pgoff >= VIA_DMA_BUFFERS) {
pgoff -= VIA_DMA_BUFFERS;
chan = >ch_in;
} else if (!wr)
chan = >ch_in;
assert unsigned long)chan->sgbuf[pgoff].cpuaddr) % PAGE_SIZE) == 0);
DPRINTK ("EXIT, returning page %p for cpuaddr %lXh\n",
virt_to_page (chan->sgbuf[pgoff].cpuaddr),
(unsigned long) chan->sgbuf[pgoff].cpuaddr);
return virt_to_page (chan->sgbuf[pgoff].cpuaddr);
}
static int via_mm_swapout (struct page *page, struct file *filp)
{
return 0;
}
struct vm_operations_struct via_mm_ops = {
nopage: via_mm_nopage,
swapout:via_mm_swapout,
};
static int via_dsp_mmap(struct file *file, struct vm_area_struct *vma)
{
struct via_info *card;
int nonblock = (file->f_flags & O_NONBLOCK);
int rc = -EINVAL, rd=0, wr=0;
unsigned long max_size, size, start, offset;
assert (file != NULL);
assert (vma != NULL);
card = file->private_data;
assert (card != NULL);
DPRINTK ("ENTER, start %lXh, size %ld, pgoff %ld\n",
vma->vm_start,
vma->vm_end - vma->vm_start,
vma->vm_pgoff);
assert (VIA_DMA_BUF_SIZE == PAGE_SIZE);
max_size = 0;
if (file->f_mode & FMODE_READ) {
rd = 1;
max_size += (VIA_DMA_BUFFERS * VIA_DMA_BUF_SIZE);
}
if (file->f_mode & FMODE_WRITE) {
wr = 1;
max_size += (VIA_DMA_BUFFERS * VIA_DMA_BUF_SIZE);
}
start = vma->vm_start;
offset = (vma->vm_pgoff << PAGE_SHIFT);
size = vma->vm_end - vma->vm_start;
if (size > max_size)
goto out;
if ((offset >= max_size) || (offset >= size))
goto out;
rc = via_syscall_down (card, nonblock);
if (rc) goto out;
vma->vm_ops = _mm_ops;
vma->vm_private_data = card;
vma->vm_flags |= VM_LOCKED | VM_SHM; /* Don't swap */
vma->vm_file = file;
if (rd)
Linux 2.2.18pre17
This is just to give folks something to sync against. Test it by all means however. Must fix stuff left to do for 2.2.18final - Merge the S/390 stuff and make S/390 build again - Fix the megaraid (revert if need be) - Fix the ps/2 misdetect bug that has appeared - NFSv3 hang report - Get to the bottom of the VM mystery if possible 2.2.18pre17 o Move a few escaped m68k headers into the right (me) directory o Backport 2.4 AF_UNIX garbage collect speedups (Dave Miller) o TCP fixes for NFS (Saadia Khan) o Fix USB audio hangs (David Woodhouse) o Sparc64 dcache and exec fixes (Dave Miller) o Fix typing crap in divert.h (Jeff Garzik) o Use pkt_type in diverter, add maintainer info (Dave Miller) o Fix obscure NAT problem in FIB code (Dave Miller) o Fix sk->allocation in TCP sendmsg (Marcelo Tossati) o Elevator fixes (Andrea Arcangeli) o Allow broken_suid on NFS root (Trond Myklebust) o Fix net/ipv6/proc off by one bug(Dave Miller) o Fix AGP oops on Alpha (Michal Jaegermann) o MSR/CPUID init call fixes (Arjan van de Ven) o CS4281 sound hang fixes (Thomas Woller) o AX.25 comment updates, Joerg has moved email(Joerg Reuter) 2.2.18pre16 o Finally get the m68k tree merged(Andrew McPherson and a cast of many) o Bring the sparc back in line, make it build (Anton Blanchard) o USB Bluetooth fixes/docs(Greg Kroah-Hartman) o Fix auth_null credentials bug (Hai-Pao Fan) o Update cpu flag names (Dave Jones) o Console 'quiet' boot option as in 2.4 (Rusty Russell) o Make the sx serial driver work again(Patrick van de Lageweg) o Fix negotation on the SYM53C1010(Gerard Roudier) o Fix alpha loops per jiffy (Jay Estabrook) o Fix pegasus to work with 2.2 kernels(Greg Kroah-Hartman) o Update plusb driver for 2.2.x (Eric Ayers, Deti Fliegl) o Fix ohci to use __init (Greg Kroah-Hartman) o /sbin/hotplug support for USB as in 2.4 (Greg Kroah-Hartman) o Update ksymoops url (Keith Owens) o Update the changes doc about gcc(Petri Kaukasoina) o Fix AMD flag naming (Ulrich Windl) o Restore old block size on devices after a partition scan (needed for powermac for one)(Michael Schmitz) o Fix GPL naming in SubmittingDrivers (Mike Harris) o NFSv3 server patches merge (Dave Higgen) o CS46xx changes (Nils Faerber) o Fix sys_nanosleep for >4GHz CPU changes (me) (Spotted by Ben Herrenschmidt) o Fix pas rev D mixer (??) o Fix multiple spelling errors(André Dahlqvist) o ISDN updates(Kai Germaschewski) o XSpeed DSL driver (Timothy Lee, Dan Hollis) o IDE multi-lun/single-lun handling (Jens Axboe) o Fix alpha generic trident sound support (Rich Payne) o Fix PPC for loops per jiffy (Cort Dougan) 2.2.18pre15 o Default msdos behaviour to old (small) letters (me) | An option 'big' goes with 'small' o Fix define collision in cpqfc (Arjan van de Ven) o Fix case where scripts/kwhich isnt executable (me) o Alpha FPU divide fix(Richard Henderson) o Add ADMtek985 to the tulip list (J Katz) o Lose excess ymfpci debugging(Rob Landley) o Fix i2c bus id clash(Russell King) o Update the ARM vidc driver (Russell King) o Update the ARM am79c961a driver (Russell King) o Fix parport_pc build with no PCI(Russell King) o Fix ARM memzero (Russell King) o Update ARM for __init and __setup (Russell King) o Update ARM to loops_per_jiffy (Russell King) o Remove arm ecard debug messages (Russell King) o Fix ARM makefiles (Russell King) o Fix iph5526 driver to
Re: Supermicro 370DE6
we have an outstanding order for one... word from the vendor was first or second week in november. joelja On Wed, 18 Oct 2000, Wakko Warner wrote: > Has anyone tried this board with any recent 2.2 or 2.4 kernel? > > It has: > Onboard Intel 82559 Ethernet controller > Onboard Adaptec AIC-7899 dual channel Ultra160 SCSI controller > ServerWorks ServerSet III HE-SL Chipset > > -- -- 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/
Supermicro 370DE6
Has anyone tried this board with any recent 2.2 or 2.4 kernel? It has: Onboard Intel 82559 Ethernet controller Onboard Adaptec AIC-7899 dual channel Ultra160 SCSI controller ServerWorks ServerSet III HE-SL Chipset -- Lab tests show that use of micro$oft causes cancer in lab animals - 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: bind() allowed to non-local addresses
Jamie Lokier <[EMAIL PROTECTED]> said: > David S. Miller wrote: > > How about first finding out why their buggy JRE detects whether an > > address is local by trying to bind() to it :-) > I don't know why the JRE does it, but I've seen that sort of thing used > to decide whether to try X shared memory. Could you explain the logic behid that?! -- 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/
Re: CDROMPLAYTRKIND in 2.4.X
On Thu, 19 Oct 2000, Jens Axboe wrote: > > Admittedly I can't remember the last time I used cdp, but this seems > > like a recent problem. Are we going to look for a workaround? I've > > tried a number of player apps and they all appear to fail in the same > > way. > > > > Judging from past history I'd say the users are going to be told to bug > > the app maintainers to tell them it's broken Jim. It always comes out > > sounding a bit harsh. > > ide-scsi should probably just convert playtrkin to play_audio_10 > or play_audio_msf Assuming you are the maintainer of ide-scsi, is this the kind of change you'd be willing to accept? I got the idea this was one of those "we don't change the kernel to accomadate borken apps" deals. If your plate is full would you like me to look at it this weekend since I'm the one with the "problem"? - 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/
CML 0.8.1 is available
The latest version is always available at http://www.tuxedo.org/~esr/kbuild/ Release 0.8.1: Wed Oct 18 21:17:56 EDT 2000 * Rules file synchronized with 2.4.0-test9. CML2 is stable, working, and ready to replace the old system. -- http://www.tuxedo.org/~esr/">Eric S. Raymond The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Thu, 19 Oct 2000 01:56:38 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote: >Keith Owens wrote >> modprobe would attempt to satisfy weak external references as if they >> were normal references, including all the module dependency chains and >> reference counts. If the reference cannot be satisfied, it is set to >> zero instead of causing an error. No changes to load/unload. > >I dont believe modprobe can do this race free in userspace Module dependency checking in userspace has always been racy. A is being loaded and needs a symbol from B. B was loaded at the start of insmod so the symbol was resolved. By the time A is actually loaded, B has been removed, userspace race. This is checked for in sys_init_module() printk(KERN_ERR "init_module: found dependency that is " "(no longer?) a module.\n"); Making some of the external references weak makes no difference. Either they are resolved to a module by insmod and checked by sys_init_module() or insmod replaces the reference with NULL. - 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: bind() allowed to non-local addresses
> The XNS specification seems loose enough to allow the Linux > behaviour. I don't > think we should however adopt it as default behaviour. Programs > that dont care > about addresses use INADDR_ANY. > > Alan I worry that an application may use ability to bind to determine whether an address is local or not in an area with security impact. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
> modprobe would attempt to satisfy weak external references as if they > were normal references, including all the module dependency chains and > reference counts. If the reference cannot be satisfied, it is set to > zero instead of causing an error. No changes to load/unload. I dont believe modprobe can do this race free in userspace - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Wed, 18 Oct 2000 20:44:19 -0400 (EDT), Alan Cox <[EMAIL PROTECTED]> wrote: >Keith Owens wrote >> Nice and clean. WEAK_EXTERN does some magic to create a NULL pointer >> at link time or load time if the symbol is not resolved. > >It also has to do the rest of the magic to handle module load/unload in >parallel but that can be done as per the current code modprobe would attempt to satisfy weak external references as if they were normal references, including all the module dependency chains and reference counts. If the reference cannot be satisfied, it is set to zero instead of causing an error. No changes to load/unload. >> Linus, do you want a patch for this? > >2.5 surely Normally I would agree but the existing code is going to cause problems all the way through 2.4. This only affects drivers/net/8390.h (all 8390 cards?) drivers/char/drm/agpsupport.c, drivers/mtd/cfi_probe.c, drivers/mtd/docprobe.c. As currently coded, some of those simply will not work with symbol versions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
> Nice and clean. WEAK_EXTERN does some magic to create a NULL pointer > at link time or load time if the symbol is not resolved. It also has to do the rest of the magic to handle module load/unload in parallel but that can be done as per the current code > Linus, do you want a patch for this? 2.5 surely - 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: atm_devs protection.
Werner Almesberger wrote: > Mitchell Blank Jr wrote: > > Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc > > open/close) code is pretty suspect. > > That's actually a bit of an understatement: Well, I was trying to be polite to the original author ;-) -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Thu, 19 Oct 2000 01:46:26 +0200, Jamie Lokier <[EMAIL PROTECTED]> wrote: >John Levon wrote: >> should get_module_symbol() die ? > >Please no. I use it for a situation where two drivers can be used >independently. However, when they're loaded at the same time they >communicate. Having a third module _just_ to work out how the devices >are related (based on PCI bus topology) and transfer the right words >seems ugly. What we really need is a weak external reference which is supported by the linker for built in objects and by modutils at load time. Then we can get rid of run time symbol lookups, get_module_symbol() is an abomination, especially with versioned symbols. WEAK_EXTERN(agp_free_memory); void (*free_memory)(agp_memory *) = _free_memory; if (free_memory) (free_memory)(some_memory); Nice and clean. WEAK_EXTERN does some magic to create a NULL pointer at link time or load time if the symbol is not resolved. Linus, do you want a patch for this? - 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: test10-pre4 fails compile on x25.h
Date:Wed, 18 Oct 2000 20:13:17 -0400 (EDT) From: "Robert M. Love" <[EMAIL PROTECTED]> with this, the file failed to compile -- the kernel compiles fine with it added back. Are you sure you didn't mis-patch your tree? There is only one line in the include you say needs to be added back, it is a declaration for a function. That function was removed in a set of changes, so I cannot see how this include line can make any difference in whether the tree builds are not. Even if the declaration from the header file is there, the function no longer exists in the tree and nothing should reference it anymore :-) Here try this from your linux/ tree; bash$ egrep x25_proto_init `find . -type f -name "*.[ch]"` If that command prints anything, you have mis-patched your tree when going to test10-pre4. BTW, you could have eliminated some of the mystery by showing the exact errors that occur due to this problem you see. :-) 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: test10-pre4 fails compile on x25.h
On Wed, 18 Oct 2000, Robert M. Love wrote: > for file include/net/x25.h, test10-pre4 contains this patch: > with this, the file failed to compile -- the kernel compiles fine with it > added back. i wrote too fast -- while there is a problem with x25 in the current kernel, it may not be the line removing the include. instead, why is x25 being compiled for me? CONFIG_X25 is not set. should anything be adding X.25 support for me? i dont think so ... so it is probably a make issue. ill grep the test10-pre4 and see if anything changed ... -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
John Levon wrote: > should get_module_symbol() die ? Please no. I use it for a situation where two drivers can be used independently. However, when they're loaded at the same time they communicate. Having a third module _just_ to work out how the devices are related (based on PCI bus topology) and transfer the right words seems ugly. -- Jamie - 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: bind() allowed to non-local addresses
David S. Miller wrote: > How about first finding out why their buggy JRE detects whether an > address is local by trying to bind() to it :-) I don't know why the JRE does it, but I've seen that sort of thing used to decide whether to try X shared memory. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8, usb, unresolved symbols
On Wed, 18 Oct 2000 13:47:40 -0700, Randy Dunlap <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >> +obj-$(CONFIG_USB) += usbcore.o usb.o > >We still need your help. Using this usb/Makefile change gives >me errors on all (?) exported symbols when I try to build all >of USB into the kernel. Example (one of many): > >usbcore.o: In function `usb_set_address': >usbcore.o(.text+0x1b90): multiple definition of `usb_set_address' >usb.o(.text+0x1b90): first defined here Remove usb.o from the list of objects that make up usbcore. - 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: __bad_udelay() is not included in 2.2.18-pre16
> e100.o is network module provided by Intel. I used version 1.3.14. The > second nin_cs.o is for PCMCIA-CS SCSI card. It's located in > ftp://projects.sourceforge.net/pub/pcmcia-cs/contrib/NinjaSCSI3-1.0.2.tar.gz. Ask the authors of those modules to use mdelay() which does millisecond level delays and allows arbitary large values - 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: CDROMPLAYTRKIND in 2.4.X
On Tue, Oct 17 2000, Thomas Molina wrote: > > On Tue, Oct 17 2000, Thomas Molina wrote: > > > CD Recording seems to work correctly under 2.4.0-test10-pre3. I'm using > > > cdrecord 1.9 with a Phillips CDD3610. However, playing back an audio cd > > > using cdp gives the following error: > > > > > > sr0: CDROM (ioctl) reports ILLEGAL REQUEST. > > > CDROMPLAYTRKIND: Operation not supported > > > > cd app players can't use CDROMPLAYTRKIND and expect it to always work. > > It will fail on most setups with ide-scsi > > Admittedly I can't remember the last time I used cdp, but this seems > like a recent problem. Are we going to look for a workaround? I've > tried a number of player apps and they all appear to fail in the same > way. > > Judging from past history I'd say the users are going to be told to bug > the app maintainers to tell them it's broken Jim. It always comes out > sounding a bit harsh. ide-scsi should probably just convert playtrkin to play_audio_10 or play_audio_msf -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
> Assuming that my "compatibility argument" is not considered valid. What > I really need is some good ammunition for going back to Sun to ask them > to change the JRE spec -- like some significant kernel features or Linux > applications that relies on this new bind() behavior. The XNS specification seems loose enough to allow the Linux behaviour. I don't think we should however adopt it as default behaviour. Programs that dont care about addresses use INADDR_ANY. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
Date:Wed, 18 Oct 2000 17:20:22 -0600 From: Matt Peterson <[EMAIL PROTECTED]> Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. How about first finding out why their buggy JRE detects whether an address is local by trying to bind() to it :-) Really, when an application feeds a specific address into bind() it must have good reason for selecting it. All I want to know in this specific instance, is why Sun's JRE is sending non-local addresses into bind(), that's all. 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: bind() allowed to non-local addresses
On Wed, Oct 18, 2000 at 05:20:22PM -0600, Matt Peterson wrote: > Your argument for supporting dynamic interfaces is valid, I really like > the idea of being able to bind to an interface that is not up yet. I can > definitely see where this would be helpful -- too bad is is not part of > the spec. What I don't like about it is that it may break existing > applications. Is the Socket spec so loose that Linux 2.4 can be > comfortable in its current condition? I hope not. > > Since it is possible that this "bug" un-repairably breaks the > portability of our application (a Java virtual machine) to the new > kernel, I suspect that there may be other applications that it breaks > too. Could you explain how the JVM breaks exactly ? -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: bind() allowed to non-local addresses
[EMAIL PROTECTED] wrote: > > Hello! > > > Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local > > address. The correct behavior should be a return code of -1 with errno > > set to EADDRNOTAVAIL. > > You can bind to any address, it is your right. You will not able > to receive on or to send from such socket until address will become > really local. > > Such bind is allowed because the address can be dynamic. > Nobody wants that a service did not start only because > the moment of start address was temporarily off-line. > > Alexey This issue here is mostly one of compatibility and standards compliance. You may not be able to obtain the Posix draft P1003.1g but you should be able to see XNS Issue 5.2 which defines the industry-standard Open Systems interfaces to communications services (including Sockets). You might be required to supply name and email address to see the free online copy: http://www.opengroup.org/onlinepubs/009619199/bind.htm#tagcjh_03_03 According to the specs and numerous implementations, looks like the way bind() is supposed to work is that it returns EADDRNOTAVAIL if the specified address is not available from the local machine rather than waiting for a recv() or send() to fail. Many developers working on software ports have felt the pain of loose interpretations of the Sockets interface. This divergence would add yet another headache. Your argument for supporting dynamic interfaces is valid, I really like the idea of being able to bind to an interface that is not up yet. I can definitely see where this would be helpful -- too bad is is not part of the spec. What I don't like about it is that it may break existing applications. Is the Socket spec so loose that Linux 2.4 can be comfortable in its current condition? I hope not. Since it is possible that this "bug" un-repairably breaks the portability of our application (a Java virtual machine) to the new kernel, I suspect that there may be other applications that it breaks too. Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. -- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc [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: Clear interrupts on a SMP machine?
Hello, I am still not sure why you cannot use an IPI for this... on the CPU that you want to access this resource, send an IPI to all other CPUs, and add code in handling that IPI that they should spin and wait till you are done with accessing the chip... then let the other CPUs continue. Best Wishes, Lyle On Wed, 18 Oct 2000, Alan Cox wrote: > > spin_lock_irqsave(_lock, flags); > > Muck_With_The_RTC_Chip(); > > spin_unlock_irqrestore(_lock, flags); > > > This protects only the local procedure. In the meantime, somebody > > else, using another CPU is mucking with the same RTC Chip. The > >You need to put the spinlock in for every other use of the chip > I can't control somebody else's use of `hwclock` or even some future kernel module. > > the data register. The "somebody else" is a realtime-clock ISR. > >Thata fine. You can compute worst case accesses for your Muck_with_.. > >Alan > Hmmm. Care to explain? What I am expected to do is to make a log entry showing the time at which a system crashed (if it crashed). The log entry must be time-stamped within one second of the crash time. This is so the customer can correlate this event with some other events such as a power failure, etc. This seems 'impossible' but it's not. Even though the machine is dead (power is lost), it can retain information that will allow the previously described specification to be met. What I do is have a daemon which wakes up at 1 second intervals and writes 'time_t' to a spare group of CMOS registers and then re-checksums the CMOS. If the normal shutdown occurs, this value is set to 0L and the CMOS is re-checksummed. Access to the realtime clock is made through an installed module driver with appropriate locking. Upon startup, the system time is set to the stored CMOS time value if it is non-zero. The appropriate log entries are made, then the system time is set to the real CMOS clock time before the usual startup log entries are made. So, even though the crash occurred several days ago (the system crashed on a weekend), the log entries show, within a second, the time at which the actual crash occurred. It is 'impressive' to hit the power switch of a server and, upon reboot, see the actual time at which the power was lost in a log file. Oct 12 10:35:29 chaos monitor[11]: Power failure This all runs fine except when a SMP machine is used that has the RTC interrupt enabled for time-keeping. Since I can't control all the applications that a user might run on this server, I need to disable all access to that chip during the time that I am using it. Currently, I cache any contents of command and status register 'B', disable any periodic interrupt, do my thing, then put it back. However, although this 'seems' to work, there is still room for a race because these things can't be done simultaneously. What I really need is a way of (effectively) disabling all interrupts. I note that the common interrupt code could (but does not) contain a semaphore that could be used to cause a spin when some driver needs all interrupts disabled. This might be very useful for problems like this. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ _ 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/
TLB, page table, and sound
Hello Developers Please help me get my head around this. The newer PCI sound cards like the EMU10K1 use page tables and a translation lookaside buffer to convert virtual to physical addresses. I think understand why this is done and the generalities of how but do not understand the specifics related to the actual programming. The page table is supposed to be in system memory and contain the physical address of each 4KB page within virtual memory. Questions: (1) How do I create these page tables? (2) I imagine there are registers controlling the TLB. What usually needs to be done in these registers? (3) Once created, how are these page tables and TLBs used? (4) Is there anything I can read to get smart on these specific problems (besides the source for the EMU10K1 driver)? Thanks, Daniel Sheltraw _ 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: atm_devs protection.
Mitchell Blank Jr wrote: > Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc > open/close) code is pretty suspect. That's actually a bit of an understatement: device removal and module unloading it were never really meant to work :-) About the only thing that might be okay right now is destruction of an atmtcp device ... - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - 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: __bad_udelay() is not included in 2.2.18-pre16
Hi, ALL. > > I tested kernel 2.2.18-pre16. And include/asm-i386/delay.h is modified > > from 2.2.17. Some non generous kernel modules use udelay() function in > > its file. But, The function __bad_udelay in delay.h is referred but > > any instance does not exist. So it's caused Unresolved Symbol problem. > > This is a trap to catch modules using overlarge delays. What modules have the > problem ? I confirmed two modules. [dyky@kyasca ~]$ sudo /sbin/depmod -a depmod: *** Unresolved symbols in /lib/modules/2.2.18-0.01601fb/misc/e100.o depmod: *** Unresolved symbols in /lib/modules/2.2.18-0.01601fb/pcmcia/nin_cs.o e100.o is network module provided by Intel. I used version 1.3.14. The second nin_cs.o is for PCMCIA-CS SCSI card. It's located in ftp://projects.sourceforge.net/pub/pcmcia-cs/contrib/NinjaSCSI3-1.0.2.tar.gz. Regards Daiki Matsuda - 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/
test10-pre4
Ok, more of the "lots of small fixes" patches. The most notable of which is probably the atomic PTE patches by Ben LaHaise, which fixes the long-standing lost dirty bits problem under SMP, and also cleans up some of the ia32 PAE mode issues. The other noticeable one is the undefined C code thing - we've all seen the discussion, and this basically has the raw patch. I expect maintainers who care about how this is done will send me their versions of the safe code - most probably don't care that much, but judging by the discussion some certainly care a LOT ;) Linus - pre4: - disable writing to /proc/xxx/mem. Sure, it works now, but it's still a security risk. - IDE driver update (Victroy66 SouthBridge support) - i810 rng driver cleanup - fix sbus Makefile - named initializers in module.. - ppoe: remove explicit initializer - it's done with initcalls. - x86 WP bit detection: do it cleanly with exception handling - Arnaldo Carvalho de Melo: memory leaks in drivers/media/video - Bartlomiej Zolnierkiewicz: video init functions get __init - David Miller: get rid of net/protocols.c - they get to initialize themselves - David Miller: get rid of dev_mc_lock - we hold dev->xmit_lock anyway. - Geert Uytterhoeven: Zorro (Amiga) bus support update - David Miller: work around gcc-2.7.2 bug - Geert Uytterhoeven: mark struct consw's "const". - Jeff Garzik: network driver cleanups, ns558 joystick driver oops fix - Tigran Aivazian: clean up __alloc_pages(), kill_super() and notify_change() - Tigran Aivazian: move stuff from .data to .bss - Jeff Garzik: divert.h typename cleanups - James Simmons: mdacon using spinlocks - Tigran Aivazian: fix BFS free block calculation - David Miller: sparc32 works again - Bernd Schmidt: fix undefined C code (set/use without a sequence point) - Mikael Pettersson: nicer Pentium IV setup handling. - Georg Acher: usb-uhci cpia oops fix - Kanoj Sarcar: more node_data cleanups for [non]NUMA. - Richard Henderson: alpha update to new vmalloc setup - Ben LaHaise: atomic pte updates (don't lose dirty bit) - David Brownell: ohci memory debugging (== use separate slabs for allocation) - pre3: - update email address of Joerg Reuter - Andries Brouwer: spelling fixes, missing atari brelse(), breada() fix - Geert Uytterhoeven: used named initializers for "struct console". - Carsten Paeth: ISDN capifs - iput() only once. - Petr Vandrovec: VFAT short name generation fix - Jeff Garzik: i810_rng cleanup, and i815 chipset added. - Bartlomiej Zolnierkiewicz: clean up some remaining old-style Makefiles - Dave Jones: x86 setup fixes (recognize Pentium IV etc). - x86: do the "fast A20" setup too in setup.S - NIIBE Yutaka: update SuperH for the global page table (vmalloc) change. - David Miller: sparc updates (vmalloc stuff still pending) - David Miller: CodaFS warnings and 64-bit warnings in pci_size() - David Miller: pcnet32 - correct NULL test - David Miller: vmlist lock -> page_table_lock clarification - Trond Myklebust: Ouch. rpcauth_lookup_credcache() memory corruption bug - Matthew Wilcox: file locking cleanups - David Woodhouse: USB audio spinlock fixes - Torben Mathiasen: tlan driver cleanups - Randy Dunlap: Yenta: CACHE_LINE_SIZE is in dwords, not bytes. - Randy Dunlap: more USB updates - Kanoj Sarcar: clean up the NUMA interfaces (pg_data instead of nodes) - "save_fpu()" was broken. Need to clear pending errors: save_init_fpu(). - pre2: - remember to change the kernel version ;) - isapnp.txt bugfix - ia64 update - sparc update - networking update (pppoe init, frame diverter, fix tcp_sendmsg, fix udp_recvmsg). - Compile for WinChip must _not_ use "-march=i686". It's a i586. - Randy Dunlap: more USB updates - clarify the Firewire AIC-5800 situation. It's not supported yet. - PCI-space decode size fix. This is needed for some (broken?) hardware - /proc/self/maps off-by-one error - 3c501, 3c507, cs89x0 network drivers drop unnecessary check_region - Asahi Kasei AK4540: new codec ID. Yamaha: new PCI ID's. - ne2k-pci net driver documentation update - Paul Gortmaker: delete paranoia check in rtc_exit - scsi_merge: memset the right amount of memory. - sun3fb: old __initfunc() not supported any more. - synclink: remove unnecessary task state games - xd.c: proper casting for 64-bit architectures - vmalloc: page table update race condition. - pre1: - Roger Larsson: ">=" instead of ">" to make the VM not get stuck. - Gideon Glass: brw_kiovec() failure case oops fix - Rik van Riel: better memory balancing and OOM killer - Ivan Kokshaysky: alpha compile fixes - Vojtech Pavlik: forgotten ENOUGH macro in via82cxxx ide driver - Arnaldo Carvalho de Melo: acpi resource leak fix -
Re: __bad_udelay() is not included in 2.2.18-pre16
Hi, ALL. > > I tested kernel 2.2.18-pre16. And include/asm-i386/delay.h is modified > > from 2.2.17. Some non generous kernel modules use udelay() function in > > its file. But, The function __bad_udelay in delay.h is referred but > > any instance does not exist. So it's caused Unresolved Symbol problem. > > This is a trap to catch modules using overlarge delays. What modules have the > problem ? I confirmed two modules. [dyky@kyasca ~]$ sudo /sbin/depmod -a depmod: *** Unresolved symbols in /lib/modules/2.2.18-0.01601fb/misc/e100.o depmod: *** Unresolved symbols in /lib/modules/2.2.18-0.01601fb/pcmcia/nin_cs.o e100.o is network module provided by Intel. I used version 1.3.14. The second nin_cs.o is for PCMCIA-CS SCSI card. It's located in ftp://projects.sourceforge.net/pub/pcmcia-cs/contrib/NinjaSCSI3-1.0.2.tar.gz. Regards Daiki Matsuda - 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: use of add_interrupt_randomness in drivers missing in many drivers
> > On Wed, Oct 18, 2000 at 05:20:43PM +0100, Alan Cox wrote: > > > The only thing needed is to add the SA_SAMPLE_RANDOM flag to request_irq > > > in the drivers. > > > > > > If nobody objects, I'll submit a patch that adds this to network drivers. > > > > Network timing is controllable remotely > > Read Bruce Schneier's paper on the design of the Yarrow PRNG. You *can* use > network timings as an entropy source if your PRNG is designed to prevent a > source from being able to effect a compromise. > > Mordy > > > > > Alan > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > - > 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: __bad_udelay() is not included in 2.2.18-pre16
> I tested kernel 2.2.18-pre16. And include/asm-i386/delay.h is modified > from 2.2.17. Some non generous kernel modules use udelay() function in > its file. But, The function __bad_udelay in delay.h is referred but > any instance does not exist. So it's caused Unresolved Symbol problem. This is a trap to catch modules using overlarge delays. What modules have the problem ? - 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/
__bad_udelay() is not included in 2.2.18-pre16
Hi, ALL. I tested kernel 2.2.18-pre16. And include/asm-i386/delay.h is modified from 2.2.17. Some non generous kernel modules use udelay() function in its file. But, The function __bad_udelay in delay.h is referred but any instance does not exist. So it's caused Unresolved Symbol problem. Regards Daiki Matsuda - 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, spin-locks for CMOS access under SMP
On Wed, 18 Oct 2000, David Woodhouse wrote: > On Wed, 18 Oct 2000, Richard B. Johnson wrote: > > > > > This puts CMOS Chip access under a spin-lock and exports the > > rtc_lock symbol. It is for 2.2.17, should patch to 2.2.18. > > Nice. You've managed to find places we haven't yet fixed it in 2.4 either > :) Yes. There were a few sneaky places that the CMOS was accessed. There are probably a few still hidden. Of course, some were "who cares", but once I defined some keyboard macros, I figured I'd use them while I had them. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch, spin-locks for CMOS access under SMP
On Wed, 18 Oct 2000, Richard B. Johnson wrote: > > This puts CMOS Chip access under a spin-lock and exports the > rtc_lock symbol. It is for 2.2.17, should patch to 2.2.18. Nice. You've managed to find places we haven't yet fixed it in 2.4 either :) -- dwmw2 - 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] fixes to Pentium IV detection in test10-pre3
Here's a patch which should improve Pentium IV support in test10-pre.
The test10-pre3 patch detects Pentium IV (family code 15) but resets
boot_cpu_data.x86 to 6 in this case.
The advantage of doing this is that the places in the kernel which
construct cpu family names (i386 .. i686) still work: the Pentium IV
will be announced as an i686. (Inaccurate, but who cares? These
names are meaningless anyway. Why should a K7 be i686?)
The BIG disadvantage is that low-level cpu-specific drivers break if
boot_cpu_data.x86 doesn't equal the family code returned by CPUID.
The patch contains the following fixes/changes:
* arch/i386/kernel/microcode.c:
- make check for Intel P6 family be strict
* arch/i386/kernel/setup.c:
- (Pentium IV) remove broken "c->x86 = 6;" assignment, so c->x86
remains == 15
- (Pentium IV) don't goto name_decoded, return instead; otherwise
the name grabbed from the extended cpuid levels will be clobbered
- print cpu family as integer not char in /proc/cpuinfo
* include/asm-i386/bugs.h:
- the test for K6 B-step chips was missing a test for family==5
- init of system_utsname.machine maps family codes > 6 to 6;
if anyone can suggest a better naming scheme for newer cpus
like P4 and the Itanium's embedded PentiumIII let me know.
* include/asm-i386/elf.h:
- same fix as in the system_utsname.machine init code
Alan wrote:
> What about the other proc stuff. This will report a 1586, type 15 cpu and
2.2? I looked carefully through 2.4 and fixed all places I found where
"1586" or "?86" ('?' == '0'+15) could have been constructed.
setup.c's print_cpu_info() is safe since x86_model_id was set from the
extended cpuid levels data.
/Mikael
--- linux-2.4.0-test10-pre3/arch/i386/kernel/microcode.c.~1~Sat Sep 9 12:49:37
2000
+++ linux-2.4.0-test10-pre3/arch/i386/kernel/microcode.cTue Oct 17 20:18:07
+2000
@@ -177,7 +177,7 @@
req->err = 1; /* assume the worst */
- if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 < 6){
+ if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 != 6){
printk(KERN_ERR "microcode: CPU%d not an Intel P6\n", cpu_num);
return;
}
--- linux-2.4.0-test10-pre3/arch/i386/kernel/setup.c.~1~Mon Oct 16 17:29:05
2000
+++ linux-2.4.0-test10-pre3/arch/i386/kernel/setup.cWed Oct 18 22:36:26 2000
@@ -1548,9 +1548,8 @@
/* Pentium IV. */
if (c->x86 == 15) {
- c->x86 = 6;
get_model_name(c);
- goto name_decoded;
+ return;
}
/* Names for the Pentium II/Celeron processors
@@ -1689,12 +1688,12 @@
#endif
p += sprintf(p,"processor\t: %d\n"
"vendor_id\t: %s\n"
- "cpu family\t: %c\n"
+ "cpu family\t: %d\n"
"model\t\t: %d\n"
"model name\t: %s\n",
n,
c->x86_vendor_id[0] ? c->x86_vendor_id : "unknown",
- c->x86 + '0',
+ c->x86,
c->x86_model,
c->x86_model_id[0] ? c->x86_model_id : "unknown");
--- linux-2.4.0-test10-pre3/include/asm-i386/bugs.h.~1~ Sat Sep 9 12:49:40 2000
+++ linux-2.4.0-test10-pre3/include/asm-i386/bugs.h Wed Oct 18 22:22:19 2000
@@ -166,6 +166,7 @@
static void __init check_amd_k6(void)
{
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+ boot_cpu_data.x86 == 5 &&
boot_cpu_data.x86_model == 6 &&
boot_cpu_data.x86_mask == 1)
{
@@ -426,5 +427,5 @@
check_pentium_f00f();
#endif
check_cyrix_coma();
- system_utsname.machine[1] = '0' + boot_cpu_data.x86;
+ system_utsname.machine[1] = '0' + (boot_cpu_data.x86 > 6 ? 6 :
+boot_cpu_data.x86);
}
--- linux-2.4.0-test10-pre3/include/asm-i386/elf.h.~1~ Fri Jul 14 18:22:10 2000
+++ linux-2.4.0-test10-pre3/include/asm-i386/elf.h Wed Oct 18 22:17:06 2000
@@ -93,7 +93,7 @@
For the moment, we have only optimizations for the Intel generations,
but that could change... */
-#define ELF_PLATFORM ("i386\0i486\0i586\0i686"+((boot_cpu_data.x86-3)*5))
+#define ELF_PLATFORM
+("i386\0i486\0i586\0i686"+(((boot_cpu_data.x86>6?6:boot_cpu_data.x86)-3)*5))
#ifdef __KERNEL__
#define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)
-
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: use of add_interrupt_randomness in drivers missing in many drivers
Horst von Brand wrote: >Adding stuff that adds no entropy (or at least doesn't add to the estimated >entropy pool) is just a waste of effort, AFAIKS. Adding stuff that has no entropy is a waste of effort. Adding stuff that probably has entropy, but where you don't bump the entropy counter, *does* add value. The entropy counter is a conservative estimate of how much entropy you can safely rely on being present. It's still useful to add more entropy to the pool -- even if it's not reflected in the counter -- because it reduces the chances of a catastrophic randomness failure. (What if you over-estimated, or if one of your sources failed and became predictable, e.g., because the attacker started jamming your GPS from a van parked outside your building?) It pays to be (prudently) paranoid, in this business. - 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: three kernel trees?
Horst von Brand wrote: > FORT David <[EMAIL PROTECTED]> said: > > Horst von Brand wrote: > > [...] > > > > Dream on, as it won't happen. Just think of either: > > > > > > - All pieces _have_ to be the same version: What is the use then? Just ship > > > them together and be done. Splitting it up is extra work, plus the > > > complaints that core-2.8.3 now doesn't work with ia32-2.6.9 and foo, bar, > > > baz drivers of assorted other versions. > > > - You can mix and match: Great! Just who will do the testing and documentatio > > n > > > of what works with what? > > > > > > Major pain and much extra work to developers (remember, Linux' objective is > > > being fun to hack on, the "World domination. Fast." thing is just FUD ;) > > > for minor convenience to some users and major pain to all the rest. > > > Isn't it what API have been made for? > > Yes. But the API isn't set in stone, as that would slow down > development. Plus you need the machinery to build whatever pieces are > extant and ignore the rest, you have to carve up the whole into separate > pieces, ... This is a *lot* of work for very minimal gain and many future > problems. > > >I think nobody would complain if > > "being fun to hack on(TM)" could also be "Fast developped(TM)". > > I don't see how chopping up the kernel will speed up development. Quite to > the contrary, any change has to be propagated to all pieces, and that will > take more time, and create a nightmare of "drivers bar-0.37.2 to 0.39.6 go > with kernel-core 2.9.45 to 2.9.76, but work only with foo-3.65.x". > Syncronization issues arise by the distributed development, which are now > trivially solved by "this is _the_ official version of _all_ there is". > I don't think API are changing so much, and documenting the way drivers SHOULD interact with the kernel is a good thing. This also make things easier for people to write new drivers. You'd also agree that as time will go by, we'll have more and more drivers, and we'll have to wait for ALL to be stable to release anything. > > > Anyway > > the developpement of the kernel is already modular, as teams are working > > quite independantly, and send theirs diff when a release is about to > > come. > > *Very* bad practice, I may add. Anybody wanting to create something with a certain size proceed this way. > > > > I take a simple example: i got an USB webcam which stopped working > > at test9-pre2, I'd like to have a 2.4.0test10-pre3 kernel but with the > > last working USB. > > So what? 2.4.0-test is experimental, you can't assume stuff will work at > all. This is not just "drop working 2.4.0-test9 into > 2.4.0-test10-pre3", if it broke there is a reason that makes it not work > anymore. I tend to doubt the USB people submmited a patch to break > it... When 2.4.0 ships, everything should work; then you can complain. But > to get there, folks _must_ make an effort to fold the latest working, > tested patches into the kernel ASAP. Then again, they are all volunteers... > When developping a part of the kernel, developpers may wish to focus to that particulary part, without caring about other bugs.. -- %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France[EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--LINUX-HTTPD-PIOGENE% % -datamining <-/| .~. % % -networking/flashed PHP3 coming soon | /V\L I N U X% % -opensource| // \\ >Fear the Penguin< % % -GNOME/enlightenment/GIMP | /( )\ % % feel enlighted| ^^-^^% % http://ibonneace.dnsalias.org/ when connected % %-% - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
> The only other users are 8390.h and a couple of mtd things. I don't see > why this stuff cannot be handled in userspace with /etc/modules.conf ... > > should get_module_symbol() die ? You need it to dynamically bind to another module if its loaded and still be loadable if that module/facility is not present. Its dynamic linking for kernel modules - 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: BLKSSZGET change will break fdisk
> "Ralf" == Ralf Baechle <[EMAIL PROTECTED]> writes: Ralf> On Tue, Oct 17, 2000 at 12:53:40AM +0200, Andries Brouwer wrote: >> (By the way, have you checked that replacing get_sectorsize by an >> empty routine, and specifying a -b option, works well?) >> >> (Do you know which disks have unusual sector size? So far I had >> only seen reports on a Fujitsu 640 MB. Have you seen other >> sectorsizes than 512, 1024, 2048 on non-IBM disks?) Ralf> Afair there is some older type of exchangable disk with 256 Ralf> bytes sectors made by Syquest. I also remember SCSI disks that Ralf> can be reformated with 4kb sectors. I used to have an old Seagate 1GB 5 1/4" SCSI disk at CERN which had a 256 byte sector size. It's hopefully in the scrapyard now. Jes - 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: Clear interrupts on a SMP machine?
> [EMAIL PROTECTED] said: > > There is no such exported variable in the 'stable' kernel tree: > > Then there should be, and the RTC accesses in 2.2 are probably racy. > > In which case, feel free to provide Alan with a patch for 2.2.18. Andrea has some bits for this on the current/pending piles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.0-test9-pre8, usb, unresolved symbols
Greg, That's fine with me, especially if it fixes this problem. Go for it. ~Randy ___ |Randy Dunlap | |randy.dunlap_at_intel.com503-696-2055| |NOTE: Any views presented here are mine alone| |& may not represent the views of my employer.| --- > -Original Message- > From: Greg KH [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 18, 2000 1:54 PM > To: Randy Dunlap > Cc: Keith Owens; Claude LeFrancois (LMC); [EMAIL PROTECTED] > Subject: Re: 2.4.0-test9-pre8, usb, unresolved symbols > > > On Wed, Oct 18, 2000 at 01:47:40PM -0700, Randy Dunlap wrote: > > I guess that we could go ahead and merge usb-core.c into usb.c > > if there's no good/simple solution to this. > > I wanted to do that anyway, so I'd recommend it. Especially > if it fixes > this problem. > > Want a patch to do it? > > thanks, > > greg k-h > > -- > greg@(kroah|wirex).com > http://immunix.org/~greg > - 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: use of add_interrupt_randomness in drivers missing in many drivers
[EMAIL PROTECTED] (David Wagner) said: > Jeff Garzik wrote: > >Then you make your local random pool vulnerable to external > >manipulation, to a certain extent... > Adding more bits to the pool should never hurt; the cryptographic > mixing ensures this. What _can_ hurt is adding predictable bits but > (erroneously) bumping up the entropy counter. The problem that was being discussed is not generating enough entropy on certain machines (f.ex. a router running out of RAM: No mouse, no kbd, no disk, ...). > So, if you're not sure whether those bits are unpredictable and random > or not, the right thing to do is to mix 'em into the pool, but don't > bump the entropy counter. The greater your diversity of sources, the > less likely it is that you encounter a catastrophic randomness failure. Adding stuff that adds no entropy (or at least doesn't add to the estimated entropy pool) is just a waste of effort, AFAIKS. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8, usb, unresolved symbols
On Wed, Oct 18, 2000 at 01:47:40PM -0700, Randy Dunlap wrote: > I guess that we could go ahead and merge usb-core.c into usb.c > if there's no good/simple solution to this. I wanted to do that anyway, so I'd recommend it. Especially if it fixes this problem. Want a patch to do it? thanks, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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, spin-locks for CMOS access under SMP
This puts CMOS Chip access under a spin-lock and exports the
rtc_lock symbol. It is for 2.2.17, should patch to 2.2.18.
--- linux-2.2.17/arch/i386/kernel/i386_ksyms.c.orig Wed Oct 18 12:53:42 2000
+++ linux-2.2.17/arch/i386/kernel/i386_ksyms.c Wed Oct 18 12:55:55 2000
@@ -17,7 +17,7 @@
#include
#include
#include
-
+extern spinlock_t rtc_lock;
extern void dump_thread(struct pt_regs *, struct user *);
extern int dump_fpu(elf_fpregset_t *);
@@ -41,7 +41,7 @@
EXPORT_SYMBOL(disable_irq);
EXPORT_SYMBOL(disable_irq_nosync);
EXPORT_SYMBOL(kernel_thread);
-
+EXPORT_SYMBOL(rtc_lock);
EXPORT_SYMBOL(init_mm);
EXPORT_SYMBOL_NOVERS(__down_failed);
--- linux-2.2.17/arch/i386/kernel/time.c.orig Wed Jun 7 17:26:42 2000
+++ linux-2.2.17/arch/i386/kernel/time.cWed Oct 18 13:27:24 2000
@@ -28,6 +28,8 @@
* 1998-12-24 Copyright (C) 1998 Andrea Arcangeli
* Fixed a xtime SMP race (we need the xtime_lock rw spinlock to
* serialize accesses to xtime/lost_ticks).
+ * 2000-10-17 [EMAIL PROTECTED]
+ * Spin-lock added to RTC code and spin-lock exported.
*/
#include
@@ -294,13 +296,19 @@
*
* BUG: This routine does not handle hour overflow properly; it just
* sets the minutes. Usually you'll only notice that after reboot!
+ *
*/
+
+spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
+
static int set_rtc_mmss(unsigned long nowtime)
{
+ unsigned long flags;
int retval = 0;
int real_seconds, real_minutes, cmos_minutes;
unsigned char save_control, save_freq_select;
+ spin_lock_irqsave(_lock, flags);
save_control = CMOS_READ(RTC_CONTROL); /* tell the clock it's being set */
CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
@@ -346,7 +354,7 @@
*/
CMOS_WRITE(save_control, RTC_CONTROL);
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
-
+ spin_unlock_irqrestore(_lock, flags);
return retval;
}
@@ -496,9 +504,12 @@
/* not static: needed by APM */
unsigned long get_cmos_time(void)
{
+ unsigned long flags;
unsigned int year, mon, day, hour, min, sec;
int i;
+ spin_lock_irqsave(_lock, flags);
+
/* The Linux interpretation of the CMOS clock register contents:
* When the Update-In-Progress (UIP) flag goes from 1 to 0, the
* RTC registers show the second which has precisely just started.
@@ -528,6 +539,7 @@
BCD_TO_BIN(mon);
BCD_TO_BIN(year);
}
+ spin_unlock_irqrestore(_lock, flags);
if ((year += 1900) < 1970)
year += 100;
return mktime(year, mon, day, hour, min, sec);
--- linux-2.2.17/drivers/block/hd.c.origWed Oct 18 15:28:18 2000
+++ linux-2.2.17/drivers/block/hd.c Wed Oct 18 16:36:11 2000
@@ -21,6 +21,8 @@
* Removed 99% of above. Use Mark's ide driver for those options.
* This is now a lightweight ST-506 driver. (Paul Gortmaker)
*
+ * 17-OCT-2000 [EMAIL PROTECTED] Added spin-lock for reading
+ * CMOS chip.
*/
/* Uncomment the following if you want verbose error reports. */
@@ -48,7 +50,7 @@
#define MAJOR_NR HD_MAJOR
#include
-
+extern spinlock_t rtc_lock;
static int revalidate_hddisk(kdev_t, int);
#defineHD_DELAY0
@@ -701,6 +703,7 @@
static void hd_geninit(struct gendisk *ignored)
{
int drive;
+ unsigned long flags;
#ifdef __i386__
if (!NR_HD) {
@@ -743,13 +746,14 @@
*/
-
+spin_lock_irqsave(_lock, flags);
if ((cmos_disks = CMOS_READ(0x12)) & 0xf0) {
if (cmos_disks & 0x0f)
NR_HD = 2;
else
NR_HD = 1;
}
+ spin_unlock_irqrestore(_lock, flags);
}
#endif /* __i386__ */
for (drive=0 ; drive < NR_HD ; drive++) {
--- linux-2.2.17/drivers/block/ide-probe.c.orig Wed Oct 18 15:38:05 2000
+++ linux-2.2.17/drivers/block/ide-probe.c Wed Oct 18 16:37:33 2000
@@ -18,6 +18,8 @@
* by Andrea Arcangeli
* Version 1.03fix for (hwif->chipset == ide_4drives)
* Version 1.04fixed buggy treatments of known flash memory cards
+ * 17-OCT-2000 [EMAIL PROTECTED] Added spin-locks for reading CMOS
+ * chip.
*/
#undef REALLY_SLOW_IO /* most systems can safely undef this */
@@ -41,6 +43,8 @@
#include
#include
+extern spinlock_t rtc_lock;
+
#include "ide.h"
static inline void do_identify (ide_drive_t *drive, byte cmd)
@@ -386,6 +390,7 @@
static void probe_cmos_for_drives (ide_hwif_t *hwif)
{
#ifdef __i386__
+ unsigned long flags;
extern struct drive_info_struct drive_info;
byte cmos_disks, *BIOS = (byte *) _info;
int unit;
@@ -394,8 +399,10 @@
if (hwif->chipset == ide_pdc4030 && hwif->channel != 0)
return;
#endif /* CONFIG_BLK_DEV_PDC4030 */
+
Re: 2.4.0-test9-pre8, usb, unresolved symbols
Keith Owens wrote: > > Objects that export symbols must be explicitly listed before the > calculation of OX_OBJS. usb.o is not explicitly listed as an object, > it is implicitly included via the link of usbcore. > > Index: 0-test10-pre3.1/drivers/usb/Makefile > --- 0-test10-pre3.1/drivers/usb/Makefile Mon, 02 Oct 2000 15:28:44 +1100 > kaos (linux-2.4/n/b/19_Makefile 1.1.1.10 644) > +++ 0-test10-pre3.1(w)/drivers/usb/Makefile Wed, 18 Oct 2000 13:17:59 > +1100 kaos (linux-2.4/n/b/19_Makefile 1.1.1.10 644) > @@ -38,7 +38,7 @@ obj- := > > # Each configuration option enables a list of files. > > -obj-$(CONFIG_USB) += usbcore.o > +obj-$(CONFIG_USB) += usbcore.o usb.o > obj-$(CONFIG_USB_UHCI) += usb-uhci.o > obj-$(CONFIG_USB_UHCI_ALT) += uhci.o > obj-$(CONFIG_USB_OHCI) += usb-ohci.o Keith- We still need your help. Using this usb/Makefile change gives me errors on all (?) exported symbols when I try to build all of USB into the kernel. Example (one of many): usbcore.o: In function `usb_set_address': usbcore.o(.text+0x1b90): multiple definition of `usb_set_address' usb.o(.text+0x1b90): first defined here I guess that we could go ahead and merge usb-core.c into usb.c if there's no good/simple solution to this. 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: three kernel trees?
On Tue, Oct 17, 2000 at 06:13:34PM -0600, Jeff V. Merkey wrote: > Kenneth Johansson wrote: > > "Jeff V. Merkey" wrote: > > > This does not solve the problem of integration testing, but eh solution > > > here is to create an integration test group whose sole charter is to > > > test modules in an integrated framework as they roll off the assembly > > > line. I am speaking from my commercial software development experienes > > > > Good luck finding anyone doing this job. It's hard to make people write > > documentation this is going to be impossible. This is a solution that works if you > > can pay people but I don't think it's going to work when volunteers is doing it. > > Well. It gets done today, so who is doing this today? To what extent? Integration testing with as much hardware as possible? The community as a whole does that. Automated integration testing? Please step forward for recognition if you are. Automated functional testing of the kernel? Yes, SGI is working on that. We still have a lot of work to do to get reasonable coverage, but we do have employees testing Linux. We have released some tests and a simple test driver under the Linux Test Project. If anyone has tests they would like to contribute to LTP, please send them to me. I will try to get the tests integrated into an automated system. The way I see it, if we can pull all of the home grown tests out of the wood work, we will have a better testing system than the defacto "build the kernel" system. -- Nate Straz [EMAIL PROTECTED] sgi, inc http://www.sgi.com/ Linux Test Projecthttp://oss.sgi.com/projects/ltp/ - 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: use of add_interrupt_randomness in drivers missing in many drivers
Jeff Garzik wrote: >Then you make your local random pool vulnerable to external >manipulation, to a certain extent... Adding more bits to the pool should never hurt; the cryptographic mixing ensures this. What _can_ hurt is adding predictable bits but (erroneously) bumping up the entropy counter. So, if you're not sure whether those bits are unpredictable and random or not, the right thing to do is to mix 'em into the pool, but don't bump the entropy counter. The greater your diversity of sources, the less likely it is that you encounter a catastrophic randomness failure. - 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: why would you want /proc/sys/net/ipv4/route/min_delay to not be zero?
On Wed, Oct 18, 2000 at 03:55:41PM -0400, Johannes Erdfelt wrote: > On Wed, Oct 18, 2000, Andi Kleen <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 18, 2000 at 03:35:46PM -0400, Christopher Friesen wrote: > > > Now what I'm trying to figure out is why anyone would want this value to > > > NOT be set to zero. When would you not want route flushes and route > > > changes to take immediate effect? > > > > Mostly to avoid total breakdown of a BGP4 router when routes are flapping. > > Isn't that what route dampening is for? The routing daemon would handle > this situation to avoid the total breakdown. The routing subsystem is designed to handle multiple routing daemons. A flush operation is relatively costly, so it is a good idea to do it in longer intervals no matter how the routes are changed (and using an user mode daemon for that would be overkill) -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: why would you want /proc/sys/net/ipv4/route/min_delay to not be zero?
On Wed, Oct 18, 2000, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Wed, Oct 18, 2000 at 03:35:46PM -0400, Christopher Friesen wrote: > > Now what I'm trying to figure out is why anyone would want this value to > > NOT be set to zero. When would you not want route flushes and route > > changes to take immediate effect? > > Mostly to avoid total breakdown of a BGP4 router when routes are flapping. Isn't that what route dampening is for? The routing daemon would handle this situation to avoid the total breakdown. 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: why would you want /proc/sys/net/ipv4/route/min_delay to not be zero?
On Wed, Oct 18, 2000 at 03:35:46PM -0400, Christopher Friesen wrote: > Now what I'm trying to figure out is why anyone would want this value to > NOT be set to zero. When would you not want route flushes and route > changes to take immediate effect? Mostly to avoid total breakdown of a BGP4 router when routes are flapping. -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/
why would you want /proc/sys/net/ipv4/route/min_delay to not be zero?
I figured out why my IP takeover was taking a couple seconds to take effect even though it returned immediately--the /proc/sys/net/ipv4/route/min_delay setting is by default set to 2, giving a 2 second delay before the route cache is updated or flushed. This meant that packets continued to go out the old interface for two seconds, until the route cache was flushed and the new route was used. Now what I'm trying to figure out is why anyone would want this value to NOT be set to zero. When would you not want route flushes and route changes to take immediate effect? Thanks again, Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] khttpd doesn't detach from the files of its parent
On Wed, 18 Oct 2000, Alessandro Rubini wrote: > > > put_files_struct() is a destructor, so it won't help here. The following > > patch may be of use [...] It's "create an empty > > files_struct and replace the task->files with it" - thing we can't do via > > clone() and may want to (khttpd does). > > Sorry, what's wrong with just closing the files? It's much > easier. Really? You copy all references to new files_struct upon clone(), then destroy them on close_files() and you claim that it's easier than clone() with CLONE_FILES (get an extra reference) followed by allocation of new files_struct (as you would do in your variant anyway) and dropping aforementioned reference? - 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: trident sound chip programming
On Wed, 18 Oct 2000, daniel sheltraw wrote: > Does anyone have a contact at Trident or one of the sound card > manufacturers using this chip that could provide the docs I need? Trident has laid off its entire 4dwave engineering team so there is noone left at Trident who knows anything about these chips anymore. The datasheets should be sufficient, or you could simply look at the ALSA source code. -Dan - 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/
trident sound chip programming
Hello kernel developers Does anyone know where I can get more programming info for the Trident 4DWave sound chip? I have obtained the datasheets for the Trident 4DWave NX from the ALSA site but they are not enough for my needs. The ALSA docs give the descriptions of important registers of the device but give no info on what must be done to play a sound and in what order. Does anyone have a contact at Trident or one of the sound card manufacturers using this chip that could provide the docs I need? I am a bit of a newbie at this so any help is appreciated. Thanks for giving us Linux, Daniel Sheltraw _ 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] Make agpsupport work with modversions
On Wed 18 Oct 2000 19:23:54 +0100, David Woodhouse <[EMAIL PROTECTED]> wrote: > Don't you need to deal with the !CONFIG_AGP case correctly? This should already be dealt with in the Makefile -- if !CONFIG_AGP, then the file that we've been talking about (agpsupport.c) isn't compiled. (So, yes, you can still customize a drm module for your specific kernel. But I'm arguing for the ability to build a generic drm module that will determine agpgart presence at run time and use it if needed.) > [EMAIL PROTECTED] said: > > [Note that the other way to fix this would be to export > > get_module_symbol all the time, and have it just search the available > > symbol space if CONFIG_MODULES is 'n'.] > > There is no available symbol space if CONFIG_MODULES is 'n'. Oh :( - 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] khttpd doesn't detach from the files of its parent
> put_files_struct() is a destructor, so it won't help here. The following > patch may be of use [...] It's "create an empty > files_struct and replace the task->files with it" - thing we can't do via > clone() and may want to (khttpd does). Sorry, what's wrong with just closing the files? It's much easier. Instead of my silly 255-to-0 loop, close_files() can be used (by copying to khttpd or by moving to a header. /alessandro - 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: use of add_interrupt_randomness in drivers missing in many drivers
On Wed, 18 Oct 2000, Sandy Harris wrote: > So methinks the questions are whether /dev/random can get one bit of > unknowable-by-the-enemy entropy per packet passing through a gateway > and whether it would estimate entropy sufficiently conservatively in > this case. If both answers are yes, please apply the patch. I'm not sure it is possible to answer this globally, without studying the hardware characteristics of the specific network interfaces involved. > I'd still like to see the patch applied, though. I'd like /dev/random > to work well "out of the box" on the FreeS/WAN gateways people are > building out of older surplus hardware. Agreed... but "out of the box" should mean, as shipped with the Linux distributions. I don't want to get *us* involved in second-guessing the author of /dev/random. The thing to do with the patch is to send it to Ted and ask *him* to put it in. Henry Spencer [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: three kernel trees?
Stephen Tweedie wrote: > > Hi, > > On Tue, Oct 17, 2000 at 03:57:52PM -0600, Jeff V. Merkey wrote: > > > > Were Linux to go totally modular in 2.5, development cycles will be > > reduced by 1/2 to 1/3. This is because you could always roll back to > > known good modules to post a release. > > Most of the big 2.4 module changes involved totally rethinking the > interactions between the modules. If you're changing the APIs between > modules, rolling one back is hard. Well, within reason if that makes sense. Sooner or later we are going to have to bite the bullet on this one, though and sooner is better than later -- we really need to start thinking about it for 2.5. :-) Jeff > > --Stephen > - > 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] Make agpsupport work with modversions
[EMAIL PROTECTED] said: > #ifdef CONFIG_MODULES /* use get_module_symbol() */ > #else /* reference agp_* directly */ > #endif Don't you need to deal with the !CONFIG_AGP case correctly? #ifdef CONFIG_MODULES /* blah */ #elif CONFIG_AGP /* blah */ agp_available = 1; #else agp_available = 0; #endif [EMAIL PROTECTED] said: > [Note that the other way to fix this would be to export > get_module_symbol all the time, and have it just search the available > symbol space if CONFIG_MODULES is 'n'.] There is no available symbol space if CONFIG_MODULES is 'n'. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Wed 18 Oct 2000 10:49:24 -0700, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Wed, 18 Oct 2000, Christoph Hellwig wrote: > > > In article <[EMAIL PROTECTED]> you >wrote: > > > > > I have no idea what the get_module_symbol() code in question is trying to > > > do, but this should be _fixed_ and not just worked around. That's a bug. > > > > It gets the symbol of a function, that's name is passed as char * to > > get_module_symbol(). > > Oh, I know what get_module_symbol() does - I just don't understand why drm > would want to use it. There are basically no good uses for it, as far as > I'm concerned. > > I assume it's something about allowing modules to be loaded in the wrong > order. Some other drivers did hooks like this in times past. The right > solution was then, and is almost certainly now, to just remove the code in > question and force the correct load order. Just to clarify -- my use of get_module_symbol has nothing to do with load order. It has to do with allowing a drm module to work with or without the agpgart module loaded. If there's some other way to do this, I'll be happy to move to that. I'd like to preserve the ability to have one driver which works with each chipset family and not have to have separate drivers for PCI and AGP cards (or, rather, to have fewer instances of the drivers -- they already depend on SMP and MODVERSIONS, and that's a lot of overhead already if you just want to play Q3A :). I'd also like a dual-head system to be able to load the same drm module and just have it work for both the agp and the pci cards (this isn't supported yet, in case anyone is wondering). > Rik? Can this code just go away? See above and my mail from a few minutes ago. I'd like to keep it (with the naming changes John Levon proposed, even if we don't make it available when CONFIG_MODULES is 'n'). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Wed, 18 Oct 2000, Rik Faith wrote: > [Note that the other way to fix this would be to export > get_module_symbol all the time, and have it just search the available > symbol space if CONFIG_MODULES is 'n'.] and s/_module//; it is mis-named already ... john -- "Mathemeticians stand on each other's shoulders while computer scientists stand on each other's toes." - Richard Hamming - 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] khttpd doesn't detach from the files of its parent
On Wed, 18 Oct 2000, Jeff Garzik wrote: > Alexander Viro wrote: > > On Wed, 18 Oct 2000, Alessandro Rubini wrote: > > > > shouldn't this be exit_files() ? > > > > Yes, definitely. > > > Arjan already replied (privately) to say the same. > > > It should, unless you want to open any files in the thread itself. > > If you start a kernel thread which opens files -before- calling > exit_files(), aren't the files opened associated with the wrong process? > > When I was playing around with kernel threads that have their own VM > mappings, I had to do exit_mm() then create_mm(), or something along > those lines. See the patch in another posting. - 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] khttpd doesn't detach from the files of its parent
On Wed, 18 Oct 2000, Arjan van de Ven wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>
> > It should, unless you want to open any files in the thread itself.
>
> Oh damn. kHTTPd does need to open files later on..
>
> Reading the code to exit_files() suggests I actually need put_files_struct()
> instead. Is that function for "public" use? (it isn't static)
put_files_struct() is a destructor, so it won't help here. The following
patch may be of use, though (warning: it's cut-and-paste, so spaces may be
wrong). Linus, what do you think about it? It's "create an empty
files_struct and replace the task->files with it" - thing we can't do via
clone() and may want to (khttpd does).
diff -urN rc10-3-a/include/linux/sched.h rc10-3-b/include/linux/sched.h
--- rc10-3-a/include/linux/sched.h Mon Oct 16 11:44:36 2000
+++ rc10-3-b/include/linux/sched.h Wed Oct 18 17:25:20 2000
@@ -729,6 +729,7 @@
extern void exit_sighand(struct task_struct *);
extern void daemonize(void);
+extern int new_files(struct task_struct *);
extern int do_execve(char *, char **, char **, struct pt_regs *);
extern int do_fork(unsigned long, unsigned long, struct pt_regs *, unsigned long);
diff -urN rc10-3-a/kernel/fork.c rc10-3-b/kernel/fork.c
--- rc10-3-a/kernel/fork.c Tue Sep 12 09:10:59 2000
+++ rc10-3-b/kernel/fork.c Wed Oct 18 17:20:35 2000
@@ -391,6 +391,38 @@
return i;
}
+int new_files(struct task_struct * tsk)
+{
+ struct files_struct *oldf, *newf;
+
+ error = -ENOMEM;
+ newf = kmem_cache_alloc(files_cachep, SLAB_KERNEL);
+ if (!newf)
+ goto out;
+
+ atomic_set(>count, 1);
+
+ newf->file_lock = RW_LOCK_UNLOCKED;
+ newf->next_fd = 0;
+ newf->max_fds = NR_OPEN_DEFAULT;
+ newf->max_fdset = __FD_SETSIZE;
+ newf->close_on_exec = >close_on_exec_init;
+ newf->open_fds = >open_fds_init;
+ newf->fd= >fd_array[0];
+ memset(newf->fds, 0, NR_OPEN_DEFAULT * sizeof(struct file *));
+ memset(newf->open_fds->fds_bits, 0, __FD_SETSIZE/8);
+ memset(newf->close_on_exec->fds_bits, 0, __FD_SETSIZE/8);
+
+ task_lock(tsk);
+ oldf = tsk->files;
+ tsk->files = newf;
+ task_unlock(tsk);
+ put_files_struct(oldf);
+ error = 0;
+out:
+ return error;
+}
+
static int copy_files(unsigned long clone_flags, struct task_struct * tsk)
{
struct files_struct *oldf, *newf;
diff -urN rc10-3-a/kernel/ksyms.c rc10-3-b/kernel/ksyms.c
--- rc10-3-a/kernel/ksyms.c Sun Oct 15 10:05:24 2000
+++ rc10-3-b/kernel/ksyms.c Wed Oct 18 17:25:37 2000
@@ -94,6 +94,7 @@
EXPORT_SYMBOL(exit_files);
EXPORT_SYMBOL(exit_fs);
EXPORT_SYMBOL(exit_sighand);
+EXPORT_SYMBOL(new_files);
/* internal kernel memory management */
EXPORT_SYMBOL(__alloc_pages);
-
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] khttpd doesn't detach from the files of its parent
>> Yes, definitely. > > It should, unless you want to open any files in the thread itself. Yes. I realized that just before getting your message (after looking at kernel/exit.c). I should never say "definitely" :) /alessandro - 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] khttpd doesn't detach from the files of its parent
Alexander Viro wrote: > On Wed, 18 Oct 2000, Alessandro Rubini wrote: > > > shouldn't this be exit_files() ? > > Yes, definitely. > > Arjan already replied (privately) to say the same. > It should, unless you want to open any files in the thread itself. If you start a kernel thread which opens files -before- calling exit_files(), aren't the files opened associated with the wrong process? When I was playing around with kernel threads that have their own VM mappings, I had to do exit_mm() then create_mm(), or something along those lines. Jeff -- Jeff Garzik| The difference between laziness and Building 1024 | prioritization is the end result. MandrakeSoft | - 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: Clear interrupts on a SMP machine?
On Wed, 18 Oct 2000, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > You want to patch /drivers/char/rtc.c ?? If you have a later kernel > > than me, it would be helpful. Just apply my patch than do the rtc.c. > > /me looks at his TODO list. > > Not really. Okay. I'll do it tonight. There are already the non-SMP save/flags/cli pairs. Looks like its easy to do. I just don't like to do something that is already being done. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Wed, 18 Oct 2000, Christoph Hellwig wrote: > In article <[EMAIL PROTECTED]> you >wrote: > > > I have no idea what the get_module_symbol() code in question is trying to > > do, but this should be _fixed_ and not just worked around. That's a bug. > > It gets the symbol of a function, that's name is passed as char * to > get_module_symbol(). Oh, I know what get_module_symbol() does - I just don't understand why drm would want to use it. There are basically no good uses for it, as far as I'm concerned. I assume it's something about allowing modules to be loaded in the wrong order. Some other drivers did hooks like this in times past. The right solution was then, and is almost certainly now, to just remove the code in question and force the correct load order. Rik? Can this code just go away? 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] khttpd doesn't detach from the files of its parent
On Wed, 18 Oct 2000, Alessandro Rubini wrote: > > > shouldn't this be exit_files() ? > > Yes, definitely. > Arjan already replied (privately) to say the same. It should, unless you want to open any files in the thread itself. - 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: Clear interrupts on a SMP machine?
[EMAIL PROTECTED] said: > You want to patch /drivers/char/rtc.c ?? If you have a later kernel > than me, it would be helpful. Just apply my patch than do the rtc.c. /me looks at his TODO list. Not really. -- dwmw2 - 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] khttpd doesn't detach from the files of its parent
> shouldn't this be exit_files() ? Yes, definitely. Arjan already replied (privately) to say the same. Thanks /alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2 generating odd TCP resets?
Well, this seems to be half the story. If I remove the close() and
let server bleed file descriptors, the RST goes away. If I add a
read() on the socket after sending all the data, the RST goes away.
However, there's NO DATA on the socket. read() returns zero until
the client closes the socket.
In the code below, I removed the shutdown() and added the block
after do_scan() to eliminate the RST. The read() never finds any data.
If there's no data pending, why does read() have any affect?
b.c.
fcntl (data_fd, F_SETFL, 1);/* set non-blocking */
/*shutdown (data_fd, 0); */
do_scan (w, h, data_fd);
{
char buff[10];
int i, c;
printf("looking for extra data\n");
while ((c = read(data_fd, buff, 10)) >= 0) {
if (c > 0) {
for (i=0; i
> Most likely reason is that the server calls close() while there is
> still data pending to be read. As TCP is a reliable transport, this
> loss of data causes a RST.
>
> An application bug.
-
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: Clear interrupts on a SMP machine?
On Wed, 18 Oct 2000, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > 2.2.17 should be able to do. > > Cool. drivers/char/rtc.c needs to use it too. Then you need to pester Alan > till he puts it in 2.2.18-pre-de-jour :) > You want to patch /drivers/char/rtc.c ?? If you have a later kernel than me, it would be helpful. Just apply my patch than do the rtc.c. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
proccess hung
Hi All, I have one process hung on my linux smp system (2 processors) running RedHat Linux 7. The command % ps -eo fname,tty,pid,stat,pcpu,nwchan,wchan gives the following information about the command : COMMAND TT PID STAT %CPU WCHAN WCHAN rm tty2 21760R99.8 - - Is there any way to find out why this particular process is hung and where exactly in the kernel is it hanging ? The WCHAN field does not tell me anything. Also, the stat of the process is always runnable and the % CPU is always 99.8. This process is like this since last 2 days. Thanks and regards, -hiren - 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] khttpd doesn't detach from the files of its parent
On Wed, 18 Oct 2000, Alessandro Rubini wrote: > + /* init_module has stdin/stdout/stderr open: close them (ARub) */ > + for (i=255; i>=0; i--) > + if (current->files->fd[i]) > + close(i); > shouldn't this be exit_files() ? see md.c for an example usage ... thanks john -- "Mathemeticians stand on each other's shoulders while computer scientists stand on each other's toes." - Richard Hamming - 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: Clear interrupts on a SMP machine?
[EMAIL PROTECTED] said: > 2.2.17 should be able to do. Cool. drivers/char/rtc.c needs to use it too. Then you need to pester Alan till he puts it in 2.2.18-pre-de-jour :) -- dwmw2 - 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: Clear interrupts on a SMP machine?
On Wed, 18 Oct 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > There is no such exported variable in the 'stable' kernel tree:
>
> Then there should be, and the RTC accesses in 2.2 are probably racy.
>
> In which case, feel free to provide Alan with a patch for 2.2.18.
>
> --
> dwmw2
>
2.2.17 should be able to do.
--- linux-2.2.17/arch/i386/kernel/i386_ksyms.c.orig Wed Oct 18 12:53:42 2000
+++ linux-2.2.17/arch/i386/kernel/i386_ksyms.c Wed Oct 18 12:55:55 2000
@@ -17,7 +17,7 @@
#include
#include
#include
-
+extern spinlock_t rtc_lock;
extern void dump_thread(struct pt_regs *, struct user *);
extern int dump_fpu(elf_fpregset_t *);
@@ -41,7 +41,7 @@
EXPORT_SYMBOL(disable_irq);
EXPORT_SYMBOL(disable_irq_nosync);
EXPORT_SYMBOL(kernel_thread);
-
+EXPORT_SYMBOL(rtc_lock);
EXPORT_SYMBOL(init_mm);
EXPORT_SYMBOL_NOVERS(__down_failed);
--- linux-2.2.17/arch/i386/kernel/time.c.orig Wed Jun 7 17:26:42 2000
+++ linux-2.2.17/arch/i386/kernel/time.cWed Oct 18 13:27:24 2000
@@ -28,6 +28,8 @@
* 1998-12-24 Copyright (C) 1998 Andrea Arcangeli
* Fixed a xtime SMP race (we need the xtime_lock rw spinlock to
* serialize accesses to xtime/lost_ticks).
+ * 2000-10-17 [EMAIL PROTECTED]
+ * Spin-lock added to RTC code and spin-lock exported.
*/
#include
@@ -294,13 +296,19 @@
*
* BUG: This routine does not handle hour overflow properly; it just
* sets the minutes. Usually you'll only notice that after reboot!
+ *
*/
+
+spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
+
static int set_rtc_mmss(unsigned long nowtime)
{
+ unsigned long flags;
int retval = 0;
int real_seconds, real_minutes, cmos_minutes;
unsigned char save_control, save_freq_select;
+ spin_lock_irqsave(_lock, flags);
save_control = CMOS_READ(RTC_CONTROL); /* tell the clock it's being set */
CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
@@ -346,7 +354,7 @@
*/
CMOS_WRITE(save_control, RTC_CONTROL);
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
-
+ spin_unlock_irqrestore(_lock, flags);
return retval;
}
@@ -496,9 +504,12 @@
/* not static: needed by APM */
unsigned long get_cmos_time(void)
{
+ unsigned long flags;
unsigned int year, mon, day, hour, min, sec;
int i;
+ spin_lock_irqsave(_lock, flags);
+
/* The Linux interpretation of the CMOS clock register contents:
* When the Update-In-Progress (UIP) flag goes from 1 to 0, the
* RTC registers show the second which has precisely just started.
@@ -528,6 +539,7 @@
BCD_TO_BIN(mon);
BCD_TO_BIN(year);
}
+ spin_unlock_irqrestore(_lock, flags);
if ((year += 1900) < 1970)
year += 100;
return mktime(year, mon, day, hour, min, sec);
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DProbes 1.1
Hallo Richard, On Wed, Oct 18, 2000 at 10:44:11AM +0100, [EMAIL PROTECTED] wrote: > > > We've release v1.1 of DProbes - deatils and code is on the DProbes web > page. > > the enhancements include: > > - DProbes for kernel version 2.4.0-test7 is now available. First thanks for this nice work. I ported the older 1.0 dprobes to 2.4 a few weeks ago for my own use. It is very useful for kernel work. Unfortunately the user space support had still one ugly race which I didn't fix because it required too extensive changes for my simple port (and it didn't concern me because I only use kernel level breakpoints) I see the problems are still in 1.1. The problem is the vma loop in process_recs_in_cow_pages over the vmas of an address_space. In 2.4 the only way to do that safely is to hold the address_space spinlock. Unfortunately you cannot take the semaphore or execute handle_mm_fault while holding the spinlock, because they could sleep. The only way I think to do it relatively race free without adding locks to the core VM is to do it two pass (first collect all the mms with mmget() and their addresses in a separate list with the spinlock and then process it with the spinlock released) Then dp_vaddr_to_page has another race. It cannot hold the mm semaphore because that would deadlock with handle_mm_struct. Not holding it means though that the page could be swapped out again after you faulted it in before you have a change to access it. It probably can be done with an loop that checks and locks the page atomically (e.g. using cmpexchg) and retries the handle_mm_fault as needed. There may be more races I missed, the 2.4 SMP MM locking hierarchy is unfortunately not very flexible and makes things like what dprobes wants to do relatively hard. Another change I added and which I found useful is a printk to show the opcode of mismatched probes (this way wrong offsets in the probe definitions are easier to fix) -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/
[patch] khttpd doesn't detach from the files of its parent
Hi all.
While looking at kHTTPd (linux-2.4.0-test9) I found what looks like a
bug to me.
The daemon doesn't detach itself from the files structure of the
parent process. Therefore, when it is run as a module, the files
opened by "insmod" (or whatever loads it) remain open.
Besides "aesthetical" issues, this can be a problem: if a script loads
a module redirecting stderr to a file, the filesystem won't be
unmountable before the module is removed. (I reproduced that).
The proposed patch is trivial, so I may miss some detail.
A sample session follows, then the patch.
/alessandro
rudo.root# ps aux | grep http
root 1828 0.0 0.0 00 ?SW 12:57 0:00 [khttpd manager]
root 1848 0.0 0.0 00 ?SW 12:58 0:00 [khttpd - 0]
root 1849 0.0 0.0 00 ?SW 12:58 0:00 [khttpd - 1]
rudo.root# ls -l /proc/1828/fd
total 48
lrwx--1 root root 64 Oct 18 13:17 0 -> /dev/ttyp1
lrwx--1 root root 64 Oct 18 13:17 1 -> /dev/ttyp1
lrwx--1 root root 64 Oct 18 13:17 2 -> /dev/ttyp1
rudo.root# ls -l /proc/1848/fd
total 48
lrwx--1 root root 64 Oct 18 13:17 0 -> /dev/ttyp1
lrwx--1 root root 64 Oct 18 13:17 1 -> /dev/ttyp1
lrwx--1 root root 64 Oct 18 13:17 2 -> /dev/ttyp1
then, I tried "insmod khttpd < /dev/ttyS0".
rudo.root# ps aux | grep http
root 2031 0.0 0.0 00 ttypcSW 13:22 0:00 [khttpd manager]
root 2034 0.0 0.0 00 ttypcSW 13:22 0:00 [khttpd - 0]
root 2035 0.0 0.0 00 ttypcSW 13:22 0:00 [khttpd - 1]
rudo.root# ls -l /proc/2034/fd
total 27
lr-x--1 root root 64 Oct 18 13:22 0 -> /dev/ttyS0
lrwx--1 root root 64 Oct 18 13:22 1 -> /dev/ttypc
lrwx--1 root root 64 Oct 18 13:22 2 -> /dev/ttypc
after applying the patch included below, no file remains open
rudo.root# ps aux | grep http
root 2019 0.0 0.0 00 ttypcSW 13:20 0:00 [khttpd manager]
root 2020 0.0 0.0 00 ttypcSW 13:20 0:00 [khttpd - 0]
root 2021 0.0 0.0 00 ttypcSW 13:20 0:00 [khttpd - 1]
rudo.root# ls -l /proc/2020/fd
total 0
rudo.root#
--- ./net/khttpd/main.c.origWed Oct 18 13:01:29 2000
+++ ./net/khttpd/main.c Wed Oct 18 19:13:01 2000
@@ -195,6 +195,7 @@
{
sigset_t tmpsig;
int waitpid_result;
+ int i;
DECLARE_WAIT_QUEUE_HEAD(WQ);
@@ -203,6 +204,10 @@
lock_kernel(); /* This seems to be required for exit_mm */
exit_mm(current);
+ /* init_module has stdin/stdout/stderr open: close them (ARub) */
+ for (i=255; i>=0; i--)
+ if (current->files->fd[i])
+ close(i);
/* Block all signals except SIGKILL and SIGSTOP */
spin_lock_irq(>sigmask_lock);
@@ -383,7 +388,7 @@
StartSysctl();
- (void)kernel_thread(ManagementDaemon,NULL, CLONE_FS | CLONE_FILES |
CLONE_SIGHAND);
+ (void)kernel_thread(ManagementDaemon,NULL, CLONE_FS | CLONE_SIGHAND);
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: [PATCH] Make agpsupport work with modversions
In article <[EMAIL PROTECTED]> you wrote: > However, the fact that you need that dependency on CONFIG_MODULES _still_ > shows that something is wrong. That dependency should not be there, and > the drm code should be fixed. Why does it care about CONFIG_MODULES at > all? It should not, and it _must_ not do that. Because get_module_symbol() needs CONFIG_MODULES. IMHO we should simply get rid of get_module_symbol in drm. > I have no idea what the get_module_symbol() code in question is trying to > do, but this should be _fixed_ and not just worked around. That's a bug. It gets the symbol of a function, that's name is passed as char * to get_module_symbol(). Christoph -- Always remember that you are unique. Just like everyone else. - 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: Processor affinity planned for 2.5?
Wasnt my idea ... I´ll forward this to the guy who asked ... On 128 CPU
machines affinity to processor groups may be a thing to consider but not
on 2 or 4 way SMPs ...
Anyway, I appreciate that he asked on linux-SMP and not here ... less
traffic in here ...
Markus
Jakob Østergaard wrote:
>
> On Wed, Oct 18, 2000 at 01:13:48PM +0200, Markus Pfeiffer wrote:
> > HI all
> >
> > I received and discussed Processor-affinity on the SMP-Kernel-list and I
> > only wanted to ask if there is something in preparation or if someone
> > (especially Linus :)) is against this ... I was asked this question
> > beacause someone wanted to do some Matrix-Operations on his SMP machine
> > and wnated to speed them up by trying affinity ...
>
> I don't know the exact answer to your question, but I can tell you that there
> has been patches floating around for a long time (somehwere) to provide
> processor affinity for processes in the Linux kernel.
>
> However, the patches has never been merged because:
> *) No matter how self-contained and simple and elegant they may be,
> they complicate the scheduler (maybe not much, but more than not)
> *) There is no performance gain what so ever, expcept for perhaps some
> very specially fabricated benchmark in some very specially fabricated
> test environment. In the best case, you will not get a slowdown from
> the explicit affinity.
>
> Think about it: It's the scheduler's job to distribute the threads of
> execution reasonably among the available processors. The scheduler knows the
> state of the system and *you* don't when you put in your static affinity
> decisions. You are bound to lose.
>
> Yes, I know that big-iron IRIX boxes have explicit processor affinity available
> to user-space. They also have gang-scheduling, which is more complicated and
> maybe more likely to actually give you a speedup than explicit affinity. IRIX
> has a lot of things, and let's not get into *that* one again ;)
>
> If you want to achieve anything in life, keep it simple. Be happy you have a
> scheduler that on any day can do a better job than you at scheduling the
> threads, and get on with your work :)
>
> Cheers,
> --
>
> : [EMAIL PROTECTED] : And I see the elder races, :
> :.: putrid forms of man:
> : Jakob Østergaard : See him rise and claim the earth, :
> :OZ9ABN : his downfall is at hand. :
> :.:{Konkhra}...:
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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/
bind() allowed to non-local addresses
Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
address. The correct behavior should be a return code of -1 with errno
set to EADDRNOTAVAIL. (Simple snippet to reproduce/debug the problem is
available on request)
There appears to be significant differences between the
net/ipv4/af_inet.c:inet_bind() in the 2.2 and 2.4 sources. The
inet_bind() in the 2.2 sources contains a check to ensure that the value
returned by inet_addr_type() is RTN_LOCAL as well as a #ifdef'ed check
to allow the bind in certain cases if the kernel was compiled with
transparent proxy is enabled. In inet_bind() of the 2.4 tree all of
these checks are conspicuously absent.
The following patch fixes the problem for me, but I am still concerned
possibly breaking transparent proxy. Basically the patch is nothing
more than the addition of a simple check for RTN_LOCAL. (Moving call to
inet_addr_type() is a *very* nit-picky "optimization" that eliminates
wasted time in the call in the event that subsequent port and capability
check fails).
*** af_inet.c Wed Oct 18 11:06:15 2000
--- af_inet.c.orig Mon Sep 18 16:04:13 2000
***
*** 459,471
if (addr_len < sizeof(struct sockaddr_in))
return -EINVAL;
snum = ntohs(addr->sin_port);
if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
return -EACCES;
! chk_addr_ret = inet_addr_type(addr->sin_addr.s_addr);
!
/* We keep a pair of addresses. rcv_saddr is the one
* used by hash lookups, and saddr is used for transmit.
*
* In the BSD API these are the same except where it
--- 459,471
if (addr_len < sizeof(struct sockaddr_in))
return -EINVAL;
+ chk_addr_ret = inet_addr_type(addr->sin_addr.s_addr);
+
snum = ntohs(addr->sin_port);
if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
return -EACCES;
/* We keep a pair of addresses. rcv_saddr is the one
* used by hash lookups, and saddr is used for transmit.
*
* In the BSD API these are the same except where it
***
*** 483,493
sk->rcv_saddr = sk->saddr = addr->sin_addr.s_addr;
if (chk_addr_ret == RTN_MULTICAST || chk_addr_ret ==
RTN_BROADCAST)
sk->saddr = 0; /* Use device */
! else if(chk_addr_ret != RTN_LOCAL){
! err = -EADDERNOTAVAIL;
! goto out;
! }
!
/* Make sure we are allowed to bind here. */
if (sk->prot->get_port(sk, snum) != 0) {
sk->saddr = sk->rcv_saddr = 0;
--- 483,489
sk->rcv_saddr = sk->saddr = addr->sin_addr.s_addr;
if (chk_addr_ret == RTN_MULTICAST || chk_addr_ret ==
RTN_BROADCAST)
sk->saddr = 0; /* Use device */
!
/* Make sure we are allowed to bind here. */
if (sk->prot->get_port(sk, snum) != 0) {
sk->saddr = sk->rcv_saddr = 0;
Discussion? Please personally CC me <[EMAIL PROTECTED]> as I am not
currently subscribed to the linux-kernel list.
Thanks.
--
Matthew Peterson
Software Engineer
Caldera Systems, Inc
-
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: use of add_interrupt_randomness in drivers missing in many drivers
Sandy Harris <[EMAIL PROTECTED]> said: [...] > I'd still like to see the patch applied, though. I'd like /dev/random > to work well "out of the box" on the FreeS/WAN gateways people are > building out of older surplus hardware. The question at hand is more "looks like it works well", and it is extremely hard to ensure it does in fact work well (behaves like random under _all_ reasonable circumstances, given foes possibly controlling its environment) exactly because it should appear random. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TCP: peer x.x.x.x:y/z shrinks window a:b:c...
"David S. Miller" wrote: > > The IP addresses are important because we can use them to find out > what TCP implementations shrink their offered windows. > > Actually, you don't need to tell me or anyone else what these IP > addresses are, you can instead run one of the "remote OS identifier" > programs out there to those sites and just let me know what OS those > systems are running :-) All of the IPs which were reported appeared to be firewalled making a direct scan impossible. The hop above them were almost always reported as Cisco terminal servers running IOS 11.2 and in one case it was reported as a Cisco router/switch running IOS 11.2. I'll keep looking. Jordan - 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/
