Re: close() slow on socketpairs?
Date:Mon, 16 Oct 2000 22:09:03 -0700 From: Dan Kegel <[EMAIL PROTECTED]> I wrote a little benchmark to call either pipe() or socketpair() 8000 times, then close() on all the fds produced by pipe or socketpair. On both 2.2.14 and 2.2.16, pipe and socketpair are nice and speedy. close() is fine for pipes, but at 8000 socketpairs, each call to close() takes 14 *milliseconds* at 100% cpu usage. What's up with that? OK, the first thing I did when I saw this was run your test program under 2.4.0-test10-pre3 on my workstation which I believe to be a very slow computer (170Mhz ultra-I) :-) It ran in under a second which is the granularity of your programs measurements :-) [root@pizda davem]# time ./sockp_test Opening 8000 socketpairs took 0 seconds Closing 8000 pipes took 0 seconds Command exited with non-zero status 1 0.05user 0.39system 0:00.44elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (65major+16minor)pagefaults 0swaps [root@pizda davem]# (BTW: I just noticed that you need to add an exit(0) to the end of main() to get a reliable zero exit status on success.) I'll try it out under 2.2.x in a second but could you try it on 2.4.x as well and let me know what kind of cpu we're talking about and precisely what "time ./sockp_test" shows on your machine for both cases? I think it's just an AF_UNIX performance anomaly which the 2.4.x kernel doesn't have. If so, it may or may not be easy to backport the fix, we'll 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: 2.2.18pre16 and USB_UHCI_ALT
On Mon, Oct 16, 2000 at 01:32:01PM -0400, Johannes Erdfelt wrote: > On Mon, Oct 16, 2000, David Rees <[EMAIL PROTECTED]> wrote: > > In 2.2.18pre16 an alternative USB_UHCI driver under the option > > CONFIG_USB_UHCI_ALT was added. Only this one works for me, and > > CONFIG_USB_UHCI throws up 50 messages a second like this one: > > > > Oct 16 00:12:22 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 188 > > > > and leaves my mouse in an unusable state. > > > > This is on a VIA Technologies VT 82C586 Apollo USB (rev 6). I have two > > USB devices connected to it: > > Microsoft Microsoft IntelliMouse® Optical > > Microsoft Natural Keyboard Pro > > > > What is supposed to be the difference between the two drivers, anyway? It > > is not clear from the docs what is different besides the fact that they > > are different. > > Just that. It's an alternative implementation. It's a long story why > there's 2 drivers for the same device, and you can check the USB > archives to learn the whole story. > > The short of it is that I didn't like the usb-uhci.c driver so I wrote a > different one. It looks like it was worth the effort since it works for > you whereas usb-uhci.c doesn't. > > I'm sure the usb-uhci.c guys will be interested to follow up with you > about the problems you are seeing. Well, the real interesting part is that I was using the usb-uhci.c driver in 2.2.18pre15, and now in 2.2.18pre16 it stopped working for my mouse with no apparent change to either of the uhci drivers. -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/
compile error in 2.4.0-test10-pre3
I patched from 2.4.0-test9 to 2.4.0-test10-pre3 successfully. I then did make mrproper, make oldconfig, make dep successfully. make bzImage resulted in the following error: [root@wr5z linux]# make bzImage gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c In file included from /usr/include/errno.h:36, from scripts/split-include.c:26: /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory make: *** [scripts/split-include] Error 1 Additional data: [root@wr5z linux]# sh scripts/ver_linux -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux wr5z 2.4.0-test9-pre2 #1 Sun Sep 17 21:35:55 CDT 2000 i586 unknown Kernel modules 2.3.16 Gnu C egcs-2.91.66 Gnu Make 3.78.1 Binutils 2.9.5.0.22 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.6 Mount 2.10f Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded opl3 # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_M686FXSR is not set CONFIG_MK6=y # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=32 CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set CONFIG_APM_REAL_MODE_POWER_OFF=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=y # CONFIG_IP_NF_MATCH_LIMIT is not set # CONFIG_IP_NF_MATCH_MAC is not set # CONFIG_IP_NF_MATCH_MARK is not set # CONFIG_IP_NF_MATCH_MULTIPORT is not set # CONFIG_IP_NF_MATCH_TOS is not set CONFIG_IP_NF_MATCH_STATE=y # CONFIG_IP_NF_MATCH_UNCLEAN
Re: fairly hard XFree86 related crash in 2.4.0-test8+
On Tue, 17 Oct 2000 00:22:06 -0500, [EMAIL PROTECTED] wrote: >My main question is how do I go about debugging a problem which locks >up my system? (or at least the video card) I would like to be able to >get some more info so I can really tell you what is going on. Anyway Apply the relevant kernel debugger patch from http://oss.sgi.com/projects/kdb/download/ix86/. Compile your kernel with NMI oopser for uniprocessor, kdb and serial console. Run a null modem to a second machine (Documentation/serial-console.txt), capture the output on the second machine. Reproduce the problem. If the machine is running at all then the NMI oopser for UP will trip after 5 seconds, if the oopser does not trip then enter control/A on the serial console. In either case you can use kdb over the serial console to see what the system is doing. Odds are it is spinning on a lock somewhere. - 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: Device Driver
H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Ok, yes now I get it. Yes, this is stupid. > Anyone here have any experience with SmartMedia and if they are sane or > stupid? I wrote the SmartMedia FlashPath driver, and I can say that the SmartMedia is fine, but the FlashPath is a little silly. (And I sometimes feel very bad for what I was forced to write due to NDA and time constraints).. (See my post on C++ kernel modules) (and evil sys_mount() syscall overloading...) (and evil /dev/fd0 driver overloading...) (basically this driver is an example of what NOT to allow in a mainline kernel... but had to be written that way to comply with marketing...) http://www.smartdisk.com/Downloads/Software/flashpath-0.2.1.tar.gz -- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 412.656.3519 cell, 415.701.0792 fax [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. - 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: [Criticism] On the discussion about C++ modules
Eray Ozkural <[EMAIL PROTECTED]> wrote: > I've read a summary of a discussion about C++ module writing on > this list, and I'd like to make some comments on it. [I'm not > subscribed to this list, please retain a Cc: to my address] I've had the (dubious) opportunity to write a C++ kernel module for Linux 2.2.x earlier this year for a client. (Code is at: http://www.smartdisk.com/Downloads/Software/flashpath-0.2.1.tar.gz ) Anyway, here's my two cents: * If you have to port a C++ codebase to run in linux, rewrite it in C. * If you can't rewrite it in C (politics, size, time, etc) make a C++<->C API translation. * All kernel calls must go through the translation * Use the minimal C++ runtime in flashpath-0.2.1/linux/cppfake.c C++ is ugly as kernel code. I do _NOT_ recommend starting a new project with it. However, if you're porting alien C++ code, it can be done. And it's not pretty. ObWackyKernelLanguage: Objective C If people are interested, I can whip up an Objective C runtime for the kernel. Will be slow as molasses compared to C, but should make for interesting driver modularity (and flame wars)... -- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 412.656.3519 cell, 415.701.0792 fax [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. - 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: Device Driver
Igmar Palsenberg writes: > In the last case, you load something direct into kernel space. In case of > binary stuff you have no idea what actually happens. Also the case with > the before boot issue, but this plays a bigger role. I take it then that you never use a hard drive in any of your systems on the grounds that it contains non-open source firmware which may affect the security of your system? ;) Tell me, what do you use to store all those Linux applications on? Hmm, I wonder if you drive a car, travel by train or by plane...? Do you trust the firmware involved there? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM 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/
want to hire a kernel hacker ...
(If there's a better place to post this let me know.) I'd like some help in modifying linux networking code (IP, firewall, routing). There are several related projects. They have to start out proprietary, but I fully expect the resulting code to become free software before long. Reply to me, of course. Thanks. - 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/
fairly hard XFree86 related crash in 2.4.0-test8+
My main question is how do I go about debugging a problem which locks up my system? (or at least the video card) I would like to be able to get some more info so I can really tell you what is going on. Anyway here is the problem: I have had some crashes when using XFree86 4.0.1 and kernel 2.4.0-test8 and 2.4.0-test10-pre3 (I have not tried others). First of all this is not a X server crash leaving me at the console. The X server freezes leaving the video card in graphics mode. Some times the kernel will respond to Alt-PrScr requests, but not always. Also I cannot predict the crashes. They seem to happen at times of hi system load but do not always happen when doing the same thing. Sometimes I'm switching virtual desktops, sometimes I'm trying to load a page in netscape. The problem seems to have been worse in test8 but I'm not at all sure. One thing that is sure is that it never happened in test1 at all. That is at least somewhere to start. My system is: Pentium 133, Voodoo3 2000 PCI (using DRI/DRM for 3D), 64M RAM, Debian 2.2 (woody) and the XF86 4 phase2 debs. As I said at the beginning: tell me what is the best way to debug this kind of problem and I'll be glad to help. Thanks for all your time. -Arthur PS: I did not post this to the XFree86 list because since the problem is kernel version dependent and not XFree version dependent so the problem is almost surely in the kernel. But tell me if you think I should post it there. PGP signature
close() slow on socketpairs?
I wrote a little benchmark to call either pipe() or socketpair()
8000 times, then close() on all the fds produced by pipe or socketpair.
On both 2.2.14 and 2.2.16, pipe and socketpair are nice and speedy.
close() is fine for pipes, but at 8000 socketpairs, each call to close()
takes 14 *milliseconds* at 100% cpu usage. What's up with that?
- Dan
#include
#include
#include
#include
#include
main()
{
int i;
int fds[16000];
int n = 8000;
time_t start = time(0);
for (i=0; ihttp://www.tux.org/lkml/
Re: test10-pre3
Followup to: <[EMAIL PROTECTED]> By author:[EMAIL PROTECTED] In newsgroup: linux.dev.kernel > > > but intel refuse to guarantee they wont produce an actual '786' class > > CPU. > > Worry about that if/when it happens ? > Dare one guess the 786 is actually the Itanic in x86 mode? -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/
Request for info on proc system update frequency
I'm trying to understand how the proc file system works. In particular I'd like to know more about the algorithm by which the information is updated and how frequently. (Could it be too old for some purposes by the time it is read?) I'm aware of the excellent proc.txt document in Documentation/filesystems/proc.txt and I know that the bulk of the source code is in fs/proc, but I would appreciate it if someone with more kernel knowledge than myself could point out which file, or where in the source code I should read to understand how often the information in the proc file system is updated. The reason I'm trying to understand this, is that I want to profile processes (aka threads) for our jit compiler. Thanks in advance John Kacur [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: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 16 Oct 2000, David Woodhouse wrote: >Date: Mon, 16 Oct 2000 16:07:13 +0100 >From: David Woodhouse <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Content-Type: text/plain; charset=iso-8859-15 >Subject: PC speaker driver patch for 2.4.0-test10-pre3 > >ftp.uk.linux.org:/pub/people/dwmw2/pcsp/patch-pcsp-soundcore-2.4.0-test10-pre3 > >Thanks to Erik Inge Bolsø for porting it to 2.3.45, this saving me most of >the work. Is there a major compelling reason that this patch isn't included in the standard kernel tree? -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- [Quote: Linus Torvalds linux-2.4.0-test8-pre6 release message - Sept 6, 2000] But I have this ugly feeling that I'm coming down with the same flu that everybody else in my family had the last week, so I'd better release this before I start puking on my keyboard. - 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: tty_[un]register_devfs putting 3K structures on the stack
[EMAIL PROTECTED] said:
> If the problem only impacts User-mode Linux, it's hard for me to justify
> hanging the "critical" label on it. However I'm willing to look at the
> patch, bless it, and send it on to Linus
Below is the patch to rid tty_register_devfs and tty_unregister_devfs of the
tty_struct local.
I still think that treating it as critical deserves consideration because it's
a potentially nasty problem, and one that could be tough to debug. As Alan
pointed out, it's easier to fix the bug than it is to prove that it can't
happen on any of the other arches.
Jeff
diff -u drivers/char/tty_io.c.orig drivers/char/tty_io.c
--- drivers/char/tty_io.c.orig Tue Oct 17 00:06:04 2000
+++ drivers/char/tty_io.c Tue Oct 17 00:05:37 2000
@@ -1994,12 +1994,11 @@
{
#ifdef CONFIG_DEVFS_FS
umode_t mode = S_IFCHR | S_IRUSR | S_IWUSR;
- struct tty_struct tty;
+ kdev_t device = MKDEV (driver->major, minor);
+ int idx = minor - driver->minor_start;
char buf[32];
- tty.driver = *driver;
- tty.device = MKDEV (driver->major, minor);
- switch (tty.device) {
+ switch (device) {
case TTY_DEV:
case PTMX_DEV:
mode |= S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH;
@@ -2020,23 +2019,21 @@
(driver->major < UNIX98_PTY_SLAVE_MAJOR + UNIX98_NR_MAJORS) )
flags |= DEVFS_FL_CURRENT_OWNER;
# endif
- devfs_register (NULL, tty_name (, buf), flags | DEVFS_FL_DEFAULT,
+ sprintf(buf, driver->name, idx + driver->name_base);
+ devfs_register (NULL, buf, flags | DEVFS_FL_DEFAULT,
driver->major, minor, mode, _fops, NULL);
#endif /* CONFIG_DEVFS_FS */
}
-void tty_unregister_devfs (struct tty_driver *driver, unsigned minor)
+void tty_unregister_devfs (struct tty_driver *driver, unsigned int minor)
{
#ifdef CONFIG_DEVFS_FS
void * handle;
- struct tty_struct tty;
+ int idx = minor - driver->minor_start;
char buf[32];
- tty.driver = *driver;
- tty.device = MKDEV(driver->major, minor);
-
- handle = devfs_find_handle (NULL, tty_name (, buf),
- driver->major, minor,
+ sprintf(buf, driver->name, idx + driver->name_base);
+ handle = devfs_find_handle (NULL, buf, driver->major, minor,
DEVFS_SPECIAL_CHR, 0);
devfs_unregister (handle);
#endif /* CONFIG_DEVFS_FS */
-
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-pre3
On Tue, 17 Oct 2000, Alan Cox wrote: > > Alan, same diff for 2.2 ? > What about the other proc stuff. This will report a 1586, type 15 cpu and > stuff Then it needs to be fixed there also. > but intel refuse to guarantee they wont produce an actual '786' class > CPU. Worry about that if/when it happens ? > > Why Intel chose family 15 is still beyond me though. > Why Intel do most things is generally a complete mystery. *grin* Well as Intel isn't even shipping P4 samples yet, most of this is just guesswork based upon preliminary datasheets. I wouldn't be surprised if we find other fun things to work around when we start seeing silicone in use. regards, Dave. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | 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: test10-pre3
On Mon, 16 Oct 2000, Michael Peddemors wrote: > Hmmm.. Wonder if this might be affecting my problem > I compile on a Pentium for a 486. Worked but after I applied the FreeS/WAN > pathes, now it won't boot on the 486's (immediate reboot, on 'now booting the > kern..' message) Doubled checked the make outputs, and config's and it says > it is 486 but will only run on the Pentiums... > Still reasearching.. Probably completely unrelated, as the code in question shouldn't even be getting executed on most 486's (due to lack of cpuid instruction) And those that do have the instruction will return a value too low to meet the condition. People mentioned that various laptops don't work since test9. I wouldn't be surprised if this was the same thing you're experiencing. Feel free to prove me wrong by reversing the changes to setup.c in test10pre though. regards, Dave. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | 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: mapping user space buffer to kernel address space
On Tue, 17 Oct 2000, Andrea Arcangeli wrote: > > If you won't delete map_user_kiobuf from your tree I think I've just provided a > real world MM corruption case where the user send the bug report back to us if > we only increase the reference count of the page to pin it. Oh. So to fix a bug, you say "either delete the code, or do something else that is completely idiotic instead"? Sure, that's sensible. NOT. Andrea, explain to me how pinning _could_ work? Explain to me how you'd lock down pages in virtual address space with multiple threads, and how you'd handle the cases of: - two threads doing direct IO from different parts of the same page - one thread starting IO from a page, another thread unmapping the range Basically, you can't handle it sanly, because the notion of virtual pinning really isn't a sane notion. The first case would need a special "pinning count". Which is too expensive to be an option, although I've seen patches that seemed to do something like that - I consider the whole notion idiotic. The second case would require that unmap() synchronize completely with the IO. Which is wasteful, and doesn't make any sense: what's the point, when you can avoid it by just not pinning? Neither option is, quite frankly, acceptable. So we're left with your suggestion to remove direct IO completely. Something that I wouldn't mind horribly much, but too many people seem to consider it worth-while - and while I've stubborny fought the direct-IO patches a long time, every single technical argument I've had has been successfully addressed over time. I'm sure this bug will get fixed too. And the fix probably won't end up even being all that painful - it's probably a question of marking the page dirty after completing IO into it and making sure the swap-out logic does the right thing (ie try to write it out again - which is exactly the same thing that happens right now if a user dirties a page while it's busy doing write-out). In fact, the code may do this already, I'll let sct look into the exact details and fix it. 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: 2.2.18pre16 on sparc64 (Ultra1): Remaining troubles
Date: Mon, 16 Oct 2000 12:35:36 -0300 From: Horst von Brand <[EMAIL PROTECTED]> depmod -ae gives unresolved symbols pci_dvma_v2p_hash (hadn't the PCI stuff been gouged out?) and empty_zero_page in: misc/ffb.o, net/skfp.o, scsi/sr_mod.o. I don't get this with the default "arch/sparc64/defconfig" configuration, and in fact I have used the FFB drm/dri driver. Could you try that out? That is what I test. If that works for you, we can then dissect what is different about the config you chose which makes it fail. It only builds as a module BTW, the drm.o archive is linked into the "ffb.o" driver, which is why is appears to be build "non-modular". 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: [PATCH] GPL licence corrections
On Mon, 16 Oct 2000, David Woodhouse wrote: >Date: Mon, 16 Oct 2000 13:02:03 +0100 >From: David Woodhouse <[EMAIL PROTECTED]> >To: Mike A. Harris <[EMAIL PROTECTED]> >Cc: Linus Torvalds <[EMAIL PROTECTED]>, > Linux Kernel mailing list <[EMAIL PROTECTED]>, > Alan Cox <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=us-ascii >Subject: Re: [PATCH] GPL licence corrections > > >[EMAIL PROTECTED] said: >> I've found a few inconsistencies with the wording of some license >> statements refering to "GNU public license" and similar, and have >> reworded them properly to "GNU General Public License". > >If we're referring to it by name, we probably ought to call it the >'GNU General Public License' (sic). You've used the British spelling of >Licence. Personally, I don't care what spelling is used, however I guess the "correct" way though, is the way the license spells it itself, which is: GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble -- I myself spell it this way also, so had I wrote the original, it would have been correct. ;o) Unfortunately, this means I may have missed a lot with my grep, so I'll go back and do another patch. If anyone has any other license inconsistencies, copyright inconsistencies, etc.. please let me know ASAP, and I'll grab them too. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- "If it isn't source, it isn't software." -- NASA - 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] GPL licence corrections
On Mon, 16 Oct 2000, [iso-8859-1] André Dahlqvist wrote: >Date: Mon, 16 Oct 2000 14:22:12 +0200 >From: "[iso-8859-1] André Dahlqvist" <[EMAIL PROTECTED]> >To: David Woodhouse <[EMAIL PROTECTED]> >Cc: Mike A. Harris <[EMAIL PROTECTED]>, > Linus Torvalds <[EMAIL PROTECTED]>, > Linux Kernel mailing list <[EMAIL PROTECTED]> >Content-Type: text/plain; charset=iso-8859-1 >Subject: Re: [PATCH] GPL licence corrections > >> If we're referring to it by name, we probably ought to call it the >> 'GNU General Public License' (sic). You've used the British spelling >> of Licence. > >That spelling was obviously used when grepping too, and as a result 343 >occurences of "GNU Public License" (ignoring case) was missed. Actually I just looked through my command history and found the exact command I used: grep -ir "licence" * > ../license-grep-2.4 Talk about not being able to decide how to spell something! Heheh. I normally spell it "license", however I don't know what got into my mind to spell it two ways. Another patch shall be forthcoming. TTYL -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Microsoft Windows(tm). A thirty-two bit extension and graphical shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor which was written by a two-bit company that can't stand one bit of competition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0test9 - keyboard: Timeout - AT keyboard not present?
After sending my last email to the list, I switched to tty1, and could not type, I got the following in my syslog, and dumped to the screen. Oct 16 20:46:37 asdf kernel: keyboard: Timeout - AT keyboard not present? Switching consoles, and hitting random keys for a few seconds got me back. Definitely not a hardware problem. Must be a bug in the keyboard driver, or tty code. This is a stock unpatched kernel. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- [Favorite quotes of Linus Torvalds - Sept 6, 2000] I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system. And I'm not just saying that. I'm really not a very nice person. I can say "I don't care" with a straight face, and really mean it. -- Linus Torvalds on linux-kernel mailing list - 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/
Weird ppp0 up, but it isn't (2.2.16)
I was getting scanned by someone just a second ago (during my keyboard problem in the previous message), and I noticed my firewall logs firing stuff left and right. I decided even though my firewall is fort knox, I'd get off and get a new IP. I did an "ifdown ppp0" and supposedly it disconnected. ifconfig however has a different story. pts/0 root@gw:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:00:B4:86:A8:11 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1355741 errors:0 dropped:3 overruns:0 frame:6 TX packets:2039126 errors:0 dropped:0 overruns:0 carrier:0 collisions:44 txqueuelen:100 Interrupt:11 Base address:0x300 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:59574 errors:0 dropped:0 overruns:0 frame:0 TX packets:59574 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 ppp0 Link encap:Point-to-Point Protocol inet addr:206.172.218.195 P-t-P:206.172.218.244 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:67813 errors:0 dropped:0 overruns:0 frame:0 TX packets:50583 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 pts/0 root@gw:~# uname -a Linux gw.capslock.lan 2.2.16-gw1 #1 Sat Jul 29 04:32:20 EDT 2000 i486 unknown This is a stock 2.2.16 kernel with no patches, running on a 486 firewall. pts/0 root@gw:~# uptime 8:56pm up 14 days, 23:24, 1 user, load average: 0.00, 0.01, 0.00 pts/0 root@gw:~# ps ax PID TTY STAT TIME COMMAND 1 ?S 0:07 init 2 ?SW 0:15 [kflushd] 3 ?SW 0:07 [kupdate] 4 ?SW 0:00 [kpiod] 5 ?SW 0:43 [kswapd] 311 ?SW 0:01 [portmap] 326 ?SW 0:00 [lockd] 327 ?SW 0:00 [rpciod] 336 ?SW 0:00 [rpc.statd] 387 ?S 0:43 syslogd -m 0 396 ?S 0:01 klogd 410 ?S 0:00 /usr/sbin/atd 424 ?S 0:01 crond 438 ?SW 0:00 [inetd] 452 ?S 7:01 named -u named 461 ?S 2:51 /usr/sbin/sshd 479 ?SW 0:00 [rpc.rquotad] 488 ?SW 0:02 [rpc.mountd] 497 ?SW 1:24 [nfsd] 498 ?SW 1:25 [nfsd] 499 ?SW 1:23 [nfsd] 500 ?SW 1:27 [nfsd] 501 ?SW 1:26 [nfsd] 502 ?SW 1:25 [nfsd] 503 ?SW 1:23 [nfsd] 504 ?SW 1:22 [nfsd] 563 ttyS0SW 0:00 [gpm] 577 tty4 SW 0:00 [mingetty] 578 tty5 SW 0:00 [mingetty] 581 tty6 SW 0:00 [mingetty] 582 ttyS1SW 0:00 [mingetty] 3288 ?S 5:59 fetchmail -d 60 4769 ?S 0:05 sendmail: accepting connections on port 25 4817 ?S 0:11 httpd 4821 ?SW 0:00 [httpd] 4822 ?SW 0:00 [httpd] 4823 ?SW 0:00 [httpd] 4824 ?SW 0:00 [httpd] 4825 ?SW 0:00 [httpd] 4826 ?SW 0:00 [httpd] 4827 ?SW 0:00 [httpd] 4828 ?SW 0:00 [httpd] 6901 ?SW 0:00 [smbd] 6910 ?S 0:09 nmbd -D 6913 ?SW 0:00 [nmbd] 10105 tty3 SW 0:00 [mingetty] 13279 tty2 SW 0:00 [mingetty] 22246 tty1 S 0:00 /sbin/mingetty --noclear tty1 22654 ?S 0:05 /usr/sbin/sshd 22656 pts/0S 0:01 -bash 22829 pts/0R 0:00 ps ax As you can see from the above "pppd" is *NOT* running on this box". pppd has been off now for 5-10 minutes, however ifconfig claims ppp0 is still up: pts/0 root@gw:~# ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:206.172.218.195 P-t-P:206.172.218.244 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:67813 errors:0 dropped:0 overruns:0 frame:0 TX packets:50583 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 I *know* that it is not, because I have disconnected the phone line cable from the computer, and have a dialtone. Also, for the record, *ALL* of the running daemons that you see above, are all firewalled off, and only visible to the internal LAN. Oddly, my ppp interface is "ppp0" however my firewall logs show: 53 216.209.120.18:1025 L=164 S=0x00 I=47612 F=0x T=14 (#5) Oct 16 20:47:47 gw kernel: Packet log: input DENY ppp1 PROTO=6 63.160.183.233:80 216.209.120.18:1143 L=52 S=0x00 I=62447 F=0x4000 T=56 (#5) Oct 16 20:47:48 gw kernel: Packet log: input DENY ppp1 PROTO=17 198.41.0.4:53 216.209.120.18:1025 L=164 S=0x00 I=42391 F=0x T=15 (#5) Oct 16 20:47:57 gw kernel: Packet log: input DENY ppp1 PROTO=17 210.132.100.101:53 216.209.120.18:1025 L=164
Re: PATCH 2.4.0.10.3: pc_keyb and q40_keyb cleanup
On Mon, Oct 16, 2000 at 09:31:42PM -0400, Jeff Garzik wrote: > I understand SA_INTERRUPT, my question in the previous e-mail was more > basic: keyboard_interrupt calls handle_kbd_event with local interrupts > disabled. [..] Woops sorry, I misunderstood your question. >[..] Why are local interrupts disabled? To avoid to deadlock on the kbd_controller_lock in SMP or to race in UP. Both irq handler and normal kernel context (open/close) will play with the keyb controller at around address 0x6x and accesses are serialized via the kbd_controller_lock. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
pre-patch-2.0.39final work fine too
Dear. I am Seiichi Nakashima. I update pre-patch-2.0.39final to other PCs, and work fine. (1) Mail Sever ( work 24 hours in a day ) motherboard ( unknown ) Celeron-400 Memory 64 MB Ethercard 3com ( maybe 3c905 ) Disk seagate and quantum (2) Samba Server ( work 24 hours in a day ) H/W Mitsubish Electoric Apricot XEN-PC motherboard ( unknown ) 486DX2-66 Memory 36MB Ethtercard NE2000 compatible Disk quantum - 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 2.4.0.10.3: pc_keyb and q40_keyb cleanup
Andrea Arcangeli wrote: > Timer, bottomhalves (softirq) and tasklets (and softnet) are always > recalled with irq enabled. So if it would be called by timer/tasklet/bhhandler > it should use irq version of the spinlocks too if it needs to run with irq > locally disabled. > > One thing you could safely change in keyboard_interrupt is to remove the save > part of the spinlock by using spin_lock_irq (we don't need to save anything > since keyboard_interrupt is only recalled as an irq handler). I understand SA_INTERRUPT, my question in the previous e-mail was more basic: keyboard_interrupt calls handle_kbd_event with local interrupts disabled. Why are local interrupts disabled? -- 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: test10-pre3
> > --- 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 Mon Oct 16 23:14:42 2000 > > @@ -426,5 +426,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); > > } > > Seems more sane to me. > Alan, same diff for 2.2 ? What about the other proc stuff. This will report a 1586, type 15 cpu and stuff but intel refuse to guarantee they wont produce an actual '786' class CPU. > > mtrr.c will need fixing too, but we can't really do that until Intel > > releases a new IA-32 System Programming manual with Pentium IV updates. > > Agreed. > > Why Intel chose family 15 is still beyond me though. Why Intel do most things is generally a complete mystery. - 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-pre3
Hmmm.. Wonder if this might be affecting my problem
I compile on a Pentium for a 486. Worked but after I applied the FreeS/WAN
pathes, now it won't boot on the 486's (immediate reboot, on 'now booting the
kern..' message) Doubled checked the make outputs, and config's and it says
it is 486 but will only run on the Pentiums...
Still reasearching..
On Mon, 16 Oct 2000, Mikael Pettersson wrote:
> On Fri, 13 Oct 2000, Linus Torvalds wrote:
> > - pre3:
> > ...
> >- Dave Jones: x86 setup fixes (recognize Pentium IV etc).
>
> And then in test10-pre3 we find the following code added to
> arch/i386/kernel/setup.c:
>
> + /* Pentium IV. */
> + if (c->x86 == 15) {
> + c->x86 = 6;
> + get_model_name(c);
> + goto name_decoded;
> + }
>
> I believe the "c->x86 = 6" assignment to be broken.
> If it's there to make uname -m return i686 for Pentium IV,
> then surely that could be done differently. (See patch below.)
>
> The assignment throws away perfectly good information, but worse,
> it also destroys the implicit invariant that boot_cpu_data.x86
> equals the "family" code as returned by CPUID. Low-level cpu-specific
> code may then malfunction, or it will have to be updated to do its
> own CPUID identification. Think about MTRRs, model-specific registers,
> performance counters, and bug workarounds.
>
> One harmless example is the "sep_bug" identification code in setup.c:
>
> sep_bug = c->x86_vendor == X86_VENDOR_INTEL &&
> c->x86 == 0x06 &&
> c->cpuid_level >= 0 &&
> (c->x86_capability & X86_FEATURE_SEP) &&
> c->x86_model < 3 &&
> c->x86_mask < 3;
>
> Since initial Pentium IV processors have model 0 according to Intel's
> Pentium IV supplement to the CPUID manual (AP-485), this code may
> actually deduce that a Pentium IV has the bug (if the mask < 3).
> Imagine a similar mistake in an MTRR/MSR/whatever driver...
>
> I propose the following patch against test10-pre3:
>
> --- 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.cMon Oct
> 16 23:13:21 2000 @@ -1548,7 +1548,6 @@
>
> /* Pentium IV. */
> if (c->x86 == 15) {
> - c->x86 = 6;
> get_model_name(c);
> goto name_decoded;
> }
> --- 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 Mon Oct 16
> 23:14:42 2000 @@ -426,5 +426,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); }
>
>
> mtrr.c will need fixing too, but we can't really do that until Intel
> releases a new IA-32 System Programming manual with Pentium IV updates.
>
> /Mikael
> -
> 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/
--
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
(604) 589-0037 Beautiful British Columbia, Canada
-
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/
MANOS/Ute-Linux mailing List problems
For you guys on the manos-kernel/ute-linux mailing lists, the reason the list has not been sending out emails for the past week is due some employees internal at Novell playing games with our servers. What appears to be going on is they have registered several bogus email addresses with bogus domains that point to MX records that route through these bogus domains back into MX -> prv-mx.provo.novell.com. They apparantley setup the DNS entries incorrectly, which is causing the buggy NetWare/Groupwise DNS servers at Novell to hang when a connection is opened to port 25 on their primary mail exchanger, and an email loop to form back to majordomo, which has resulted in majordomo freezing up during bulk resend (because majordomo fills up the entire disk with the same messages. The /var/spool/mqueue diretory appears to still have all the emails posted and as soon as we disable routing to Novell's DNS mail exchangers, the messages will repost. We apologize for the list problems, and will have it back up later this evening. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[USB] Alcatel Modem ?
Hi is there currently any support under linxu for the Alcatel USB ADSL modem under linux ? thanks James - 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/
OnStream DI-30 with ide-tape version 1.16f problems
Thanks for your work with the OnStream driver! Unfortunately, I'm having some trouble getting it to work. It looks like my kernel (2.2.17) detects the drive properly, but I keep getting I/O errors when I stat it. My drive is a slave on my second ide channel (/dev/hdd). I'd really appreciate any advice you could offer. Thanks, --Noel mt -f /dev/nht0 status /dev/nht0: Device or resource busy tail /var/log/messages kernel: ide-tape: hdd <-> ht0: OnStream DI-30 rev 1.08 kernel: ide-tape: hdd <-> ht0: 990KBps, 64*32kB buffer, 10208kB pipeline, 60ms tDSC kernel: ide-tape: ht0: I/O error, pc = 0, key = 2, asc = 3a, ascq = 0 kernel: ide-tape: ht0: drive not ready Kernel: linux-2.2.17 ide.2.2.17.all.2904.patch.bz2 cat /proc/ide/hdd/model OnStream DI-30 cat /proc/ide/hdd/driver ide-tape version 1.16f cat /proc/ide/hdd/settings namevalue min max mode - --- --- avg_speed 0 0 65535 r buffer 20480 32767 r cur_frames 0 0 65535 r current_speed 0 0 69 rw debug_level 0 0 65535 rw dsc_overlap 1 0 1 rw ide_scsi0 0 1 rw init_speed 0 0 69 rw insert_size 0 0 65535 r insert_speed0 0 65535 r io_32bit0 0 3 rw keepsettings0 0 1 rw max_frames 0 0 65535 r max_insert_speed500 0 65535 rw nice1 1 0 1 rw number 3 0 3 rw pio_modewrite-only 0 255 w pipeline10208 64 2097120 rw pipeline_head_speed_c 0 0 65535 r pipeline_head_speed_u 0 0 65535 r pipeline_max20416 64 2097120 rw pipeline_min10208 64 2097120 rw pipeline_pending0 0 2097120 r pipeline_used 0 0 2097120 r slow0 0 1 rw speed 990 0 65535 r speed_control 1 0 65535 rw stage 32 0 63 r tape_still_time 0 0 65535 r tdsc60 50 400 rw unmaskirq 0 0 1 rw using_dma 0 0 1 rw - 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-pre3
On Tue, 17 Oct 2000, Mikael Pettersson wrote:
> Since initial Pentium IV processors have model 0 according to Intel's
> Pentium IV supplement to the CPUID manual (AP-485), this code may
> actually deduce that a Pentium IV has the bug (if the mask < 3).
Valid point. I copied the same fix from 2.2.18pre.
Obviously its broken there also.
> --- 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.c Mon Oct 16 23:13:21 2000
> @@ -1548,7 +1548,6 @@
>
> /* Pentium IV. */
> if (c->x86 == 15) {
> - c->x86 = 6;
> get_model_name(c);
> goto name_decoded;
> }
> --- 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 Mon Oct 16 23:14:42 2000
> @@ -426,5 +426,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);
> }
Seems more sane to me.
Alan, same diff for 2.2 ?
> mtrr.c will need fixing too, but we can't really do that until Intel
> releases a new IA-32 System Programming manual with Pentium IV updates.
Agreed.
Why Intel chose family 15 is still beyond me though.
regards,
Dave.
--
| Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej
| 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: [PATCH] max_loop module parameter for 2.2.x loop.c
On Mon, 16 Oct 2000, Alan Cox wrote:
> ENOPATCH
sorry.
here it is.
--- linux-2.2.18pre16/drivers/block/loop.c.orig Mon Oct 16 22:09:17 2000
+++ linux-2.2.18pre16/drivers/block/loop.c Mon Oct 16 22:14:00 2000
@@ -22,6 +22,8 @@
* CBC (and relatives) mode encryption requiring unique IVs per data block.
* Reed H. Petty, [EMAIL PROTECTED]
*
+ * module parameter for max. number of loop devices - Eric Lammerts, Oct 16, 2000
+ *
* Still To Fix:
* - Advisory locking is ignored here.
* - Should use an own CAP_* category instead of CAP_SYS_ADMIN
@@ -42,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -61,10 +64,12 @@
#define TIMEOUT_VALUE (6 * HZ)
#include
-#define MAX_LOOP 8
-static struct loop_device loop_dev[MAX_LOOP];
-static int loop_sizes[MAX_LOOP];
-static int loop_blksizes[MAX_LOOP];
+static int max_loop = 8;
+MODULE_PARM(max_loop, "i");
+
+static struct loop_device *loop_dev;
+static int *loop_sizes;
+static int *loop_blksizes;
#define FALSE 0
#define TRUE (!FALSE)
@@ -169,7 +174,7 @@
INIT_REQUEST;
current_request=CURRENT;
CURRENT=current_request->next;
- if (MINOR(current_request->rq_dev) >= MAX_LOOP)
+ if (MINOR(current_request->rq_dev) >= max_loop)
goto error_out;
lo = _dev[MINOR(current_request->rq_dev)];
if (!lo->lo_dentry || !lo->transfer)
@@ -577,7 +582,7 @@
return -ENODEV;
}
dev = MINOR(inode->i_rdev);
- if (dev >= MAX_LOOP)
+ if (dev >= max_loop)
return -ENODEV;
lo = _dev[dev];
switch (cmd) {
@@ -614,7 +619,7 @@
return -ENODEV;
}
dev = MINOR(inode->i_rdev);
- if (dev >= MAX_LOOP) {
+ if (dev >= max_loop) {
return -ENODEV;
}
lo = _dev[dev];
@@ -639,7 +644,7 @@
return 0;
}
dev = MINOR(inode->i_rdev);
- if (dev >= MAX_LOOP)
+ if (dev >= max_loop)
return 0;
err = fsync_dev(inode->i_rdev);
lo = _dev[dev];
@@ -689,7 +694,7 @@
if ((unsigned)number >= MAX_LO_CRYPT)
return -EINVAL;
- for (lo = _dev[0]; lo < _dev[MAX_LOOP]; lo++) {
+ for (lo = _dev[0]; lo < _dev[max_loop]; lo++) {
int type = lo->lo_encrypt_type;
if (type == number) {
xfer_funcs[type]->release(lo);
@@ -706,34 +711,65 @@
int __init loop_init(void)
{
- int i;
+ int i, retval;
+
+ if(max_loop < 1 || max_loop > 256) {
+ printk(KERN_ERR "loop: 1 <= max_loop <= 256\n");
+ return -EINVAL;
+ }
+
+ retval = -ENOMEM;
+ loop_dev = kmalloc(sizeof(*loop_dev) * max_loop, GFP_KERNEL);
+ if(loop_dev == NULL) goto out_nomem;
+
+ loop_sizes = kmalloc(sizeof(*loop_sizes) * max_loop, GFP_KERNEL);
+ if(loop_sizes == NULL) goto out_nomem_freedev;
+
+ loop_blksizes = kmalloc(sizeof(*loop_blksizes) * max_loop, GFP_KERNEL);
+ if(loop_blksizes == NULL) goto out_nomem_freesizes;
if (register_blkdev(MAJOR_NR, "loop", _fops)) {
printk(KERN_WARNING "Unable to get major number %d for loop device\n",
MAJOR_NR);
- return -EIO;
+ retval = -EIO;
+ goto out_nomem_freeblksizes;
}
#ifndef MODULE
printk(KERN_INFO "loop: registered device at major %d\n", MAJOR_NR);
#endif
blk_dev[MAJOR_NR].request_fn = DEVICE_REQUEST;
- for (i=0; i < MAX_LOOP; i++) {
+ for (i=0; i < max_loop; i++) {
memset(_dev[i], 0, sizeof(struct loop_device));
loop_dev[i].lo_number = i;
}
- memset(_sizes, 0, sizeof(loop_sizes));
- memset(_blksizes, 0, sizeof(loop_blksizes));
+ memset(loop_sizes, 0, sizeof(*loop_sizes) * max_loop);
+ memset(loop_blksizes, 0, sizeof(*loop_blksizes) * max_loop);
blk_size[MAJOR_NR] = loop_sizes;
blksize_size[MAJOR_NR] = loop_blksizes;
return 0;
+
+out_nomem_freeblksizes:
+ kfree(loop_blksizes);
+out_nomem_freesizes:
+ kfree(loop_sizes);
+out_nomem_freedev:
+ kfree(loop_dev);
+out_nomem:
+ return retval;
}
#ifdef MODULE
void cleanup_module(void)
{
- if (unregister_blkdev(MAJOR_NR, "loop") != 0)
+ if (unregister_blkdev(MAJOR_NR, "loop") != 0) {
printk(KERN_WARNING "loop: cannot unregister blkdev\n");
+ return;
+ }
+
+ kfree(loop_dev);
+ kfree(loop_sizes);
+ kfree(loop_blksizes);
}
#endif
Re: mapping user space buffer to kernel address space
On Mon, Oct 16, 2000 at 03:21:11PM -0700, Linus Torvalds wrote: > Pinning will not happen. Pinning happens every day on my box while I use rawio. If you want to avoid pinning _userspace_ pages then we should delete map_user_kiobuf and define a new functionality and API to replace RAWIO for DBMS that must bypass the kernel cache while doing I/O to disk and possibly providing zero copy below highmem as rawio does. (later on we should do the same for networkng) IMHO rawio is providing the above necessary functionality with a sane userspace interface. > (And remap_page_range() has nothing to do with pinning - they are just > pages that cannot be swapped out because they are not normal pages at > all). They are _normal_ pages allocated by a device driver and made temporarly visible to userspace mapping them into the virtual address space of the process _after_ "pinning" them using the PG_reserved bitflag. If we wouldn't pin them too, they would be unmapped as well as soon as they're visible in the virtual address space of the process. I don't think the thing is much different. The main difference I can see is the one that was buggy: that is remap_page_range doesn't have to care that the page stays there while pinning it, because before pinning it it's still private and not visible by the VM (that's why it's much simpler). map_user_kiobuf instead is more complex because it must make sure that the page stays there while we pin it (and that should be fixed now). I hope we're not getting confused by the term "pin". With "pin" I always meant to avoid the userspace-visible page to go away from under us while we use it from kernel space because of underlying VM activities. I don't see any other possible meaning for "pin" in the context of map_user_kiobuf. (in journaling we instead use "pin" to mean a page that can't be freed but that also can't be written before some other transaction is committed to disk) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Douglas Gilbert wrote: > Sg has an ioctl called SG_SET_TRANSFORM which is only > relevant to the ide-scsi driver. As far as I know, no > applications use it. Still it is not clear why Mark's > system would work on a UP machine but fail on a SMP box. Hi Douglas, Jörg, all, I just finished compiling cdrecord-1.8.1 with debug enabled. The two attached log files are from the hp7100i / smp / 2.2.18pre15, and the ricoh 9060 / up /2.2.18pre15. Exact same cdrw media. # ./cdrecord -debug dev=1,0,0 blank=all 2>&1 | tee log.(hp7100|ricoh) I should note that the ricoh when blanking took a whole 5-6 seconds, so it didn't blank the whole disk. I guess it's being 'clever' and knew the disk was blank, and just 'made sure'. I just finished writing a 650Mb iso to the cdrw in question, so it does appear to still be okay. Looking at the traces and where they diverge it does appear to be shortly after cdrecord attempts to read ATIP data - which the Ricoh supports, and the HP7100i doesn't. I'm guessing that it's something in cdrecord making a bad assumption if ATIP isn't available, though I'll have to look further into this. Thanks to everyone who has taken time looking at this so far. It's appreciated. Cheers, Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ fs: 4194304 buflen: 4198400 ./cdrecord: shared memory segment allocated: 48169 ./cdrecord: shared memory segment attached: 40149000 buf: 40149000 bufend: 4054A000, buflen: 4198400 buf: 40149000 bufend: 4054A000, buflen: 4198400 (align 0) SCSI buffer size: 32768 dev: 1,0,0 speed: -1 fs: -1 Cdrecord 1.8.1 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 l1: 0xA05 l2: 0x0 Bus: 0 Target: 5 Lun: 0 Chan: 0 Ino: 10 l1: 0x3200 l2: 0x0 Bus: 1 Target: 0 Lun: 0 Chan: 0 Ino: 50 Using libscg version 'schily-0.1' scsi_getbuf: 32768 bytes atapi: 1 DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x08073550 size: 36 - using copy buffer DMA addr: 0xBFFFDDC0 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDAA0 size: 2 - using copy buffer DMA addr: 0xBFFFDAA0 size: 30 - using copy buffer DMA addr: 0xBFFFDBE0 size: 30 - using copy buffer Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'HP ' Identifikation : 'CD-Writer+ 7100 ' Revision : '3.01' Device seems to be: Generic mmc CD-RW. DMA addr: 0xBFFFDF40 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDC20 size: 2 - using copy buffer DMA addr: 0xBFFFDC20 size: 30 - using copy buffer DMA addr: 0xBFFFDD60 size: 30 - using copy buffer DMA addr: 0xBFFFDF60 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDC40 size: 2 - using copy buffer DMA addr: 0xBFFFDC40 size: 30 - using copy buffer DMA addr: 0xBFFFDD80 size: 30 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDD70 size: 2 - using copy buffer DMA addr: 0xBFFFDD70 size: 30 - using copy buffer DMA addr: 0xBFFFDEB0 size: 30 - using copy buffer Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO DMA addr: 0xBFFFE1B0 size: 12 - using copy buffer Drive buf size : 786432 = 768 KB ./cdrecord: Input/output error. read toc: scsi sendcmd: retryable error status: 0x2 (CHECK CONDITION) DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDF30 size: 259 - using copy buffer Pages: 0x1 0x5 0xd 0xe 0x2a DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDF30 size: 259 - using copy buffer Pages: 0x1 0x5 0xd 0xe 0x2a Current Secsize: -1 DMA addr: 0x08073578 size: 8 - using copy buffer DMA addr: 0xBFFFE0C0 size: 2 - using copy buffer Disk info: 00 20 10 01 01 01 01 00 00 00 00 00 00 00 00 00 00 61 1A 3F 00 4B 00 00 00 00 00 00 00 00 00 00 00 00 Disk info: 00 20 10 01 01 01 01 00 00 00 00 00 00 00 00 00 00 61 1A 3F 00 4B 00 00 00 00 00 00
Re: [linux-fbdev] [PATCH] mdacon SMP fix
> Hi James,
>
> I think you missed to remove one restore_flags().
> (There could be more, I only looked shortly at your patch)
Yeap. I didn't remove the restore_flag calls. Fixed now. Here is the
correct patch. I tested to see if it compiles against a test-9 kernel.
It does. That is the problem with fixing code that you don't have the
hardware for. You can't find those stupid mistakes before you post a
possible patch :-( It is next to impossible to find a MDA card. *shameless
plug *
--- mdacon.c.orig Wed Oct 11 18:09:01 2000
+++ mdacon.cMon Oct 16 23:03:26 2000
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,7 @@
#include
#include
+static spinlock_t mda_lock = SPIN_LOCK_UNLOCKED;
/* description of the hardware layout */
@@ -80,7 +82,6 @@
MODULE_PARM(mda_last_vc, "1-255i");
#endif
-
/* MDA register values
*/
@@ -110,39 +111,38 @@
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(_lock, flags);
outb_p(reg, mda_index_port);
outb_p(val, mda_value_port);
- restore_flags(flags);
+ spin_unlock_irqrestore(_lock, flags);
}
static void write_mda_w(unsigned int val, unsigned char reg)
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(_lock, flags);
outb_p(reg, mda_index_port); outb_p(val >> 8, mda_value_port);
outb_p(reg+1, mda_index_port); outb_p(val & 0xff, mda_value_port);
- restore_flags(flags);
+ spin_unlock_irqrestore(_lock, flags);
}
static int test_mda_b(unsigned char val, unsigned char reg)
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(_lock, flags);
outb_p(reg, mda_index_port);
outb (val, mda_value_port);
udelay(20); val = (inb_p(mda_value_port) == val);
- restore_flags(flags);
-
+ spin_unlock_irqrestore(_lock, flags);
return val;
}
-
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
On Tue, Oct 17, 2000 at 12:02:01AM +0200, Roman Zippel wrote: > Why don't we give BLKSSZGET a new number and make the old one obsolete? But you see that one would need a new name as well, otherwise the value associated with BLKSSZGET would depend on the kernel version, and one would need version checks anyway. I think all this is too unimportant. Almost nobody uses this stuff, and 2.4 is correct, and we may fix 2.2 one of these days, perhaps for 2.2.19, and we may fix *fdisk to correctly use it. (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?) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MIME QP encoded good/bad ...
[EMAIL PROTECTED] (Alan Cox) wrote on 09.10.00 in <[EMAIL PROTECTED]>: > > I do use PINE, and I still think QP is buggy and a stupid excersize. Mail > > delivery should have been cleaned up, not the user agent. You could have > > done the equivalent of QP inside sendmail, and none of the stupid QP > > issues would ever ever have happened (sure, people with old sendmails > > would have seen the QP-encoding, but that's THEIR problem). > > Umm you can. Sendmail supports arbitary delivery agents, you just need to > write a suitable one in your 'copious' free time Such software exists. Stuff like emil, for example ... MfG Kai - 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: mapping user space buffer to kernel address space
On Mon, Oct 16, 2000 at 02:59:59PM -0700, Linus Torvalds wrote: > No. Because "pinning" is _stupid_. Pinning using map_user_kiobuf looks just the other way around of what we do usually with the mmap callback of the device driver and remap_page_range. I considered "pinning" just to convert the user page to one of the pages mapped with remap_page_range so they can threat them in the same way internally in the device driver (and the ones mapped with remap_page_range don't get unmapped and then into swap of course). > Instead, the Linux answer is to say: pinning is bad, pinning is stupid, > pinning is useless - so dont do it. So just delete map_user_kiobuf from your tree if people shouldn't do it. That would fix the mm corruption too indeed. I don't see why you provide that functionality and then you keep telling people not to use it. Also rawio and networking could use the other way around. I think that's mainly a matter of API. People is used to think in read/write terms. And infact rawio doesn't provide a completly transpartent read/write because it have constrants on the buffer alignment. If you won't delete map_user_kiobuf from your tree I think I've just provided a real world MM corruption case where the user send the bug report back to us if we only increase the reference count of the page to pin it. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] mdacon SMP fix
> I will test this soon, hopefully. I move tomorrow, and will be bringing my > X environment and my audio environment into my dual P200 machine. This is > against which kernel? 2.4.0-test10 prepatch, or? 2.4.0-test9. It should work against a test10-preX. - 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: Is this a valid construct?
You know, it would help if I posted the right pseudocode.
Yes, I found this race condition a while ago. I do set flagvar _before_ I
chew on the hardware.
Nevertheless, what I'm seeing looks like either (a) the change to flagvar
isn't being propagated from the IRQ handler to the thread, or (b) the
down() fails to sleep for no good reason.
Matt
On Mon, Oct 16, 2000 at 05:34:02PM -0500, Sudhindra Herle wrote:
> You have a race condition.
>
> > int flagvar = 0;
> > struct semaphore blocking_sem;
> >
> > void function_called_from_kernel_thread(void)
> > {
> > chew_on_hardware();
> ^^^
> As soon as you do/did this, the IRQ must've happened. So, before the next
> statement is executed, the IRQ handler is called which clears flagvar.
>
> > flagvar = 1;
> This is executed _after_ the IRQ handler completes. So, you stomp over
> whatever
> the IRQ handler did.
>
> > down(blocking_sem);
> Since the IRQ handler did up(), this down() won't sleep.
>
> Try setting flagvar = 1 _before_ you chew_on_hardware().
> Make sure that what ever you do is SMP safe.
>
> Store the tick count of when you do the IRQ handler and when you do
> chew_on_hardware(). You'll see if I am right.
> i.e., try:
>
> before = system_ticks_NOW
> flagvar = 1;
> chew_on_hardware ();
> after = system_ticks_NOW
>
> printk (..., before, after, irq)
>
>
> interrupt_handler ( ..)
> {
> irq = system_ticks_NOW
> ...
> }
>
>
> Cheers,
> -Sudhi.
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
DP: And judging from the scores, Stef has the sma...
T: LET'S NOT GO THERE!
-- Dust Puppy and Tanya
User Friendly, 12/11/1997
PGP signature
Re: Is this a valid construct?
Also sprach Matthew Dharm:
} Does the following pseudocode do what I think it does?
}
} Assume the semaphore is properly initialized to locked.
}
} int flagvar = 0;
} struct semaphore blocking_sem;
}
} void function_called_from_kernel_thread(void)
} {
} chew_on_hardware();
} flagvar = 1;
} down(blocking_sem);
}
} if (flagvar)
} printk("something went wrong")
} else
} printk("everything okay")
} }
}
} void function_called_from_interrupt_context()
} {
} flagvar = 0;
} up(blocking_sem);
} }
}
} void function_to_call_from_timeout()
} {
} up(blocking_sem);
} }
}
} The idea is this -- I chew on the hardware, then sleep on the semaphore. I
} then either get woken up by an IRQ (which may never come), or the timeout.
} I then try to use the flagvar to determine which of the two happened.
}
} This _looks_ valid to me... but I'm seeing occurances where I get the IRQ
} (yes, I'm sure of it) but flagvar == 1, which confuses me.
}
Are you sure there isn't a race on the flagvar variable? Like, the
interrupt happens, it gets set to 0, then before we can ``up'' the
semaphore, it's set to 1 in the function_called_from_kernel_thread()?
--
|| Bill Wendling[EMAIL PROTECTED]
PGP signature
RE: Is this a valid construct?
You have a race condition.
> int flagvar = 0;
> struct semaphore blocking_sem;
>
> void function_called_from_kernel_thread(void)
> {
> chew_on_hardware();
^^^
As soon as you do/did this, the IRQ must've happened. So, before the next
statement is executed, the IRQ handler is called which clears flagvar.
> flagvar = 1;
This is executed _after_ the IRQ handler completes. So, you stomp over
whatever
the IRQ handler did.
> down(blocking_sem);
Since the IRQ handler did up(), this down() won't sleep.
Try setting flagvar = 1 _before_ you chew_on_hardware().
Make sure that what ever you do is SMP safe.
Store the tick count of when you do the IRQ handler and when you do
chew_on_hardware(). You'll see if I am right.
i.e., try:
before = system_ticks_NOW
flagvar = 1;
chew_on_hardware ();
after = system_ticks_NOW
printk (..., before, after, irq)
interrupt_handler ( ..)
{
irq = system_ticks_NOW
...
}
Cheers,
-Sudhi.
-
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/
Is this a valid construct?
Does the following pseudocode do what I think it does?
Assume the semaphore is properly initialized to locked.
int flagvar = 0;
struct semaphore blocking_sem;
void function_called_from_kernel_thread(void)
{
chew_on_hardware();
flagvar = 1;
down(blocking_sem);
if (flagvar)
printk("something went wrong")
else
printk("everything okay")
}
void function_called_from_interrupt_context()
{
flagvar = 0;
up(blocking_sem);
}
void function_to_call_from_timeout()
{
up(blocking_sem);
}
The idea is this -- I chew on the hardware, then sleep on the semaphore. I
then either get woken up by an IRQ (which may never come), or the timeout.
I then try to use the flagvar to determine which of the two happened.
This _looks_ valid to me... but I'm seeing occurances where I get the IRQ
(yes, I'm sure of it) but flagvar == 1, which confuses me.
Is this one of those places where I need the "volatile" keyword?
The code I'm working on is in the kernel... but this is the stripped-down
version. I can provide files/lines if people want to look at particulars.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Somebody call an exorcist!
-- Dust Puppy
User Friendly, 5/16/1998
PGP signature
Re: mapping user space buffer to kernel address space
On Tue, 17 Oct 2000, Andrea Arcangeli wrote: > > And anyways from a design standpoint it looks much better to really pin the > page in the pte too (just like kernel reserved pages are pinend after a > remap_page_range). No. Read my emails. "Pinning" is stupid. There are no ifs, buts, or maybes about it. Pinning will not happen. (And remap_page_range() has nothing to do with pinning - they are just pages that cannot be swapped out because they are not normal pages at all). 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: mapping user space buffer to kernel address space
On Mon, Oct 16, 2000 at 10:14:01PM +0100, Stephen C. Tweedie wrote:
> [..] If the VM
> chooses to unmap the page temporarily, then as long as the page
> remains in physical memory, then a subsequent page fault will
> reestablish the mapping. [..]
Correct. But the problem is that the page won't stay in physical memory after
we finished the I/O because swap cache with page count 1 will be freed by the
VM. And even it stays in physical memory because a read fault happened on the
swap cache before we freed it, we could have swap cache that isn't coherent
with the on-disk data (that could lead to the same problem but later).
And anyways from a design standpoint it looks much better to really pin the
page in the pte too (just like kernel reserved pages are pinend after a
remap_page_range).
> It's an important distinction, because we really would rather avoid
> taking the page lock. If you happen to have the same page mapped into
> multiple VAs within the region being written, should the kernel
> object? [..]
I see your point but if you want to allow that we should simply check if the
page that we can't lock is just locked in the earlier part of the kiobuf (just
browsing backwards the iobuf->maplist). I just don't think that not locking the
page is the right way to provide that feature.
I think it's not horribly wrong if people can't do map_user_kiobuf on virtual
pages pointing to the same physical page because that functionality is quite
special, just like rawio is quite special in requiring people to use
hardblocksize aligned buffers. And yes, we could also allow people to do
rawio without that userspace alignment constraint but with that constraint
we force them to do zero copy.
> shouldn't matter. For some other applications, it might be important,
> which is why I wanted to keep the map_user_kiobuf() and lock_kiobuf()
> functions distinct.
I'm not sure which are those apps but if we need we can easily handle that case
by browsing backwards the maplist in the TryLockPage == 1 slow path.
> Note that if you have a threaded application and another thread goes
> messing with the MM while your IO is in progress, then it's possible
> that the pages in the user's VA at the end of the IO are not the same
> as the ones that were there at the start. No big deal, that's no
> different to the situation if you have any other read or write going
> on in parallel with other MM activity.
Yep, that looks ok.
> > + if (!(map = follow_page(ptr, write))) {
> > + char * user_ptr = (char *) ptr;
> > + char c;
> > spin_unlock(>page_table_lock);
> > + up(>mmap_sem);
> > + if (get_user(c, user_ptr))
> > + goto out;
> > + if (write && put_user(c, user_ptr))
> > + goto out;
> > + down(>mmap_sem);
> > + goto refind;
>
> looks unnecessarily messy. We don't need the get_user() in ptrace:
> why do we need it here? Similarly, the put_user should be dealt with
> by the handle_mm_fault. We already absolutely rely on the fact that
> handle_mm_fault never continually fails to make progress for ever. If
> it did, then a page fault could produce an infinite loop in the
> kernel.
Replacing the get_user/put_user with handle_mm_fault _after_ changing
follow_page to check the dirty bit too in the write case should be ok.
If you want I can do this change plus the backwards maplist check for allowing
mapping the same physical page multiple times in a kiobuf (the unmap_kiobuf
will unlock the same physical page multiple times but that's ok).
> Once I'm back in the UK I'll look at getting map_user_kiobuf() simply
> to call the existing access_one_page() from ptrace. You're right,
access_one_page is missing the pagetable lock too, but that seems the only
problem. I'm not convinced mixing the internal of access_one_page and
map_user_kiobuf is a good thing since they needs to do a very different thing
in the critical section.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
oops playing audio CD with scsi cdrom on test10-pre3
This is in reply to an earlier thread, "aic7xxx problem on linux-2.4.0-test10-pre1". If you play hr eject an audio cd-rom from gtcd (a GNOME cd player), you get an oops like the one mentioned. I just wanted to confirm that Jens' one-liner patch fixes the problem for me. The aic7xxx driver was involved for both me and the original poster, but it looks like the problem exists for any scsi cdrom drive, as it's in drivers/scsi/sr_ioctl.c. http://www.uwsg.indiana.edu/hypermail/linux/kernel/0010.1/0726.html Jason - 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-2.4.0-test10-pre3] logic of __alloc_pages_limit(
On Mon, 16 Oct 2000, Petr Vandrovec wrote:
> On 16 Oct 00 at 22:50, Tigran Aivazian wrote:
> > + struct page *page;
> > /* If possible, reclaim a page directly. */
> > - if (direct_reclaim && z->free_pages < z->pages_min + 8)
> > + if (direct_reclaim && z->free_pages < z->pages_min + 8) {
> > page = reclaim_page(z);
> > - /* If that fails, fall back to rmqueue. */
> > - if (!page)
> > - page = rmqueue(z, order);
> > - if (page)
> > - return page;
> > + /* If that fails, fall back to rmqueue. */
> > + if (!page) {
> > + page = rmqueue(z, order);
> > + if (page)
> > + return page;
> > + }
>
> Old code returned page from both reclaim_page() or rmqueue(), while new
> returns pages only from rmqueue... What happens with page grabbed by
> rmqueue, BTW ? Or is there something out of picture I do not see?
> Petr
You are absolutely right, sorry. I will keep my eyes open a bit wider next
time. I put back Linus and linux-kernel to admit my mistake.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> - pre3:
> ...
>- Dave Jones: x86 setup fixes (recognize Pentium IV etc).
And then in test10-pre3 we find the following code added to
arch/i386/kernel/setup.c:
+ /* Pentium IV. */
+ if (c->x86 == 15) {
+ c->x86 = 6;
+ get_model_name(c);
+ goto name_decoded;
+ }
I believe the "c->x86 = 6" assignment to be broken.
If it's there to make uname -m return i686 for Pentium IV,
then surely that could be done differently. (See patch below.)
The assignment throws away perfectly good information, but worse,
it also destroys the implicit invariant that boot_cpu_data.x86
equals the "family" code as returned by CPUID. Low-level cpu-specific
code may then malfunction, or it will have to be updated to do its
own CPUID identification. Think about MTRRs, model-specific registers,
performance counters, and bug workarounds.
One harmless example is the "sep_bug" identification code in setup.c:
sep_bug = c->x86_vendor == X86_VENDOR_INTEL &&
c->x86 == 0x06 &&
c->cpuid_level >= 0 &&
(c->x86_capability & X86_FEATURE_SEP) &&
c->x86_model < 3 &&
c->x86_mask < 3;
Since initial Pentium IV processors have model 0 according to Intel's
Pentium IV supplement to the CPUID manual (AP-485), this code may
actually deduce that a Pentium IV has the bug (if the mask < 3).
Imagine a similar mistake in an MTRR/MSR/whatever driver...
I propose the following patch against test10-pre3:
--- 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.cMon Oct 16 23:13:21 2000
@@ -1548,7 +1548,6 @@
/* Pentium IV. */
if (c->x86 == 15) {
- c->x86 = 6;
get_model_name(c);
goto name_decoded;
}
--- 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 Mon Oct 16 23:14:42 2000
@@ -426,5 +426,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);
}
mtrr.c will need fixing too, but we can't really do that until Intel
releases a new IA-32 System Programming manual with Pentium IV updates.
/Mikael
-
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
Hi, > - BLKSSZGET added in common.h Why don't we give BLKSSZGET a new number and make the old one obsolete? I don't think it's used anywhere, as its result is pretty useless in userspace (and even if it's used somewhere, they have to copy the define anyway). This way we don't need that version check. bye, Roman - 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: mapping user space buffer to kernel address space
On Mon, 16 Oct 2000, Andrea Arcangeli wrote: > > If the page isn't locked swap_out will unmap it from the pte and anybody will > be able to start any kind of regular VM I/O on the page. Doesn't matter. If you have increased the page count, the page _will_ stay in the page cache. So everybody who wants to see the page that was mapped, will see it with no possibility of getting an alias. >This isn't what the > programmer expects If so, the programmer has shit for brains. That simple. >and that's not what I consider pinning. No. Because "pinning" is _stupid_. Imagine having two threads that both do direct IO from overlapping pages. YOU NEED TO COUNT THE PINNING. A "lock" bit is useless, and anybody who uses a lock bit is stupid and ends up having to serialize things for no good reason. Instead, the Linux answer is to say: pinning is bad, pinning is stupid, pinning is useless - so dont do it. Instead, we have the notion of "I have a reference to this page, don't let it go away". Sure, the page can be _unmapped_ (ie it is not pinned), but WHO CARES? Nobody. 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/
[patch-2.4.0-test10-pre3] logic of __alloc_pages_limit().
Hi Linus and Rik,
The same analysis I did for __alloc_pages() applies to
__alloc_pages_limit(), namely it can be optimized by looking at the logic
of 'page == NULL'. In both cases, of course, I checked the assembly
listing to make sure that my patch didn't make a worse code. It was always
a few instructions shorter and therefore worth it. (I didn't check whether
gcc produced fewer branches, I assume he did, otherwise he would be
totally braindead...).
Regards,
Tigran
--- linux/mm/page_alloc.c Sun Oct 15 20:40:38 2000
+++ work/mm/page_alloc.cMon Oct 16 22:39:13 2000
@@ -262,15 +262,17 @@
}
if (z->free_pages + z->inactive_clean_pages >= water_mark) {
- struct page *page = NULL;
+ struct page *page;
/* If possible, reclaim a page directly. */
- if (direct_reclaim && z->free_pages < z->pages_min + 8)
+ if (direct_reclaim && z->free_pages < z->pages_min + 8) {
page = reclaim_page(z);
- /* If that fails, fall back to rmqueue. */
- if (!page)
- page = rmqueue(z, order);
- if (page)
- return page;
+ /* If that fails, fall back to rmqueue. */
+ if (!page) {
+ page = rmqueue(z, order);
+ if (page)
+ return page;
+ }
+ }
}
}
-
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: mapping user space buffer to kernel address space
On Mon, Oct 16, 2000 at 11:29:27AM -0700, Linus Torvalds wrote: > The page count is (or should be) sufficient, and if it weren't sufficient > that would be a bug in the swap-out handling of anonymous or shm memory. I If the page isn't locked swap_out will unmap it from the pte and anybody will be able to start any kind of regular VM I/O on the page. This isn't what the programmer expects and that's not what I consider pinning. It just looks much saner to completly pin it and to keep it mapped as if it would be kernel memory marked as reserved and then mapped to userspace via remap_page_range. I don't see any particular benefit in allowing swap_out to mess with pinned pages that would make worthwhile not to lock them. Said that (and the above arguments are more a design issue) there's also a pratical problem that I can see in not taking the page locked. What will happen without the lock on the page is that swapout will unmap the pte while adding the page to the swap cache and while writing it to disk. Then the page will be clean and in the swap cache with reference count 2 because we take it pinned and because it's part of the swap cache. Then we do the DMA from disk to the page but the page is still considered clean from the VM because it's an unlocked swap cache page. But instead the contents of the page aren't in sync anymore with the contents of the on-disk counterpart of the swap cache after DMA completed. So that will again generate corruption because it breaks VM assumptions on the swap cache (even if it's more subtle to trigger than the other problems). Maybe even more subtle issue could arise by not taking the lock on the page while it's pinned. > refuse to see page locking or similar for this kind of pinning (counts are > recursive and re-entrant, a "lock bit" is not). Infact swapin_readahead was deadlocking exactly because lock bit isn't reentrant. But the fix for that deadlock looks worthwhile regardless of the pinning-user-memory-with-lock-bit issue. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: why my subscription has disappeared ? Re: test - plz ignore
On Mon, Oct 16, 2000 at 10:22:06PM +0100, Per Jessen wrote: > I haven't seen any traffic since Oct13 - is the list down ? Back then your email address started to bounce somehow. I have already forgotten the details, but when we get bounces (often quite a lot), we remove the offender's subscriptions.We let email to somebody's domain to stay in VGER's queue for at least 2d12h, then it *may* get into kill zone, but when oldest one exceeds 3d0h, (it begins to bounce) the whole queue to that domain gets axed along the subscriptions to it. Do check your email address functionality. Use http://zmailer.org/mxverify.html Always be wary of your email environment going boinkers. (We see a few ISP's with systems bouncing email "just because we are a bit loaded right now, we reject this, please send it again if you want to reach this person ...") (We don't, we remove the subscription.) > regards, > Per Jessen /Matti Aarnio - 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 to remove undefined C code
Matti Aarnio <[EMAIL PROTECTED]> writes: > On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote: > > Yes. In practice the usual question is whether the compiler will > > evaluate the operands from left to right or from right to left, > > but the compiler is within its rights to evaluate the operands in > > any order it wants. > > That depends mainly on question: Does your stack grow up or down ? No it doesn't. It depends mainly on whether the ABI for the machine says that arguments are pushed onto the stack in left-to-right or right-to-left order. You could do either on x86, for instance, and it has nothing to do with whether the x86 stack grows up or down. > > > Does this imply that even the evaluation of a function pointer > > > is itself undefined in terms of ordering? > > > > Yes. > >For things like lone pointer referral with pre/post inc/dec: > *p++ >it is well defined, but for things like: > *p++ + *p >it is not. (Will the second *p be evaluated before or after *p++ >post-increment ?) Non sequitur: I see no function pointers being evaluated here. - 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] max_loop module parameter for 2.2.x loop.c
This patch add the module parameter 'max_loop' to loop.c (like there is in 2.4). It's against 2.2.18pre16. Eric - 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
On Mon, Oct 16, 2000 at 10:38:41PM +0200, Roman Zippel wrote:
> > [now that you make me look at this, there is a flaw in fdisk there;
> > fixed in 2.10p]
>
> BLKSSZGET isn't defined for fdisk.c? :)
Indeed :-)
The current code looks like this:
- BLKSSZGET added in common.h
- in fdisk.c added linux_version_code() similar to the one in nfsmount.c.
- in fdisk.c sector_size code:
static void
get_sectorsize(int fd) {
#if defined(BLKSSZGET)
if (!user_set_sector_size &&
linux_version_code() >= MAKE_VERSION(2,3,3)) {
int arg;
if (ioctl(fd, BLKSSZGET, ) == 0)
sector_size = arg;
if (sector_size != DEFAULT_SECTOR_SIZE)
printf(_("Note: sector size is %d (not %d)\n"),
sector_size, DEFAULT_SECTOR_SIZE);
}
#else
/* maybe the user specified it; and otherwise we still
have the DEFAULT_SECTOR_SIZE default */
#endif
}
> BTW the problem is a bit bigger, I tried to partition a 4GB mo disk, what
> horribly breaks with current fdisk under 2.2. It results in an odd
> partition offset and you can't access any partition. So I need a fixed
> fdisk. As quick hack I simply reused BLKSSZGET, but now I have a fdisk,
> that only works with a fixed kernel.
Instead of the above, just use
static void
get_sectorsize(int fd) {
}
and use a -b option to specify the sector size.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.10.3: pc_keyb and q40_keyb cleanup
Andrea Arcangeli wrote: > > On Sun, Oct 15, 2000 at 03:48:55PM -0400, Jeff Garzik wrote: > > Changes: > > * both: we know we are in an interrupt, so > > s/spin_lock_irqsave/spin_lock/ > > There request_irq is not called passing the SA_INTERRUPT flag so the irq > handler is recalled with irqs enabled and in turn irqsave is necessary. hmmm. Can you elaborate on this a bit? I didn't know that bit about !SA_INTERRUPT, but why is irqsave necessary in these drivers? I don't see handle_kbd_event() being called from a timer or anything special like that.. -- 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: Patch to remove undefined C code
On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote: > > > $ The order of evaluation of the function designator, the > > > $ arguments, and subexpressions within the arguments is > > > $ unspecified, ... > > > > I sit surprised and corrected. With every version of every C compiler on > > every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using > > Manx C to E1 using Kai C++) the behavior has been the same for parameter > > lists as for the comma operator in this respect. > > Yes. In practice the usual question is whether the compiler will > evaluate the operands from left to right or from right to left, > but the compiler is within its rights to evaluate the operands in > any order it wants. That depends mainly on question: Does your stack grow up or down ? Machines where stack grows up are a bit rare, but they do exist. The CISC archetype, IBM S/360/370/390 has simple instruction to add a small positive offset value into pointer register, but not to substract it (nor have negative offsets). Thus most stackfull languages there have the stack growing up. Doing downwards-growing stack setup requires 1 extra register use, and one extra instruction per frame entry, plus considerably more for parameter push. (But it was a great beast to run Fortran-IV which didn't need stack, just subfunction invocation record -- at a static location unique for each subfunction --> no recursion supported.) > > Does this imply that even the evaluation of a function pointer > > is itself undefined in terms of ordering? > > Yes. For things like lone pointer referral with pre/post inc/dec: *p++ it is well defined, but for things like: *p++ + *p it is not. (Will the second *p be evaluated before or after *p++ post-increment ?) /Matti Aarnio - 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/
test - plz ignore
I haven't seen any traffic since Oct13 - is the list down ? regards, Per Jessen - 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: mapping user space buffer to kernel address space
Hi,
On Mon, Oct 16, 2000 at 12:08:54AM +0200, Andrea Arcangeli wrote:
> The basic problem is that map_user_kiobuf tries to map those pages calling an
> handle_mm_fault on their virtual addresses and it's thinking that when
> handle_mm_fault returns 1 the page is mapped. That's wrong.
Good point --- good work.
> Furthmore in 2.4.x SMP (this couldn't happen in 2.2.x SMP at least) the page
> can also go away from under us even assuming handle_mm_fault did its work right
> by luck.
Hmm --- we had the BKL to protect against this when this code was
first done for 2.3. That's definitely a regression, agreed.
> I'm also not convinced that only increasing the page count in the critical
> section in map_user_kiobuf is enough because swap_out doesn't care about the
> page count (in 2.2.x rawio it's taking the page lock). The page count is
> significant as a "pin" only for the page cache and not for anonymous or shm
> memory for example. swap_out can mess with anonymous memory with a page
> count > 1 for example.
This bit I think we have to talk about --- I'm not sure I agree. I
dropped that automatic-page-locking from the map_user_kiobuf code
quite deliberately.
Basically, we don't care at all about pinning the pte in the page
tables during the IO. All we really care about is preserving the
mapping between the user's VA and the physical page. If the VM
chooses to unmap the page temporarily, then as long as the page
remains in physical memory, then a subsequent page fault will
reestablish the mapping. The swap cache and page cache are sufficient
to make this guarantee.
It's an important distinction, because we really would rather avoid
taking the page lock. If you happen to have the same page mapped into
multiple VAs within the region being written, should the kernel
object? If you're writing that region to disk, then it really
shouldn't matter. For some other applications, it might be important,
which is why I wanted to keep the map_user_kiobuf() and lock_kiobuf()
functions distinct.
Note that if you have a threaded application and another thread goes
messing with the MM while your IO is in progress, then it's possible
that the pages in the user's VA at the end of the IO are not the same
as the ones that were there at the start. No big deal, that's no
different to the situation if you have any other read or write going
on in parallel with other MM activity.
One final point: the new code,
> + if (!(map = follow_page(ptr, write))) {
> + char * user_ptr = (char *) ptr;
> + char c;
> spin_unlock(>page_table_lock);
> + up(>mmap_sem);
> + if (get_user(c, user_ptr))
> + goto out;
> + if (write && put_user(c, user_ptr))
> + goto out;
> + down(>mmap_sem);
> + goto refind;
looks unnecessarily messy. We don't need the get_user() in ptrace:
why do we need it here? Similarly, the put_user should be dealt with
by the handle_mm_fault. We already absolutely rely on the fact that
handle_mm_fault never continually fails to make progress for ever. If
it did, then a page fault could produce an infinite loop in the
kernel.
Once I'm back in the UK I'll look at getting map_user_kiobuf() simply
to call the existing access_one_page() from ptrace. You're right,
this stuff is racy, so we should avoid duplicating it in memory.c.
Cheers,
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/
Re: Patch to remove undefined C code
On Mon, 16 Oct 2000, Mike Castle wrote: > On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote: > > tmp = *p++; > > *q = f(tmp, *p++); > > return p; > > > > is equivalent to more idiomatic > > > > *q = f(p[0], p[1]); > > return p+2; > > > Which gets better assembler out of various versions of gcc? On which platform? If it would be VAX - sure, autoincrement rocks, but for something like x86 I would expect the second form to do better. Besides, it's more readable and is harder to fsck up when you are modifying the code. - 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 to remove undefined C code
On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote: > tmp = *p++; > *q = f(tmp, *p++); > return p; > > is equivalent to more idiomatic > > *q = f(p[0], p[1]); > return p+2; Which gets better assembler out of various versions of gcc? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 to remove undefined C code
>-Original Message- >From: Alexander Viro [mailto:[EMAIL PROTECTED]] [snip] > >No arguments here, but proposed fixes were remarkably ugly. Example: > >tmp = *p++; >*q = f(tmp, *p++); >return p; > >is equivalent to more idiomatic > >*q = f(p[0], p[1]); >return p+2; > >And example with copying the string up to the comma... Yuck. Legal C != >decent C. Strongly agree. If the changes were an elegant solution to the ambiguities I never would have cared. In fact the whole reason I bothered to read the patch in the first place was that I feel strongly that something like that _was_ needed, but the solutions really seemed inferior to the original code in terms of elegance of expression. (Well some of the original code was pretty ugly too :-) --Jonathan-- - 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 to remove undefined C code
Jonathan George <[EMAIL PROTECTED]> writes: > > $ The order of evaluation of the function designator, the > > $ arguments, and subexpressions within the arguments is > > $ unspecified, ... > >-- > > I sit surprised and corrected. With every version of every C compiler on > every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using > Manx C to E1 using Kai C++) the behavior has been the same for parameter > lists as for the comma operator in this respect. Yes. In practice the usual question is whether the compiler will evaluate the operands from left to right or from right to left, but the compiler is within its rights to evaluate the operands in any order it wants. > Does this imply that even the evaluation of a function pointer > is itself undefined in terms of ordering? Yes. > >"Premature optimization is the root of all evil." > >--D. E. Knuth, "Structured Programming with go to Statements" > > Absolutely true. Good sigmonster, have $TREAT. > I would be really interested to see how well the kernel compiler does at > optimizing out all of these new tmp variables in terms of the resulting > register utilization and performance. At least an assembler code size > comparison is in order for each of these individual cases. I agree with you and Al Viro that the proposed fixes were less than desirable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] mdacon SMP fix
I will test this soon, hopefully. I move tomorrow, and will be bringing my
X environment and my audio environment into my dual P200 machine. This is
against which kernel? 2.4.0-test10 prepatch, or?
On Mon, 16 Oct 2000, James Simmons wrote:
>
> ANyone with a MDA card on a SMP or even UP machione please test this
> patch. This patch should fix any SMP deadlocks that could happen with
> a MDA card. Thank you.
>
> --- mdacon.c.orig Wed Oct 11 18:09:01 2000
> +++ mdacon.c Wed Oct 11 18:14:18 2000
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -44,6 +45,7 @@
> #include
> #include
>
> +static spinlock_t mda_lock = SPIN_LOCK_UNLOCKED;
>
> /* description of the hardware layout */
>
> @@ -80,7 +82,6 @@
> MODULE_PARM(mda_last_vc, "1-255i");
> #endif
>
> -
> /* MDA register values
> */
>
> @@ -110,23 +111,24 @@
> {
> unsigned long flags;
>
> - save_flags(flags); cli();
> + spin_lock_irqsave(_lock, flags);
>
> outb_p(reg, mda_index_port);
> outb_p(val, mda_value_port);
>
> - restore_flags(flags);
> + spin_unlock_irqrestore(_lock, flags);
> }
>
> static void write_mda_w(unsigned int val, unsigned char reg)
> {
> unsigned long flags;
>
> - save_flags(flags); cli();
> + spin_lock_irqsave(_lock, flags);
>
> outb_p(reg, mda_index_port); outb_p(val >> 8, mda_value_port);
> outb_p(reg+1, mda_index_port); outb_p(val & 0xff, mda_value_port);
>
> + spin_unlock_irqrestore(_lock, flags);
> restore_flags(flags);
> }
>
> @@ -134,15 +136,14 @@
> {
> unsigned long flags;
>
> - save_flags(flags); cli();
> + spin_lock_irqsave(_lock, flags);
>
> outb_p(reg, mda_index_port);
> outb (val, mda_value_port);
>
> udelay(20); val = (inb_p(mda_value_port) == val);
>
> - restore_flags(flags);
> -
> + spin_unlock_irqrestore(_lock, flags);
> return val;
> }
>
>
RE: Patch to remove undefined C code
-Original Message- From: Ben Pfaff [mailto:[EMAIL PROTECTED]] >Jonathan George <[EMAIL PROTECTED]> writes: > >> This patch has many bogus corrections where new variables were created, but >> the order of evaluation is already unambiguous. >> >> For example each comma separated clause in an expression is guaranteed to be >> completely evaluated before the next comma separated clause Including >> Assignments. > >No, that is not true in general. When the comma in question is >the comma operator, it is true. But when the comma separates >arguments to a function, it is not: the order of evaluation of >function arguments is implementation dependent. See C89 section >6.3.2.2 "Function calls": > > $ The order of evaluation of the function designator, the > $ arguments, and subexpressions within the arguments is > $ unspecified, ... >-- I sit surprised and corrected. With every version of every C compiler on every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using Manx C to E1 using Kai C++) the behavior has been the same for parameter lists as for the comma operator in this respect. Does this imply that even the evaluation of a function pointer is itself undefined in terms of ordering? >"Premature optimization is the root of all evil." >--D. E. Knuth, "Structured Programming with go to Statements" Absolutely true. However, optimization of well tested, and algorithmically validated kernel code in a time critical section does not constitute premature optimization as I'm sure Donald would agree. I would be really interested to see how well the kernel compiler does at optimizing out all of these new tmp variables in terms of the resulting register utilization and performance. At least an assembler code size comparison is in order for each of these individual cases. That is my only real concern (other than all of that syntactically ambiguous code I have written over the last 15 years ;-) is that critical performance not be compromised in the kernel. --Jonathan-- - 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 to remove undefined C code
On 16 Oct 2000, Ben Pfaff wrote: > Jonathan George <[EMAIL PROTECTED]> writes: > > > This patch has many bogus corrections where new variables were created, but > > the order of evaluation is already unambiguous. > > > > For example each comma separated clause in an expression is guaranteed to be > > completely evaluated before the next comma separated clause Including > > Assignments. > > No, that is not true in general. When the comma in question is > the comma operator, it is true. But when the comma separates > arguments to a function, it is not: the order of evaluation of > function arguments is implementation dependent. See C89 section > 6.3.2.2 "Function calls": [snip] No arguments here, but proposed fixes were remarkably ugly. Example: tmp = *p++; *q = f(tmp, *p++); return p; is equivalent to more idiomatic *q = f(p[0], p[1]); return p+2; And example with copying the string up to the comma... Yuck. Legal C != decent C. - 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
Hi, > Concerning fdisk, luckily you are mistaken - its source says > > #if defined(BLKSSZGET) && defined(HAVE_blkpg_h) > > so that it will not use the broken BLKSSZGET of 2.2. ??? BLKSSZGET has exactly the same ioctl number in 2.2 and 2.4, so if I compile fdisk under 2.4 and try to use it under 2.2, it will break. I saw the above test, but that is a compile time check not a run time check. Am I missing something here? BTW the problem is a bit bigger, I tried to partition a 4GB mo disk, what horribly breaks with current fdisk under 2.2. It results in an odd partition offset and you can't access any partition. So I need a fixed fdisk. As quick hack I simply reused BLKSSZGET, but now I have a fdisk, that only works with a fixed kernel. > [now that you make me look at this, there is a flaw in fdisk there; > fixed in 2.10p] BLKSSZGET isn't defined for fdisk.c? :) BTW sfdisk isn't fixed at all for different sector sizes. bye, Roman - 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: A patch to loop.c for better cryption support
On Mon, Oct 16, 2000 at 06:23:32PM +, David Wagner wrote: (snip) > > Using SHA1(sector #) should be ok, as long as you don't expect your > plaintexts to have similar patterns. (If you do think your plaintexts > might begin with the SHA1-hashes of sector numbers, you could use a > "keyed hash", or more precisely, a pseudorandom function. For instance, > you could encrypt the sector number using a secret IV-generation key.) I think our discussion may be drifting a bit. Perhaps revisiting some crypto system fundamentals might be helpful. The loop device driver provides a transfer module API, nothing more. Placing encryption code (which includes hashes) into the loop device driver is not appropriate. The crypto functionality should be wholly contained in the transfer modules. IMHO, all that we should ask of the loop.c transfer API is: a) Type of transformation needed (encipher or decipher). b) Data bits to be transformed and length. c) Key bits and length. d) A *UNIQUE* IV seed associated *ONLY* (!!) with the data in step b) above. A design goal of all modern crypto systems is that the security of the system rest soley in the key. IV's must be unique, not secret. Unique IVseed means "never duplicated". An increasing block | sector # is one means to meet the unique requirement. Transfer modules are free to further mangle the IVseed via whatever method they feel is appropriate. Reed H. Petty [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/
[2.4.0-test10-pre3] UART401 problem causes Oops.
I recently compiled 2.4.0-test10-pre3, and was torture-testing it...I hadnt played any MIDI files in a while, so while one was playing (on my waveblaster GM daughterboard, thru UART401), the gave an Oops. After doing some detective work, I found that the culprit was a small daemon I had running that does a "double-rmmod -a" every X seconds. It was rmmod'ing the uart401 module while it was in use. I confirmed that while the MIDI file was playing, the lsmod usage count was zero, and I could manually remove it. (causing an instant oops) It looks like the UART401 (this is a Sound Blaster 16 ISA non-PnP card) module is not marking itself used while it's being accessed. -- Mark Orr [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 to remove undefined C code
Jonathan George <[EMAIL PROTECTED]> writes: > This patch has many bogus corrections where new variables were created, but > the order of evaluation is already unambiguous. > > For example each comma separated clause in an expression is guaranteed to be > completely evaluated before the next comma separated clause Including > Assignments. No, that is not true in general. When the comma in question is the comma operator, it is true. But when the comma separates arguments to a function, it is not: the order of evaluation of function arguments is implementation dependent. See C89 section 6.3.2.2 "Function calls": $ The order of evaluation of the function designator, the $ arguments, and subexpressions within the arguments is $ unspecified, ... -- "Premature optimization is the root of all evil." --D. E. Knuth, "Structured Programming with go to Statements" - 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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Douglas Gilbert wrote:
> I if cdrecord bypassed the sg driver and spoke to the
> cdrom driver directly. I know the CDROM_SEND_PACKET
> ioctl() is in place for lk 2.4 but from which version
> has it been functional in the lk 2.2 series?
But the write command is not included in any source tree yet, and it works.
> Jens, do you know of some example code that shows the
> CDROM_SEND_PACKET ioctl being exercised for non-trivial
> work? Something that could be sent onto Joerg Schilling.
Jens is out of pocket and is somewhere over the Atlantic by now.
I may have to go and get him at the airport tonight.
We will have a month to fight between the two of us to get it correct.
I have all the devices local, there are some issues in getting things to
him because of availablity of early product development in the industry.
I expect by 10/20/2000 you will see Direct ATAPI published.
> > Aside: Browsing through the cdrecord 10a4 source does flag a specific
> > note in the mmc driver about ATIP not being supported on the 7100, but
> > seems to suggest that a failure to read the ATIP data's non-fatal...
/dev/hdf on /dvdrom type iso9660 (ro,noexec,nosuid,nodev)
/dev/hde on /dvdram type ext2 (rw,noexec,nosuid,nodev)
hdparm -i /dev/hde
/dev/hde:
Model=MATSHITADVD-RAM LF-D210, FwRev=A106, SerialNo=
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2 udma0 udma1 udma2
Drive Supports : Reserved : ATA-4
This will be fun when it is released.
Imagine direct read/write access to DVD regardless of filesystems.
It should also do CD-RW's, but not tested.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
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: Updated 2.4 TODO List
Hi! > While you should report drivers or other kernel functions > that don't work, I don't think that just saying that > something is broken is sufficient. Well, that driver really is broken. It uses tq_scheduler in strange way, so it has unbound ping times. (Up to 20 seconds). It breaks under heavy load. Pavel > > Hi! > > > > > 7. Obvious Projects For People (well if you have the hardware..) > > > > > > * Make syncppp use new ppp code > > > * Fix SPX socket code > > > > USB: plusb is b0rken. > > Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
Also sprach Abramo Bagnara: } } Isn't this more efficient? } n = (x>>32) | (x<<32); } n = ((n & 0xLL)<<16) | (n & 0xLL)>>16; } n = ((n & 0x00ff00ff00ff00ffLL)<<8) | (n & 0xff00ff00ff00ff00LL)>>8; } } 6 shift } 4 and } 3 or } Plus 3 assigns...but they may get optimized out. :) } instead of } } 8 shift } 8 and } 7 or } -- || Bill Wendling[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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
Mark Cooke wrote: > On Mon, 16 Oct 2000, Andre Hedrick wrote: > > > Yes but there is a way to do this directly now, the question is can the > > user-space apps change to go both ways. > > Hi Andre, > > Is there any tool / test code that you know of to 'do this directly' - > I'm wanting to try to avoid ade-scsi translation, and show the drive's > still working okay for blanking. One less variable in the soup to > worry about then. As far as I know, cdrecord interfaces to Linux either via the sg or pg devices. No-one would be happier than I if cdrecord bypassed the sg driver and spoke to the cdrom driver directly. I know the CDROM_SEND_PACKET ioctl() is in place for lk 2.4 but from which version has it been functional in the lk 2.2 series? Jens, do you know of some example code that shows the CDROM_SEND_PACKET ioctl being exercised for non-trivial work? Something that could be sent onto Joerg Schilling. > Aside: Browsing through the cdrecord 10a4 source does flag a specific > note in the mmc driver about ATIP not being supported on the 7100, but > seems to suggest that a failure to read the ATIP data's non-fatal... Sg has an ioctl called SG_SET_TRANSFORM which is only relevant to the ide-scsi driver. As far as I know, no applications use it. Still it is not clear why Mark's system would work on a UP machine but fail on a SMP box. Doug Gilbert - 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: Documentation for the code in nfs-utils-0.1.9.1
> " " == Samar Sharma <[EMAIL PROTECTED]> writes: > Does anyone have a pointer to some documents/books for the > nfs-utils code ? (i.e., code for mountd, statd etc) That depends on what you need. If the question is about the protocols, then the best source I've found is the X/Open doc at http://www.opengroup.org/publications/catalog/c702.htm that covers the NFS + mount + NLM (locking) + NSM (statd) protocols, and is available on the Web. If, however, you're talking about documentation on the specific Linux implementations, then I'm afraid that the best I can do is to point you to the actual source code. You'll find the latest version (and/or instructions about how to access the CVS repository) on http://sourceforge.net/projects/nfs/ Cheers, Trond - 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
On Mon, Oct 16, 2000 at 08:04:27PM +0200, Roman Zippel wrote: > I noticed that behaviour of BLKSSZGET changed between 2.2 and 2.4. One of > the users will be fdisk, as soon as it is compiled with 2.4 kernel > headers, but then fdisk will be no longer usable under 2.2! > My question now is, wouldn't it be better to use a new ioctl (like > BLKHSSZGET) and keep the old behaviour of BLKSSZGET? No, BLKSSZGET has only a single purpose, and it is right in 2.4 and wrong in 2.2. Maybe I should send Alan a BLKSSZGET patch. We already agreed in email that it was wrong, but then did not do anything about it. Concerning fdisk, luckily you are mistaken - its source says #if defined(BLKSSZGET) && defined(HAVE_blkpg_h) so that it will not use the broken BLKSSZGET of 2.2. [now that you make me look at this, there is a flaw in fdisk there; fixed in 2.10p] Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Am I the only one with scsi-ide CDR problems?
On Sat, 14 Oct 2000, David Riley wrote: > safemode wrote: > > > > I'm just wondering if I'm the only person who has had problems with > > 2.4.0-test9 recording on ide-scsi cdr's? > > Nobody has posted anything about it and the test10-prex changefiles don't > > mention it. cdrecord reports very weird results when scanning the scsi > > bus whereas dmesg shows what one would expect of the ide-scsi detection. > > anyone? > > Actually, I think it's on the TODO list for 2.4. That's definitely the > sort of thing to fix. I think the exact syntax was "cdrecord produces > shiny coasters" or something similar. It actually is in the "Fixed" section of the TODO list, and it did seem to be working for me on the weekend, as I burnt a couple of disks (one at 8x) under 2.4.0-test9 without any errors. That's with a relatively new Matushita 8/4/32 CD-RW drive and cdrecord 1.8. Scott -- = Scott Murrayemail: [EMAIL PROTECTED] http://www.interlog.com/~scottm ICQ: 10602428 - "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness" - 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 to remove undefined C code
At 01:21 PM 10/16/00, Jeff Garzik wrote: >Bernd Schmidt wrote: > > diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c > linux-2.4-fixed/drivers/net/tulip/tulip_core.c > > --- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000 > > +++ linux-2.4-fixed/drivers/net/tulip/tulip_core.c Mon Oct 16 > 15:40:12 2000 >[...] > > @@ -944,9 +946,9 @@ > > > > /* Fill the final entry with our physical address. */ > > eaddrs = (u16 *)dev->dev_addr; > > - *setup_frm++ = *setup_frm++ = eaddrs[0]; > > - *setup_frm++ = *setup_frm++ = eaddrs[1]; > > - *setup_frm++ = *setup_frm++ = eaddrs[2]; > > + *setup_frm++ = eaddrs[0]; *setup_frm++ = eaddrs[0]; > > + *setup_frm++ = eaddrs[1]; *setup_frm++ = eaddrs[1]; > > + *setup_frm++ = eaddrs[2]; *setup_frm++ = eaddrs[2]; > > > > spin_lock_irqsave(>lock, flags); > > Looking at the above code, I noticed that there are a lot of ++ operations. I rewrote the code as: setup_from[0] = setup_from[1] = eaddrs[0]; setup_from[2] = setup_from[3] = eaddrs[1]; setup_from[4] = setup_from[5] = eaddrs[2]; setup_from += 6; I compiled using "gcc -S -Wall -O2 -fomit-frame-pointer -m486" to generate the assembler code. The old code is 17 instructions long and the new code is 11 instructions. As well as being shorter, simple timing test indicate that the new code is significantly quicker. David David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] 514 W. Keech Ave. www.osagesoftware.com Ann Arbor, MI 48103 voice: 734.821.8800fax: 734.821.8800 - 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/
Problems with agpgart on MVP3
On a RedHat 7.0 stock kernel, agpgart finds the AGP aperture the first time it's loaded, but if it's unloaded and reloaded, it gets confused and seems to think the aperture is located at 0. At this point, starting the Xserver (3.x or 4.x) or loading DRM drivers manually freezes the system. SysRq doesn't work. This is on an Epox MVPG3-M board (VIA MVP3 chipset) running an AMD K6-2/400 and a Matrox G200 accelerator. I've tried this on RedHat 6.2's most recent kernel as well as a few 2.4.0-testX kernels, and the result is readily reproducible on all versions of the kernel. matroxfb/vesafb don't seem to affect this problem either way. relevant dmesg output and lspci -v are attached. Please cc: me, as I'm not subscribed to this list. -ed 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04) Flags: bus master, medium devsel, latency 16 Memory at e000 (32-bit, prefetchable) Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: e400-e7ff Prefetchable memory behind bridge: e800-e8ff 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 06) Subsystem: VIA Technologies, Inc. VT82C596/A/B PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 64 I/O ports at d000 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at d400 00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050 Flags: medium devsel 00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02) Subsystem: Unknown device 9292:0202 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at d800 Memory at ea00 (32-bit, non-prefetchable) Expansion ROM at e900 [disabled] 00:0a.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128 Flags: bus master, slow devsel, latency 64, IRQ 12 I/O ports at dc00 Capabilities: [dc] Power Management version 1 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) Subsystem: Realtek Semiconductor Co., Ltd. RT8029(AS) Flags: medium devsel, IRQ 5 I/O ports at e000 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G200 AGP Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at e800 (32-bit, prefetchable) Memory at e400 (32-bit, non-prefetchable) Memory at e500 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 Capabilities: [f0] AGP version 1.0 Linux version 2.2.16-22 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Aug 22 16:16:55 EDT 2000 Detected 400913 kHz processor. ide_setup: ide0=dma ide_setup: ide1=dma Console: colour VGA+ 80x25 Calibrating delay loop... 799.54 BogoMIPS Memory: 127376k/131072k available (1048k kernel code, 408k reserved, 1728k data, 64k init, 0k bigmem) Dentry hash table entries: 262144 (order 9, 2048k) Buffer cache hash table entries: 131072 (order 7, 512k) Page cache hash table entries: 32768 (order 5, 128k) VFS: Diskquotas version dquot_6.4.0 initialized CPU: L1 I Cache: 32K L1 D Cache: 32K CPU: AMD AMD-K6(tm) 3D processor stepping 0c Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb4d0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: 00:38 [1106/0596]: Work around ISA DMA hangs (00) Activating ISA DMA hang workarounds. Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 131072 bhash 65536) Linux IP multicast router 0.06 plus PIM-SM Initializing RT netlink socket Starting kswapd v 1.5 Detected PS/2 Mouse Port. Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A pty: 256 Unix98 ptys configured apm: BIOS version 1.2
Re: Multiple sound cards?
David Lang wrote: > > -BEGIN PGP SIGNED MESSAGE- > > where can I look to find what hardware to look for/avoid? The es1371's are especially rock solid stable. If you have PCI and its supported, you are ok I think... 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: Multiple sound cards?
-BEGIN PGP SIGNED MESSAGE- where can I look to find what hardware to look for/avoid? David Lang On Mon, 16 Oct 2000, Jeff Garzik wrote: > David Lang wrote: > > Does the kernel support multiple sound cards in one machine? > > It depends on the driver and hardware, but in general yes. PCI cards > are your best bet, you can pretty much stick as many of those in your > machine as you would like, without having to worry about IRQ/DMA/ioport > conflicts. > > > > if so what are the devices they use (i.e. /dev/audio0, /dev/audio1, etc or > > what?) > > yep. /dev/dspX, /dev/audioX, etc. > > -- > Jeff Garzik| The difference between laziness and > Building 1024 | prioritization is the end result. > MandrakeSoft | > -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQEVAwUBOetOhD7msCGEppcbAQE6Nwf+JTLZL0mjvq76Xlf+x2IipeEG/nfqX8w/ Sf3aRimvhERWRsgBAZ8q7p8jpZt8mQlObwJiYmV5kZSMhIsxMfUVV0Kb2C0Y7qyN 9mKPJHP5uT/Rf3+a48vczDMVnZA8PKYoqI0ji+LcUJE24F7sXEgECWKuNTOCqdwW CxP/g2Yq+Db4xfXRwSV48TMXZb6uChFQya8tgNNbMqlLevnV4FgdGY3aZatmr77P tmTjhFzT763pCNqrW01LncxnVh7itY0l3wyBSKSdqNv9EWlFN8sUSUtpinnwIFTa SvUTFfXAGG+ysRhwx00cOJwJGz95I99UAa49sTRXoclgG5ZamrIqzg== =KFjY -END PGP SIGNATURE- - 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: Multiple sound cards?
David Lang wrote: > Does the kernel support multiple sound cards in one machine? It depends on the driver and hardware, but in general yes. PCI cards are your best bet, you can pretty much stick as many of those in your machine as you would like, without having to worry about IRQ/DMA/ioport conflicts. > if so what are the devices they use (i.e. /dev/audio0, /dev/audio1, etc or > what?) yep. /dev/dspX, /dev/audioX, etc. -- 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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Andre Hedrick wrote: > Yes but there is a way to do this directly now, the question is can the > user-space apps change to go both ways. Hi Andre, Is there any tool / test code that you know of to 'do this directly' - I'm wanting to try to avoid ade-scsi translation, and show the drive's still working okay for blanking. One less variable in the soup to worry about then. Aside: Browsing through the cdrecord 10a4 source does flag a specific note in the mmc driver about ATIP not being supported on the 7100, but seems to suggest that a failure to read the ATIP data's non-fatal... Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - 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: A patch to loop.c for better cryption support
Ingo Rohloff wrote: >-snip--- > As an example, it is not true that CBC encryption > can use an arbitrary nonce initialization vector: it is essential > that the IV be unpredictable by the adversary. (To see this, suppose > the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp- > tion of 0x followed by an encryption of > 0x0001 is recognizably distinct from a (first) encryption > of 0x followed by an encryption of > 0x. Clearly this violates violates the notion of a > secure encryption sketched in Section 2.) >-snip--- > >So I think what is written in "Applied Cryptography" (by Bruce Schneier) >is correct. A sequence is ok, as long as you can't predict the start >of the sequence. No, a sequence is not ok, even if the beginning is unpredictable. Why? The encryption of 0 with IV v followed by encryption of 1 with IV v+1 is distinguishable from the reverse. (Because, with high probability, v and v+1 differ only in their low bit.) The problem is that the patterns in the IV sequence can interact with patterns in the plaintext. And, if the plaintext is patterned (e.g., ASCII-encoded English), there is a reasonable chance that you can get two plaintexts which start with blocks that differ only in their low bit; and this is the case that leads to the bad interaction, when you use a counter as your IV sequence. Using SHA1(sector #) should be ok, as long as you don't expect your plaintexts to have similar patterns. (If you do think your plaintexts might begin with the SHA1-hashes of sector numbers, you could use a "keyed hash", or more precisely, a pseudorandom function. For instance, you could encrypt the sector number using a secret IV-generation key.) - 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: A patch to loop.c for better cryption support
Ingo Rohloff wrote: >> There is a paper about why it is a bad idea to use >> sequence numbers for CBC IV's. I just have to find the reference to it. > >Does this mean sequence as in 0,1,2,3,4 ... or does this mean >any pre-calculate-able sequence ? In the former case we might just use >a simple one way hash-function over the requested sector number. It just means that 0,1,2,3,... is bad. Using SHA1(sector #) should be ok. But do think carefully about what happens when you modify a sector!! In particular, will you be re-using the old IV when you write the new data? That could be problematic. - 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: mapping user space buffer to kernel address space
Hi, On Fri, Oct 13, 2000 at 12:30:49PM +0100, Malcolm Beattie wrote: > free_kiovec(1, );/* does an implicit unlock_kiovec */ > > It doesn't do an unmap_kiobuf(iobuf) so I don't understand where > the per-page map->count that map_user_kiobuf incremented gets > decremented again. Anyone? The 2.4 raw code I'm looking at does an explicit unmap_kiobuf after each brw_kiovec(). > Lowlevel I/O on a kiovec can be done > with something like an ll_rw_kiovec which sct said was going to get > put in but since I haven't read anything more recent than > 2.4.0-test5 at the moment, I can't say if it's there or what it > looks like. It's being maintained inside the SGI XFS tree right now. They've got it pretty stable under XFS load so I'll probably put together the ll_rw_kio functionality using their low level code the next time I do a kiovec release. I believe that the XFS tree has 2.4.0-test9 support for this code. Cheers, 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/
Re: large memory support for x86
BTW, this fork program did appear to kill about 2 sun servers here...
The linux kernel v2.2.16 that they were running survived fine.
On Thu, 12 Oct 2000, Richard B. Johnson wrote:
> On Thu, 12 Oct 2000, Oliver Xymoron wrote:
>
> > On Wed, 11 Oct 2000, Kiril Vidimce wrote:
> >
> > > My primary concern is whether a process can allocate more than 4 GB of
> > > memory, rather than just be able to use more than 4 GB of physical
> > > memory in the system.
> >
> > Define allocate. There are tricks you can play, but userspace is still a
> > flat 32-bit address space per-process.
> >
>
> --- per process. Which means, in principle, that one could have 100
> processes that are accessing a total of 400 Gb of virtual memory.
>
> It gets to be a bit less than that, though. Process virtual address
> space doesn't start at 0
>
> Script started on Thu Oct 12 13:25:45 2000
> cat xxx.c
> main()
> {
> printf("main() starts at %p\n", main);
> }
> # gcc -o xxx xxx.c
> # ./xxx
> main() starts at 0x8048488
> # exit
> exit
> Script done on Thu Oct 12 13:26:08 2000
>
>
>
> 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/
>
-
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: Device Driver
> >Every closed source piece of software is unacceptable in a standard kernel > >: > > > >-hh We can't debug it > >- We depend on the guys / girls that maintain the binary image > >- It's a security risk. > > > Aren't there other examples where firmware is supplied in a struct > which is initialized to the needed binary values? Seems like Linux > doesn't need every bit of source (probably for some completely other > processor or ASIC, maybe written in FORTH) included as part of the > kernel. Possible, off course. Binary firmware probably the one being least to worry about. Binary modules can't be debugged, en god knows what's in them. The last sentence also plays with firmware, who nows what influence it has on the system. I don't trust thing I don't have the source of. > > johnh Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SIGHUP not reaching pppd
Im running my linux box as a RAS using pppd 2.3.7 on kernel version 2.2.5. What we see is that if we disconnect more than 60 sessions in an instant only 60 or so pppd go away and not the rest.. Secondly what we have seen is that after there have been about more than 2 connections / disconnections SIGHUP on a few cases does not reach the pppd process and though ive closed the master handle on my gateway the pppd (the slave) still hangs around HAs any one come accross this problem.. jayant - 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 to remove undefined C code
This patch has many bogus corrections where new variables were created, but the order of evaluation is already unambiguous. For example each comma separated clause in an expression is guaranteed to be completely evaluated before the next comma separated clause Including Assignments. It seems as if about half of the patched code simply makes it easier for the inexperienced C programmer to understand without actually fixing linguistic ambiguities, and at the same time introducing new variables which will clutter up the registers and the cache lines. Please don't apply this patch without consideration. --Jonathan--- - 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/
BLKSSZGET change will break fdisk
Hi, I noticed that behaviour of BLKSSZGET changed between 2.2 and 2.4. One of the users will be fdisk, as soon as it is compiled with 2.4 kernel headers, but then fdisk will be no longer usable under 2.2! My question now is, wouldn't it be better to use a new ioctl (like BLKHSSZGET) and keep the old behaviour of BLKSSZGET? bye, Roman - 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/
Documentation for the code in nfs-utils-0.1.9.1
Does anyone have a pointer to some documents/books for the nfs-utils code ? (i.e., code for mountd, statd etc) Thanks. Samar - 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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Ricky Beam wrote: > There are specific notes about the HP 7100 drives not working corectly due > to bad command translations. That was supposed to have been fixed years > ago. Hi Ricky, And I know it was working on this very machine some time in the past with a 2.2.x. Where are you seeing these notes ? Only refs to the 7100 I can see are for patching in atapi support into 2.0.x :) (quick poke around the doc directory in the rh7 cdrecord-1.9 package / looking at the web site) Where did you see this noted ? I have the latest HP firmware (3.01) loaded on the 7100i, so the notes wrt firmware 2.02 I found on http://www.fadden.com/cdrfaq/faq05.html#[5-1-5] hopefully got resolved. *source for the very latest cdrecord alpha (10a4) is just downloading* Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - 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: Updated 2.4 TODO List
Pavel, While you should report drivers or other kernel functions that don't work, I don't think that just saying that something is broken is sufficient. ~Randy > Hi! > > > 7. Obvious Projects For People (well if you have the hardware..) > > > > * Make syncppp use new ppp code > > * Fix SPX socket code > > USB: plusb is b0rken. > Pavel - 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 to remove undefined C code
Bernd Schmidt wrote:
>
> +
> +#define ___swab64(x) \
> +({ \
> + __u64 __x = (x); \
> + ((__u64)( \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) << 56) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) << 40) | \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) << 24) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) << 8) | \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) >> 8) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) >> 24) | \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) >> 40) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) >> 56) )); \
> +})
Isn't this more efficient?
n = (x>>32) | (x<<32);
n = ((n & 0xLL)<<16) | (n & 0xLL)>>16;
n = ((n & 0x00ff00ff00ff00ffLL)<<8) | (n & 0xff00ff00ff00ff00LL)>>8;
6 shift
4 and
3 or
instead of
8 shift
8 and
7 or
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica
Via Emilia Interna, 140 Phone: +39.0546.656023
48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023
ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Alan Cox wrote: > > >Its a message from the drive politely requesting cd-record to talk valid > > >commands. But as ide-scsi touches some commands (remapping old ones that are > > >not supported on ATAPI) its possible to be kernel > > > > Umm, doesn't cdrecord know how to address IDE devices directly? > > IDE cd burners talk ATAPI. ATAPI is just a scsi variant. SCSI won the battle > at the protocol level > > IDE ATAPI is SCSI protocol subset > SCSI bus is SCSI protocol > USB mass storage is SCSI protocol subset > Fibre channel is SCSI protocol > > etc Yes but there is a way to do this directly now, the question is can the user-space apps change to go both ways. We will be able to do direct rw to dvd-ram soon (patch to be released). Also with the new drop and burn standard that is in the works, the burning engin will be in the device and remove the burden of support form the OS. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Device Driver
Andre Hedrick wrote: > > > > I don't understand why you say this... CompactFlash, for example, is a > > solid-state HDD device, and it speaks ATA just as well as any disk. > > No special binaries required. > > This is my point. > > www.platypustechnology.com SSD/HDD's require a firmware load to make them > become whatever, in this case storage thingy's. > > If it was going to be a storage solution, why create something that does > not conform to T10/T13 rules. But then we have the beloved MTD's. > Ok, yes now I get it. Yes, this is stupid. Anyone here have any experience with SmartMedia and if they are sane or stupid? -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/
Re: 2.2.18pre16 and USB_UHCI_ALT
On Mon, Oct 16, 2000, David Rees <[EMAIL PROTECTED]> wrote: > In 2.2.18pre16 an alternative USB_UHCI driver under the option > CONFIG_USB_UHCI_ALT was added. Only this one works for me, and > CONFIG_USB_UHCI throws up 50 messages a second like this one: > > Oct 16 00:12:22 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 188 > > and leaves my mouse in an unusable state. > > This is on a VIA Technologies VT 82C586 Apollo USB (rev 6). I have two > USB devices connected to it: > Microsoft Microsoft IntelliMouse® Optical > Microsoft Natural Keyboard Pro > > What is supposed to be the difference between the two drivers, anyway? It > is not clear from the docs what is different besides the fact that they > are different. Just that. It's an alternative implementation. It's a long story why there's 2 drivers for the same device, and you can check the USB archives to learn the whole story. The short of it is that I didn't like the usb-uhci.c driver so I wrote a different one. It looks like it was worth the effort since it works for you whereas usb-uhci.c doesn't. I'm sure the usb-uhci.c guys will be interested to follow up with you about the problems you are seeing. 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: Problems with Tulip driver in 2.2 and 2.4
"Mike A. Harris" wrote: > > On Mon, 16 Oct 2000, Alan Cox wrote: > > >> I've noticed this behavior for a few kernel revisions now, up to and > >> including 2.2.17. It would be nice to get this bug worked out before > >> 2.2.18. > > > >I dont think that is likely to happen. Every time someone touches the tulip > >driver close to release they fix one card and break another 8( > > This might be a good reason to fork the driver code. Linus > commented before that he'd prefer a fork if it prevented problems > like this from occuring I believe. Look at drivers/net/tulip/* in 2.4.x kernels. And submit patches, if you have an idea :) For 2.2.x, I am pretty much staying away from tulip.c. For most chipsets it is rock solid stable, and I have no desire to change it... For a few new or really elcheapo NIC, you need Don Becker's tulip.c replacement. Other that that, 2.2.x's tulip.c is golden. 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/
