Re: nfsd vfs.c does not seems to fsync() with file overwrite, when ithave to.
On Tuesday April 3, [EMAIL PROTECTED] wrote:
> Dear Neil,
>
> I think I've found bug in nfsd. Here's patch for fixing.
> I'd like to explain what's problem and what's changed, after patch.
snip
>
> Because
>
> L710: err = file.f_op->write(, buf, cnt, _pos);
>
> does not store dirty pages to storage in case of async, we need to
> call fsync() in case if variable stable is non 0.
>
>
> Whether we should call nfsd_sync() or not, should not depend on
> whetherEX_WGATHER(exp) is true or not. So, calling nfsd_sync()
> should be outside
>
>if ( EX_WGATHER(exp) ) {...}
>
> statement.
>
You've missed an important fact.
A few lines earlier is the code:
if (stable && !EX_WGATHER(exp))
file.f_flags |= O_SYNC;
so if ! EX_WGATHER, the file has the O_SYNC flag set and all IO to
that file is synchronous (whether the fs was mounted synchronous or
not).
If EX_WGATHER, the flag isn't set, and explicitly call fsync after a
short delay.
>
> Also, it should not depend on whether (inode->i_state & I_DIRTY) is
> true or not, because (inode->i_state & I_DIRTY) is true only when
> inode is being changed ( i.e. when append write is being held ),
> while we need to sync written data to filesystem even when we only
> over wrote already existing data area.
Whenever you write to a file you change the inode - by changing the
modify time at least. Look at generic_file_write in mm/filemap.c.
Notice the code:
if (count) {
remove_suid(inode);
inode->i_ctime = inode->i_mtime = CURRENT_TIME;
mark_inode_dirty_sync(inode);
}
If a non-zero amount of data is being written, the inode is marked dirty.
If don't think the test actually serves the purpose as an fsync
doesn't cause the inode to be marked clean. I'm not sure when that happens.
>
> P.S. I don't really think we should wait for 10msec At point of
> Gathered writes. I don't think this will be of any help.
> It's because fsync() have locking of it's own.
The theory is that you might get 4 write requests inside 10msec.
Each of them enter data into the cache, but don't flush it to disc.
10ms after the first arrives, it causes a fsync on the file. This
writes out all the data for the 4 requests. The other requests
eventually finish their 10ms wait, and fsync finds that there is
nothing to write out and so complete quickly.
I didn't write this code and I don't know how well this code actually
works, but it doesn't seem *wrong* or harmful in any way.
NeilBrown
-
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: /proc/config idea
On Mon, Apr 02, 2001 at 05:39:19PM -0700, David Lang wrote: > > if the distro/sysadmin _always_ installs the kernel the 'right way' then > the difference isn't nessasarily that large, but if you want reliability > on any system it may be worth loosing a page or so of memory (hasn't > someone said that the data can be compressed to <1K?) After throwing away in a Makefile rule all "is not set" lines, as they are trivially recoverable with 'make oldconfig', what is left for an avarege kernel compresses to something like 500 bytes. Quite a bit of space left on this one page if you need more extensive .config. 'zcat /proc/config.gz' works just fine. As most kernels around are NOT installed "the right way" I found that in practice separating configuration information from a kernel image is not even close to be semi-reliable on a longer run. Those who say "installation script", and similar things, assume that people compile kernels for themselves. This is undoubtely true for folks on this list; this does not start to approximate the situation in general and, it seems, that we really want it that way. :-) BTW - /sbin/installkernel, as seen in practice, is not even correct for a general case with x86; not to mention other architectures. Writing something like /var/log/config from "init data" during a bootup could be another solution which does not take any kernel memory and still keeps all this information attached to a kernel image itself. OTOH we have all these tons of strings which show in /proc/pci output and somehow these do not cause such huge opposition. Yes, I know that 'lspci' was supposed to replace that; but it did not. Michal - 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/
BTTV problems in 2.4.3
I'm having some bttv problems in 2.4.3 (2.4.2 works fine). When my xawtv window (or my fbtv resolution) gets to a certain point (like 768x576, which is what I want, 640x480 is still fine) the right part of the tv window is left black. I'm back to using 2.4.2 again, but I could produce a screenshot if you want me to. We're not talking some small bar being left black, but rather a small bar on the left showing 20-25% of the tv picture. P.S. Please CC to me, I'm not on the list Robert - 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: More about 2.4.3 timer problems
Andrew Morton wrote: > Eric Gillespie wrote: > > > >... > > VESA fb mode 1280x1024x16, clock lost 1m 35s in time > > ... > > Same command, normal (non-fb mode) lost no time off clock. > > Is due to the 2.4.3 console drivers. They block interrupts during > console output. There's a fix in 2.4.2-ac. > > There's also a patch against 2.4.3-pre6 at > > http://www.uow.edu.au/~andrewm/linux/console.html > > If you'd care to test the 2.4.3-pre6 patch for a while, that'd > be useful. > Cool - I'll do that - err, just one question - is a kernel-m.n-preX a precursor to kernel-m.n+1? If that sentence didn't make sense, think back to algebra years. Thanks again. -- /| _,.:*^*:., |\ Cheers from the Viking family, | |_/' viking@ `\_| |including Pippin, our cat |flying-brick| $FunnyMail Bilbo : Now far ahead the Road has gone, \_.caverock.net.nz_/ 5.39in LOTR : Let others follow it who can! - 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/
Future reports
Please send reports directly to <[EMAIL PROTECTED]> I hope to figure out a news reader and have it parse real problems, but for now I am dropping off lkml for sometime as I am tired. Regards, Andre Hedrick Linux ATA Development - 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: [lkml]Re: [lkml]Re: Matrox G400 Dualhead
> > >If I use X on an accelerated, normal Matrox screen, my monitor complains > > >on exit: > > > > > >fH 49.4 KHz, fV 39.8 Hz > > > > > >(and it doesn't sync at 40 Hz vertical refresh :-( ). > > > > > >This is _half_ of the normal 80 Hz. Using fbset -a "1600x1200-80" > > >before X, of after X, doesn't do anything. Does anybody know what to > > >hack out in X to get it to _not_ reset my G400 to some unusable > > >state? 3.3.6 was didn't do this. I can use the framebuffer-screen > > >just fine, but I miss the DGA extension. > > > >Try adding this to your XF86Config file: > > > >Section "Device" > >... > >Option UseFBDev > >... > >EndSection > > >A very neat trick. X can now be ended correctly. Unfortunately, any >scrolling on any VT afterwards gives me a corrupted screen - parts of >the screen from other VT's are inserted below, or over the cursor >position, and at 'half-line' intervals. In typing this email, I've seen >it 5 times already. >I'm willing to test anything - but the corruption is alway gone after I >switch VT's. So getting a screendump is not easy. I never have seen this problem before. Petr do you know what it could be? MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Stuck: What to do with solid locks?
Hello, Three times since I upgraded to 2.4.3 and at least once in the 2.4.3-pre series, my machine would completely lock hard. I've got KDB running on a serial console (as I've been seeing lots of crashes, usually in the scsi_eh_0 process) and even this fails to pick up anything wrong. It's just a completely hard crash. I don't know what to do or how to go about collecting info for debugging purposes. I run Win2k and FreeBSD on it too and while Win2k does crash on it sometimes, it doesn't crash anywhere near as much as Linux. FreeBSD doesn't crash at all. Unfortunately for me, I prefer Linux for my machine, so ditching Linux for one of these is not a preferred option. Anyway, I'm stumped. The magic SysReq stuff doesn't respond either. Any ides on how to debug this? My HW is: dual P3 600, 640M RAM, IEEE1394 PCI card, G200 (and G400 sometimes) AGP card, Promise Ultra66 PCI card, Adaptec 2940UW PCI card, SB Live (EMU10k1) card, and a Linksys 10/100 PCI ethernet card. Additionally, I have two USB hubs plugged into my PC. One of these hubs has a USB mouse and a (USB) SanDisk SDDR-31 plugged into it. The other hub (sometimes) has a Rio 500 plugged into it. I have a generic ATAPI CDROM (the Kenwood True-X 72x was very flaky when using IDE-SCSI) connected to the Promise card (yes, I know it doesn't do UDMA4) and a Plextor 12/4/32 SCSI CD-RW connected to the Adaptec card. Finally, I have two hard drives with Linux partitions on both. Almost all of these partition are ReiserFS, with /, /var, and /boot being EXT2. Attached is my .config file. I'm using stock 2.4.3 with the most recent KDB patch and the newest AIC7xxx driver (6.1.8). I'm using RH7.0 with XFree 4.0.1. I've upgraded packages as per the Changes docs. I'm also using the most recent modutils (2.4.5). Every crash has happened in X, but then, I almost always work in X on this workstation, so the only place for them to happen would be in X. I'll see about leaving it on overnight without running X. This is very frustrating. I really, really want to be able to start doing something on my workstation without having to worry everytime about it crashing. Thanks, pete # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set CONFIG_APM_REAL_MODE_POWER_OFF=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=m CONFIG_ISAPNP=m # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set #
Re: Basic Text Mode (was: Re: Question about SysRq)
> One more property, that i'd like to have should be request key to force > the most basic text mode (say 80x25) on the console, when eg. X freezes > and i kill its session, then last gfx mode resides on the screen and > see no way to restore back the text mode - /usr/bin/reset or something > alike will not do it. But it seems to be not a good idea at all, does it > ? I'm working on this. In theory it should be possible with SAK. Alt-SysRq-k resets the console. Here it set the vc_mode back to KD_TEXT and the keyboard back to VC_XLATE. It even reset ths palette. What it doesn't do is reset the hardware state. I hope to change this for 2.5.X. It is possible using fbdev to do this very easily. I'm working on it so you can go back and forth between fbdev and vgacon for those who want to if their hardware supports it use vgacon. This can be applied to this problem very easily. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
>Is it possible that "jump scroll" would provide more performance benefit >than an accelerated driver anyway? I wouldn't rule it out. If someone wants to wipe up some code I would have no problem testing it to see if it is worth it. >Seeing as you bring up this topic of writing a 9525 driver. It seems to >me rather wasteful that you (collectively linux framebuffer authors), >XFree86 and Berlin are all writing drivers for the same, hugely diverse >class of hardware, to support more or less the same ops on the hardware. > >Isn't possible to pool the development effort of video drivers? Doesn't >X require basically the same set of operations as the kernel? I.e., >initialise the card and video mode (usually the very complex part); do >some rendering ops (usually fairly simple). Sure, X provides a few more >kinds of rendering op, but that part of the code is usually much simpler >and smaller than the initialisation code. Well the goal of each is very much different. Fbcon was developed to deal the fact that most modern video hardware doesn't support text but graphical based modes instead. VGA text is slowly going away. Since are goal is to emulate a text console we just have to provide basic support to provide just this. We need to 1) Draw basic text -> Glyph operations. 2) scrolling -> hardware panning or a copy area operation. 3) scroll a region of the screen -> copy area operation. 4) Clear the display or region of display -> fillrect 5) Set color palette. 6) Manage a hardware cursor. 7) Manage the current resolution for VC switching or a mode change vi VT_RESIZE or TIOCSWINSZ. So fbcon is out of necessite. Now X you mean XFree86 which is really a OS in itself. Its goal to do everything itself so it can run everywhere know to mankind. As for Berlin I don't know the code so I can't say. As people are finding out XFree86 doing everything itself is having issues. A good example is the classic problem of X dying and you have to reboot the machine. Also when under heavy load and you exit X to the console you don't get the text mode. Well right now its tough luck and just reboot your machine. A M$ solution but people have been doing it so long they don't mind it. I hope to fix those problems for 2.5.X. As you can see I think the OS should handle the transfer from console mode to text mode and vice versa. Now for programming the accel engine to do graphics in userland. Well their is nothing wrong that each does their own thing. What does matter is their is a GIU independent kernel manager of the graphics engine state. DRI attempts to handle this. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION] 2.4.x nice level
Quim K Holland wrote: > > > "BS" == BERECZ Szabolcs <[EMAIL PROTECTED]> writes: > > BS> ... a setiathome running at nice level 19, and a bladeenc at > BS> nice level 0. setiathome uses 14 percent, and bladeenc uses > BS> 84 percent of the processor. I think, setiathome should use > BS> max 2-3 percent. the 14 percent is way too much for me. > BS> ... > BS> with kernel 2.2.16 it worked for me. > BS> now I use 2.4.2-ac20 --- I was running 2 copies of setiathome on a 4 CPU server @ work. The two processes ran nice'd -19. The builds we were running still took 20-30% longer as opposed to when setiathome wasn't running (went from 45 minutes up to about an hour). This machine has 1G, so I don't think it was hurting from swapping. I finally wrote a script that checked every 30 seconds -- if the load on the machine climbed over '4', the script would SIGSTOP the seti jobs. Once the load on the machine fell below 2, it would send a SIGCONT to them. I was also running setiathome on my laptop for a short while -- but the fan kept coming on and the computer would get really hot. So I stopped that. Linux @ idle doesn't seem to ever kick on the fan, but turn on a CPU cruching program and it sure seemed to heat up the machine. I still wonder how many kilo or mega watts go to running dispersed computation programs. Just one of those things I may never know -l -- The above thoughts and | They may have nothing to do with writings are my own. | the opinions of my employer. :-) L A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 - 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: scsi bus numbering
>"Justin T. Gibbs" wrote: >> It is bogus that this stuff depends on link order to function >> correctly. > >No, it is simply one more rule, and one that is not immediately >obvious. Take heart though. Like Rolaids, 2.5's updated makefile >system will bring relief... Its not something the build system can "fix". Its a design issue that will have to be corrected by writing code. -- Justin - 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: Serial Console!!
Apparently "Green" <[EMAIL PROTECTED]> wrote: > Hi all, > I want to login to my MIPS box through serial port. > I execute 'make menuconfig' and select the 'serial console'. > But I can't see the login prompt in my window(I use netterm). > May I ask how serial console work? > Or I forget something? > P.S I skip /sbin/init program. In order for you to have full serial console port you must do more than simply enable the option in your kernel. Your BIOS/firmware should have serial console support of its own (most PCs don't, most other systems, even most PowerPC based Macs and workstations do, in the form of OpenFirmware --- formerly known as Sun's FCODE). Your MIPS box might have a firmware with serial console support, or it might not. That should allow you to access any pre-boot configuration options or diagnostics (including providing some mechanism to reset the NVRAM and to set the boot device or sequence) Your bootloader would have to support serial console to allow you to select which kernel you want to load and/or to pass kernel command line options and set initial environment variable/value pairs (a feature that seems unique to Linux). Of course, the Linux kernel support must be enabled, though that *only* applies to whether the kernel messages are copied to that device. If you would see it from dmesg, then it won't get copied to the console. To enable logins on a serial device you must spawn some form of getty process (normally done by init). That will listen for connections (normallly by taking login names) and exec() your login program (usually with the login name passed on its argument list). Since you specify that you're not running init, it's obvious why you can't "login." So, please tell me that you didn't actually think that logins and shells were handled directly by UNIX and Linux kernels! -- Jim Dennis Software Analyst Axis Personal Trainers http://www.axispt.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: /proc/config idea
a module for 2.4.3 will work for any 2.4.3 kernel that supports modules at all (except for the SMP vs UP issue) so it's not the same thing as trying to figure out which if the 2.4.3 kernels matches what you are running. David Lang On Mon, 2 Apr 2001, Jeff Garzik wrote: > Date: Mon, 02 Apr 2001 20:49:09 -0400 > From: Jeff Garzik <[EMAIL PROTECTED]> > To: Jeremy Jackson <[EMAIL PROTECTED]> > Cc: Ian Soboroff <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: /proc/config idea > > Jeremy Jackson wrote: > > If you have a lot of kernels around, which Config-2.4.3 applies to kernel 2.4.3 > > given 5 to choose from...the idea (same for System.map) is that it being in the > > same > > file they can't be confused. Kinda like forks under Mac (but let's not go there > > now) > > The same applies to kernel modules too. Are you going to put all those > in the kernel image too? > > If it's a file, read it from a filesystem after the kernel has booted. > There is no need to special case this stuff. > > -- > Jeff Garzik | May you have warm words on a cold evening, > Building 1024 | a full moon on a dark night, > MandrakeSoft | and a smooth road all the way to your door. > - > 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: PROBLEM:Bug when installing NVidia Driver Module
I have tried out the latest NVidia driver set, and they do work fine for me with plain vanilla 2.4.3 on my Athlon with GCC 2.95.3. I would blame your compiler, it's dated July 2000, that's an old CVS version AFAIK. - Aric - 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: More about 2.4.3 timer problems
Eric Gillespie wrote: > >... > VESA fb mode 1280x1024x16, clock lost 1m 35s in time > ... > Same command, normal (non-fb mode) lost no time off clock. Is due to the 2.4.3 console drivers. They block interrupts during console output. There's a fix in 2.4.2-ac. There's also a patch against 2.4.3-pre6 at http://www.uow.edu.au/~andrewm/linux/console.html If you'd care to test the 2.4.3-pre6 patch for a while, that'd be useful. - - 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/
size of ring buffer for kernel msgs
Kernel gurus, Since the boot process on some SMP machines can be rather verbose, it seems that the ring buffer for printk()s wraps before it can be snarfed by klogd/syslogd after boot. This makes it difficult to troubleshoot messages printed early in the boot process (like BIOS RAM maps). The default buffer size is 16k. (kernel/printk.c, line 26) Would it be reasonable to increase this to 32k (or more) on most machines? The buffer size is set at compile-time, and may present a problem in limited-memory (embedded?) systems if grown too large. Comments are most welcome. Tim -- Tim "Griffy" Strobell, [EMAIL PROTECTED], (301) 405-8175 Assistant Sysadmin and Server Janitor Department of Mathematics, University of Maryland at College Park - 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: what is pci=biosirq
The error message idicates that the MPS table doesn't provide interrupt routing information for that PCI slot. I ran into the same problem on my K6 machine. I was able to fix it in the BIOS. In the BIOS setup go to the `Advaned' page. Look under `Installed O/S'. It probably says something silly like `Win95' or `Win98/Win2000'. Change it to `Other' and your problem should go away. On Sat, Mar 31, 2001 at 06:37:41PM -0800, xcp wrote: > I have an ALi chipset motherboard that seems to function normally. K6-2 > 450, 256mb ram, 20gb ide fujitsu hard disk. Every time I boot up I get > this unsettling message about PCI: No IRQ known for interrupt pin A of > device 00:0f.0. Please try using pci=biosirq. > > It turns out that 00:0f.0 is my ALi ide controller: 00:0f.0 IDE > interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c1) > > Is this normal, or what should I do to "fix" it? Changing plug and play > OS in the bios has no effect. > > dmesg and lspci follow: > > Linux version 2.4.3 (root@coffee) (gcc version 2.95.3 20010315 (release)) > #2 Sat Mar 31 17:50:50 PST 2001 > BIOS-provided physical RAM map: > BIOS-e820: - 0009fc00 (usable) > BIOS-e820: 0009fc00 - 000a (reserved) > BIOS-e820: 000f - 0010 (reserved) > BIOS-e820: 0010 - 0fffc000 (usable) > BIOS-e820: 0fffc000 - 0000 (ACPI data) > BIOS-e820: 0000 - 1000 (ACPI NVS) > BIOS-e820: - 0001 (reserved) > On node 0 totalpages: 65532 > zone(0): 4096 pages. > zone(1): 61436 pages. > zone(2): 0 pages. > Kernel command line: > Initializing CPU#0 > Detected 451.019 MHz processor. > Console: colour VGA+ 80x25 > Calibrating delay loop... 901.12 BogoMIPS > Memory: 255860k/262128k available (826k kernel code, 5880k reserved, 271k > data, 176k init, 0k highmem) > Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) > Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) > Page-cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) > CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 > CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) > CPU: After vendor init, caps: 008021bf 808029bf 0002 > CPU: After generic, caps: 008021bf 808029bf 0002 > CPU: Common caps: 008021bf 808029bf 0002 > CPU: AMD-K6(tm) 3D processor stepping 0c > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) > mtrr: detected mtrr type: AMD K6 > PCI: PCI BIOS revision 2.10 entry at 0xf0720, last bus=1 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > PCI: Using IRQ router ALI [10b9/1533] at 00:07.0 > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > Starting kswapd v1.8 > pty: 512 Unix98 ptys configured > block: queued sectors max/low 170010kB/56670kB, 512 slots per queue > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > ALI15X3: IDE controller on PCI bus 00 dev 78 > PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using > pci=biosirq. > ALI15X3: chipset revision 193 > ALI15X3: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:pio, hdd:pio > hda: FUJITSU MPF3204AT, ATA DISK drive > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > hdc: RICOH CD-R/RW MP7040A, ATAPI CD/DVD-ROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: 40031712 sectors (20496 MB) w/512KiB Cache, CHS=2491/255/63, UDMA(33) > Partition check: > hda: hda1 hda2 < hda5 hda6 > hda3 hda4 > Serial driver version 5.05 (2000-12-13) with MANY_PORTS SHARE_IRQ > SERIAL_PCI enabled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > PPP generic driver version 2.4.1 > PPP Deflate Compression module registered > PPP BSD Compression module registered > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP > IP: routing cache hash table of 2048 buckets, 16Kbytes > TCP: Hash tables configured (established 16384 bind 16384) > ip_tables: (c)2000 Netfilter core team > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > cryptoapi: Registered sha1 (0) > cryptoapi: Registered rijndael-ecb (0) > cryptoapi: Registered rijndael-cbc (65536) > cryptoapi: Registered aes-ecb (0) > cryptoapi: Registered aes-cbc (65536) > cryptoapi: Registered blowfish-ecb (0) > cryptoapi: Registered blowfish-cbc (65536) > cryptoapi: Registered des-ecb (0) > cryptoapi: Registered des-cbc (65536) > cryptoapi: Registered des_ede3-ecb (0) > cryptoapi: Registered des_ede3-cbc (65536) > VFS: Mounted
a quest for a better scheduler
Hello, I sent a message a few days ago about some limitations I found in the linux scheduler. In servers like Apache where a large (> 1000) number of processes can be running at the same time and where many of them are runnable at the same time, the default Linux scheduler just starts trashing and the machine becomes very rapidly unusable. Performance degradations are quite noticeable on a two-way SMP machine (20-30% of the CPU gets lost) and are even more glaring on a multi-cpu machine. As an example, an 8-way Compaq Proliant just crawls with linux. >From the feedback I received I realized that there are at least two possible solutions to the problem: http://lse.sourceforge.net/scheduling/ http://resourcemanagement.unixsolutions.hp.com/WaRM/schedpolicy.html Indeed I've tried the patches available on the sites for the multi-queue scheduler and I was amazed by the performance improvement that I got. Both patches allow me to get to a 100% real CPU utilization on a two way machine running ~1500 processes. What those patches do is quite simple, instead of having the single global process queue present in the normal Linux scheduler, they add multiple queues (one per CPU). In this way the scheduling decision can be greatly simplified and almost made local to each CPU. No hotspots, no global locks (well, almost). Although some scalability problems are still there (there still is a global decision to make), the performance improvement obtained and the simplicity of the solution are remarkable. The HP patch is probably the most interesting, since it consists of really a few lines of code and it gets (for what I could measure) the same kind of performance improvement of the more elaborate (but still quite simple) sourceforge patch. Is there any special reason why any of those patches didn't make it to the mainstream kernel code? TIA, ciao, - Fabio - 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/
More about 2.4.3 timer problems
First off, CC: back to me, as my machine can't handle an estimated 200 messages a day for me to sign up to the list 8-( - Anyway.. I updated my kernel to 2.4.3 when the patch was released. As I said earlier, I noticed my timer losing a few seconds over the space of a couple of hours. Well, I have since found out that the amount of time lost is proportional to the load on the machine: the heavier the load, the more time lost. I found this out while I was compiling a kernel, incidentally: kernel-2.4.3 (and I am trying this without the TSC enabled, but it hasn't made any difference that I've noticed), other details as before. I really DON'T want to be running a cron job to re-read the CMOS clock every minute or so - that's a patch, not a fix. Output from "time make -j 3 bzImage" VESA fb mode 1280x1024x16, clock lost 1m 35s in time 996.52 user 166.82 system 23:19.40 elapsed 83% CPU (0 avgtext+0 avgdata 0 maxresident)k 0 inputs+0 outputs (471222 major+583276 minor) pagefaults 0swaps Same command, fbmode 640x480x24, clock lost 19s in time 751.42 user 89.47 system 18:40.79 elapsed 75% CPU (0 avgtext+0 avgdata 0 maxresident)k 0inputs+0outputs (468926 major+578877 minor) pagefaults 0 swaps Same command, normal (non-fb mode) lost no time off clock. 991.13 user 160.44 system 22:38.15 elapsed 84% CPU (0 avgtext+0 avgdata 0 maxresident)k 0 inputs+0 outputs (468051 major+577233 minor) pagefaults 0 swaps Hope this helps out, and by the way, thank you to Mark Hahn & Gerhard Mack for their suggestions. -- /| _,.:*^*:., |\ Cheers from the Viking family, | |_/' viking@ `\_| |including Pippin, our cat |flying-brick| $FunnyMail Bilbo : Now far ahead the Road has gone, \_.caverock.net.nz_/ 5.39in LOTR : Let others follow it who can! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question: is linux support Intel's i840 chipset?
Thanks a lot. A fool question: since IDE controller is a PCI device, and the PCI is 32bit/33MHz - 132MB/s or so. How does two ATA-100 device work, it will use 2 x 100MB/s bandwidth. I know most IDE controller is in the Sound Bridge, but I can buy an IDE expand card, which support ATA-100 too. - Original Message - From: "Ofer Fryman" <[EMAIL PROTECTED]> To: "'Jean-Michel Lee'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, March 29, 2001 6:20 PM Subject: RE: Question: is linux support Intel's i840 chipset? > I believe that Linux 2.2.x and 2.4.x do support it well, however I tried > using it with Linux 2.0.x and it caused me many problems with PCI drivers. I > also tried server-works chipset, which also works with 64-bit PCI bus, it > worked well under Linux 2.0.x no problems what so ever. > Any way since the 840 chipset is known to be buggy, I suggest you use > server-works. > > Ofer > > -Original Message- > From: Jean-Michel Lee [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 29, 2001 11:47 AM > To: [EMAIL PROTECTED] > Subject: Question: is linux support Intel's i840 chipset? > > > Hi, > > I just want to search a mainboard with 64-bit PCI bus and ATA-100 support. I > just find that Intel i840 do. So, I wonder whether linux support Intel's > i840. > > Thanks. > > Michel > > - > 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: vmalloc on 2.4.x on ia64
That is what I said. I am using vmalloc only. But the call to vmalloc is hanging. -hiren > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 02, 2001 6:26 PM > To: [EMAIL PROTECTED] > Subject: RE: vmalloc on 2.4.x on ia64 > > > kmalloc() has a limit of 128KB. Use get_free_pages() or > vmalloc() instead, > or break up your allocation into smaller hunks. > > Thanks, > Matt > > -- > Matt Domsch > Sr. Software Engineer > Dell Linux Systems Group > Linux OS Development > www.dell.com/linux > > > > > -Original Message- > > From: MEHTA,HIREN (A-SanJose,ex1) [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 02, 2001 7:07 PM > > To: '[EMAIL PROTECTED]' > > Subject: vmalloc on 2.4.x on ia64 > > > > > > Greetings. > > > > Is vmalloc() interface broken on any of 2.4.x kernel on ia64 ? > > I am trying to call vmalloc from the driver to allocate > > about 130kb of memory and it hangs the system. > > I am running 2.4.1 kernel with ia64 patch (I can find out the > > exact patch if needed) on LION. Let me know if more information > > is required. > > > > Thanks and regards, > > -hiren > > - > > 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: /proc/config idea
Jeremy Jackson wrote: > If you have a lot of kernels around, which Config-2.4.3 applies to kernel 2.4.3 > given 5 to choose from...the idea (same for System.map) is that it being in the > same > file they can't be confused. Kinda like forks under Mac (but let's not go there > now) The same applies to kernel modules too. Are you going to put all those in the kernel image too? If it's a file, read it from a filesystem after the kernel has booted. There is no need to special case this stuff. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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: /proc/config idea
yes it's unreclaimable memory and that's why we want to minimize how much is used. on the other hand there is a factor of reliability in the kernel knowing what options were used to compile it that you just cannot match with a seperate file, or even with it a part of the on-disk image that is thrown out when it gets loaded into memory. if the distro/sysadmin _always_ installs the kernel the 'right way' then the difference isn't nessasarily that large, but if you want reliability on any system it may be worth loosing a page or so of memory (hasn't someone said that the data can be compressed to <1K?) make it so that you need a common external tool to use the data and deliver it from the kernel in compressed form and you don't even need to put the decompression routine in the kernel (cat /proc/sys/kernel/config |gunzip >config) David Lang On Mon, 2 Apr 2001, Jeff Garzik wrote: > Date: Mon, 02 Apr 2001 20:23:28 -0400 > From: Jeff Garzik <[EMAIL PROTECTED]> > To: Jeremy Jackson <[EMAIL PROTECTED]> > Cc: Ian Soboroff <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: /proc/config idea > > Jeremy Jackson wrote: > > Yes, I like this. I do this manually, it allows reproducability, and > > incremental > > modifications, tracing how that kernel on that problem system was made... > > > > I think the ultimate would be to put all of .config (gzipped?) in a new ELF > > section without the Loadable attribute... I wish System.map was the same. > > The you're guaranteed you know how a kernel on disk was configured. > > > > To correlate a running kernel to one on disk (vmlinuz) you have LILO... > > it appends an environment variable to the kernel command line with > > the name of the file it booted. This is not infallable, since LILO maps > > disk sectors, only using the filesystem at map install time. > > > > Permaps an md5sum of the .text ELF section would conclusively > > link the in-core kernel with an on-disk vmlinuz? Shouldn't be hard > > to do with objcopy and /proc/kmem? > [...] > > Comments anyone? > > Instead of doing all this stuff in the kernel, you could simply update > symlinks to properly installed files at boot time. > > Putting _files_ in the kernel is plain silly. This is unreclaimable > memory, folks. There is no need to special case an operation as simple > as reading a file. [I think this about firmware images too, but that's > another thread] > > -- > Jeff Garzik | May you have warm words on a cold evening, > Building 1024 | a full moon on a dark night, > MandrakeSoft | and a smooth road all the way to your door. > - > 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: /proc/config idea
Jeff Garzik wrote: > Jeremy Jackson wrote: > > Yes, I like this. I do this manually, it allows reproducability, and > > incremental > > modifications, tracing how that kernel on that problem system was made... > > > > I think the ultimate would be to put all of .config (gzipped?) in a new ELF > > section without the Loadable attribute... I wish System.map was the same. > > The you're guaranteed you know how a kernel on disk was configured. > > > > To correlate a running kernel to one on disk (vmlinuz) you have LILO... > > it appends an environment variable to the kernel command line with > > the name of the file it booted. This is not infallable, since LILO maps > > disk sectors, only using the filesystem at map install time. > > > > Permaps an md5sum of the .text ELF section would conclusively > > link the in-core kernel with an on-disk vmlinuz? Shouldn't be hard > > to do with objcopy and /proc/kmem? > [...] > > Comments anyone? > > Instead of doing all this stuff in the kernel, you could simply update > symlinks to properly installed files at boot time. > > Putting _files_ in the kernel is plain silly. This is unreclaimable not in the kernel in an ELF section, marked not loadable. it never leaves the disk. as someone else posted, it's ~900 bytes gzipped (if you want to have it in core) unfortunately (in the LILO case) x86 doesn't boot an ELF image... (oops) > > memory, folks. There is no need to special case an operation as simple If you have a lot of kernels around, which Config-2.4.3 applies to kernel 2.4.3 given 5 to choose from...the idea (same for System.map) is that it being in the same file they can't be confused. Kinda like forks under Mac (but let's not go there now) > > as reading a file. [I think this about firmware images too, but that's > another thread] - 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: can not compile 2.4.3 on alpha
Gustavo Niemeyer wrote: > Hello Andrejs!! > > /usr/src/linux-2.4.3/include/asm/pgalloc.h:334: conflicting types for > > `pte_alloc' > This is happening on ia64 as well. The interface seems to have changed > but some architectures were forgotten. The interface changed and other architectures have not caught up yet :) Other archs pretty much always play catch-up to the x86 port. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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: /proc/config idea
Jeremy Jackson wrote: > Yes, I like this. I do this manually, it allows reproducability, and > incremental > modifications, tracing how that kernel on that problem system was made... > > I think the ultimate would be to put all of .config (gzipped?) in a new ELF > section without the Loadable attribute... I wish System.map was the same. > The you're guaranteed you know how a kernel on disk was configured. > > To correlate a running kernel to one on disk (vmlinuz) you have LILO... > it appends an environment variable to the kernel command line with > the name of the file it booted. This is not infallable, since LILO maps > disk sectors, only using the filesystem at map install time. > > Permaps an md5sum of the .text ELF section would conclusively > link the in-core kernel with an on-disk vmlinuz? Shouldn't be hard > to do with objcopy and /proc/kmem? [...] > Comments anyone? Instead of doing all this stuff in the kernel, you could simply update symlinks to properly installed files at boot time. Putting _files_ in the kernel is plain silly. This is unreclaimable memory, folks. There is no need to special case an operation as simple as reading a file. [I think this about firmware images too, but that's another thread] -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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: oops in uhci.c running 2.4.2-ac28
Johannes Erdfelt wrote: > > On Mon, Apr 02, 2001, Jeff Golds <[EMAIL PROTECTED]> wrote: > > Let me show what I got with the 2.4.2 kernel with USB support enabled. > > > > Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad > > Mar 19 14:10:31 Eng99 last message repeated 108 times > > Mar 19 14:11:37 Eng99 last message repeated 93 times > > Mar 19 14:12:39 Eng99 last message repeated 87 times > > Mar 19 14:13:40 Eng99 last message repeated 20 times > > Mar 19 14:14:45 Eng99 last message repeated 42 times > > Mar 19 14:15:46 Eng99 last message repeated 47 times > > Mar 19 14:16:47 Eng99 last message repeated 127 times > > Mar 19 14:17:50 Eng99 last message repeated 7074 times > > Mar 19 14:18:51 Eng99 last message repeated 3342 times > > Mar 19 14:19:52 Eng99 last message repeated 10948 times > > Mar 19 14:20:00 Eng99 last message repeated 15 > > times > > > > This happens after simply fiddling around with ethernet settings (it's a > > PCI ethernet card). In fact, my syslog is FULL of these messages... my > > syslog was 3x larger than usual. The console is just about unusable > > because of all the spam. > > > > Something seems terribly wrong with the uhci driver... I've disabled it > > on my system and it's fine now (I don't need USB). > > Do you get the same messages with the usb-uhci driver? > Don't think I tried that one. > > My system: > > Slot 1 P3-850 > > VIA chipset MB (not sure of exact chipset, can find out if needed) > > Some of the VIA chipsets have port aliasing problems supposedely. This > may cause your controller to go insane like you've described. > > JE > That could explain the issue. Fortunately, I don't need USB so I can avoid the spam, I just thought someone might like to hear about it. -Jeff P.S. Sorry for responding directly to you, Johannes. -- Jeff Golds [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/
Sandisk flashcard reader on 2.4.2. It works. Sort of.
PLease Cc: all responses to [EMAIL PROTECTED] Hiya, since I'm not on the list, and my experience with and knowledge of kernel internals are negligable, please keep in mind to Carbon copy all forcoming relevant conversation to me. Thank you. Ok, I bought a Nikon Coolpix 990, aand to download the ppix to my Linux PC at home a SanDisk ImageMate SDDR-01. That's parallel IDE. At the time, I ran 2.2.17, which of course didn't touch the thing with a 10 parsecs pole. Som searching on the web led me to two conclusions: 1. This thing is either new or scorned. 2, There is a patch at http://www.electricgod.net/~moomonk/epat/ which may or may not help. All the time during this story a 16 Mb SanDisk CompactFlash card is in the reader, unles otherwise specified. So I applied the patch to the 2.2.17 kernel, remade, and rebooted. No dice. Several kernel reconfigurations and rebots later still nothing, it seemed. So I downloaded and installed 2.4.2, which was mentioned to problably include the necessary features. I copied .config from the 2.2.17, superficially checked the config, and remade and rebooted. This was where I noted, that the parport, paride, epat and pd modules didn't get installed as modules at all. I havnet dug into the why of that, let those familiar with the processes and Makefiles do that. So I reconfigured to get those into the kernel, and remade and rebooted. No dice, so I succesfully again applied the same patch, configured it into the kernel and remade and rebooted. No SanDisk. For some reason or another I rebooted again, and lo and behold, we have a SanDisk. I mount it ok, cd /sandisk/dir/, mv * elsewhere, my system hangs. Reset. cp * hangs the system as well, so I do a for i in *; do; cp $i /there; sync; done; The system hangs whenever I try to copy a certain picture. (No, it doesn't contain nudiepixels.) Luckily, I didn't care much about that one. Since the start of this story and "now" I've aqcuired an 128 Mb card, and shot some pictures using it. So I unmount my 16 Mb one, swicth cards, and mount the device again. Or so I hoped. System hangs on the mount operation. And no CTRL-ALT-DEL to go down more or less gracefully. It really hangs, like whenever the patched system barfs on the SanDisk. And today, several days later, the system even refuses to see the little bugger, even the lasst time, without any card it it's waiting little mouth. So the message is: Yes, it could work, but with the patch from http://www.electricgod.net/~moomonk/epat/ it's slightly better working than without it. What am I to do? With kind regards, Stefan. Please Cc: reactions to me. -- Stefan Linnemannhttp://www.xs4all.nl/~mazur/ Systems programmer Unix ICQ: 25314387 - 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/
vmalloc on 2.4.x on ia64
Greetings. Is vmalloc() interface broken on any of 2.4.x kernel on ia64 ? I am trying to call vmalloc from the driver to allocate about 130kb of memory and it hangs the system. I am running 2.4.1 kernel with ia64 patch (I can find out the exact patch if needed) on LION. Let me know if more information is required. Thanks and regards, -hiren - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about SysRq
On Sat, 31 Mar 2001, Boris Pisarcik wrote: > on say tty2. The processes get created pretty fast. After a short while > I supposed a single solution to this to kill all session by alt+sysrq+k, > but nothing happened. Under normal averagely loaded situation, this will > imidiately kill all processes on current vt and bring getty prompt. > Shouldn't it function similiarily in former case ? I see all processes on vt > get SIGKILL, so what's hapenned ? Maybe I had to wait > a bit longer for kernel to accomplish that ? Killing all processes with init > (alt+sysrq+i) seems to be immediate. > > > Thought, i really love all sysrq properties of linux, so i need less often > to make hardware resets an then await and fear, what fsck will print. > One more property, that i'd like to have should be request key to force the > most basic text mode (say 80x25) on the console, when eg. X freezes and > i kill its session, then last gfx mode resides on the screen and see no way > to restore back the text mode - /usr/bin/reset or something alike will not > do it. But it seems to be not a good idea at all, does it ? I've noticed a similar situation: I recently upgraded to XFree86 4.0.3 and have been having nothing but problems with it. Often times, the machine will crash, with crap shot to the screen. Howver, the IP stack still functions, routes packets, but none of the user processes respond. I'll try and hit sysrq-s to sync the disks, sysrq-u to unmount them, and sysrq-b to boot the machine. Unfortunately, the only one that responds is sysrq-b, which boots the box without syncing or unmounting the disks. Not only does that piss me off but it's led to some fs corruption as well (which pisses me off even more). sysrq-b is the *only* combination I can get working when this happens. However, when the machine is *not* locked, sysrq-[su] work fine. Kernel is 2.4.3-pre6 on SMP i686. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - 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] multiline string cleanup
On Mon, Apr 02, 2001 at 07:50:04PM -0400, Jeff Garzik wrote: > Andi Kleen wrote: > > "J . A . Magallon" <[EMAIL PROTECTED]> writes: > > > This is one other try to make kernel sources gcc-3.0 friendly. This cleans > > > some muti-line asm strings in checksum.h and floppy.h (this were the only > > > ones reported in my kernel build, perhaps there are more in drivers I do > > > not use). > > > I surely hope the gcc guys will just remove that silly warning again, because > > it makes it impossible to write readable inline assembly now. > > If it's a silly warning, then we should turn it off in linux/Makefile. > I dunno that the kernel can dictate to gcc here what to do... It unfortunately cannot be turned off ATM (it is "deprecation warning" where someone is trying to warn you that the next release of gcc may not support multi line strings anymore). > Also some multiline string cleanups have already made it into the kernel > -- though that is not conclusive, as it may just be maintainer > preference. Longer inline assembly without multi strings is hard to read and very nasty to edit, so I don't see that as a "cleanup", but as a pessimization towards less maintainable code. -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/
Re: scsi bus numbering
"Justin T. Gibbs" wrote: > It is bogus that this stuff depends on link order to function > correctly. No, it is simply one more rule, and one that is not immediately obvious. Take heart though. Like Rolaids, 2.5's updated makefile system will bring relief... Make sure to add a comment, when you update the 2.4 makefile where link order is significant. (as it is not, in all cases) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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: oops in uhci.c running 2.4.2-ac28
On Mon, Apr 02, 2001, Jeff Golds <[EMAIL PROTECTED]> wrote: > Let me show what I got with the 2.4.2 kernel with USB support enabled. > > Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad > Mar 19 14:10:31 Eng99 last message repeated 108 times > Mar 19 14:11:37 Eng99 last message repeated 93 times > Mar 19 14:12:39 Eng99 last message repeated 87 times > Mar 19 14:13:40 Eng99 last message repeated 20 times > Mar 19 14:14:45 Eng99 last message repeated 42 times > Mar 19 14:15:46 Eng99 last message repeated 47 times > Mar 19 14:16:47 Eng99 last message repeated 127 times > Mar 19 14:17:50 Eng99 last message repeated 7074 times > Mar 19 14:18:51 Eng99 last message repeated 3342 times > Mar 19 14:19:52 Eng99 last message repeated 10948 times > Mar 19 14:20:00 Eng99 last message repeated 15 > times > > This happens after simply fiddling around with ethernet settings (it's a > PCI ethernet card). In fact, my syslog is FULL of these messages... my > syslog was 3x larger than usual. The console is just about unusable > because of all the spam. > > Something seems terribly wrong with the uhci driver... I've disabled it > on my system and it's fine now (I don't need USB). Do you get the same messages with the usb-uhci driver? > My system: > Slot 1 P3-850 > VIA chipset MB (not sure of exact chipset, can find out if needed) Some of the VIA chipsets have port aliasing problems supposedely. This may cause your controller to go insane like you've described. JE - 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] multiline string cleanup
Andi Kleen wrote: > "J . A . Magallon" <[EMAIL PROTECTED]> writes: > > This is one other try to make kernel sources gcc-3.0 friendly. This cleans > > some muti-line asm strings in checksum.h and floppy.h (this were the only > > ones reported in my kernel build, perhaps there are more in drivers I do > > not use). > I surely hope the gcc guys will just remove that silly warning again, because > it makes it impossible to write readable inline assembly now. If it's a silly warning, then we should turn it off in linux/Makefile. I dunno that the kernel can dictate to gcc here what to do... Also some multiline string cleanups have already made it into the kernel -- though that is not conclusive, as it may just be maintainer preference. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Jeff Garzik wrote: > Oliver Xymoron wrote: > > On Mon, 2 Apr 2001, Tom Leete wrote: > > > How about /lib/modules/$(uname -r)/build/.config ? It's already there. > > > It'd be great if we got away from the config being hidden too. > > When exporting it outside the kernel tree, the '.' prefix should > definitely be stripped... I think the same should be true for the new build system as well. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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: oops in uhci.c running 2.4.2-ac28
Pete Zaitcev wrote: > > > Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST) > > From: Ketil Froyn <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > > While running kernel 2.4.2-ac28, I switched on spinlock debugging and > > verbose BUG() reporting (I always use sysrq). Anyway, while running this I > > got an oops after about 2 or 3 minutes running, several times, exact same > > place each time, which I traced back to rh_int_timer_do(). > > This was in uhci.c (I used CONFIG_USB_UHCI_ALT). [...] I > > recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get > > the oops any more. > > I am behind usb-uhci for a reason. Alan bounced your report > to me but I do not see a case for action... > > -- Pete > - Let me show what I got with the 2.4.2 kernel with USB support enabled. Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad Mar 19 14:10:31 Eng99 last message repeated 108 times Mar 19 14:11:37 Eng99 last message repeated 93 times Mar 19 14:12:39 Eng99 last message repeated 87 times Mar 19 14:13:40 Eng99 last message repeated 20 times Mar 19 14:14:45 Eng99 last message repeated 42 times Mar 19 14:15:46 Eng99 last message repeated 47 times Mar 19 14:16:47 Eng99 last message repeated 127 times Mar 19 14:17:50 Eng99 last message repeated 7074 times Mar 19 14:18:51 Eng99 last message repeated 3342 times Mar 19 14:19:52 Eng99 last message repeated 10948 times Mar 19 14:20:00 Eng99 last message repeated 15 times This happens after simply fiddling around with ethernet settings (it's a PCI ethernet card). In fact, my syslog is FULL of these messages... my syslog was 3x larger than usual. The console is just about unusable because of all the spam. Something seems terribly wrong with the uhci driver... I've disabled it on my system and it's fine now (I don't need USB). My system: Slot 1 P3-850 VIA chipset MB (not sure of exact chipset, can find out if needed) -Jeff -- Jeff Golds [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: Kernel 2.4.3 fails to compile
> > buz.c: In function `v4l_fbuffer_alloc':
> > buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function)
> > buz.c:188: (Each undeclared identifier is reported only once
> > buz.c:188: for each function it appears in.)
>
> Easy solution -- just delete the entire test
>
> if (size > KMALLOC_MAXSIZE) {
> ...
> }
Or use the -ac driver, or better yet use the new zoran driver in -ac, since
buz.c doesnt actually work in any 2.4 tree in either vanilla or -ac.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 aic7xxx wont compile
> The sad part is that there has been a fix for this "problem", supplied > by the author of the driver, for well over a month that everyone seems > to ignore. I've not had a patch from the author to apply so I've not applied anything. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dell PERC/Adaptec RAID support?
> kernels. As I want to run Linux-2.4.x, I can't find a kernel supporting > the PERC, and this annoys me... Does anyone know when this will be > merged into the main source tree? When someone writes a driver that is less disgusting than the current one - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: > On Mon, 2 Apr 2001, Tom Leete wrote: > > How about /lib/modules/$(uname -r)/build/.config ? It's already there. > It'd be great if we got away from the config being hidden too. When exporting it outside the kernel tree, the '.' prefix should definitely be stripped... My preference is /boot/config-2.4.3 (with /boot/config as a symlink to it) Assuming your initscripts is smart about updating /boot symlinks, any running kernel config [properly installed] can be grabbed with a simple 'cp /boot/config .' -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Tom Leete wrote: > Oliver Xymoron wrote: > > > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > > > On Sun, 1 Apr 2001, David Lang wrote: > > > > if we want to get the .config as part of the report then we need to make > > > > it part of the kernel in some standard way (the old /proc/config flamewar) > > > > it's difficult enough sometimes for the sysadmin of a box to know what > > > > kernel is running on it, let alone a bug reporting script. > > > > > > Let's hope it's not a flamewar, but here goes :) > > > > > > We -need- .config, but /proc/config seems like pure bloat. > > > > As a former proponent of /proc/config (I wrote one of the much-debated > > patches), I tend to agree. Debian's make-kpkg does the right thing, namely > > treating .config the same way it treats System-map, putting it in the > > package and eventually installing it in /boot/config-x.y.z. If Redhat's > > kernel-install script did the same it would rapidly become a non-issue. > > How about /lib/modules/$(uname -r)/build/.config ? It's already there. It'd be great if we got away from the config being hidden too. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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: EXT2-fs error
> > I got the following while rm -rf'ing my mozilla cvs checkout. Deadly or not >deadly? > > Highly deadly. > > Your disk is dropping bits, or, more likely, your RAM. This is very, > very bad. if it was 2.2 I'd believe it. 2.4 is still showing these kind of problems in software on many VIA chipset athlon boards and under extreme loads on other boxes too. - 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: Disturbing news..
On Wed, 28 Mar 2001, Jesse Pollard wrote: > Sure - very simple. If the execute bit is set on a file, don't allow > ANY write to the file. This does modify the permission bits slightly > but I don't think it is an unreasonable thing to have. Oh, honestly! Think about what you are saying here: What if you are developing something in an interpereted language such as perl or a shell script, where you *directly modify the executable file*? No, this won't work...Not wwithout being annoying as hell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > On Sun, 1 Apr 2001, David Lang wrote: > > > if we want to get the .config as part of the report then we need to make > > > it part of the kernel in some standard way (the old /proc/config flamewar) > > > it's difficult enough sometimes for the sysadmin of a box to know what > > > kernel is running on it, let alone a bug reporting script. > > > > Let's hope it's not a flamewar, but here goes :) > > > > We -need- .config, but /proc/config seems like pure bloat. > > As a former proponent of /proc/config (I wrote one of the much-debated > patches), I tend to agree. Debian's make-kpkg does the right thing, namely > treating .config the same way it treats System-map, putting it in the > package and eventually installing it in /boot/config-x.y.z. If Redhat's > kernel-install script did the same it would rapidly become a non-issue. How about /lib/modules/$(uname -r)/build/.config ? It's already there. Tom -- The Daemons lurk and are dumb. -- Emerson - 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: oops in uhci.c running 2.4.2-ac28
On Mon, Apr 02, 2001, Pete Zaitcev <[EMAIL PROTECTED]> wrote: > > Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST) > > From: Ketil Froyn <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > > While running kernel 2.4.2-ac28, I switched on spinlock debugging and > > verbose BUG() reporting (I always use sysrq). Anyway, while running this I > > got an oops after about 2 or 3 minutes running, several times, exact same > > place each time, which I traced back to rh_int_timer_do(). > > This was in uhci.c (I used CONFIG_USB_UHCI_ALT). [...] I > > recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get > > the oops any more. > > I am behind usb-uhci for a reason. Alan bounced your report > to me but I do not see a case for action... What do you mean by "behind". Have you tried the latest patches for uhci.c? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION] 2.4.x nice level
> "BS" == BERECZ Szabolcs <[EMAIL PROTECTED]> writes: BS> ... a setiathome running at nice level 19, and a bladeenc at BS> nice level 0. setiathome uses 14 percent, and bladeenc uses BS> 84 percent of the processor. I think, setiathome should use BS> max 2-3 percent. the 14 percent is way too much for me. BS> ... BS> with kernel 2.2.16 it worked for me. BS> now I use 2.4.2-ac20 Would it the case that bladeenc running on 2.4.2 spends more time doing I/O? I am not saying that the userland makes more I/O requests, but if the same set of I/O requests are taking longer to complete on 2.4.2, then while bladeenc is waiting for their completion, it is not so surprising that the other process uses the otherwise-idle CPU cycles. --== Sent via Deja.com ==-- http://www.deja.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: oops in uhci.c running 2.4.2-ac28
> Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST) > From: Ketil Froyn <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > While running kernel 2.4.2-ac28, I switched on spinlock debugging and > verbose BUG() reporting (I always use sysrq). Anyway, while running this I > got an oops after about 2 or 3 minutes running, several times, exact same > place each time, which I traced back to rh_int_timer_do(). > This was in uhci.c (I used CONFIG_USB_UHCI_ALT). [...] I > recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get > the oops any more. I am behind usb-uhci for a reason. Alan bounced your report to me but I do not see a case for action... -- Pete - 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 scheduler limitations?
> I've found a (to me) unexplicable system behaviour when the number of > Apache forked instances goes somewhere beyond 1050, the machine > suddently slows down almost top a halt and becomes totally unresponsive, > until I stop the test (SpecWeb). Im suprised it gets that far > Moreover the max number of processes is not even constant. If I increase > the server load gradually then I manage to have 1500 processes running > with no problem, but if the transition is sharp (the SpecWeb case) than > I end-up having a lock up. With that many servers and a sudden load you are probably causing a lot of paging. What kernel version. And while this isnt a solution to kernel issues take a look at thttpd instead (www.acme.com). If you have 1500 8K stacks thrashing in your cache you are not going to have good performance. - 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-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
> Yes this is problem. See my response to Paul about this. The only reason > I'm using MMX for the vesa framebuffer because it has no acceleration. MMX > gives a big boost for genuine intel chips. Other types of MMX are fast but > they don't seemed to be optimized for memory transfers like MMX on intel > chips. I also have regular code that does all kinds of tricks to optimize Then you are doing something badly wrong. The MMX memcpy for CyrixIII and Athlon boxes is something like twice the speed of rep movs. On most pentium II/III boxes the fast paths for rep movs and for MMX are the same speed Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
the reason for suggesting /proc is that this data needs to be available in
a standard place, putting it in the kernel image (compressed is fine,
bitmap is fine) eliminates the problems of trying to dictate where in the
filesystem the distros need to put things.
putting it in /proc _somewhere_ (/proc/sys/kernel/config any better???)
avoids the need to invent a new place to put it.
one person suggested that instead of listing all the options in a nice
human readable format we could change it to a series of flags, that won't
quite work as there are three values for most options (Y,N,M) not to
mentions the ones that allow more values. you could still just list all
the config values without including the stuff to the left of the = it
would require matching up with the kernel version specific config file to
tell what is what but would cut down on the space needed.
David Lang
proc is overused, but putting the compile options
On Mon, 2 Apr 2001, Jeff Garzik wrote:
> Date: Mon, 02 Apr 2001 18:09:05 -0400
> From: Jeff Garzik <[EMAIL PROTECTED]>
> To: J . A . Magallon <[EMAIL PROTECTED]>
> Cc: Oliver Xymoron <[EMAIL PROTECTED]>, David Lang <[EMAIL PROTECTED]>,
> Manfred Spraul <[EMAIL PROTECTED]>,
> Albert D . Cahalan <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> [EMAIL PROTECTED]
> Subject: Re: bug database braindump from the kernel summit
>
> "J . A . Magallon" wrote:
> > Could make part of the kernel scripts, or in one other
> > standard software package, like modutils, so its versions are controlled
>
> There is value in putting it into the Linux kernel source tree, in
> linux/scripts dir. But most vendors can and should take this script as
> a sample, and customize it for their distro. The Linux-Mandrake
> installkernel script definitely gets touched every so often, and
> decisions it makes, like updating lilo.conf or grub/menu.lst, or
> autodetecting the boot loader, are definitely not to be applied for all
> cases.
>
> FWIW here is our /sbin/installkernel command line usage help text, to
> give a glimpse of what it does and can do:
>
> Usage: ${0##*/} -[lngarhcq] KERNEL_VERSION BOOTIMAGE MAPFILE
>
> -l: Add a lilo entry
> -i: Dont generate Initrd files
> -n: Don't launch lilo.
> -g: Add a Grub entry.
> -d: Don't autodetect boot loader.
> -a: Autodetect boot loader.
> -r: Features for RPM post install.
> -c: Don't copy files.
> -q: Be quiet.
> -h: This help.
>
>
> > I think the best solution would be to make /boot the 'official' place for
> > kernels, the -X.Y.Z naming an standard, installkernel should save System.map
> > and .config.
>
> There will never be an official place to put this stuff, because that's
> a distro policy decision. A quick search just now reveals no reference
> to /boot in the i386 Makefiles, and only a quick reference in the README
> file.
>
> > And you can add something like /proc/signature/map, /proc/signature/config,
> > etc to md5-check if a certain file fits running kernel.
>
> Additionally, everyone should remember: /proc is not a dumping ground :)
>
> Ad-hoc naming like this has created the procfs namespace ugliness we
> have now... let's not add to it unless we have to, and unless we have a
> good idea of proper naming.
>
> --
> Jeff Garzik | May you have warm words on a cold evening,
> Building 1024 | a full moon on a dark night,
> MandrakeSoft | and a smooth road all the way to your door.
>
-
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: Asus CUV4X-D, 2.4.3 crashes at boot
From: "Alan Cox" <[EMAIL PROTECTED]> > > I've seen the exact same behavior with my CUV4X-D (2x1GHz) under > > 2.4.2 (debian woody). In addition, the kernel would sometimes hang > > around NMI watchdog enable. At least, I think it's trying to > > Known problem. Thats one reason why -ac trees had nmi watchdog turned off. It still crashes with nmi_watchdog turned off. Running with noapic fixes it but then the system crashes if you access the RTC with hwclock (and probably creates a hundred other problems...). How can I get this chipset/motherboard supported properly under Linux? I'm happy to test patches etc. on the box. *pleading* Cheers Simon Garner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On 04.03 Jeff Garzik wrote:
> "J . A . Magallon" wrote:
> > Could make part of the kernel scripts, or in one other
> > standard software package, like modutils, so its versions are controlled
>
> There is value in putting it into the Linux kernel source tree, in
> linux/scripts dir. But most vendors can and should take this script as
> a sample, and customize it for their distro. The Linux-Mandrake
> installkernel script definitely gets touched every so often, and
> decisions it makes, like updating lilo.conf or grub/menu.lst, or
> autodetecting the boot loader, are definitely not to be applied for all
> cases.
>
I think that should be split in two, one thing is building and install a kernel
and one other is add the entry in your bootloader config ('update-bootloader',
for example, that looks into /boot and adds missing entries).
> FWIW here is our /sbin/installkernel command line usage help text, to
> give a glimpse of what it does and can do:
I know, run Cooker.
>
> There will never be an official place to put this stuff, because that's
> a distro policy decision. A quick search just now reveals no reference
> to /boot in the i386 Makefiles, and only a quick reference in the README
> file.
linux/Makefile, #INSTALL_PATH=/boot
>
> > And you can add something like /proc/signature/map, /proc/signature/config,
> > etc to md5-check if a certain file fits running kernel.
>
I usually think about /proc like the way to do a 'cat' instead of a 'syscall',
in this case to ask kernel for various md5 sigs,
but of course you can always write a user app that queries kernel and prints
result for your scripting pleasure...
--
J.A. Magallon # Let the source
mailto:[EMAIL PROTECTED] # be with you, Luke...
Linux werewolf 2.4.3 #2 SMP Fri Mar 30 15:42:05 CEST 2001 i686
-
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:Bug when installing NVidia Driver Module
> /lib/modules/2.4.3/video/NVDriver: unresolved symbol _mmx_memcpy > > however if i rebuild my kernel using an "i686" architecture this problem > no longer comes up. > > It is quite possible that this is NVidia's problem, however it seemed > reasonable that the "athlon" architecture should support MMX. Take it up with Nvidia - its (as usual) their problem - 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: Asus CUV4X-D, 2.4.3 crashes at boot
> I've seen the exact same behavior with my CUV4X-D (2x1GHz) under > 2.4.2 (debian woody). In addition, the kernel would sometimes hang > around NMI watchdog enable. At least, I think it's trying to Known problem. Thats one reason why -ac trees had nmi watchdog turned off. - 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: Matrox G400 Dualhead
On Mon, 2 Apr 2001 17:43:42, Petr Vandrovec <[EMAIL PROTECTED]> wrote: > Trevor Hemsley wrote: > > > I get this as well on my G200. From observation it appears that the > > refresh rate is being doubled when you exit X and that's why the > > console appears blank. On my system I normally use > > > > modprobe matroxfb vesa=263 fv=85 > > > > to give a large text console. On return from X, if I blindly type > > > > fbset "640x480-60" > > > > then I get a visible screen back but my monitor tells me that it's > > running at 640x480@119Hz. Same thing for 800x600-60 only this one says > > 120Hz. > > Unfortunately Matrox datasheet says that it is impossible :-( Can you > try 'fbset -depth 0; fbset -depth 8' ? Yes, that fixes it. Issuing the first fbset command brings me back some sort of display, all fsck'ed up but vaguely readable with shimmering bits of text all over it in the wrong places. The second fbset gets it back correctly at the right resolution and right refresh rate. Thanks, a workaround at least. -- Trevor Hemsley, Brighton, UK. [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: Oracle 8I & Kernel 2.4.3 : Sane ?
> I noticed that 2.4.3 contains some fixs for shared memory - > So the final question IS : > > Is oracle 8.1.5 + Kernel 2.4.3 a sane combination ? Probably not yet but getting closer. > In general is oracle + Kernel 2.4 working ? Ditto. The shm and rawio fixes are very recent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[QUESTION] 2.4.x nice level
Hi! I just noticed, that a process with nice level 19, gets some processor time, even if there is another process, which would use all of the processor time. for example, there is a setiathome running at nice level 19, and a bladeenc at nice level 0. setiathome uses 14 percent, and bladeenc uses 84 percent of the processor. I think, setiathome should use max 2-3 percent. the 14 percent is way too much for me. or is there any other way to run a process only if nothing uses the processor? with kernel 2.2.16 it worked for me. now I use 2.4.2-ac20 Bye, Szabi - 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: Larger dev_t
> Mount NFS device areas with NFSv2. Thats the standard workaround Oh, sure. We survived with 16 bits and we'll survive with 32. Nevertheless it is a bad sign that you have to start talking about workarounds even before the new system has been implemented. (And NFSv2 has its quirks as well. Solaris will split the 32-bit number (the size given in a CREATE request) into 14+18 when it is not a 16-bit value, while it will split it into 8+8 if it is. FreeBSD will regard it as a 8+24 dev_t. So, in general, different systems will parse the same dev_t in different ways, and hence see different (major,minor) for the same device.) 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: bug database braindump from the kernel summit
"J . A . Magallon" wrote:
> Could make part of the kernel scripts, or in one other
> standard software package, like modutils, so its versions are controlled
There is value in putting it into the Linux kernel source tree, in
linux/scripts dir. But most vendors can and should take this script as
a sample, and customize it for their distro. The Linux-Mandrake
installkernel script definitely gets touched every so often, and
decisions it makes, like updating lilo.conf or grub/menu.lst, or
autodetecting the boot loader, are definitely not to be applied for all
cases.
FWIW here is our /sbin/installkernel command line usage help text, to
give a glimpse of what it does and can do:
Usage: ${0##*/} -[lngarhcq] KERNEL_VERSION BOOTIMAGE MAPFILE
-l: Add a lilo entry
-i: Dont generate Initrd files
-n: Don't launch lilo.
-g: Add a Grub entry.
-d: Don't autodetect boot loader.
-a: Autodetect boot loader.
-r: Features for RPM post install.
-c: Don't copy files.
-q: Be quiet.
-h: This help.
> I think the best solution would be to make /boot the 'official' place for
> kernels, the -X.Y.Z naming an standard, installkernel should save System.map
> and .config.
There will never be an official place to put this stuff, because that's
a distro policy decision. A quick search just now reveals no reference
to /boot in the i386 Makefiles, and only a quick reference in the README
file.
> And you can add something like /proc/signature/map, /proc/signature/config,
> etc to md5-check if a certain file fits running kernel.
Additionally, everyone should remember: /proc is not a dumping ground :)
Ad-hoc naming like this has created the procfs namespace ugliness we
have now... let's not add to it unless we have to, and unless we have a
good idea of proper naming.
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full moon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
-
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] multiline string cleanup
"J . A . Magallon" <[EMAIL PROTECTED]> writes: > This is one other try to make kernel sources gcc-3.0 friendly. This cleans > some muti-line asm strings in checksum.h and floppy.h (this were the only > ones reported in my kernel build, perhaps there are more in drivers I do > not use). I surely hope the gcc guys will just remove that silly warning again, because it makes it impossible to write readable inline assembly now. -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/
Re: Cool Road Runner (was CFA as Ide.)
Richard A. Smith wrote: > On Mon, 02 Apr 2001 21:50:59 +0100, Adrian Cox wrote: >> If only. In my limited experience SanDisk cards have been the most >> tolerant. I suspect that Sandisk actually implement the full range of >> timings documented in the spec, and nobody else bothers. [...] > We do actually use SST (Silcon Storage Technolog) CF's as well and they seem to >function just > identical to the SanDisk but not quite as robust... I have had several of the SST's >develope > a problem in the partition table and as thus the just error when you try to mount >them. > Several people on the liunx-embedded list also have similar experiences. > > That seems to follow your observations... > > Will it be worth while for you if I break out the scope and examine how our CF's >handle the > PDIAG signal or can we just go on faith that they do indeed work as expected? Might be interesting to see. The worst trouble I've had has been with noname parts from high street computer stores, and I don't know who the original manufacturer was. If I knew what subset of functionality digital cameras used I'd know what could be relied on. - Adrian - 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: [Fwd: [Copyright/Licensing] "Dual-copyright/licensing" of your IP withOUT your permission]
I like specially this: http://www.passport.com/Consumer/TermsOfUse.asp .. Microsoft reserves the right to review materials posted to a Communication Service and to remove any materials in its sole discretion. Microsoft reserves .. Well, this just says they will read all your e-mail and kick you off if they do not like what you say ? -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3 #2 SMP Fri Mar 30 15:42:05 CEST 2001 i686 - 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: Larger dev_t
> Not using 64 also gives interesting small problems with Solaris or > FreeBSD NFS mounts. One uses 14+18, the other 8+24, so with 12+20 > we cannot handle Solaris' majors and we cannot handle FreeBSD's minors. Mount NFS device areas with NFSv2. Thats the standard workaround for the fact the NFSv3 designers got a good idea slightly wrong. There are other approaches too that also do not need 64bits. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Mon, Apr 02, 2001 at 06:26:45AM +0100, Richard Russon wrote: > On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote: > > Let's hope it's not a flamewar, but here goes :) > > > > We -need- .config, but /proc/config seems like pure bloat. > > Don't ask me for sample code, but... > > The init code for many drivers is freed up after it's used. > Could we apply the same technique and compile in .config, > then printk the entire lot (boot option) and free up the > space afterwards? Though this would save memory at run-time, you'd still increase the size of the image. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
Announcing Journaled File System (JFS) release 0.2.2 available
The latest drop of JFS was made available today. The file system has fixes included. Also, the utilities have been cleaned up to use standard types. In the file system the following problems have been fixed. - Fix for assert(iagp->wmap[extno] & mask); (line #2875) in jfs_imap while running dbench - Fixed hang on scsi - added /proc/fs/jfs/jfsFYI (2.4.* kernels only) echo 1 > /proc/fs/jfs/jfsFYI ; Turns on very verbose output to syslog echo 0 > /proc/fs/jfs/jfsFYI ; Turns it back off For more details about the problems fixed, please see the README. Steve JFS for Linux http://oss.software.ibm.com/developerworks/opensource/jfs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On 04.02 Oliver Xymoron wrote: > > As a former proponent of /proc/config (I wrote one of the much-debated > patches), I tend to agree. Debian's make-kpkg does the right thing, namely > treating .config the same way it treats System-map, putting it in the > package and eventually installing it in /boot/config-x.y.z. If Redhat's > kernel-install script did the same it would rapidly become a non-issue. > Could make part of the kernel scripts, or in one other standard software package, like modutils, so its versions are controlled and can be requested (in Doc/ChageLog, like other things) ? Perhaps it could be put into a kernel-utils package with ksymoops, and standarise the places and naming. I do not know if systems like Caldera, SuSE or Debian adopted the /boot place for kernel things (standard kernels still come with INSTALL_PATH=/boot commented-out), or the vmlinuz-X.Y.Z naming. I think the best solution would be to make /boot the 'official' place for kernels, the -X.Y.Z naming an standard, installkernel should save System.map and .config. And you can add something like /proc/signature/map, /proc/signature/config, etc to md5-check if a certain file fits running kernel. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3 #2 SMP Fri Mar 30 15:42:05 CEST 2001 i686 - 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: Cool Road Runner (was CFA as Ide.)
On Mon, 02 Apr 2001 21:50:59 +0100, Adrian Cox wrote: >> IIRC SanDisk was the original people to come out with IDE CFA and everyone >> else just copied them. I have the SanDisk datasheets that I can send you >> if you need them to verify stuff. I believe that if you verify it with >> the SanDisk then all the other MFG's should work as well. > >If only. In my limited experience SanDisk cards have been the most >tolerant. I suspect that Sandisk actually implement the full range of >timings documented in the spec, and nobody else bothers. > >This isn't normally a problem on PC hardware, but if you try to >implement an interface to talk to a CF card in an embedded system you >find this out. Hmmm... most of our embedded systems are based on a PC somehow either via a processor card or an actual PC system that we design so perhaps I have't stressed the limits yet. We do actually use SST (Silcon Storage Technolog) CF's as well and they seem to function just identical to the SanDisk but not quite as robust... I have had several of the SST's develope a problem in the partition table and as thus the just error when you try to mount them. Several people on the liunx-embedded list also have similar experiences. That seems to follow your observations... Will it be worth while for you if I break out the scope and examine how our CF's handle the PDIAG signal or can we just go on faith that they do indeed work as expected? -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 Sr. Design Engineerhttp://www.bitworks.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/
Swapping wierdness on SparcStation 4 w/ 2.2.19
I built and installed 2.2.19 on my SparcStation 4 last night, and have been testing it by recompiling gcc 2.95.2 over and over. Just noticed now that it doesn't seem to swap at all, despite the fact that the swap partition exists and is active. Here's the output from procinfo (snipped for brevity) Linux 2.2.19 (root@sparc4) (gcc 2.95.2 19991024 ) #6 Sun Apr 1 22:23:42 BST 2001 1CPU [sparc4.] Memory: TotalUsedFree Shared Buffers Cached Mem: 95532 895126020 23784 29560 37576 Swap: 131120 0 131120 Bootup: Sun Apr 1 23:45:56 2001Load average: 1.00 1.00 1.00 3/40 19021 Here's the output from swapon -s: [alex@sparc4]/home/alex > swapon -s FilenameTypeSizeUsedPriority /dev/sda2 partition 131120 0 -1 Here's the /proc/cpuinfo, in case it is relevant [alex@sparc4]/home/alex > cat /proc/cpuinfo cpu : Fujitsu MB86904 fpu : Lsi Logic/Meiko L64804 or compatible promlib : Version 3 Revision 2 prom: 2.24 type: sun4m ncpus probed: 1 ncpus active: 1 BogoMips: 109.77 MMU type: Fujitsu Swift invall : 0 invmm : 0 invrnge : 0 invpg : 0 contexts: 256 I'm not currently subscribed to the l-k mailing list so feel free to cc me on any replies, thanks. -- I'm just too silly for you. http://www.tahallah.clara.co.uk - 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: scsi bus numbering
>The intent is that all built in HBA drivers are >initialized _before_ the built in upper level >drivers (e.g. sd). To get the effect you describe >the driver init order seems to have been: > register ncr53c8xxx > register sd > register aic7xxx # too late ... It is bogus that this stuff depends on link order to function correctly. The driver is built and linked into the kernel in its current fashion to satisfy Linus' desire to make drivers as independant from the SCSI Makefile and Config file as possible. I've modified how the driver is built for the 6.1.9 driver release so it will be linked in prior to the top level drivers. -- Justin - 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: Cool Road Runner (was CFA as Ide.)
Richard A. Smith wrote: > IIRC SanDisk was the original people to come out with IDE CFA and everyone else just >copied > them. I have the SanDisk datasheets that I can send you if you need them to verify >stuff. I > believe that if you verify it with the SanDisk then all the other MFG's should work >as well. If only. In my limited experience SanDisk cards have been the most tolerant. I suspect that Sandisk actually implement the full range of timings documented in the spec, and nobody else bothers. This isn't normally a problem on PC hardware, but if you try to implement an interface to talk to a CF card in an embedded system you find this out. - Adrian Cox - 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: Cool Road Runner (was CFA as Ide.)
On Mon, 23 Apr 2001 21:57:12 -0700 (PDT), Andre Hedrick wrote: >> OK can we just have a technical discussion? >Please, lets do, I am tired of the battles Me three... I am much better at tech than flames although I seemed to have missed all the flambe. BTW... why is this thread called Road Runner? >> I.E. no need for PCMCIA or any of that. I understood from your >> responses that you didn't realise this? >This valid that I do not know everything and that CFA does interesting >things more than what was specified in the past. The converse is true as well.. Having only used the CFA devices as solid state IDE drives I was unaware that there were any that didn't do the True IDE mode. >Sorry phone call and email got mixed togather. >But I did explain that there could be a failure to detect if PDIAG/DASP >if one or the other devices was held to long and the wrong device reported >a signature in the task register. Also that the if you reversed the two >device it would correctly report always. Yes... Now that I am up on the docs I see exactly how this can happen. Mishandled signals would cause device 0 to go 30 seconds before it gave up on Device 1. Andre, do you think it's reasonable to assume that if most PC BIOS's will detect the CFA then it probally is handling the POR sequence and EXECUTE DEVICE DIAGNOSIC correctly? If so then I feel pretty confident that it should work ok.. Over the 2 years we have been using CFAs as solid state HD's I have never seen a case where the BIOS didn't autodetect it properly as master or slave or have I had a problem with a long timeout. I have plugged it up to all manner of machine old and new.. An the usual configuration was that the CFA was Device 0 and some random IDE drive we have laying around was device 1. Now I am not saying it won't happen.. just that I haven't seen it. >Not quite, the electronic differences and flash in native mode is >incompatible, if you put it in to a mode that is 5V compatable then it >does seem possible and reasonable to work. Your imperical data points >verify this issue. Not to mention that the datasheet for the device indicates that this is possible and intended not just happenstance. *grin* >What really needs to happen is that all the devices that are CFA-like >which require name parsing for detecting should have the "flash" rule >imposed. Whereas the ones that correctly report 0x848A for word 0 of the >identify page may be exempt. Yes I think so... Although I haven't done a rigorous reading of the SanDisk datasheet I haven't found anything so far that would lead me to believe that operates any different than an ATA-2 device when operating in True IDE mode. IIRC SanDisk was the original people to come out with IDE CFA and everyone else just copied them. I have the SanDisk datasheets that I can send you if you need them to verify stuff. I believe that if you verify it with the SanDisk then all the other MFG's should work as well. -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 Sr. Design Engineerhttp://www.bitworks.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/
Memory maps
Dear freinds: I have following questions about memory maps. I appreciate any suggestion. Q. (1)When a process is running, how can I get the range of data, stack, and code segments, say the stack segment is from address 0x. to 0x. so do data segments and code segments? PS: Under ELF format, there are several seperaed code and data segments, but the process control table has only one pair of pointers for each, Are the pointers still useful? (2) /proc/*/maps will show us those info, but how does it get these info? FuHau - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
[EMAIL PROTECTED] (Ben Ford) wrote on 01.04.01 in <[EMAIL PROTECTED]>: > Why not have the /proc/config option but instead of being plain text, > make it binary with a userspace app that can interpret it? > > It could have a signature as to kernel version + patches and the rest > would be just bits. > You'd have > 2.4.3-pre3:110101 . . . . . Another option would be to put a checksum of the config, and still keep the config separate - at least you could tell if you had the right config for the kernel. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
OK - everybody back from San Jose - pity I couldnt come - and it is no longer April 1st, so we can continue quarreling a little. Interesting that where I had divided stuff in the trivial part, the interesting part and the lot-of-work part we already start fighting on the trivial part. Maybe it is not very important - still I'd prefer to do things right from the start. Yes. We need a larger dev_t as everybody agrees. How large? What is dev_t used for? It is a communication channel from filesystem to user space (via the stat() system call) and from user space to filesystem (via the mknod() system call). So, it seems the kernel interface must allow passing the values that actually occur, in present or future file systems. Making the interface narrow is only asking for problems later. Are there already any filesystems that use 64-bits? I would say that that is irrelevant - what we don't have today may come tomorrow - but in fact the NFSv3 interface uses a 64-bit device number. So glibc comes with 64 bits, the kernel has to hand these bits over to NFS but is unwilling to - you are not going to get more than 32. Why? > I have a holy crusade. I fail to see the connection. There is no bloat here, the kernel is hardly involved. Some values are passed. If the values are larger than the filesystem likes it will probably return EINVAL. But the kernel has no business getting in the way. There is no matter of efficiency either - mknod is not precisely the most frequently used system call, and our stat interface, which really is important, is 64 bits today. Not using 64 also gives interesting small problems with Solaris or FreeBSD NFS mounts. One uses 14+18, the other 8+24, so with 12+20 we cannot handle Solaris' majors and we cannot handle FreeBSD's minors. [Then there were discussions about naming. These are interesting, but independent. The current discussion is almost entirely about mknod.] 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: [reiserfs-list] Re: ReiserFS - corrupted files (2.4.3)
monstr will debug this and elena will enter it into our buglist file.
Hans
Rasmus Bøg Hansen wrote:
>
> Hello
>
> I am getting musch the same types of corruption. I am on a K6-2 with a
> 30Gb IBM HD and 256Mb RAM running vanilla 2.4.3 with iptables and squid
> caching proxy. The problems arise on the cache part of the FS (i.e. with
> many file operations).
>
> I am considering using reiserfsck (3.x.0j) to fix it, but it has to wait
> until the morning - so in the meantime perhaps somebody can use the info
> about the corruptions? I have nowhere to back up my rather large (in
> comparison to other space on the box) cache, but if it goes lost in the
> process of rebuilding it, it does not matter so much.
>
> What should I do to help? I will try to debug the problem if necessary -
> should I turb on internal checks?
>
> On Mon, 2 Apr 2001, Robert NEDBAL wrote:
>
> > Hello,
> > I'm using ReiserFS on my primary filesystem and yesterday, I have found
> > that some files are corrupted. Yesterday I had to reset computer becase
> > X Window freezed. Maybe it caused this problem.
> >
> > This comes from log:
>
> [SNIP]
>
> My log goes much the same (although I have fewer errors - it seems to
> affect only few files):
> Mar 30 10:32:09 wiibroe kernel: reiserfs: checking transaction log
> (device 16:01) ...
> Mar 30 10:32:09 wiibroe kernel: Using r5 hash to sort names
> Mar 30 10:32:09 wiibroe kernel: ReiserFS version 3.6.25
> [...]
> Apr 2 14:36:10 wiibroe kernel: is_leaf: item location seems wrong:
> *OLD*[1214 319934 0x8f1 DIRECT], item_len 0, item_location 0,
> free_space(entry_count) 2289
> Apr 2 14:36:10 wiibroe kernel: vs-5150: search_by_key: invalid format
> found in block 132193. Fsck?
> Apr 2 14:36:10 wiibroe kernel: is_leaf: item location seems wrong:
> *OLD*[1214 319934 0x8f1 DIRECT], item_len 0, item_location 0,
> free_space(entry_count) 2289
> Apr 2 14:36:10 wiibroe kernel: vs-5150: search_by_key: invalid format
> found in block 132193. Fsck?
> Apr 2 14:36:10 wiibroe kernel: vs-13050: reiserfs_update_sd: i/o
> failure occurred trying to update [1214 319936 0x0 SD] stat datais_leaf:
> item location seems wrong: *OLD*[1214 319934 0x8f1 DIRECT], item_len 0,
> item_location 0, free_space(entry_count) 2289
> Apr 2 14:36:10 wiibroe kernel: vs-5150: search_by_key: invalid format
> found in block 132193. Fsck?
> Apr 2 14:36:10 wiibroe kernel: vs-: reiserfs_delete_solid_item: i/o
> failure occurred trying to delete [1214 319936 0x0 SD]
> [...]
> Apr 2 18:36:25 wiibroe kernel: vs-13042: reiserfs_read_inode2: [1020
> 271248 0x0 SD] not found
> Apr 2 18:36:25 wiibroe kernel: vs-13048: reiserfs_iget: bad_inode. Stat
> data of (1020 271248) not found
> Apr 2 18:36:50 wiibroe kernel: is_leaf: item location seems wrong:
> *OLD*[1214 319934 0x8f1 DIRECT], item_len 0, item_location 0,
> free_space(entry_count) 2289
> Apr 2 18:36:50 wiibroe kernel: vs-5150: search_by_key: invalid format
> found in block 132193. Fsck?
> Apr 2 18:36:50 wiibroe kernel: vs-13070: reiserfs_read_inode2: i/o
> failure occurred trying to find stat data of [1214 319935 0x0 SD]
> Apr 2 18:36:50 wiibroe kernel: vs-13048: reiserfs_iget: bad_inode. Stat
> data of (1214 319935) not found
>
> > When I want to list corrupted directory, I get this:
>
> What I get is:
>
> root@wiibroe:/var/spool/squid# find /var/spool/squid/ -type f | xargs ls
> > /dev/null
> find: /var/spool/squid/01/C5/0001C5DA: Ingen sådan fil eller filkatalog
> find: /var/spool/squid/01/C5/0001C5E6: Ingen sådan fil eller filkatalog
> find: /var/spool/squid/03/F5/0003F5E9: Adgang nægtet
> find: /var/spool/squid/04/B6/0004B6E0: Adgang nægtet
>
> (Ingen sådan fil eller filkatalog = No such file or directory
> Adgang nægtet = Access denied)
>
> Rasmus Bøg Hansen
>
> --
> -- [ Rasmus 'Møffe' Bøg Hansen ] --
> if (getenv(EDITOR) == "vim") {karma++};
> - [ moffe at amagerkollegiet dot dk ] -
-
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: Larger dev_t
> So change them as well for a new distribution. What's there problem. > There isn't anything out there you can't do by hand. > Fortunately so! So users cannot go back and forward between new and old kernels. Very good. Try explaining that to serious production -users- of a system and see how it goes down - 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 for 2.5] preemptible kernel
Nigel Gamble wrote:
>
> On Sat, 31 Mar 2001, george anzinger wrote:
> > I think this should be:
> > if (p->has_cpu || p->state & TASK_PREEMPTED)) {
> > to catch tasks that were preempted with other states.
>
> But the other states are all part of the state change that happens at a
> non-preemtive schedule() point, aren't they, so those tasks are already
> safe to access the data we are protecting.
>
If your saying that the task's "thinking" about a state change is
sufficient, ok. The point is that a task changes it state prior to
calling schedule() and then, sometimes, doesn't call schedule and just
changes its state back to running. Preemption can happen at any of
these times, after all that is what the TASK_PREEMPTED flag is used for.
On a higher level, I think the scanning of the run list to set flags and
counters is a bit off. If these things need to be counted and kept
track of, the tasks should be doing it "in the moment" not some other
task at some distant time. For example if what is being protected is a
data structure, a counter could be put in the structure that keeps track
of the number of tasks that are interested in seeing it stay around. As
I understand the objective of the method being explored, a writer wants
to change the structure, but old readers can continue to use the old
while new readers get the new structure. The issue then is when to
"garbage collect" the no longer used structures. It seems to me that
the pointer to the structure can be changed to point to the new one when
the writer has it set up. Old users continue to use the old. When they
are done, they decrement the use count. When the use count goes to
zero, it is time to "garbage collect". At this time, the "garbage man"
is called (one simple one would be to check if the structure is still
the one a "new" task would get). Various methods exist for determing
how and if the "garbage man" should be called, but this sort of thing,
IMNSHO, does NOT belong in schedule().
George
-
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/
[WARNING] Please don't send kernel patches through Hotmail
- Forwarded message from Bryan-TheBS-Smith <[EMAIL PROTECTED]> - From: Bryan-TheBS-Smith <[EMAIL PROTECTED],[EMAIL PROTECTED]> Subject: [Copyright/Licensing] "Dual-copyright/licensing" of your IP withOUT your permission Date: 2001 April 02 [Copyright/Licensing] "Dual-copyright/licensing" of your IP withOUT your permission USING A PASSPORT.COM-ENABLED SERVICE WILL DUAL-COPYRIGHT/LICENSE YOUR ORIGINAL WORK I just want to throw this out for *OFF-LIST* discussion. I am currently writing an article on the new licensing agreement at Microsoft's Passport.COM. What most people don't realize is that if you use MSN, Hotmail, Expedia and, in some cases, just MS IE/Outlook, you have _already_agreed_ to this license. Why? In the case of MSN, Hotmail and Expedia, your passwords are stored on Passport.COM (remember when Microsoft went down in late 1999 because of their expiration of Passport.COM?). I am still researching the depth of Passport.COM's interaction with MS IE itself (seperate from these services), and other Microsoft and non-Microsoft, Internet-enabled software. The problem? In a nutshell, any outgoing information, software and/or services of your original copyright/license/IP are "dual copyrighted/licensed" to Microsoft c/o this new agreement. This can be _very_dangerous_ from the standpoint of free software development. Worse yet is the fact that no one currently knows to what extent the Passport.COM licensing agreement applies, but it seems all MSN, Hotmail and Expedia users are subject to it, possibly all users of MS IE as well. GPL DOES NOT OVERRIDE YOUR COPYRIGHTS (NOR YOUR ABILITY TO ASSIGN THEM TO OTHERS) Now you may think the GPL (and/or other GNU licensed works like the LGPL, FDL, etc...) protects your work. What you may not realize is that Copyright Law is the _ultimate_ law. The software that cracked the encryption (really "uglification") and revealed the follies of popular "Internet Filtering" software were perfect examples. The software was released GPL, but then revoked later. How? Because the creators ultimately have "all rights reserved" to their copyright, and can revoke any license at any time (like they did when the popular filtering software vendors bought the rights). When you post, upload or otherwise transmit through a Passport.COM-enabled service, you are effectively giving Microsoft a non-exclusive, "blank 'copyright' check" to use your work. Now one way you can "protect" your free software/works from being submissive to this "hole" in Copyright Law is to assign all rights to the Free Software Foundation. In fact, this is exactly what the FSF recommends you do with any GNU licensed work. If you have not done so already, consider doing this with any GPL, LGPL, FDL or other GNU-licensed work that you do not plan to "dual-license" yourself or other entity. IS THIS AN "ANAL" STANCE? MICROSOFT "REALITY CHECK": Now before you think I'm going off an being "anal" on this, or screaming "the sky is falling," realize the following: 1. Many companies are looking for new avenues of revenue and the "total forfeit" or "dual-copyright/licensure" of your copyright/licenses/IP is nothing new. 2. Microsoft (among others, even non-Windows vendors) have been shown time and time again to be all for #1, and abusing the rights of others in the name of profits. 3. *BIG ONE*: Anyone who has interviewed with Microsoft, or visited the Microsoft campus knows that Microsoft's future goals _include_ the revenue stream of _charging_you_ to even see your own data! 4. *ANOTHER*: Microsoft has identified "dual-copyright/licensure" as a key method to "bypassing" the "GPL virus." 5. *MOST IMPORTANTLY*: Microsoft is currently the biggest lobbyist of the US government, and expends the most in legal costs of any American company. Lawyers are difference between something just being just "unethical and not legally binding" and "unethical but quite legal binding and quite enforcable." #5 is what makes the Passport.COM licensing agreement the most scary, even though it is nothing new in some circles. WHAT SHOULD THE FREE SOFTWARE COMMUNITY DO TO COMBAT THIS? Other than avoiding these services and any other that use Passport.COM (which will only get harder and harder as .NET makes it presence), there are some _real_issues_ to doing _anything_ on the Internet that will require our action. At least two key issues need to be addressed (with possible solutions): 1. "Identify" users who are using these services when they contact your web site, archive, CVS repository, etc... They need not only be informed of these issues -- but they need to "sign" a "counter agreement" that they agree to the policies of our site, archive, repository, etc... which either "prohibit" uploading from services where there is such an agreement and/or somehow put the responsibility on the consumer and/or service to NOT allow such "dual-copyright/licensure" rights to be applicable to those
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
According to [EMAIL PROTECTED]:
>[EMAIL PROTECTED] (Chip Salzenberg) wrote:
>>Why not have a kernel thread and use standard RPC techniques like
>>sockets? Then you'd not have to invent anything unimportant like
>>Yet Another IPC Technique.
>
>kerneld (kmod's late unlamented predecessor) used to use Unix sockets
>to communicate from the kernel to the daemon. It forced everybody to
>link Unix sockets into the kernel but there are some people out there
>who want to use it as a module. Also the kernel code for communicating
>with kerneld was "unpleasant", see ipc/msg.c in a 2.0 kernel.
I see.
On the other hand, file-style (e.g. /proc-style) access works in Plan9
at least inpart because each client makes his own connection to the
server. Thus, the question of how clients know which response is for
them is trivially solved. ('Server' would in this case be the JFS
kernel thread.)
Sockets are apparently not the right way to go about getting
transaction support for kernel threads.
AFAIK, Alex Viro's idea of bindable namespaces provides effective
transaction support *ONLY* if there are per-process bindings. With
per-process bindings, each client that opens a connection does so
through a distinct binding; when that client's responses go back
through the same binding, only that client can see them.
I hope that Alex's namespaces patch, implementing per-process
bindings, goes into the official kernel Real Soon Now.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
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.2-ac27
> This is consistent throughout all 2.4.x at least. From your comment I've > learnt SuS v2 requires -ENODEV for the len=0 case. While this would it needs -ENODEV for all cases where you mmap a file which does not support mmap operations. A 0 length mmap could return the address, EINVAL and maybe some other stuff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Jeff Garzik wrote: > On Sun, 1 Apr 2001, David Lang wrote: > > if we want to get the .config as part of the report then we need to make > > it part of the kernel in some standard way (the old /proc/config flamewar) > > it's difficult enough sometimes for the sysadmin of a box to know what > > kernel is running on it, let alone a bug reporting script. > > Let's hope it's not a flamewar, but here goes :) > > We -need- .config, but /proc/config seems like pure bloat. As a former proponent of /proc/config (I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in /boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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: configuring net interfaces
Jeff Garzik <[EMAIL PROTECTED]> writes:
> First of all, you as the HDLC subsystem maintainer have a lot more
> control over what goes into include/linux/hdlc.h than
> include/linux/sockios.h. New SIOC ioctls should not be added on a
> whim, but after examination of the issues involved.
Right. The same applies to config_xxx structures.
This is why we're talking about it here.
> Making a mistake
> and adding a bad/pointless SIOC ioctl means you are stuck with it
> for a long time. The same applies to ioctls in hdlc.h of course -- but
> the key distinction is that you are 100% sure of the issues involved
> because changes are localized to your own domain.
I don't see the real difference. SIOCxxx is just a name+value pair,
everybody can monitor SIOCxxx changes etc.
> Further, each change to sockios.h affects a LOT of code, both in
> and outside the kernel. Localizing your changes also localizes the
> effects of bad namespace and ioctl choices (and bugs, though in this
> case that would be rare).
We should then design it the right way :-)
> Finally, I have this (perhaps crazy) idea that we should move in the
> direction of removing ALL hardware-related ioctls from sockios.h, making
> SIOC the domain of generic network device ioctls.
What are these "generic network device ioctls"? Is add-an-IP-address
a generic enough? Not all devices use IP.
Is set-interface-speed a generic command? Most devices have something
like "speed", clock rate or something like this.
The question is: where would you like to move these ioctls to?
> Comments welcome. IMHO domain-specific ioctls are a better direction
> than the current make-sockios.h-huge-with-new-ioctls approach.
I think we should separate two things there:
- the place (files) where SIOCxxx values are defined
- the way we use ioctl call.
The first question is less important (files are just files, both
sockios.h and protocol header files are acceptable I think). We just
have to make sure ioctls are unique across the kernel - current
sockios.h does the job, but we can, for example, use a prefix like
#define HDLC_PREFIX 0xHD7C and then
#define SIOC_add-HDLC-something HDLC_PREFIX | 0x0001
(It looks more complicated and thus we should avoid it I think).
The second question looks more important, as it influences the actual
code being used.
I just believe something like:
struct ifreq {
name;
union {
struct ifru_addr;
struct ifru_ipv6_something;
...
struct hdlc_physical;
struct eth_physical;
struct fr_protocol;
...
}ifru;
}
and calling ioctl with:
ifreq.name = "qwe0";
ifreq.ifru.fr_protocol.t391 = 20;
ifreq.ifru.fr_protocol.n293 = 5;
ioctl(s, SIOC_SET_FR_PROTO_PARAMETERS, );
is technically much better than:
struct ifreq {
name;
void *data;
}
you have to call it with:
proto = malloc();
ifreq.name = "qwe0";
ifreq.data = proto;
(int*)proto = SIOC_SET_FR_PROTO_PARAMETERS;
(fr_protocol)(((int*)proto) + 1).fr_protocol.t391 = 20;
(fr_protocol)(((int*)proto) + 1).fr_protocol.n393 = 5;
ioctl(s, SIOC_FR_PROTO, );
and it ends in the protocol driver:
do_ioctl(dev, *ifreq, int cmd)
{
verify_area(..., ifreq.data, sizeof(int));
if (*(int*)ifreq.data == SIOC_SET_FR_PROTO_PARAMETERS) {
verify_area(ifreq.data + sizeof(int), sizeof(fr_protocol));
etc.
Your comments?
In short and general: I think the quality (and thus simplicity) of the
actual code is more important than creating mechanisms designed to fight
future possible binary incompatibility issues, especially issues with
helper utils like ifconfig which can be easily rebuild from source.
Of course, we have to design good code and this is why we're all here.
--
Krzysztof Halasa
Network Administrator
-
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: aic7xxx TCQ settings?
> >I'm using 2.4.3 vanilla with aic7xxx (aic7880 onboard) >I set the max # of TCQ commands per device setting to 50..what's a really >good setting for this, just the default of 253? Depends on the device. The aic7xxx driver will determine the maximum number of tags that a particular device can handle and limit the transactions accordingly. For devices with now hard limit, transactions will be dynamically varied to limit the occurrance of queue full but to otherwise try to keep the limit as high as possible. Some devices do not perform well when lots of transactions are outstanding even though they never report queue full. On these devices, you will get better performance if you lower your transaction settings. > >In /proc/scsi/aic7xxx/0 i see for my drives these numbers: > Commands Queued 14 This is a count of the number of commands ever queued to the device. The only time it will "decrease" is when the counter wraps to 0. The counter, at least in the 6.1.8 driver, is an unsigned long. > Commands Active 0 This is a count of the number of commands currently outstanding to the device. You system was idle, SCSI wise, when you pulled this information. > Command Openings 253 Current "soft limit" on tagged transactions. We've never seen a queue full from this device, so the tag count has not been reduced from its original setting. > Max Tagged Openings 253 Hard limit on the number of tagged transactions. The hard limit is set by monitoring the device's "queue full" behavior. -- Justin - 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/
No Subject
Hi all. Ok, maybe this isn't the right list for this question. In 2.2.x the parport_probe module extracted the ieee1284 device id correctly and added to the proc fs. However this doesn't seem to work for me in 2.4.x I only have one device to test it on and since I know there have been some difficulties regarding the device string's length bytes etc I post my device_id string here the first two bytes says that length is 96 and the following is the string "MFG:Winbond;MDL:SA5459B;CLS:DIGCAM;DES:Winbond's DIGCAM driver can not be found in the system;" I have tested to build, parport, parport_pc and ieee1284 both as modules and static into the kernel. Is there some option I need to enable. As far as I understand the CONFIG_PARPORT_1284 should be enough?? Bye Jakob - 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/
aic7xxx TCQ settings?
I'm using 2.4.3 vanilla with aic7xxx (aic7880 onboard) I set the max # of TCQ commands per device setting to 50..what's a really good setting for this, just the default of 253? In /proc/scsi/aic7xxx/0 i see for my drives these numbers: Commands Queued 14 Commands Active 0 Command Openings 253 Max Tagged Openings 253 and the Queued number keeps increasing, never decreasing. is it supposed to do this? Sometimes Commands Active is at 50, but mostly 0 Thanx, -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CFA Membership (Re: Cool Road Runner)
Andre Hedrick wrote: > On Mon, 2 Apr 2001, Padraig Brady wrote: > >> I'm not sure I have. They seem to following the latest spec I >> downloaded from www.compactflash.org > > I am not paying $2500-$5000 annual for membership sorry. > It is bad enough that I burn $800 for T13 plus about $1000 per meeting. > $7000 is my personal financial limit. > > If you want to give me the SPEC to review and no NDA cool, but CFA and SDA > I have not interest in the legal action that will happen I expose SDA for > what it is ... I just filled a form on the WWW site and downloaded: "CF+ and CompactFlash Specificiation revision 1.4" Padraig. - 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/
User guide
SYMPA -- Systeme de Multi-Postage Automatique (Automatic Mailing System) User's Guide SYMPA is an electronic mailing-list manager that automates list management functions such as subscriptions, moderation, and archive management. All commands must be sent to the electronic address You can put multiple commands in a message. These commands must appear in the message body and each line must contain only one command. The message body is ignored if the Content-Type is different from text/plain but even with crasy mailer using multipart and text/html for any message, commands in the subject are recognized. Available commands are: HELp* This help file INFO* Information about a list LISts * Directory of lists managed on this node REView* Displays the subscribers to WHICH * Displays which lists you are subscribed to SUBscribe * To subscribe or to confirm a subscription to , is an optional information about subscriber. UNSubscribe* To quit . is an optional email address, usefull if different from your "From:" address. UNSubscribe ** To quit all lists. SET NOMAIL * To suspend the message reception for SET DIGEST * Message reception in compilation mode SET SUMMARY* Receiving the message index only SET MAIL * reception in normal mode SET CONCEAL* To become unlisted (hidden subscriber address) SET NOCONCEAL * Subscriber address visible via REView INDex * archive file list GET * To get of archive LAST * Used to received the last message from INVITE * Invite for subscribtion in CONFIRM* Confirmation for sending a message (depending on the list's configuration) QUIT* Indicates the end of the commands (to ignore a signature) Powered by Sympa 3.0.3 : http://listes.cru.fr/sympa/ - 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: [lkml]Re: [lkml]Re: Matrox G400 Dualhead
On Sun, Apr 01, 2001 at 07:40:36AM -0700, James Simmons wrote: > > >If I use X on an accelerated, normal Matrox screen, my monitor complains > >on exit: > > > >fH 49.4 KHz, fV 39.8 Hz > > > >(and it doesn't sync at 40 Hz vertical refresh :-( ). > > > >This is _half_ of the normal 80 Hz. Using fbset -a "1600x1200-80" before > >X, of after X, doesn't do anything. Does anybody know what to hack out > >in X to get it to _not_ reset my G400 to some unusable state? 3.3.6 was > >didn't do this. I can use the framebuffer-screen just fine, but I miss > >the DGA extension. > > Try adding this to your XF86Config file: > > Section "Device" > ... > Option UseFBDev > ... > EndSection > A very neat trick. X can now be ended correctly. Unfortunately, any scrolling on any VT afterwards gives me a corrupted screen - parts of the screen from other VT's are inserted below, or over the cursor position, and at 'half-line' intervals. In typing this email, I've seen it 5 times already. I'm willing to test anything - but the corruption is alway gone after I switch VT's. So getting a screendump is not easy. Thanks! Jurriaan -- Send lawyers, guns, and money, The shit has hit the fan. Warren Zevon GNU/Linux 2.4.2-ac28 SMP/ReiserFS 2x1743 bogomips load av: 0.98 0.54 0.21 - 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: ReiserFS - corrupted files (2.4.3)
Robert, That output below is part of the results from reiserfsck /dev/hde5 (obviously /dev/hde5 is the partition that I checked). I'm using reiserfsprogs version 3.x.0i. You can run reiserfsck without any arguments and it can't do any harm to your partition - it's read-only. I tried "reiserfsck -x /dev/hde5" but that didn't fix anything. (the -x switch is supposed to "fix fixable without having to use --rebuild-tree). But reiserfsck --rebuild-tree /dev/hde5 fixed the bitmap problem in this case, and it didn't cause any new problems. Nevertheless, I'm using reiserfs on all my machines, so I would be glad to help debug the problems asap - I'm worried about losing a whole partition here and there eventually. I'd go back to kernel 2.2.18, which is supposedly very stable, but I can't. It doesn't work for me on reiserfs partitions created with 2.4.x. I don't know where to start with debugging, either, but I'm willing to take instructions. -Nick * Robert NEDBAL ([EMAIL PROTECTED]) [010402 10:28]: > Hello, > thank you for your fast reply. > > On Mon, 2 Apr 2001, Nicholas Petreley wrote: > > Comparing bitmaps..free block count 613785 mismatches with > > a correct one 613799. > > byte 114154: bm1: bm2 1f > > byte 114155: bm1: bm2 fffc > > byte 118307: bm1: bm2 ffef > > byte 118309: bm1: bm2 3f > > byte 118310: bm1: bm2 fffc > > byte 118312: bm1: bm2 ff87 > > on-disk bitmap does not match to the correct one. 6 bytes > > differ > > How you get these results? > > > > > And I found a recently updated log file with nulls in it - > > I thought that problem was fixed long ago. I've been using > > ac28 and 2.4.3 while getting these errors. The corruptions > > occur on two machines, asus a7v and asus a7v133, via686a > > and via686b. I've had reasonably good luck with > > reiserfsck, though, so it's not something to fear entirely. > > ;-) > > > > I'll try running reiserfsck as the last option. (Just before complete > reinstallation :-) ) > > > I'd be glad to help with any debugging as time permits. > > > > I'm happy that somebody is interrested in debugging. Bud I'm only C/C++ > coder, I dont know much about kernel internals. How can I begin with > debugging? > > regards, > Robert > > > > > -- > > ** > > Nicholas Petreley Caldera Systems - LinuxWorld/InfoWorld > > [EMAIL PROTECTED] - http://www.petreley.com - Eph 6:12 > > ** > > . > > > > > Robert Nedbal - Czech Technical University in Prague, Czech Republic > email: [EMAIL PROTECTED] http://www.sh.cvut.cz/~robik/ > /* Debuggers are evil. Never ever trust them. */ > > -- ** Nicholas Petreley Caldera Systems - LinuxWorld/InfoWorld [EMAIL PROTECTED] - http://www.petreley.com - Eph 6:12 ** . - 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/isdn/hisax/bkm_a8.c, kernel 2.4.2 (Scitel Quadro)
Hi all, great to hear, that the fix solves the problem. Is there any information about, whether and when the fix will migrate into the isdn4l source pool? Roland - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, March 30, 2001 5:05 PM Subject: [PATCH] drivers/isdn/hisax/bkm_a8.c, kernel 2.4.2 (Scitel Quadro) > Hi, > > Please find attached a patch to fix the following problems with the > Scitel Quadro ISDN card in 2.4 kernels which suddenly arised when I > bought > a K7T Pro motherboard. > > kernel: HiSax: Scitel port 0xcc00-0xcd00 already in use > kernel: HiSax: Card Scitel Quadro not installed ! > > Credits go to Roland Klabunde who told me early december: > > > The Scitel [...] resource requirements are as follows: > > - 1 shared interrupt for all controllers > - 1 shared port address for all controllers with a range of 128 bytes > - 1 port address for each controller with a range of 64 bytes > > [...] > > I've currently downloaded the ISDN stuff [...] As mentioned above, the > span is *128* for pci_ioaddr1 and *64* for pci_ioaddr2 to pci_ioaddr5 > [...]. What I see from the source is, that one attempts to claim a > range of 256 bytes for pci_ioaddr1 to _5. That may cause the problems > if the range overlaps with other boards. You may try to change the > following calls in bkm_a8.c: > > sct_alloc_io(pci_ioaddr1, 256) to sct_alloc_io(pci_ioaddr1, 128) > sct_alloc_io(pci_ioaddr2, 256) to sct_alloc_io(pci_ioaddr1, 64) > sct_alloc_io(pci_ioaddr3, 256) to sct_alloc_io(pci_ioaddr1, 64) > sct_alloc_io(pci_ioaddr4, 256) to sct_alloc_io(pci_ioaddr1, 64) > sct_alloc_io(pci_ioaddr5, 256) to sct_alloc_io(pci_ioaddr1, 64) > > Please note the necessary changes in release_io_sct_quadro. > > > Too bad I went on a holiday that time and forgot all about it, untill > today (shame shame shame). Anyway, this patch to 2.4.2 > drivers/isdn/hisax/bkm_a8.c fixes the problem and everything runs > fine again. > > Ime Smits > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA 82C686 Audio Codec: Clicks
You could try the ALSA driver if you're certain it is not a hw problem.It works better here than the one in the kernel. On Sun, 1 Apr 2001, Harald Dunkel wrote: > Hi folks, > > Has anybody an idea how to get rid of the annoying clicks of the > VIA 82C686 audio codec? Using xmms (just as an example) I get a > click with each new track, when I move and release the track slider, > etc. > > Even this > > echo -n "" >/dev/dsp > > produces a click. > > > Regards > > Harri > - > 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: Matrox G400 Dualhead
mythos wrote: > > I solved the problem with dualhead!!! > Second head from 2.4.3 is /dev/fb2 rather than /dev/fb1. > Just had to look to the messages. And who is /dev/fb1? You must change your configuration... > P.S. Petr on the second head if I put mouse in the right-corner at the > bottom of the screen I will have a nice white border around the screen. It is feature. Secondary head does not have any blanking, it just repeats last 64bits (last memory fetch cycle) again and again through whole vertical blanking interval (try 'setterm -bgcolor red' and you'll see). There are two possible workarounds: (1) create screen with width = 648 instead of 640 (it must be visible width!) and fill this column with black. This brokes too many apps because of they expect that they can horizontally scroll for vxres - xres pixels :-( This is what Windows drivers do. (2) create screen with height = 481 instead of 480 and fill this line with black. Unfortunately, you cannot use virtual scrolling then :-( So I decided just to live with it... You can just try 'fbset -yres 481 -vyres 481' - it should implement (2). > Also cursor blinks very strange if there is a lot of move on another > framebuffer on the first head and leaves some white blocks around. You are not using 'video=scrollback:0', do you? You should... There were some changes in console_lock recently, maybe that someone now forgets to grab lock when doing scrolling/putcs? Petr - 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/
CFA Membership (Re: Cool Road Runner)
On Mon, 2 Apr 2001, Padraig Brady wrote: > I'm not sure I have. They seem to following the latest spec I > downloaded from www.compactflash.org I am not paying $2500-$5000 annual for membership sorry. It is bad enough that I burn $800 for T13 plus about $1000 per meeting. $7000 is my personal financial limit. If you want to give me the SPEC to review and no NDA cool, but CFA and SDA I have not interest in the legal action that will happen I expose SDA for what it is ... Andre Hedrick Linux ATA Development - 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 connectivity trashed.
On Thu, 29 Mar 2001, Doug Ledford wrote: > John Jasen wrote: > > > > On Thu, 29 Mar 2001, Richard B. Johnson wrote: > > > > > In short, your security administrator needs to be dragged out, shot, and > > left hanging by the front door as a warning to his replacement. > > > > Or, at least fired. > I have now gotten three linux machines back "on-the-air". The security people insist on doing "NAT", so these machine are now using a phony internal address, but we are up. Another crisis created and resolved. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Matrox G400 Dualhead
Trevor Hemsley wrote: > I get this as well on my G200. From observation it appears that the > refresh rate is being doubled when you exit X and that's why the > console appears blank. On my system I normally use > > modprobe matroxfb vesa=263 fv=85 > > to give a large text console. On return from X, if I blindly type > > fbset "640x480-60" > > then I get a visible screen back but my monitor tells me that it's > running at 640x480@119Hz. Same thing for 800x600-60 only this one says > 120Hz. Unfortunately Matrox datasheet says that it is impossible :-( Can you try 'fbset -depth 0; fbset -depth 8' ? Petr - 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: Cool Road Runner
Andre Hedrick wrote: > On Mon, 2 Apr 2001, Padraig Brady wrote: > >> OK can we just have a technical discussion? > > Please, lets do, I am tired of the battles > >> I.E. no need for PCMCIA or any of that. I understood from your >> responses that you didn't realise this? > > This valid that I do not know everything and that CFA does interesting > things more than what was specified in the past. cool. >> 2. Compact Flash in this application (I.E. solid state hard disk) is >> getting very popular as prices are tumbling. >> >> 3. Having a config parameter (uneeded kludge in my opinion), like hdx=flash >> even if hdx is not a compact flash is confusing. Can we call it hdx=probe >> which fits nicely with the noprobe option. >> >>> I then explained why the detection was failing and pointed where to verify. >> >> No you didn't. You mentioned a 30 second timeout, but not why it >> was caused. Have you seen this yourself or can you point us at who >> reported this to you? > > Sorry phone call and email got mixed togather. > But I did explain that there could be a failure to detect if PDIAG/DASP > if one or the other devices was held to long and the wrong device reported > a signature in the task register. Also that the if you reversed the two > device it would correctly report always. > Hmm, OK. >> >>> After 3-5 attempts and I can not get the point across because the other >>> party keeps going off in different directions to do "what about this", >> >> Emm, I think *you* were going off describing your application with >> a "bazar ata-bridge", not the simple use of a compact flash as a >> hard disk. > > Not quite, the electronic differences and flash in native mode is > incompatable, if you put it in to a mode that is 5V compatable then it > does seem possible and reasonable to work. Your imperical data points > verify this issue. cool > What really needs to happen is that all the devices that are CFA-like > which require name parsing for detecting should have the "flash" rule > imposed. Whereas the ones that correctly report 0x848A for word 0 of the > identify page may be exempt. sounds good if we can easily differentiate between buggy & non-buggy flash. > This seems like a reasonable step given that you are pointing out you > a have modern CFA's that are more than just CFA's. I'm not sure I have. They seem to following the latest spec I downloaded from www.compactflash.org > Would that work for you? > >>> I finally pointed out facts that distrub people, and gave up on trying to >>> show/present/give the answer and offered to then enforce their beliefs of >>> reality. >>> >>> So I state a few facts very pointed to get their attention again and that >>> is additude?? >> >> Actually I thought the final email was a little more concise/informative, thanks. > > Well I am glad that somebody gleened some information and providing > feedback so that forward progress is possible, and not the classic battles. cool, Padraig. - 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: Assumption in sym53c8xx.c failed
On Sat, 31 Mar 2001, Christian Kurz wrote:
> Hi,
>
> I'm currently running 2.4.2-ac28 and today I got a failing assumption in
> sym53c8xx.c. I'm not sure about the exact steps that I did to produce
> this error, but it must have been something like: cdparanoia -blank=all,
> then sending Ctrl+C to this process and after it's been killed
> cdparanoia -blank=fast. I then got assertion: k!=-1 failed. But I found
> no hint about this in the messages or syslog file. So I looked through
> sym53c8xx.c to find this code and it seems like line 10123 is
> responsible for creating this error and kernel panic. Should this be the
> normal behaviour or is this a bug in the code?
This might well be both at the same time. I mean normal behaviour given a
bug in the code. :-)
Could you try this tiny patch and let me know:
--- sym53c8xx.c.0402Mon Apr 2 15:58:32 2001
+++ sym53c8xx.c Mon Apr 2 16:02:43 2001
@@ -10167,14 +10167,13 @@
if (i >= MAX_START*2)
i = 0;
}
- assert(k != -1);
if (k != 1) {
np->squeue[k] = np->squeue[i]; /* Idle task */
np->squeueput = k; /* Start queue pointer */
- cp->host_status = HS_ABORTED;
- cp->scsi_status = S_ILLEGAL;
- ncr_complete(np, cp);
}
+ cp->host_status = HS_ABORTED;
+ cp->scsi_status = S_ILLEGAL;
+ ncr_complete(np, cp);
}
break;
/*
What happens is that this part of the driver code assumed that the CCB for
an IO to abort is queued to the SCSI SCRIPTS. This is not always true
since the driver may temporarily not queue all IOs to SCRIPTS. This may
happens on QUEUE FULL condition or for devices that donnot accept tagged
commands, for example.
Regards,
Gérard.
-
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: can not compile 2.4.3 on alpha
On Mon, Apr 02, 2001 at 02:40:01PM +0300, Andrejs Dubovskis wrote: > [linux] make dep;make clean;make boot > ... > gcc -D__KERNEL__ -I/usr/src/linux-2.4.3/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -c -o init/main.o > init/main.c > In file included from /usr/src/linux-2.4.3/include/linux/highmem.h:6, > from /usr/src/linux-2.4.3/include/linux/pagemap.h:17, > from /usr/src/linux-2.4.3/include/linux/locks.h:9, > from /usr/src/linux-2.4.3/include/linux/raid/md.h:37, > from init/main.c:25: > /usr/src/linux-2.4.3/include/asm/pgalloc.h:334: conflicting types for > `pte_alloc' > /usr/src/linux-2.4.3/include/linux/mm.h:399: previous declaration of > `pte_alloc' > /usr/src/linux-2.4.3/include/asm/pgalloc.h:352: conflicting types for > `pmd_alloc' > /usr/src/linux-2.4.3/include/linux/mm.h:412: previous declaration of > `pmd_alloc' > make: *** [init/main.o] Error 1 can you try this patch? ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.3/alpha-numa-2 Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cool Road Runner
Andre Hedrick writes: > On Mon, 2 Apr 2001, Steffen Grunewald wrote: > > > And BTW: Isn't Andre's writing style very lovely ? > > DGD, and who made you a grammer teacher of english on LKML? > Never claimed to be an "English Major" soo WTF is the price of > eggs in Germany today? This is no different to trying an orthoginal > rotation to one's person. Well, I for one think people should make the effort to write better English. It makes it easier to parse. I realise it's hard, more so for some than others. I also realise that there's the temptation to just blurt out quickly and move on. But overall it's still better to make it easier for people to read. As I say in the FAQ "write for maximum efficiency of reading". More time is wasted if thousands of brains stall for a minute while parsing, than if one brain stalls for 5 minutes in generating. Respect the time of the readers. Their time is important too. However, flaming about it isn't the right answer either. Nor are snide comments. The point can be raised politely (i.e. "I have difficulty parsing your messages because of your writing style/grammar/spelling"). Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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/
Basic Text Mode (was: Re: Question about SysRq)
> Thought, i really love all sysrq properties of linux, so i need less often > to make hardware resets an then await and fear, what fsck will print. 101% ACK > One more property, that i'd like to have should be request key to force the > most basic text mode (say 80x25) on the console, when eg. X freezes and > i kill its session, then last gfx mode resides on the screen and see no way > to restore back the text mode - /usr/bin/reset or something alike will not > do it. But it seems to be not a good idea at all, does it ? It is a very good idea, and to implement quite easy. You just do have to diff between three types of video cards (MDA, MGA and HGC vs. CGA and AGA vs. EGA+). Then you do direct register writes. For the HGC I did it recently in a DOS proggy which switched from text to gfx and back. I had a TSR which simulated a gfx BIOS. Only problem is, I lost the source. But I could rewrite and test it on request. I even would put it under GPL for the kernel (normally this is a no-no for me), just ask me. I will write it in NASM then because I can't the AT syntax. For non-i386 Platforms I do not know about this topic. (IIRC the Apples didnt even have a text mode) Maybe I could look up the EGA register values somewhere. -mirabilos - 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/
