Re: Matrox G400 Dualhead
J Brook wrote: > > >With 2.4.2 it was working just fine. > > I have also noticed problems with the 2.4.3 release. I have a G450 > 32Mb, that I use in single-head mode. The console framebuffer runs > fine at boot time, but when I load X (4.0.3 compiled with Matrox HAL > library) and then return to the console, I get a blank screen (signal > lost). In my case, when lilo boots my G450 on any video mode other than 'normal', going into X and then back into console, leads to a blank screen. I've observed this behavior in 2.2 and 2.4. Otherwise, I've no problem using the card in single or dual head. Since the HAL lib is a binary, we might have to wait for Matrox to fix this problem. -- Rafael - 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: ACPI poweroff problem with 2.4.x on VIA chipset M/B
No there isn't a chipset patch for ACPI, because IMHO vendor-specific code is the wrong way to go regarding this. ACPI defines how shutdown should happen, and if it doesn't work on a given system, then either the code has a bug or the hardware is not ACPI compliant. (I think the ACPI code has a bug, but it's not immediately obvious to me how to fix it, since we are doing what the spec says, so what more can we do?) Regards -- Andy > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > My machine has ASUS CUV4X-E mainboard with Award BIOS. > Using poweroff command, I can power off my machine > with kernel 2.2.x. > But with kernel 2.4.x, this machine doesn't change > to soft-off(S5) state after poweroff command enters. > The last message is "Could not enter S5". > However, old via-chipset mainboard machine has > no problem to poweroff with kernel 2.4.x. > > I found 2.3.x VIA chipset patch for ACPI. > Is there 2.4.x VIA chipser pach for ACPI? > > Please CC any replies to my email address > becausen I am not subscribed to linux-kernel - 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: kapm-idled using 45% CPU (why not 100%?)
Stephen Rothwell writes: > Hi Jamie, > > Jamie Lokier <[EMAIL PROTECTED]> writes: > > Subject says it all. On my laptop which is running 2.4.0, while the > > machine is completely idle "top" reports kapm-idled as usin about 45% of > > the CPU. The remaining 55% is reported as idle time. > > This is normal behaviour ... the current implementation of kapm-idled > means that it is sleeping some of the time, so the real idle process > actually gets some time. I did a patch a while ago the got the kapm-idled > up to about 93-95%, but I didn;t think i was all that important. > > > When the machine gets a little more active, the CPU time attributed to > > kapm-idled decreases while the 55% idle time increases to 85%! > > Again this is normal (although it may not seem sensible). > > > This is not caused be "top": I get the same 45% from "ps -l 3". > > > > I remember when kapmd was reporting 100%. Is the new behaviour > > intentional, and is it saving the maximum power on the laptop? > > I have NEVER seen kapmd getting 100%. You are probably getting > about as good power saving as you will get (unfortunately) although > don't hold me to that - I have heard of some laptops that get better > power savings when CONFIG_APM_CPU_IDLE was NOT set ... The Cyrix chips have an extremely low power mode: they stop the clock on halt. They use microwatts in this mode (you need to frob a register to enable this). On an idle machine, these chips don't need a heatsink and still run cool. If you enable APM on these machines, the CPU runs hot even though it's idling. That's because the clock is still running. Slower, yes. But there's a big difference between slowing down the clock a few times, or stopping it entirely. 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/
Problems with 2.4 kernels (including latest; 2.4.3-pre8) related tohard drives/file systems
Hi, I am not subscribed to this list. Please email me with any questions. I've been trying unsuccessfully to use 2.4 kernels for a while now. I wanted to use DRI and it seems I need a 2.4 kernel for it to work but I have the following problem: description: when I go to pretty much any directory, but for example, /usr/src (/usr is mounted as /dev/hdc5) and do an "ls", the list starts but it freezes at a certain entry and as far as I can tell never resumes. I can press control-c and it aborts just fine and my computer keeps running normally - I can do pretty much anything - but if I try to list the file (the one it stopped at) or many others, the same thing happens again. I can't think of anything remarkable about /dev/hd5 - it is an ext2 partition, on an IBM Ultra33 drive (see below), on the motherboard controller. Perhaps it is because I have an Intel 840 chipset motherboard? Oh, DMA is on, block transfer is on and 32 bit transfer is on for this drive. Here is my hardware: Intel 840 chipset (SuperMicro P3DME) with two 850MHz Pentium 3 chips (100MHz bus, slot1), 512MB PC100RAM (2x256MB buffered ECC; ECC disabled). Voodoo3 3500 AGP TV, Promise Ultra66, SoundBlaster Live! MP3+, Adaptec AIC-7850 SCSI card with Plextor 8x CD burner and Pioneer 10x DVD drive, Znyx ZX348Q (two DEC Tulip chips with a PCI bus controller). The motherboard has onboard LAN (EtherExpressPro 100) and sound (don't know what; it's disabled). Hard drives are layed out as follows: hda: LS-120 VER5 00 UHD Floppy, ATAPI FLOPPY drive hdb: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive hdc: IBM-DJNA-352500, ATA DISK drive hde: IBM-DPTA-353750, ATA DISK drive hdg: IBM-DPTA-353750, ATA DISK drive hde and hdg are on the Promise Ultra66 controller and are part of a stripe set using normal kernel RAID support. However I have this problem on drives not associated with this stripe set. here is how hdc is partitioned: Disk /dev/hdc: 16 heads, 63 sectors, 49585 cylinders Units = cylinders of 1008 * 512 bytes Device BootStart EndBlocks Id System /dev/hdc1 166 33232+ 83 Linux /dev/hdc267 587262584 82 Linux swap /dev/hdc3 * 588 4749 2097648 83 Linux /dev/hdc4 4750 49585 225973445 Extended /dev/hdc5 4750 10991 3145936+ 83 Linux /dev/hdc6 10992 49585 19451344+ 83 Linux and how they are mounted: /dev/hdc2 swapswapdefaults 0 0 /dev/hde5 swapswapdefaults 0 0 /dev/hdg5 swapswapdefaults 0 0 /dev/hdc3 / ext2 defaults,nocheck,noatime 1 1 /dev/hdc5 /usrext2 defaults,nocheck,noatime 1 2 /dev/hdc6 /home ext2 defaults,nocheck,noatime 1 3 /dev/hdc1 /boot ext2 defaults,nocheck,noatime 1 4 /dev/md0 /raid ext2 defaults,nocheck,noatime 1 2 here are my SCSI drives incase it helps: scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.31/3.2.4 scsi : 1 host. (scsi0:0:3:0) Synchronous at 10.0 Mbyte/sec, offset 15. Vendor: PIONEER Model: DVD-ROM DVD-305 Rev: 1.00 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 (scsi0:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 8. Vendor: IMATION Model: CD-RW IMW080220 Rev: 1.00 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0 scsi : detected 2 SCSI generics 2 SCSI cdroms total. sr0: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.11 sr1: scsi3-mmc drive: 20x/20x writer cd/rw xa/form2 cdda tray I don't think I have anything strange in my kernel config but if you want I can send it to you - or anything else you need to fix this - even access to my machine in this state if you want. I hope this helps. Nicholas - 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: kapm-idled using 45% CPU (why not 100%?)
Hi Jamie, Jamie Lokier <[EMAIL PROTECTED]> writes: > Subject says it all. On my laptop which is running 2.4.0, while the > machine is completely idle "top" reports kapm-idled as usin about 45% of > the CPU. The remaining 55% is reported as idle time. This is normal behaviour ... the current implementation of kapm-idled means that it is sleeping some of the time, so the real idle process actually gets some time. I did a patch a while ago the got the kapm-idled up to about 93-95%, but I didn;t think i was all that important. > When the machine gets a little more active, the CPU time attributed to > kapm-idled decreases while the 55% idle time increases to 85%! Again this is normal (although it may not seem sensible). > This is not caused be "top": I get the same 45% from "ps -l 3". > > I remember when kapmd was reporting 100%. Is the new behaviour > intentional, and is it saving the maximum power on the laptop? I have NEVER seen kapmd getting 100%. You are probably getting about as good power saving as you will get (unfortunately) although don't hold me to that - I have heard of some laptops that get better power savings when CONFIG_APM_CPU_IDLE was NOT set ... Cheers, Stephen - 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: Recent problems with APM and XFree86-4.0.1
Hi Jamie, Jamie Lokier <[EMAIL PROTECTED]> writes: > > On that theme of power management with X problems, I have been having > trouble with my laptop crashing when the lid is closed, instead of > suspending as it used to. The laptop is a Toshiba Satellite 4070CDT. Can you please try adding Option "NoPM" to the device section of XF86Config or (XF86Config) and then try suspending and resuming. This made suspend/resume much more reliable on the Thinkpad 600E with XFree86 4. Also you could try XFree86 4.0.2, as I know that it actually does interact with APM (4.0.1 may have as well - I am not sure). Cheers, Stephen Rothwell[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/
[Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
>I took to using X, with a single screen size xterm to present the >illusion of console mode. Cute trick. I have seen some slow text mode cards. As time goes on it will get worst since text mode support is not the prime goal anymore. Especially now that you see graphical BIOS interfaces. Some graphics cards manufactures have dropped vga text mode support all together. In the next 5 years you will see the elimination of vga text mode. >Probably the lack of hardware area copies has something to do with >this. 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 data transfers over the bus. It needs more testing but from my comparison between my voodoo 3 accel engine and this code it ran nearly as fast as the accelerator at all depths :-) Another idea for 2.5.X is to implement a font cache in video memory. Even with AGP it is just to slow to constantly transfer font data over the bus. Of course this requires a bit of work since we only have so much video memory but it is worth it for the performance improvement. 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/
[Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
>The console driver does not actually use 2.5MB. Does it make sense to >use an MTRR for the smaller power-of-two region? If we implement a font cache in the future it could. Also that extra memory is used to allow scrollback. We could break up the size of the region. Have it a*2^n+b*2^(n-1)+c*2^(n-2)+... = 2.5 MB. Isn't math grand :-) 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: fbcon slowness [was NTP on 2.4.2?]
>> Probably the lack of hardware area copies has something to do with >> this. However, who isn't familiar with xterm "jump scroll" mode? >> That's nice and fast. >> >> Could such a thing be implemented in the console driver? > >I believe so. It would be simple: if there's too much activit, defer >framebuffer updates and only update in-memory copy. Sync from time to >time. I'd certainly like to see that. If the time between syncs gets to big then the amount of data to go over the bus would kill performance. Plus this has the problem that even small areas like 12x20 areas become more expensive as the bpp increases. A better solution is to implement accelerated copyareas. In fact for 2.5.X I have the fbcon system wrapped around using accels instead of writing to the framebuffer directly. I have had enormous improvements doing this. Plus using this approach makes the fbcon layer much simpler and smaller in size. Thus better performace overall. 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: fbcon slowness [was NTP on 2.4.2?]
>I had patch which tried that at one point. Just try all 2^n numbers ><= size until it succeeds. Hum. Is this the only way we can solve this problem? I assume you end of with most of but not all the video memory using MTRR then. Kind of sucks!! 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: Plans for 2.5
On Thu, 29 Mar 2001, Hen, Shmulik wrote: > Just some general questions: > > 1) Is there anywhere a list that describes what is intended to be in 2.5.x ? > 2) Are there any early releases of 2.5.x ? if it's anything like 2.1 or 2.3 we need a bit more 2.4 tidying till somebody decides some major component needs a rewrite. > 3) Are the things for 2.5.x being discussed on another mailing list ? > 4) What is the time frame of releasing 2.5.x-final (or 2.6.x) ? wow that's jumping the gun a bit. > Specifically, I'm more interested in the network driver aspect. > 1) Are there any intended changes to the networking layer ? I should think. > 2) I over heard something about making the driver reentrant - any news ? > 3) What about support for IPv6 ? (I noticed it was marked as experimental > until now) one of things I'd like to see is igmpv3 support. The sprintlabs code would need pretty serious effort to make pretty, but folks are starting to work on getting wilberts (kpn) code into freebsd 4.3 beta so it might be time to start looking at it. > > Thanks in advance, > Shmulik Hen > Software Engineer > Linux Advanced Networking Services > Intel Network Communications Group > Jerusalem, Israel > > > -Original Message- > From: Bruno Avila [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 29, 2001 12:45 AM > To: [EMAIL PROTECTED] > Subject: Plans for 2.5 > > > Hello people, > > I got some questions. When are we going to develop stuff for 2.5? > What is > planed? My opinion for linux 2.5 should be performance. Since linux already > is stable or well done for nature, we could thing more on performance to be > a diferencial over others. What do you people thing? > > Bruno Avila > > PS: Not a good english. I know! :) > > - > 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/ > -- -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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?]
> > You have same toshiba satellite as me, right? > > Yes Is this the NeoMagic chipset? 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 Kernel IRC Room?
there's discussion on irc.linpeople.org and irc.slashnet.org... but I'm not sure the kernel needs an offical channel... joelja On Thu, 29 Mar 2001, Colin Watson wrote: > David Lang <[EMAIL PROTECTED]> wrote: > >how do you hold a real-time chat with people around the world? the fact > >that the key people would seldom be on at the same time severly limits > >it's usefullness. the mailing list does a pretty good job as is. > > Doesn't seem to harm #debian-devel ... > > -- -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA IDE driver status ?
Hi. I really can't get UDMA66 with the VIA driver. I tried
everything, also a new motherboard (ASUS A7Pro) with a
ATA100/ATA66 cable (using both ends...)!
All I get are the usual CRC error messages.
So, there's no UDMA66 for any vt82c686a ? I'm using 2.4.3.
If there's no UDMA66, what are the advantages using this
driver ?
TIA.
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
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/
ACPI poweroff problem with 2.4.x on VIA chipset M/B
Hello everyone, My machine has ASUS CUV4X-E mainboard with Award BIOS. Using poweroff command, I can power off my machine with kernel 2.2.x. But with kernel 2.4.x, this machine doesn't change to soft-off(S5) state after poweroff command enters. The last message is "Could not enter S5". However, old via-chipset mainboard machine has no problem to poweroff with kernel 2.4.x. I found 2.3.x VIA chipset patch for ACPI. Is there 2.4.x VIA chipser pach for ACPI? Please CC any replies to my email address becausen I am not subscribed to linux-kernel - nso --- SangOg Na - 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/
2.4.3 CVS 20010330: No floppy
Mostlt RH 6.2 on sparc64. 2.2.18 works fine. A strace(1) of a failed
mdir(1) ends:
open("/dev/fd0", O_RDONLY|O_LARGEFILE) = 3
SYS_63()= 0
flock(3, LOCK_SH|LOCK_NB) = 0
ioctl(3, FDGETPRM, 0xefffde98) = -1 ENODEV (No such device)
close(3)= 0
write(2, "init: set default params\n", 25init: set default params
) = 25
write(2, "Cannot initialize \'A:\'\n", 23Cannot initialize 'A:'
) = 23
exit(1) = ?
--
Dr. Horst H. von Brand mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3c905B(cyclone) DHCP delay on boot time
Hello everyone, I recently upgraded kernel to 2.4.2 on 3 machines. These machines use DHCP. 2 machines have 3c905B(cyclone) and 1 machine has 3c905c(Tornado). At boot time, there are over 1 minute delay to bring up network interface eth0 at 3c905B machines. There is no problems when booting with kernel 2.2.x or booting with kernel 2.4.2 on 3c905C machine. Please CC any replies to my email address becausen I am not subscribed to linux-kernel - nso --- SangOg Na - 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
J Brook wrote: > > > Does anyone know why fualhead is not working anymore? > > I just get a screen with rubbish on the second head. > > Also when kernel loads and and registers fb1 I lose signal > > on the second head. On G400 there is no signal on second head after poweron. So you cannot lose it ;-) On G450 there is same signal on both heads - but you are talking about G400. Or no? They are very different (they have different everything except PCI device ID register :-( ). You should add 'Option "UseFBDev"' into your XF86Config-4 - probably together with 'Option "NoHWCursor"'. > ... > > >With 2.4.2 it was working just fine. > > I have also noticed problems with the 2.4.3 release. I have a G450 > 32Mb, that I use in single-head mode. The console framebuffer runs > fine at boot time, but when I load X (4.0.3 compiled with Matrox HAL > library) and then return to the console, I get a blank screen (signal > lost). It is easy - do not do that. Matroxfb really does not expect that someone will powerdown parts of chip which matroxfb needs, but which XFree does not use (for example clock source for secondary head) or that it will change some undocumented registers (for example Matrox HAL driver changes memory clock speed). > I don't know what the problem is. I can confirm with Mythos that > under > 2.4.2 it was working just fine :-) I have no idea what changed between 2.4.2 and 2.4.3 - I do not remember that I was doing some changes into the matroxfb during last few weeks - so maybe that source of these problems is in XFree 4.0.3 ? Petr Vandrovec [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/
kapm-idled using 45% CPU (why not 100%?)
Subject says it all. On my laptop which is running 2.4.0, while the machine is completely idle "top" reports kapm-idled as usin about 45% of the CPU. The remaining 55% is reported as idle time. When the machine gets a little more active, the CPU time attributed to kapm-idled decreases while the 55% idle time increases to 85%! This is not caused be "top": I get the same 45% from "ps -l 3". I remember when kapmd was reporting 100%. Is the new behaviour intentional, and is it saving the maximum power on the laptop? thanks, -- Jamie - 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: fbcon slowness [was NTP on 2.4.2?]
Pavel Machek wrote: > You have same toshiba satellite as me, right? Yes. -- Jamie - 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: fbcon slowness [was NTP on 2.4.2?]
Hi! > > >Are you using fbcon? If so, and if it goes away after starting X, then it > > >is the "fbcon kills interrupt latency" problem. > > > > Ug!!! This is getting bad. Give me some time. I plan on releasing a new > > vesafb using MMX to help speed up the drawing routines. It will help alot > > with the latency issues. I also know using ARM assembly we can greatly > > reduce the latency issues. > > On console speedups: back in the old days, scrolling a subregion of the > text console to be _really_ slow on some machines. I am talking about > text mode now, not framebuffer mode. On some cards, text mode is > actually very very slow and the framebuffer is faster. It took *2 > seconds* to scroll a 50 lines of text 50 times on my 200MHz PPro system > 4 years ago. So less "back one screen" took 2 seconds. And Emacs uses > "scroll region by N lines" a lot. In those days, "N lines" scrolls > actually did N x 1 line scrolls, so text mode was really a burden on > that machine. I took to using X, with a single screen size xterm to > present the illusion of console mode. > > Well, nowadays on my laptop we have the joy of the framebuffer console. > Nice penguin aside, it means I get a console on the full screen area. > > But it is nearly as slow at scrolling as my old 200MHz PPro. You have same toshiba satellite as me, right? > Probably the lack of hardware area copies has something to do with > this. However, who isn't familiar with xterm "jump scroll" mode? > That's nice and fast. > > Could such a thing be implemented in the console driver? I believe so. It would be simple: if there's too much activit, defer framebuffer updates and only update in-memory copy. Sync from time to time. I'd certainly like to see that. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - 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: fbcon slowness [was NTP on 2.4.2?]
James Simmons wrote: > Ug!!! This is getting bad. Give me some time. I plan on releasing a new > vesafb using MMX to help speed up the drawing routines. It will help alot > with the latency issues. I also know using ARM assembly we can greatly > reduce the latency issues. There is another issue with vesafb. It tries to use an MTRR, but this fails for the 2.5MB region that is video RAM because 2.5MB is not a power of two. The console driver does not actually use 2.5MB. Does it make sense to use an MTRR for the smaller power-of-two region? -- Jamie - 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: fbcon slowness [was NTP on 2.4.2?]
Hi! > > Ug!!! This is getting bad. Give me some time. I plan on releasing a new > > vesafb using MMX to help speed up the drawing routines. It will help alot > > with the latency issues. I also know using ARM assembly we can greatly > > reduce the latency issues. > > There is another issue with vesafb. It tries to use an MTRR, but this > fails for the 2.5MB region that is video RAM because 2.5MB is not a > power of two. > > The console driver does not actually use 2.5MB. Does it make sense to > use an MTRR for the smaller power-of-two region? I had patch which tried that at one point. Just try all 2^n numbers <= size until it succeeds. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - 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: tulip (was RE: Kernel 2.4.3 fails to compile)
Jeff Garzik wrote: > On Fri, 30 Mar 2001, Manuel A. McLure wrote: > > It looks like the tulip driver isn't as up-to-date as the one from > > 2.4.2-ac20 - when is 2.4.3-ac1 due? :-) I got NETDEV > WATCHDOG errors shortly > > after rebooting with 2.4.3, although these were of the > "slow/packet lossy" > > type I got with 2.4.2-ac20 instead of the "network > completely unusable" type > > I got with 2.4.2-ac11 and earlier. > > I'm betting that the latest ac (ac28?) is broken for you, too. > > I had to revert the changes in 'ac' tulip -- they fixed Comet > and 21041 > cards, but broke some others. sigh. > > sigh. More testing and debugging for Jeffro... Comet (your chip, I > am guessing?) should be fixed ASAP, it's pretty easy. 21041 is not as > easy, but should be fixed quickly as well. Yes, mine is a Comet - here's the exact detection message: Mar 30 13:09:06 ulthar kernel: Linux Tulip driver version 0.9.14 (February 20, 2 001) Mar 30 13:09:06 ulthar kernel: PCI: Found IRQ 5 for device 00:0c.0 Mar 30 13:09:06 ulthar kernel: eth0: ADMtek Comet rev 17 at 0xb000, 00:20:78:0D: D2:E1, IRQ 5. I must say that I really appreciate the effort that all of the kernel developers put in... Thanks, -- Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]> Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." - 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: fbcon slowness [was NTP on 2.4.2?]
James Simmons wrote: > > >Are you using fbcon? If so, and if it goes away after starting X, then it > >is the "fbcon kills interrupt latency" problem. > > Ug!!! This is getting bad. Give me some time. I plan on releasing a new > vesafb using MMX to help speed up the drawing routines. It will help alot > with the latency issues. I also know using ARM assembly we can greatly > reduce the latency issues. On console speedups: back in the old days, scrolling a subregion of the text console to be _really_ slow on some machines. I am talking about text mode now, not framebuffer mode. On some cards, text mode is actually very very slow and the framebuffer is faster. It took *2 seconds* to scroll a 50 lines of text 50 times on my 200MHz PPro system 4 years ago. So less "back one screen" took 2 seconds. And Emacs uses "scroll region by N lines" a lot. In those days, "N lines" scrolls actually did N x 1 line scrolls, so text mode was really a burden on that machine. I took to using X, with a single screen size xterm to present the illusion of console mode. Well, nowadays on my laptop we have the joy of the framebuffer console. Nice penguin aside, it means I get a console on the full screen area. But it is nearly as slow at scrolling as my old 200MHz PPro. Probably the lack of hardware area copies has something to do with this. However, who isn't familiar with xterm "jump scroll" mode? That's nice and fast. Could such a thing be implemented in the console driver? cheers, -- Jamie - 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/
tulip (was RE: Kernel 2.4.3 fails to compile)
On Fri, 30 Mar 2001, Manuel A. McLure wrote: > It looks like the tulip driver isn't as up-to-date as the one from > 2.4.2-ac20 - when is 2.4.3-ac1 due? :-) I got NETDEV WATCHDOG errors shortly > after rebooting with 2.4.3, although these were of the "slow/packet lossy" > type I got with 2.4.2-ac20 instead of the "network completely unusable" type > I got with 2.4.2-ac11 and earlier. I'm betting that the latest ac (ac28?) is broken for you, too. I had to revert the changes in 'ac' tulip -- they fixed Comet and 21041 cards, but broke some others. sigh. sigh. More testing and debugging for Jeffro... Comet (your chip, I am guessing?) should be fixed ASAP, it's pretty easy. 21041 is not as easy, but should be fixed quickly as well. Jeff - 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: pcnet32 (maybe more) hosed in 2.4.3
On Fri, 30 Mar 2001, Scott G. Miller wrote: > Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in > 2.4.3, pcnet32 loads, gives an error message: hrm, can you try 2.4.2-acXX as well? I pretty much just merged pcnet32 patches from there. I should be getting a pcnet32 test card on Tuesday, maybe I can knock out the bug and avoid having to revert the merge. Regards, Jeff - 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/
Recent problems with APM and XFree86-4.0.1
Benjamin Herrenschmidt wrote: > There is a problem with the power management code for console.c > > The current code calls do_blank_screen(0); on PM_SUSPEND, and > unblank_screen() on PM_RESUME. > > The problem happens when X is the current display while putting the > machine to sleep. The do_blank_screen(0) code will do nothing as > the console is not in KD_TEXT mode. > However, unblank_screen has no such protection. That means that > on wakeup, the cursor timer & console blank timers will be re-enabled > while X is frontmost, causing the blinking cursor to be displayed on > top of X, and other possible issues. On that theme of power management with X problems, I have been having trouble with my laptop crashing when the lid is closed, instead of suspending as it used to. The laptop is a Toshiba Satellite 4070CDT. The problem appeared around the time I updated the XFree86-4 package to Red Hat 7's latest update, but I also updated to kernel 2.4.2 around the same time so I'm not sure of the cause. Until recently, closing the lid caused the machine to beep three times, sync data to disk and suspend, then opening the lid resumed. This worked with or without X displaying. Now if I switch to a text console and then suspend, it is fine. If I have X displaying, closing the lid causes the machine to beep... and beep and beep. About half the time it does suspend after many more beeps than usual (e.g. 10 seconds pass before deciding to sync to disk), and in that case it usually resumes ok but sometimes it resumes and the machine is not responding to keyboard input. When this happens, a hard reboot is required. (SysRq doesn't work). The other half of the time it just beeps repeatedly forever. Mouse input doesn't work, nor does keyboard. Curiously, SysRq-S-U-B still syncs and reboots the machine with a clean disk from this state. These effects might have something to do with APM in current kernels and/or XFree86-4.0.1-1 from Red Hat 7 updates. Has anyone observed similar recent problems? -- Jamie - 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/
oops during kfree_skbmem
I am reposting... the oops call stack didn't show up correctly. >>EIP; c012c504<= Trace; c011b77a Trace; c012c82a Trace; c01d00fd Trace; c01d024b <__kfree_skb+f3/f8> Trace; c01d0d1d Trace; c0203a61 Trace; c01cd441 Trace; c0203928 Trace; c01ce2fd The oops happened on a box running Linux 2.4.0 and libpcap-0.6.2 (which uses AF_PACKET socket). The packet received was an arp request. I have syslog indicating the kernel received the arp request. My pcap application captures arp packet as well. The calls leading to the oops : pcap_dispatch ... sys_recvfrom ... kfree_skbmem ...free_block. The oops is not recreatable on demand. However, on another box running 2.4.0-test7, there is a memory leak. Top reports memory used by my application stable at 0.3%, but system memory usage keeps going up (reaching 250M used, 4M free before staying there). Allen Lau - 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/
pcnet32 (maybe more) hosed in 2.4.3
Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in 2.4.3, pcnet32 loads, gives an error message: Mar 30 18:45:09 obsidian kernel: pcnet32_probe_pci: found device 0x001022.0x002000 Mar 30 18:45:09 obsidian kernel: ioaddr=0x00b800 resource_flags=0x000101 Mar 30 18:45:09 obsidian kernel: < Mar 30 18:45:09 obsidian kernel: 6>eth0: PCnet/FAST 79C971 at 0xb800, warning: PROM address does not match CSR address 00 00 00 00 00 00 Mar 30 18:45:09 obsidian kernel: tx_start_pt(0x0c00):~220 bytes, BCR18(9861):BurstWrEn BurstRdEn NoUFlow Mar 30 18:45:09 obsidian kernel: SRAMSIZE=0x7f00, SRAM_BND=0x3f00, Mar 30 18:45:09 obsidian kernel: pcnet32: pcnet32_private lp=c3173000 lp_dma_addr=0x3173000 assigned IRQ 5. Mar 30 18:45:09 obsidian kernel: pcnet32.c:v1.25kf 26.9.1999 [EMAIL PROTECTED] Though it does still load. However, the interface does not come up. (DHCP doesn't work, can't even assign a manual address). Worse, I get multiple entries for the driver in /proc/interrupts. Each time I attempt to bring the interface up another is added so I have: 5: 11276 11416 IO-APIC-level aic7xxx, PCnet/FAST 79C971, PCnet/FAST 79C971, PCnet/FAST 79C971 When I attempt to rmmod the driver, even if there is only one, I get a Kernel OOPS (in the interrupt handler, so it wasn't written anywhere). I'll attempt to copy it down by hand and post to the list in a bit. Scott PGP signature
[SOLVED]Re: 2.2.19 && ppa: total lockup. No problem with 2.2.17
On Fri, 30 Mar 2001, Tim Waugh wrote: > On Fri, Mar 30, 2001 at 03:55:01PM +0200, Juan Piernas Canovas wrote: > > > The kernel configuration is the same in both 2.2.17 and 2.2.19. > > Perhaps, the problem is not in the ppa module, but in the parport, > > parport_pc or parport_probe modules. > > There weren't any parport changes in 2.2.18->2.2.19, and the ones in > 2.2.17->2.2.18 won't affect you unless you are using a PCI card. > > Could you please try this patch and let me know if the behaviour > changes? > > Thanks, > Tim. > */ > > --- linux/drivers/scsi/ppa.h.eh Fri Mar 30 15:27:43 2001 > +++ linux/drivers/scsi/ppa.h Fri Mar 30 15:27:52 2001 > @@ -178,7 +178,6 @@ > eh_device_reset_handler:NULL, \ > eh_bus_reset_handler: ppa_reset, \ > eh_host_reset_handler: ppa_reset, \ > - use_new_eh_code:1, \ > bios_param: ppa_biosparam, \ > this_id:-1, \ > sg_tablesize: SG_ALL, \ > Yes!!!. It works. I am happy now :-) Thank you very much, Tim. Juan. - 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: How to compile linux 0.0.0.1?
On Sat, 31 Mar 2001, Dr S.M. Huen wrote: > On Fri, 30 Mar 2001, Alan Olsen wrote: > > > Yeah, but then you have to find the buffalo and that gets hard. (Actually > > Linus used a carabou, but those are even harder to find...) > > > I thought he used GNU? :-) It was out of bullocks. ]:> [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - 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: How to compile linux 0.0.0.1?
On Fri, 30 Mar 2001, Alan Olsen wrote: > On Fri, 30 Mar 2001, David Relson wrote: > > > At 03:06 PM 3/30/01, Alan Olsen wrote: > > I have a friend who's a flintknapper. He's been doing it for decades and > > does good work. I'm sure he could set you up with raw materials or with > > finished products, i.e. arrowheads, knife blades, etc. > > Yeah, but then you have to find the buffalo and that gets hard. (Actually > Linus used a carabou, but those are even harder to find...) > I thought he used GNU? :-) - 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
> Does anyone know why fualhead is not working anymore? > I just get a screen with rubbish on the second head. > Also when kernel loads and and registers fb1 I lose signal > on the second head. ... >With 2.4.2 it was working just fine. I have also noticed problems with the 2.4.3 release. I have a G450 32Mb, that I use in single-head mode. The console framebuffer runs fine at boot time, but when I load X (4.0.3 compiled with Matrox HAL library) and then return to the console, I get a blank screen (signal lost). I don't know what the problem is. I can confirm with Mythos that under 2.4.2 it was working just fine :-) Petr Vandrovec is the man who knows... what do you say Petr?! John [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: 2.4.3 aic7xxx wont compile
"Justin T. Gibbs" wrote: > > >You cannot expect that all people will instantly start using the > >latest driver from your Web site, immediately. Especially considering > > I guess I expect people posting on LK to read it. There have been > announcements for all the driver versions on that list, I've responded > to all of the threads complaining about the aicasm stuff, and > I've provided updated patches to Linus. > > I'll try the psychic waves thing. Perhaps it will help. Jeff's implied request that you send in a patch to Alan and Linus adding your contact information and development website URL to the MAINTAINERS file and your source code seems like a really good idea. Would you please do this? Miles - 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
Jeff Garzik wrote:
> On Fri, 30 Mar 2001, Manuel A. McLure wrote:
>
> > Jeff Garzik wrote:
> > > On Fri, 30 Mar 2001, Manuel A. McLure wrote:
> > >
> > > > ...
> > > > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall
> > > -Wstrict-prototypes -O2
> > > > -fomit-frame-pointer -fno-strict-aliasing -pipe
> > > -mpreferred-stack-boundary=2
> > > > -march=athlon -DMODULE -DMODVERSIONS -include
> > > > /usr/src/linux/include/linux/modversions.h -c -o buz.o buz.c
> > > > 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) {
> > > ...
> > > }
> >
> > Thanks, I'll do that. It just seemed strange that the file was being
> > compiled in the first place when the config option was not set.
>
> buz is built with CONFIG...ZORAN as well as CONFIG...BUZ. I dunno if
> that's a bug or not...
Yeah - I figured that out. I found that there were many places where
KMALLOC_MAXSIZE was being used in buz.c so I removed CONFIG...ZORAN and the
kernel is working now.
It looks like the tulip driver isn't as up-to-date as the one from
2.4.2-ac20 - when is 2.4.3-ac1 due? :-) I got NETDEV WATCHDOG errors shortly
after rebooting with 2.4.3, although these were of the "slow/packet lossy"
type I got with 2.4.2-ac20 instead of the "network completely unusable" type
I got with 2.4.2-ac11 and earlier.
--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. Good."
-
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 port latency
Hi! > > > Is the computer otherwise idle? > > > I've seen one unexplainable report with atm problems that > disappeared > > > (!) if a kernel compile was running. > > > > I've seen similar bugs. If you hook something on schedule_tq and > forget > > to set current->need_resched, this is exactly what you get. > > > I'm running with a patch that printk's if cpu_idle() is called while a > softirq is pending. > If I access the floppy on my K6/200 every track triggers the check, and > sometimes the console blanking code triggers it. Seems floppy and console is buggy, then. > What about creating a special cpu_is_idle() function that the idle > functions must call before sleeping? I'd say just fix all the bugs. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - 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 Summit info?
On Fri, Mar 30, 2001 at 01:01:09PM -0800, Torrey Hoffman wrote: > However... for those of us who are curious, is there a web site somewhere > with information about the goings-on? What would be really nice is web cams, > or a RealAudio feed from the meetings. There isn't anything being broadcast on the web at the moment, but after the meeting, webcasts should be available on the net. I believe that they'll be up around 10th April. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] multiline string cleanup
Hi, kernel developers.
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 have not tested the changes with older binutils, as Alan suggested, but
the changes are made following other __asm__ pieces in the kernel. They
build with gcc-3.0-20010326 snapshot and binutils-2.10.1.0.2.
BTW, I have a doubt: as assembler is written in the rest of kernel (get,
for example, system.h):
static inline unsigned long _get_base(char * addr)
{
unsigned long __base;
__asm__("movb %3,%%dh\n\t"
"movb %2,%%dl\n\t"
"shll $16,%%edx\n\t"
"movw %1,%%dx"
:"=" (__base)
:"m" (*((addr)+2)),
"m" (*((addr)+4)),
"m" (*((addr)+7)));
return __base;
}
the first asm line is not tabbed, the result is:
movb %3,%%dh
movb %2,%%dl
shll $16,%%edx
movw %1,%%dx
so is really format (tabs) so important ?
Patch inlined
=== patch-mls
--- linux-2.4.3/include/asm-i386/checksum.h.origFri Mar 30 23:13:22 2001
+++ linux-2.4.3/include/asm-i386/checksum.h Fri Mar 30 23:24:04 2001
@@ -69,25 +69,24 @@
unsigned int ihl) {
unsigned int sum;
- __asm__ __volatile__("
- movl (%1), %0
- subl $4, %2
- jbe 2f
- addl 4(%1), %0
- adcl 8(%1), %0
- adcl 12(%1), %0
-1: adcl 16(%1), %0
- lea 4(%1), %1
- decl %2
- jne 1b
- adcl $0, %0
- movl %0, %2
- shrl $16, %0
- addw %w2, %w0
- adcl $0, %0
- notl %0
-2:
- "
+ __asm__ __volatile__(
+ "movl (%1), %0\n\t"
+ "subl $4, %2\n\t"
+ "jbe 2f\n\t"
+ "addl 4(%1), %0\n\t"
+ "adcl 8(%1), %0\n\t"
+ "adcl 12(%1), %0\n"
+ "1:\tadcl 16(%1), %0\n\t"
+ "lea 4(%1), %1\n\t"
+ "decl %2\n\t"
+ "jne1b\n\t"
+ "adcl $0, %0\n\t"
+ "movl %0, %2\n\t"
+ "shrl $16, %0\n\t"
+ "addw %w2, %w0\n\t"
+ "adcl $0, %0\n\t"
+ "notl %0\n"
+ "2:"
/* Since the input registers which are loaded with iph and ipl
are modified, we must also specify them as outputs, or gcc
will assume they contain their original values. */
@@ -102,10 +101,9 @@
static inline unsigned int csum_fold(unsigned int sum)
{
- __asm__("
- addl %1, %0
- adcl $0x, %0
- "
+ __asm__(
+ "addl %1, %0\n\t"
+ "adcl $0x, %0"
: "=r" (sum)
: "r" (sum << 16), "0" (sum & 0x)
);
@@ -118,12 +116,11 @@
unsigned short proto,
unsigned int sum)
{
-__asm__("
- addl %1, %0
- adcl %2, %0
- adcl %3, %0
- adcl $0, %0
- "
+__asm__(
+ "addl %1, %0\n\t"
+ "adcl %2, %0\n\t"
+ "adcl %3, %0\n\t"
+ "adcl $0, %0"
: "=r" (sum)
: "g" (daddr), "g"(saddr), "g"((ntohs(len)<<16)+proto*256), "0"(sum));
return sum;
@@ -158,19 +155,18 @@
unsigned short proto,
unsigned int sum)
{
- __asm__("
- addl 0(%1), %0
- adcl 4(%1), %0
- adcl 8(%1), %0
- adcl 12(%1), %0
- adcl 0(%2), %0
- adcl 4(%2), %0
- adcl 8(%2), %0
- adcl 12(%2), %0
- adcl %3, %0
- adcl %4, %0
- adcl $0, %0
- "
+ __asm__(
+ "addl 0(%1), %0\n\t"
+ "adcl 4(%1), %0\n\t"
+ "adcl 8(%1), %0\n\t"
+ "adcl 12(%1), %0\n\t"
+ "adcl 0(%2), %0\n\t"
+ "adcl 4(%2), %0\n\t"
+ "adcl 8(%2), %0\n\t"
+ "adcl 12(%2), %0\n\t"
+ "adcl %3, %0\n\t"
+ "adcl %4, %0\n\t"
+ "adcl $0, %0"
: "=" (sum)
: "r" (saddr), "r" (daddr),
"r"(htonl(len)), "r"(htonl(proto)), "0"(sum));
--- linux-2.4.3/include/asm-i386/floppy.h.orig Fri Mar 30 23:24:25 2001
+++ linux-2.4.3/include/asm-i386/floppy.h Fri Mar 30 23:32:36 2001
@@ -75,28 +75,28 @@
#ifndef NO_FLOPPY_ASSEMBLER
__asm__ (
- "testl %1,%1
- je 3f
-1: inb %w4,%b0
- andb $160,%b0
- cmpb $160,%b0
- jne 2f
- incw %w4
- testl %3,%3
- jne 4f
- inb %w4,%b0
- movb %0,(%2)
- jmp 5f
-4: movb (%2),%0
- outb %b0,%w4
-5: decw %w4
- outb %0,$0x80
- decl %1
- incl %2
- testl
Re: Kernel Summit info?
On Fri, 30 Mar 2001, Torrey Hoffman wrote: > However... for those of us who are curious, is there a web site somewhere > with information about the goings-on? What would be really nice is web cams, > or a RealAudio feed from the meetings. I don't have specific info, but the meetings are being webcast.. Jeff - 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/
max_sector support for scsi in 2.4.3??
In 2.4.2-ac9, max_sectors support was added to the SCSI midlayer. I was somewhat expecting to see that make it into 2.4.3, but it seems not. Can anyone shed some light on why? thanks - jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel 2.4.3 fails to compile
On Fri, 30 Mar 2001, Manuel A. McLure wrote:
> Jeff Garzik wrote:
> > On Fri, 30 Mar 2001, Manuel A. McLure wrote:
> >
> > > ...
> > > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall
> > -Wstrict-prototypes -O2
> > > -fomit-frame-pointer -fno-strict-aliasing -pipe
> > -mpreferred-stack-boundary=2
> > > -march=athlon -DMODULE -DMODVERSIONS -include
> > > /usr/src/linux/include/linux/modversions.h -c -o buz.o buz.c
> > > 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) {
> > ...
> > }
>
> Thanks, I'll do that. It just seemed strange that the file was being
> compiled in the first place when the config option was not set.
buz is built with CONFIG...ZORAN as well as CONFIG...BUZ. I dunno if
that's a bug or not...
Jeff
-
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 Summit info?
http://lwn.net/2001/0329/kernel.php3 The LWN kernel editor will apparently be doing some reporting for the event. On Fri, Mar 30, 2001 at 01:01:09PM -0800, Torrey Hoffman wrote: > > Is anything like that available? I'm really hoping that some of the people > present at least post summaries about what the topics of discussion were, > what options were looked at, and what decisions were made. Are any > journalists there? > > Thanks. > > Torrey Hoffman > [EMAIL PROTECTED] > > -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [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: How to compile linux 0.0.0.1?
On Fri, 30 Mar 2001, Alan Olsen wrote: > On Fri, 30 Mar 2001, David Relson wrote: > >> At 03:06 PM 3/30/01, Alan Olsen wrote: >>>On Fri, 30 Mar 2001, Bruno Avila wrote: >>> I can't find this anywhere. What is the version of the tools to compile linux kernel 0.0.0.1 (../Historic)? And where can i find them? >>> >>>Well, first you have to find a good source of obsidean, a >>> couple of sharp rocks, and some flint... >> >> I have a friend who's a flintknapper. He's been doing it >> for decades and does good work. I'm sure he could set you >> up with raw materials or with finished products, i.e. >> arrowheads, knife blades, etc. > > Yeah, but then you have to find the buffalo and that gets > hard. (Actually Linus used a carabou, but those are even > harder to find...) Well, I remember back to 0.12ish and the Caribou around here (Alaska) were plentiful then. Ah, those were the days. I did find my 0.95 disk the other day (Yggdrasil distro) and toyed with the idea of installing it, just to see how much things had really changed. But i don't have anything pre-80686 :-( - 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
Dualhead is not working with the current kernel(2.4.3). With 2.4.2 it was working just fine. I have not used any special compiler flags,just the usual ones and I am not loading XFree. Also does anyone know why when I change from Xfree to console most of the times the console is corrupted..? This is a problem which I have noticed from Xfree-4.0 and after. Thanks in advance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Summit info?
One of the reasons I read the kernel mailing list is that it's educational and fascinating to see the discussion between the kernel developers. This weekend (including today) many of the well known Linux developers are at the kernel summit meeting. I'm sure that having a face to face meeting like that is a great way to get a lot of work done quickly, and make some of the difficult decisions. I don't begrudge the developers for having a meeting like that. I don't even mind that it's invitation only. That was probably the only efficient way to organize it. However... for those of us who are curious, is there a web site somewhere with information about the goings-on? What would be really nice is web cams, or a RealAudio feed from the meetings. Is anything like that available? I'm really hoping that some of the people present at least post summaries about what the topics of discussion were, what options were looked at, and what decisions were made. Are any journalists there? Thanks. Torrey Hoffman [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: problem in drivers/block/Config.in
On Fri, Mar 30, 2001 at 10:17:08PM +0200, Herbert Rosmanith wrote: > why not simply write: > > define_bool CONFIG_PARIDE_PARPORT $CONFIG_PARPORT > > instead? Because it isn't that simple. PARIDE works with parport, or without parport, but if parport is a module then PARIDE must be configured as modules too. I'm planning on changing that in the next development cycle so that PARIDE just depends on parport and that's it. Tim. */ PGP signature
Re: How to compile linux 0.0.0.1?
On Fri, 30 Mar 2001, David Relson wrote: > At 03:06 PM 3/30/01, Alan Olsen wrote: > >On Fri, 30 Mar 2001, Bruno Avila wrote: > > > > >I can't find this anywhere. What is the version of the tools to > > > compile linux kernel 0.0.0.1 (../Historic)? And where can i find them? > > > >Well, first you have to find a good source of obsidean, a couple of sharp > >rocks, and some flint... > > I have a friend who's a flintknapper. He's been doing it for decades and > does good work. I'm sure he could set you up with raw materials or with > finished products, i.e. arrowheads, knife blades, etc. Yeah, but then you have to find the buffalo and that gets hard. (Actually Linus used a carabou, but those are even harder to find...) [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - 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 Fri, 30 Mar 2001, mythos wrote: > Does anyone know why fualhead is not working anymore? > I just get a screen with rubbish on the second head. > Also when kernel loads and and registers fb1 I lose signal > on the second head. Probably a question for the xpert list ([EMAIL PROTECTED])... What kernel version are you using? Kernel compile options? Version of XFree86? Have to looked for error messages in /var/log/XFree86.0.log? [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - 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/
problem in drivers/block/Config.in
hi, I noticed that the option CONFIG_PARIDE_PARPORT will always be "y", even if CONFIG_PARIDE_PARPORT="n". I checked with kernels 2.2.18 and 2.2.19. the file responsible is "drivers/block/Config.in", around line 126. it reads: # PARIDE doesn't need PARPORT, but if PARPORT is configured as a module, # PARIDE must also be a module. The bogus CONFIG_PARIDE_PARPORT option # controls the choices given to the user ... if [ "$CONFIG_PARPORT" = "y" -o "$CONFIG_PARPORT" = "n" ] ; then define_bool CONFIG_PARIDE_PARPORT y else define_bool CONFIG_PARIDE_PARPORT m fi so, as you can see, CONFIG_PARIDE_PARPORT will be set to "yes" even if CONFIG_PARPORT="no". why not simply write: define_bool CONFIG_PARIDE_PARPORT $CONFIG_PARPORT instead? regards, herbert rosmanith [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: [PATCH for 2.5] preemptible kernel
In message <[EMAIL PROTECTED]> you write:
> Here is an attempt at a possible version of synchronize_kernel() that
> should work on a preemptible kernel. I haven't tested it yet.
It's close, but...
Those who suggest that we don't do preemtion on SMP make this much
easier (synchronize_kernel() is a NOP on UP), and I'm starting to
agree with them. Anyway:
> if (p->state == TASK_RUNNING ||
> (p->state == (TASK_RUNNING|TASK_PREEMPTED))) {
> p->flags |= PF_SYNCING;
Setting a running task's flags brings races, AFAICT, and checking
p->state is NOT sufficient, consider wait_event(): you need p->has_cpu
here I think. You could do it for TASK_PREEMPTED only, but you'd have
to do the "unreal priority" part of synchronize_kernel() with some
method to say "don't preempt anyone", but it will hurt latency.
Hmmm...
The only way I can see is to have a new element in "struct
task_struct" saying "syncing now", which is protected by the runqueue
lock. This looks like (and I prefer wait queues, they have such nice
helpers):
static DECLARE_WAIT_QUEUE_HEAD(syncing_task);
static DECLARE_MUTEX(synchronize_kernel_mtx);
static int sync_count = 0;
schedule():
if (!(prev->state & TASK_PREEMPTED) && prev->syncing)
if (--sync_count == 0) wake_up(_task);
synchronize_kernel():
{
struct list_head *tmp;
struct task_struct *p;
/* Guard against multiple calls to this function */
down(_kernel_mtx);
/* Everyone running now or currently preempted must
voluntarily schedule before we know we are safe. */
spin_lock_irq(_lock);
list_for_each(tmp, _head) {
p = list_entry(tmp, struct task_struct, run_list);
if (p->has_cpu || p->state == (TASK_RUNNING|TASK_PREEMPTED)) {
p->syncing = 1;
sync_count++;
}
}
spin_unlock_irq(_lock);
/* Wait for them all */
wait_event(syncing_task, sync_count == 0);
up(_kernel_mtx);
}
Also untested 8),
Rusty.
--
Premature optmztion is rt of all evl. --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: Kernel 2.4.3 fails to compile
Jeff Garzik wrote:
> On Fri, 30 Mar 2001, Manuel A. McLure wrote:
>
> > ...
> > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall
> -Wstrict-prototypes -O2
> > -fomit-frame-pointer -fno-strict-aliasing -pipe
> -mpreferred-stack-boundary=2
> > -march=athlon -DMODULE -DMODVERSIONS -include
> > /usr/src/linux/include/linux/modversions.h -c -o buz.o buz.c
> > 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) {
> ...
> }
Thanks, I'll do that. It just seemed strange that the file was being
compiled in the first place when the config option was not set.
--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. Good."
-
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: memcpy in 2.2.19
Keith Owens <[EMAIL PROTECTED]> said: > On Fri, 30 Mar 2001 08:04:17 +0100, > "Chris Funderburg" <[EMAIL PROTECTED]> wrote: > >drivers/scsi/scsi.a(aic7xxx.o): In function `aic7xxx_load_seeprom': > >aic7xxx.o(.text+0x116bf): undefined reference to `memcpy' > Under some circumstances gcc will generate an internal call to > memcpy(). Alas this bypasses the pre-processor so memcpy is not > converted to the kernel's internal memcpy code. The cause is normally > a structure assignment, probably this line. > > struct seeprom_config *sc = (struct seeprom_config *) scarray; Just a pointer initialization. [...] > The other possibility I can see is > > p->sc = *sc; > > try > > memcpy(&(p->sc), sc, sizeof(*sc)); -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vmtime and vm balancing
Hi, I installed this patch onto one of my pop3/imap servers in my farm, and it crashed pretty hard today. I didn't get any crash data though, another admin rebooted it. This was after approx. 24 hours uptime. My service log shows load went absolutely through the roof, as high as 214, but memory never got above 88%. I will give it another try on Monday, I don't want any weekend issues to come up. Josh --- Josh Grebe Senior Unix Systems Administrator Primary Network, an MPower Company http://www.primary.net On Tue, 27 Mar 2001, Ed Tomlinson wrote: > Hi, > > The following patch introduces the idea of vmtime. vmtime is time as the > vm percieves it. Its advanced by memory pressure, which in the end, works > out to be the page allocation & reclaim rate. With this figure I attempt to solve > two problems. > > First I slow down the background page scanning to the rate we are allocating > pages. This means that an idle machine will not end up with all page ages > equal nearly as quickly. It should also help prevent cases where kswapd > eats too much cpu. The other effect should be to prevent or reduce some > swap out spikes. > > Second, I add some slab cache pressure. Without the patch the icache and > dcache will get shrunk in under extreme cases. From comments on mm > list (and personal experience) the slab cache can grow and end up causing > paging when it would make more sense to just shrink it. This also has > oom implications since the size of the slab cache, and the possible space > we can free from it, are not accounted for in the oom test. In any case > the patch should help keep this storage under control. Are there any other > parts of the slab cache we should think about shrinking? > > This has survived the night on my box with printk(s) in the if(s) to verify > its actually working. It should apply to pre8 and ac25/ac26. The vmscan.c > change made by ac26 should not hurt this patch but may make it age > pages a bit more aggressivily. > > We need to find out if this helps. Reports on what effect this has would > be very welcome. Rik has looked at the patch and wants to see some > feedback... > > Comments on style or bugs very welcome. > [patch removed] - 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
On Fri, 30 Mar 2001, Manuel A. McLure wrote:
> ...
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
> -march=athlon -DMODULE -DMODVERSIONS -include
> /usr/src/linux/include/linux/modversions.h -c -o buz.o buz.c
> 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) {
...
}
-
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: Memory leak in the ramfs file system
Hi, After testing with patch-2.4.2-ac28, the df commands works fine on a dir mounted as ramfs. Also, it recognizes the limits set, etc. Thanks to David Gibson, Alan and others for making this available. Regards Amit - 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/
Issue with console on non-sequential BIOS serial port
There appears to be a device naming inconsistancy with the BIOS-handled serial ports. I'm not enough of a C coder to narrow it down, but in terms of observed behaviour, it appears that there is a hard-coded mapping between the four BIOS serial ports and four device nodes (ttyS0[0-3]), which does not appear to be followed by devfs. My hardware: TMC dual socket 7 board, PIIX3 controller. The two onboard ports are set to BIOS [com1:] and [com3:]. I also have a two-port ISA serial card set to non-BIOS IO ports. The onboard port hardware does allow interrupt sharing. The onboard ports are assigned to /dev/tts/0 and /dev/tts/1, and I have the other two mapped with setserial to /dev/tts/2 and /dev/tts/3. Now I put a serial console on the second port. I put a getty on /dev/tts/1 in inittab, but at this point I discover that I have to pass console=ttyS2, to the kernel. Seems to work okay, until setserial opens the serial device nodes, and the serial console is overwritten with a single repeating character. This happens until the getty is spawned, and the serial console appears to go back to normal: I start to see console messages on it again. My question is, what is the best way to resolve this inconsistancy? I really can't change the serial port configuration, since I don't have any free interrupts left to unshare the serial port (well, there IS irq 6, but I can't put anything on that). I also can't use serial port 0 because of cable limitations. Could the serial code be changed to sequentially enumerate the BIOS ports, instead of hard-mapping them? Or, (I think this might be a better solution) specify the serial console port directly by IO address and IRQ, then switch it to the correct device node once serial ports are initialised? -- Ferret (who just has to do the weirdest things to his hardware) - 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: RTL8139 conflicting with hard drive?
On Fri, Mar 30, 2001 at 08:52:08AM -0500, Tim Coleman wrote: > I'm having a problem with a NIC I tried to install this morning. > The chip on the NIC says its an RTL-8139B (it's a generic brand > NIC, and I didn't really need anything fancy). > > When I install the NIC, and try to boot, the kernel complains > about not being able to find the root device. If I take it out, > everything is fine. I'm using kernel version 2.4.1, and my > motherboard is an Asus A7V. > > I already have one RTL-8139B NIC installed, and it's just fine. > > I also noticed that the kernel seemed to detect it as an IDE > controller, because two more IDE devices showed up in the boot > messages. > > What could cause this? More importantly, what's a good remedy? Sorry about posting that. I figured out what I was doing wrong, and everything works now. The new NIC I put in was stealing the hardware addresses used by my IDE controller. A change to lilo.conf fixed everything. -- Tim Coleman <[EMAIL PROTECTED]> [43.28 N 80.31 W] Software Developer/Systems Administrator/RDBMS Specialist/Linux Advocate University of Waterloo Honours Co-op Combinatorics & Optimization "Go to Heaven for the climate, Hell for the company." -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange lines in dmesg
Na, thats ok, that's just a dumping of debug info :) Not to worry. On Fri, 30 Mar 2001, Denis Perchine wrote: > Hello, > > I got the following lines in dmesg: > > freesibling > task PCstack pid father child younger older > init S C144DF28 4912 1 0 840 (NOTLB) > Call Trace: [] [] [] [] [] > [] > keventd S 6020 2 1(L-TLB) 3 > Call Trace: [] [] > kswapdS C1455FAC 5812 3 1(L-TLB) 4 2 > Call Trace: [] [] [] [] [] > kreclaimd S 0286 6316 4 1(L-TLB) 5 3 > Call Trace: [] [] [] > bdflush S C145 5972 5 1(L-TLB) 6 4 > Call Trace: [] [] > kupdated S C147FFC8 6296 6 1(L-TLB) 197 5 > > And more for other processes. > > As far as I can understand lines containing 'Call Trace' are printed in > trap.c in show_trace function. Does anyone know what this thing can mean, and > how to found a real reason? > > Problem is that on this machine I have install 2.3.2-ac26 + Morton's patch to > allow very large processes not be killed when there are not reused pages in > swap, etc. > > My sci advisor have real problem as his process beying killed when reached > 960Mb. There is 256Mb of RAM in machine, and 1.5Gb of swap... It looks like > it is again a problem with kernel does not use all possibilities before kill > a process. > > And what worries me is that I found mentioned above lines in kernel log. > > -- > Sincerely Yours, > Denis Perchine > > -- > E-Mail: [EMAIL PROTECTED] > HomePage: http://www.perchine.com/dyp/ > FidoNet: 2:5000/120.5 > -- > - > 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: Cool Road Runner
Steffen Gruenwald writes: > The CompactFlash disk (a 32 MB SanDisk) is recognized as /dev/hda, > but the system fails to see the /dev/hdb disk (an IBM DARA-206000 > jumpered as slave). When the IDE driver loads, it displays > hda:pio, hdb:DMA - and yes, the BIOS assigns UDMA33 to the slave drive > while the master is detected as Mode1. > The IDE controller is a CS5530. This was just discussed this week by Andre Hedrick. You need to add a mount option like "hdb=flash" (I wasn't paying much attention). This is because CF disks do not properly handle detection of slaves. See: http://marc.theaimsgroup.com/?l=linux-kernel=98580536318380=4 Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
>You cannot expect that all people will instantly start using the >latest driver from your Web site, immediately. Especially considering I guess I expect people posting on LK to read it. There have been announcements for all the driver versions on that list, I've responded to all of the threads complaining about the aicasm stuff, and I've provided updated patches to Linus. I'll try the psychic waves thing. Perhaps it will help. -- 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: 2.4.3 aic7xxx wont compile
On Fri, 30 Mar 2001, Justin T. Gibbs wrote: > > Yes, "-I." from gcc flags. > > > > The sad part is that people have been patching right and left to get > > that monster utility to compile because the dependencies say that it > > must be used to remake the AIC sequencer binary image; which image is > > perfectly ok except of its timestampts due to patching process. > > 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. You cannot expect that all people will instantly start using the latest driver from your Web site, immediately. Especially considering 1) There is no MAINTAINERS entry listing you or your web site 2) Your e-mail address is nowhere to be found in the code 3) The driver Web site address is nowhere to be found in the code 4) People are used to getting aic7xxx out of the kernel tarball Are people just supposed to pick up your psychic waves? :) Jeff - 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 still doesn't see my Xircom CardBus modem
On Fri, 30 Mar 2001, Alessandro Suardi wrote: > Just in case people forgot... (serial.c still not detecting my card). > > As always, available for tests/patches/whatever. Thanks & ciao, Haven't forgotten, just need to figure out how generic the fix needs to be ... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA problems on IBM ThinkPad 600X
On Fri, 30 Mar 2001, Anton Safonov wrote: > Hi! > > I have a problem with PCMCIA support on this IBM ThinkPad 600X. > > kernel - 2.4.2 + patch-2.4.3-pre4 > pcmcia-cs - 3.1.25 (also tried with 3.1.23) > > Then I insert a card (I'm trying now with two cards: 3COM 3CCFE575CT, > D-Link DFE-680TX) the computer beeps and responds with: > "cs: socket X timed out during reset" > > > kernel config file is following: > > # > # PCMCIA/CardBus support > # > CONFIG_PCMCIA=m > CONFIG_CARDBUS=y > CONFIG_I82365=y > CONFIG_TCIC=y If you have CardBus support, do -not- define CONFIG_I82365 or CONFIG_TCIC. Jeff - 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: Incorrect mdelay() results on Power Managed Machines x86
I'm not sure what you mean by well-defined. Do you mean, does it have a fixed address? No, it is relocatable. The ACPI driver can find it because the base address is specified in the ACPI tables. After the ACPI driver is loaded the driver could export a pmtimer read function. This is great except that anything before ACPI load would be out of luck. After reading a chipset datasheet (in this case for the ICH-2M) both the 8254 timers and the PM timer are driven off a 14.31818 MHz clock input - the PM timer is that divided by 4 and the 8254 is that divided by 12. Is there any way we could use the 8254 timer for a reliable udelay? Not as accurate, but no ACPI dependency. Regards -- Andy > From: Alan Cox [mailto:[EMAIL PROTECTED]] > > I know on ACPI systems you are guaranteed a PM timer > running at ~3.57 Mhz. > > Could udelay use that, or are there other timers that are > better (maybe > > without the ACPI dependency)? > > We could use that if ACPI was present. It might be worth > exploring. Is this > PM timer well defined for accesses ? - 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
On Fri, Mar 30, 2001 at 05:59:00PM +0200, Steffen Grunewald wrote: > Hi all, > > we're trying to get a Cool Road Runner board by Lippert (see > http://www.emjembedded.com/products/single/coolroadr.html) > to run under Linux (SuSE 6.4, kernel 2.2.14). > well looking at that page, there's a linux link to http://www.whitedwarflinux.org which looks like a distro specific to this board... you may want to try this out before continuing on as it is considered an embedded system and they appear to have their own open source patches for 2.2.14 -- .oO Gnea [gnea at rochester dot rr dot com] Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish." -unknown - 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: IP layer bug?
Hello! >For now I workarounded it with filling skb->cb with zeroes before >netif_rx(), This is right. For another examples look into tunnels. > but I believe it is a kludge and networking layer should be fixed instead. No. alloc_skb() creates skb with clean cb. ip_rcv() and other protocol handlers do not redo this work. If device uses cb internally, it must clear it before handing skb to netif_rx(). Alexey - 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 apm code (PR#128)
[EMAIL PROTECTED] writes: [...] > > AFAICS. I hacked together the following patch for it a while ago, > > which updated APM_IOC_REJECT for slightly more recent kernels (be > > warned, I think I made some mistakes) > > Thanks for this, I will review it and post a patch based on it (with > due accredition of course). Not sure that would be an altogether good idea, because I think I made a bit of a hash of it ;-) Did you get Albert Cranford's version? I would recommend it over mine (though I have not yet looked at it). [...] > I did not say the I did not "like the idea of me implementing it, as > some people at linuxcare (including Stephen) want to do it > differently themselves". I did interpolate the connection between these two clauses. If it truely did not exist, I apologise. > What I said the first time was that I preferred the idea of a user > mode daemon interacting with the kernel not the kernel forking and > execing a new process for every event. This has nothing to do with the interface presented to the APM driver. [...] > It is important when implementing an API (and that is what we are > doing) to try to get it as right and stable as possible because > other developers do not like interfaces changing ... Maybe this is true in general but in this particular case the "API" has only one user at the moment, which is APM, so it is hardly a fully fledged abstraction layer. Do you argue that the current pm_send_all interface is superior to the one in my patch? [...] -- http://www.penguinpowered.com/~vii - 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: still experiencing APIC-related hangs
On Fri, Mar 30, 2001 at 02:32:24PM +0200, Frank de Lange wrote:
> Hi'all,
>
> Subject says it all: 2.4.3 (unpatchaed) is still causing the dreaded
> APIC-related hangs on SMP BX systems (Abit BP-6, maybe Gigabyte). I still need
> to apply one of Maciej's patches to get rid of these hangs. The source comments
> in arc/i386/kernel/apic.c ("If focus CPU is disabled then the hang goes away")
> are incorrect, as the hang does not go away by simply disabling focus CPU. The
> only way for me to get rid of the hangs is to apply patch-2.4.1-io_apic-46
> (which does the LEVEL->EDGE->LEVEL triggered trick to 'free' the IO_APIC). I've
> been running with this patch for quite some time now, and have not experienced
> any problems with it. Maybe it it time to include it in the main kernel,
> perhaps as a configurable option ("BROKEN_IO_APIC")?
>
> Maciej, did you submit the patch to Linus? It really seems to solve the
> (occurence of the) problems with these boards...
Where is this patch found? I am not seeing it so far on kernel.org.
-- Ferret
-
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: still experiencing APIC-related hangs
On Fri, Mar 30, 2001 at 08:32:39AM -0800, [EMAIL PROTECTED] wrote:
> On Fri, Mar 30, 2001 at 02:32:24PM +0200, Frank de Lange wrote:
> >
> > Maciej, did you submit the patch to Linus? It really seems to solve the
> > (occurence of the) problems with these boards...
>
> Where is this patch found? I am not seeing it so far on kernel.org.
It is allmost ancient history, from days long gone when men were men, women
were women and Linux had only reached 2.4.1...
I can send you a copy, if you need it...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
-
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: still experiencing APIC-related hangs
On Fri, 30 Mar 2001, Frank de Lange wrote: > Maciej, did you submit the patch to Linus? It really seems to solve the > (occurence of the) problems with these boards... I suppose Alan is going to pass the patch to Linus eventually. I think there is actually a number of people interested in the fix, so I may pass it to Linus independently, but I'm really time-constrained these days, so it might not happen before 2.4.3 (I don't feel safe about submitting a patch without actually run-time testing it against whatever test kernel is current at the moment). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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/
Cool Road Runner
Hi all, we're trying to get a Cool Road Runner board by Lippert (see http://www.emjembedded.com/products/single/coolroadr.html) to run under Linux (SuSE 6.4, kernel 2.2.14). The CompactFlash disk (a 32 MB SanDisk) is recognized as /dev/hda, but the system fails to see the /dev/hdb disk (an IBM DARA-206000 jumpered as slave). When the IDE driver loads, it displays hda:pio, hdb:DMA - and yes, the BIOS assigns UDMA33 to the slave drive while the master is detected as Mode1. The IDE controller is a CS5530. Is there a chance that a newer kernel will detect the second disk? If I disconnect the slave drive, I can see "hdb:pio" :-((( but not the drive, of course B-) Any ideas? Steffen -- Steffen Grunewald | GFZ | PB 2.2 | Telegrafenberg E3 | D-14473 Potsdam » email: steffen(at)gfz-potsdam.de | fax/fon: +49-331-288-1266/-1245 « It has just been discovered that research causes cancer in rats. - 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.2 cs4232 is not SMP safe
Olaf Hering wrote: > > On Wed, Mar 28, Alan Cox wrote: > > > > But it still jumps into xmon. How can we make that driver SMP safe? > > > There is no maintainer address in the files. > > > > CS4232 has no maintainer. I've had no SMP x86 problems reported with it for > > a long time but that may be chance > > Well, the alsa driver loads but it can not play sound, all you get is a > strange noise. The same driver (alsa/kernel) works on a UP ppc machine > (a B50). I will try to get an UP kernel for that machine, it worked once > around 2.4.3-pre. I have been using a Dell SMB dual PII/300 box with cs4232 playing my MP3s in a loop 24x7 for nearly a year without any glitches. I have tried it with 2.2 kernels and 2.4.0. The only problem I have had with the box and sound driver was that I had to set the PCI quirks flag to 1 (thanks to Alan for pointing me to it) to keep it from crashing when playing sound and accessing the floppy (this got QUITE embarassing when I was doing some custom work for some high-level folks a while back). However, I have one beef with the driver. Each time it starts a cut, I get a loud pop from the speaker. This appears to be a startup transient and is not present on my other sound card in the box, a SoundBlaster Vibra 16. This pop happens on ANY play application, playing ANY file (esdplay, play[sox], vplay, xmms, etc.). Cheers, -- Wade Hampton - 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 in EZ-Drive remapping code (ide.c)
On Mar 30, [EMAIL PROTECTED] wrote: > So yes, the problem is known, but I do not see a clean solution, > unless the solution is to rip out all this EZ drive nonsense. Grub can already handle EZ drives itself so this would be a solution :) However, fdisk depends on the remapping. > (I can well imagine that this would happen in 2.5: > the task of the IDE driver is to transport bits from and to > the disk, not to worry about the contents.) > And even if it were fixed somehow in a 2.4 kernel, lots of > people will have a 2.2 or older system for quite some time > to come. So probably grub should regard this as a quirk in > the Linux handling of disks with EZ drive and adapt > (that is, read sector 0, and then read sectors 1-N, > but do not read 0-N). I make a patch for grub to do that. Jochen - 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/
2.4.3: INIT: PANIC: segmentation violation...
I get the message segmentation violation at XXX! sleeping for
30 seconds. with 2.4.3.
No problems with 2.4.2 and the same configuration.
Any hints ?
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
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
> Yes, "-I." from gcc flags. > > The sad part is that people have been patching right and left to get > that monster utility to compile because the dependencies say that it > must be used to remake the AIC sequencer binary image; which image is > perfectly ok except of its timestampts due to patching process. 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. -- 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: 2.4.3 aic7xxx wont compile
>Just tried to build 2.4.3, got: Grumble. Grumble. Grumble. We've been through this before. The 6.1.8 version of the driver has a fixed Makefile, doesn't even attempt to assemble the firmware unless you config your kernel to turn it on, and has been out for over a month now. I guess it will have to wait until 2.4.4. I'll post updated patches for 2.4.3 later today, but the ones for 2.4.3-pre6 should apply fine. -- 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/
[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
--- linux-2.4.2-dist/drivers/isdn/hisax/bkm_a8.cWed Nov 29 19:12:29 2000
+++ linux-2.4.2/drivers/isdn/hisax/bkm_a8.c Fri Mar 30 13:32:21 2001
@@ -205,9 +205,9 @@
void
release_io_sct_quadro(struct IsdnCardState *cs)
{
- release_region(cs->hw.ax.base & 0xffc0, 256);
+ release_region(cs->hw.ax.base & 0xffc0, 128);
if (cs->subtyp == SCT_1)
- release_region(cs->hw.ax.plx_adr, 256);
+ release_region(cs->hw.ax.plx_adr, 64);
}
static void
@@ -403,9 +403,9 @@
switch(cs->subtyp) {
case 1:
cs->hw.ax.base = pci_ioaddr5 + 0x00;
- if (sct_alloc_io(pci_ioaddr1, 256))
+ if (sct_alloc_io(pci_ioaddr1, 128))
return(0);
- if (sct_alloc_io(pci_ioaddr5, 256))
+ if (sct_alloc_io(pci_ioaddr5, 64))
return(0);
/* disable all IPAC */
writereg(pci_ioaddr5, pci_ioaddr5 + 4,
@@ -419,17 +419,17 @@
break;
case 2:
cs->hw.ax.base = pci_ioaddr4 + 0x08;
- if (sct_alloc_io(pci_ioaddr4, 256))
+ if (sct_alloc_io(pci_ioaddr4, 64))
return(0);
break;
case 3:
cs->hw.ax.base = pci_ioaddr3 + 0x10;
- if (sct_alloc_io(pci_ioaddr3, 256))
+ if (sct_alloc_io(pci_ioaddr3, 64))
return(0);
break;
case 4:
cs->hw.ax.base = pci_ioaddr2 + 0x20;
- if (sct_alloc_io(pci_ioaddr2, 256))
+ if (sct_alloc_io(pci_ioaddr2, 64))
return(0);
break;
}
Re: Bug in EZ-Drive remapping code (ide.c)
Jochen, I don't really care about Disk Overlays. However if you can fix it or if Andries can great. Sorry, On Fri, 30 Mar 2001, Jochen Hoenicke wrote: > Hello, > > The EZ-Drive remapping code remaps to many sectors, if they are read > together with sector 0 in one bunch. This is even documented: > > >From linux-2.4.0/drivers/ide/ide.c line 1165: > /* Yecch - this will shift the entire interval, >possibly killing some innocent following sector */ > > This problem hit a GRUB user using linux-2.4.2 but it exists for a > long time; the remapping code is already in 2.0.xx. The reason that > nobody cares is probably because there are only a few programs that > access /dev/hda directly. > > GRUB is a boot loader that normally runs under plain BIOS but there is > also a wrapper to run it under linux and other unixes. Because it > shares most code with its BIOS derivate it accesses the disk the hard > way, reading directly from /dev/hda and interpreting the file system > with its own (read-only) file system drivers. > > This is what happened: Grub reads the first track in one bunch and > since a track has an odd number of sectors, linux adds the first > sector of the next track to this bunch. This sector contains the boot > sector of the first FAT partition. The result of the remapping is > that grub can't access that partition. > > Please CC me on reply. > > Jochen > 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: OOM killer???
Just to throw my own observations into the war, I have to agree with David K. here. This needs to be some sort of module and/or interface. Get the policy into a replaceable user space module. One of the hot areas for the kernel right now is for embedded systems. They need an entirely different strategy than for a desk top. I'm working on such a thing now were we don't even have an enabled swap space and the OOM is causing us no end of trouble as we start dipping below 1MB "free" system memory. On 29 Mar 2001, Michael Peddemors wrote: > Looking over the last few weeks of postings, there are just WAY to many > conflicting ways that people want the OOM to work.. Although an > incredible amount of good work has gone into this, people are definetely > not happy about the benifits of OOM ... About 10 different approaches > are being made to change the rule based systems pertaining to WHEN the > OOM will fire, but in the end, still not everyone will be happy.. > On 29 Mar 2001 07:41:44 -0800, David Konerding wrote: > > > Now, if you're going to implement OOM, when it is absolutely necessary, at the very > > least, move the policy implementation out of the kernel. One of the general > > philosophies of Linux has been to move policy out of the kernel. In this case, >you'd > > just have a root owned process with locked pages that can't be pre-empted, which > > implemented the policy. You'll never come up with an OOM policy that will fit > > everybody's needs unless it can be tuned for particular system's usage, and it's > > going to be far easier to come up with that policy if it's not in the kernel. - 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.2.19 && ppa: total lockup. No problem with 2.2.17
On Fri, Mar 30, 2001 at 03:55:01PM +0200, Juan Piernas Canovas wrote: > The kernel configuration is the same in both 2.2.17 and 2.2.19. > Perhaps, the problem is not in the ppa module, but in the parport, > parport_pc or parport_probe modules. There weren't any parport changes in 2.2.18->2.2.19, and the ones in 2.2.17->2.2.18 won't affect you unless you are using a PCI card. Could you please try this patch and let me know if the behaviour changes? Thanks, Tim. */ --- linux/drivers/scsi/ppa.h.eh Fri Mar 30 15:27:43 2001 +++ linux/drivers/scsi/ppa.hFri Mar 30 15:27:52 2001 @@ -178,7 +178,6 @@ eh_device_reset_handler:NULL, \ eh_bus_reset_handler: ppa_reset, \ eh_host_reset_handler: ppa_reset, \ - use_new_eh_code:1, \ bios_param: ppa_biosparam, \ this_id:-1, \ sg_tablesize: SG_ALL, \ PGP signature
2.4.3 still doesn't see my Xircom CardBus modem
Just in case people forgot... (serial.c still not detecting my card). As always, available for tests/patches/whatever. Thanks & ciao, --alessandro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Linux: kernel 2.2.19/2.4.3p8 glibc-2.2 gcc-2.96-69 binutils-2.11.90.0.1 Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux motto: Tell the truth, there's less to remember. - 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/
tmpfs in 2.4.3 and AC
Hi, tmpfs (or shmfs or whatever name you like) is still different in official series (2.4.3) and in ac series. Its a kick in the ass for multiboot, as offcial 2.4.3 does not recognise 'tmpfs' in fstab: shmfs /dev/shmtmpfs ... Any reason, or is because it has been forgotten ? -- 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/
[PATCH] PAE zap_low_mappings no-op
i386 pgd_clear() is now a no-op with PAE as without: so zap_low_mappings() isn't zapping in the PAE case. Patch below against 2.4.3, or 2.4.2-ac28 offset 1 line. Hugh --- 2.4.3/arch/i386/mm/init.c Mon Mar 26 20:01:56 2001 +++ linux/arch/i386/mm/init.c Fri Mar 30 14:46:34 2001 @@ -309,14 +309,11 @@ * Zap initial low-memory mappings. * * Note that "pgd_clear()" doesn't do it for -* us in this case, because pgd_clear() is a -* no-op in the 2-level case (pmd_clear() is -* the thing that clears the page-tables in -* that case). +* us, because pgd_clear() is a no-op on i386. */ for (i = 0; i < USER_PTRS_PER_PGD; i++) #if CONFIG_X86_PAE - pgd_clear(swapper_pg_dir+i); + set_pgd(swapper_pg_dir+i, __pgd(1 + __pa(empty_zero_page))); #else set_pgd(swapper_pg_dir+i, __pgd(0)); #endif - 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/
2.2.19 && ppa: total lockup. No problem with 2.2.17
On Fri, 30 Mar 2001, Juan Piernas Canovas wrote: Hi!. When I execute "modprobe ppa" while running a kernel 2.2.19, my computer hangs completely. No messages. System request key does not work. The kernel configuration is the same in both 2.2.17 and 2.2.19. Perhaps, the problem is not in the ppa module, but in the parport, parport_pc or parport_probe modules. Bye! Juan. - 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/
RTL8139 conflicting with hard drive?
I'm having a problem with a NIC I tried to install this morning. The chip on the NIC says its an RTL-8139B (it's a generic brand NIC, and I didn't really need anything fancy). When I install the NIC, and try to boot, the kernel complains about not being able to find the root device. If I take it out, everything is fine. I'm using kernel version 2.4.1, and my motherboard is an Asus A7V. I already have one RTL-8139B NIC installed, and it's just fine. I also noticed that the kernel seemed to detect it as an IDE controller, because two more IDE devices showed up in the boot messages. What could cause this? More importantly, what's a good remedy? -- Tim Coleman <[EMAIL PROTECTED]> [43.28 N 80.31 W] Software Developer/Systems Administrator/RDBMS Specialist/Linux Advocate University of Waterloo Honours Co-op Combinatorics & Optimization "Go to Heaven for the climate, Hell for the company." -- Mark Twain - 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
> Linux vingeren.girl 2.4.3-pre7 #5 Mon Mar 26 23:33:59 EST 2001 i686 unknown > > EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block >1048576 > EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block >1048576 > > ^ > I got the following while rm -rf'ing my mozilla cvs checkout. Deadly or not deadly? Are you running with a Buslogic SCSI card? 2.4.x (x < 3 - pre something) has a problem with them. I was seeing exactly these sorts of errors before I went to 2.4.3 pre-8. Later, Dale -- Dale E. Martin, Clifton Labs, Inc. Senior Computer Engineer [EMAIL PROTECTED] http://www.cliftonlabs.com pgp key available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: WG: 2.4 on COMPQ Proliant
Hi, I solved the SCSI problem now - thanks for the hint to take sym53c8xx instead of ncr53c8xx. For the SMP-Problem it helped to use an option offerd at boot time: "Press F9 to select different operating system". Before I used "Minimum Configuration...", because Linux wasn't listed. After I've choosen UNIX/SCO, the SMP was detected properly. Now I have 3 of these machines, dedicated to a cluster. On the second machine, The "F9"-option is not offered! (only F10 for Partitioning Utilities - but they were not found). What option do I have now to change the settings? Is there a posibility to start something from "SmartStart" to adjust it? I've installed RedHat7 default for servers - there is no special COMPAQ-Partition on it (I'm not sure if there was before). Thx, Frank >Hello EveryBody, > I have a COMPAQ ML570 (2xPIII-700Mhz/1MBytes Cache, 2 x NCR SCSI controller= > ,=20 > 1 SMART ARRAY 5304 (128 MBytes Cache). I test with linux 2.4.2-ac20, and al= > l=20 > disks, CPU's and memory have been detected by the KERNEL. > See your BIOS Version, My COMPAQ has BIOS P20 01/21/2001, I download from=20 > compaq.com > > Andre Margis Em Quinta 29 Mar=E7o 2001 20:02, Mr. James W. Laferriere escreveu: > Hello Frank , Highly recommend the sym53c* . JimL > > On Thu, 29 Mar 2001, Butter, Frank wrote: > > 2.2.16 claimes to find a ncr53c1510D-chipset, supported by > > the driver ncr53c8xx. Which kernel-param would be the correct one for > > this? Frank > > > > > -Urspr=FCngliche Nachricht- > > > Von: Butter, Frank > > > Gesendet: Donnerstag, 29. M=E4rz 2001 17:11 > > > An: '[EMAIL PROTECTED]' > > > Betreff: 2.4 on COMPQ Proliant > > > Has anyone experiences with 2.4.x on recent Compaq Proliant > > > Servers (e.g. ML570)? > > > > > > I've installed RedHat7 and it worked fine out of the box. > > > Except that the SMP-enabled kernel stated there was no > > > SMP-board detected ;-/ > > > For some reasons (Fibrechannel drivers and so on) I've compiled > > > 2.4.2 and installed it. Although I've compiled the support > > > in, the NCR-SCSI-chip was not found and therefore no > > > root-partition. It is a model supported by 53c8xx - detected > > > by the original RedHat-kernel. > > > > > > For testing I compiled a kernel with all (!) scsi-low-level-drivers - > > > with the same result. The SMP-board also was NOT detected by 2.4.2. > > > > > > Any hint? > > > > > > Frank - 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/
ide_cs post 2.4.1
On my laptop, a Fujitsu B110, I have started having trouble with the ide_cs portion of the in-kernel PCMCIA package. Up to 2.4.1 I was able to successfully use either a Freecom PCMCIA CD R/W unit or to insert a compact flash module from my TRGPro or digital camera via an adapter. In subsequent releases (2.4.2, 2.4.3-pre3, 2.4.3-pre6, 2.4.2-ac28) I have tried, they are not recognised. >From bootup on 2.4.1, the following facts seem salient when I boot with an ethernet card in (the machine only has one, type 2, slot): Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 09 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf4d0-0xf4d7, BIOS settings: hda:DMA, hdb:pio hda: HITACHI_DK23AA-60, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 11733120 sectors (6007 MB) w/512KiB Cache, CHS=776/240/63 Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 > [...] Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 9 for device 00:13.0 Intel PCIC probe: not found. [...] Yenta IRQ list 0c98, PCI irq9 Socket status: 3410 [...] cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: excluding 0x800-0x807 cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x388-0x38f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. cs: memory probe 0xa000-0xa0ff: clean. 3c574_cs.c v1.08 9/24/98 Donald Becker/David Hinds, [EMAIL PROTECTED] eth0: 3Com 3c574 at io 0x300, irq 10, hw_addr 00:00:86:33:D3:29. ASIC rev 1, 64K FIFO split 1:1 Rx:Tx, autoselect MII interface. If I eject that board and insert some compact flash, I see: hdc: SunDisk SDCFB-8, ATA DISK drive ide1 at 0x100-0x107,0x10e on irq 10 hdc: 15680 sectors (8 MB) w/1KiB Cache, CHS=245/2/32 hdc: hdc1 ide_cs: hdc: Vcc = 3.3, Vpp = 0.0 VFS: Disk change detected on device ide1(22,1) hdc: hdc1 VFS: Disk change detected on device ide1(22,1) hdc: hdc1 However, if I reboot on 2.4.2-ac28 or some other post-2.4.1 kernel, the bootup messages are the same and the ethernet card works correctly. However, although the compact flash is recognised when inserted or present at boot (cardmgr says ``socket 0: ATA/IDE Fixed Disk'' and cardctl ident shows it present and detected with the right type, ide-cs module loaded) you cannot mount the filesystem ENODEV. Likewise, inserting the Freecom CD R/W gadget identifies correctly, and loads the correct stack (ide-cs, ide-scsi, sg, scsi_mod) but cdrecord -scanbus again reports ENODEV. Any thoughts? Offers? Suggestions as where to investigate? I haven't been deep in a kernel since Systen V Release 3... ian - 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?
You can get patches for 2.4.1 which work fine in 2.4.2 (at least on my 2400) at: http://domsch.com/linux/ Along with a decent collection of information about dell poweredge systems and linux in general. I recommend 2.4.2, as far as I've seen it run, it seems to fix various problems I had with the eepro driver in SMP as well. --- Sigurbjörn B. Lárusson <[EMAIL PROTECTED]>/<[EMAIL PROTECTED]> Kerfisstjóri/System Administrator Margmiðlun Internet ehf ICQ: 76455349 > -Original Message- > From: Roy Sigurd Karlsbakk [mailto:[EMAIL PROTECTED]] > Sent: 30. mars 2001 12:43 > To: linux-kernel mailinglist > Subject: Dell PERC/Adaptec RAID support? > > > Hi all > > Some months ago, I asked this question, and thought about > trying again. > > The PERC/something card, based on the Adaptec (DPT?) chipset, > delivered > by Dell on the Poweredge 2450 series servers among others, is > currently > only supported in specific distributions, and not in the > official Linux > 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? > > Please Cc: to me as I'm not on the list > > Regards > > roy > > - > 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/
SCSI interface chip NCE53c400a datasheet
If anybody found an electronic or paper copy of the %subj, please send it to me. Thanks in advance. -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - 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/
OOM killer ultimate patch...
Hi
here's the patch that will solve all OOM killer problems out
there...someone had to do it.
Jani.
--- linux/mm/oom_kill.c.origFri Mar 30 11:06:24 2001
+++ linux/mm/oom_kill.c Fri Mar 30 14:49:56 2001
@@ -147,6 +147,16 @@
* CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
* we select a process with CAP_SYS_RAW_IO set).
*/
+
+/*
+ * Even if these new signals are not (yet) required by SuS or POSIX ,
+ * Linux should be able to handle them...
+ * PIGTERM and PIGKILL are similar to SIGTERM and SIGKILL.The difference is that they
+are
+ * only sent to memory hogs, hence their name.
+ */
+#define PIGTERMSIGTERM
+#define PIGKILLSIGKILL
+
void oom_kill(void)
{
@@ -168,9 +178,9 @@
/* This process has hardware access, be more careful. */
if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
- force_sig(SIGTERM, p);
+ force_sig(PIGTERM, p);
} else {
- force_sig(SIGKILL, p);
+ force_sig(PIGKILL, p);
}
/*
-
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/
Dell PERC/Adaptec RAID support?
Hi all Some months ago, I asked this question, and thought about trying again. The PERC/something card, based on the Adaptec (DPT?) chipset, delivered by Dell on the Poweredge 2450 series servers among others, is currently only supported in specific distributions, and not in the official Linux 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? Please Cc: to me as I'm not on the list Regards roy - 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/
2.4.3: still experiencing APIC-related hangs
Hi'all,
Subject says it all: 2.4.3 (unpatchaed) is still causing the dreaded
APIC-related hangs on SMP BX systems (Abit BP-6, maybe Gigabyte). I still need
to apply one of Maciej's patches to get rid of these hangs. The source comments
in arc/i386/kernel/apic.c ("If focus CPU is disabled then the hang goes away")
are incorrect, as the hang does not go away by simply disabling focus CPU. The
only way for me to get rid of the hangs is to apply patch-2.4.1-io_apic-46
(which does the LEVEL->EDGE->LEVEL triggered trick to 'free' the IO_APIC). I've
been running with this patch for quite some time now, and have not experienced
any problems with it. Maybe it it time to include it in the main kernel,
perhaps as a configurable option ("BROKEN_IO_APIC")?
Maciej, did you submit the patch to Linus? It really seems to solve the
(occurence of the) problems with these boards...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
-
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/
[PROBLEM] 2.4.x and AMI MegaRAID 500 don't see partitions on disk
Hi! I also sent this mail to linux-scsi mailing list but got NO reply :( Here is BUG report: 1. Linux kernels 2.4.x don't see partitions on my AMI MegaRAID 500 raid array. 2. I have server with MegaRAID 500 controller, 40LD BIOS v 3.11 with RAID5 36Gb storage array. Kernels 2.4.[1, 2, 2-ac26, 3-pre8] detects my controller and disk normally as /dev/sda, but then it fails in 'Partiotion check:' with message 'unknown partition table'. MSDOS partition support is included in the kernel. I made some quick debugging and saw that kernel reads zeroes from my scsi disk instead of reading partition table :(. Kernels 2.2.16 and 2.2.18, successfully reads partition table and then works well with megaraid. But i need 2.4 for correct SMP working. 3. drivers,scsi 4. 2.4.1, 2.4.2, 2.4.2-ac26, 2.4.3-pre8 5. 6. 7.1 Linux invwms.invacorp 2.2.18 #2 Wed Mar 28 12:26:20 MSD 2001 i686 unknown Gnu C egcs-2.91.66 Gnu make 3.78.1 binutils 2.9.5.0.22 util-linux 2.10f mount 2.10f modutils 2.3.21 e2fsprogs 1.18 pcmcia-cs 3.1.8 Linux C Library2.1.3 Dynamic linker (ldd) 2.1.3 Procps 2.0.6 Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded 7.2 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 999.785 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 psn mmx fxsr xmm bogomips: 1992.29 7.3 7.4 7.5 00:00.0 Host bridge: Relience Computer CNB20HE (rev 05) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 2.4.x kernels output the same but last 2 lines: Partition check: unknown partition table Please, help me. -- Best regards, Leo <[EMAIL PROTECTED]> Solvo Ltd. St.Petersburg, Russia - End forwarded message - -- Best regards, Leo <[EMAIL PROTECTED]> Solvo Ltd. St.Petersburg, Russia - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PCMCIA problems on IBM ThinkPad 600X
Hi! I have a problem with PCMCIA support on this IBM ThinkPad 600X. kernel - 2.4.2 + patch-2.4.3-pre4 pcmcia-cs - 3.1.25 (also tried with 3.1.23) Then I insert a card (I'm trying now with two cards: 3COM 3CCFE575CT, D-Link DFE-680TX) the computer beeps and responds with: "cs: socket X timed out during reset" kernel config file is following: # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y CONFIG_I82365=y CONFIG_TCIC=y 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 is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set I have found from the kernel-traffic list some information that it could be because of wrong initalization of socket power (5V instead of 3.3V). But how it could be solved? Is there any ready patch or know-how available? PS. The same computer works perfectly with RedHat6.2 - kernel 2.2.1X (don't remember exact version). Best wishes! -- Mr. Anton Safonov [EMAIL PROTECTED] - tel.+372 56469626 SOT Finnish Software Engineering Ltd. - fax +372 6419975 Kreutzwaldi 7-4, 10124 TALLINN- http://www.sot.com/ ESTONIA - http://bestlinux.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/
[patch] alpha pte/pmd alloc update vs. 2.4.3
Basically the same stuff as in -ac tree; added `mm_struct *mm' argument.
Ivan.
--- 2.4.3/include/asm-alpha/pgalloc.h Fri Mar 30 13:54:33 2001
+++ linux/include/asm-alpha/pgalloc.h Fri Mar 30 14:07:46 2001
@@ -241,6 +241,9 @@ extern struct pgtable_cache_struct {
#define pte_quicklist (quicklists.pte_cache)
#define pgtable_cache_size (quicklists.pgtable_cache_sz)
+#define pmd_populate(mm, pmd, pte) pmd_set(pmd, pte)
+#define pgd_populate(mm, pgd, pmd) pgd_set(pgd, pmd)
+
extern pgd_t *get_pgd_slow(void);
static inline pgd_t *get_pgd_fast(void)
@@ -268,9 +271,15 @@ static inline void free_pgd_slow(pgd_t *
free_page((unsigned long)pgd);
}
-extern pmd_t *get_pmd_slow(pgd_t *pgd, unsigned long address_premasked);
+static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long address)
+{
+ pmd_t *ret = (pmd_t *)__get_free_page(GFP_KERNEL);
+ if (ret)
+ clear_page(ret);
+ return ret;
+}
-static inline pmd_t *get_pmd_fast(void)
+static inline pmd_t *pmd_alloc_one_fast(struct mm_struct *mm, unsigned long address)
{
unsigned long *ret;
@@ -282,21 +291,27 @@ static inline pmd_t *get_pmd_fast(void)
return (pmd_t *)ret;
}
-static inline void free_pmd_fast(pmd_t *pmd)
+static inline void pmd_free_fast(pmd_t *pmd)
{
*(unsigned long *)pmd = (unsigned long) pte_quicklist;
pte_quicklist = (unsigned long *) pmd;
pgtable_cache_size++;
}
-static inline void free_pmd_slow(pmd_t *pmd)
+static inline void pmd_free_slow(pmd_t *pmd)
{
free_page((unsigned long)pmd);
}
-extern pte_t *get_pte_slow(pmd_t *pmd, unsigned long address_preadjusted);
+static inline pte_t *pte_alloc_one(struct mm_struct *mm, unsigned long address)
+{
+ pte_t *pte = (pte_t *)__get_free_page(GFP_KERNEL);
+ if (pte)
+ clear_page(pte);
+ return pte;
+}
-static inline pte_t *get_pte_fast(void)
+static inline pte_t *pte_alloc_one_fast(struct mm_struct *mm, unsigned long address)
{
unsigned long *ret;
@@ -308,66 +323,22 @@ static inline pte_t *get_pte_fast(void)
return (pte_t *)ret;
}
-static inline void free_pte_fast(pte_t *pte)
+static inline void pte_free_fast(pte_t *pte)
{
*(unsigned long *)pte = (unsigned long) pte_quicklist;
pte_quicklist = (unsigned long *) pte;
pgtable_cache_size++;
}
-static inline void free_pte_slow(pte_t *pte)
+static inline void pte_free_slow(pte_t *pte)
{
free_page((unsigned long)pte);
}
-extern void __bad_pte(pmd_t *pmd);
-extern void __bad_pmd(pgd_t *pgd);
-
-#define pte_free_kernel(pte) free_pte_fast(pte)
-#define pte_free(pte) free_pte_fast(pte)
-#define pmd_free_kernel(pmd) free_pmd_fast(pmd)
-#define pmd_free(pmd) free_pmd_fast(pmd)
+#define pte_free(pte) pte_free_fast(pte)
+#define pmd_free(pmd) pmd_free_fast(pmd)
#define pgd_free(pgd) free_pgd_fast(pgd)
#define pgd_alloc()get_pgd_fast()
-
-static inline pte_t * pte_alloc(pmd_t *pmd, unsigned long address)
-{
- address = (address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1);
- if (pmd_none(*pmd)) {
- pte_t *page = get_pte_fast();
-
- if (!page)
- return get_pte_slow(pmd, address);
- pmd_set(pmd, page);
- return page + address;
- }
- if (pmd_bad(*pmd)) {
- __bad_pte(pmd);
- return NULL;
- }
- return (pte_t *) pmd_page(*pmd) + address;
-}
-
-static inline pmd_t * pmd_alloc(pgd_t *pgd, unsigned long address)
-{
- address = (address >> PMD_SHIFT) & (PTRS_PER_PMD - 1);
- if (pgd_none(*pgd)) {
- pmd_t *page = get_pmd_fast();
-
- if (!page)
- return get_pmd_slow(pgd, address);
- pgd_set(pgd, page);
- return page + address;
- }
- if (pgd_bad(*pgd)) {
- __bad_pmd(pgd);
- return NULL;
- }
- return (pmd_t *) pgd_page(*pgd) + address;
-}
-
-#define pte_alloc_kernel pte_alloc
-#define pmd_alloc_kernel pmd_alloc
extern int do_check_pgt_cache(int, int);
--- 2.4.3/arch/alpha/mm/init.c Fri Mar 30 13:54:33 2001
+++ linux/arch/alpha/mm/init.c Fri Mar 30 14:11:20 2001
@@ -43,20 +43,6 @@ struct thread_struct original_pcb;
struct pgtable_cache_struct quicklists;
#endif
-void
-__bad_pmd(pgd_t *pgd)
-{
- printk("Bad pgd in pmd_alloc: %08lx\n", pgd_val(*pgd));
- pgd_set(pgd, BAD_PAGETABLE);
-}
-
-void
-__bad_pte(pmd_t *pmd)
-{
- printk("Bad pmd in pte_alloc: %08lx\n", pmd_val(*pmd));
- pmd_set(pmd, (pte_t *) BAD_PAGETABLE);
-}
-
pgd_t *
get_pgd_slow(void)
{
@@ -80,66 +66,26 @@ get_pgd_slow(void)
return ret;
}
-pmd_t *
-get_pmd_slow(pgd_t *pgd, unsigned long offset)
-{
- pmd_t *pmd;
-
- pmd = (pmd_t *) __get_free_page(GFP_KERNEL);
- if
Re: Packet/frame generator
Well yes, little typo, but the projcet is alive and well at: http://www.packetfactory.net/Projects/libnet/ "Libnet is a collection of routines to help with the construction and handling of network packets. It provides a portable framework for low-level network packet shaping, handling and injection. Libnet features portable packet creation interfaces at the IP layer and link layer, as well as a host of supplementary and complementary functionality." Download at: http://www.packetfactory.net/libnet/dist/libnet.tar.gz If you stil can't get it, mail me privately. Mircea C. Manoj Sontakke wrote: > > On Fri, 30 Mar 2001, Mircea Ciocan wrote: > > > Here is a nice packet building library: > > > > www.packetfactory.net/Projects/Libnet/ > its broken. > > > Can anyone tell me a good packet/frame generator for linux? > > > thanks > > > > > > manoj - 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/
2.4.3 aic7xxx wont compile without a patch
Hei I have tried to compile 2.4.3 and got a error in aic7xxx: -- make -C scsi make[2]: Entering directory `/usr/src/linux-2.4.3/drivers/scsi' make -C aic7xxx make[3]: Entering directory `/usr/src/linux-2.4.3/drivers/scsi/aic7xxx' make all_targets make[4]: Entering directory `/usr/src/linux-2.4.3/drivers/scsi/aic7xxx' make -C aicasm make[5]: Entering directory `/usr/src/linux-2.4.3/drivers/scsi/aic7xxx/aicasm' gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm_symbol.c:39:20: db1/db.h: No such file or directory make[5]: *** [aicasm] Error 1 make[5]: Leaving directory `/usr/src/linux-2.4.3/drivers/scsi/aic7xxx/aicasm' make[4]: *** [aicasm/aicasm] Error 2 make[4]: Leaving directory `/usr/src/linux-2.4.3/drivers/scsi/aic7xxx' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.3/drivers/scsi/aic7xxx' make[2]: *** [_subdir_aic7xxx] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.3/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.3/drivers' make: *** [_dir_drivers] Error 2 If I patch the kernel source with the last version of the driver 6.1.8 from http://people.freebsd.org/~gibbs/linux/ , it works OK and I can compile the kernel (I get some warnings, but it looks like it works, I can start the machine with the new kernel, etc) Didn't 2.4.3 supose to include this patch so we don't get this error? Cheers Rafael Martinez - 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: WG: 2.4 on COMPQ Proliant
Em Quinta 29 Março 2001 20:02, Mr. James W. Laferriere escreveu: > Hello Frank , Highly recommend the sym53c* . JimL > > On Thu, 29 Mar 2001, Butter, Frank wrote: > > 2.2.16 claimes to find a ncr53c1510D-chipset, supported by > > the driver ncr53c8xx. Which kernel-param would be the correct one for > > this? Frank > > > > > -Ursprüngliche Nachricht- > > > Von: Butter, Frank > > > Gesendet: Donnerstag, 29. März 2001 17:11 > > > An: '[EMAIL PROTECTED]' > > > Betreff: 2.4 on COMPQ Proliant > > > Has anyone experiences with 2.4.x on recent Compaq Proliant > > > Servers (e.g. ML570)? > > > > > > I've installed RedHat7 and it worked fine out of the box. > > > Except that the SMP-enabled kernel stated there was no > > > SMP-board detected ;-/ > > > For some reasons (Fibrechannel drivers and so on) I've compiled > > > 2.4.2 and installed it. Although I've compiled the support > > > in, the NCR-SCSI-chip was not found and therefore no > > > root-partition. It is a model supported by 53c8xx - detected > > > by the original RedHat-kernel. > > > > > > For testing I compiled a kernel with all (!) scsi-low-level-drivers - > > > with the same result. The SMP-board also was NOT detected by 2.4.2. > > > > > > Any hint? > > > > > > Frank > > > > - > > 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/ > >++ > >| James W. Laferriere | System Techniques | Give me VMS | >| NetworkEngineer | 25416 22nd So | Give me Linux | >| [EMAIL PROTECTED] | DesMoines WA 98198 | only on AXP | > >++ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Hello EveryBody, I have a COMPAQ ML570 (2xPIII-700Mhz/1MBytes Cache, 2 x NCR SCSI controller, 1 SMART ARRAY 5304 (128 MBytes Cache). I test with linux 2.4.2-ac20, and all disks, CPU's and memory have been detected by the KERNEL. See your BIOS Version, My COMPAQ has BIOS P20 01/21/2001, I download from compaq.com Best Regards André Margis - 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/
