Intel SRCU3-1 RAID (I2O) and 2.4.5-ac18
I have configured a RAID5 volume, partitioned it and created ext2 on it. I can mount it and everything seems to be ok, but trying to copy a large (+-500MB) file from one directory on the filesystem on the RAID to another results in something like: i2o/iop0: No handler for event (0x0400) i2o/iop0 requires user configuration Driver "I2O Block OSM" did not release device! i2ob_del_device called, but not in dev table! Driver "I2O Block OSM" did not release device! and the copying process is frozen. After that I can read some data from the filesystem (tried to ls some directories) but cannot umount it and cannot kill the copying process. The event code in the message's first line sometimes has different values (0x0020 for example), the first line happens to be repeated a few times as well. The problem is fully reproducible with my system. The system is RedHat 7.1, the kernel is compiled with SMP, I2O block OSM, I2O PCI support and without I2O SCSI and I2O net OSMs. SCSI support is also off. I enabled the enhanced RTC because a somewhat dated document from Intel concerning support for this controller with RH62 says it has to be on. GCC and binutils versions are: egcs-2.91.66 (stock RH71 "kgcc"), binutils-2.10.91.0.2 (stock RH71). I have the controller working in an Intel L440GX+ board with two PIII 700MHz processors. The board specs are: 82440GX chipset, Cirrus Logic CLGD5480 VGA, Adaptec AIC-7896 SCSI (unused), Intel 82559 EtherPro100 (unused). The SRCU31 controller works in an ordinary PCI slot (32bit/33mhz), the only other PCI card in the system (apart from the on-board devices) is an Intel EtherPro100. There are four IBM DDYS-T18350 drives on the controller, three of them are in the raid. The controller has 32MB RAM as cache, the system has 512MB of ECC RAM. greetings, Przemek Tomala PS: if you need additional info or you can help with this, please CC me, as I am not subscribed to the list - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: EEPro100 problems in SMP on 2.4.5 ?
Dylan Griffiths wrote: > > Hi. While doing some file tranfers to our new server (a Compaq Proliant > 8way XEON 500 with 4gb ram and an EEPro100 NIC), the box socked solid (no > oops, no response via network, no response via console). The other hardware > in the system was a Compaq Smart Array 9SMART2 driver). It's running > Slackware 7.1. The other system was a dual P3 450 running Redhat 7.1 (Linux > velocity.kuro5hin.org 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 2001 i686 > unknown) w/ 3c59x NIC. The Redhat machine experienced no problems. > In Uni processor mode, the system is totally stable. But only using 1/8th > of its power :-/ We had to roll back to 2.2.19 with a bigmem patch, but > we'd like to have a stable 2.4 kernel to use (since it's so much better SMP > wise, throughput wise, etc). Some things to try: 1: Include `magic sysrq' support in the kernel and use ALT-SYSRQ-T and S when it has locked up. If you get some traces then please feed them into `ksymoops -m System.map' and report back. 2: If the above doesn't work, add `nmi_watchdog=1' to the kernel boot options. That may catch the lockup. 3: Replace the NIC with another eepro100. If the problem goes away then chuck the old one. 4: Replace the NIC with one of a different type (ie: swap with the other machine). If that fixes it we look at the ethernet driver. Otherwise we look at, umm, the rest of 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: supermount
Supermount has been integrated into the Mandrake 8 kernel (2.4); I have been unable to locate the standalone patch for this, however. Steve Kieu wrote: > > --- Sam Halliday <[EMAIL PROTECTED]> wrote: > This > email was delivered to you by The Free > > Internet, > > a Business Online Group company. > > http://www.thefreeinternet.net > I totally aggree, supermount is nice features and it > should be integrated into the main kernel stream (just > my HO) > > > > --- > > hello, > > i am fairly new to linux, i need it's fast > > number crunching powers > > for my research... and i have only recently begun to > > have a look at the > > kernel (i believe every workman should know his > > tools). but i have > > noticed that supermount is not a standard part of > > the project, is there > > any reason why this is? is it due to man power? i > > would have been less > > shocked by the absense of other features in the > > > > > radio support, supermount seems to me to be > > essential in any operating > > system. > > i apologise if this is a very silly question or > > if i have posted > > this question in the wrong place, but please excuse > > me, im new to this > > whole world. > > > > and keep up the good work, i wish i knew more about > > the whole thing so i > > could contribute something. > > > > Sam, Ireland > > > > - > > To unsubscribe from this list: send the line > > "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > = > S.KIEU > > _ > http://messenger.yahoo.com.au - Yahoo! Messenger > - Voice chat, mail alerts, stock quotes and favourite news and lots more! > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- John P. Silva[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/
Mac USB keyboards (Was: USB Keyboard errors with 2.4.5-ac)
On Sat, Jun 30, 2001 at 12:11:00AM +0200, Tim Jansen wrote: > I use a USB keyboard (Macally iKey) and mouse (Logitech iFeel) without > problems. I also get these messages, but I dont see any performance problem. > It may help you to enable an option like "Legacy USB keyboard support" in > your BIOS. This will emulate a PS/2 keyboard until USB is initialized. If you're using it on a wintel arch machine, have you managed to get the numeric keypad's = key or the power key to work? Doesn't here and I've tried more than one model of keyboard on more than one machine, no luck even with showkey. MacOS likes the keys just fine, naturally. -- Joseph Carter <[EMAIL PROTECTED]> Free software developer * TribFurry only gets spam mail from ucsd... I used to get email from myself but I decided I didn't like myself and stopped talking to me PGP signature
EEPro100 problems in SMP on 2.4.5 ?
Hi. While doing some file tranfers to our new server (a Compaq Proliant 8way XEON 500 with 4gb ram and an EEPro100 NIC), the box socked solid (no oops, no response via network, no response via console). The other hardware in the system was a Compaq Smart Array 9SMART2 driver). It's running Slackware 7.1. The other system was a dual P3 450 running Redhat 7.1 (Linux velocity.kuro5hin.org 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 2001 i686 unknown) w/ 3c59x NIC. The Redhat machine experienced no problems. In Uni processor mode, the system is totally stable. But only using 1/8th of its power :-/ We had to roll back to 2.2.19 with a bigmem patch, but we'd like to have a stable 2.4 kernel to use (since it's so much better SMP wise, throughput wise, etc). -- www.kuro5hin.org -- technology and culture, from the trenches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Q] IP autoconfiguration and make xconfig problem.. (fwd)
Sorry, I have mistyping... Hi, I have a two problem... 1) kernel 2.4.5 has a IP kernel level autoconfiguration problem. This kernel do not receive IP from dhcp server. but, kernel 2.4.3 has not any problem about it. <--- this... 2) make xconfig has stop with following error message -- drivers/net/Config.in: 145: can't handle dep_bool/dep_mbool/dep_tristate condition make[1]: *** [kconfig.tk] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.5/scripts' make: *** [xconfig] Error 2 -- how can solve this problems? thanks.. Ki hyung Ju -- I love Jesus Christ who is my savior. He gives me meanning of life. In Christ, I have become shepherd and bible teacher. e-mail : [EMAIL PROTECTED] home : http://newton.skku.ac.kr/~newton (My old home page) -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: AD1816A Sound Failure Upgrading to Kernel-2.4.5 from Kernel-2.2.19
[1.] AD1816A Sound Failure Upgrading to Kernel-2.4.5 from Kernel-2.2.19
[2.] I have been successfully running kernel-2.2.19 on an HP Pavilion
8180 system with an AD1816A sound device. When I installed
kernel-2.4.5, the sound system became erratic. It would
ocassionally produce the correct sounds, but would suddenly
generate severely distorted output.
I noted in the system logs that the AD1816 module reported
"isadmabug=0" under kernel-2.2.19, but was now reporting
"isadmabug=1" under kernel-2.4.5. After searching the source,
it appears that the variable 'isa_dma_bridge_buggy' is now set
in /arch/i386/kernel/setup.c, though I'm not 100% sure of that.
There does not appear to be a configuration variable which
controls this setting either.
As a pure hack, I modified drivers/sound/ad1816.c to include a
line which sets isa_dma_bridge_buggy to zero in function
probe_ad1816() as follows:
/* replace with probe routine */
static int __init probe_ad1816 ( struct address_info *hw_config )
{
ad1816_info*devc = _info[nr_ad1816_devs];
int io_base=hw_config->io_base;
int *osp=hw_config->osp;
int tmp;
printk("ad1816: AD1816 sounddriver Copyright (C) 1998 by Thorsten Knabe\n");
isa_dma_bridge_buggy = 0;
...
}
With this one line change, the sound system works perfectly
again. This is clearly not the best fix, but I hope it helps
isolate the true source of the problem.
[3.] Keywords: sound, ad1816
[4.] Kernel version: Linux version 2.4.5 ([EMAIL PROTECTED])
(gcc version 2.95.4 20010604 (Debian prerelease)) #3 Tue Jun 26
14:35:49 MDT 2001
[5.] N/A
[6.] N/A
[7.]
[7.1]
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux egor.linux.home 2.4.5 #3 Tue Jun 26 14:35:49 MDT 2001 i686 unknown
Gnu C 2.95.4
Gnu make 3.79.1
binutils 2.11.90.0.7
util-linux 2.11d
mount 2.11d
modutils 2.4.6
e2fsprogs 1.22
PPP2.4.1
Linux C Library2.2.3
Dynamic linker (ldd) 2.2.3
Procps 2.0.7
Net-tools 1.60
Kbd1.06
Sh-utils 2.0.11
Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc ad1816 sound
soundcore
[7.2]
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 3
model name : Pentium II (Klamath)
stepping: 3
cpu MHz : 265.914
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov mmx
bogomips: 530.84
[7.3]
ppp_deflate39136 0 (autoclean)
bsd_comp4096 0 (autoclean)
ppp_async 6224 0 (autoclean)
ppp_generic12992 0 (autoclean) [ppp_deflate bsd_comp ppp_async]
slhc4640 0 (autoclean) [ppp_generic]
ad1816 9232 1 (autoclean)
sound 54544 1 (autoclean) [ad1816]
soundcore 3664 4 (autoclean) [sound]
[7.4]
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03e8-03ef : serial(set)
03f6-03f6 : ide0
03f8-03ff : serial(set)
0500-050f : AD1816 Sound
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
f480-f4ff : Digital Equipment Corporation DECchip 21041 [Tulip Pass 3]
f480-f4ff : tulip
f800-f8ff : Adaptec AIC-7861
fc00-fcff : ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB]
ff80-ff9f : Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II]
ffa0-ffaf : Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
ffa0-ffa7 : ide0
ffa8-ffaf : ide1
-0009efff : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000c8000-000cc7ff : Extension ROM
000f-000f : System ROM
0010-07ff : System RAM
0010-0021e78f : Kernel code
0021e790-0029abbf : Kernel data
fb00-fbff : ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB]
ffbee000-ffbeefff : Adaptec AIC-7861
ffbee000-ffbeefff : aic7xxx
ffbef000-ffbe : ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB]
fff7fc00-fff7fc7f : Digital Equipment Corporation DECchip 21041 [Tulip Pass 3]
fff7fc00-fff7fc7f : tulip
[7.5] No lspci utility (??)
[7.6]
Attached devices:
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: SEAGATE Model: ST410800NRev: 7101
Type: Direct-AccessANSI
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 11:17:15AM -0700, Christoph Zens wrote: > > > Also, in printk's, you waste run-time memory, and you bloat up the need > > for the log size. Both of which are _technical_ reasons not to do it. > > > > Small is beuatiful. > > I totally agree. If you want to use Linux for a small and low cost > embedded system, you can't afford loads of RAM and FLASH space. > Small is the _key_ for those systems. *For* *those* *systems*. Until 99% of the Linux machines are Agendas, or whatever, and 1% PC's, as opposed to the other way around, we should default to displaying basic[1] info about the driver, unless told to with a "verbose" option or somesuch, which would make it spew verbose stuff[2]. And then a "debug" option which would make it spew lots and lots of stuff[3]. All of this specifiable on the commandline. (Can you currently change the default loglevel on the kernel commandline?). I honestly feel that this is the best idea. Just because we do this by default doesn't mean that the people who make embedded systems can't modify the kernel, or hell, even just the bootflags, to do what they want. :) d [1]: : , e.g.: eth0: Intel EtherExpress PRO/100, IRQ10, etc [2]: : : , e.g.: eepro100.c: v0.1, Daniel Stone <[EMAIL PROTECTED]> eth0: Intel EtherExpress PRO/100, IRQ10, etc [3]: : : , e.g.: eepro100.c: v0.1, Daniel Stone <[EMAIL PROTECTED]> Loaded with no options, scanning all PCI bus by default. eth0: Intel EtherExpress PRO/100, IRQ10, etc Intel i82559 OEM card, with bug. Enabling lock-up workaround bug, but you should get a Tulip. -- Daniel Stone <[EMAIL PROTECTED]> "can NE1 help me aim nuclear weaponz? /MSG ME!!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: The latest Microsoft FUD. This time from BillG, himself.
Lew Wolfgang wrote: > It is something that I read somewhere. If memory serves, Microsoft > will allow two installs on the same CD-key. Note that this is > different from the old MS key manager, all you had to do there > was enter the CD-key. There were no real-time checks on how > many times it was installed. You mean they will allow to overlapping installs. That is, you have permission to run the software on two machines. This says nothing about their enforcement scheme. > This http://two.digital.cnet.com/cgi-bin2/flo?y=eBwm0Hm1h0U0c7G0A4 > says, "In the case of Office XP, people can install the software on two > computers, such as a desktop PC and a laptop. But the second > installation requires a phone call to obtain the 44-key unlock code." So the first time you install it, you can do it the easy way. After that, you need to call them to get the code. For all we know, it's as simple as, "I'm the purchaser and I'd like to install it again". > The question remains, "How many times will Microsoft let you install?" > I'll test the process starting on Monday. I have an Office XP that > has been installed once. I'll try it again without giving my name > and keep trying until I reach the limit. I'll say that I'm having > problems with my disk crashing or something. I'll report my findings > here. That's precisely the question, and we have no answer. It is becoming more and more obvious to me that statements such as "If the CD key is used again they just refuse to send the final key" are sheer speculation mixed with a small dose of FUD. More likely, Microsoft will display escalating suspicion with each install, especially if they are in close time proximity or widely varying physical locations (or other suspicious patterns). If they find out that a key is definitely being abused, they will stop issuing unlock codes for it. In other words, they will cause great inconvenience for pirates and little inconvenience for legitimate users. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: The latest Microsoft FUD. This time from BillG, himself.
On Fri, 29 Jun 2001, David Schwartz wrote: > > If the > > CD key is used again they just refuse to send the final key. > > Do you have any evidence to support this statement or is it an assumption? > This is almost never the way such schemes are implemented. The policy is to > send the final key unless there's clear evidence of abuse (such as the CD > key being found on a web site or being reinstalled dozens of times from all > over the planet). Hi David, It is something that I read somewhere. If memory serves, Microsoft will allow two installs on the same CD-key. Note that this is different from the old MS key manager, all you had to do there was enter the CD-key. There were no real-time checks on how many times it was installed. This http://two.digital.cnet.com/cgi-bin2/flo?y=eBwm0Hm1h0U0c7G0A4 says, "In the case of Office XP, people can install the software on two computers, such as a desktop PC and a laptop. But the second installation requires a phone call to obtain the 44-key unlock code." Microsoft is apparently using this technology to enforce subscription plans in New Zealand and Austrailia. The software just dies if you don't send in your mortita. The question remains, "How many times will Microsoft let you install?" I'll test the process starting on Monday. I have an Office XP that has been installed once. I'll try it again without giving my name and keep trying until I reach the limit. I'll say that I'm having problems with my disk crashing or something. I'll report my findings here. Regards, Lew Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 82C686B SouthBridge fixup in linux/drivers/pci/quirks.c
Hi, I am not subscribed to the list. Please CC me on replies.
The VIA686B SouthBridge bug workaround is not activated on motherboards
which have a VIA 82C686B that needs fixing, but not a VIA NorthBridge. For
example, my Asus A7M266 has an AMD 761 NorthBridge, and the table at the end
of linux/drivers/pci/quirks.c thus does not attempt to apply the fix.
Someone suggested a fix against 2.4.4 in this thread, however it has not all
been fixed on 2.4.5 nor 2.4.5-ac22 (current, I believe).
Below is a patch to the __initdata table which causes the fix to be applied
based on detection of the buggy SouthBridge, and *not* the NorthBridge which
is commonly used with it. This is the correct behavior, and was suggested
by someone during the thread I reference, however this aspect of the fix was
overlooked.
http://mailman.real-time.com/pipermail/linux-kernel/Week-of-Mon-20010430/032
013.html
---
Jeff S Wheeler [EMAIL PROTECTED]
Software DevelopmentFive Elements, Inc
--- linux-2.4.5/drivers/pci/quirks.c.orig Fri Jun 29 20:24:09 2001
+++ linux-2.4.5/drivers/pci/quirks.cFri Jun 29 20:58:14 2001
@@ -358,7 +358,7 @@
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82443BX_2, quirk_natoma },
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_SI,
PCI_DEVICE_ID_SI_5597, quirk_nopcipci },
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_SI,
PCI_DEVICE_ID_SI_496, quirk_nopcipci },
- { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8363_0, quirk_vialatency },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C686, quirk_vialatency },
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C597_0, quirk_viaetbf },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C597_0, quirk_vt82c598_id },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_82C586_3, quirk_vt82c586_acpi },
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: The latest Microsoft FUD. This time from BillG, himself.
> If the > CD key is used again they just refuse to send the final key. Do you have any evidence to support this statement or is it an assumption? This is almost never the way such schemes are implemented. The policy is to send the final key unless there's clear evidence of abuse (such as the CD key being found on a web site or being reinstalled dozens of times from all over the planet). DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: all processes waiting in TASK_UNINTERRUPTIBLE state
On Friday 29 June 2001 22:40, Jeff Dike wrote: > The bug was UML-specific and specific in such a way that I don't think it's > possible to find the bug in the native kernel by making analogies from the > UML bug. Heh, too bad, there goes that chance to show uml bagging a major kernel bug. But it's just a matter of time... -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
some linux history online...
just a fun read: 1. "As of March 17, 1993, the current version of Linux is 0.99 patchlevel 7." 2. "Linux runs only on 386/486 machines with an ISA or EISA bus." http://www.bombthebox.com/Archive/Linux/ article: Linux - Free Unix Information Sheet.txt -- elko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CRAMFS error "attempt to access beyond end of device"
Hello - Is there maybe a missing boundary check in cramfs that causes accesses slightly past (up to 24 or 32K?) the end of a device? Here's an example of a cramfs image mounted on a loop device (the same thing happens with other block devices, and when the kernel itself mounts a partition as cramfs-root.) attempt to access beyond end of device 07:01: rw=0, want=1156, limit=1152 attempt to access beyond end of device 07:01: rw=0, want=1160, limit=1152 attempt to access beyond end of device 07:01: rw=0, want=1164, limit=1152 The messages appear while running "diff -r" against the original tree. The diff itself doesn't find any problems with the filesystem. The size of the cramfs is 1179648 bytes, or exactly 1152 * 1024. My kernel version is 2.4.5, but this behavior has existed since the 2.4.0-test kernels. If anyone has ideas on this, please let me know. - Sidik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ipppd/isdn
hi,
i have a very nasty bug that is troubling me for months now and it took
me till today to find out whats really causing the crashes and to
reproduce it. before i go on, the bug only appears with MPPP (two isdn
lines) enabled. so what happens is:
i connect to my ISP with MPPP enabled. no problem some far. after about
12hours my ISP will disconnect me (to enforce changing IPs). my isdn
connection will quit, but since i'm downloading something most of the
time it will try to reconnect immediately. but this reconnect will never
happen because the kernel will oops just at this postion:
Jun 29 23:30:21 knecht ipppd[237]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, l
Jun 29 23:30:21 knecht ipppd[237]: Remote message:
Jun 29 23:30:21 knecht ipppd[237]: MPPP negotiation, He: Yes We: Yes
every time. so i can reproduce it by just pulling the isdn cable out of
the isdn-card and the connection will timeout after a while. then i put
the cable back in, the isdn-card dials out and the kernel will ooops
again. i temporarely "fixed" it by disconneting/reconnecting the
connection via cron every 10 hours. so the bug only appears when ipppd
doesn't expect a disconnect and is kinda "surprised".
i've atached the unmodified oops, the oops through ksymoops and the
important stuff from syslog. i will provide more info if needed.
[1]the original oops:
isdn_ppp_mp_receive: lpq->ppp_slot -1
isdn_ppp_mp_receive: lpq->ppp_slot -1
isdn_ppp_mp_receive: lpq->ppp_slot -1
isdn_ppp_mp_receive: lpq->ppp_slot -1
isdn_ppp_xmit: lpq->ppp_slot -1
Unable to handle kernel paging request at virtual address 08066da0
printing eip:
0804b232
*pde = 03634067
*pte = 01f3b065
Oops: 0007
CPU:0
EIP:0023:[<0804b232>]
EFLAGS: 00010202
eax: 033d ebx: b5f4 ecx: 0806b718 edx:
esi: b614 edi: 08060b13 ebp: 080b70c0 esp: b594
ds: 002b es: 002b ss: 002b
Process ipppd (pid: 237, stackpage=c3711000)
<0>Kernel panic: aiee, killing interrupt handler!
In interrupt handler - not syncing
<6>SysRq: Emergency Sync
Syncing device 03:01 ... Scheduling in interrupt
kernel BUG at sched.c:714!
invalid operand:
CPU:0
EIP:0010:[]
EFLAGS: 00010286
eax: 001b ebx: c3711e74 ecx: c027a41c edx: 2075
esi: c1e7d660 edi: c371 ebp: c3711e60 esp: c3711e34
ds: 0018 es: 0018 ss: 0018
Process ipppd (pid: 237, stackpage=c3711000)
Stack: c022b456 02ca c3711e74 c1e7d660 c371 c011415c c02efba0 c3711e74
c1e7d660 c02efc04 0001 c012b47a 00ba c3877140 0301
c371 c1e7d6ac c1e7d6ac c012b61e c1e7d660 0301
Call Trace: [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] []
Code: 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 90 55 89 e5 83 ec 0c 57
<0>Kernel panic: aiee, killing interrupt handler!
In interrupt handler - not syncing
[2]the oops through ksymoops:
ksymoops 2.3.4 on i586 2.4.5-ac21. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.5-ac21/ (default)
-m /boot/System.map-2.4.5-ac21 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c01ddf20,
System.map says c0146b60. Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address 08066da0
0804b232
*pde = 03634067
Oops: 0007
CPU:0
EIP:0023:[<0804b232>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 033d ebx: b5f4 ecx: 0806b718 edx:
esi: b614 edi: 08060b13 ebp: 080b70c0 esp: b594
ds: 002b es: 002b ss: 002b
Process ipppd (pid: 237, stackpage=c3711000)
<0>Kernel panic: aiee, killing interrupt handler!
invalid operand:
CPU:0
EIP:0010:[]
EFLAGS: 00010286
eax: 001b ebx: c3711e74 ecx: c027a41c edx: 2075
esi: c1e7d660 edi: c371 ebp: c3711e60 esp: c3711e34
ds: 0018 es: 0018 ss: 0018
Process ipppd (pid: 237, stackpage=c3711000)
Stack: c022b456 02ca c3711e74 c1e7d660 c371 c011415c c02efba0 c3711e74
c1e7d660 c02efc04 0001 c012b47a 00ba c3877140 0301
c371 c1e7d6ac c1e7d6ac c012b61e c1e7d660 0301
Call Trace: [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] []
Code: 0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 90 55 89 e5 83 ec 0c 57
>>EIP; 0804b232 Before first symbol <=
>>EIP; c010e33f<=
Trace; c011415c <__run_task_queue+50/64>
Trace; c012b47a
Re: VM behaviour under 2.4.5-ac21
On 20010629 Martin Knoblauch wrote: >Hi, > > just something positive for the weekend. With 2.4.5-ac21, the behaviour >on my laptop (128MB plus twice the sapw) seems a bit more sane. When I >start new large applications now, the "used" portion of VM actually >pushes against the cache instead of forcing stuff into swap. It is still >using swap, but the effects on interactivity are much lighter. > I was just going to say the same. After ac20, I think, the kernel stopped pre-allocating swap. Before I had always some swap used even if I was only using half my core memory (256Mb). And growing. I have not seen the box touch the swap since ac20. It uses all the ram it can get for cache, but does not send anything to swap to use its ram for cache. Now running ac21 while building ac22, and state is: werewolf:/usr/src# free total used free sharedbuffers cached Mem:255588 241044 14544 2168 8836 153752 -/+ buffers/cache: 78456 177132 Swap: 152576 0 152576 werewolf:/usr/src# vmstat procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 0 0 0 6944 8836 153868 0 01612 95 385 17 3 80 -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Mandrake Linux release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac21 #1 SMP Fri Jun 29 16:02:22 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Friday 29 June 2001 15:11, Clayton, Mark wrote: > > -Original Message- > > From: Paul Fulghum [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 29, 2001 4:02 PM > > To: Pavel Machek; [EMAIL PROTECTED]; Schilling, Richard; > > [EMAIL PROTECTED]; Henning P. Schmiedehausen; > > [EMAIL PROTECTED] > > Subject: Re: The latest Microsoft FUD. This time from BillG, himself. > > > > > Is this accurate? I never knew NT was mach-based. I do not think NT > > > 1-3 were actually ever shipped, first was NT 3.5 right? > > > Pavel > > > > NT 3.1 was the 1st to ship. > > I still have my 3.1 package all boxed up in the basement. I remember > impatiently waiting for its arrival. What a disappointment it turned > out to be. > > Mark I already answered this on the comphist list, but I've gotten in the habit of trimming linux-kernel from the replies. NT 3.1 was the first release version to ship, but there had been a "beta 1" in late 1992 and a "beta 2" in 1993. (This is why I said I needed my notebook. :) NT 3.1 was obviously numbered that due to the success of Windows 3.1. It didn't fool anybody, of course. But it DID manage to confuse things enough to delay the release of Windows 4.0 (nee 95) for about two years while they tried to shoehorn NT into the consumer space... http://www.jwntug.or.jp/misc/japanization/history.html The dos death march: Dos 1.0 they didn't mean to do until the CP/M deal fell through. DOS 2.0 was documented as being a transitional product until the PC could run Xenix. Dos 4.0 was going to be replaced by OS/2. Dos 6 was going to be replaced by NT. Dos 7 (in windows 95) was the absolutely last version ever, swear on a stack of printouts. Windows 98 tried to avoid mentioning the word "dos". Bill Gates' evil sidekick winnie-me (You can just see him, shaved head, pinkie in corner of mouth, "I shall call it...") tried very hard to hide the presence of dos, actively denying access to command.com wherever possible. What kind of odds are Lloyds of London giving on the presence of DOS in Windows XP at this point? Just curious... And any FURTHER discusson of this belongs on: http://lists.sourceforge.net/lists/listinfo/penguicon-comphist Really. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thursday 28 June 2001 14:36, Miquel van Smoorenburg wrote: > You know what I hate? Debugging stuff like BIOS-e820, zone messages, > dentry|buffer|page-cache hash table entries, CPU: Before vendor init, > CPU: After vendor init, etc etc, PCI: Probing PCI hardware, > ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc We've got a couple of VA rackmount servers with adaptec scsi controllers that print out several SCREENS worth of information as they probe all the busses and joyfully announce that yes, there are still hard drives plugged into some of them, and even gives me a list of the ones that DON'T have hard drives plugged into them. Interestingly, the bios also goes through a very similar ritual earlier in the boot. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Module tracing.
>I've recently been laboring over a kernel module that allows other >kernel modules to send messages and tracing statements. If anyone >has any input on whether this would be a usefull thing or not >please let me know. Here is a quick breakdown on how it works. Here is one raised hand. >From your description, I can see that this could be use as a Monitoring tool (heart beat, status, progress, etc..). I would appreciate any additional info. Thanks in advance, Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] Re: Linux 2.4.5-ac22
On Fri, 29 Jun 2001, Alan Cox wrote: > 2.4.5-ac20 > o Commence resync with 2.4.6pre5 I updated my laptop to 2.4.5-ac21 today. After reboot, I found a strange problem: My network card wouldn't initialize properly (eepro100). Jun 29 21:26:31 vaio kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others Jun 29 21:26:31 vaio kernel: PCI: Found IRQ 9 for device 00:0b.0 Jun 29 21:26:31 vaio kernel: eth0: Invalid EEPROM checksum 0xff00, check settings before activating this device! Jun 29 21:26:31 vaio kernel: eth0: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 9. Jun 29 21:26:31 vaio kernel: Board assembly ff-255, Physical connectors present: RJ45 BNC AUI MII Jun 29 21:26:31 vaio kernel: Primary interface chip unknown-15 PHY #31. Jun 29 21:26:31 vaio kernel: Secondary interface chip i82555. Jun 29 21:26:31 vaio kernel: Self test failed, status : Jun 29 21:26:31 vaio kernel: Failure to initialize the i82557. Jun 29 21:26:31 vaio kernel: Verify that the card is a bus-master capable slot.Jun 29 21:26:31 vaio kernel: eth0: 0 multicast blocks dropped. Jun 29 21:26:31 vaio kernel: eth0: 0 multicast blocks dropped. rmmod'ing and insmod'ing eepro100 again fixed the problem: Jun 29 21:27:16 vaio kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Jun 29 21:27:16 vaio kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others Jun 29 21:27:16 vaio kernel: PCI: Found IRQ 9 for device 00:0b.0 Jun 29 21:27:16 vaio kernel: eth0: OEM i82557/i82558 10/100 Ethernet, 08:00:46:08:0E:5D, IRQ 9. Jun 29 21:27:16 vaio kernel: Receiver lock-up bug exists -- enabling work-around. Jun 29 21:27:16 vaio kernel: Board assembly 11-001, Physical connectors present: RJ45 Jun 29 21:27:16 vaio kernel: Primary interface chip i82555 PHY #1. Jun 29 21:27:16 vaio kernel: General self-test: passed. Jun 29 21:27:16 vaio kernel: Serial sub-system self-test: passed. Jun 29 21:27:16 vaio kernel: Internal registers self-test: passed. Jun 29 21:27:16 vaio kernel: ROM checksum self-test: passed (0x04f4518b). Jun 29 21:27:16 vaio kernel: Receiver lock-up workaround activated. Things weren't always exactly reproducible, but I found the following: - The problem doesn't seem to happen with -ac19, it starts with -ac20 - After cold reboot it doesn't seem to happen - I took eepro100.c from -ac19 and put into -ac20: Still the same problem, but everything would stay at 0xFF even after reloading - I backed out the pci changes from -ac19 to -ac20 - no change of behavior (hope I didn't screw up anything during this test) - I tried 2.4.6-pre5, same behavior as -ac20+ I have CONFIG_ACPI off, CONFIG_PM on, CONFIG_EEPRO100_PM on (when it still existed) lspci -vvxxx diff before/after loading the module the first (non-working) time: 00:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Sony Corporation: Unknown device 8084 - Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Keyboard errors with 2.4.5-ac
On Friday 29 June 2001 19:27, Jordan Breeding wrote: > noticed my real problem with the keyboard. The kernel apparently > expects a PS/2 (AT) keyboard to be plugged in because if there isn't one > the kernel reports timeouts and seems slower than when there is a PS/2 > keyboard present, my guess is because it is waiting on all of those > timeouts. I use a USB keyboard (Macally iKey) and mouse (Logitech iFeel) without problems. I also get these messages, but I dont see any performance problem. It may help you to enable an option like "Legacy USB keyboard support" in your BIOS. This will emulate a PS/2 keyboard until USB is initialized. > The next major keyboard thing I noticed is that I can type on > certain keys but if I do anything like hit the caps lock key or number > lock a couple of times then the keyboard stops responding completely and > the kernel tells me that there was an error waiting on a IRQ on CPU #1. This was discussed in the USB mailing list a few weeks ago. Several people experienced this problem, including me. As a workaround, use the alternate UHCI (JE) driver. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RESEND: [ PATCH ] externalize (new) scsi timer function
I sent this back in January and previously. I still think they're important. FWIW, Doug Gilbert thought they were okay. -matt --- linux.orig/drivers/scsi/scsi_syms.c Wed Nov 29 18:19:45 2000 +++ linux/drivers/scsi/scsi_syms.c Wed Nov 29 18:18:35 2000 @@ -91,3 +91,10 @@ EXPORT_SYMBOL(scsi_devicelist); EXPORT_SYMBOL(scsi_device_types); +/* + * Externalize timers so that HBAs can safely start/restart commands. + */ +extern void scsi_add_timer(Scsi_Cmnd *, int, void ((*) (Scsi_Cmnd *))); +extern int scsi_delete_timer(Scsi_Cmnd *); +EXPORT_SYMBOL(scsi_add_timer); +EXPORT_SYMBOL(scsi_delete_timer); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
creeping system useage in 2.4.5
the machines: I have a firewall running 2.4.5 (stock, no patches) the boxes are: 1.2GHz athlon 512MB pc133 ram 20G 7200RPM ata100 drive D-link quad nic 2G swap space (swap is never used) Slackware-current (as of June 1) syslog set to log in async mode, logs rotated every hour running FWTK plug-gw proxy This proxy is horribly inefficiant, it forks off a new process for each incoming connection. this box is fast enough to handle this inefficiancy. also runnning heartbeat (heartbeat running over eth0 and eth1) the problem: when freshly booted the machine CPU load is ~5-15% system, 3-5% user loadave <1. as it continues to run the system time keeps climbing, after a day or so it's not unusual for the system time to be up ~40% with the user time still at 3-5% and loadave ~2-3, after a couple days the system time hits ~95% with the user time at 5% and the loadave ~12. at this point things start to seriously slow down. switching to the backup box (which then carries the same load) resets teh numbers back to the fresh system numbers even as it continues to handle the same traffic. the box normally has ~600-700 processes listed in a ps, after a fresh boot during a slow afternoon it gets up to ~350 processes within a couple min and ramps up to ~600 over the next couple hours (at which time the CPU times and the loadave are still nice and low) and remains fairly steady at this point until the machine fails (climbing to ~700 processes at peak load times and then dropping back to ~600 as the load drops off). Bandwidth of network traffic is low, ifconfig shows essentially no errors (<30 out of millions of packets) I had to bump the max filehandles up from the default 8K (I went all the way to 64K as it would run into a problem running out of them, after raising the limit the box will fail with the high-water mark of ~13000 and current of ~9000 (cat /proc/sys/fs/file-nr) I have used the plug-gw before on a 2.2 system (and a 2.4.0pre system) and with the process count ranging from ~1500 (idle) and ~5000 (loaded) this problem did not appear so I seriously doubt that it's a bug in this proxy. any ideas as to what could be accumulating to slowly tie up the cpu in system mode? David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: qlogicfc driver
Dmitry Meshchaninov wrote: > > Hi! > Judging from recent messages on linux-kernel and from the code which is > currently in 2.4.x the qlogicfc driver needs to be updated a bit. I have > done some amount of work on this driver and have sent patches to > Chris in the past, however I did not receive any comments on my changes. > It looks like Chris is too busy with other things right now, and I will > gladly maintain the driver if there is a consensus that the driver needs > a new maintainer. Meanwhile I am cleaning up driver for 2.4.4 > (not tested with 2.4.5 yet, but probably will work). I'll publish those > changes if there will be any interest. It is a drop-in replacement for > the five files in drivers/scsi/ (qlogicfc.c, qlogicfc.h, qlogicfc_inc.h, > qlogicfc_asm_ip.c and qlogicfc_asm.c). This contains updated (both with > and without ip support) firmware and many bugfixes. I decided not to > provide a patch because it is bigger then just those five files combind. > I have splitted up driver body into .h-file with types and > driver itself (as it should be). But this is negotiable. If you are working on qlogicfc, that's great! But since others are currently using this driver without problems, you might consider sending in your patches separated out (per Documentation/SubmittingPatches) so that it is easier for others to review and apply them in turn. -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
qlogicfc driver
Hi! Judging from recent messages on linux-kernel and from the code which is currently in 2.4.x the qlogicfc driver needs to be updated a bit. I have done some amount of work on this driver and have sent patches to Chris in the past, however I did not receive any comments on my changes. It looks like Chris is too busy with other things right now, and I will gladly maintain the driver if there is a consensus that the driver needs a new maintainer. Meanwhile I am cleaning up driver for 2.4.4 (not tested with 2.4.5 yet, but probably will work). I'll publish those changes if there will be any interest. It is a drop-in replacement for the five files in drivers/scsi/ (qlogicfc.c, qlogicfc.h, qlogicfc_inc.h, qlogicfc_asm_ip.c and qlogicfc_asm.c). This contains updated (both with and without ip support) firmware and many bugfixes. I decided not to provide a patch because it is bigger then just those five files combind. I have splitted up driver body into .h-file with types and driver itself (as it should be). But this is negotiable. Sincerely, Dmitry Meshchaninov software engineer DataFoundation Inc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Module tracing.
I've recently been laboring over a kernel module that allows other kernel modules to send messages and tracing statements. If anyone has any input on whether this would be a usefull thing or not please let me know. Here is a quick breakdown on how it works. Beware, this is only a BRIEF explaination.. I'll follow up with more details if anyone is intereasted. trace.o <- Tracing module mymodule .o <- Client module 1: Load tracing module 2: Load a module that uses the tracing modules for reporting. a. the client module requests a certain number of reporting levels. b. the trace module creates a devFS entry for each of the requested reporting levels. ( /dev/trace/mymodule/mymodule0 mymodule1 ... ) 3. Now the client module can send messages with a specific severity rating and have it set to the appropriate character file. 4. User space programs listening on each of the character files can do whatever, log the messages or perform tasks depending on the message. 5. When a client module is unloaded the devFS entries are removed and the user programs are also told to close the file. I am using the devFS filesystem because of the abilities to easily dynamically create new entries and remove them.. Currently devFS does not recycle Major and Minor numbers, but a co-worker of mine has created a patch to fix that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.6-pre3 + reiserfs + NFS peculiarities
Hello We've installed reiserfs on a logical volume, consisting of 2 60GB hard drives, and exported it over NFS. Kernel 2.4.6-pre3. In the beginning everything seemed to be fine. But then a few strange things have happened: 1. I tried running a program on a host, importing the filesystem in question, and sending its output to it. The program uses fwrite function, and checks the number of items written, so, it didn't match. On the second run yet another (similar writing) problem occured, but since then this program has been running for a few hours already without any noticeable errors. The remote host is Solaris-2.7 on a Sparc. 2. Another strangeness - this filesystem is also mounted on yet another Linux machine, running 2.4.5. Actually, the situation is slightly more complicated: on host a we've got 2 logical volumes with reiserfs: a1 and a2, mounted in /mnt/lvm/a1 and /mnt/lvm/a2. And the whole directory /mnt/lvm is exported over NFS. So, when on a remote host you do df -k on that mounted filesystem, all 3 values (total, occupied, free) are wrong. 3. All (except ext2, which is used for /) filesystems are compiled as modules. reiserfs is loaded on boot, when lvols are mounted. I tried mounting a fat-diskette, and got the following mesage: read_old_super_block: try to find super block in old location read_old_super_block: can't find a reiserfs filesystem on dev 02:00. If all the problems, mentioned above are known and have known solutions (patches, etc, however, I checked the reiserfs ftp-site - no patches for 2.4.6 yet), please let me know. Shall I use an earlier kernel version? If they are new, I'll gladly provide any necessary additional information. Below is lspci output: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) 00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 50) 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10) 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (rev 7a) Thanks Guennadi ___ Dr. Guennadi V. Liakhovetski Department of Applied Mathematics University of Sheffield, Sheffield, U.K. email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] I/O Access Abstractions
> "David" == David Howells <[EMAIL PROTECTED]> writes: David> Jes Sorensen <[EMAIL PROTECTED]> wrote: >> Have you considered the method used by the 8390 Ethernet driver? >> For each device, add a pointer to the registers and a register >> shift. David> And also flags to specify which address space the I/O ports David> reside in, and which how to adjust the host-PCI bridge to bring David> the appropriate bit of the PCI address space into view through David> the CPU address space window. Don't laugh - it happens. Hmm, I am shocked ;-) >> I really don't like hacing virtual access functions that makes >> memory mapped I/O look the same as I/O operations. David> Why not? It makes drivers a simpler and more flexible if they David> can treat different types of resource in the same way. serial.c David> is a really good example of this: It will also degrade performance if you introduce all these weird tests or function calls in the hot path. David> The switch has to be performed at runtime - so you get at least David> one conditional branch in your code, probably more. My proposal David> would replace the conditional branch with a subroutine (which David> lacks the pipline stall). Actually on some architectures you'd prefer the conditional branch over the subroutine call when you can do predication like on the ia64. David> Also a number of drivers (eg: ne2k-pci) have to be bound to David> compile time to either I/O space or memory space. This would David> allow you to do it at runtime without incurring conditional David> branching. But it's going to cost for the ones who do not support this. >> For memory mapped I/O you want to be able to smart optimizations to >> reduce the access on the PCI bus (or similar). David> I wouldn't have thought you'd want to reduce the number of David> accesses to the PCI bus. If, for example, you did to writes to David> a memory-mapped I/O register, you don't want the first to be David> optimised away. One good example I can think off is when you update a dma descriptor in PCI shared memory space (__raw_writel()). In that case you want to be able to use posted writes so all writes is done in one PCI write transaction instead of individual ones. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
plz ignore.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Bounce buffer deadlock
> Has anyone else seen a hang like this: > > bdflush() > flush_dirty_buffers() > ll_rw_block() > submit_bh(buffer X) > generic_make_request() > __make_request() > create_bounce() > alloc_bounce_page() > alloc_page() > try_to_free_pages() > do_try_to_free_pages() > page_launder() > try_to_free_buffers( , 2) -- i.e. wait for buffers > sync_page_buffers() > __wait_on_buffer(buffer X) Whoops. We actually carefully set PF_MEMALLOC to avoid deadlocks here but if the buffer is laundered ummm Looks like page_launder needs to be more careful > I hit this in 2.4.6-pre6, and I don't see anything in the ac series to protect > against it. Not this one no Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)V3
Andre Hedrick wrote:
> That is a legacy bit from ATA-2 but it is one of those things you cannot
> get rid of :-(
in ANSI X3.279-1996, "AT Attachment Interface with Extensions (ATA-2)",
Approved September 11, 1996 , control register bit 3-7 are reserved.
However ANSI X3.221-1994, "AT Attachment Interface for Disk Drives",
Approved May 12, 1994, bit3 is "1" and bits 4-7 are "x".
No further explanation.
How far back must we go, to get the sense ?
> struct {
> unsigned bit0 : 1;
> unsigned nIEN : 1;/* device INTRQ to host */
> unsigned SRST : 1;/* host soft reset bit */
> unsigned bit3 : 1;/* ATA-2 thingy */
> unsigned reserved456: 3;
> unsigned HOB: 1;/* 48-bit address ordering */
> } control_t;
>
> once I add-in the real def of bit3 then I will not
> need to look it up again.
bit3: 0: drive has 1-8 heads
1: drive has more than 8 heads
(From old MFM/RLL times. In ATA-1 bit3 is set to 1.
See also
http://www.win.tue.nl/~aeb/linux/hdtypes/hdtypes-2.html
.)
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Bounce buffer deadlock
Has anyone else seen a hang like this: bdflush() flush_dirty_buffers() ll_rw_block() submit_bh(buffer X) generic_make_request() __make_request() create_bounce() alloc_bounce_page() alloc_page() try_to_free_pages() do_try_to_free_pages() page_launder() try_to_free_buffers( , 2) -- i.e. wait for buffers sync_page_buffers() __wait_on_buffer(buffer X) Where the buffer head X going in the top of the stack is the same as the one we wait on at the bottom. There still seems to be nothing to prevent the try to free buffers from blocking on a buffer like this. Setting a flag on the buffer around the create_bounce call, and skipping it in the try_to_free_buffers path would be one approach to avoiding this. I hit this in 2.4.6-pre6, and I don't see anything in the ac series to protect against it. Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac22
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org This is the initial merge with 2.4.6pre - treat this one with care, it may not be the most reliable 2.4.5ac release ever made 2.4.5-ac22 o Fix the remaining make xconfig mess (me) o Add APM disabling on DMI match (me) | Needed for the Trigem Delhi3 (aka E Machines E-Tower 333cs) o Fix pnpbios without hotplug (I hope)(me) o Merge an escaped via midi fixup (Adrian Cox) o Revert minixfs changes 2.4.5-ac21 o Fix pnpbios compile failure and add docking (me) station hotplug (/sbin/hotplug dock) o Fix make xconfig failure(Keith Owens) o Fix cciss pci device table (Marcus Meissner) o Fix bogus math.h include in iphase driver (Arjan van de Ven) o Reiserfs vm deadlock fix(Chris Mason) o Make the i810 tco disable info clearer (Andrey Panin) o Correct bzImage size limit check(Pavel Machek) o Next lvm patch (Joe Thornber) o Fix toshoboe for pm api change (me) 2.4.5-ac20 o Commence resync with 2.4.6pre5 - Merge kernel doc tool changes - Merge sunrpc printk check change - Merge net core changes - Merge Bluetooth stack - Merge inet proto register - Merge bridge updates - Merge net/ipv4 and ipv6 changes - Merge x86 arch support - Merge m68k port changes - Merge ppc port changes - Merge sparc32/64 changes - Merge ACPI - Merge ll_rw_blk changes - Merge miro rds changes - Merge USB updates Kept xtime volatile - pending verification drivers are safe with this change Kept old atyfb code (someone needs to sort out which atyfb is the one being worked on and get that tree into the kernel) As with 2.4.6pre power management PCI interface changes mean power management is likely to be broken somewhat Also there is some kind of deadlock I suspect related to the mm changes in 2.4.6pre/2.4.5ac14 o Resync with 2.4.6pre6 o Add macserial printk levels (Arnaldo Carvalho de Melo) o Add picturebook vaio wide console mode support (Marcel Wijlaars) o Riscom8 driver printk/regions etc (Arnaldo Carvalho de Melo) o ESP serial driver clean up (Arnaldo Carvalho de Melo) o dz serial driver clean up (Arnaldo Carvalho de Melo) o Fix hangs during heavy buffer I/O (Arjan van de Ven) (eg mke2fs) o Clean up doubletalk driver (Arnaldo Carvalho de Melo) o Further imsttfb updates (Paul Mundt) o MTD missing export fixes(David Woodhouse) o MTD configure script fixes (me) o MTD include fixes (me) o Yamaha pci audio cleanup , longer delay (Pete Zaitcev) o i810 ioctl fix (Damjan Lango) o Add printk levels to tty_io.c (Arnaldo Carvalho de Melo) and tty_ioctl.c o Small acm serial driver cleanup (Arnaldo Carvalho de Melo) o Printk levels for via-pmu (Arnaldo Carvalho de Melo) o Improve kernel-doc parser (Christian Kreibich) o Disable AMI megaraid 64bit mode (Martti Hyppänen) | Seems the HP board firmware reports 64bit supported but | it doesn't actually work reliably on them 2.4.5-ac19 o Update Gareth Hughes contact info (Gareth Hughes) o Make sure NFS atime is handled by server(Trond Myklebust) o Fix Configure.help glitch (Geert Uytterhoeven) o Fix nfs readdir EIO and duplicates bug (Trond Myklebust) o Fix netlink removal of proc directory (Herbert Rosmanith) o Use skb_purge_queue in net stacks (Arnaldo Carvalho de Melo) | lapb, netrom, econet, rose, ax25, atm, sched, | socket core, unix o Fix reference after free in eql driver (Arnaldo Carvalho de Melo) o Fix reference after free in shaper (Arnaldo Carvalho de Melo) o Gameport fixes for Alpha(Jeff Garzik) o Configure.help updates (Eric Raymond) o JFFS copyright banner update(David Woodhouse) o Update docs on binfmt_misc java (Kurt Huwig) o Fix tty release_mem oops(Tachino Nobuhiro) o Pull nfs data out of inode struct
raid + xfs
hi. i'm using xfs on top of raid, and have noticed some unusual behavior. my basic hardware configuration is 850 p3, intel d815eea2 motherboard, 4 ibm drives, 2 promise cards, and a separate drive on built in ide channel as the root (this was not the initial configuration, but kind of evolved as we went ahead.) what we noticed was that the resyncing speed as reported by cat /proc/mdstat was originally 100k/sec, making resyncing take forever. we bumped /proc/sys/dev/raid up, and got resyncing to around 3000k/sec, with 90% cpu usage for raid5sync. then i decided to run the bonnie benchmark, and *while* bonnie was running, resyncing went up to 1k, with low CPU usage. when bonnie finised, resyncing started to behave badly again. (and bonnie's performance wasn't noticably impacted by the resyncing either). perhaps in a few weeks i might be able to investigate the raid code, but i'm hoping that someone might know what is causing this behavior. please CC me at [EMAIL PROTECTED] if you reply. thanks, jon bright -- jonathan bright [EMAIL PROTECTED] 415.820.7322 - voicemail/fax www.brightconsulting.com Binary data Binary data Binary data
Re: Cosmetic JFFS patch.
In article <[EMAIL PROTECTED]>, Chuck Wolber <[EMAIL PROTECTED]> wrote: >> Does sed tell you who programmed it on startup? >> >> Awk? >> >> Perl? >> >> Groff? >> >> Gcc? >> >> See a pattern here? > >Yeah, the output of these programms are usually parsed by other programs. >If they barked version info, that'd be extra code that has to go into >*EVERY* script that uses them. You're not using the kernel in the same >capacity. A counter example that does both, bc does tell us who wrote it every time we run it (most annoying) and is smart enough to know when it is not talking to a tty. % bc bc 1.05 Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1+2 3 % bc > test 1+2 % cat test 3 % I think listing driver versions on boot with perhaps some diagnostic info if appropriate is useful. Names and copyrights should be in the source. -- __O Lineo - For Embedded Linux Solutions _-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
motherboard/chipset confusion
I've been lurking lkml for a number of years, I follow most of what goes on here, and I don't pipe up often, but I'm trying to id a new system, and I'm confused about all of the via chipset problems/issues talked about here recently. Simply put, what chipset(s) should I consider for purchase, or if the converse subset is smaller, what should I avoid? I've searched and found nothing about the VIA VT8633 chipset, but a lot about problematic VIA chipsets, so I'm wary. Any feed back on this chipset or, specifically the ASUS CUV266 motherboard? thanks, -chuck -- ACCEL Services, Inc.| Specialists in Gravity, Magnetics | 1(713)993-0671 ph. 1980 Post Oak Blvd. | and Integrated Interpretation | 1(713)960-1157 fax Suite 2050 | | Houston, TX, 77056 | Chuck Campbell | [EMAIL PROTECTED] | President & Senior Geoscientist | "Integration means more than having all the maps at the same scale!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Some experience of linux on a Laptop
Alan Cox wrote: > > > Features I would like in the kernel: > > 1: Make the whole insmod-rmmod tingie a kernel internal so they could be > > trigged before rootmount. > > Already there. In fact Red Hat uses it for the scsi devices. That is what > initrd is for. > > > 2: Compile time optimization options in Make menuconfig > > such as ? > > > 3: Lilo/grub config in make menuconfig > > make bzlilo does the lilo install - what else would you expect there > > > 4: make bzImage && make modules && make modules install && cp > > arch/i386/boot/bzImage /boot/'uname -r' something inside make menuconfig > > So really you want an outside GUI tool that lets you reconfigure build and > install kernels. Yeah I'd agree with that. Someone just needs to write the > killer gnome/kde config tool. I've got C code for parsing/loading config.in > files and deducing the dependancy constraints if anyone ever wants to try > and write such a tool 8) > > > 5: Better support for toshiba computers... well try =) > > modprobe toshiba and look at http://www.buzzard.org.uk/toshiba/ > > > 6: Wouldn't it be easier for svgalib/framebuffer/GGI/X11 and others if the > > graphiccard drivers where kernel modules? > > No. > > > 8: A way to change kernel without rebooting. I have no diskdrive or cddrive > > in my laptop so I often do drastic things when I install a new distribution. > > Thats actually an incredibly hard problem to solve. The only people who do > this level of stuff are some of the telephony folks, and the expensive > tandem non-stop boxes. > > Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Could you please send me that peace of code to parse/loading config.in, It would be interesting thing to do. Thanks, John. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VFS locking & HFS problems (2.4.6pre6)
On Fri, 29 Jun 2001, Benjamin Herrenschmidt wrote: > The deadlock happen in the HFS filesystem in hfs_cat_put(), apparently > (quickly looking at addresses) in spin_lock(). Uh-oh. Looks like hfs_cat_put() grabs some internal spinlock and calls write_entry(). If it really is what its name implies, you are calling a blocking function under the spinlock. > So my question: Is there any document explaining the various locking > requirements & re-entrency possibilities in a filesystem. There is, but this bug has nothing fs-specific in it. You should never block while holding a spinlock. BTW, looks like 2.2 has the same bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
>No 'debug=' could then simply cause the kernel to kprint any info from >drivers/modules that failed to load, else keep schtum. My idea is that the driver announces itself, and then what it has found/initialized, in the minimum number of screen lines possible. I'd want that to be the default, because it gives you a decent idea of where it was if it failed. I am envisioning an algorithm like this: 1. Printk name and version 2. initialize self 3. Hunt for devices, printk when you find one 4. Initialize this device 5. Go back to 3 until you don't detect any more devices 6. Do whatever final thing needs doing Note that I only advocate the two printk's mentioned explicitly. I think this provides just enough of a clue to give one an idea of what might have gone wrong, so you might be able to make a quick fix even before needing to enter a "tell me everything you are doing" mode for debugging. More might be nice, but balance is good. I agree with some folks that this is way too much from some drivers. The giant per CPU tables are an example. That's a useful thing if you are a kernel developer, or are trying to debug something weird, but it too much information for someone like me, who knows the code works most of the time. If I see an error, I'm going to replace the CPU, not write new code. On the other hand, I do like the v for version, etc thing, but I think I would have it like this: v for version i for initiation progress (devices and options) d for debugging (or tell me every major step you take) q for quiet (Just the kernel version and the word "Loading" and a spinner of some sort) s for "shut up shuttin' up!" (Nothing, or maybe some custom module for the embedded installations) Obviously, the last two are exclusive with the first three. I'd make it so including them after the other cancels them, so you could add something temporarily without losing your default. I would default to "vi", no pun intended. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: The latest Microsoft FUD. This time from BillG, himself.
On Fri, 29 Jun 2001, Pavel Machek wrote: > > The biggest improvement would be that users could remain with a version > > that works for them and NOT be forced to pay more money for the same > > functionality (watch out for the XP license virus... also known as > > a logic bomb). > > What is XP license virus? Hi Pavel, I'm not sure it's like a virus, maybe more like a genetic defect. This is Micro$oft's new licensing scheme that made its first appearance with the SR1 edition of Office 2000. I've been subjected to it twice now, with Office 2000 and Office XP. Windows XP will use the same scheme. It seems to be a multifaceted license manager that does the following when installed: 1. Sniffs around the hardware, building a list of what's installed. This serves as a "fingerprint" for the Pea Sea. 2. The user enters the CD "key", a unique serial number for the software you purchased. 3. A new encrypted string containing the sftwe key and the hardware fingerprint is now generated. This new key must be provided to Microsoft where they then generate a third key based on the second. This new key must be entered to "unlock" the software. If this sequence is not followed, Office will run only 50 times, then shut itself down. (I bet it leaves "spoor" somewhere to prevent the average user from just reinstalling from the CD. I heard that Windows XP will run only 5 times before shutdown without the final key. Note that the manager encourages the user to use the automatic method for sending the key to Micro$oft. A form is filled out with name, organization, address, phone number and such before a button is pressed to send your personal profile off to the Borg. The return address has to be valid or you can't get the final, third key. (In all fairness, they will allow telephone key transmittal that can be anonymous. This is what I did from a public phone booth) So, Micro$oft now has lots of information about you. If the CD key is used again they just refuse to send the final key. Further, if your hardware environment changes (adding a new frame buffer, scsi controller, etc) the license manager assumes you copied the whole disk to another computer and are therefore a pirate. It shuts down the package until a new key can be obtained from Micro$oft, presumably after you convince them that you aren't really a crook. "I just added a disk! Please turn my Windows on again! I promise to be good and send you more money in the future.", can be heard across the land. This whole thing will probably be good for the Open Source Movement. We won't have to "pull" users from the Borg, the Borg will start "pushing" them to us. Interesting times in which we live, what? Regards, Lew Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: The latest Microsoft FUD. This time from BillG, himself.
> >I still have my 3.1 package all boxed up in the basement. I remember >impatiently waiting for its arrival. What a disappointment it turned >out to be. > >Mark To say the least. The big thing in the current Windows OS's these days is FAT 32. NT 3.1 and NT 3.5 won't even acknowledge this file system. And the ATAPI.SYS file they used is a joke. The first thing you need to do when you install NT is to install a new ATAPI.SYS that would at least see all your partitions. Windows 2000 is far better in this respect, but it's a bloated pig. And I won't even talk about XP. Minimum memory required for XP is 128 Megs. And this license bullsh*t is just an insult to the consumers. Thank the Heavens for Linux! -- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Keyboard errors with 2.4.5-ac
> is it totally hopeless to want to try and get a USB keyboard to work > as the systems only keyboard and have it work under X > and also not freeze the whole system when hitting certain keys? I just tried, and everything works flawlessly here [2.4.6pre5]. In case you see strange things for some keys but not for others, try finding out what the keycodes are (say, with showkey). Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hi David. >> Perhaps even a boot flag of some sort to de-activate the >> printing of the /proc/credits during the kernel boot sequence. >> Or would the community rather an opt-in scenario... > KERN_BANNER Where would you put that in the sequence? Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCI bridge setup error in linux-2.4.x (anyone of them)
On Fri, Jun 29, 2001 at 09:00:01PM +0200, Martin Dalecki wrote: > I ahve a PC box at hand, which ist containing 8 PCI slots. > Four of them are sitting behind a PCI bridge. > The error in the new kernel series is that during the > PCI bus setup if a card is sitting behind the bridge, it > will be miracelously detected TWICE. Once in front of the > bridge and once behind the bridge. The initialisation of > the card will then be entierly hossed. > > This00:02.0 PCI bridge: Intel Corporation 80960RP [i960 RP > Microprocessor/Bridge] (rev 03) > 00:02.1 I2O: Intel Corporation 80960RP [i960RP Microprocessor] (rev 03) > 00:03.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 02) > > 00:06.0 System peripheral: Hewlett-Packard Company NetServer Smart IRQ > Router (rev a0) > 00:08.0 VGA compatible controller: Cirrus Logic GD 5446 (rev 45) > 00:0f.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) > 00:0f.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) > 00:0f.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) > 00:0f.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) > 00:10.0 Host bridge: Intel Corporation 450NX - 82451NX Memory & I/O > Controller (rev 03) > 00:12.0 Host bridge: Intel Corporation 450NX - 82454NX PCI Expander > Bridge (rev 02) > 02:04.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] > (rev 74) > oops:~ # > doesn't happen under linux-2.2.x kernel series. > I have an ITI-4280UE multifunction card (two Symbios Logic 875's and a DEC21140 fast ethernet) which also has such a bridge (rev 02, even) and have noticed nothing wrong until 2.4.5-ac19 (haven't tested further). Jurriaan -- ... thy successors will not thank thee for it, but rather shall revile thy works and curse thy name, and word of this might get to thy next employer. Henry Spencer - The Ten Commandments for C programmers (Annotated Ed.) GNU/Linux 2.4.5-ac19 SMP/ReiserFS 2x1402 bogomips load av: 0.00 0.01 0.05 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: The latest Microsoft FUD. This time from BillG, himself.
> -Original Message- > From: Paul Fulghum [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 4:02 PM > To: Pavel Machek; [EMAIL PROTECTED]; Schilling, Richard; > [EMAIL PROTECTED]; Henning P. Schmiedehausen; > [EMAIL PROTECTED] > Subject: Re: The latest Microsoft FUD. This time from BillG, himself. > > > > Is this accurate? I never knew NT was mach-based. I do not think NT > > 1-3 were actually ever shipped, first was NT 3.5 right? > > Pavel > > NT 3.1 was the 1st to ship. > I still have my 3.1 package all boxed up in the basement. I remember impatiently waiting for its arrival. What a disappointment it turned out to be. Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: The latest Microsoft FUD. This time from BillG, himself.
> Is this accurate? I never knew NT was mach-based. I do not think NT > 1-3 were actually ever shipped, first was NT 3.5 right? > Pavel NT 3.1 was the 1st to ship. Paul Fulghum [EMAIL PROTECTED] Microgate Corporation www.microgate.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PCI bridge setup error in linux-2.4.x (anyone of them)
I ahve a PC box at hand, which ist containing 8 PCI slots. Four of them are sitting behind a PCI bridge. The error in the new kernel series is that during the PCI bus setup if a card is sitting behind the bridge, it will be miracelously detected TWICE. Once in front of the bridge and once behind the bridge. The initialisation of the card will then be entierly hossed. This00:02.0 PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (rev 03) 00:02.1 I2O: Intel Corporation 80960RP [i960RP Microprocessor] (rev 03) 00:03.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 02) 00:06.0 System peripheral: Hewlett-Packard Company NetServer Smart IRQ Router (rev a0) 00:08.0 VGA compatible controller: Cirrus Logic GD 5446 (rev 45) 00:0f.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:0f.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:0f.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:0f.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:10.0 Host bridge: Intel Corporation 450NX - 82451NX Memory & I/O Controller (rev 03) 00:12.0 Host bridge: Intel Corporation 450NX - 82454NX PCI Expander Bridge (rev 02) 02:04.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) oops:~ # doesn't happen under linux-2.2.x kernel series. Here is the output of lspci on this box after I moved the card in front of the bridge: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a couple of NICs that don't NIC
John Jasen wrote: > kernels: 2.4.4 > > drivers used: kernel 8139too > > symptoms: the system would hang under heavy network traffic, and need to > be powercycled backed to life. fixed in 2.4.6-pre6 -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
> Almost always ? > It seems like gcc is THE ONLY program which gets > signal 11 > Why the X server doesn't get signal 11 ? > Why others programs don't get signal 11 ? ... > Some time ago I installed Linux (Redhat 6.0) on my > pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a > couple every hour) I was upgrading > the kernel every time there was a new kernel and > from 2.2.12(or 14) no more signal 11 (very rare) > Is this still a hardware problem ? It could be. One possible way: 1. your system is clogged with dust 2. gcc runs the CPU hard, generating lots of heat 3. the heat causes crashes 4. a new Linux version that sets a Cyrix-specific power-saving mode 5. your heat problems go away, and so do the crashes Another possible way: 1. you have buggy motherboard or disk hardware 2. when you swap, gcc gets corrupted by the hardware 3. you get a new Linux kernel that has a bug work-around 4. your problems go away Yet another way: 1. your room is hot, your computer is near a huge motor... 2. you upgrade to Linux 2.2.12 and move your computer 3. soon you realize that the crashes are gone 4. you credit the kernel, but location was the problem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cs46xx and 2.4.6-pre6
Hi, Suspect the #define CS46XX_APCI_SUPPORT 1 found in cs46xxpm-24.h is bogus. With it defined I can conflicts between it an cs46xx.c with cs46xx_suspend_tlb and cs46xx_resume_tbl Removed the #define and the module built. Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Dan Kegel wrote: > Pseudocode: > > sigemptyset(); > sigaddset(SIGUSR1, ); > fd=sigopen(); > m=read(fd, buf, n*sizeof(siginfo_t)) > close(fd); > > should probably be equivalent to > > sigemptyset(); > sigaddset(SIGUSR1, ); > struct sigaction newaction, oldaction; > newaction.sa_handler = dummy_handler; > newaction.sa_flags = SA_SIGINFO; > newaction.sa_mask = 0; > sigaction(SIGUSR1, , ); I forgot to mask off the signal to avoid traditional delivery: sigprocmask(SIG_BLOCK, , ); > for (i=0; i if (sigwaitinfo(, buf+i)) > break; > m = n * sizeof(siginfo_t); > sigaction(SIGUSR1, , 0); sigprocmask(SIG_UNBLOCK, ); > (apologies if any of the above is wrong) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
back when I was doing PC repair (1.x kernel days) I started useing linux becouse the boot messages gave me so much info about the system (I started to keep a Slackware boot/root disk set on hand so when faced with a customer machine I could boot and see what hardware was actually installed) make a boot option to turn on the verbose mode if you want, but don't eliminate it completely. David Lang On Fri, 29 Jun 2001, Holger Lubitz wrote: > Date: Fri, 29 Jun 2001 15:43:25 +0200 > From: Holger Lubitz <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Newsgroups: lists.linux.kernel > Subject: Re: Cosmetic JFFS patch. > > Miquel van Smoorenburg proclaimed: > > You know what I hate? Debugging stuff like BIOS-e820, zone messages, > > dentry|buffer|page-cache hash table entries, CPU: Before vendor init, > > CPU: After vendor init, etc etc, PCI: Probing PCI hardware, > > ip_conntrack (256 buckets, 2048 max), the complete APIC tables, etc > > Well, I _like_ the fact that my machine tells me all that when booting > (ok, maybe the APIC tables are a little bit much). Believe it or not - > the detailed boot messages were one of the reasons I chose Linux over > BSD back in 1993 when I started. I think it gives a valuable feeling for > what the OS is up to - even to the unexperienced. > > A boot parameter for the verbosity would be ok, though. But I'd still > vote for the default to be pretty verbose. Leave it to the distributors > to disable it, if they want. > > After all - how often does the average linux machine boot? Once a day at > most. Mine usually run until the next kernel upgrade. But then again, > I'm not a kernel hacker, so this is to be taken more as a users point of > view. > > Holger > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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: Q: sparse file creation in existing data?
Phil writes: > though looking and grepping through the sources I couldn't find a way (via > fcntl() or whatever) to allow an existing file to get holes. > > What I'd like to do is something like > > fh=open( ... , O_RDWR); > lseek(fh, position ,SEEK_START); > // where position is a multiple of fs block size > fcntl(fh,F_MAKESPARSE,16384); > > to create a 16kB hole in a file. > If the underlying fs doesn't support holes, I'd get ENOSYS or something. Peter Braam <[EMAIL PROTECTED]> implemented such a syscall, and support for it in ext2, in the 2.2 kernel. It is called "sys_punch" (punching holes in a file). I'm not sure how applicable the patch is in the 2.4 world (probably not at all, unfortunately). I did a port of this code to 2.2 ext3 a long time ago, but have not kept it updated. I'm not sure it was 100% race free (Al would probably say not), but it worked well enough while I was using it. The basic premise is that it will write zero's to partial blocks at the beginning and end of the punch region, and make holes of any intervening blocks. It did NOT do checks to see if a partial block was entirely zero filled and make it a hole (although that would be a possible feature). It could be used as a replacement for the truncate code, because then truncate is simply a special case of punch, namely punch(0, end). > What I'd like to use that for: > > I imagine having a file on hd (eg. tar) and not enough space to decompress. > So with SOME space at least I'd open the file and stream it's data to tar, > after each few kB read I'd free some space - so this could eventually succeed. > > I also thought about simple reversing the filedata - so I'd read off the > end of the file and truncate() downwards - but that would mean reversing > the whole file which could take some time on creation and would solve only > this specific case. I'm not sure I would agree with your application, but I do agree that there are some uses for it. In Peter's case he used it for implementing a cacheing HFS storage system, but he also wanted to use it for InterMezzo (a cacheing network filesystem) to do several things: - delete entries from a transaction log, in a way that actually reduces the physical size of the log. The log itself could be always appended to the end (for 64-bit file size), but transactions/blocks would be punched from the beginning. - delete blocks from the beginning/middle of large files cached on the client. This is useful if the file size is too large to fit into the cache, or if you are doing some sort of LRU replacement of blocks in the cache. I don't think any of this has been implemented in InterMezzo yet. 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: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)V3
Andre Hedrick wrote:
>
> That is a legacy bit from ATA-2 but it is one of those things you can not
> get rid of :-( even thou things are obsoleted, they are not retired.
> This means that you have to go back into the past to see how it was used,
> silly! I hope you agree to that point.
No,
in ANSI X3.279-1996, "AT Attachment Interface with Extensions (ATA-2)",
Approved September 11, 1996 , control register bit 3-7 are reserved.
However ANSI X3.221-1994, "AT Attachment Interface for Disk Drives",
Approved May 12, 1994, bit3 is "1" and bits 4-7 are "x". No further explanation.
How far back must we go, to get the sense ?
>
> This is the drive->ctrl register pointer.
>
> outp(drive->ctl|0x02, IDE_CONTROL_REG);
>
> typedef union {
> unsigned all: 8;/* all of the bits together */
> struct {
> unsigned bit0 : 1;
> unsigned nIEN : 1;/* device INTRQ to host */
> unsigned SRST : 1;/* host soft reset bit */
> unsigned bit3 : 1;/* ATA-2 thingy */
> unsigned reserved456: 3;
> unsigned HOB: 1;/* 48-bit address ordering */
> } b;
> } control_t;
>
> This is a new struct that is to be added for 48-bit addressing and it will
> reflect drive->ctl soon. I have not decided how to use it best or at all,
> but it has meaning and once I add-in the real def of bit3 then I will not
> need to look it up again.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: The latest Microsoft FUD. This time from BillG, himself.
Hi! > > I'm unimpressed with what Microsoft calls an operating system and > > I'm equally unimpressed with what Unix calls an application layer. > > For the last 10 years, Unix has gotten the OS right and the apps wrong > > and Microsoft has gotten the apps right and the OS wrong. Seems like > > there is potential for a win-win. > > I'm equally unimpressed by their applications - how many macro viruses > exist? How do they propagate? How many times do they change file formats? > How many patches are (re)issued to "fix" the same problem? > > The biggest improvement would be that users could remain with a version > that works for them and NOT be forced to pay more money for the same > functionality (watch out for the XP license virus... also known as > a logic bomb). What is XP license virus? Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
Hi! > > (i.e. counted). An alternative to queuing (user selectable) is to block > > interrupt generation at hardware level in kernel space immediately > > before notification. > > > > I'm missing something? > > IRQ 9 shared between user space app and disk. IRQ arrives is disabled and > reported, app wakes up, app wants to page in code, IRQ is disabled, > box dies Actually, what about specifying that your usermode app has to be pagelocked? Alternatively You *can* do disk I/O without interrupts. Just poll your IDE controller. [I'm doing that on my velo.] Hopefully your timer IRQ is not shared with usermode app, then :-( [but that's almost impossible on PCs, right?]. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
Hi! > Hmm. This *is* the company that has at least one guy full-time working on > merging their changes back into gcc (with the right Copyright > assignments), and where the guy in question does discuss how to make gcc > work nice with both Apple's application framework and the GPL clone of it. > > Oh, and one intern working right now to improve gcc's errors-and-warnings > code, because that's what the gcc list came up with as a task. > > Sure, that's not many people in such a large company, but it's a vast > difference from MS, and it's also a vast difference from the earlier Apple > from the look-and-feel lawsuit age. Take a look at themes.org. They are basicaly trying to sue anyone who makes something similar to their aqua. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
Hi! > >No. The IRQ might be shared, and you get a slight problem if you just disabled > >an IRQ needed to make progress for user space to handle the IRQ > > Two choices: > > - Disallow shared interrupts for usermode drivers. That's hard... If you your notebook comes with soundcard and ltmodem sharing the irq, and ltmodem only has userspace driver, you are screwed. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
Hi! > I wouldn't be at all suprised if they did. It'd fit in with the history of > NT. (Version numbers really approximate, I don't have my notes with me.) > > NT 1.0: the inherited OS/2 1.x code ported to 32 bit mode, sort of. > > NT 2.0: 1.0 didn't work so let's try porting it to the mach microkernel. > > NT 3.0: that didn't work either, so let's hire Dave Cutler (chief unix hater > at Digital research and ex-head of the VAX VMS operating system) to port VMS > on top of the steaming pile of code that is NT. > > NT 3.5: punch holes in the mach microkernel to get some performance, try to > fix some of the more obvious bugs. > > NT 4.0 stabilized (a bit) because dave cutler (and the team under him) was > still around. They hadn't yet again changed horses in midstream. > Eventually, with the same team working on the same code, it's bound to > stabilize a bit.) Bloated a bit as well, but that's proprietary software for > you. Is this accurate? I never knew NT was mach-based. I do not think NT 1-3 were actually ever shipped, first was NT 3.5 right? Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
Hi! > I realize that the Linux kernel supports user > level drivers (via ioperm, etc). However interrupts > at user level are not supported, does anyone think > it would be a good idea to add user level interrupt > support ? I have a framework for it, but it still > needs > a lot of work. > > Depending on the response I get, I can send out > more email. Please cc me to the replies as I am no > longer a part of the Linux kernel mailing list - due > to the humble size of my mail box. I'd like to see that done for userspace ltmodem driver... Unfortunately it can not be easily done for shared PCI interrupts. Pavel PS: Next needed thing is to make it possible for usermode driver to "mimic" kernel one, including ioctls. -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Any gain to supporting only a single PCMCIA slot?
Hi! > PCMCIA/Cardbus controllers typically (always?) support 2 slots, and system > resources are allocated to support those slots. When you build PCMCIA > support into your kernel, you are implicitly asking for both slots to be > supported. I'm wondering if it would be worthwhile to let the user opt out of > supporting one of the slots. > > Compaq, in their finite wisdom, only provides a single Type2 Cardbus slot > on my Presario 1260 notebook. The controller (a TI PCI1131, see below) > can handle 2 slots, of course, but only a single physical connector is > present on this machine. Therefore I will never get the use of half of > the controller, including the I/O address, etc. that the kernel has > allocated for it. > Would it be worth the savings in system resources to allow support for > only a single slot? Probably not. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kill unused crap in putuser.S
Hi!
Yup. Whole putuser.S is unused. Either it should be killed [as my
patch suggests], or ... well ... it should be used.
Please either apply or say how you'd like this to be fixed.
Pavel
PS: Tested on i386, both make and make modules works ok.
--- clean/arch/i386/lib/putuser.S Mon Jan 12 22:37:26 1998
+++ linux/arch/i386/lib/putuser.S Thu Jun 28 12:53:09 2001
@@ -1,71 +0,0 @@
-/*
- * __put_user functions.
- *
- * (C) Copyright 1998 Linus Torvalds
- *
- * These functions have a non-standard call interface
- * to make them more efficient.
- */
-
-/*
- * __put_user_X
- *
- * Inputs: %eax contains the address
- * %edx contains the value
- *
- * Outputs:%eax is error code (0 or -EFAULT)
- * %ecx is corrupted (will contain "current_task").
- *
- * These functions should not modify any other registers,
- * as they get called from within inline assembly.
- */
-
-addr_limit = 12
-
-.text
-.align 4
-.globl __put_user_1
-__put_user_1:
- movl %esp,%ecx
- andl $0xe000,%ecx
- cmpl addr_limit(%ecx),%eax
- jae bad_put_user
-1: movb %dl,(%eax)
- xorl %eax,%eax
- ret
-
-.align 4
-.globl __put_user_2
-__put_user_2:
- addl $1,%eax
- movl %esp,%ecx
- jc bad_put_user
- andl $0xe000,%ecx
- cmpl addr_limit(%ecx),%eax
- jae bad_put_user
-2: movw %dx,-1(%eax)
- xorl %eax,%eax
- ret
-
-.align 4
-.globl __put_user_4
-__put_user_4:
- addl $3,%eax
- movl %esp,%ecx
- jc bad_put_user
- andl $0xe000,%ecx
- cmpl addr_limit(%ecx),%eax
- jae bad_put_user
-3: movl %edx,-3(%eax)
- xorl %eax,%eax
- ret
-
-bad_put_user:
- movl $-14,%eax
- ret
-
-.section __ex_table,"a"
- .long 1b,bad_put_user
- .long 2b,bad_put_user
- .long 3b,bad_put_user
-.previous
--- clean/arch/i386/kernel/i386_ksyms.c Tue Jun 5 21:37:20 2001
+++ linux/arch/i386/kernel/i386_ksyms.c Fri Jun 29 00:18:50 2001
@@ -90,9 +90,6 @@
EXPORT_SYMBOL_NOVERS(__get_user_1);
EXPORT_SYMBOL_NOVERS(__get_user_2);
EXPORT_SYMBOL_NOVERS(__get_user_4);
-EXPORT_SYMBOL_NOVERS(__put_user_1);
-EXPORT_SYMBOL_NOVERS(__put_user_2);
-EXPORT_SYMBOL_NOVERS(__put_user_4);
EXPORT_SYMBOL(strtok);
EXPORT_SYMBOL(strpbrk);
--- clean/include/asm-i386/uaccess.hTue May 8 11:43:51 2001
+++ linux/include/asm-i386/uaccess.hThu Jun 28 12:52:48 2001
@@ -129,12 +129,6 @@
extern void __put_user_bad(void);
-#define __put_user_x(size,ret,x,ptr) \
- __asm__ __volatile__("call __put_user_" #size \
- :"=a" (ret) \
- :"0" (ptr),"d" (x) \
- :"cx")
-
#define put_user(x,ptr)\
__put_user_check((__typeof__(*(ptr)))(x),(ptr),sizeof(*(ptr)))
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
Hi! > > The problem is that the IRQ has to be cleared in > > kernel space, because otherwise > > you may deadlock. > > > > I agree, the idea is to clear the IRQ in kernel space > and then deliver to user level programs interested ...*IF* you know how to clear it. THat differs device-to-device. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: CLOSE_WAIT Problem
Chriss wrote: > I wrote a simple server application and installed it on a linux machine > in Slovakia, running Mandrake 7.2 (2.2.18). > That machine loses tcp/ip packages, as it uses a Microwave connection. > So my server works all the time, and the tcp/ip connections are set to > TIME_WAIT, but after a couple of hours > my server application won't get any connections anymore and the netstat > shows a lot of CLOSE_WAITs that belong to the server. > I've installed the same server on two SuSE 7.1 (2.2.18) machines in > Austria, and the problem never occured. > So does anyone know how to avoid that CLOSE_WAITs, or at least how to > get rid of them? Dunno if this will help, but: They're supposed to go away by themselves after 2MSL (about 120 seconds). Other people (on many operating systems) have reported similar problems, btw: http://uwsg.iu.edu/hypermail/linux/net/9611.2/0043.html http://www.sunmanagers.org/pipermail/sunmanagers/2001-April/002894.html http://www2.real-time.com/tclug-list/1999/Jun/msg00254.html http://mail-index.netbsd.org/netbsd-bugs/1996/04/16/0004.html The last one has a fix for an old bug in netbsd that could cause this. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: core dump problem with a multi-threaded program
> multi-threaded program is not possible under RedHat Linux 7.1 (kernel > version 2.4.2-2), because loading the core into gdb 5.0 does not show > the correct crash location. 2.4.2 doesn't support multithreaded core dumps. The RH errata kernel will generate a dump for each thread as/if/when that thread crashes You can then inspect the relevant core.pid file, I've no idea how well the gdb thread stuff works with it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Hi, > Many new Linux users go through an extended period of dual-booting. And many users also have to sleep in the same room as their computers (still live w/ parents or are in college) and the fans bother them, so they turn them off every night. Just my 2 eurocents. -- Chris Boot [EMAIL PROTECTED] "use the source, luke." (obi-wan gnuobi) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
core dump problem with a multi-threaded program
Hi,
We are facing the problem that a post-mortem investigation of a
multi-threaded program is not possible under RedHat Linux 7.1 (kernel
version 2.4.2-2), because loading the core into gdb 5.0 does not show
the correct crash location.
Attached is a test program, linux.c.
This is a producer-consumer program, with pairs of threads sending each
other messages. Its structure is described in comments at the very
beginning of source code. If 0 is typed as stdin, a divide-by-zero
exception happens.
If you use GDB to look into the core, you'll see it gets some errors
while loading, and doesn't show the correct line which causes the
arithmetic exception:
rock[19] gdb yahuitest/p15 core
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `yahuitest/p15 10'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/i686/libpthread.so.0...done.
warning: Unable to set global thread event mask: generic error
[New Thread 1024 (LWP 5458)]
Error while reading shared library symbols:
Can't attach LWP 5458: No such process
...
Obviously, if one runs the program in the debugger, it shows the correct
location.
Another problem is that core is not always dumpable. I repeat running
this program with 0.csh script as attached. You'll find it stops with no
core dumped after few iterations.
Does anyone know if this is a problem that we can work-around with the
current versions of the kernel (eg. setting a signal handler, etc)? Do
we need a newer version of GDB?
Thanks.
Yahui
0.csh
/* linux.c
*
* This is a N-paired program. Each consumer takes message from the buffer in which
* the corresponding producer puts data. Each pair is independent of the others.
* A producer is randomly picked to read from stdin. If 0 is typed as stdin, an
* arithmetic exception happens. Core file is expected to dump at this point.
* Mutex is used to synchronize the communication between producer and consumer.
* To guarantee each message is consumed before producer puts in new one, condition
* variables are used.
*
* command line: linux 100
* The second argument is the time (microseconds) the producer sleeps aftet each
* iteration.
*
* Written by Yahui Lin
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define NUMPAIRS 15
int buffer[NUMPAIRS];
int seg_fault;
int p_sleep;
pthread_mutex_t prod_mutex[NUMPAIRS], cons_mutex[NUMPAIRS];
pthread_t prod_id[NUMPAIRS], cons_id[NUMPAIRS];
pthread_cond_t prod_cond[NUMPAIRS], cons_cond[NUMPAIRS];
void *producer(void *arg);
void *consumer(void *arg);
void sighandler(int sig)
{
if( sig != SIGFPE )
fprintf(stderr, "unexpected signal in handler: %d\n", sig);
else
abort();
}
int main(int argc, char *argv[])
{
inti;
struct sigaction act;
sigset_t mask_sig;
if( argc != 2 )
{
fprintf(stderr, "usage: %s prod_sleep_time\n", argv[0]);
exit(1);
}
if( (p_sleep = atoi(argv[1])) < 0 )
p_sleep = 0;
sigemptyset(_sig);
sigaddset(_sig, SIGFPE);
act.sa_handler = sighandler;
act.sa_mask = mask_sig;
act.sa_flags = 0;
if(sigaction(SIGFPE, , NULL) == -1){
perror("sigaction error");
exit(1);
}
for(i=0; i
USB Keyboard errors with 2.4.5-ac
I encountered a rather weird problem last night. I was testing out a USB Type 6 Unix layout keyboard from Sun Microsystems and a USB Crossbow model mouse from Sun as well. I like the Sun keyboard and mice and am used to the layout from using it so often at work. I originally thought that it would be no big deal since they both work perfectly in Windows (tested while at work on my Windows 2000 box). When I got them home and tried them out I noticed one thing immediately that I could easily get the mouse to work with GPM and also I could unplug it and plug it back in with no problem as all. The keyboard was a different story, if I plug the keyboard in during operation everything freaks out and I have to reboot the machine to get it to work properly. I also noticed that X would not work properly if I had either the USB keyboard and a PS/2 keyboard plugged in or if I had the USB keyboard plugged in alone. No matter what I tried I could not get X to work, but while trying I noticed my real problem with the keyboard. The kernel apparently expects a PS/2 (AT) keyboard to be plugged in because if there isn't one the kernel reports timeouts and seems slower than when there is a PS/2 keyboard present, my guess is because it is waiting on all of those timeouts. The next major keyboard thing I noticed is that I can type on certain keys but if I do anything like hit the caps lock key or number lock a couple of times then the keyboard stops responding completely and the kernel tells me that there was an error waiting on a IRQ on CPU #1. So I guess my questions are the following, is it totally hopeless to want to try and get a USB keyboard to work as the systems only keyboard and have it work under X and also not freeze the whole system when hitting certain keys? Do I just need to give up for now and get one of those USB->PS/2 converters and use my normal keyboard port, if so will Linux ever be able to not depend on PS/2 hardware for keyboards on ix86? I am not looking for anything fancy here, I mean all the extra keys on it like front, stop etc. would be nice to use eventually but if they do absolutely nothing that is fine with me, I just want to be able to use this keyboard. Below are the pertinent .config sections, this is on a Tyan Tiger 230 which uses a Via chipset. The mouse is still working right now and X works if I have a PS/2 keyboard only plugged in and just use the mouse. Thanks for any help you can give me. Jordan Breeding # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # Input core support # CONFIG_INPUT=y CONFIG_INPUT_KEYBDEV=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set CONFIG_USB_LONG_TIMEOUT=y CONFIG_USB_LARGE_CONFIG=y CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set CONFIG_USB_UHCI=y # CONFIG_USB_UHCI_ALT is not set # CONFIG_USB_OHCI is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set CONFIG_USB_HID=y CONFIG_USB_HIDDEV=y # CONFIG_USB_WACOM is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HP5300 is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_DABUSB is not set # CONFIG_USB_PLUSB is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # CONFIG_USB_RIO500 is not set # # Bluetooth support # # CONFIG_BLUEZ is not set - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Linux Sparc V9 code optimazation
To any Sparc guru, This question relates to the effect of instruction alignment on a Sparc's Prefetch/Dispatch unit. Just how exactly does the branch prediction bits for instruction pairs in the I-Cache utilized. I'm trying to figure out the consequences of an odd word fetch into an Instruction cache line with a the fourth instruction being another branch. Please cc me as I am currently not on the mailing list. Ramil J.Santamaria Toshiba America Information Systems (949) 461-4379 (949) 206-3439 - fax [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: alpha - generic_init_pit - why using RTC for calibration?
On Fri, Jun 29, 2001 at 04:20:59PM +0400, Oleg I. Vdovikin wrote:
> we've a bunch of UP2000/UP2000+ boards (similar to DP264) with 666MHz
> EV67 Alphas (we're building large Alpha cluster). And we're regulary see
> "HWRPB cycle frequency bogus" and the measured value for the speed in the
> range of 519 MHz - 666 MHz. And this value changes in this range from boot
> to boot. So why this happens???
This is known problem with Cypress cy82c693 SIO. The RTC on this chip
sometimes need a very long time (up to several minutes) to settle down
after reset/power-up. But I thought it's fixed on newer systems with
"ub" revision of the chip... :-(
> So, the final question: why we're not using the aproach which is used by
> x86 time.c? I.e. why not to use CTC channel 2 for calibration?
Good idea. The patch below works reliably on my sx164.
Ivan.
--- 2.4.6-pre5/arch/alpha/kernel/time.c Mon Nov 13 06:27:11 2000
+++ linux/arch/alpha/kernel/time.c Fri Jun 29 20:58:09 2001
@@ -169,6 +169,63 @@ common_init_rtc(void)
init_rtc_irq();
}
+/*
+ * Calibrate CPU clock using legacy 8254 timer/counter. Stolen from
+ * arch/i386/time.c.
+ */
+
+#define CALIBRATE_LATCH(52 * LATCH)
+#define CALIBRATE_TIME (52 * 120 / HZ)
+
+static unsigned long __init
+calibrate_cc(void)
+{
+ int cc;
+ unsigned long count = 0;
+
+ /* Set the Gate high, disable speaker */
+ outb((inb(0x61) & ~0x02) | 0x01, 0x61);
+
+ /*
+* Now let's take care of CTC channel 2
+*
+* Set the Gate high, program CTC channel 2 for mode 0,
+* (interrupt on terminal count mode), binary count,
+* load 5 * LATCH count, (LSB and MSB) to begin countdown.
+*/
+ outb(0xb0, 0x43); /* binary, mode 0, LSB/MSB, Ch 2 */
+ outb(CALIBRATE_LATCH & 0xff, 0x42); /* LSB of count */
+ outb(CALIBRATE_LATCH >> 8, 0x42); /* MSB of count */
+
+ cc = rpcc();
+ do {
+ count++;
+ } while ((inb(0x61) & 0x20) == 0);
+ cc = rpcc() - cc;
+
+ /* Error: ECTCNEVERSET */
+ if (count <= 1)
+ goto bad_ctc;
+
+ /* Error: ECPUTOOFAST */
+ if (count >> 32)
+ goto bad_ctc;
+
+ /* Error: ECPUTOOSLOW */
+ if (cc <= CALIBRATE_TIME)
+ goto bad_ctc;
+
+ return ((long)cc * 100) / CALIBRATE_TIME;
+
+ /*
+* The CTC wasn't reliable: we got a hit on the very first read,
+* or the CPU was so fast/slow that the quotient wouldn't fit in
+* 32 bits..
+*/
+bad_ctc:
+ return 0;
+}
+
void __init
time_init(void)
{
@@ -176,6 +233,9 @@ time_init(void)
unsigned long cycle_freq, one_percent;
long diff;
+ /* Calibrate CPU clock -- attempt #1. If this fails, use RTC. */
+ if (!est_cycle_freq)
+ est_cycle_freq = calibrate_cc();
/*
* The Linux interpretation of the CMOS clock register contents:
* When the Update-In-Progress (UIP) flag goes from 1 to 0, the
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: artificial latency for a network interface
> > I wanted to do that using two tun devices. > > I had hoped to have a routing like this: > > > > <-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1 > >yes, that works very well. A userspace app sits on top of the >tun/tap device and pulls out packets, delays them and reinjects >them. Right. And you don't even need tun1. Just write them back to tun0. >The problem is routing: when you send the packet back to the >kernel, it sends it straight back to you. You need to rewrite >the headers, which is a pain. True. Max Maksim Krasnyanskiy Senior Kernel Engineer Qualcomm Incorporated [EMAIL PROTECTED] http://bluez.sf.net http://vtun.sf.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: 2.4.5 NFS io errors
> " " == J R de Jong writes: > Hi all, Recently I upgraded from 2.4.4 to 2.4.5, but after that > I got users complaining about io errors on some mounted NFS > systems on some files, whenever they tried to stat (ls) or open > the file. Even after several reboots (other files failed tho). > Going back to 2.4.4 solved the problem. I don't know if this > problem has been adressed already. Sounds like you're using soft mounts? Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Problems with 2.4.5ac21
Hi, with the newest kernel linux-2.4.5ac21 I am not able to activate the ppp network device an dits options. Regardless what I am doing, the setting will not be stored into .config... Any trick to avoid this ? Thanks for any help in advance! (PS: I am currently not on the kernel list, please answer also to my email address. Thank you!) keep hacking the right site of life ! :-) Meino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A Possible 2.5 Idea, maybe?
> Thats why we have /proc/... To echo things into it. I don't know of a proc entry that lets the user tell the VM not to cache as much or use swap in a different manner. > Several kernel threads are hard to maintain, hard to evolve, hard to > bugfix, modify patches, etc. Mainly, we should have a single kernel that > can be tuned to fit people's needs. I agree that keeping several threads would be difficult, but is there not a way to have certain values plugged into the code for something like cache pressure before swapping, or extended boot messages instead of a quiet boot? These values would be dependant on the config options that were selected in the config. I am not talking about forking the kernel. I am instead talking about a process to select a different concept that the same kernel runs under and have this concept selected at compile time. > IMO, the Linux distributions out there should configure the kernel based > on the type of system the (l[inux])user wants. Those who have the balls to > compile their own system should know such things anyway. The rest, better > rely on the distribution default and/or ask around and get some more > info [the kernel configuration help is explicit enough anyway, given a > decent level of common sense is used]. This leaves several people out in the rain though. First how would a distro make a system that works well for the desktop users if the kernel is designed to work well on servers? Also I should be able to run debian on my desktop if I want without having to suffer through interactivity issues, because debian builds their distros for servers and has most of the hard drives cached. Also I know several people that recompile kernels and such, but have no clue as the process to go through to optimize it for their particular setup. If people are hoping that linux will move into other markets besides servers then you cannot have the attitude that everyone has to suffer with a) what the distros give them or b) be come fluent enought in kernel programming and desgin to be able to edit the code so that it works better for them. Brent Norris Executive Advisor -- WKU-Linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 aic7xxx driver 6.1.11 (fwd)
-- Forwarded message -- Date: Mon, 25 Jun 2001 11:31:32 -0400 (EDT) From: John Jasen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Dima Meschaninov <[EMAIL PROTECTED]> Subject: problems with aic7xxx driver 6.1.11 #1) It seems that the new aic7xxx drivers do not detect raid controllers, et al on the bus, as we have an nStor NexStor 8le that is completely invisible to your driver. #2) There seem to be a few problems with the new driver, where it can easily get confused into a reset loop. (see below for a rough description) -- Forwarded message -- Date: Mon, 25 Jun 2001 11:20:08 -0400 From: Dmitry Meshchaninov <[EMAIL PROTECTED]> To: John Jasen <[EMAIL PROTECTED]> Subject: Description of SCSI situation on zathras Looks like we have had power down at night. Afterwards, the scsi tray was in a strange state - the system BIOS didn't find anything on the bus, and naturally the linux driver didn't either. After we power cycled scsi tray and rebooted the system, the system BIOS detected all the scsi devices but the linux driver still was blind. It said something about timeouts during lun probing and marked all the devicess offline, and we tried it via reboot/powercycle of the system at least 2-3 times. After we setup the old driver everything went fine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
a couple of NICs that don't NIC
In these cases, both network interface cards fall over under moderate to heavy traffic. 1) 01:05.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) kernels: 2.2.19 and 2.4.4 drivers used: kernel eepro100 (2.2.19 and 2.4.4) and intel e100 (2.4.4) symptoms: the system would spontaneously reboot under heavy NFS traffic, with no console or /var/log/messages reports. This could be reliably reproduced by mounting an exported directory, and looping "find /mounted/directory -depth -print | xargs cat >/dev/null" 2) SMC EZNET 10/100 nic, using a realtek chipset kernels: 2.4.4 drivers used: kernel 8139too symptoms: the system would hang under heavy network traffic, and need to be powercycled backed to life. ping -f could cause it, as could the test above. Nothing of interest to report via console or syslog. I've currently replaced these cards with the Netgear FA310 series, using the tulip driver (01:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)) and have had no problems, so being able to help in testing would probably be more difficult. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
- Received message begins Here - > > > --- Jesse Pollard <[EMAIL PROTECTED]> > wrote: > > > > > > > > > "This is almost always the result of flakiness in > > your hardware - either > > > RAM (most likely), or motherboard (less likely). > > " > > > > > > I cannot understand > > this. There are many other > > > stuffs that I compiled with gcc without any > > problem. Again compilation is only > > > a application. It only parse and gernerates > > object files. How can RAM or > > > motherboard makes different > > > > It's most likely flackey memory. > > > > Remember- a single bit that dropps can cause the > > signal 11. It doesn't have > > to happen consistently either. I had the same > > problem until I slowed down > > memory access (that seemd to cover the borderline > > chip). > > > > The compiler uses different amounts of memory > > depending on the source file, > > number of symbols defined (via include headers). > > When the multiple passes > > occur simultaneously, there is higher memory > > pressure, and more of the > > free space used. One of the pages may flake out. > > Compiling the kernel > > puts more pressure on memory than compiling most > > applications. > > > > > - > > Jesse I Pollard, II > > Email: [EMAIL PROTECTED] > > > > Any opinions expressed are solely my own. > > - > > To unsubscribe from this list: send the line > > "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > Almost always ? > It seems like gcc is THE ONLY program which gets > signal 11 > Why the X server doesn't get signal 11 ? > Why others programs don't get signal 11 ? Load the system down with lots of processes/large image windows. Unless the bit in question is in a pointer, or data used in pointer arithmetic or function call it won't segfault. Applications (if an instruction page gets hit) may get an illegal instruction. > I remember that once Bill Gates was asked about > crashes in windows and he said: It's a hardware > problem. > It was also a joke on that subject: > Winerr xxx: Hardware problem (it's not our fault, it's > not, it's not, it's not, it's not...) Yup - because it crashed VERY frequently when it was obviously a software bug. > Seems to me like Micro$oft way of handling problems. > > We must agree that gcc is full of bugs (xanim does not > > run corectly if it is compiled with gcc 2.95.3 > and other programs which use floating point > calculations do the same (spice 3f5)) Generating wrong code is different than a segfault. Currently I'm using egcs-2.91.66 on a 486, without problems. (I don't do floating point on a 486... too slow). > Some time ago I installed Linux (Redhat 6.0) on my > pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a > couple every hour) I was upgrading > the kernel every time there was a new kernel and > from 2.2.12(or 14) no more signal 11 (very rare) > Is this still a hardware problem ? > Was a bug in kernel ? Not likely - It could just depend on whether all of available was used. If the physical page with the problem doesn't get used very often, it won't show up. If the bit in question is not part of a pointer, or used in pointer arithmetic, again it won't show up (actually, any operation on addresses). Wrong, or slightly wrong results MAY show up. > I think the last answer is more obvious.(or the gcc > had a bug and the kernel -- a workaround). > > Sorry for bothering you but in every piece of linux > documentation signal 11 seems to be __identic__ with > hardware problem. > Bye Only when it appears in random location. GCC is a fairly well debugged program and doesn't segfault unless you run out of memory, or flakey memory. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS locking & HFS problems (2.4.6pre6)
> Yup. It's the problem. It locks, then calls some alloc routines, which > fills a cache and uses kmalloc with GFP_KERNEL. Thats quite common. If it can safely sleep there without other deadlocks a semaphore may be better > Turning it into GFP_ATOMIC might not be the best idea as the HFS > filesystem currently shares a single hfs_malloc() for everybody and > turning it into GFP_ATOMIC would cause all of HFS allocs to be atomic. Another approach is to prealloc the object and pass it in, then free it if not needed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac21: make menuconfig errors
I was trying to configure 2.4.5-ac21 when I ran into some problems. First off i noticed this when I went to make menuconfig : root@fire-eyes:/usr/src/linux # make menuconfig rm -f include/asm ( cd include ; ln -sf asm-i386 asm) make -C scripts/lxdialog all make[1]: Entering directory `/usr/src/linux-2.4.5-ac21/scripts/lxdialog' make[1]: Leaving directory `/usr/src/linux-2.4.5-ac21/scripts/lxdialog' /bin/sh scripts/Menuconfig arch/i386/config.in Using defaults found in .config Preparing scripts: functions, parsing..scripts/Menuconfig: ./MCmenu31: line 185: syntax error near unexpected token `fi' scripts/Menuconfig: ./MCmenu31: line 185: `fi' ...make: *** [menuconfig] Error 1 The Error at the end is ONLY BECAUSE I ^c to see the line 185 error, otherwise the menu would have popped up and covered it up. AFter this the menu comes up. And here is another problem .. Network device support ---> Ethernet (10 or 100Mbit) ---> Menuconfig has encountered a possible error in one of the kernel's configuration files and is unable to continue. Here is the error report: Q> scripts/Menuconfig: MCmenu31: command not found Please report this to the maintainer <[EMAIL PROTECTED]>. You may also send a problem report to <[EMAIL PROTECTED]>. Please indicate the kernel version you are trying to configure and which menu you were trying to enter when this error occurred. make: *** [menuconfig] Error 1 I simply skipped that menu, and now I am attempting to continue with the kernel build. I would state here if that failed or not but this is a slow system. I am not on the list, I would appreciate anything important being mailed to me. Or if I get sub instructions back ill sub. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SMP] 2.4.5-ac13 through ac18 dcache/NFS conflict
Just to follow up on this situation, I think I've tracked it down to a problem arising from a combination of SMP, the directory entry cache, and NFS client code. After several 24-hour runs of 10 copies of 'find /nfs-mounted-directory -print > /dev/null' running simultaneously, the kernel stops or dies in fs/dcache.c (in dput() or d_lookup(), and it triggered the BUG() on line 129 once). Performing the same 10 finds on a locally mounted ext2 filesystem produces no lockups or hangs. -Bob > I've got a strange situation, and I'm looking for a little direction. > Quick summary: I get sporadic lockups running 2.4.5-ac13 on a > ServerWorks HE-SL board (SuperMicro 370DE6), 2 800MHz Coppermine CPUs, > 512M RAM, 512M+ swap. Machine has 8 active disks, two as RAID 1, > 6 as RAID 5. Swap is on RAID 1. Machine also has a 100Mbit Netgear > FA310TX and an Intel 82559-based 100Mbit card. SCSI controllers > are AIC-7899 (2) and AIC-7895 (1). RAM is PC-133 ECC RAM; two > identical machines display these problems. > > I've seen three variations of symptoms: > > 1) Almost complete lockout - machine responds to interrupts (indeed, > it can even complete a TCP connection) but no userspace code gets > executed. Alt-SysRq-* still works, console scrollback does not; > 2) Partial lockout - lock_kernel() seems to be getting called without > a corresponding unlock_kernel(). This manifested as programs such > as 'ps' and 'top' getting stuck in kernel space; > 3) Unkillable programs - a test program that allocates 512M of memory > and touches every page; running two copies of this simultaneously > repeatedly results in at least one of the copies getting stuck > in 'raid1_alloc_r1bh'. > > Symptom number 1 was present in 2.4.2-ac20 as well; symptoms 2 and 3 > were observed under 2.4.5-ac13 only. I never get any PANICs, only > these variety of deadlocks. A reboot is the only way to resolve the > problem. > > There seem to be two ways to manifest the problem. As alluded to in > (3), running two copies of the memory eater simultaneously along with > calls to 'ps' and 'top' trigger the bug fairly quickly (within a minute > or two). Another method to manifest the problem is to run multiple > copies of this script (I run 10 simultaneous copies): > > #!/bin/sh > > while /bin/true; do > ssh remote-machine 'sleep 1' > done > > This script causes (1) in about a day or two. > > If anyone has any suggestions about how to proceed to figure out what > the problem is (or if there is already a fix), please let me know. > I would be more than willing to provide a wide range of cooperation on > this problem. I don't have a feel for where to go from here, and I'm > hoping that someone with more experience can give me some > assistance.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
make menuconfig error
hi, i encountered following err during make menuconfig/net device/10mbitcards selection. axel --- Menuconfig has encountered a possible error in one of the kernel's configuration files and is unable to continue. Here is the error report: Q> scripts/Menuconfig: MCmenu31: command not found Please report this to the maintainer <[EMAIL PROTECTED]>. You may also send a problem report to <[EMAIL PROTECTED]>. Please indicate the kernel version you are trying to configure and which menu you were trying to enter when this error occurred. make: *** [menuconfig] Error 1 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS locking & HFS problems (2.4.6pre6)
Alan Cox wrote: >Holding a spinlock while sleeping is an offence punishable by deadlock.. Right, and it's indeed the problem. But I'm still concerned about locking since by using that spinlock, the guy who wrote it did not expect beeing re-entered at this point, and just "cleaning" it may not be enough. >You might also look for memory allocations that are not GFP_ATOMIC made with >the lock held Yup. It's the problem. It locks, then calls some alloc routines, which fills a cache and uses kmalloc with GFP_KERNEL. Turning it into GFP_ATOMIC might not be the best idea as the HFS filesystem currently shares a single hfs_malloc() for everybody and turning it into GFP_ATOMIC would cause all of HFS allocs to be atomic. I can change this single routine (and any other doing the same thing), but I'd rather fix it by making sure HFS can safely sleep at this point and still use GFP_KERNEL. I just found Documentations/filesystems/Locking document, I bet I'll find all the infos I need there. It's amazing how long it took me to look for the info where it logically should be ;) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A Possible 2.5 Idea, maybe?
On Fri, 29 Jun 2001, Brent D. Norris wrote: > Recently one more than one subject there have been comments along the > lines of, "Do x, y and z because it would be great on desktops" and then > someone else will say "NO! becausing doing x, y, and z will make servers > run slow." Then as a final note someone else will say "Do y and z, but > not x, because that will make my handheld linux project a lot better." > Now whatever is eventually decided in each discusion, normally one > group/user walks away feeling they are getting the shortend of the stick. Ok, this is a problem. Though it was sort of discussed before when someone came with the idea of creating a 'home' linux-kernel edition (yuck!). > Now many of these things are configurable. If it is the amount of > messages that the boot of the kernel makes or even the "motivation" and > actions that the VM takes. It seems possible to configure the kernel so > that it would work optimally for each of the groups. The problem is that > the code in these sections is having to work in too different of > situations. Example : The VM is now somewhat more tweaked for servers > than it was previously. Many people were concerned about the > "interactivity" of it. Now it seems that it would be possible to change > the vm code so that it worked better for desktop users, but the > maintainers are not eager to do that because it would slow linux down in > the server market. Thats why we have /proc/... To echo things into it. > This all stems from one problem, which is a really great problem to have > if you must have a problem. Linux is spreading to largely different > kinds of machines with many different purposes. Microsoft solved this > problem by having several different kernels (NT code base for servers, 9x > code base for desktops, CE code base for handhelds), and this is somewhat > like what the "forking is a good thing" messge recommended for linux. I > disagree with that concept though. It is easy to see the trouble > microsoft is having with that and now they are trying to slowly merge the > two (NT,9x) together. Several kernel threads are hard to maintain, hard to evolve, hard to bugfix, modify patches, etc. Mainly, we should have a single kernel that can be tuned to fit people's needs. > Instead of forking the kernel or catering only to one group, instead why > not try this: Using the new CML2 tools and rulesets, make it possible to > have the kernel configured for the type of job it will be doing? Just > like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out > and configures options for that, have it ask people "Is your machine a > server, workstation, embedded/handheld?" and configure things in the > kernel like the VM, bootup and others to optimize it for that job type? IMO, the Linux distributions out there should configure the kernel based on the type of system the (l[inux])user wants. Those who have the balls to compile their own system should know such things anyway. The rest, better rely on the distribution default and/or ask around and get some more info [the kernel configuration help is explicit enough anyway, given a decent level of common sense is used]. Dan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS locking & HFS problems (2.4.6pre6)
Benjamin Herrenschmidt wrote: > > I've had a deadlock twice with 2.4.6pre6 today. It's an SMP kernel > running on an UP box (a PowerBook Pismo). > > The deadlock happen in the HFS filesystem in hfs_cat_put(), apparently > (quickly looking at addresses) in spin_lock(). > Please test this: Index: fs/hfs/catalog.c === RCS file: /opt/cvs/lk/fs/hfs/catalog.c,v retrieving revision 1.2 diff -u -r1.2 catalog.c --- fs/hfs/catalog.c2001/02/17 01:44:39 1.2 +++ fs/hfs/catalog.c2001/06/29 15:54:17 @@ -549,7 +549,7 @@ entry->state &= ~HFS_LOCK; hfs_wake_up(>wait); } - + spin_lock(_lock); return entry; } @@ -559,7 +559,6 @@ if (grow_entries()) goto add_new_entry; - spin_unlock(_lock); return NULL; read_fail: @@ -570,7 +569,6 @@ init_entry(entry); list_add(>list, _unused); entries_stat.nr_free_entries++; - spin_unlock(_lock); return NULL; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Qlogic Fiber Channel
You know, this is probably slightly OTm, but I've been getting closer and closer to what I consider 'happy' for my QLogic megadriver under Linux- I have just a tad more to deal with in local loop failures (I spent far too much time working on fabric only)- but I've been happier with it and need to close it up and move on. I *do* plan to finish IP support eventually. I certainly would like to get more feedback about it. Feel free to pick up- bk://blade.feral.com:9002 ftp://ftp.feral.com/pub/isp/isp_dist.tgz It's certainly got the latest f/w in it which you can try and use with qlogicfc. -matt On Fri, 29 Jun 2001, [ISO-8859-1] christophe barbé wrote: > > Le ven, 29 jun 2001 17:09:56, Alan Cox a écrit : > > > From my point of view, this driver is sadly broken. The fun part is > that > > > the qlogic driver is certainly based on this one too (look at the code, > > > the drivers differs not so much). > > > > And if the other one is stable someone should spend the time merging the > > two. > > That what I would like to try but It seems impossible without an > IP-enhanced firmware. I could try with the old firmware but I believe that > the new code from QLogic use some features that are only in recent > firmware. > > > > > > IMHO the qlogicfc driver should be removed from the kernel tree and > > > perhaps replaced by the last qlogic one. We then lost the IP support > > > but this is a broken support. > > > > For 2.5 that may wellk make sense. Personally I'd prefer someone worked > > out > > why the qlogicfc driver behaves as it does. It sounds like two small bugs > > nothing more > > > > 1. That the FC event code wasnt updated from 2.2 so now runs > > with IRQ's off when it didnt expect it > > > > 2. That someone has a slight glitch in the queue handling. > > This driver is already buggy under kernel 2.2. This driver is a well known > source of problems in the GFS mailing lists. > > I believe that the better thing to do is to use the qlogic driver. If we > manage to get a recent IP-enhanced firmware we could rewrite the missing IP > code. Half of the job is already done in the source of this driver. > > I didn't manage to reach the good person from qlogic. Perhaps someone would > have better results. > > Christophe > > -- > Christophe Barbé > Software Engineer - [EMAIL PROTECTED] > Lineo France - Lineo High Availability Group > 42-46, rue Médéric - 92110 Clichy - France > phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 > http://www.lineo.com > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gcc: internal compiler error: program cc1 got fatal signal 11
At 10:20 AM 6/29/01, you wrote: >Almost always ? >It seems like gcc is THE ONLY program which gets >signal 11 >Why the X server doesn't get signal 11 ? >Why others programs don't get signal 11 ? > >I remember that once Bill Gates was asked about >crashes in windows and he said: It's a hardware >problem. >It was also a joke on that subject: >Winerr xxx: Hardware problem (it's not our fault, it's >not, it's not, it's not, it's not...) > > >Seems to me like Micro$oft way of handling problems. > >We must agree that gcc is full of bugs (xanim does not >run corectly if it is compiled with gcc 2.95.3 >and other programs which use floating point >calculations do the same (spice 3f5)) All versions of gcc have bugs. They generally show up as incorrect complaints about the source code, as generated code that is less than optimal or that is flat out wrong. With this kind of bug, if you compile the program twice you'll get the same (buggy) result. Sig 11 is a bit different. With a compiler bug causing the sig 11, the problem will happen EVERY time you compile the given file - because the compiler is busted. This kind of problem is detected early in the compiler's life cycle and gets fixed. Then there are the intermittent sig 11 errors. If the software was broken, the sig 11 would happen whenever you do the same thing. Being able to compile a bunch of files, get a sig 11, compile a bunch more, sig 11, a bunch more ... is a sign that the problem isn't the compiler. Peoples' experience over the years has shown that symptoms of this type are cause by (intermittent) hardware problems. Why does this affect gcc more than other programs? Because gcc uses gazillions of pointers and bad memory causes bad pointers causes sig 11. Hope this helps. David P.S. Years ago, installing OS/2 on an apparently 100% working system would show similar problems. OS/2 was the first widely used 32 bit operating system on Intel hardware. It exercised the hardware differently from DOS, Windows, etc and flaky memory would make itself known. The usual reaction was "But my system worked fine before OS/2" The response was "different software exercises the hardware differently and may reveal unsuspected problems". David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] Ann Arbor, MI 48103 www.osagesoftware.com tel: 734.821.8800 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Qlogic Fiber Channel
> manage to get a recent IP-enhanced firmware we could rewrite the missing = > IP > code. Half of the job is already done in the source of this driver. > > I didn't manage to reach the good person from qlogic. Perhaps someone wou= > ld > have better results. Well lets wait and see what qlogic have to say, but removing IP support in the middle of a stable release is bad. And I still do not believe the driver will be hard to fix, its relatively clean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Qlogic Fiber Channel
Le ven, 29 jun 2001 17:09:56, Alan Cox a écrit : > > From my point of view, this driver is sadly broken. The fun part is that > > the qlogic driver is certainly based on this one too (look at the code, > > the drivers differs not so much). > > And if the other one is stable someone should spend the time merging the > two. That what I would like to try but It seems impossible without an IP-enhanced firmware. I could try with the old firmware but I believe that the new code from QLogic use some features that are only in recent firmware. > > > IMHO the qlogicfc driver should be removed from the kernel tree and > > perhaps replaced by the last qlogic one. We then lost the IP support > > but this is a broken support. > > For 2.5 that may wellk make sense. Personally I'd prefer someone worked > out > why the qlogicfc driver behaves as it does. It sounds like two small bugs > nothing more > > 1.That the FC event code wasnt updated from 2.2 so now runs > with IRQ's off when it didnt expect it > > 2.That someone has a slight glitch in the queue handling. This driver is already buggy under kernel 2.2. This driver is a well known source of problems in the GFS mailing lists. I believe that the better thing to do is to use the qlogic driver. If we manage to get a recent IP-enhanced firmware we could rewrite the missing IP code. Half of the job is already done in the source of this driver. I didn't manage to reach the good person from qlogic. Perhaps someone would have better results. Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP/IP stack
Michael J Clark <[EMAIL PROTECTED]> writes:
>
> I have been reading through TCP/IP Illustrated Vol 2 and the linux
> source. I am having a heck of a time finding where it sees a SYN packet
> and check to see if the desitination port is open. In the book it looks
> like it happens in tcp_input where it looks for the PCB for a segment.
> Any pointers would be greatly appeciated.
In 2.2.19 (since I have the source handy), this processing is done in
"linux/net/ipv4/tcp_input.c" in function "tcp_rcv_state_process". If
a SYN packet arrives and the socket is in state TCP_LISTEN, the
address-family-specific "conn_request" function is called. For IPv4,
this is "tcp_v4_conn_request" in "tcp_ipv4.c".
On the other hand, if a SYN packet is sent to a TCP_CLOSE socket,
"tcp_rcv_state_process" returns 1. This is an indication to the
caller ("tcp_v4_do_rcv" in "tcp_ipv4.c", in the case of IPv4) to send
a RST packet.
Kevin <[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: O_DIRECT please; Sybase 12.5
XFS supports O_DIRECT on linux, has done for a while. Steve > At work I had to sit through a meeting where I heard > the boss say "If Linux makes Sybase go through the page cache on > reads, maybe we'll just have to switch to Solaris. That's > a serious performance problem." > All I could say was "I expect Linux will support O_DIRECT > soon, and Sybase will support that within a year." > > Er, so did I promise too much? Andrea mentioned O_DIRECT recently > ( http://marc.theaimsgroup.com/?l=linux-kernel=99253913516599=2, > http://lwn.net/2001/0510/bigpage.php3 ) > Is it supported yet in 2.4, or is this a 2.5 thing? > > And what are the chances Sybase will support that flag any time > soon? I just read on news://forums.sybase.com/sybase.public.ase.linux > that Sybase ASE 12.5 was released today, and a 60 day eval is downloadable > for NT and Linux. I'm downloading now; it's a biggie. > > It supports raw partitions, which is good; that might satisfy my > boss (although the administration will be a pain, and I'm not > sure whether it's really supported by Dell RAID devices). > I'd prefer O_DIRECT :-( > > Hope somebody can give me encouraging news. > > Thanks, > Dan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Qlogic Fiber Channel
Hi Mike, Looks like QLogic up-rev'd the driver versions on their website. They have the source code for both v4.25 and v4.27 posted now and rpm's for v4.25. Hope that helps. Heather > -Original Message- > From: Mike Black [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 6:53 AM > To: [EMAIL PROTECTED] > Subject: Qlogic Fiber Channel > > > I have been running successfully with qla2x00src-4.15Beta.tgz > for several > months now over several kernel versions up to 2.4.5. > When I tested 2.4.6-pre6 I decided to use the qlogicfc driver -- BAD > MISTAKE!!! > > #1 - My system had crashed (for a different reason) and when > the raid5 was > resyncing and e2fsck happening at the same time the kernel locked with > messages from qlogicfc.o: > qlogicfc0: no handle slots, this should not happen. > hostdata->queue is 2a, inptr: 74 > I was able to repeat this several times so it's a consistent error. > Waiting for the raid resync to finish did allow this complete > -- but now > when I come in the next morning the console is locked up and > no network > access either. So I reset it. Checked the logs and here it is again: > Jun 29 03:39:21 yeti kernel: qlogicfc0 : no handle slots, > this should not > happen. > Jun 29 03:39:21 yeti kernel: hostdata->queued is 36, in_ptr: 13 > This was during a tape backup. > > So I'm switching back to qla2x00src-4.15Beta.tgz -- which > does the resync > and e2fsck just fine together BTW. > Jun 29 06:22:47 yeti kernel: qla2x00: detect() found an HBA > Jun 29 06:22:47 yeti kernel: qla2x00: VID=1077 DID=2100 > SSVID=0 SSDID=0 > > Only problem is I don't see this package on qlogic's website > anymore and > their "beta" directory is empty now. I'm waiting to see what > their tech > support says. > > > Michael D. Black Principal Engineer > [EMAIL PROTECTED] 321-676-2923,x203 > http://www.csihq.com Computer Science Innovations > http://www.csihq.com/~mike My home page > FAX 321-676-2355 > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message 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/
VFS locking & HFS problems (2.4.6pre6)
I've had a deadlock twice with 2.4.6pre6 today. It's an SMP kernel running on an UP box (a PowerBook Pismo). The deadlock happen in the HFS filesystem in hfs_cat_put(), apparently (quickly looking at addresses) in spin_lock(). I don't have the complete backtrace at hand right now, but it basically went up to kswapd without anything evidently getting that spinlock, I'll try to gather more details. So my question: Is there any document explaining the various locking requirements & re-entrency possibilities in a filesystem. What I think might happen after a quick look is that HFS may be causing schedule() to be called while holding the spinlock, and gets then re-entered from another process context. I have to look at it in more detail (is there an HFS maintainer ?) but some background informations on VFS locking & reentrancy issues would be helpful. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Qlogic Fiber Channel
> =46rom my point of view, this driver is sadly broken. The fun part is t= > hat > the qlogic driver is certainly based on this one too (look at the code,= > the > drivers differs not so much).=20 And if the other one is stable someone should spend the time merging the two. > IMHO the qlogicfc driver should be removed from the kernel tree and per= > haps > replaced by the last qlogic one. We then lost the IP support but this i= > s a > broken support. For 2.5 that may wellk make sense. Personally I'd prefer someone worked out why the qlogicfc driver behaves as it does. It sounds like two small bugs nothing more 1. That the FC event code wasnt updated from 2.2 so now runs with IRQ's off when it didnt expect it 2. That someone has a slight glitch in the queue handling. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Friday 29 June 2001 15:43, Holger Lubitz wrote: > A boot parameter for the verbosity would be ok, though. But I'd still > vote for the default to be pretty verbose. Leave it to the distributors > to disable it, if they want. > > After all - how often does the average linux machine boot? Once a day at > most. Mine usually run until the next kernel upgrade. But then again, > I'm not a kernel hacker, so this is to be taken more as a users point of > view. Many new Linux users go through an extended period of dual-booting. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Q: sparse file creation in existing data?
On Friday 29 June 2001 14:55, Ph. Marek wrote: > Hmmm, on second thought ... But I'd like it better to have a fcntl for > hole-making :-) > Maybe I'll implement this myself. A far superior interface would be: ssize_t sys_clear(unsigned int fd, size_t count) A stub implementation would just write zeroes. You would need a generic way of determining whether holes are supported for a particular file - this is where an fcntl would be appropriate. It would also be nice to know this before opening/creating a file, perhaps by fcntling the directory. But don't expect to have a real, hole-creating implementation any time soon. Taming the truncate races is hard enough as it is with a single boundary at the end of a file. Taking care of multiple boundaries inside the file is far, far harder. Talk to Al Viro or the Ext3 team if you want the whole ugly story. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: __alloc_pages: 1-order allocation failed
I had the same problem, and some other strange problems, booting with the 'noapic' option solved them ... (sorry for the late reply, I was still testing the machine... ) On Thu, 28 Jun 2001, Eugenio Mastroviti wrote: > This is possibly not the best place to post this message, but if anybody > could help I'd be very grateful... > > Twice at about the same time one of our server, running kernel 2.4.4, > has died. Attached is an excerpt from syslog - the actual list of > messages is 5 or 6 times longer, all with the same timestamp - after > this the machine froze until it was rebooted, about an hour later. > > The server is a dual-CPU Dell 2450 with 1.5GB RAM, 1.5GB swap, Megaraid > controller, running application server software > > Another identical server in the same subnet, running the same kind of > software with kernel 2.2.16 without any modification, is running fine in > spite of the bigger load on it (more threads, larger memory usage) > > Eugenio Mastroviti > > Systems Administrator > > Go Internet Ltd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A Possible 2.5 Idea, maybe?
On Fri, Jun 29, 2001 at 08:17:25AM -0500, Brent D. Norris wrote: > Instead of forking the kernel or catering only to one group, instead why > not try this: Using the new CML2 tools and rulesets, make it possible to > have the kernel configured for the type of job it will be doing? Just > like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out > and configures options for that, have it ask people "Is your machine a > server, workstation, embedded/handheld?" and configure things in the > kernel like the VM, bootup and others to optimize it for that job type? that could be the "easy == end-user" setup why can't there be two (possibly similar but tweaked) VMs (and other stuff as well) be in the source so everyone has to choose exactly one for his kernel? patrick mauritz -- ,. >Fighting for peace is like fucking for virginity< || >The Forthcoming OpenBIOS | www.freiburg.linux.de/openbios < `' because light travels faster than sound, some people appear to be intelligent, until you hear them speak. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VM behaviour under 2.4.5-ac21
Hi, just something positive for the weekend. With 2.4.5-ac21, the behaviour on my laptop (128MB plus twice the sapw) seems a bit more sane. When I start new large applications now, the "used" portion of VM actually pushes against the cache instead of forcing stuff into swap. It is still using swap, but the effects on interactivity are much lighter. So, if this is a preview of 2.4.6 bahaviour, there may be a light at the end of the tunnel. Have a good weekend Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
> After all - how often does the average linux machine boot? Once a day at > most. Mine usually run until the next kernel upgrade. But then again, > I'm not a kernel hacker, so this is to be taken more as a users point of > view. Don't forget that embedded devices boot much more often than their desktop counterparts, and they are most often used by people who definitely fall into the non-linux savvy demographic (like my grandmother). We use the Linux Progress Patch (http://lpp.FreeLords.org/) for our solutions. Despite the size that it adds to the kernel (a 240 x 320 image is a pretty big linux_logo.h file), I feel that it makes the kernel booting procedure more painless for the average user (and the hackers can always use dmesg to find out what happened). Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
