waitqueues 2.2->2.4
Again, I"m working on converting a module from 2.2 to being compatible with 2.4. In the 2.2 version it uses wait_queue structs with function calls such as wake_up(), interruptible_sleep_on()... In 2.4 these have changed to accept wait_queue_head_t's. What is the correct way to convert to the new way of doing things? And on another note, what is the best way to debug a module that crashes in an interrupt routine? (the oops info doesn't get logged anywhere since it crashes in the ISR). * Please CC to me since I'm not subscribed... Thanks, --James Lamanna - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
virt_to_bus and virt_to_phys on Apple G4 target
I am running linux 2.4.2 on Apple G4 machine. I think the 'PCI bus addresses' and 'physical addresses' are same on this architecture. I expected the two be different but according to asm/io.h 'virt_to_bus(addr) = virt_to_phys(addr) + PCI_DRAM_OFFSET'. I printed the value of 'PCI_DRAM_OFFSET' and that come out to be zero. Is this correct? If I somehow get the physical address of a user space buffer in a module and take this as a PCI bus address, will I be able to do DMA properly? thanks, Daljeet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Ive also had a problem with signal 11, heres a great page explaining the aspects of signal 11 error from gcc (http://www.bitwizard.nl/sig11/). Signal 11 is usually a hardware problem, as the article points out. I found a sloppy soulution playing with my BIOS settings, turns out there was an option called "Memory Hole at 15Mb Addr." I enabled it and i got no more sig11, however when I boot up, Linux only recognizes like 13Mb of my 64Mb of RAM. Anyway, there are my 2 cents. Luis -- ___ FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup FREE PC-to-Phone calls with Net2Phone http://www.net2phone.com/cgi-bin/link.cgi?121 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel still resides in the root
Hi I just completed the full compilation. But there is one still missing factor. I uncommented the INSTALL_PATH=/boot. But still the vmlinux still resides in the directory where i compiled the kernel. Why is it so. What to do if the kernel should be present in the boot directory. by Blesson Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
I confronted @Home's tech support, and they're programmed to say "server" but even tier-2 had no idea what it actually meant that I could and could not do. Go figure. - Original Message - From: "Hua Zhong" <[EMAIL PROTECTED]> To: "H. Peter Anvin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, July 02, 2001 12:56 PM Subject: Re: Uncle Sam Wants YOU! > -> From "H. Peter Anvin" <[EMAIL PROTECTED]> : > > When I got Pac*Smell DSL, the installer guy (who seemed to be a > > relatively clueful type) said "and [the contract] says you're not > > allowed to run a server... but who'd know?" > > ..and please define "server". Does it mean that you can not run any programs > listening on a port and accepting incoming connections or datagrams? :-) > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
- Original Message - From: "Jesse Pollard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "J Sloan" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, July 02, 2001 10:09 AM Subject: Re: Uncle Sam Wants YOU! > "Jim Roland" <[EMAIL PROTECTED]>: > > From: "Jesse Pollard" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; "Kurt Maxwell Weber" <[EMAIL PROTECTED]>; "J Sloan" > > <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Sunday, July 01, 2001 3:03 PM > > Subject: Re: Uncle Sam Wants YOU! > > > > > > [snip] > > > >In that case, I have the following options: > > > >1) Start my own ISP > > > > > > Only if the upstream provider doesn't require you to use windows. > > > > > > >2) Use Windows XP > > > >3) Not use Windows XP and not be able to use my current ISP > > > >4) Go to a different ISP > > > > > > You may not be able to find another. It took me a year. I gave up. I was > > > fortunate that Verio doesn't care what you have... though if you use > > > the dialup or basic dsl, MS is it, or no real support. > > > > > > >I'll just have to decide which I value more. As long as I won't be > > killed > > > >for using a different OS, I still have a choice. > > > > > > No, but you might be forced out of a job. > > > > In one of the large metro areas in which I live, there are a LOT of ISPs > > that do not require you to use Windows, but will not support you beyond the > > IP layer if you don't. Use linux, install PPP with MS-CHAPv2 (with or > > without MPPE) for your dialup connection and it works just fine on a > > Winblows-only ISP. DSL or Cable, just acquire your actual IP settings > > program a Linksys router/hub box and be done with it. > > Better re-read the fine print on the "fair-use" statement. BOTH DSL and > Cable, or dialup (New Orleans at least) will disconnect you if you run ANY > unattended operation (if they determine it IS unattended). No daemon services. > No routing/NAT (unless they do it). No remote login. No mail. DHCP reconfig > between 4 and 8 hours (or whenever they choose to). > > They will let you plug in, but will not provide any support (even TCP/IP is > not assured). > TCP/IP is assured, in the case of my @Home service, they provide me with the transport layer and settings (IP, subnet, etc) but no software support. That is a provider choice, and I have no problem with it. Microsoft does not (and will never) control the transport layer. Doing so will kill Cisco routers, etc. Being an ISP myself, there is absolutely nothing Microsoft can say or do to force me to support only them. If XP clients don't work with my service, give someone a little while and there will be a plug-in or patch that allows XP to run with standard service. As I said, they can do nothing for force me to move over to only Microsoft support. I am Linux, and I'm only a small-guy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
@Home tells you the same thing. Although they portscanned me frequently, they were checking for specific servers and actually deny traffic on ports 135-139 (Winblows traffic). Unless they change over to non-routables (which would kill things like ICQ, etc) they will not be able to stop me from using ssh or others for remote access. @Home and other providers get around the "server" issue by capping your maximum outbound bandwidth. This is something I have had to live with when upload FTP files to some off-site game servers I own. - Original Message - From: "H. Peter Anvin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 02, 2001 12:49 PM Subject: Re: Uncle Sam Wants YOU! > Followup to: <[EMAIL PROTECTED]> > By author:William T Wilson <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > On Mon, 2 Jul 2001, Jesse Pollard wrote: > > > > > Better re-read the fine print on the "fair-use" statement. BOTH DSL > > > and Cable, or dialup (New Orleans at least) will disconnect you if you > > > run ANY unattended operation (if they determine it IS unattended). No > > > > This would take a lot of watching on their part. > > > > My cable company occasionally portscans me, so I blackholed the > > portscanning machine. Even before I had done that, though, they never > > complained about my remote logins. They only complain if you use > > excessive bandwidth or if you do anything commercial. > > > > The DSL provider here, when it was still US West, explicitly stated to me > > (over the phone) that they absolutely did not care what I did with it as > > long as it was not illegal. However they would still not give you a > > static IP address unless you paid them extra money. :} > > > > When I got Pac*Smell DSL, the installer guy (who seemed to be a > relatively clueful type) said "and [the contract] says you're not > allowed to run a server... but who'd know?" > > -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] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Validation of memory allocated through kmalloc
Hi, Is there some kernel api to validate memory allocated using kmalloc. Suppose, I allocate some memory using kmalloc and at a later point of execution I would like to validate if the memory allocated is not possibly freed by some other thread. Pls suggest a patch/pointers if any. I also noticed a commented 'CONFIG_DEBUG_MALLOC' config option (2.4.3 source), It doesn't seem to be functional. Any pointers towards the history behind it would also be helpful. Thanks in advance, Kiran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Q] IP Autoconfiguration problem..???
n> I use kernel 2.4.5 with IP Autoconfiguration included dhcp, bootp, n> rarp . n> but, This kernel has not request IP to my dhcp server. so, kernel n> panic... The default behaviour changed in 2.4.4-pre8. You have to add ip=dhcp or ip=bootp to the kernel command line in order for the kernel to actually use autoconfiguration. http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Mon, 2 Jul 2001, mr sam jooky wrote: >>Somewhere between 2.4.2 and 2.4.5-ac13, PCMCIA card insertion and >>removal appears to have broken on my Toshiba Libretto. On 2.4.2 all was >>fine. On both 2.4.5-ac13 and ac22 it's broken. The whole machine >>freezes >>solid, no SAK-s, SAK-u, SAK-b, no Ctrl-Alt-Fn to switch VC's. No >>messages >>are issued. Problem occurs when inserting/removing any of YE-Data >>PCMCIA >>floppy, TDK Smartmedia adapter (ide_cs), or 3c589 ethernet card. > >On my IBM Thinkpad 390E my PCMCIA works fine with 2.4.5, on very rare >occasions >the mouse will drift diagonaly to the lower right corner. I read in the kernel >sources that this happens normaly due to probing of the PCMCIA which screws up >the mouse device. It happens so rarely I have not yet taken the time to try to >debug it. > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ ... Just FYI.(maybe worthless without ksymoops report) My ThinkPad 600X(Coppermine 500 MHZ, 100 MHZ SDRAM 320 MB, NeoMagic 256Z Video chipset, UDMA3 IDE hdd, cardbus IBM Etherjet 10/100 - Xircom oem, tulip 21143 compatible, external mii tranceiver - Cirrus CS46XX sound chipset) was completely locked up the system while loading yenta_socket and other modules. But, Mr. David Hinds' pcmcia-cs-3.1.26(i82365, tulip_cs) always works well. This was the first time for me to try to experiment with built-in pcmcia support of regular linux kernel after 2.4.0 kernel was released. I have been using only pcmcia-cs-3.1.2x since I bought 600X in Dec 2000, because pcmcia drivers of 2.4.0-testX kernel doesn't worked wel at that time. I use kernel-2.4.3-ac22, gcc-2.96-88, binutils-2.11.90.0.19, glibc-2.2.3, XFree86-4.1.0, ..). -- Where there is a will, there is a way. [EMAIL PROTECTED] For the future of you and me! [EMAIL PROTECTED] fingerprint = 1429 8AAF 8A2C 6043 DA2E BD4C 964C 2698 687D 4B7D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Q] IP Autoconfiguration problem..???
Hi, I use kernel 2.4.5 with IP Autoconfiguration included dhcp, bootp, rarp . but, This kernel has not request IP to my dhcp server. so, kernel panic... But, kernel 2.4.3 has no any problem. Help me! Peace be with you...:) Kihyung Ju -- I love Jesus Christ who is my savior. He gives me meanning of life. In Christ, I have become shepherd and bible teacher. e-mail : [EMAIL PROTECTED] home : http://newton.skku.ac.kr/~newton (My old home page) -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RH kernel 2.2.19-6.2.7, md_setup_drive, reference undefined
When I attempt to build a custom version of the Red Hat kernel 2.2.19-6.2.7 in Red Hat 6.2, the compile aborts with init/main.o(.data.init+0x13c): undefined reference to `md_setup' drivers/block/block.a(genhd.o): In function `device_setup': genhd.o(.text.init+0x13a): undefined reference to `md_setup_drive' make: *** [vmlinux] Error 1 Anybody know what's wrong? Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: readl() / writel() on PowerPC
> I have been working on a driver for a PowerPC PCI card/framebuffer device, > and noticed that the standard readl() and writel() for this platform to > byte swapping, since PowerPC runs big-endian. However, at least for my > hardware it's *really* not needed, and should just do a regular load > store, as is done for CONFIG_APUS. Looking at another driver > (drivers/char/bttv.h) I notice that Mr. Metzler redefines his read and > write routines for PowerPC as well to do simple loads and stores to IO > regions. > > Am I missing something? Is there some reason that readl() and > writel() should byte-swap by default? Use the fb_writeX/fb_readX functions in fbcon.h. They take care of these issues. P.S Watchout for userland programs. You can NOT use memset on the framebuffer on PPC due to caching issues. Use have to use tricks similar to what is done in fbcon.h with fb_memset. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
Alan Cox wrote: > > > > > You pass a single cookie to the readb code > > > > Odd platforms decode it > > > > > > Last time I checked, ioremap didn't work for inb() and outb(). > > > > It should :) > > it doesnt need to. > > pci_find_device returns the io address and can return a cookie, ditto > isapnp etc Is the idea here to mitigate the amount of driver code changes, or something else? If you are sticking a cookie in there behind the scenes, why go ahead and use ioremap? We -already- have a system which does remapping and returns cookies and such for PCI mem regions. Why not use it for I/O regions too? Jeff -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: drivers/char/vt.c allows virtually locking up nonnetworkedmachine
On Sat, 30 Jun 2001, Rudolf Polzer wrote: > There is a problem concerning chvt. A normal user can run a > > bash$ while [ 1 ]; do chvt 11; done > > which cannot be killed using the console (only remotely, virtually never > on a nonnetworked multiuser machine). So I changed the kernel source code > so that only the superuser may change terminals. Ok, lemme see if I got this right. What exactly do you mean by 'a normal user' or a 'nonnetworked machine'. If the machine is non-networked, then it must be sort of single user. Oh yea, and if someone logs on from your console, smack them and don't patch the kernel. Oh yeah, I can imagine a few situations in which this would be necessary. But if someone you don't trust logs on from your (non-networked) console and has time to play with it, you're screwed anyway. Dan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
>Somewhere between 2.4.2 and 2.4.5-ac13, PCMCIA card insertion and >removal appears to have broken on my Toshiba Libretto. On 2.4.2 all was >fine. On both 2.4.5-ac13 and ac22 it's broken. The whole machine >freezes >solid, no SAK-s, SAK-u, SAK-b, no Ctrl-Alt-Fn to switch VC's. No >messages >are issued. Problem occurs when inserting/removing any of YE-Data >PCMCIA >floppy, TDK Smartmedia adapter (ide_cs), or 3c589 ethernet card. On my IBM Thinkpad 390E my PCMCIA works fine with 2.4.5, on very rare occasions the mouse will drift diagonaly to the lower right corner. I read in the kernel sources that this happens normaly due to probing of the PCMCIA which screws up the mouse device. It happens so rarely I have not yet taken the time to try to debug it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: readl() / writel() on PowerPC
On Mon, Jul 02, 2001 at 08:22:55PM -0400, David T Eger wrote: > > I have been working on a driver for a PowerPC PCI card/framebuffer device, > and noticed that the standard readl() and writel() for this platform to > byte swapping, since PowerPC runs big-endian. However, at least for my > hardware it's *really* not needed, and should just do a regular load > store, as is done for CONFIG_APUS. Looking at another driver > (drivers/char/bttv.h) I notice that Mr. Metzler redefines his read and > write routines for PowerPC as well to do simple loads and stores to IO > regions. I believe you are looking for __raw_readl(), __raw_writel(). dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
Somewhere between 2.4.2 and 2.4.5-ac13, PCMCIA card insertion and removal appears to have broken on my Toshiba Libretto. On 2.4.2 all was fine. On both 2.4.5-ac13 and ac22 it's broken. The whole machine freezes solid, no SAK-s, SAK-u, SAK-b, no Ctrl-Alt-Fn to switch VC's. No messages are issued. Problem occurs when inserting/removing any of YE-Data PCMCIA floppy, TDK Smartmedia adapter (ide_cs), or 3c589 ethernet card. If I boot with the cards in the slot then there is no problem - I can cardctl eject/insert them as long as I do not physically remove the cards from the slots. Any attempt to insert/remove cards kills the machine to power off point. Dropping back to 2.4.2 cures this. Base system is SuSE 7.1. trevor@trevor5:~ > /sbin/lspci 00:00.0 Host bridge: Toshiba America Info Systems 601 (rev 2e) 00:04.0 VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] (rev 01) 00:06.0 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 20) 00:06.1 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 20) 00:0b.0 USB Controller: NEC Corporation USB (rev 02) 00:11.0 Communication controller: Toshiba America Info Systems FIR Port (rev 22) 00:13.0 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 20) 00:13.1 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 20) trevor@trevor5:~ > trevor@trevor5:~ > dmesg Linux version 2.4.5-ac22 (root@trevor5) (gcc version 2.95.2 19991024 (release)) #4 Mon Jul 2 23:27:13 GMT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0401 (usable) BIOS-e820: 0401 - 0402 (ACPI data) BIOS-e820: 0402 - 0404 (reserved) BIOS-e820: fef8 - ff00 (reserved) BIOS-e820: fffe - fffe6e00 (reserved) BIOS-e820: fffe6e00 - fffe7000 (ACPI NVS) BIOS-e820: fffe7000 - 0001 (reserved) On node 0 totalpages: 16400 zone(0): 4096 pages. zone(1): 12304 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=l245 ro root=306 BOOT_FILE=/l245/vmlinuz video=vesa:ywrap Initializing CPU#0 Detected 166.637 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 332.59 BogoMIPS Memory: 62616k/65600k available (823k kernel code, 2596k reserved, 225k data, 200k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Mount-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 008001bf , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. Intel old style machine check architecture
readl() / writel() on PowerPC
I have been working on a driver for a PowerPC PCI card/framebuffer device, and noticed that the standard readl() and writel() for this platform to byte swapping, since PowerPC runs big-endian. However, at least for my hardware it's *really* not needed, and should just do a regular load store, as is done for CONFIG_APUS. Looking at another driver (drivers/char/bttv.h) I notice that Mr. Metzler redefines his read and write routines for PowerPC as well to do simple loads and stores to IO regions. Am I missing something? Is there some reason that readl() and writel() should byte-swap by default? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
> >Can you give me an idea of what sort of cookie decoding a PPC/PMac would need >and why - Im working off things like pa-risc so I dont have a full picture. Each domain provide an IO space (size depends on the bridge, recent Apple UniNorth hosts have 16Mb per domain). That IO space can be in any location (depends on the box, bridge config, ..), so basically, we must assume that each host bridge can have it's IO space anywhere in CPU mem space. Currently, we store the physical address of those in our pci_controller structure, and ioremap all of them. One is picked up as the "ISA" io base (for VGA and such things as legacy devices on non-pmac PPCs). That isa_io_base is used as an offset to inx/outx, and all PCI IO_RESOURCES are fixed up to be their real virtual address offset'ed with isa_io_base. (A bit weird but works and we have only an addition in inx/outx). I'm more concerned about having all that space mapped permanently in kernel virtual space. I'd prefer mapping on-demand, and that would require a specific ioremap for IOs. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac23
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.5-ac23 o Merge with 2.4.6pre8 | This should make things much more stable o Restore backed out shm patches (Christoph Rohland) o Fix quotaoff crash (Jan Kara) o Move stuff into BSS on decnet (Xavier Bestel) o Update ims twinturbo fb maintainer (Paul Mundt) o Update Crutcher Dunnavant's email address (Crutcher Dunnavant) o UML ^S/^Q support for the console and serial(Livio Soares) o code cleanups in UML drivers(Jeff Dike) o UML include and #define cleanups(Niels Kristian Bech Jensen) o UML ubd driver defines blk_size correctly (Roman Zippel) o which allowed clean up of related ubd code (Jeff Dike) o tweak the UML definition is a fixable seg fault (Jeff Dike) o fix the UML TASK_UNINTERRUPTIBLE deadlock (Jeff Dike) o Update ldconfig scripts for multiple rodata (Jakub Jelinek) o Small isdn.h fixes (Kai Germaschewski) o Add Advantech TurboPAM isdn (Stelian Pop) o Maxine frame buffer cleanups(Paul Mundt) o UDF cleanup (Arnaldo Carvalho de Melo) o Fix jffs2 includes (Keith Owens) o Small cleanups to vt.c (Arnaldo Carvalho de Melo) o Clean up istallion driver (Arnaldo Carvalho de Melo) o Clean up sh-sci driver (Arnaldo Carvalho de Melo) o Clean up selection (Arnaldo Carvalho de Melo) o Small random driver cleanups(Arnaldo Carvalho de Melo) o Small tty_io cleanup(Arnaldo Carvalho de Melo) o Small isdn_tty cleanup (Arnaldo Carvalho de Melo) o Expose scsi_add/del_timer for hosts to adjust timeouts when they know better(Matthew Jacob) o Remove unneeded init of data(Xavier Bestel) o Remove unneeded init of data in wavfront(Xavier Bestel) o Remove unneeded init of data in sb (Xavier Bestel) o Remove unneeded init of data in nm256 (Xavier Bestel) o Remove unneeded init of data in oss sound (Xavier Bestel) o Remove unneeded init of data in cs4232 (Xavier Bestel) o Remove unneeded init of data in ultrastor (Xavier Bestel) o Remove unneeded init of data in scsi/hosts.c(Xavier Bestel) o Remove unneeded init of data in i2o_core(Xavier Bestel) o Fix strange fs/exec.c error return (Andrew Morton) o Remove unneeded init of data in mcd (Xavier Bestel) o Clean up belkin_sa ioctl code (Arnaldo Carvalho de Melo) o Clean up ftdi_sio ioctl code(Arnaldo Carvalho de Melo) o Clean up mct_u232 ioctl code(Arnaldo Carvalho de Melo) o Tidy ircomm_tty_ioctl (Arnaldo Carvalho de Melo) o Work around cypress cy723c693 RTC stability bug (Ivan Kokshaysky) o Clean up autofs user access slightly(Arnaldo Carvalho de Melo) o Small fs/exec.c clean ups (Arnaldo Carvalho de Melo) o Fix eepro100 oops with power management (Marc Boucher) 2.4.5-ac22 o Fix the remaining make xconfig mess (me) o Add APM disabling on DMI match (me) | Needed for the Trigem Delhi3 (aka E Machines E-Tower 333cs) o Fix pnpbios without hotplug (I hope)(me) o Merge an escaped via midi fixup (Adrian Cox) o Revert minixfs changes 2.4.5-ac21 o Fix pnpbios compile failure and add docking (me) station hotplug (/sbin/hotplug dock) o Fix make xconfig failure(Keith Owens) o Fix cciss pci device table (Marcus Meissner) o Fix bogus math.h include in iphase driver (Arjan van de Ven) o Reiserfs vm deadlock fix(Chris Mason) o Make the i810 tco disable info clearer (Andrey Panin) o Correct bzImage size limit check(Pavel Machek) o Next lvm patch (Joe Thornber) o Fix toshoboe for pm api change (me) 2.4.5-ac20 o Commence resync with 2.4.6pre5 - Merge kernel doc tool changes - Merge sunrpc printk check change - Merge net core changes - Merge Bluetooth stack - Merge inet proto register - Merge bridge updates - Merge net/ipv4 and ipv6 changes - Merge x86 arch support - Merge m68k port changes
[RFC][PATCH] struct kernel_stat -> struct cpu_stat[NR_CPUS]
Currently struct kernel_stat has a few pre cpu arrays. This creates
cacheline exchange noise as the cpus update their entries in each array.
This patch creates an array of per cpu structs. The structure is padded
to the length of a cacheline. The meat of the patch against 2.4.6-pre8
is attached. The rest of the patch is rather large because it touches
all the architectures' use of ks->irqs[], and can be found at
http://www.osdlab.org/sw_resources/cpustat/cpustat-2.4.6.pre8-1.diff
These per cpu statistics are reported via a new /proc/cpustat, a quick
tool for processing that output, vmstat-style, can be found near
http://www.osdlab.org/sw_resources/cpustat/index.shtml
In addition to shuffling structures around, the patch adds the recording
of context scheduling migrations as well as "minor", "major", and
"cow" faults.
I'd really like to hear what people think of the patch. Unless someone
strongly is dead set against it, I'd like to send it off to Linus and
move on to other things :) Would arch maintainers rather that I fed
them per-arch patches for their trees?
- z
--- linux-2.4.6-pre8/fs/proc/proc_misc.c.cpustatFri Apr 13 20:26:07 2001
+++ linux-2.4.6-pre8/fs/proc/proc_misc.cMon Jul 2 15:04:49 2001
@@ -265,32 +265,37 @@
int i, len;
extern unsigned long total_forks;
unsigned long jif = jiffies;
- unsigned int sum = 0, user = 0, nice = 0, system = 0;
+ unsigned int sum = 0, user = 0, nice = 0, system = 0, ctxt = 0;
int major, disk;
for (i = 0 ; i < smp_num_cpus; i++) {
int cpu = cpu_logical_map(i), j;
- user += kstat.per_cpu_user[cpu];
- nice += kstat.per_cpu_nice[cpu];
- system += kstat.per_cpu_system[cpu];
+ user += cpu_stat[cpu].user;
+ nice += cpu_stat[cpu].nice;
+ system += cpu_stat[cpu].system;
+ ctxt += cpu_stat[cpu].context_swtch;
#if !defined(CONFIG_ARCH_S390)
for (j = 0 ; j < NR_IRQS ; j++)
- sum += kstat.irqs[cpu][j];
+ sum += cpu_stat[cpu].irqs[j];
#endif
}
len = sprintf(page, "cpu %u %u %u %lu\n", user, nice, system,
jif * smp_num_cpus - (user + nice + system));
- for (i = 0 ; i < smp_num_cpus; i++)
+ for (i = 0 ; i < smp_num_cpus; i++) {
+ unsigned int user_i, nice_i, system_i;
+ int cpu = cpu_logical_map(i);
+
+ user_i = cpu_stat[cpu].user;
+ nice_i = cpu_stat[cpu].nice;
+ system_i = cpu_stat[cpu].system;
+
len += sprintf(page + len, "cpu%d %u %u %u %lu\n",
i,
- kstat.per_cpu_user[cpu_logical_map(i)],
- kstat.per_cpu_nice[cpu_logical_map(i)],
- kstat.per_cpu_system[cpu_logical_map(i)],
- jif - ( kstat.per_cpu_user[cpu_logical_map(i)] \
- + kstat.per_cpu_nice[cpu_logical_map(i)] \
- + kstat.per_cpu_system[cpu_logical_map(i)]));
+ user_i, nice_i, system_i,
+ jif - ( user_i + nice_i + system_i ) );
+ }
len += sprintf(page + len,
"page %u %u\n"
"swap %u %u\n"
@@ -330,13 +335,64 @@
"\nctxt %u\n"
"btime %lu\n"
"processes %lu\n",
- kstat.context_swtch,
+ ctxt,
xtime.tv_sec - jif / HZ,
total_forks);
return proc_calc_metrics(page, start, off, count, eof, len);
}
+static int cstat_read_proc(char *page, char **start, off_t off,
+int count, int *eof, void *data)
+{
+ int i, len;
+
+ len = sprintf(page, "cpu_stat 0.0\n");
+
+ for (i = 0 ; i < smp_num_cpus; i++) {
+ unsigned int user, nice, system;
+ int j, cpu = cpu_logical_map(i);
+ struct cpu_stat *cs = _stat[cpu];
+
+#if !defined(CONFIG_ARCH_S390)
+ len += sprintf(page + len, "cpu%d irqs ", cpu);
+ for (j = 0 ; j < NR_IRQS ; j++) {
+ len += sprintf(page + len, " %u",
+ cs->irqs[j]);
+ }
+ len += sprintf(page + len, "\n");
+#endif
+#if defined(CONFIG_SMP)
+ len += sprintf(page + len, "cpu%d context_migration %u\n",
+ cpu, cs->context_migration);
+#endif
+ len += sprintf(page + len, "cpu%d context_switches %u\n",
+ cpu, cs->context_swtch);
+
+ len += sprintf(page + len, "cpu%d major_faults %u\n",
+ cpu, cs->major_fault);
+ len += sprintf(page + len, "cpu%d minor_faults %u\n",
+ cpu, cs->minor_fault);
+
Re: usbserial/keyspan module load race [was: 2.4.5 keyspan driver]
adric@glitch[~]$ dpkg -l modutils | tail -n1 ii modutils 2.4.6-3Linux module utilities. On Mon, Jul 02, 2001 at 03:43:25PM -0700, Greg KH wrote: > What version of the modutils package do you have? > > thanks, > > greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pte_val(*pte) as lvalue
Timur Tabi <[EMAIL PROTECTED]> writes: > > What is the accepted way to assign an integer to a pte that works in 2.2 and > 2.4? set_pte(pte, mk_pte( ... )) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pte_val(*pte) as lvalue
In my driver, I have this code: unsigned long p = pte_val(*pte); [set some bits in "p"] pte_val(*pte) = p; This works fine in 2.2, and 2.4 when PAE support is disabled. When PAE support is enabled, it doesn't work, because the pte_val macro can no longer be an lvalue. What is the accepted way to assign an integer to a pte that works in 2.2 and 2.4? -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usbserial/keyspan module load race [was: 2.4.5 keyspan driver]
On Mon, Jul 02, 2001 at 05:22:17PM -0500, Gregory T. Norris wrote: > It wasn't quite as cooperative today, but after a few attempts I was > able to reproduce it. > > root@glitch[~]# modprobe keyspan > Warning: /lib/modules/2.4.5/kernel/drivers/usb/serial/usbserial.o symbol for >parameter vendor not found > Segmentation fault What version of the modutils package do you have? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Just to confirm Dan. I was a fool and did not install the dummy handler for the masked signal I was using. I added the proper code over the weekend with no noticable effect (JDK 1.3 still sigtimedwait()'s on the signal :-(). --Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: usbserial/keyspan module load race [was: 2.4.5 keyspan driver]
It wasn't quite as cooperative today, but after a few attempts I was able to reproduce it. root@glitch[~]# modprobe keyspan Warning: /lib/modules/2.4.5/kernel/drivers/usb/serial/usbserial.o symbol for parameter vendor not found Segmentation fault root@glitch[~]# ps -ef|grep "[m]odprobe" root@glitch[~]# root@glitch[~]# egrep "usb|key" /proc/modules keyspan22112 (initializing) usbserial 17296 0 [keyspan] usb-uhci 21200 0 (unused) usbcore48688 1 [keyspan usbserial usb-uhci] I browsed the full ps output as well, but I didn't find anything looking like what you described. On Mon, Jul 02, 2001 at 12:02:52AM +0200, Oliver Neukum wrote: > When this happens does the modprobe task hang in __down with state D ? > ps can show you this information. > > Regards > Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reg crash utility installation
SATHISH.J wrote: > I installed crash2.6 on my machine. > When I give the command "crash" from the prompt it says "no debugging > symbols found in /boot/vmlinux2.2.14-12". Why does this message show. crash relies on debug info and so it needs access to an uncompressed vmlinux file which was built using -g. The following URL offers more info: http://oss.missioncriticallinux.com/projects/crash/usage.php Pat -- Patrick O'Rourke [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
> - Parsing of this cookie on each inx/outx access, which can > take a bit of time (typically looking up the host bridge) It depends on the implementation obviously, but its typically something like take lock writew(port&0x, port&0x); writew(data, port&0x+1); drop lock Assuming you can drop the bridges on 64K boundaries in pci mem space, or one extra deref and a register load if not. Can you give me an idea of what sort of cookie decoding a PPC/PMac would need and why - Im working off things like pa-risc so I dont have a full picture. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
>Last time I checked, ioremap didn't work for inb() and outb(). ioremap itself cannot work for inb/outb as they are different address spaces with potentially overlapping addresses, I don't see how a single function would handle both... except if we pass it a struct resource instead of the address. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
>> > Last time I checked, ioremap didn't work for inb() and outb().
>>
>> It should :)
>
>it doesnt need to.
>
>pci_find_device returns the io address and can return a cookie, ditto
>isapnp etc
Yes, but doing that require 2 annoying things:
- Parsing of this cookie on each inx/outx access, which can
take a bit of time (typically looking up the host bridge)
- On machines with PIO mapped in CPU mem space and several
(or large) IO regions, they must all be mapped all the time,
which is a waste of kernel virtual space.
Why not, at least for 2.5, define a kind of pioremap that
would be the equivalent of ioremap for PIO ?
In fact, I'd rather have all this abstracted in a
ioremap_resource(struct resource *, int flags)
iounmap_resource(struct resource *)
("flags" is just an idea that could be used to pass things
like specific caching attributes, or whatever makes sense to
a given arch).
The distinction between inx/oux & readx/writex would still
make sense at least for x86.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
semaphore/down()/up() question
I need to stop a kernel thread at a certain place in the
driver code. The task that stopped it needs to know that it's
stopped, i.e., needs to wait until it's sleeping.
Later on, I need to start it. So, I thought that a
semaphore would work. It works the first time, but
not after that. In other words, the first down_interruptible()
does, indeed put it in "down_interruptible". I can wake it
up with 'up()'. After that, the kernel thread just ignores
(immediately returns from) down_interruptible().
Trying to find out what was going on, I decided to cheat and
initialize the semaphore immediately before down_interruptible().
Again, it works the first time. However, the second time through
the code then gets stuck in down_interruptible() and a call to
up() gets stuck forever.
Also, it seems that up() and down() are logically reversed,
up() seems to wait until down() is executed. I would expect
that up() would just return if the semaphore was not active,
i.e., locked.
Does anybody know what's going on? Maybe this isn't how to
use these kernel services??
static struct semaphore stopper;
kernel_thread()
{
for(;;)
{
down_interruptible();
do_stuff();
}
}
ioctl()
{
up();
}
int __init init_module()
{
init_MUTEX_LOCKED();
}
Cheers,
Dick Johnson
Penguin : Linux version 2.4.5 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] Early Flush with Bandwidth Estimation
This is an experimental attempt to optimize my previous early flush patch by adding continuous disk bandwidth estimation. In spirit, the new modifications are similar to Stephen Tweedie's "sard" disk monitoring patch, though it was only after implementing my own ideas that I became aware of the overlap. On the other hand, what I have done here is quite lightweight, on the order of 20 lines or so, and seems to produce good results. It is far from clear that this continuous bandwidth feedback from the IO queue is the "right" approach. Alternatively, it would be quite easy to provide an interface from userland to allow the administrator to provide a one-time bandwidth estimate, perhaps derived from hddisk -t. On the other hand, it would be just as easy to provide both an automatic estimation and a manual override. One big advantage of making the automatic method the default is that no tuning needs to be done in order to get decent performance from a new install. Another potential advantage is that bandwidth can change under different loads, so any one-time estimate may prove to be sub-optimal. The Patch - This is a patch set with three parts: 1) A lightly edited version of the early flush patch 2) Add-on bandwidth estimation 3) Add-on proc interface for bandwidth estimate and transfer rate Each part depends on the ones before it and each results in a usable system. I.e, to get the original early flush behaviour, just omit the second and third patches. The second patch adds bandwidth estimation and this is where things get interesting from the benchmarking point of view. At this point I haven't done any rigorous benchmarking and I can only guess at the performance effects. On the other hand, by monitoring the bandwidth estimate, I've learned some interesting things about how well we are doing in terms of optimizing disk seeks (not spectacularly well) and I have also noticed what appears to be a low-level problem in the disk queue, causing short periods of unreasonably low block transfer rates on my laptop. To apply: cd /usr/src/yourtree patch -p0 patch -p0 From the enterprise-computing point of view, the major improvement that needs to be made is in separate analysis of multiple block devices. This per-device information needs to be propagated back into kernel mechanisms such as bdflush, page_launder and the swapper. Needless to say, this is 2.5 material. Proc Interface -- In the third patch of this set I create a simple proc interface to expose the bandwidth estimation, and another simple statistic, current transfer rate, to user space. This is used as follows: daniel@starship# cat /proc/bandwith 1720 0 The first number is the current bandwidth estimate and the second is the current transfer rate. Note that the bandwidth estimate is updated only when there is disk activity, and it can vary a great deal as described above. Do not be surprised to see a strangely low bandwith estimate when the system is sitting idle - it can easily result from a final burst of disk access that is extremely fragmented. I do not pretend that the this proc interface is correct in any way, however is should be fun to play with. early.flush.1 - --- ../uml.2.4.5.clean/drivers/block/ll_rw_blk.cThu Apr 12 21:15:52 2001 +++ ./drivers/block/ll_rw_blk.c Sun Jul 1 02:48:35 2001 @@ -122,6 +122,7 @@ * of memory with locked buffers */ atomic_t queued_sectors; +atomic_t submitted_sectors; /* * high and low watermark for above --- ../uml.2.4.5.clean/include/linux/blkdev.h Sat May 26 03:01:40 2001 +++ ./include/linux/blkdev.hSun Jul 1 02:51:09 2001 @@ -177,6 +177,7 @@ extern int * max_segments[MAX_BLKDEV]; extern atomic_t queued_sectors; +extern atomic_t submitted_sectors; #define MAX_SEGMENTS 128 #define MAX_SECTORS 255 @@ -213,6 +214,7 @@ } #define blk_started_io(nsects) \ + atomic_add(nsects, _sectors); \ atomic_add(nsects, _sectors); #endif --- ../uml.2.4.5.clean/include/linux/fs.h Sat May 26 03:01:28 2001 +++ ./include/linux/fs.hFri Jun 29 20:37:18 2001 @@ -236,7 +236,7 @@ atomic_t b_count; /* users using this block */ kdev_t b_rdev; /* Real device */ unsigned long b_state; /* buffer state bitmap (see above) */ - unsigned long b_flushtime; /* Time when (dirty) buffer should be written */ + unsigned long b_dirtytime; /* Time buffer became dirty */ struct buffer_head *b_next_free;/* lru/free list linkage */ struct buffer_head *b_prev_free;/* doubly linked list of buffers */ --- ../uml.2.4.5.clean/mm/filemap.c Thu May 31 15:29:06 2001 +++ ./mm/filemap.c Fri Jun 29 20:37:19 2001 @@ -349,7 +349,7 @@ if (buffer_locked(bh) || !buffer_dirty(bh) || !buffer_uptodate(bh)) continue; -
Re: [RFC] I/O Access Abstractions
> > > You pass a single cookie to the readb code > > > Odd platforms decode it > > > > Last time I checked, ioremap didn't work for inb() and outb(). > > It should :) it doesnt need to. pci_find_device returns the io address and can return a cookie, ditto isapnp etc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange errors in /var/log/messages
On Mon, 2 Jul 2001, Guest section DW wrote: > On Mon, Jul 02, 2001 at 05:16:23PM +0100, Alan Cox wrote: > > > > I'm running RedHat 7.0 with all official RH patches applied. The kernel I > > > currently run fow a few days is 2.2.19-7.0.8 > > > I run the pre-compiled kernel of RH. Suddenly I the following messages: > > > > > > Jul 2 15:12:16 gateway SERVER[1240]: Dispatch_input: bad request line > > > 'BBXX%.176u%3 > > > >00$nsecurity.%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > > > These are for an application. Not sure which or why > > See CERT Advisory CA-2000-22 > http://www.infowar.com/iwftp/cert/advisories/CA-2000-22.html > > "A popular replacement software package to the BSD lpd printing service >called LPRng contains at least one software defect, known as a "format string >vulnerability," which may allow remote users to execute arbitrary code on >vulnerable systems." I just read the article. It seems somebody tried to exploid a bug in LPRng. Unfortunately I didn't check the TCP/IP connections at the time of attack (with netstat), so I couldn't tell who was connected to port 515. The article suggest upgrading to 3.6.25. I'm currenlty running 3.7.4-23. I assume I'm not vulnerable, but those 'errors' in the logfile really scared the heck out of me! :) To be certain, I just blocked poort 515 for outbound connections. :) Bye the way, sorry this message was off-topic, but I didn't know it was a LPRng issue, not a kernel issue. Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
-> From Alan Cox <[EMAIL PROTECTED]> : > > (a) It does less, namely will not kill processes with uid 0. > > Ted, any objections? > > That breaks the security guarantee. Suppose I use a setuid app to confuse > you into doing something ? a setuid app only changes euid, doesn't it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
On Mon, Jul 02, 2001 at 02:16:36PM +0200, [EMAIL PROTECTED] wrote: > (a) It does less, namely will not kill processes with uid 0. > Ted, any objections? What if you have a process running wild as uid 0 (i.e. X server gone bad) that you need to die *right now*? -- "Don't dwell on reality; it will only keep you from greatness." -- Randall McBride, Jr. ** Evil Genius Bryon Roche, Kain <[EMAIL PROTECTED]> PGP signature
Re: VM Requirement Document - v0.0
On Thu, 28 Jun 2001, Marco Colombo wrote: > I'm not sure that, in general, recent pages with only one access are > still better eviction candidates compared to 8 hours old pages. Here > we need either another way to detect one-shot activity (like the one > performed by updatedb), Fully agreed, but there is one problem with this idea. Suppose you have a maximum of 20% of your RAM for these "one-shot" things, now how are you going to be able to page in an application with a working set of, say, 25% the size of RAM ? If you don't have any special measures, the pages from this "new" application will always be treated as one-shot pages and the process will never be able to be cached in memory completely... Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SCSI I/O error
>From my logs: Jun 29 14:19:56 Jay kernel: SCSI disk error : host 1 channel 0 id 5 lun 0 return code = 802 Jun 29 14:19:56 Jay kernel: Current sd08:11: sense key Recovered Error Jun 29 14:19:56 Jay kernel: Additional sense indicates Recovered data with error correction applied Jun 29 14:19:56 Jay kernel: I/O error: dev 08:11, sector 480940 Jun 29 14:19:56 Jay kernel: Incorrect number of segments after building list I programmed the disk to report recovered errors too, and the log shows one of these. The user-level tool exited with an I/O error. The last line comes from drivers/scsi/scsi_merge.c:__init_io() and I thing there is a bug in the SCSI error handling code. I have an Adaptec card. [Linux version 2.4.6-pre3] Bye. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
Russell King wrote: > > On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote: > > Case 1: > > You pass a single cookie to the readb code > > Odd platforms decode it > > Last time I checked, ioremap didn't work for inb() and outb(). It should :) -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: Strange errors in /var/log/messages
On Mon, Jul 02, 2001 at 01:00:33PM -0400, you [Richard B. Johnson] claimed: > > Jul 2 15:12:16 gateway SERVER[1240]: Dispatch_input: bad request line > > 'BBXX%.176u%3 > > >00$nsecurity.%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > > I think you just got 'rooted'. Look at /etc/inetd.conf (if it exists > on your system, the xinetd is more robust). It may have a new entry > on its last line providing a root shell to anybody. This looks somewhat > like an attack shown by CERN about 6 to 12 months ago. (This has nothing to do with linux-kernel, sorry...) I don't think anything particular in that message suggests he actually got rooted? It just seems that somebody tried to exploit lprNG hole (or something else) and the daemon logged that. Of course, it *is* perfectly possible, that he _got_ rooted (although he said he was running redhat-7.0 with all the updates). (The attacker may have tried other attacks so if he got rooted, those above are not necessarily the related log messages. In any case, a 'smart' intruder would have cleaned the log. Also, 'smart' attacker propably uses something more advanced as backdoor than /etc/inetd.conf these days.) Or is there something that actually indicates a succesfull intrusion in the log snippet that I'm missing? -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote: > Case 1: > You pass a single cookie to the readb code > Odd platforms decode it Last time I checked, ioremap didn't work for inb() and outb(). -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Doubt in interrupts
Swami wrote: > > Hi, > > Are there any interrupts which doesn't affect local_irq_count(cpu) or that > doesn't enter do_IRQ()? (other than NMIs). > > Because I'm implementing my own locking routine and I'm getting > interrupted during spin, but I check and found that in_interupt() returns > zero. All hardware interrupts go through do_IRQ. There are also CPU exceptions and inter-processor interupts (SMP only) that have individual handlers. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cleaning up a socket in FIN_WAIT_1
A socket got stuck in the FIN_WAIT_1 state coz the client that was generating these TCP segments got terminated prematurely. The kernel does clean it up after 2MSL seconds. However, I would like to know if there is a way to explicitly clean it up from the command line (as root). SO_REUSEADDR option only helps for sockets in TIME_WAIT. Also, Does the kernel have such mechanisms to clean up any kernel data structure? I would appreciate it if whoever answers this query also Cc me coz I'm not subscribed to the kernel mailing list. Thanks, Shashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
-> From "H. Peter Anvin" <[EMAIL PROTECTED]> : > When I got Pac*Smell DSL, the installer guy (who seemed to be a > relatively clueful type) said "and [the contract] says you're not > allowed to run a server... but who'd know?" ..and please define "server". Does it mean that you can not run any programs listening on a port and accepting incoming connections or datagrams? :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
Followup to: <[EMAIL PROTECTED]> By author:William T Wilson <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Mon, 2 Jul 2001, Jesse Pollard wrote: > > > Better re-read the fine print on the "fair-use" statement. BOTH DSL > > and Cable, or dialup (New Orleans at least) will disconnect you if you > > run ANY unattended operation (if they determine it IS unattended). No > > This would take a lot of watching on their part. > > My cable company occasionally portscans me, so I blackholed the > portscanning machine. Even before I had done that, though, they never > complained about my remote logins. They only complain if you use > excessive bandwidth or if you do anything commercial. > > The DSL provider here, when it was still US West, explicitly stated to me > (over the phone) that they absolutely did not care what I did with it as > long as it was not illegal. However they would still not give you a > static IP address unless you paid them extra money. :} > When I got Pac*Smell DSL, the installer guy (who seemed to be a relatively clueful type) said "and [the contract] says you're not allowed to run a server... but who'd know?" -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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Doubt in interrupts
Hi, Are there any interrupts which doesn't affect local_irq_count(cpu) or that doesn't enter do_IRQ()? (other than NMIs). Because I'm implementing my own locking routine and I'm getting interrupted during spin, but I check and found that in_interupt() returns zero. Thanking in advance, Swami -- http://www.swaminathans.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange errors in /var/log/messages
On Mon, Jul 02, 2001 at 05:16:23PM +0100, Alan Cox wrote: > > I'm running RedHat 7.0 with all official RH patches applied. The kernel I > > currently run fow a few days is 2.2.19-7.0.8 > > I run the pre-compiled kernel of RH. Suddenly I the following messages: > > > > Jul 2 15:12:16 gateway SERVER[1240]: Dispatch_input: bad request line > > 'BBXX%.176u%3 > > >00$nsecurity.%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > These are for an application. Not sure which or why See CERT Advisory CA-2000-22 http://www.infowar.com/iwftp/cert/advisories/CA-2000-22.html "A popular replacement software package to the BSD lpd printing service called LPRng contains at least one software defect, known as a "format string vulnerability," which may allow remote users to execute arbitrary code on vulnerable systems." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
On Mon, 2 Jul 2001, Jesse Pollard wrote: > Better re-read the fine print on the "fair-use" statement. BOTH DSL > and Cable, or dialup (New Orleans at least) will disconnect you if you > run ANY unattended operation (if they determine it IS unattended). No This would take a lot of watching on their part. My cable company occasionally portscans me, so I blackholed the portscanning machine. Even before I had done that, though, they never complained about my remote logins. They only complain if you use excessive bandwidth or if you do anything commercial. The DSL provider here, when it was still US West, explicitly stated to me (over the phone) that they absolutely did not care what I did with it as long as it was not illegal. However they would still not give you a static IP address unless you paid them extra money. :} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
__alloc_pages: 4-order allocation failed
Hi, I got the error __alloc_pages: 4-order allocation failed in a module that uses and frees a lot of pages. Basically, I am trying implement a page cache for the module. First, I keep allocating pages using page_cache_alloc() until it fails, then I free a whole bunch of pages using freepages((unsigned long)page_address(page)) Would anyone please give me some advice about how to solve this problem? Thanks a lot. __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange errors in /var/log/messages
On Mon, 2 Jul 2001 [EMAIL PROTECTED] wrote: > Hi! > > I'm running RedHat 7.0 with all official RH patches applied. The kernel I > currently run fow a few days is 2.2.19-7.0.8 > I run the pre-compiled kernel of RH. Suddenly I the following messages: > > Jul 2 15:12:16 gateway SERVER[1240]: Dispatch_input: bad request line > 'BBXX%.176u%3 > >00$nsecurity.%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > 0\220\220\220\220\220\220111F\200\2111f\2111\211C\211]C\211]K\211M\215M\2001\211ECf > > > > Jul 2 15:12:53 gateway SERVER[1152]: Dispatch_input: bad request line > 'BBTUVWXX%.20u%30 > >0$n%.166u%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > >0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 > 0\220\220\220\220\220111F\200\2111f\2111\211C\211]C\211]K\211M\215M\2001\211ECf\211 > > This continued for about half an hour. Then it stopped. What's going on > here?? > > - I think you just got 'rooted'. Look at /etc/inetd.conf (if it exists on your system, the xinetd is more robust). It may have a new entry on its last line providing a root shell to anybody. This looks somewhat like an attack shown by CERN about 6 to 12 months ago. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
> Because if we just pass in this one extra piece of information which is > normally already available in the driver, we can avoid a whole lot of ugly > cruft in the out-of-line functions by plugging in the correct out-of-line > function to match the resource. Case 1: You pass a single cookie to the readb code Odd platforms decode it Case 2: You carry around bus number information all throughout each driver You keep putting it on/off the stack You keep it in structures You do complex generic locking for hotplug 'just in case' I think I prefer case 1. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
[EMAIL PROTECTED] said: > The question I think being ignored here is. Why not leave things as > is. Because if we just pass in this one extra piece of information which is normally already available in the driver, we can avoid a whole lot of ugly cruft in the out-of-line functions by plugging in the correct out-of-line function to match the resource. > The multiple bus stuff is a port specific detail hidden behind > readb() and friends. The alternative view is that the _single_ bus stuff is a port-specific detail which has permeated all the drivers and forced the non-i386 architectures' I/O functions to have to try to work out which bus they're talking to when the driver could have just passed that information to them. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
> [EMAIL PROTECTED] said: > > I think the second #define should be: > > #define res_readb(res, adr) readb(res->start+adr) > > for consistency. > > You're right that it should be consistent. But it doesn't really matter > whether we pass an offset within the resource, or whether we continue to The question I think being ignored here is. Why not leave things as is. The multiple bus stuff is a port specific detail hidden behind readb() and friends. On the HP PA32 its already hiding controller number encodings and generating multiple cycles under spinlocks for PCI I/O space and the devices dont know about it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
[EMAIL PROTECTED] said: > I think the second #define should be: > #define res_readb(res, adr) readb(res->start+adr) > for consistency. You're right that it should be consistent. But it doesn't really matter whether we pass an offset within the resource, or whether we continue to pass the full 'bus address'. The driver doesn't even need to care - it just adds the register offset to whatever opaque cookie it's given as the address of that resource anyway. That's really an orthogonal issue. The _important_ bit is that we pass the resource to the I/O functions, so that in the case where they're out-of-line, they don't need to play silly buggers with the numbers they're given just to work out which bus they should be talking to. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange errors in /var/log/messages
> I'm running RedHat 7.0 with all official RH patches applied. The kernel I > currently run fow a few days is 2.2.19-7.0.8 > I run the pre-compiled kernel of RH. Suddenly I the following messages: > > Jul 2 15:12:16 gateway SERVER[1240]: Dispatch_input: bad request line > 'BBXX%.176u%3 > >00$nsecurity.%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 These are for an application. Not sure which or why - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange errors in /var/log/messages
<[EMAIL PROTECTED]> writes: > Hi! > > I'm running RedHat 7.0 with all official RH patches applied. The kernel I > currently run fow a few days is 2.2.19-7.0.8 > I run the pre-compiled kernel of RH. Suddenly I the following messages: > This continued for about half an hour. Then it stopped. What's going on > here?? Here you have two options: You are either under attack by someone who's trying to exploit your LPRng (someone's trying to use LPR's logging function to get a shell). This is the LPRng string format _syslog bug that theoretically could allow root access. For more info check http://www.securityfocus.com/vdb/bottom.html?vid=1712 The other option is that you're under rpc.statd attack at the moment. In either case, make sure you upgraded to the latest patch versions and subscribe to BugTraq and the Security Focus Incidents mailinglist :) regards, Remco -- Remco B. Brink - SOL Børs A/S systemsdeveloper - http://www.norge-invest.no Personal site at http://rc6.org - PGP/GnuPG key at http://rc6.org/rbb.pgp "What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water." (By Matt Welsh) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strange errors in /var/log/messages
Hi! I'm running RedHat 7.0 with all official RH patches applied. The kernel I currently run fow a few days is 2.2.19-7.0.8 I run the pre-compiled kernel of RH. Suddenly I the following messages: Jul 2 15:12:16 gateway SERVER[1240]: Dispatch_input: bad request line 'BBXX%.176u%3 00$nsecurity.%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220111F\200\2111f\2111\211C\211]C\211]K\211M\215M\2001\211ECf Jul 2 15:12:53 gateway SERVER[1152]: Dispatch_input: bad request line 'BBTUVWXX%.20u%30 0$n%.166u%301$n%302$n%.192u%303$n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220111F\200\2111f\2111\211C\211]C\211]K\211M\215M\2001\211ECf\211 This continued for about half an hour. Then it stopped. What's going on here?? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WOL with 3c59x and 2.4.6-pre6 breaks WOL
Andrew Morton wrote: > --- linux-2.4.6-pre8/drivers/pci/pci.c Sun Jul 1 16:11:25 2001 > +++ linux-akpm/drivers/pci/pci.cTue Jul 3 01:28:35 2001 > @@ -425,7 +425,7 @@ int pci_enable_wake(struct pci_dev *dev, > > if (enable) value |= PCI_PM_CTRL_PME_STATUS; > else value &= ~PCI_PM_CTRL_PME_STATUS; > - > + value |= PCI_PM_CTRL_PME_ENABLE; > pci_write_config_word(dev, pm + PCI_PM_CTRL, value); > > return 0; wrong but it seems you spotted a bug in the code -- set/clear _ENABLE right above your change here. maybe read and write _STATUS unconditionally, for paranoia. -- Jeff Garzik | The LSB is a bunch of crap. Building 1024| E-mail for details. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
> #ifdef OUT_OF_LINE_MMIO > #define res_readb(res, adr) (res->access_ops->readb(res, adr) > #else > #define res_readb(res, adr) readb(adr) > #endif I think the second #define should be: #define res_readb(res, adr) readb(res->start+adr) for consistency. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix kernel linker scripts
Hi!
Apparently all kernel scripts only have .rodata and not also .rodata.* input
sections in it.
This has been no problem so far, but since binutils and gcc support SHF_MERGE
sections (so that string constant (and other constant too) duplicates can be
removed at link time) the compiler creates sections like .rodata.str1.1
and they really should be merged into the rodata output section
(or whatever else) during linking (the default binutils linker scripts are
doing this for ages).
On some architectures it creates no problems, just one more section in
section table (like i386), on others it causes the kernel not to boot at all
(e.g. on ia64).
Please apply.
--- linux/arch/alpha/boot/bootloader.lds.jj Sun Sep 6 13:34:33 1998
+++ linux/arch/alpha/boot/bootloader.ldsTue Jun 26 11:05:14 2001
@@ -6,7 +6,7 @@ SECTIONS
.text : { *(.text) }
_etext = .;
PROVIDE (etext = .);
- .rodata : { *(.rodata) }
+ .rodata : { *(.rodata) *(.rodata.*) }
.data : { *(.data) CONSTRUCTORS }
.got : { *(.got) }
.sdata : { *(.sdata) }
--- linux/arch/alpha/vmlinux.lds.in.jj Mon Jun 26 14:26:56 2000
+++ linux/arch/alpha/vmlinux.lds.in Tue Jun 26 11:05:24 2001
@@ -53,7 +53,7 @@ SECTIONS
/* Global data */
_data = .;
.data.cacheline_aligned : { *(.data.cacheline_aligned) }
- .rodata : { *(.rodata) }
+ .rodata : { *(.rodata) *(.rodata.*) }
.data : { *(.data) CONSTRUCTORS }
.got : { *(.got) }
.sdata : { *(.sdata) }
--- linux/arch/arm/boot/compressed/vmlinux.lds.in.jjThu Feb 8 19:32:44 2001
+++ linux/arch/arm/boot/compressed/vmlinux.lds.in Tue Jun 26 11:05:35 2001
@@ -24,6 +24,7 @@ SECTIONS
*(.fixup)
*(.gnu.warning)
*(.rodata)
+*(.rodata.*)
*(.glue_7)
*(.glue_7t)
input_data = .;
--- linux/arch/arm/vmlinux-armo.lds.in.jj Thu Feb 8 19:32:44 2001
+++ linux/arch/arm/vmlinux-armo.lds.in Tue Jun 26 11:05:49 2001
@@ -47,6 +47,7 @@ SECTIONS
*(.gnu.warning)
*(.text.lock) /* out-of-line lock text */
*(.rodata)
+ *(.rodata.*)
*(.glue_7)
*(.glue_7t)
*(.kstrtab)
--- linux/arch/arm/vmlinux-armv.lds.in.jj Wed May 16 18:25:16 2001
+++ linux/arch/arm/vmlinux-armv.lds.in Tue Jun 26 11:05:57 2001
@@ -42,6 +42,7 @@ SECTIONS
*(.gnu.warning)
*(.text.lock) /* out-of-line lock text */
*(.rodata)
+ *(.rodata.*)
*(.glue_7)
*(.glue_7t)
*(.got) /* Global offset table */
--- linux/arch/cris/boot/compressed/decompress.ld.jjFri Apr 6 13:42:55 2001
+++ linux/arch/cris/boot/compressed/decompress.ld Tue Jun 26 11:06:04 2001
@@ -13,6 +13,7 @@ SECTIONS
_stext = . ;
*(.text)
*(.rodata)
+ *(.rodata.*)
_etext = . ;
} > dram
.data :
--- linux/arch/cris/cris.ld.jj Tue May 1 19:04:56 2001
+++ linux/arch/cris/cris.ld Tue Jun 26 11:06:23 2001
@@ -24,7 +24,7 @@ SECTIONS
*(.fixup)
*(.text.__*)
*(.rodata)
- *(.rodata.__*)
+ *(.rodata.*)
}
. = ALIGN(4);/* Exception table */
--- linux/arch/i386/vmlinux.lds.jj Wed Jan 3 23:45:26 2001
+++ linux/arch/i386/vmlinux.lds Tue Jun 26 11:06:33 2001
@@ -17,7 +17,7 @@ SECTIONS
_etext = .; /* End of text section */
- .rodata : { *(.rodata) }
+ .rodata : { *(.rodata) *(.rodata.*) }
.kstrtab : { *(.kstrtab) }
. = ALIGN(16); /* Exception table */
--- linux/arch/ia64/boot/bootloader.lds.jj Sun Feb 6 21:42:40 2000
+++ linux/arch/ia64/boot/bootloader.lds Tue Jun 26 11:06:42 2001
@@ -12,7 +12,7 @@ SECTIONS
/* Global data */
_data = .;
- .rodata : { *(.rodata) }
+ .rodata : { *(.rodata) *(.rodata.*) }
.data: { *(.data) *(.gnu.linkonce.d*) CONSTRUCTORS }
__gp = ALIGN (8) + 0x20;
.got : { *(.got.plt) *(.got) }
--- linux/arch/ia64/sn/fprom/fprom.lds.jj Thu Jan 4 16:00:15 2001
+++ linux/arch/ia64/sn/fprom/fprom.lds Tue Jun 26 11:07:02 2001
@@ -24,7 +24,7 @@ SECTIONS
_data = .;
.rodata : AT(ADDR(.rodata) - 0x )
- { *(.rodata) }
+ { *(.rodata) *(.rodata.*) }
.opd : AT(ADDR(.opd) - 0x )
{ *(.opd) }
.data : AT(ADDR(.data) - 0x )
--- linux/arch/ia64/vmlinux.lds.S.jjThu Apr 5 15:51:47 2001
+++ linux/arch/ia64/vmlinux.lds.S Tue Jun 26 11:07:15 2001
@@ -83,7 +83,7 @@ SECTIONS
ia64_unw_end = .;
.rodata : AT(ADDR(.rodata) - PAGE_OFFSET)
- { *(.rodata) }
+ { *(.rodata) *(.rodata.*) }
.kstrtab : AT(ADDR(.kstrtab) - PAGE_OFFSET)
{ *(.kstrtab) }
.opd : AT(ADDR(.opd) -
[PATCH] Fix binfmt_elf.c
Hi!
There is a bug in binfmt_elf.c if the dynamic linker has non-zero base vaddr
(e.g. if it is prelinked). The issue is that in such case ld-linux.so.2 is
loaded at ELF_ET_DYN_BASE + p_vaddr instead of ELF_ET_DYN_BASE, on some
architectures into non-desirable places in virtual memory.
Best explained on a ld-linux.so.2 prelink(1)ed to 0x4000 on ia32:
$ LD_TRACE_LOADED_OBJECTS=1 ./ld-linux.so.2 ./libc.so.6
/lib/ld-linux.so.2 => ./ld-linux.so.2 (0x6000)
ELF_ET_DYN_BASE is defined to 0x2000 in ia32 (see the patch, it was
meant to be 0x8000), so ld-linux.so.2 should have l_map_start 0x2000
while as you see in reality it has 0x6000.
If this prelinked VMA + ELF_ET_DYN_BASE fits into kernel reserved address
space, ./ld-linux.so.2 running won't work at all.
Also, many platforms such as i386 use
#define ELF_ET_DYN_BASE (2 * TASK_SIZE / 3)
which I guess is not what was originally intended (on i386 this is usually
0x2aaa). As this value gets passed to elf_map which rounds it down to
ELF page boundary anyway, I think (TASK_SIZE / 3 * 2) is far better.
I've changed it on ia32 only, but if someone would test it on other
platforms which set ELF_ET_DYN_BASE this way it would be probably good to
change elsewhere as well.
--- linux/fs/binfmt_elf.c.jjThu May 24 11:11:36 2001
+++ linux/fs/binfmt_elf.c Thu May 24 11:32:26 2001
@@ -396,7 +396,7 @@ out:
static int load_elf_binary(struct linux_binprm * bprm, struct pt_regs * regs)
{
struct file *interpreter = NULL; /* to shut gcc up */
- unsigned long load_addr = 0, load_bias;
+ unsigned long load_addr = 0, load_bias = 0;
int load_addr_set = 0;
char * elf_interpreter = NULL;
unsigned int interpreter_type = INTERPRETER_NONE;
@@ -595,12 +595,6 @@ static int load_elf_binary(struct linux_
setup_arg_pages(bprm); /* XXX: check error */
current->mm->start_stack = bprm->p;
- /* Try and get dynamic programs out of the way of the default mmap
- base, as well as whatever program they might try to exec. This
- is because the brk will follow the loader, and is not movable. */
-
- load_bias = ELF_PAGESTART(elf_ex.e_type==ET_DYN ? ELF_ET_DYN_BASE : 0);
-
/* Now we do a little grungy work by mmaping the ELF image into
the correct location in memory. At this point, we assume that
the image should be loaded at fixed address, not at a variable
@@ -624,6 +618,11 @@ static int load_elf_binary(struct linux_
vaddr = elf_ppnt->p_vaddr;
if (elf_ex.e_type == ET_EXEC || load_addr_set) {
elf_flags |= MAP_FIXED;
+ } else if (elf_ex.e_type == ET_DYN) {
+ /* Try and get dynamic programs out of the way of the default
+mmap
+ base, as well as whatever program they might try to exec.
+This
+ is because the brk will follow the loader, and is not
+movable. */
+ load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr);
}
error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt, elf_prot,
elf_flags);
--- linux/include/asm-i386/elf.h.jj Mon Mar 26 18:48:10 2001
+++ linux/include/asm-i386/elf.hThu May 24 11:49:38 2001
@@ -55,7 +55,7 @@ typedef struct user_fxsr_struct elf_fpxr
the loader. We need to make sure that it is out of the way of the program
that it will "exec", and that there is sufficient room for the brk. */
-#define ELF_ET_DYN_BASE (2 * TASK_SIZE / 3)
+#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2)
/* Wow, the "main" arch needs arch dependent functions too.. :) */
Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WOL with 3c59x and 2.4.6-pre6 breaks WOL
Tobias Ringstrom wrote:
>
> I just tried 2.4.6-pre6 this morning, and found out that when I enable
> WOL (using enable_wol=1), my 3c905c-tx does not work at all any more.
> It worked just fine with 2.4.5. Without enable_wol=1, I have no problems.
>
> It is my guess that this is very easy to reproduce, but if not, please ask
> me for more details. I'm attaching the dmesg output. I'll be gone until
> monday.
Seems that the new PM code has broken the driver. It
wasn't doing the right thing in the first place.
Please use 2.4.6-pre8 plus this patch, let me know.
--- linux-2.4.6-pre8/drivers/pci/pci.c Sun Jul 1 16:11:25 2001
+++ linux-akpm/drivers/pci/pci.cTue Jul 3 01:28:35 2001
@@ -425,7 +425,7 @@ int pci_enable_wake(struct pci_dev *dev,
if (enable) value |= PCI_PM_CTRL_PME_STATUS;
else value &= ~PCI_PM_CTRL_PME_STATUS;
-
+ value |= PCI_PM_CTRL_PME_ENABLE;
pci_write_config_word(dev, pm + PCI_PM_CTRL, value);
return 0;
--- linux-2.4.6-pre8/drivers/net/3c59x.cSun Jul 1 16:11:24 2001
+++ linux-akpm/drivers/net/3c59x.c Tue Jul 3 01:29:08 2001
@@ -760,6 +760,7 @@ struct vortex_private {
u16 io_size;/* Size of PCI region
(for release_region) */
spinlock_t lock;/* Serialise access to
device & its vortex_private */
spinlock_t mdio_lock; /* Serialise access to mdio
hardware */
+ u32 power_state[16];
};
/* The action to take with a media selection timer tick.
@@ -1239,9 +1240,6 @@ static int __devinit vortex_probe1(struc
}
}
- if (pdev && vp->enable_wol && (vp->capabilities & CapPwrMgmt))
- acpi_set_WOL(dev);
-
if (vp->capabilities & CapBusMaster) {
vp->full_bus_master_tx = 1;
printk(KERN_INFO" Enabling bus-master transmits and %s receives.\n",
@@ -1279,6 +1277,10 @@ static int __devinit vortex_probe1(struc
dev->set_multicast_list = set_rx_mode;
dev->tx_timeout = vortex_tx_timeout;
dev->watchdog_timeo = (watchdog * HZ) / 1000;
+ if (pdev && vp->enable_wol) {
+ pci_save_state(vp->pdev, vp->power_state);
+ acpi_set_WOL(dev);
+ }
retval = register_netdev(dev);
if (retval == 0)
return 0;
@@ -1331,8 +1333,10 @@ vortex_up(struct net_device *dev)
unsigned int config;
int i;
- if (vp->pdev && vp->enable_wol) /* AKPM: test not needed? */
+ if (vp->pdev && vp->enable_wol) {
pci_set_power_state(vp->pdev, 0); /* Go active */
+ pci_restore_state(vp->pdev, vp->power_state);
+ }
/* Before initializing select the active media port. */
EL3WINDOW(3);
@@ -1516,9 +1520,6 @@ vortex_open(struct net_device *dev)
int i;
int retval;
- if (vp->pdev && vp->enable_wol) /* AKPM: test not
needed? */
- pci_set_power_state(vp->pdev, 0); /* Go active */
-
/* Use the now-standard shared IRQ implementation. */
if ((retval = request_irq(dev->irq, vp->full_bus_master_rx ?
_interrupt : _interrupt, SA_SHIRQ,
dev->name, dev))) {
@@ -2452,8 +2453,10 @@ vortex_down(struct net_device *dev)
if (vp->full_bus_master_tx)
outl(0, ioaddr + DownListPtr);
- if (vp->pdev && vp->enable_wol && (vp->capabilities & CapPwrMgmt))
+ if (vp->pdev && vp->enable_wol) {
+ pci_save_state(vp->pdev, vp->power_state);
acpi_set_WOL(dev);
+ }
}
static int
@@ -2808,8 +2811,10 @@ static void acpi_set_WOL(struct net_devi
/* The RxFilter must accept the WOL frames. */
outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast, ioaddr + EL3_CMD);
outw(RxEnable, ioaddr + EL3_CMD);
+
/* Change the power state to D3; RxEnable doesn't take effect. */
- pci_set_power_state(vp->pdev, 0x8103);
+ pci_enable_wake(vp->pdev, 0, 1);
+ pci_set_power_state(vp->pdev, 3);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
"Jim Roland" <[EMAIL PROTECTED]>: > From: "Jesse Pollard" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; "Kurt Maxwell Weber" <[EMAIL PROTECTED]>; "J Sloan" > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, July 01, 2001 3:03 PM > Subject: Re: Uncle Sam Wants YOU! > > > [snip] > > >In that case, I have the following options: > > >1) Start my own ISP > > > > Only if the upstream provider doesn't require you to use windows. > > > > >2) Use Windows XP > > >3) Not use Windows XP and not be able to use my current ISP > > >4) Go to a different ISP > > > > You may not be able to find another. It took me a year. I gave up. I was > > fortunate that Verio doesn't care what you have... though if you use > > the dialup or basic dsl, MS is it, or no real support. > > > > >I'll just have to decide which I value more. As long as I won't be > killed > > >for using a different OS, I still have a choice. > > > > No, but you might be forced out of a job. > > In one of the large metro areas in which I live, there are a LOT of ISPs > that do not require you to use Windows, but will not support you beyond the > IP layer if you don't. Use linux, install PPP with MS-CHAPv2 (with or > without MPPE) for your dialup connection and it works just fine on a > Winblows-only ISP. DSL or Cable, just acquire your actual IP settings > program a Linksys router/hub box and be done with it. Better re-read the fine print on the "fair-use" statement. BOTH DSL and Cable, or dialup (New Orleans at least) will disconnect you if you run ANY unattended operation (if they determine it IS unattended). No daemon services. No routing/NAT (unless they do it). No remote login. No mail. DHCP reconfig between 4 and 8 hours (or whenever they choose to). They will let you plug in, but will not provide any support (even TCP/IP is not assured). - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[was: Re: Maintainers master list]
Wed Jun 27 2001 - 10:12:18 EST, Jes Sorensen said: > A good place to start would be to write a script that checks the email > addresses listed in there for bounces say every 6 months (not too > often or people will get grumphy). Oh and maybe include the data about > the person so he/she can verify it's ok, maybe this way we can get > forget this meta-data sillyness. OK, but what about those people who have two addresses listed in the mainainers-file? Do they have to answer those autogenerated mails twice? A sollution to this may be that we only allow one address per entry, but I think that some people will object to this. And what should we do if the mail bounces? Should we remove the entry, or should we try to contact the (former) maintainer? I think this would be difficult, because we can't reach them by mail any more... Regards, Marc Brekoo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
[EMAIL PROTECTED] said: > But it's going to cost for the ones who do not support this. You don't need to make it out-of-line for all cases - or indeed in any case where it isn't out-of-line already. Some architectures may have only IO calls out-of-line (many already do). Some may have MMIO calls out-of-line too - some already do that too. It would just be nice to have a standard way of doing it, and in particular it would be nice to pass the struct resource into the out-of-line functions in the case where they _are_ out of line, so that the Iyou/O functions don't have to play evil tricks with the numbers they're given to work out which bus the caller wanted to talk to. #ifdef OUT_OF_LINE_MMIO #define res_readb(res, adr) (res->access_ops->readb(res, adr) #else #define res_readb(res, adr) readb(adr) #endif etc. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with SMC Etherpower II + kernel newer 2.4.2
On Mon, 2 Jul 2001, Juergen Wolf wrote: > currently I experience some strange problems with every kernels newer > than 2.4.2 and my SMC Etherpower II network card. While running such a > kernel, the network hangs and I get lots of errors like these listed > below: under the dumb question department: a) bad cable? b) not negotiating speed and duplex with the switch correctly? c) bad card? d) IRQ sharing causing a conflict? I'm less predisposed to blame the card in general or the driver, as I have probably about a dozen SMC epic100 cards here, in single processor x86, dual x86, and dual alphas that have been flawless from about 2.2.14 to 2.4.4. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmap
I use the 'map_user_kiobuf' and 'lock_kiovec' kernel routines in a module for 'user space memory'. After that if I pass the '(iobuf->maplist[0])-mem_map) << PAGE_SHIFT)' to the hardware for DMA operations and it works fine for Intel platforms. Now how can I use the 'iobuf' struct obtained after lock_kiovec operation to get a PCI bus address that I can pass to hardware for DMA operations on my Apple machine.? thanks, Daljeet. |+---> || Gerd Knorr | ||| || | || 05/15/01 | || 01:03 PM | || Please | || respond to | || Gerd Knorr | || | |+---> >---| | | | To: [EMAIL PROTECTED]| | cc: (bcc: Daljeet Maini/India/IBM) | | Subject: Re: mmap | >---| [EMAIL PROTECTED] wrote: > I am doing the following: > > malloc some memory is user space > pass its pointer to some kernel module > in the kernel module...do a pci_alloc_consistent so that i get a memory > region for PCI DMA operations Wrong approach, you can use kiobufs if you want DMA to the malloc()ed userspace memory: * lock down the user memory using map_user_kiobuf() + lock_kiovec() (see linux/iobuf.h). * translate the iobuf->maplist into a scatterlist [1] * feed pci_map_sg() with the scatterlist to get DMA addresses. you can pass to the hardware. And the reverse to free everything when you are done of course. Gerd [1] IMHO it would be more useful if iobufs would use a scatterlist instead of an struct page* array. -- Gerd Knorr <[EMAIL PROTECTED]> -- SuSE Labs, Außenstelle Berlin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible problem with IDE device driver in kernel.
On Thu, 2 Jan 1997, Philip V. Neves wrote: > I would like to report a bug that I've seen in a few linux kernels now. This > may be a serious problem with the IDE controler software because it may cause > a hard drive to ware out over a period of time. I've noticed for a long time > that when linux is loaded the hard drive light on my computer goes on and > stays on. It never turns off. If I boot with windows the light turns off. I > think it may be the device driver that forgets to turn of the light. Could > one of you please confirm if this is a problem with the kernel and get back > to me if it is not. > > Thank you, > > > Philip V. Neves I experience the same feature, but not only in Linux. BeOS, FreeBSD, NetBSD, OpenBSD do not turn off the IDE light. The manual for my main board (GA-6BXDS) sais that the light does not turn off if no SCSI devices are attached to the board and SCSI is set to 'off' in the BIOS. But even if I turn it on, the light is constantly lit. If I use a kernel compiled for Pentium (not PII which I really have) the lamp does turn off sometimes (I mean with some kernels, I don't see any other regularity). I'm using a western Digital Caviar disk (WDC AC29100D) for over 2 years now, and everything but for the light is fine. Cezary Kaliszyk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: VM Requirement Document - v0.0
Hi, > My laptop has 256mb of ram, > but every day > it runs the updatedb for locate. The remedy here is simple: Do not run updatedb from cron, but only when you made changes. Greetings, Jens - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
[EMAIL PROTECTED] said: > So the Config.in is wrong since I can select spia on x86 Yep. I've added a few more dependencies like that to the map drivers too. I heard rumours that someone else had done similar changes, but nobody sent me a patch so those rumours can't be true. I'll wait for Steven to fix this up and then send all those changes to Linus. Assuming, that is, that nobody else takes it upon themselves to keep resending small bits of the pending changes, gratuitously making it harder to me to keep in sync. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
>> (a) It does less, namely will not kill processes with uid 0.
>> Ted, any objections?
Alan:
> That breaks the security guarantee. Suppose I use a setuid app to confuse
> you into doing something ?
On second thoughts I agree. Here is the patch without test for p->uid.
Andries
diff -u --recursive --new-file ../linux-2.4.6-pre8/linux/drivers/char/keyboard.c
./linux/drivers/char/keyboard.c
--- ../linux-2.4.6-pre8/linux/drivers/char/keyboard.c Mon Oct 16 21:58:51 2000
+++ ./linux/drivers/char/keyboard.c Mon Jul 2 13:28:09 2001
@@ -506,6 +506,8 @@
* them properly.
*/
+ if (!tty && ttytab && ttytab[0] && ttytab[0]->driver_data)
+ tty = ttytab[0];
do_SAK(tty);
reset_vc(fg_console);
#if 0
diff -u --recursive --new-file ../linux-2.4.6-pre8/linux/drivers/char/tty_io.c
./linux/drivers/char/tty_io.c
--- ../linux-2.4.6-pre8/linux/drivers/char/tty_io.c Sun Jul 1 15:19:26 2001
+++ ./linux/drivers/char/tty_io.c Mon Jul 2 14:53:52 2001
@@ -1818,20 +1818,29 @@
*
* Nasty bug: do_SAK is being called in interrupt context. This can
* deadlock. We punt it up to process context. AKPM - 16Mar2001
+ *
+ * Treat all VTs as a single tty for the purposes of SAK. A process with an
+ * open fd for one VT can do interesting things to all. aeb, 2001-07-02
*/
-static void __do_SAK(void *arg)
+#ifdef CONFIG_VT
+static inline int tty_is_vt(struct tty_struct *tty)
{
-#ifdef TTY_SOFT_SAK
- tty_hangup(tty);
+ return tty ? (tty->driver.type == TTY_DRIVER_TYPE_CONSOLE) : 0;
+}
#else
- struct tty_struct *tty = arg;
+static inline int tty_is_vt(struct tty_struct *tty)
+{
+ return 0;
+}
+#endif
+
+static inline void tty_hard_SAK(struct tty_struct *tty)
+{
struct task_struct *p;
int session;
- int i;
- struct file *filp;
-
- if (!tty)
- return;
+ int i;
+ struct file *filp;
+
session = tty->session;
if (tty->ldisc.flush_buffer)
tty->ldisc.flush_buffer(tty);
@@ -1839,7 +1848,9 @@
tty->driver.flush_buffer(tty);
read_lock(_lock);
for_each_task(p) {
+ /* all VTs are considered a single tty here */
if ((p->tty == tty) ||
+ (tty_is_vt(tty) && tty_is_vt(p->tty)) ||
((session > 0) && (p->session == session))) {
send_sig(SIGKILL, p, 1);
continue;
@@ -1850,7 +1861,9 @@
for (i=0; i < p->files->max_fds; i++) {
filp = fcheck_files(p->files, i);
if (filp && (filp->f_op == _fops) &&
- (filp->private_data == tty)) {
+ (filp->private_data == tty ||
+(tty_is_vt(tty) &&
+ tty_is_vt(filp->private_data {
send_sig(SIGKILL, p, 1);
break;
}
@@ -1860,6 +1873,17 @@
task_unlock(p);
}
read_unlock(_lock);
+}
+
+static void __do_SAK(void *arg)
+{
+ struct tty_struct *tty = arg;
+ if (!tty) /* impossible */
+ return;
+#ifdef TTY_SOFT_SAK
+ tty_hangup(tty);
+#else
+ tty_hard_SAK(tty);
#endif
}
@@ -1872,6 +1896,8 @@
*/
void do_SAK(struct tty_struct *tty)
{
+ if (!tty)
+ return;
PREPARE_TQUEUE(>SAK_tq, __do_SAK, tty);
schedule_task(>SAK_tq);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
[EMAIL PROTECTED] said: > 'spia.c' is the device dependent part. You should write your own > version of 'spia.c' and "simply" fill in the addresses for the IO > address and control register address depending on your specific > hardware. The above symbols are only defined for my specific hardware. Where are those four variables defined? In platform-dependent code for your board? If so, we should probably make the config option dependent on that platform. That'll make ESR whinge at me if support for your platform isn't (yet) in Linus' tree - but I don't care too much about that. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
> The way that I architected the raw NAND flash device driver was to > break it into 2 parts. 'nand.c' contains the actual driver code and > is considered to be device independent. 'spia.c' is the device > dependent part. You should write your own version of 'spia.c' and So the Config.in is wrong since I can select spia on x86 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
>> (a) It does less, namely will not kill processes with uid 0. >> Ted, any objections? Alan: > That breaks the security guarantee. Suppose I use a setuid app to confuse > you into doing something ? You confuse me? Unlikely :-) Indeed, discussion is possible. I think my version is more secure and more useful, but if you disagree, delete the lines /* do not kill root processes */ if (p->uid == 0) continue; Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols
"Adam J. Richter" wrote: > > linux-2.4.6-pre8/drivers/mtd/nand/spia.c references four > undefined symbols, presumably intended to be #define constants, > although I am not sure what their values are supposed to be: > > IO_BASE > FIO_BASE > PEDR > PEDDR > The way that I architected the raw NAND flash device driver was to break it into 2 parts. 'nand.c' contains the actual driver code and is considered to be device independent. 'spia.c' is the device dependent part. You should write your own version of 'spia.c' and "simply" fill in the addresses for the IO address and control register address depending on your specific hardware. The above symbols are only defined for my specific hardware. They should be changed to values used on your hardware platform. Let me know if you need further assistance. -Steve -- Steven J. Hill - Embedded SW Engineer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
> (a) It does less, namely will not kill processes with uid 0. > Ted, any objections? That breaks the security guarantee. Suppose I use a setuid app to confuse you into doing something ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] more SAK stuff
Dear Linus, Alan, Ted, Andrew, all:
(i) Andrew - why don't you add yourself to the CREDITS file?
(then I'll find your email address at the first instead of the second attempt)
(ii) Yesterday I complained about the fact that pressing SAK twice
crashes the kernel (because the close from the first time will set
tty->driver_data = 0;
and then on the next press kbd has tty==0 and do_SAK() kills the system).
There is more bad stuff in this 2.4.3 patch:
-void do_SAK( struct tty_struct *tty)
+static void __do_SAK(void *arg)
{
#ifdef TTY_SOFT_SAK
tty_hangup(tty);
#else
+ struct tty_struct *tty = arg;
Clearly, if TTY_SOFT_SAK is defined this will not compile
(or, worse, will pick up some global variable tty).
The patch below has yesterdays fix of do_SAK(), and fixes this
compilation problem. I invented a separate inline routine here -
I do not like very long stretches of code inside #ifdef.
More interestingly, it changes the operation of SAK in two ways:
(a) It does less, namely will not kill processes with uid 0.
Ted, any objections?
For example, when syslog has several output streams, and one is
to /dev/tty10, then a SAK typed at /dev/tty10 should not kill syslog,
that is bad for security.
(b) It does more, namely will for the purposes of SAK consider all
VTs equivalent, so that a SAK typed on /dev/tty1 also kills processes
that have an open file descriptor on /dev/tty2.
That is good for security, since many keyboard or console ioctls just
require an open fd for some VT, and this process on tty2 can for example
change the keymap on tty1.
One of the motivations of this patch was that SAK should be able
to kill a "while [ 1 ]; do chvt 21; done", that is the reason
for the keyboard.c fragment.
Ted, please complain if anything is wrong with the way
filp->private_data is used.
Andries
diff -u --recursive --new-file ../linux-2.4.6-pre8/linux/drivers/char/keyboard.c
./linux/drivers/char/keyboard.c
--- ../linux-2.4.6-pre8/linux/drivers/char/keyboard.c Mon Oct 16 21:58:51 2000
+++ ./linux/drivers/char/keyboard.c Mon Jul 2 13:28:09 2001
@@ -506,6 +506,8 @@
* them properly.
*/
+ if (!tty && ttytab && ttytab[0] && ttytab[0]->driver_data)
+ tty = ttytab[0];
do_SAK(tty);
reset_vc(fg_console);
#if 0
diff -u --recursive --new-file ../linux-2.4.6-pre8/linux/drivers/char/tty_io.c
./linux/drivers/char/tty_io.c
--- ../linux-2.4.6-pre8/linux/drivers/char/tty_io.c Sun Jul 1 15:19:26 2001
+++ ./linux/drivers/char/tty_io.c Mon Jul 2 13:27:19 2001
@@ -1818,20 +1818,29 @@
*
* Nasty bug: do_SAK is being called in interrupt context. This can
* deadlock. We punt it up to process context. AKPM - 16Mar2001
+ *
+ * Treat all VTs as a single tty for the purposes of SAK. A process with an
+ * open fd for one VT can do interesting things to all. aeb, 2001-07-02
*/
-static void __do_SAK(void *arg)
+#ifdef CONFIG_VT
+static inline int tty_is_vt(struct tty_struct *tty)
{
-#ifdef TTY_SOFT_SAK
- tty_hangup(tty);
+ return tty ? (tty->driver.type == TTY_DRIVER_TYPE_CONSOLE) : 0;
+}
#else
- struct tty_struct *tty = arg;
+static inline int tty_is_vt(struct tty_struct *tty)
+{
+ return 0;
+}
+#endif
+
+static inline void tty_hard_SAK(struct tty_struct *tty)
+{
struct task_struct *p;
int session;
- int i;
- struct file *filp;
-
- if (!tty)
- return;
+ int i;
+ struct file *filp;
+
session = tty->session;
if (tty->ldisc.flush_buffer)
tty->ldisc.flush_buffer(tty);
@@ -1839,7 +1848,12 @@
tty->driver.flush_buffer(tty);
read_lock(_lock);
for_each_task(p) {
+ /* do not kill root processes */
+ if (p->uid == 0)
+ continue;
+ /* all VTs are considered a single tty here */
if ((p->tty == tty) ||
+ (tty_is_vt(tty) && tty_is_vt(p->tty)) ||
((session > 0) && (p->session == session))) {
send_sig(SIGKILL, p, 1);
continue;
@@ -1850,7 +1864,9 @@
for (i=0; i < p->files->max_fds; i++) {
filp = fcheck_files(p->files, i);
if (filp && (filp->f_op == _fops) &&
- (filp->private_data == tty)) {
+ (filp->private_data == tty ||
+(tty_is_vt(tty) &&
+ tty_is_vt(filp->private_data {
send_sig(SIGKILL, p, 1);
break;
}
@@ -1860,6 +1876,17 @@
task_unlock(p);
}
read_unlock(_lock);
+}
+
+static void __do_SAK(void *arg)
+{
+ struct tty_struct *tty = arg;
+
Re: Uncle Sam Wants YOU!
On Sun, 1 Jul 2001 20:19:07 -0500 Mon, 2 Jul 01 12:25:43 BST, you wrote: >- Original Message - >From: "William T Wilson" <[EMAIL PROTECTED]> >> On Sun, 1 Jul 2001, Ben Ford wrote: >> >> > This seems to be meant as a joke, but I don't think it's all that >unlikely. >> > >> > I seem to recall that MS products cannot be used in aircraft control >> > rooms for this reason. >> >> It's not just MS. Aircraft control rooms (as well as nuclear power >> plants, spacecraft mission control, etc.) require special certified >> software to be used - it's not simply that they avoid MS, they avoid all >> software that hasn't been blessed. >> >> My understanding is that astronauts going up on the shuttle take turns >> bringing a laptop computer so they have actual computing power available >> to them. The shuttle computer is not adequate for many tasks because it >> is something like 30 years old, but that's what they use because it is >> certified. So somebody has to bring along a non-certified system in their >> "personal effects" allowance to get real work done :} > >From what I've heard, NASA relies heavily on modified Linux. Last time I was in Mission Control at JSC, some of the consoles I looked at were very obviously X desktops. I didn't look closely enough to identify them more specifically - I'll take a closer look next month when I'm out there again... James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch] tmpfs/ramfs accounting
Hi Alan,
here is the patch you backed out for -ac22.
I slightly changed the approach: I do not rely on removepage to
calculate the fs size any more since the special-casing was ugly and
PG_marker was dropped. But I use removepage for the shmem_nrpages
calculation.
Please apply
Christoph
diff -uNr 5-ac22/fs/ramfs/inode.c 5-ac22-fix/fs/ramfs/inode.c
--- 5-ac22/fs/ramfs/inode.c Mon Jul 2 09:13:18 2001
+++ 5-ac22-fix/fs/ramfs/inode.c Mon Jul 2 09:55:52 2001
@@ -289,7 +289,7 @@
return 0;
}
-static void ramfs_truncatepage(struct page *page)
+static void ramfs_removepage(struct page *page)
{
struct inode *inode = (struct inode *)page->mapping->host;
@@ -659,7 +659,7 @@
writepage: ramfs_writepage,
prepare_write: ramfs_prepare_write,
commit_write: ramfs_commit_write,
- truncatepage: ramfs_truncatepage,
+ removepage: ramfs_removepage,
};
static struct file_operations ramfs_file_operations = {
diff -uNr 5-ac22/include/linux/fs.h 5-ac22-fix/include/linux/fs.h
--- 5-ac22/include/linux/fs.h Mon Jul 2 09:35:39 2001
+++ 5-ac22-fix/include/linux/fs.h Mon Jul 2 10:32:04 2001
@@ -375,7 +375,7 @@
int (*sync_page)(struct page *);
int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
- void (*truncatepage)(struct page *); /* called from truncate_complete_page */
+ void (*removepage)(struct page *); /* called when page gets removed from the
+inode */
/* Unfortunately this kludge is needed for FIBMAP. Don't use it */
int (*bmap)(struct address_space *, long);
};
diff -uNr 5-ac22/mm/filemap.c 5-ac22-fix/mm/filemap.c
--- 5-ac22/mm/filemap.c Mon Jul 2 09:13:29 2001
+++ 5-ac22-fix/mm/filemap.c Mon Jul 2 10:22:52 2001
@@ -87,6 +87,9 @@
{
struct address_space * mapping = page->mapping;
+ if (mapping->a_ops->removepage)
+ mapping->a_ops->removepage(page);
+
mapping->nrpages--;
list_del(>list);
page->mapping = NULL;
@@ -211,9 +214,6 @@
if (!page->buffers || block_flushpage(page, 0))
lru_cache_del(page);
- if (page->mapping->a_ops->truncatepage)
- page->mapping->a_ops->truncatepage(page);
-
/*
* We remove the page from the page cache _after_ we have
* destroyed all buffer-cache references to it. Otherwise some
diff -uNr 5-ac22/mm/shmem.c 5-ac22-fix/mm/shmem.c
--- 5-ac22/mm/shmem.c Mon Jul 2 09:13:29 2001
+++ 5-ac22-fix/mm/shmem.c Mon Jul 2 10:54:55 2001
@@ -34,6 +34,7 @@
#define TMPFS_MAGIC0x01021994
#define ENTRIES_PER_PAGE (PAGE_SIZE/sizeof(unsigned long))
+#define SHMEM_MAX_BLOCKS (SHMEM_NR_DIRECT + ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
#define SHMEM_SB(sb) (>u.shmem_sb)
@@ -51,6 +52,11 @@
#define BLOCKS_PER_PAGE (PAGE_SIZE/512)
+static void shmem_removepage(struct page *page)
+{
+ atomic_dec(_nrpages);
+}
+
/*
* shmem_recalc_inode - recalculate the size of an inode
*
@@ -69,11 +75,9 @@
* (inode->i_mapping->nrpages + info->swapped)
*
* It has to be called with the spinlock held.
- *
- * The swap parameter is a performance hack for truncate.
*/
-static void shmem_recalc_inode(struct inode * inode, unsigned long swap)
+static void shmem_recalc_inode(struct inode * inode)
{
unsigned long freed;
@@ -85,7 +89,6 @@
spin_lock (>stat_lock);
sbinfo->free_blocks += freed;
spin_unlock (>stat_lock);
- atomic_sub(freed-swap, _nrpages);
}
}
@@ -202,7 +205,7 @@
out:
info->max_index = index;
info->swapped -= freed;
- shmem_recalc_inode(inode, freed);
+ shmem_recalc_inode(inode);
spin_unlock (>lock);
up(>sem);
}
@@ -257,7 +260,7 @@
entry = shmem_swp_entry(info, page->index);
if (IS_ERR(entry)) /* this had been allocted on page allocation */
BUG();
- shmem_recalc_inode(page->mapping->host, 0);
+ shmem_recalc_inode(page->mapping->host);
error = -EAGAIN;
if (entry->val)
BUG();
@@ -265,7 +268,6 @@
*entry = swap;
error = 0;
/* Remove the page from the page cache */
- atomic_dec(_nrpages);
lru_cache_del(page);
remove_inode_page(page);
@@ -1086,6 +1088,8 @@
unsigned long max_inodes, inodes;
struct shmem_sb_info *sbinfo = SHMEM_SB(sb);
+ max_blocks = sbinfo->max_blocks;
+ max_inodes = sbinfo->max_inodes;
if (shmem_parse_options (data, NULL, _blocks, _inodes))
return -EINVAL;
@@ -1134,7 +1138,7 @@
sbinfo->free_blocks = blocks;
sbinfo->max_inodes = inodes;
sbinfo->free_inodes = inodes;
- sb->s_maxbytes = (unsigned long long)(SHMEM_NR_DIRECT +
broken support of g_NCR5380 under 2.4.x ???
Hi, i have just test my old DTC3181E mustek scanner interfacecard under the new kernelversions. The giving tips from the mailinglists-archives (kernel, linux-scsi, etc) dosn't help ... i can't initialize the interface card. just a idea? thanks Frank Eichentopf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
On Sun, 1 Jul 2001, Justin Guyett wrote: > > Problem: I don't like company policy > Solution: Deal or get another job Not so easy in every country. For example in Italy the law called stauto dei lavoratori forbits workers to change so easily. > > > Peon: Help! I installed linux at work and got fired! > Oracle: You made a bad choice. > Not so easy for a company, at less in Italy. In fact the statuto dei lavoratori forbits a company to fire everyone for this kind of reasons. Also companies are forbitten to use any audio-visive way to monitor workers activities. The point is that your discussion does apply just to USA, at less for the terms you are using. Problems out of USA are different. I can install linux as i want, where i want, on sparc, on alpha, on ppc, to do all I want, but then M$ pre-sales have a good time to clean managers head, and to make managers belive M$ is the just one way to go. And managers and politician have power in companies, never technicians. If I would be regularly employed, (i do prefer my freedom), i could never be fired, of course, but anyway none would listen to me proposing linux, just because i am a technician. Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intel SRCU3-1 RAID (I2O) and 2.4.5-ac18
> > ALso set up the i2o cgi tools and see why > > the device wants to talk to you > > Tried to setup the Intel tools just as I did it before and I get > only an "Error: could not open I2O system" in the browser under the > RH-supplied kernel. I will keep trying to resolve this problem. modprobe i2o_config may be needed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
> "rob" == Rob Landley <[EMAIL PROTECTED]> writes: rob> On Saturday 23 June 2001 22:47, Eric W. Biederman wrote: >> Rob Landley <[EMAIL PROTECTED]> writes: >> > Ummm... GEM was the Geos stuff? (Yeah I remember it, I haven't >> > researched it yet though...) >> >> GEM was a gui from Digital Research I believe. >> Geoworks/Geos was a seperate entity. rob> Ah, the DR-DOS answer to dosshell/windows. Cool. (I used Dr. Dos byt never rob> tried its gui.) Nope. GEM is older that dosshell, if I remember correctly, dosshell appeared with dos 4.x, and GEM was there with DOS 3.x (was x = 22?). I also had DOS+ from Digital Research in my Amstrad PC1512. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha - generic_init_pit - why using RTC for calibration?
Ivan, thanks. I will minorly adjust the patch, prepare it for 2.2.x series
and then post it.
Thanks,
Oleg.
P.S. Richard, any thoughts?
- Original Message -
From: "Ivan Kokshaysky" <[EMAIL PROTECTED]>
To: "Oleg I. Vdovikin" <[EMAIL PROTECTED]>
Cc: "Richard Henderson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 9:19 PM
Subject: Re: alpha - generic_init_pit - why using RTC for calibration?
> On Fri, Jun 29, 2001 at 04:20:59PM +0400, Oleg I. Vdovikin wrote:
> > we've a bunch of UP2000/UP2000+ boards (similar to DP264) with
666MHz
> > EV67 Alphas (we're building large Alpha cluster). And we're regulary see
> > "HWRPB cycle frequency bogus" and the measured value for the speed in
the
> > range of 519 MHz - 666 MHz. And this value changes in this range from
boot
> > to boot. So why this happens???
>
> This is known problem with Cypress cy82c693 SIO. The RTC on this chip
> sometimes need a very long time (up to several minutes) to settle down
> after reset/power-up. But I thought it's fixed on newer systems with
> "ub" revision of the chip... :-(
>
> > So, the final question: why we're not using the aproach which is
used by
> > x86 time.c? I.e. why not to use CTC channel 2 for calibration?
>
> Good idea. The patch below works reliably on my sx164.
>
> Ivan.
>
> --- 2.4.6-pre5/arch/alpha/kernel/time.c Mon Nov 13 06:27:11 2000
> +++ linux/arch/alpha/kernel/time.c Fri Jun 29 20:58:09 2001
> @@ -169,6 +169,63 @@ common_init_rtc(void)
> init_rtc_irq();
> }
>
> +/*
> + * Calibrate CPU clock using legacy 8254 timer/counter. Stolen from
> + * arch/i386/time.c.
> + */
> +
> +#define CALIBRATE_LATCH (52 * LATCH)
> +#define CALIBRATE_TIME (52 * 120 / HZ)
> +
> +static unsigned long __init
> +calibrate_cc(void)
> +{
> + int cc;
> + unsigned long count = 0;
> +
> + /* Set the Gate high, disable speaker */
> + outb((inb(0x61) & ~0x02) | 0x01, 0x61);
> +
> + /*
> + * Now let's take care of CTC channel 2
> + *
> + * Set the Gate high, program CTC channel 2 for mode 0,
> + * (interrupt on terminal count mode), binary count,
> + * load 5 * LATCH count, (LSB and MSB) to begin countdown.
> + */
> + outb(0xb0, 0x43); /* binary, mode 0, LSB/MSB, Ch 2 */
> + outb(CALIBRATE_LATCH & 0xff, 0x42); /* LSB of count */
> + outb(CALIBRATE_LATCH >> 8, 0x42); /* MSB of count */
> +
> + cc = rpcc();
> + do {
> + count++;
> + } while ((inb(0x61) & 0x20) == 0);
> + cc = rpcc() - cc;
> +
> + /* Error: ECTCNEVERSET */
> + if (count <= 1)
> + goto bad_ctc;
> +
> + /* Error: ECPUTOOFAST */
> + if (count >> 32)
> + goto bad_ctc;
> +
> + /* Error: ECPUTOOSLOW */
> + if (cc <= CALIBRATE_TIME)
> + goto bad_ctc;
> +
> + return ((long)cc * 100) / CALIBRATE_TIME;
> +
> + /*
> + * The CTC wasn't reliable: we got a hit on the very first read,
> + * or the CPU was so fast/slow that the quotient wouldn't fit in
> + * 32 bits..
> + */
> +bad_ctc:
> + return 0;
> +}
> +
> void __init
> time_init(void)
> {
> @@ -176,6 +233,9 @@ time_init(void)
> unsigned long cycle_freq, one_percent;
> long diff;
>
> + /* Calibrate CPU clock -- attempt #1. If this fails, use RTC. */
> + if (!est_cycle_freq)
> + est_cycle_freq = calibrate_cc();
> /*
> * The Linux interpretation of the CMOS clock register contents:
> * When the Update-In-Progress (UIP) flag goes from 1 to 0, the
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sticky IO-APIC problem
'K, here's the deal. I have a Pentium III 933/133 (Coppermine, stepping 6) in an Intel-manufactured i810 motherboard (hey, I know it's a lame chipset, but it was on sale). On boot, the kernel (version 2.4.6-pre8) identifies and maps the IO-APIC onboard, but does not assign any IRQs to it. The relevant boot log snippet follows. [root@fortytwo i386]# cat /var/log/dmesg ... ... mapped APIC to e000 (0121c000) Kernel command line: auto BOOT_IMAGE=linux-test ro root=307 BOOT_FILE=/boot/vmlinuz-2.4.6-pre8 devfs=mount pirq=9,4 PIRQ redirection, working around broken MP-BIOS. ... PIRQ0 -> IRQ 9 ... PIRQ1 -> IRQ 4 ... ... And /proc/interrupts: [root@fortytwo i386]# cat /proc/interrupts CPU0 0: 79409 XT-PIC timer 1: 5911 XT-PIC keyboard 2: 0 XT-PIC cascade 4:990 XT-PIC es1371 8: 1 XT-PIC rtc 9: 26402 XT-PIC usb-uhci, serial 11: 16473 XT-PIC i810@PCI:0:1:0 14: 5152 XT-PIC ide0 15: 47 XT-PIC ide1 NMI: 0 ERR: 0 MIS: 0 [root@fortytwo i386]# This problem also occurs when booting without the pirq switch. I've configured everything the way it's mentioned in Documentation/i386/IO-APIC.txt, but it doesn't help. Anyway, thx in advance for the help. -- Colin The CompNerd Network: http://www.compnerd.com/ Where a nerd can be a nerd. Get your free [EMAIL PROTECTED]! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
Of course, being an OS/2 person myself before Slackware 1.2, I am still (to this day) disappointed that OS/2 was abandoned by their own creators, IBM. I'm waiting for IBM to abandon Linux in favor of their on Mainframe systems again. - Original Message - From: "Graham Murray" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 02, 2001 12:40 AM Subject: Re: Uncle Sam Wants YOU! > "Jim Roland" <[EMAIL PROTECTED]> writes: > > > What some people don't realize is that Microsoft *DID* do Unix a long time > > ago, they were even into OS/2 Development. :-) > > And they annoyed not just a few application vendors when just a few > months after giving the message "Go with OS/2, it is the way forward", > they abandoned it in favour of NT. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
- Original Message - From: "J Sloan" <[EMAIL PROTECTED]> To: "Jim Roland" <[EMAIL PROTECTED]> Sent: Sunday, July 01, 2001 11:34 PM Subject: Re: Uncle Sam Wants YOU! > Jim Roland wrote: > > > I don't see them taking RedHat or Slackware away from me! > > I see your point, but in a very real sense they > are taking red hat or slackware from you - > > They have been pushing the industry frantically > to make ms windows the standard and deprecate > everything else - many people have discovered > the frustration of "microsoft-only" web sites and > software which exists for windows only. > > For those who find that they can no longer > connect to their isp unless they are running > ms windows, it's a rude awakening. > > Sure, you can keep using slackware, but > you won't be able to connect to the internet > if they have their way - won't that be lovely? Sorry, I can't disagree more. Nobody is stopping me from purchasing RedHat or any other Linux Distro at Frys Electronics, online, or downloading a free (legal) copy of it. Nobody is stopping me from installing it on a PC, and nobody stops me from connecting to the internet with it. In fact, my windows machine connects to the same internet connection (cablemodem) as my linux systems, all behind a firewall appliance which actually touches the interface. Fact remains, TCP/IP and IPv6 are RFC STANDARDS not Microsoft standards. Even so, there are ways around the MS-CHAP issues preventing connections to the internet to allow Linux systems that speak STRAIGHT TCP/IP. See also, GTE. GTE about 3 years ago had their network fixed so that Microsoft systems could only connect, their modem pools literally hung up the line if you were using anything non-Microsoft. Currently, as long as you authenticate with them properly, they don't care what you use. How would you expain the Cisc's, Linksys's, etc? They aren't Microsoft, besides they pass IP over the wire, any IP-compatible machine will connect to it. Simply put, where I live (a top 10 metro area) there are plenty of ISPs that accept dial-ins from any system that authenticates PAP or CHAP/MS-CHAP. Like I've been saying before...stop blaming the "Dark Empire" and let's all come up with solutions to beat them at their own game. I'm done with this subject, it's aleady older that the science experiment leftovers in my refrigerator. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Stuart Lynne wrote: > I think listing driver versions on boot with perhaps some diagnostic info > if appropriate is useful. Names and copyrights should be in the source. Yup, if you go out and buy a book, the copyright business is in small print inside, not under the title on the dust-cover.. Now, I'll just have to pretend they don't put the authors name on the front in huge letters, and my analogy will be complete. Hmmm. Craig. -- Craig McLeanP: 01276 423905 Proactive Technical Analyst M: 07801 459497 Sun Microsystems Proactive Services E: [EMAIL PROTECTED] My opinions are not necessarily those of Sun Microsystems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intel SRCU3-1 RAID (I2O) and 2.4.5-ac18
> If you can repeat it in 2.4.5 let me know. Yes, I can reproduce it in 2.4.5 with exactly the same behaviour and messages. I made another experiment by installing RH7.1 directly on the raid partition (it was not possible to install with my mobo before because of a problem in the RH installer) and I couldn't reproduce the problem in 2.4.2 supplied by RedHat. > ALso set up the i2o cgi tools and see why > the device wants to talk to you Tried to setup the Intel tools just as I did it before and I get only an "Error: could not open I2O system" in the browser under the RH-supplied kernel. I will keep trying to resolve this problem. greetings Przemek Tomala - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
quotaoff OOPS (2.4.5-ac22)
After issuing quotaoff -a the kernel oopses. All filesystems which have quotas are ext2 and are using the new quota system. Oops: Jul 2 09:08:49 girly kernel: Unable to handle kernel NULL pointer dereference at virtual address 032a Jul 2 09:08:49 girly kernel: printing eip: Jul 2 09:08:49 girly kernel: c0146886 Jul 2 09:08:49 girly kernel: *pde = Jul 2 09:08:49 girly kernel: Oops: Jul 2 09:08:49 girly kernel: CPU:1 Jul 2 09:08:49 girly kernel: EIP:0010:[] Jul 2 09:08:49 girly kernel: EFLAGS: 00010282 Jul 2 09:08:49 girly kernel: eax: d0735f4c ebx: ccdda800 ecx: edx: d0735f4c Jul 2 09:08:49 girly kernel: esi: ccdda87c edi: 0306 ebp: d0735fa4 esp: d0735f30 Jul 2 09:08:49 girly kernel: ds: 0018 es: 0018 ss: 0018 Jul 2 09:08:49 girly kernel: Process quotaoff (pid: 1892, stackpage=d0735000) Jul 2 09:08:49 girly kernel: Stack: ccdda800 ccdda87c d0735fa4 d0735fa4 5fa4 d0735f4c Jul 2 09:08:49 girly kernel:d0735f4c c014a62c 0306 ccdda800 0200 d0735fa4 Jul 2 09:08:49 girly kernel:ccdda894 ccdda87c c014ab8c ccdda800 d0734000 Jul 2 09:08:49 girly kernel: Call Trace: [] [] [] [] Jul 2 09:08:49 girly kernel: Jul 2 09:08:49 girly kernel: Code: 83 7f 24 00 0f 84 0f 01 00 00 f0 fe 0d d4 01 25 c0 0f 88 09 KSymoops: >>EIP; c0146886<= Trace; c014a62c Trace; c014ab8c Trace; c0131953 Trace; c0106cbb Code; c0146886 <_EIP>: Code; c0146886<= 0: 83 7f 24 00 cmpl $0x0,0x24(%edi) <= Code; c014688a 4: 0f 84 0f 01 00 00 je 119 <_EIP+0x119> c014699f Code; c0146890 a: f0 fe 0d d4 01 25 c0 lock decb 0xc02501d4 Code; c0146897 11: 0f 88 09 00 00 00 js 20 <_EIP+0x20> c01468a6 Linux Version: Linux girly 2.4.5-ac22 #2 SMP Sun Jul 1 12:54:40 CEST 2001 i686 unknown Distribution: Debian SID Quota Version: ii quota 3.00pre01-8 An implementation of the diskquota system. Jul 2 09:18:40 girly kernel: VFS: Diskquotas version dquot_6.5.0 initialized -- Cliff Albert| RIPE: CA3348-RIPE | www.oisec.net [EMAIL PROTECTED] | 6BONE: CA2-6BONE | icq 18461740 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Keyboard errors with 2.4.5-ac
On Sun, Jul 01, 2001 at 11:39:42PM -0700, Greg KH wrote:
> On Sat, Jun 30, 2001 at 07:48:36PM +0200, Jakob Borg wrote:
> > You are using an SMP kernel. In my experience, nothing USB works with an SMP
> > kernel >2.4.3.
>
> Hm, that's a pretty vague statement :)
> I'm happily running USB on a few SMP machines around here. What are the
> problems that you are having?
Well, the problems I have (had; I'll get to that) are:
* Hard lockup whenever you try to access an USB audio device
* Sudden reboot sometimes when streaming video from an USB webcam.
The first problem appeared in 2.4.3 and only on SMP, but I know work around
that by using the alternate UHCI driver which seems to work well so far. The
second problem persists, but that is probably just a bug in the camera
driver. Nevertheless, all USB devices I tried on { SMP, kernel >2.4.3,
non-alternate UHCI driver } failed, so my statement was correct. :)
Since the alternate UHCI driver works I am satisified, but perhaps someone
interested in the normal driver should look into what happened between 2.4.3
and 2.4.4.
//jb
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
>_I_ think it's childish to claim the above. You _may_ have a choice, yes, but >is that choice equal or fair? Microsoft has infected both the user area as >much as the business/work area. If you want to purchase a PC because your >computer just fried and you want to finish a paper or something, but you >_want_ to use KOffice on Linux, and you don't care for Windows/Word >whatsoever, what are the chances that if you run down to the computer store >your "choices" will be Windows/Word, _period_! You'll then have to make sure >that none of the hardware in it is Software driven-like winmodems-and that >it's supported by Linux (or whatever OS you prefer). Almost all computers out >there (from well-known compianies) ship with winmodems. How is that a choice? >You have a choice to waste $70 on a harware modem, when someone who uses >Windows doesn't? > >-- >Marius Nita I'm not about to defend MicroSoft, but I will say this: When it comes to getting PC's, the best solution is to build your own. You pick the parts you want, you choose the software to install. This way you are sure to get a standard machine, and you get the original CD's and manuals that make up the software. Of course, the best bet in that area is to just download Linux from your favorite FTP site and not worry about spending money on Microsoft products. -- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Keyboard errors with 2.4.5-ac
On Sat, Jun 30, 2001 at 07:48:36PM +0200, Jakob Borg wrote: > On Fri, Jun 29, 2001 at 12:27:34PM -0500, Jordan Breeding wrote: > > lock a couple of times then the keyboard stops responding completely and > > the kernel tells me that there was an error waiting on a IRQ on CPU #1. > > You are using an SMP kernel. In my experience, nothing USB works with an SMP > kernel >2.4.3. Hm, that's a pretty vague statement :) I'm happily running USB on a few SMP machines around here. What are the problems that you are having? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Keyboard errors with 2.4.5-ac
On Sat, Jun 30, 2001 at 07:48:36PM +0200, Jakob Borg wrote: On Fri, Jun 29, 2001 at 12:27:34PM -0500, Jordan Breeding wrote: lock a couple of times then the keyboard stops responding completely and the kernel tells me that there was an error waiting on a IRQ on CPU #1. You are using an SMP kernel. In my experience, nothing USB works with an SMP kernel 2.4.3. Hm, that's a pretty vague statement :) I'm happily running USB on a few SMP machines around here. What are the problems that you are having? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
_I_ think it's childish to claim the above. You _may_ have a choice, yes, but is that choice equal or fair? Microsoft has infected both the user area as much as the business/work area. If you want to purchase a PC because your computer just fried and you want to finish a paper or something, but you _want_ to use KOffice on Linux, and you don't care for Windows/Word whatsoever, what are the chances that if you run down to the computer store your choices will be Windows/Word, _period_! You'll then have to make sure that none of the hardware in it is Software driven-like winmodems-and that it's supported by Linux (or whatever OS you prefer). Almost all computers out there (from well-known compianies) ship with winmodems. How is that a choice? You have a choice to waste $70 on a harware modem, when someone who uses Windows doesn't? -- Marius Nita I'm not about to defend MicroSoft, but I will say this: When it comes to getting PC's, the best solution is to build your own. You pick the parts you want, you choose the software to install. This way you are sure to get a standard machine, and you get the original CD's and manuals that make up the software. Of course, the best bet in that area is to just download Linux from your favorite FTP site and not worry about spending money on Microsoft products. -- Ted - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Keyboard errors with 2.4.5-ac
On Sun, Jul 01, 2001 at 11:39:42PM -0700, Greg KH wrote:
On Sat, Jun 30, 2001 at 07:48:36PM +0200, Jakob Borg wrote:
You are using an SMP kernel. In my experience, nothing USB works with an SMP
kernel 2.4.3.
Hm, that's a pretty vague statement :)
I'm happily running USB on a few SMP machines around here. What are the
problems that you are having?
Well, the problems I have (had; I'll get to that) are:
* Hard lockup whenever you try to access an USB audio device
* Sudden reboot sometimes when streaming video from an USB webcam.
The first problem appeared in 2.4.3 and only on SMP, but I know work around
that by using the alternate UHCI driver which seems to work well so far. The
second problem persists, but that is probably just a bug in the camera
driver. Nevertheless, all USB devices I tried on { SMP, kernel 2.4.3,
non-alternate UHCI driver } failed, so my statement was correct. :)
Since the alternate UHCI driver works I am satisified, but perhaps someone
interested in the normal driver should look into what happened between 2.4.3
and 2.4.4.
//jb
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
quotaoff OOPS (2.4.5-ac22)
After issuing quotaoff -a the kernel oopses. All filesystems which have quotas are ext2 and are using the new quota system. Oops: Jul 2 09:08:49 girly kernel: Unable to handle kernel NULL pointer dereference at virtual address 032a Jul 2 09:08:49 girly kernel: printing eip: Jul 2 09:08:49 girly kernel: c0146886 Jul 2 09:08:49 girly kernel: *pde = Jul 2 09:08:49 girly kernel: Oops: Jul 2 09:08:49 girly kernel: CPU:1 Jul 2 09:08:49 girly kernel: EIP:0010:[c0146886] Jul 2 09:08:49 girly kernel: EFLAGS: 00010282 Jul 2 09:08:49 girly kernel: eax: d0735f4c ebx: ccdda800 ecx: edx: d0735f4c Jul 2 09:08:49 girly kernel: esi: ccdda87c edi: 0306 ebp: d0735fa4 esp: d0735f30 Jul 2 09:08:49 girly kernel: ds: 0018 es: 0018 ss: 0018 Jul 2 09:08:49 girly kernel: Process quotaoff (pid: 1892, stackpage=d0735000) Jul 2 09:08:49 girly kernel: Stack: ccdda800 ccdda87c d0735fa4 d0735fa4 5fa4 d0735f4c Jul 2 09:08:49 girly kernel:d0735f4c c014a62c 0306 ccdda800 0200 d0735fa4 Jul 2 09:08:49 girly kernel:ccdda894 ccdda87c c014ab8c ccdda800 d0734000 Jul 2 09:08:49 girly kernel: Call Trace: [c014a62c] [c014ab8c] [c0131953] [c0106cbb] Jul 2 09:08:49 girly kernel: Jul 2 09:08:49 girly kernel: Code: 83 7f 24 00 0f 84 0f 01 00 00 f0 fe 0d d4 01 25 c0 0f 88 09 KSymoops: EIP; c0146886 remove_dquot_ref+22/14c = Trace; c014a62c quota_off+cc/154 Trace; c014ab8c sys_quotactl+268/3bc Trace; c0131953 sys_read+bf/c8 Trace; c0106cbb system_call+33/38 Code; c0146886 remove_dquot_ref+22/14c _EIP: Code; c0146886 remove_dquot_ref+22/14c = 0: 83 7f 24 00 cmpl $0x0,0x24(%edi) = Code; c014688a remove_dquot_ref+26/14c 4: 0f 84 0f 01 00 00 je 119 _EIP+0x119 c014699f remove_dquot_ref+13b/14c Code; c0146890 remove_dquot_ref+2c/14c a: f0 fe 0d d4 01 25 c0 lock decb 0xc02501d4 Code; c0146897 remove_dquot_ref+33/14c 11: 0f 88 09 00 00 00 js 20 _EIP+0x20 c01468a6 remove_dquot_ref+42/14c Linux Version: Linux girly 2.4.5-ac22 #2 SMP Sun Jul 1 12:54:40 CEST 2001 i686 unknown Distribution: Debian SID Quota Version: ii quota 3.00pre01-8 An implementation of the diskquota system. Jul 2 09:18:40 girly kernel: VFS: Diskquotas version dquot_6.5.0 initialized -- Cliff Albert| RIPE: CA3348-RIPE | www.oisec.net [EMAIL PROTECTED] | 6BONE: CA2-6BONE | icq 18461740 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intel SRCU3-1 RAID (I2O) and 2.4.5-ac18
If you can repeat it in 2.4.5 let me know. Yes, I can reproduce it in 2.4.5 with exactly the same behaviour and messages. I made another experiment by installing RH7.1 directly on the raid partition (it was not possible to install with my mobo before because of a problem in the RH installer) and I couldn't reproduce the problem in 2.4.2 supplied by RedHat. ALso set up the i2o cgi tools and see why the device wants to talk to you Tried to setup the Intel tools just as I did it before and I get only an Error: could not open I2O system in the browser under the RH-supplied kernel. I will keep trying to resolve this problem. greetings Przemek Tomala - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
