Netmos PCI parallel card
Hi,
Attached is a patch to make a Netmos PCI parallal port card working.
Card is a PCI card with a Netmos 9705 controller and an Atmel serial
eeprom.
Regards,
Igmar
--
--
Igmar Palsenberg
JDI Media Solutions
Jansplaats 11
6811 GB Arnhem
The Netherlands
mailto: [EMAIL PROTECTED]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
00:00.0 Class 0600: 8086:7122 (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B-
00:1f.0 Class 0601: 8086:2410 (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-
--- linux/include/linux/pci.h.orig Thu Feb 15 11:18:43 2001
+++ linux/include/linux/pci.h Thu Feb 15 11:52:27 2001
@@ -1268,6 +1268,9 @@
#define PCI_DEVICE_ID_INTERPHASE_5526 0x0004
#define PCI_DEVICE_ID_INTERPHASE_55x6 0x0005
+#define PCI_VENDOR_ID_NETMOS 0x9710
+#define PCI_VENDOR_ID_NETMOS_9705 0x9705
+
/*
* The PCI interface treats multi-function devices as independent
* devices. The slot/function address of each device is encoded
--- linux/drivers/misc/parport_pc.c.origThu Feb 15 11:49:00 2001
+++ linux/drivers/misc/parport_pc.c Thu Feb 15 11:53:21 2001
@@ -910,6 +910,8 @@
{ { 0, -1 }, } },
{ PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_12PCI840, 1,
{ { 0, 1 }, } },
+ { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9705, 1,
+ { { 0, -1 }, } },
{ 0, }
};
--- linux/drivers/pci/oldproc.c.origThu Feb 15 11:30:36 2001
+++ linux/drivers/pci/oldproc.c Thu Feb 15 11:30:06 2001
@@ -947,6 +947,7 @@
case PCI_VENDOR_ID_TIGERJET: return "TigerJet";
case PCI_VENDOR_ID_ARK: return "ARK Logic";
case PCI_VENDOR_ID_SYSKONNECT:return "SysKonnect";
+ case PCI_VENDOR_ID_NETMOS:return "Netmos";
default: return "Unknown vendor";
}
}
Netmos patch
Hi,
Wrong patch. Attached is the (hopefully) correct one. Or replace the
PCI_VENDOR_ID_NETMOS_9705 with PCI_DEVICE_ID_NETMOS_9705
Regards,
Igmar
--
--
Igmar Palsenberg
JDI Media Solutions
Jansplaats 11
6811 GB Arnhem
The Netherlands
mailto: [EMAIL PROTECTED]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
--- linux/include/linux/pci.h.orig Thu Feb 15 11:18:43 2001
+++ linux/include/linux/pci.h Thu Feb 15 11:52:27 2001
@@ -1268,6 +1268,9 @@
#define PCI_DEVICE_ID_INTERPHASE_5526 0x0004
#define PCI_DEVICE_ID_INTERPHASE_55x6 0x0005
+#define PCI_VENDOR_ID_NETMOS 0x9710
+#define PCI_DEVICE_ID_NETMOS_9705 0x9705
+
/*
* The PCI interface treats multi-function devices as independent
* devices. The slot/function address of each device is encoded
--- linux/drivers/misc/parport_pc.c.origThu Feb 15 11:49:00 2001
+++ linux/drivers/misc/parport_pc.c Thu Feb 15 11:53:21 2001
@@ -910,6 +910,8 @@
{ { 0, -1 }, } },
{ PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_12PCI840, 1,
{ { 0, 1 }, } },
+ { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9705, 1,
+ { { 0, -1 }, } },
{ 0, }
};
--- linux/drivers/pci/oldproc.c.origThu Feb 15 11:30:36 2001
+++ linux/drivers/pci/oldproc.c Thu Feb 15 11:30:06 2001
@@ -947,6 +947,7 @@
case PCI_VENDOR_ID_TIGERJET: return "TigerJet";
case PCI_VENDOR_ID_ARK: return "ARK Logic";
case PCI_VENDOR_ID_SYSKONNECT:return "SysKonnect";
+ case PCI_VENDOR_ID_NETMOS:return "Netmos";
default: return "Unknown vendor";
}
}
2.2.18 and Maxtor 96147H6 (61 GB)
Hi, kernel 2.2.18 hates my Maxtor drive : ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: Maxtor 96147H6, 32253MB w/2048kB Cache, CHS=65531/16/63, (U)DMA Actual (correct) parameters : CHS=119112/16/63 Looks like some short int (2 bytes) overflowing. I'll try the ide patches. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 and Maxtor 96147H6 (61 GB) part #2
Hi, Just tried the ide patches for 2.2.18, and same result :(( Any patches / suggestions I can try ?? Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> You have a hard destroke clipping on the drive. > Go look at you logs. Yep, logs indicate that.. Sven, how did you kill the clipping ?? Or in generic, how do I kill the clipping ? Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
Hi, Forget the question on killing the drive clipping. I forgot to RTFM :) Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
On Thu, 4 Jan 2001, Andre Hedrick wrote: > > You have a hard destroke clipping on the drive. > Go look at you logs. Yeah.. I removed the clipping, and the machine won't boot. It halts after PnP init. Any way to use full capacity with the clipping enabled ? Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> I did'nt know something like that even existed :) > > Just plugged the drive into the ide controller (single drive on a > promise ata100 in a dec alpha) and it worked. Ah.. This is a i386 machine, UDMA33 capable, and the bloody thing won't boot with the clipping removed, and with clipping I can use only 32 GB :(( > But I'm booting from SCSI as the machine does not support IDE-drives in > the "bios". This machine the other way around :) Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.2.18 and Maxtor 96147H6 (61 GB)
On Thu, 4 Jan 2001, Torrey Hoffman wrote: > I had exactly this problem with the Maxtor 61 GB drive on my > Pentium based server. Theoretically a BIOS upgrade could fix it, > but ASUS quit making BIOS upgrades for my motherboard two years > ago. Ah well, join the club in my case :) > I solved the problem by getting a Promise Ultra 100 controller > and putting the drive on that. Works perfectly under Linux > Mandrake 2.2.17-mdk-21 - it shows up as /dev/hde. They are > cheap controllers if you don't get the RAID version. Thanx.. Will try that. New machine costs more. > Best wishes. > > Torrey Hoffman Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> No. 2.2.* handles large drives since 2.2.14. > This looks more like you used the jumper to clip the drive to 32GB. > Don't use it and get full capacity. > If your BIOS hangs when it sees such a large drive so that you > cannot avoid using the jumper, use setmax in your boot scripts, > or use a kernel patch that does the same at kernel boot time. > > >> Looks like some short int (2 bytes) overflowing. I'll try the ide patches. > > The overflow is in certain BIOSes, not in Linux. > (You see in the above: 65531 is not an overflow value.) The number after clipping was actual - 2^16. Was the reason I was thinking the kernel was playing games. After applying IDE patches the idesetmax message showed up :) > > I had to recompile fdisk as my old suse 6.4 version got the same > > 2byte-wraparound problem. > > In the good old days the HDIO_GETGEOM ioctl would give you the disk > geometry. It has a short for cylinders and hence overflows when C > gets above 65535. Since geometry is on its way out - indeed, there has > not been any such thing for many, many years - it would have been > nonsense to introduce new ioctls that report meaningless 32-bit numbers > instead of the present meaningless 16-bit number. > So, instead, the "cylinder" field in the output of this ioctl has been > declared obsolete, and is not used anymore. Programs that want to print > some value, just because they always did and users expect something, > now use BLKGETSIZE to get total size and divide by heads*sectors > to get a cylinder value. > (But again: this cylinder value is not used anywhere, the computed value > is just for the user's eyes.) all is block adressed indeed.. I need to look at fdisk, because it is doing things wrong. The other machine's BIOS can handle 64 GB wihout problems, so I can run without clipping in that machine. Linux sees the correct size, but fdisk still sees 32 GB. Probably a recompile / upgrade. > Andries Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> I had a similar situation except I was more interested in the performance > difference. Went from ~4MB/s with the 430HX controller to ~12.5MB/s with > the promise. This on an old Pentium system. The network is 10 mbit, so 4 MB/sec is no good in this case. I've got the thing running, with (ibm)setmax. Don't hang the disk in a machine that does handle > 32 GB, because it will screw the limit the setmax just set. > > > I solved the problem by getting a Promise Ultra 100 controller > > > and putting the drive on that. Works perfectly under Linux > > > Mandrake 2.2.17-mdk-21 - it shows up as /dev/hde. They are > > > cheap controllers if you don't get the RAID version. > > > > Thanx.. Will try that. New machine costs more. > > > > Vanilla 2.2 kernels don't have this support (at least not as on 2.2.18). > If you're not running Mandrake, grab Andre Hedrick's excellent ide patch. Already installed :) > One thing you may like to know. If you want the drives attached to the new > controller to be /dev/hda..., then edit lilo.conf and add > append="pci=reverse" > to your patched kernel entry. Oh, and if you ever need to bootstrap one of > these puppies with a kernel that doesn't have the drivers, you can use > append="ide0=0xe000,0xd802 ide1=0xd400,0xd002" > to be able to access the drive attached to the Promise controller using the > standard ide driver. > > Hope this helps. Thanx. If I get anymore problems I'll switch to a Promise controller. 2 days to setup a plain Linux box is a bit much.. Main problem I've had is that the software clipping bugs, or that my BIOS in teh newer machine screws things up. > Tim Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> > Sven, how did you kill the clipping ?? > > Or in generic, how do I kill the clipping ? > > Go set the jumpers right. (anyhow, IBM drives are delivered unclipped, > not sure why Maxtors seem to be) It's not that simple.. The maxtor comes clipped,. but Linux can't kill the clip. So it sticks with 32 MB ibmsetmax.c does a software clip, but that bugs a bit. Sometimes even Linux doesn't see 61 GB, but only 32, sometimes the full capacity. (i'm talking without the hardware jumper). the machine I used to set the limit (target machine doesn't but without the hardware clip), seems to reset the software clip. Probably the BIOS who does that. It seems stable now, machine boots OK, and Linux sees 61GB. Let's hope it will stay that way. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Console logging
On Sat, 6 Jan 2001, Mike wrote: > Hi! > > I am getting getting "/var/log/messages" on my console. It doesn't save > it in /var/log. > I have checked entries in /etc/syslog.conf file. Its correct. > Can someone help me. Syslog isn't running > > Regards, > Mike Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
On Sat, 6 Jan 2001 [EMAIL PROTECTED] wrote: > > It's not that simple.. The maxtor comes clipped,. but Linux can't kill the > > clip. So it sticks with 32 MB > > > ibmsetmax.c does a software clip, but that bugs a bit. Sometimes even > > Linux doesn't see 61 GB, but only 32, sometimes the full capacity. > > Please don't talk vague useless garbage. > There is no entity called "Linux". If you mean "the 2.4.0 kernel > boot messages report 61 GB, fdisk 2.9s sees 32 GB, fdisk 2.10r sees 61 GB" > then say so. If you mean something else, say what you mean. > Precisely, with versions and everything. 2.2.18 sometimes sees 61 GB, sometimes 32 GB. I don't call that hard to understand. And I don't use 2.4 on that machine, see previous posting. I also mentined that I use 2.2.18 with Andre's IDE patches. > Since you have a Maxtor, my old setmax should suffice for you, it can kill > the clip, and there is no reason to use ibmsetmax.c, that is a version for > IBM disks. There should not be any need to use other machines. > > If something changed for recent Maxtor disks, we would like to know, > but only reliable, detailed reports are of any use. It was probably t he BIOS of this newer machine that somehow killed the software clip. I can't explain otherwise. The setmax program initially gave errors, so that's why I switched to ibmsetmax. If the vague behaviour starts appearing again I'll debug the thing. For now I blaim the award bios :) > Andries Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Delay in authentication.
On Mon, 8 Jan 2001, Chris Meadors wrote: > On Mon, 8 Jan 2001, David S. Miller wrote: > > > This definitely seems like the classic "/etc/nsswitch.conf is told to > > look for YP servers and you are not using YP", so have a look and fix > > nsswitch.conf if this is in fact the problem. > > What I have never gotten, is why on my machines (no specific distro, just > everything built from source and installed by me) login takes a long time, > unless I have portmap running. > > My /etc/nsswitch.conf would seem to be right: > > What else could effect that? check /etc/pam.d/login Could be kerberos that is biting you, althrough that doesn't explain the portmap story. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> > 2.2.18 sometimes sees 61 GB, sometimes 32 GB. > > I don't call that hard to understand. > > The same kernel has varying behaviour? > Maybe not hard to understand, but rather surprising. > You are the first to report nondeterministic behaviour. You're not the only one that is suprised : 1) Put disk in my machine (target machine hangs itself with the disk) 2) use setmax to set the limit to 32 GB 3) Put the disk in the target machine 4) System boots, linux sees 64GB 5) rebooted system, system hangs due to the soft clippig 'vanished' I even had occurences of the kernel setmax message showing up, and after a plain reboot it didn't. It beats me.. I can't explain, and the machine is rock solid now. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Shared memory not enabled in 2.4.0?
> # cat /proc/meminfo > total:used:free: shared: buffers: cached: > Mem: 130293760 123133952 71598080 30371840 15179776 ^^ It means shared process memory, not shm. One thing to watch : PowerTweak. Seems to set the max shm segments to 0 Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Delay in authentication.
On Mon, 8 Jan 2001, Scott Laird wrote: > > Is syslog running correctly? When syslog screws up, it very frequently > results in this sort of problem. Indeed, or no DNS when talking remote logins. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> Probably you confused the proper way to use ibmsetmax with > the proper way to use setmax. For setmax, and a Maxtor disk, > you do not use a different machine, put the jumper to clip, > now the boot succeeds, and you let Linux unclip. > Either with a patched kernel that knows about these things > or with a utility run from a boot script. > (It is most convenient to have a partition boundary where > the jumper clips, so that with old kernels and without running > the utility you also have a valid filesystem.) I found out yesterday after searching the mailinglist... My bad. Thanx for the info. 2.2.18 + ide is patched, 2.4.0 isn't. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Message from new kernel
On Thu, 11 Jan 2001, Nguyen Truong Sinh wrote: > I am using Redhat 7.0 for my system. After install new kernel (2.4.0). My system >always inform > NET: 3 messages suppressed > > What does it mean ? and how to fix it, I don't want it appears on the console at all. man syslog messages supressed means it didn't write all three messages, but a line saying that the three messages where the same as the previous one in the logs. > > Thanks. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PS/2 mouse access kills keyboard
Hi, on plain 2.4.0 vanilla any mouse access kills the keyboard. Only way to restore functionality is to kill gpm. gpm writes 'protocol error' to syslog. I have access to this machine on monday, so I can post details then. Changing the IRQ is totally unrelated, machine works in 2.2.x with the same config. regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0 + iproute2
Hi, kernel : 2.4.0 vanilla iproute2 version : ss001007 After building I've got a few problems : ./ip rule list RTNETLINK answers: Invalid argument Dump terminated Version should be OK according to the Changes file. config is attached Regards, Igmar -- -- Igmar Palsenberg JDI Media Solutions Jansplaats 11 6811 GB Arnhem The Netherlands mailto: [EMAIL PROTECTED] PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y # # Processor type and features # CONFIG_M586TSC=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_486=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_NOHIGHMEM=y # # General setup # CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETFILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_LOG=y # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_CMD640=y CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDE_MODES=y # # Network device support # CONFIG_NETDEVICES=y # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y CONFIG_NET_PCI=y CONFIG_8139TOO=y # # Ethernet (1000 Mbit) # CONFIG_PPP=y CONFIG_PPP_ASYNC=y CONFIG_PPP_DEFLATE=y # # ISDN subsystem # CONFIG_ISDN=y # # Passive ISDN cards # CONFIG_ISDN_DRV_HISAX=y CONFIG_HISAX_EURO=y CONFIG_HISAX_16_3=y # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # Mice # CONFIG_MOUSE=y CONFIG_PSMOUSE=y # # File systems # CONFIG_QUOTA=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y # # Partition Types # CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ISO8859_1=y # # Console drivers # CONFIG_VGA_CONSOLE=y
Re: 2.4.0 + iproute2
> On Sat, Jan 13, 2001 at 05:37:01PM +0100, Igmar Palsenberg wrote: > > Hi, > > > > kernel : 2.4.0 vanilla > > iproute2 version : ss001007 > > > > After building I've got a few problems : > > > > ./ip rule list > > RTNETLINK answers: Invalid argument > > Dump terminated > > You forgot to set CONFIG_IP_ADVANCED_ROUTER Nope. Still the same error after that one is set : CONFIG_IP_ADVANCED_ROUTER=y [root@base root]# ip rule list RTNETLINK answers: Invalid argument Dump terminated According to net/ipv4/Config.in : if [ "$CONFIG_IP_ADVANCED_ROUTER" = "y" ]; then define_bool CONFIG_RTNETLINK y define_bool CONFIG_NETLINK y CONFIG_IP_ADVANCED_ROUTER just sets those two values, and adapts the questions. To make sure I just recompiled with Advanced Router turned on, and still the same error. I tested the other command of the ip command, and this one is the only one that gives problems, the others are fine. Regards, Igmar -- -- Igmar Palsenberg JDI Media Solutions Jansplaats 11 6811 GB Arnhem The Netherlands mailto: [EMAIL PROTECTED] PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + iproute2
> > > You forgot to set CONFIG_IP_ADVANCED_ROUTER > > > > Nope. Still the same error after that one is set : > > > > CONFIG_IP_ADVANCED_ROUTER=y > > Try CONFIG_IP_MULTIPLE_TABLES. Yep, that was the one.. we might want to consider changing the error the call gives in case MULTIPLE_TABLES isn't set. -EINVAL is ugly, -ENOSYS should make the error more clear.. > Later, > David S. Miller > [EMAIL PROTECTED] Thanx, Igmar -- -- Igmar Palsenberg JDI Media Solutions Jansplaats 11 6811 GB Arnhem The Netherlands mailto: [EMAIL PROTECTED] PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + iproute2
> Igmar Palsenberg writes: > > > we might want to consider changing the error the call gives in case > > MULTIPLE_TABLES isn't set. -EINVAL is ugly, -ENOSYS should make the error > > more clear.. > > How do I tell the difference between using the wrong system call > number to invoke an ioctl or socket option change, and making a > call for a feature I haven't configured into my kernel? The large tables option is rather strange : Looking at the name I start thinking that the option is actually already there, but this option enlarges this table. When the kernel return -EINVAL I start thinking that the call is actually supported, but the userspace stuff sends garbage. In this case, it sends valid data, bit the call isn't there. I haven't had a real good look at the code, but we might change the behaviour so that the call fails (same case if NETLINK isn't compiled in, you get an error when creating the socket). If this isn't possible (if we don't know what userspace wants when creating the socket, it's a good idea to print an aditional hint saying 'you might want to compile LARGE TABLES option'. > I think ENOSYS is just a bad a choice. Maybe time for a ENOTSUPPORTED or so ? The config option says : 'If you have routing zones that grow to more than about 64 entries, you may want to say Y here to speed up the routing process' Which I assume that it just enlarges the table. -ENOSYS is bad in this case indeed, but -EINVAL is also bad IMHO. Regards, Igmar -- -- Igmar Palsenberg JDI Media Solutions Jansplaats 11 6811 GB Arnhem The Netherlands mailto: [EMAIL PROTECTED] PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + iproute2
On Sun, 14 Jan 2001, Andi Kleen wrote:
> On Sun, Jan 14, 2001 at 03:36:55AM -0800, David S. Miller wrote:
> >
> > Andi Kleen writes:
> > > How would you pass the extended errors? As strings or as to be
> > > defined new numbers? I would prefer strings, because the number
> > > namespace could turn out to be as nasty to maintain as the current
> > > sysctl one.
> >
> > Textual error messages for system calls never belong in the kernel.
> > Put it in glibc or wherever.
>
> This just means that a table needs to be kept in sync between glibc and
> netlink, and if someone e.g. gets a new CBQ module he would need to update
> glibc. It's also bad for maintainers, because patches for tables of number
> tend to always reject ;)
Agree, but textual strings are bad. I want to say :
if (error) {
perror("RTNETLINK");
return -1;
}
Using textual strings means you can't use standard functions. An option
would be to extend the call so that if the userspace app wants to know
what really went wrong he can ask the kernel.
In that case you can keep the -EINVAL, the namespace won't be polluted,
and you can see what goes wrong. Agains this is that you need another
interface, which isn't portable.
>
> Textual error messages are e.g. used by plan9 and would be somewhat similar
> to /proc. It would probably waste a few bytes in the kernel, but that's not
> too bad, given the work it saves. e.g. rusty's code usually has a debug option
> that you can set and where each EINVAL outputs a error message; i always found
> that very useful and sometimes hacked that into other subsystems in my
> private tree.
Still means that all standard functions won't work.
> -Andi
Igmar
--
--
Igmar Palsenberg
JDI Media Solutions
Jansplaats 11
6811 GB Arnhem
The Netherlands
mailto: [EMAIL PROTECTED]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + iproute2
> People must be really suffering right now, and we ought to get > /proc/errno_strings implemented as soon as possible... :-) First the help describing large tables should be changed. It's wrong. String errors don't belong in kernel space IMHO. Igmar -- -- Igmar Palsenberg JDI Media Solutions Jansplaats 11 6811 GB Arnhem The Netherlands mailto: [EMAIL PROTECTED] PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + iproute2
> > Using textual strings means you can't use standard functions. An option > > would be to extend the call so that if the userspace app wants to know > > what really went wrong he can ask the kernel. > > That will not work. Consider an application that has multiple rtnetlink > sockets open, which each have own errors. errno is only valid until a new syscall is done. So I don't see the problem with multiple sockets, you can only perform one at a time. > rtnetlink is such a radical interface for unix, adding a few more changes > for a different error reporting system probably does not make much difference. > > my problem with keeping the textual error messages out of kernel is that > it means that three entities (kernel module, number table in kernel and > external string table) need to be kept in sync. In practice that's usually > not the case. I wonder if the glibc keeps it's own copy of the sys_errlist[]. If it has, that means that we indeed have a problem.. Maybe the kernel could provide errno -> textual mapping, but that sounds like bloat to me.. An other way is to have some kind of extended error. > David's /proc/errno_strings would only require keeping kernel table and > module in sync. > Text errors for rtnetlink would localize it to the module itself. > I could probably live with David's solution, although I would prefer the full > way. Disadvantage of textual stuff is that you can't do more then print it. > -Andi Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0ac9
Hi, 2.4.0ac9 still kills the mouse on this machine. dmesg is attached. Something I find interesting is that the PCMCIA bridge is on IRQ12. We can't change the mouse or the PCMCIA bridges' interrupt. I'll be happy to provide additional info. Regards, Igmar Jan 16 08:33:06 mars kernel: Linux version 2.4.0-ac9 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Mon Jan 15 19:03:29 CET 2001 Jan 16 08:33:06 mars kernel: BIOS-provided physical RAM map: Jan 16 08:33:06 mars kernel: BIOS-e820: 0009f800 @ (usable) Jan 16 08:33:06 mars kernel: BIOS-e820: 0800 @ 0009f800 (reserved) Jan 16 08:33:06 mars kernel: BIOS-e820: 00015800 @ 000ea800 (reserved) Jan 16 08:33:06 mars kernel: BIOS-e820: 05f0 @ 0010 (usable) Jan 16 08:33:06 mars kernel: BIOS-e820: 00015800 @ fffea800 (reserved) Jan 16 08:33:06 mars kernel: On node 0 totalpages: 24576 Jan 16 08:33:06 mars kernel: zone(0): 4096 pages. Jan 16 08:33:06 mars kernel: zone(1): 20480 pages. Jan 16 08:33:06 mars atd: atd startup succeeded Jan 16 08:33:06 mars kernel: zone(2): 0 pages. Jan 16 08:33:07 mars kernel: Kernel command line: BOOT_IMAGE=test1 ro root=307 sb=0x220,5,1 Jan 16 08:33:07 mars kernel: Initializing CPU#0 Jan 16 08:33:07 mars kernel: Detected 232.110 MHz processor. Jan 16 08:33:07 mars kernel: Console: colour VGA+ 80x25 Jan 16 08:33:07 mars kernel: Calibrating delay loop... 462.02 BogoMIPS Jan 16 08:33:07 mars kernel: Memory: 94084k/98304k available (1252k kernel code, 3832k reserved, 508k data, 196k init, 0k highmem) Jan 16 08:33:07 mars kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Jan 16 08:33:07 mars kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Jan 16 08:33:07 mars kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Jan 16 08:33:07 mars kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Jan 16 08:33:07 mars kernel: VFS: Diskquotas version dquot_6.5.0 initialized Jan 16 08:33:00 mars rc.sysinit: Mounting proc filesystem succeeded Jan 16 08:33:07 mars crond: crond startup succeeded Jan 16 08:33:07 mars kernel: CPU: Before vendor init, caps: 0183f9ff , vendor = 0 Jan 16 08:33:00 mars sysctl: net.ipv4.ip_forward = 0 Jan 16 08:33:07 mars kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Jan 16 08:33:00 mars sysctl: net.ipv4.conf.all.rp_filter = 1 Jan 16 08:33:07 mars kernel: CPU: L2 cache: 512K Jan 16 08:33:00 mars sysctl: kernel.sysrq = 0 Jan 16 08:33:08 mars kernel: Intel machine check architecture supported. Jan 16 08:33:08 mars inet: inetd startup succeeded Jan 16 08:33:00 mars sysctl: error: 'net.ipv4.ip_always_defrag' is an unknown key Jan 16 08:33:08 mars kernel: Intel machine check reporting enabled on CPU#0. Jan 16 08:33:00 mars rc.sysinit: Configuring kernel parameters succeeded Jan 16 08:33:08 mars kernel: CPU: After vendor init, caps: 0183f9ff Jan 16 08:33:08 mars sshd: Starting sshd: Jan 16 08:33:00 mars date: Tue Jan 16 08:32:59 CET 2001 Jan 16 08:33:08 mars kernel: CPU: After generic, caps: 0183f9ff Jan 16 08:33:00 mars rc.sysinit: Setting clock : Tue Jan 16 08:32:59 CET 2001 succeeded Jan 16 08:33:08 mars kernel: CPU: Common caps: 0183f9ff Jan 16 08:33:00 mars rc.sysinit: Loading default keymap succeeded Jan 16 08:33:09 mars kernel: CPU: Intel Pentium II (Deschutes) stepping 02 Jan 16 08:33:00 mars rc.sysinit: Activating swap partitions succeeded Jan 16 08:33:09 mars kernel: Enabling fast FPU save and restore... done. Jan 16 08:33:00 mars rc.sysinit: Setting hostname mars.office.jdimedia.nl succeeded Jan 16 08:33:09 mars kernel: Checking 'hlt' instruction... OK. Jan 16 08:33:00 mars fsck: /dev/hda7: clean, 50558/114016 files, 196128/227800 blocks Jan 16 08:33:10 mars sshd: sshd startup succeeded Jan 16 08:33:10 mars sshd[557]: Server listening on 0.0.0.0 port 22. Jan 16 08:33:10 mars kernel: POSIX conformance testing by UNIFIX Jan 16 08:33:00 mars rc.sysinit: Checking root filesystem succeeded Jan 16 08:33:10 mars sshd: Jan 16 08:33:10 mars sshd[557]: Generating 768 bit RSA key. Jan 16 08:33:10 mars kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd9e3, last bus=0 Jan 16 08:33:00 mars rc.sysinit: Remounting root filesystem in read-write mode succeeded Jan 16 08:33:10 mars rc: Starting sshd succeeded Jan 16 08:33:10 mars kernel: PCI: Using configuration type 1 Jan 16 08:33:00 mars rc.sysinit: Finding module dependencies failed Jan 16 08:33:10 mars kernel: PCI: Probing PCI hardware Jan 16 08:33:00 mars depmod: depmod: Can't open /lib/modules/2.4.0-ac9/modules.dep for writing Jan 16 08:33:11 mars kernel: PCI: Using IRQ router PIIX [8086/7110] at 00:03.0 Jan 16 08:
Re: detecting bounced mails
On Wed, 17 Jan 2001, Rajiv Majumdar wrote: > > > Sorry..the topic does not fit here. But wanted to know, how can we check > validity of an email id "in advance" You can't. Only think you can check is a valid domain that will in theory accept mail, no way to check if it really dilivers. > so that we can skip "bounce". > > Thanks! > Rajiv Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + iproute2
> The underlying problem is of course that all those sanity checks should > be done in user space, not in the kernel. > > (See also ftp://icaftp.epfl.ch/pub/people/almesber/slides/tmp-tc.ps.gz > The bitching starts on slide 11, some ideas for fixing the problem on > slide 16, but heed the warning on slide 15.) > > Besides that, I agree that we have far too many EINVALs in the kernel. > Maybe we should just record file name and line number of the EINVAL > in *current and add an eh?(2) system call ;-) I don't care about an error, but EINVAL is giving very confusing errors.. Like finding your glasses when you're already have them on. I like the h_errno solution, but that's another glibc change. > - Werner Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting stat(2)
> Nope stat should return the details of the symlink > whereas lstat should return the details of the symlink target. It's the other way around according to the manpage, and my code also says it's the other way around. It's logical the way it is.. I use lstat to check if a config file is a symlink, and if it is, it refuses to open it. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting stat(2)
On Thu, 18 Jan 2001, Mike Castle wrote: > On Thu, Jan 18, 2001 at 09:52:02PM +0100, Igmar Palsenberg wrote: > > I use lstat to check if a config file is a symlink, and if it is, it > > refuses to open it. > > Nice race condition. Agree, but still better then opening things that are actually a symlink. Now would someone probably say : use the O_NOWFOLLOW option, but since I do other checks that wouldn't be an option. > mrc Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID modules and CONFIG_AUTODETECT_RAID
On Wed, 15 Nov 2000, Peter Samuelson wrote: > > [Ian Grant] > > In 2.2.x we were able to build a kernel with RAID modules and have it > > autodetect RAID partitions at boot time - so we could use raid root > > partitions. > > Really? Funny, because IIRC RAID autodetection does not even exist in > 2.2.x kernels. Perhaps you are referring to vendor-patched kernels -- > some distributions ship 2.2 kernels with RAID patches applied. I call the CONFIG_MD_BOOT option a RAID autodetection :) > > In 2.40 the configuration option CONFIG_AUTODETECT_RAID is explicitly > > disabled unless at least one RAID module is built into the kernel. I > > presume there is a good reason for this and that it's not just a > > mistake. > > What would be the point? Autodetection is only needed for mounting the > root filesystem. After root is mounted, you can use raidtools. Please notice the 'filesystem'. I needed to put /boot on a non-RAID partition, else it was a nogo. > Peter Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File Support
On Thu, 16 Nov 2000, Andreas S. Kerber wrote: > We need to handle files which are about 10GB large. > Is there any way to do this with Linux? Some pointers would be nice. Install a kernel / glibc that handles LFS. Search for LFS on Freshmeat, you'll end up with the right patch. You'll probably need to recompile some stuff, see the LFS patches on what define to use. I forgot. > Andreas Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: grphics mode problem
On Fri, 17 Nov 2000, M.Kiran Babu wrote: > sir, > i am getting some problem with graphics mode. my system is opening in text > mode only. upto yesterday it is ok. but now it is failing to open in > graphics mode. i am using startx, xinit and Xconfigurator all options. but > even it is showing errors. it is displaying something cannot set font path > unix-->:1 and font cant find like this. what may be the reason. how to get > the graphics mode again. finally it is displaing one more statement > killed display :0.0 like this. > give me reply quickly. Your font server is dead, and this is not a kernel problem/ > bye > kiran Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
On Mon, 20 Nov 2000, Charles Turner, Ph.D. wrote: These are hardware problems, not software. Programs like gcc and ld segfaulting like this is NOT a software problem. Please don't turn up with some 'hey, it worked with my disk', that's no clue that the distrib is bad. The same arguments as 'it works with Windows'. Stick with RH 6.2 if you want something stable. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
53c400 driver
Hi, Support for some 53c400 cards is still bad (the non-PnP), so I'll start fixing this. I'll be my fist kernel job, so please spare me :)) Issues : 53c400a non-PNP still lock this system hard. It starts barking about a busy SCSI bus, and then I can fsck again. To Alan : How hard is it to get thing beast (53c400 and family) to be SMP safe ?? Or is it better to start over again ? Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 53c400 driver
On Tue, 21 Nov 2000, Dunlap, Randy wrote: > JE's UHCI driver (drivers/usb/uhci.[hc]) uses > nested_lock() and nested_unlock() for this. > Maybe it could help. I may should solve the nested spinlock issue.. It however doesn't solve the 100Kb+ pile of spaghetti the code is. I think I'll just start over. I have to do something in my spare time :) > ~Randy Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN causing problems
On Tue, 21 Nov 2000, Joseph Gooch wrote: > My RaptorNT 6.5 firewall rejects all connections from my linux box when ECN > is enabled. The error is attached. Perhaps this feature should be disabled > by default? Or is there already an option of the sort that i'm missing? I > only got the idea to disable it after a search of linux-kernel. The're is variable in /proc somewhere. Teh firewall should be fixed, what Linux is doing is legal to the RFC. Cisco fixed most of their products that misbehaved. Complain to the guys who moade RaptorNT :) > Plz cc me, I"m not on the list. > > Later! > Joe Gooch > Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modutils 2.3.20 not backward compatible
> -i and -m have never been in the base code. -i in depmod is a Redhat > add on, only in their distribution. I have no idea what -m does, apart > from -m in insmod which is supported. Blame the distributors. -m == -F in depmod (RH anyways) Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.2.18-pre19 asm/delay.h problem?
> > #define __bad_udelay() panic("Udelay called with too large a constant")
Can't we change that to :
#error "Udelay..."
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Rik's bad process killer - how to kill _IT_?
On Wed, 22 Nov 2000, Daniel Stone wrote: > Hi, > I've been having a bit of a problem with Rik's new VM, in particular the bad > process-killer. Basically put, I have a reasonably underpowered system > (P166) running Helix GNOME & Sawfish, and half the time when I load my Eterm > (admittedly, transparent, but it looks cool, damnit!), or Netscape (or > both!) it seems to be Rik's VM killer slaying them. No error message is > logged anywhere, not even if I start 'em from the console. > Is there a /proc hack or something? > Thanks a lot! This is NOT the OOM killer. It always logs / sends messages to the console. The app probably just segfaults. > :) d Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.2.18-pre19 asm/delay.h problem?
> |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> |>
> |> Can't we change that to :
> |> #error "Udelay..."
>
> No.
?? I think I'm missing something here.
> Andreas.
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: USB doesn't work with 440MX chipset, PCI IRQ problem?
> CPU0 > 0:1415829 XT-PIC timer > 1: 10361 XT-PIC keyboard > 2: 0 XT-PIC cascade > 3: 70687 XT-PIC serial > 5: 0 XT-PIC Intel ICH > 9: 3134 XT-PIC 3c574_cs >11: 1 XT-PIC Ricoh Co Ltd RL5c475, usb-uhci Your videocard is also at 11. Could be an issue if the USB driver hates sharing IRQ's. >12: 18847 XT-PIC PS/2 Mouse >14: 146954 XT-PIC ide0 > NMI: 0 > ERR: 0 Nothing in there that I would lie awake from. > Erik Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Octal vs. Hex war o' death
> [snip a boring troll] Please, don't insult my mother in law. She's not that boring ;P Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> Indeed, you are correct. Is vpnd broken then, for assuming > that it can gather the required randomness in one read? Yep. It assumes that if the required randommness numbers aren't met a read to /dev/random will block. And it's not the only program that assumes this : I also did. /dev/random is called a blocking random device, which more or less implies that it will totally block. I suggest we put this somewhere in the kernel docs, since lots of people out there assume that it totally blocks. Means I've got to updates some sources of mine :) > Matthew. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> For a blocking fd, read(2) has always blocked until some data is > available. There has never been a guarantee, for any driver, that > a read(2) will return the full amount of bytes requested. I know. Still leaves lot's of people that assume that reading /dev/random will return data, or will block. I've seen lots of programs that will assume that if we request x bytes from /dev/random it will return x bytes. > There is no need to document this... man read(2) ;-) > > Jeff Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> "totally block"? > > For a blocking fd, read(2) has always blocked until some data is > available. There has never been a guarantee, for any driver, that > a read(2) will return the full amount of bytes requested. Hmm.. Some came to mind : Making /dev/random block if the amount requirements aren't met makes sense to me. If I request x bytes of random stuff, and get less, I probably reread /dev/random. If it's entropy pool is exhausted it makes sense to be to block. Just some mind spin. > There is no need to document this... man read(2) ;-) > > Jeff Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> > I know. Still leaves lot's of people that assume that reading /dev/random > > will return data, or will block. > > > > I've seen lots of programs that will assume that if we request x bytes > > from /dev/random it will return x bytes. > > I find this really humorous honestly. I see a lot of people assuming that if > you write N bytes or read N bytes that you will have done N bytes. There are > return values for these functions that tell you clearly how many bytes were > done. Of course. Lesson one : check return values > Any programmer who has evolved sufficiently from a scriptie should take > necessary precautions to check how much data was transferred. Those who > don't..well, there is still tomorrow. > > There is no reason to add any additional documentation. If we did, we'd be > starting the trend of documenting the direction a mouse moves when it's > pushed and not to be alarmed if you turn the mouse sideways and the result is > 90 degrees off. random devices are different. If it request 10 bytes on random stuff, I want 10 bytes. Anything less is a waste of the read, because I need 10 bytes. At least, in my opinion. Anyone has an insight how other *NIX'es handle this ? > -d Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> > Making /dev/random block if the amount requirements aren't met makes sense > > to me. If I request x bytes of random stuff, and get less, I probably > > reread /dev/random. If it's entropy pool is exhausted it makes sense to be > > to block. > > This is the job of the program accessing /dev/random. Open it blocking or > non-blocking and read until you satisfy your read buffer. Agree, if randomness is guaranteed in that case. I usually bail out in that case. Time to change that :) > -d Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> Well, that's the Unix interface you. I you don't like it, why don't you > become a Windows programmer and try your hand at the Win32 interface? :-) > > Seriously, doing something different for /dev/random compared to all > other read(2) calls is a bad idea; it will get people confused. The > answer is whenever you call read(2), you must check the return values. > People who don't are waiting to get themselves into a lot of trouble, > particularly people who writing network programs. The number of people > who assume that they can get an entire (variable-length) RPC packet by > doing a single read() call astounds me. TCP doesn't provide message > boundaries, never did and never will. The problem is that such program > will work on a LAN, and then blow up when you try using them across the > real Internet. > > Secondly, the number of times that you end up going into a kernel is > relatively rare; I doubt you'd be able to notice a performance > difference in the real world using a real-world program. As far as > source/object code bloat, well, how much space does a while loop take? > And I usyally write a helper function which takes care of the while > loop, checks for errors, calls read again if EINTR is returned, etc. Agree. I thought that en exhausted entropy pool gave less random numbers on the next read. After having a look at the source I realized I was taking nonsense. > - Ted Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
> This is standard stuff... You are really pissing into the wind here ;) Guess I am. Still isn't an explaination why I see a lot of broken code out there regarding this issue. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia-cd-3.1.19
On Thu, 31 Aug 2000, Ibrahim El-Shafei wrote: > Hi, > When I tried to install the pcmcia-cs-3.1.19, I got a message that I > attached it with this E-Mail, so I stopped the installation until I find the > answer. Date doesn't like that no timezone is set. Try setting one. man date might be helpful. > This may help you: > I live in Egypt/CAIRO > > thanks for help. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MTBF data for linux
On Fri, 1 Sep 2000, Jim Garlick wrote: > Can someone point me to MTBF data for Linux? I realize this is kind of > vague. Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha, > but any data is better than nothing. This is to help win an argument to > put linux on a large cluster. Thanks in advance. MTBF is something that says shit. depends on hardware, what the machine does, if it has a UPS, etc, etc, etc, etc. This machine is running 2 years without problems. > Jim Garlick Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MTBF data for linux
On Fri, 1 Sep 2000, Matthew Dharm wrote: > I agree that the MTBF can be very misleading... > > But put it this way: My server ran 2.2.14 for over 400 days before I > rebooted it. It was down for about 5 minutes while rebooting (probably > less). > > My NT Server gets a nightly reboot. I can't get it to run for more than a > week without it developing _some_ problem. > > Mind you, on both of these systems, nobody is doing any development/kernel > hacking/anything. They're just mail/www/ftp/dns/login (for linux) servers. > To a first order approximation, they're basically the same hardware, both > protected by a UPS. MTBF is something that's only of value when identical things are compared, 1000 of those things are tested, and some statisticall data is calculated. With PC, the're just to many factors that play a role. I think it's safe to assume that with proper management downtime is less than an hour on a yearly base. Downtime is mostly cause by upgrades, both hardware and software. These are values I actually present to customers. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: thread rant
On Fri, 1 Sep 2000, Michael Bacarella wrote: > > Q: Why do we need threads? > A: Because on some operating systems, task switches are expensive. No. threads share variable and code memory, processes do not. And sometimes it can make your life a lot easier. Even if you can use things such as SHM or so. > Q: So, threads are a hack to get around operating systems that suck? > A: Basically. I don't agree. > Q: So, why must Linux support threads? > A1: : | > A2: So other programs can be easily ported to Linux! > > That can already happen. It's not the *best* implementation. It's > not as fast as it can be. But it works. And that's all it should do. If > you're not happy, cope. > > "But threads on this system are faster than on Linux!" > > The fact that the system implements threads speaks enough about > it's capabilities. ie, it's trying hard to suck less. So, from my POV, > we're looking to make Linux suck more by effectively emulating systems > that are trying to suck less. > > But, I've never done anything worthwhile for Linux, so take this for what > it's worth, from an asshole. > -MB Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IrDA and PCMCIA
> ... > Linux PCMCIA Card Services 3.1.11 > options: [pci] [cardbus] [pm] > Yenta IRQ list 0698, PCI irq11 > ... The PCMCIA IRQ probes can hang the system if it probes the wrong IRQ. Fix your PCMCIA config. > Without the next line. I don't know what's wrong on my side -- > kernel 2.2.16 worked just fine... There is a possibility, that I'll check > later, 'cause it can be my modification to get_random_bytes that just > returns with exit code 1 instead of writing anything to the text console. > > 2. the second issue is not so simple. When I load some modules for > my IrDA to work: > > ircomm-tty 18376 0 (unused) > ircomm 6648 0 [ircomm-tty] > irtty 5092 2 > irport 4544 0 (unused) > irda 75201 2 [ircomm-tty ircomm irtty irport] > > and fire up irattach and irmanager (btw, smc-ircc module doesn't > work... Maybe i've got to supply some IO addresses, but I don't know them > and it's my first day of playing with this...) with devices discovery on, > it doesn't discover anything. (If anyone want, I can check if it does emit > any kind of infrared then with my Palm, but for the tests I've been using > Nokia 7110 mobile phone). When I remove my Xircom CEM-56 PCMCIA card from > it's slot, suddenly... there is my phone discovered! And if I put this > PCMCIA card do it's slot, IrDA connection and pc card are working > seamlessly. > > What should I do? Is this a bug? If so, can I help? I am not a > coder... and I'm NOT subscribed to this list (I can't fetch it using my > 28k8 dialup connection), so PLEASE CC: every mail in reply to this to > me... Please post this to the PCMCIA list / developers. Seems like things bite eachother. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
> >You can not go after people for patches. > > Hi, > > >there is no GPL issue. Upon Microsoft's adpotion of the model they will > > of course you can. Just don't release a patch but grab the driver > you're patching against (which is GPL), add your modifications and > release your driver with full task file access as a complete package > (including the full .c and .h files) under GPL which is compilant with > the available license. I think you can even do this with a patch. But > then again it is your call to add or name a license. > > It is your code. You can put it under every license you want. You can > even put it under the "no white male over 28 years and left handed is > allowed to use this code unless he types it into the keyboard with > only his left hand and the right hand tied behind his back" > license. If is, after all, _YOUR WORK_ and you can choose to license > it in every way that you want. > > There are even countries (like Germany) where you CAN'T give up your > copyright and put things into public domain. There is no such thing as > public domain here. You _always_ keep a certain copyright until > someone else assumes responsibility. It is for sueing people over > here. :-) > > >Linux rejected the code because it does not understand nor does anyone > >have the desire to learn what it does. Since it is not in the kernel > > Neither "Linux" rejected your code (may be Linu_s_ did) nor was it > rejected because no one understood it (you have a big ego to say > that. I would think that most of the developers here are able to > understand what your code does. There is no real magic in it) but > because there is an effort to stabilize and release 2.4. And, as Alan > said, sometimes things just miss deadlines. You don't keep introducing > new variables if you want to stabilize things. The existing IDE driver > works fine for normal operations so it was kept. I would bet much that > your IDE driver will be one of the first things included once 2.5 is > opened up. > > Until then, nothing stops you from releasing patches against official > 2.2 and 2.4 releases. I'm sure that many people will use it and SuSE > will put it into its kernel (they put everything they can find on the > net into their kernel :-) ). I will use it as I really enjoy the new > features for IDE under 2.2. But not on my business-critical machines > but on my Workstation and my machine at home. > > >be years ahead of Linux. FreeBSD does something similar and I expect them > >to soon to begin laughing at us for being stupid. > > Andre, it took me a while to realize that the best thing to cope with > "FreeBSD will laugh at us" to look onto the installed server and user > base and then to realize that BSD was years before Linux and failed > where Linux succeeded. And Linux did not succeed because it was aimed > "at the server market" or "at the end user" but because there is a > bunch of people _that_ _do_ _not_ _care_ _at_ _all_ about the > "marketability" of a feature but for the correct solution. As long as > decisions in the kernel are made because of good and bad taste, I'm > not at all afraid for Linux. > > "They" came to Linux. Not vice versa. And "they" did not come just > because Linux is good. But because the alternatives are worse. And are > not improving. Just ask yourself why there was no such rave about the > release of the 4.4BSD code, the first FreeBSD and the first OpenBSD > release. It is not because their code is bad. But they have no cute > mascot as Tux and no all-famous benevolent dictator from Finland. :-) > > Regards > Henning > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
Sorry for the last mail. Wrong button. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
> But they can take the ideas and methods demonstrated by the code in the > patch. Its not that they are going to take what he wrote and run patch > against their code. They can take a good idea, sit a skilled programmer in a > room and adapt the concepts without a bit of a problem. I call this a 'derived work' and if M$ does something to my code / ideas I'll personally sue their ass off. But then again, all what M$ has 'invented' is a totall rip, so it would be time that they would lose a case in court about this.. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: What the Heck? [Fwd: Returned mail: User unknown]
> Ugh. What rubbish. > > The moment I detect my provider changing anything beyond a TTL is the > moment I find a new provider. The 'problem' is a bunch of stupid American politics (excuse anyone American), than passed a law that all spam containing a remove adress is legal. So that means I get all kinds of spam containing 'This is legal because blahblah Bill blablah' Well, I don't live in the US, and that bill is not legal here. I basically block the entire IP after receiving SPAM. It the domein is proven to be 'spam-only', then I just block the entire domain as well. AOL is next on my TODO list. > I'm all for reduced spam, but I think you've absolutely gone over the top > on this one. I can't imagine how much spam you must receive to be willing > to hand over not only your freedom but MINE as well to corporate > profiteers. I get 10 a day or so. > As far as broadband service goes, just give the damn users fixed IPs and > let the opt-in blacklists handle them. My idea. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test8-pre4: innd fixed?
> 4.21, IIRC. Check the BUGTRAQ. Nobody had provided a full analysis, let > alone exploit, but there was an example of headers making pine _very_ > unhappy (attempt to save the mailbox after any modifications => screwed > mailbox). I didn't attempt to dig in the source - Mark et.al. got such a > "style" that... well, I know more pleasant ways to part with one's > breakfast. And making it SIG11. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Thu, 7 Sep 2000, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Which Linux companies are profitable? **NONE**. That's a statement with balls, which I would really see with some numbers.. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: write permissions and root.
> [root@pepsi /tmp]# su adam > [adam@pepsi /tmp]$ touch blah > [adam@pepsi /tmp]$ chmod -w blah > [adam@pepsi /tmp]$ echo hi > blah > bash2: blah: Permission denied > [adam@pepsi /tmp]$ exit > exit > [root@pepsi /tmp]# echo hi > blah > [root@pepsi /tmp]# ls -l blah > -r--r--r--1 adam adam3 Sep 8 21:11 blah > > if this matters it is 2.4.0-test7 Because root is allowed to override file permissions. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: write permissions and root.
> Correct me if I'm wrong, but I believe that all non-TOS > unices have behaved this way since the 70s. I see no reason why it shouldn't behave this way. Root can do su - user and screw up the file that way. Users with UID 0 are capable of doing about anything possible. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Using Yarrow in /dev/random
> No, not true. The mixing into the entropy pool uses a twisted LFSR, but > all outputs from the pool (to either /dev/random or /dev/urandom) > filters the output through SHA-1 as a whitener. The key here, though, > and what makes this fundamentally different from yarrow, is that since > we're feeding the entire (large) entropy pool through SHA-1, even if the > SHA-1 algorithm is very badly broken (say as in what's been happening > with MD5), as long as there's sufficient entropy in the pool, the > adversary can define but minimal information about the pool, since the > 8192 -> 160 bit transform has to lose information by definition. Broken ?? Please explain. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
On Fri, 15 Sep 2000, David Ciemiewicz wrote: > [4.] Linux version 2.2.14-5.0 ([EMAIL PROTECTED]) (gcc version Don't report bugs with this old version. [root@base igmar]# uname -a Linux base.jdimedia.nl 2.2.17acl #2 Mon Sep 11 02:23:03 CEST 2000 i586 unknown [root@base igmar]# cat /proc/tty/driver/serial serinfo:1.0 driver:4.27 0: uart:16550A port:3F8 irq:4 baud:1200 tx:3328 rx:354427 fe:245 brk:914 RTS|DTR1: uart:16550A port:2F8 irq:3 baud:9600 tx:103818 rx:4576 CTS|DSR 2: uart:unknown port:3E8 irq:4 3: uart:unknown port:2E8 irq:3 Works fine here. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
> Igmar, > > Thanks for attempting to validate that the problem is fixed in a > later release. However, I still stand by my submission. The problem was that the kernel was overwriting a userspace buffer, used to copy the data to. I can have a look at the code to see if it is really fixed. It seems really fixed, even dd likes the new sitation.. It always segfaulted with the old kernel. > If the readers will note, the problem is in 2.2.14 and > AND in 2.3.5 as referenced by another auther. It looks like the Both kernels are VERY OLD. 2.3.5 is ancient, 2.2.14 is also. Upgrading should be done anyway due to security bugs present in < 2.2.16 > info structure in drivers/char/serial.c:line_info is not sufficiently > initialized in all cases that might be processed by serial_in() > for instance, the CONFIG_HUB6 case. If line_info populates an > info struct and CONFIG_HUB6 is defined and info->hub6 is > dereferenced, there may well be garbage in info->hub6. > > I've searched the source trees and I don't see any of the fixes > between 2.2.14 and 2.2.17 referenced by the previous author at > the end of my original post. > > That said, the incompletely initialized "info" structure problem > exists. The fact that you and many others may not encountered the > problem is pure happenstance either because CONFIG_HUB6 was not > configured or you were lucky enough not to have garbage in any > of the data structures. > > So, if I upgraded to 2.2.17 and the problem went away, that doesn't > mean the problem doesn't exist, it just means that the problem may > simply be being masked or has not yet been encountered. I'll have a look at the code these days.. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
On Sat, 16 Sep 2000, David Ford wrote: > There was a round of discussion about /proc.../serial back in May. It > covered corruption and bad addresses. Although it didn't specifically say > "I'm fixing the segmentation fault that some people are going to report", > they did indeed discuss the bad data, smp locking, and etc precisely on > serial.c. > > If a specific problem such as a bad address went away by upgrading, there's a > very strong chance that the bug was fixed. Such problems aren't likely to > migrate around in the kernel and be hidden, they tend to stay localized. > Instead of searching for a given author's comments, diff the two files and > see if the initializing code changed. A lot of fixes go in without specific > credits. That's also my thought.. I'll diff the files tomorrow, and see what comes out. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PERCRAID 3 drivers?
On Sun, 17 Sep 2000, Bruce A. Locke wrote: > > Hello... > > The organization I do some work for purchased a rackmount server from > Dell with the intent of running some webconferencing software under > Linux. The salesman we had spoken to assured us that Linux fully > supported the machine. Yeah... Right... :) Tell those morons at Dell that a binary module is NOT providing support. Support breaks when upgrading a machine. So sue them :) Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: can kernel memory allocated by kmalloc be swapped out??
On Sun, 17 Sep 2000 [EMAIL PROTECTED] wrote: > hi everyone, > > suppose i allocate some kernel memory in a module by calling kmalloc, > can that memory be swapped out, for example in AIX even the kernel memory > which is allocated by rmalloc is swappable!! No, kernel memory is not swappable. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: PERCRAID 3 drivers?
On Sun, 17 Sep 2000 [EMAIL PROTECTED] wrote: > The aacraid driver was submitted to Alan Cox, but rejected because it has > too many "NTism's" in it, which are being addressed. Please see the Red Hat > Linux "Pinstripe" beta kernel source RPM for the source code, or contact me > privately. In my opinion, manufacturers should provide docs, not some buggy peace of software that needs to be completely rewritten afterwards. This has a few advantages : - It saves Dell a lot of time - It makes fixes easier to make But I'm glad Dell provides sources :) > Sincerely, > Matt Domsch > Dell Enterprise Systems Group > Linux Development Team Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
> reproduce the exact kernel configuration of my running 2.2.14 system > and a 2.2.17 kernel. (It would be extremely useful to have a pointer > to a tool which would duplicate the configs rather than going through > the manual process of configuring the kernel build). cp .config new_kernel_dir cd new_kernel_dir make menuconfig make dep; make clean; make bzImage Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Oops] Unable to handle kernel NULL pointer dereference
> >>EIP; c01527b9<= > Trace; c015357b > Trace; c01363d8 > Trace; c012c1e7 > Trace; c01371a9 <__user_walk+4d/58> > Trace; c012c23b > Trace; c011d630 > Trace; c0108d83 > Code; c01527b9 > <_EIP>: > Code; c01527b9<= >0: f6 43 34 40 testb $0x40,0x34(%ebx) <= > Code; c01527bd >4: 74 07 je d <_EIP+0xd> c01527c6 > > Code; c01527bf >6: 31 c0 xor%eax,%eax > Code; c01527c1 >8: e9 f9 00 00 00jmp106 <_EIP+0x106> c01528bf > > Code; c01527c6 >d: 8b 53 48 mov0x48(%ebx),%edx > Code; c01527c9 > 10: 85 d2 test %edx,%edx > Code; c01527cb > 12: 74 43 je 57 <_EIP+0x57> c0152810 > Smells like the famous quota bug. Didn't there get a patch posted a few days ago ? Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mousedev.c
Hi,
Patch looks not necessary. The compiler executes the statements until it
encounters a break.
> - case BTN_EXTRA: if (list->mode > 1)
>{ index = 4; break; }
> + case BTN_EXTRA: if (list->mode > 1)
>index = 4; break;
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Reproducable hard locks in 2.2.17. IDE related
Hi,
This machine is running 2.2.17aa2 (I needed LFS), and I'm able to lock it
hard. This is what was in the logs :
Sep 21 23:55:38 fs1 kernel: hdc: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Sep 21 23:55:38 fs1 kernel: hdc: dma_intr: error=0x40 { UncorrectableError
}, LBAsect=16373421, sector=3521368
Sep 21 23:55:38 fs1 kernel: end_request: I/O error, dev 16:02 (hdc),
sector 3521368
Sep 21 23:55:41 fs1 kernel: hdc: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Sep 21 23:55:41 fs1 kernel: hdc: dma_intr: error=0x40 { UncorrectableError
}, LBAsect=16373421, sector=3521376
Sep 21 23:55:41 fs1 kernel: end_request: I/O error, dev 16:02 (hdc),
sector 3521376
Sep 21 23:55:44 fs1 kernel: hdb: timeout waiting for DMA
Sep 21 23:55:44 fs1 kernel: hdb: irq timeout: status=0xd0 { Busy }
Sep 21 23:55:44 fs1 kernel: hda: DMA disabled
Sep 21 23:55:44 fs1 kernel: hdb: DMA disabled
Sep 21 23:55:44 fs1 kernel: ide0: unexpected interrupt, status=0xd0,
count=1
Sep 21 23:55:44 fs1 kernel: ide0: reset: success
After that it locked solid.
Relevant dmesg output :
PCI_IDE: unknown IDE controller on PCI bus 00 device 08, VID=1106,
DID=1571
PCI_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x6000-0x6007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x6008-0x600f, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 71626 AP, ATA DISK drive
hdb: Maxtor 91021U2, ATA DISK drive
hdc: Maxtor 91021U2, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: Maxtor 71626 AP, 1554MB w/128kB Cache, CHS=789/64/63, DMA
hdb: Maxtor 91021U2, 9641MB w/512kB Cache, CHS=1229/255/63, (U)DMA
hdc: Maxtor 91021U2, 9641MB w/512kB Cache, CHS=19590/16/63, (U)DMA
The above is bad... It is using an unknown IDE controller, and it seems to
use UDMA.
lspci -v gives :
00:00.0 Host bridge: Stratus Computers VIA VT82C570MV [Apollo] (Wrong
vendor I
) (rev 02)
Flags: bus master, fast devsel, latency 0
00:01.0 IDE interface: VIA Technologies, Inc. VT82C416MV (rev 04) (prog-if
8a
aster SecP PriP])
Flags: bus master, medium devsel, latency 32
I/O ports at 6000
00:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink]
(rev
)
Subsystem: 3Com Corporation: Unknown device 1000
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at 6100
Memory at f100 (32-bit, non-prefetchable)
Capabilities: [dc] Power Management version 2
00:0b.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA])
Flags: medium devsel, IRQ 10
Memory at f000 (32-bit, prefetchable)
The reproduce is easy : I have 2 2.5 GB files, start two session at the
same time, and md5sum both files at the same time. Files are on a
different FS, on different disks. After about 20 minutes the machine locks
solid. I'll have the guy at the console see if it responds to sysrq..
Regards,
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Reproducable hard locks in 2.2.17. IDE related
On Fri, 22 Sep 2000, Alan Cox wrote:
> > This machine is running 2.2.17aa2 (I needed LFS), and I'm able to lock it
> > hard. This is what was in the logs :
> >
> > Sep 21 23:55:38 fs1 kernel: hdc: dma_intr: status=0x51 { DriveReady
> > SeekComplete Error }
>
> A disk seek failed
>
> > Sep 21 23:55:38 fs1 kernel: hdc: dma_intr: error=0x40 { UncorrectableError
> > }, LBAsect=16373421, sector=3521368
>
> Uncorrectable error is the drive.
No, that's not the case. If it md5sum the file one at a time, all is fine.
Both disks are brand new, so I doubt a hardware failure on the disk side..
It could be that it is choking on the fact that one drives is LBA, one
drive isn't. Drives are identical, but dmesg gives different CHS for each
of them..
> > Sep 21 23:55:44 fs1 kernel: hdb: timeout waiting for DMA
> > Sep 21 23:55:44 fs1 kernel: hdb: irq timeout: status=0xd0 { Busy }
> > Sep 21 23:55:44 fs1 kernel: hda: DMA disabled
> > Sep 21 23:55:44 fs1 kernel: hdb: DMA disabled
> > Sep 21 23:55:44 fs1 kernel: ide0: unexpected interrupt, status=0xd0,
> > count=1
> > Sep 21 23:55:44 fs1 kernel: ide0: reset: success
>
> Then it tried an IDE reset, then it choked
Why the total meltdown ?
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Reproducable hard locks in 2.2.17. IDE related
On Fri, 22 Sep 2000, Carsten Lang wrote: > i don't think that we can blame the disks! > I have 3 different drives, which produce this error after 24 hrs under heavy load. This one chokes after about 10 mins. Total meltdown. Drives are brandnew, so I doubt the failure. If I md5sum the files after eachother instead both at the same time, no errors. In case of a real disk failure, it should also bark in this case. The only difference is the load : about 1.0 in case 1 (no crash), > 2.0 in case 2 (total meltdown) Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Reproducable hard locks in 2.2.17. IDE related
> This is the following problem > > hda: Maxtor 71626 AP, 1554MB w/128kB Cache, CHS=789/64/63, DMA > hdb: Maxtor 91021U2, 9641MB w/512kB Cache, CHS=1229/255/63, (U)DMA > hdc: Maxtor 91021U2, 9641MB w/512kB Cache, CHS=19590/16/63, (U)DMA I'll put both UDMA drives on ide1 and kick it's ass again. I'll let you know what it does.. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Reproducable hard locks in 2.2.17. IDE related
> Do you have stuff logged about trying to access out of range blocks ? No. It start to bark about the DMA mode and then dies. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Reproducable hard locks in 2.2.17. IDE related
On Fri, 22 Sep 2000, Andries Brouwer wrote:
> On Fri, Sep 22, 2000 at 02:34:16PM +0200, Igmar Palsenberg wrote:
>
> > It could be that it is choking on the fact that one drives is LBA, one
> > drive isn't. Drives are identical, but dmesg gives different CHS for each
> > of them..
>
> A FAQ. See
> http://www.win.tue.nl/~aeb/linux/Large-Disk-14.html#ss14.2
> ("Nonproblem: Identical disks have different geometry?")
>
> Furthermore, it seems there is a misunderstanding here.
> "One drive is LBA, the other isnt" is nonsense.
I meant to say that :)
Normally I don't care, some cases I do (RAID is one of them)
> (There are two access methods to disks, sometimes called CHS and LBA
> access. These days all disks are capable of handling LBA, and Linux
> always uses LBA.
> There are zillions of geometry invention, distortion and translation
> methods, a few thousand of which are called LBA. Such geometry business
> is completely unrelated to Linux disk access.
> You seem to confuse the former LBA with the latter.)
>
> > hda: Maxtor 71626 AP, 1554MB w/128kB Cache, CHS=789/64/63, DMA
> > hdb: Maxtor 91021U2, 9641MB w/512kB Cache, CHS=1229/255/63, (U)DMA
> > hdc: Maxtor 91021U2, 9641MB w/512kB Cache, CHS=19590/16/63, (U)DMA
>
> Here 1.4 MB is wasted on hdb because the BIOS has invented
> this 1229/255/63 translation. The disk access methods on
> hdb and hdc is the same.
Yep. We're trying to put hdb and hdc on the same controller. According to
Andre the VIA bugs with this setup. It isn't hard for me to produce the
lockup (my god, I love 2.5 GB random data :)), so I'll test it when things
are swapped.
> Andries
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mousedev.c
On Fri, 22 Sep 2000, Russell King wrote:
> You're telling us that:
>
> if (list->mode > 1) {
> index = 4;
> break;
> }
>
> is the same as:
>
> if (list->mode > 1)
> index = 4;
> break;
No, it isn't.. Ws confused with switch() {}
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Reproducable hard locks in 2.2.17. IDE related
> > > Do you have stuff logged about trying to access out of range blocks ? Putting primary to secondary slave (two UDMA devices on the same bus) fixed the lockup. The second drive was ginging errors in some cases, and sometimes it didn't. Was the reason I couldn't reproduce the unrecoverable error. It's send back to the manufacturer. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Reproducable hard locks in 2.2.17. IDE related
On Fri, 22 Sep 2000, Andre Hedrick wrote: > On Fri, 22 Sep 2000, Andries Brouwer wrote: > > > Here 1.4 MB is wasted on hdb because the BIOS has invented > > this 1229/255/63 translation. The disk access methods on > > hdb and hdc is the same. > > Yes, and soon CHS will go away completely with 48-bit LBA or if you CHS > these large drives. I considered the making of a forced policy if you > have drives beyond 80 or 100 GB but policies are pooh-poohed regardless if > they are correct. Thus I will have to wait for the 137GB limit to enforce > the standard and make the default CHS limited to 137GB and beyond that you > have to use LBA. Yep.. Maybe it's a good idea in case of the buggy VIA to bark loudly if a DMA and non DMA disk are on the same bus ?? I'll have a look at the code and see if I understand is. Golden rule : Never without coffee, I mix up if () and switch() :-))) Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CS8920 Crystal lan adapter driver.
On Sun, 24 Sep 2000, MOHAMMED AZAD wrote: > Hi all, > > Any one using crystal lan cs8920 adapters.??? .. mine is a cs8920 > crystal lan adapter.. as per the driver source.. driver does not support > pnp.. and i need to disable it... after disabling pnp and giving an irq and > i/o address the driver gets loaded.. but still i am not able to configure my > network... any help appreciated... Please define 'not able to configure my network'. Some error messages would be handy :-) Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: "Tux" is the wrong logo for Linux
On Thu, 19 Oct 2000, KMF AV wrote: > First, the 2.4 kernel is years late and doesn't work > right, and keeps getting rewritten because it's a > festering hunk of fetid spaghetti inside. Well, in that case shut up and write your own. Second, don't hide behind a yahoo.com adress when making these kind of statements. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, > kernel 2.2.x), within a few minutes you will find your entire machine > grinds to a halt. For example, nobody can log in. > > This happens because once the /dev/log buffer fills, the syslog() > glibc function blocks. > > This is a problem for us in Real Life because named and syslogd are > deadlocking while trying to talk to each other. On our loghost, > syslogd needs to do reverse name lookups while named needs to call > syslog(). When traffic gets heavy all around, the deadlock is > triggered, and it is quite unpleasant. We are about to configure > named to use flat files instead of syslog, but that feels more like a > workaround than a fix. > > I am not sure whether this is a glibc bug or a kernel bug. I have > used netstat and the glibc sources to confirm that glibc is using a > SOCK_DGRAM Unix socket to send to /dev/log. I thought DGRAM sockets > were supposed to drop packets on the floor instead of blocking. But > perhaps I am wrong and glibc is supposed to be explicitly marking the > socket as non-blocking. > > Regardless of whose bug it is, I suggest that it needs to be fixed. > To my knowledge, other Unix systems do not behave this way; they > simply drop messages when syslogd is not responding. IMO, that is > correct behavior. This is a long standing. A perfect example that triggers the named part is Netscape : I one window does a lookup, all other windows are dead. I don't know the exact cause of this problem, you'll have to ask the glibc guys for this. The correct behaviour in this case is syslog() to stop doing lookups, dropping messages is unacceptable. Looking up a name afterward is no problem, loosing important messages is a problem. If you're talking remote syslogging here, putting all local hostnames in /etc/hosts would save named some work. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
> You obviously don't understand the communication channel being used. > "/dev/log" is a UNIX DOMAIN SOCKET -- AF_UNIX. Datagrams are unreliable > for _IP_ (AF_INET). Traffic on an AF_UNIX socket is always reliable. > > Ok, smarty, go change the syslogd source to open /dev/log as SOCK_STREAM > and watch it fail. (syslog wasn't invented yesturday.) > > I would suggest disabling name resolution for syslog, but that's an ugly > option. There's no way to stop a glibc system from doing a DNS query for > a reverse lookup. HOWEVER, you can set the DNS timeout to 1 second and > set the resolver options to prevent recursion (answer from cache only.) Reverse isn't necessary on a central loghost. Saves at least one system call. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
> Ulrich Drepper <[EMAIL PROTECTED]> writes: > > > If anything has to be changed it's (as suggested) the configuration > > or even the implementation of syslogd. Make it robust. > > OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM. > If I wanted reliable syslogging, it would be listening on it as a > SOCK_STREAM. Maybe I care more about performance and backwards > compatibility than reliable syslogging. But whatever my reasons, my > connection to syslogd is already unreliable and therefore *should not > block*. > > (Could a syslogd listen on /dev/log both as SOCK_DGRAM and as > SOCK_STREAM? If so, then your philosophy implies that glibc should be > trying SOCK_STREAM *first*, falling back to SOCK_DGRAM for historical > compatibility. Either way, when it uses datagrams, it should never > block, period.) The reason for this is that DGRAM is faster the STREAM. And with syslogd being on a fast, secure network I can understand the design filosofie behind this. I'll have a look at syslog, and see if I can hack out the reverse lookups. > - Pat Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: > Jesse Pollard <[EMAIL PROTECTED]> writes: > > > Don't configure syslogd to do reverse lookups. > > Our syslogd has no option to disable the reverse lookups. Requires a recompile. > > You can NEVER guarantee that the reverse lookup will succeed, and > > can be delayed several minutes for a single reply. > > Not true. The named on our loghost is authoritative for the reverse > mappings for all of the machines which can log there. Put the names of your machines in /etc/hosts on your logmachine. > > > I consider this a configuration error. I don't believe syslogd > > should ever do a reverse lookup, since the name you are trying to > > get may never arrive, or if arrives, it may be spoofed. > > There *is* no configuration for these tools which gives the behavior > you describe, so this is not a "configuration error". I agree that it is ugly that you can't disable reverse with syslog. There are implementations of the syslogd (syslog-ng) that do allow this. If you want to stick with the 'normal' syslog, either recompile with an option not do do reverse lookups, put you hosts in /etc/hosts, of hack the source. > > It's not a bug, but a security feature. NO log to syslogd should be > > lost, since it may be related to an attack. > > Historically, no other Unix system has had reliable syslogging. It > would require very defensive programming for syslogd, and that has > clearly not been performed. > > And if this is what GNU/Linux intends, why does glibc use a SOCK_DGRAM > socket for communication with syslogd? By definition, such sockets > are *unreliable*. If syslog is supposed to be reliable, a different > connection type must be used. Because if is fast. Second, you can assume that remote logging is NOT done over the internet, anyone who does is an idiot. So the change that some UDP packet get's lost is close to zero. I think the changes are higher that the connection oriented solutions would get messages lost. > Your philosophy that "no syslog message should ever be lost" is not > necessarily bad. But it is clearly at odds with historical practice, > the current glibc syslog() implementation, and the current syslogd > itself. > > It is true that glibc falls back to using SOCK_STREAM if the > SOCK_DGRAM connection fails. Does that mean GNU/Linux is expects > syslog to be reliable eventually? If so, then my problem is entirely > a bug in syslogd and I will report it as such. I agree with the bad configuration remark at top. WHY do you want named to do the reverse ?? Putting things in /etc/hosts makes thing hell of a lot faster. With a central loghost that makes sense to me. > - Pat Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
> No, I didn't say they "should" be dropped but merely that dropping them > would fix your problem. Personally, I'd look closely at your setup to > determine exactly why this has become a problem. named is being blocked > on writing to /dev/log. This should only happen if there is sufficient > _local_ syslog traffic to fill the buffer or syslogd has too much remote > traffic to ever read from /dev/log. > > Per chance are you running the name service caching daemon (nscd)? I'd > also guess you aren't disabling fsync() for your sysylog files (it's part > of the syslog.conf format) -- this is a conciderable drain on syslogd. Agree. It is there for a reason : I case the system hangs, you at least get the last messages. But it is indeed a major drain. I've send Patrick a small path that makes reverse lookups a config option. Please note that syslog does NOT resolve things it get's from the local machine, it uses gethostname() for that name. > --Ricky Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
> Perhaps syslogd is not giving higher priority to local messages; if it > did, maybe it could recover from the deadlock. But this would not be > a reliable solution; the only reliable solution is for syslogd to be > independent of any processes which need to talk to it. In that case, don't do lookups at all. Let a script do resolving in a crontab or so. analog uses a nice solution for this : store hostnames in a file. When it doesn't know a hostname, look it up. That saves tons of querys. > > Per chance are you running the name service caching daemon (nscd)? > > No. > > > I'd also guess you aren't disabling fsync() for your sysylog files > > (it's part of the syslog.conf format) -- this is a conciderable > > drain on syslogd. > > I see no documentation for such an option in the syslog.conf man page. > This is with the current Red Hat 6.2 syslogd (package > sysklogd-1.3.31-17). There is. see man syslogd(8). You need to prefix files that don't need to be synced() with a - > - Pat Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID superblock
On Wed, 25 Oct 2000, Anil kumar wrote: > Hi, > After I create a RAID setup on the drives,The > superblock will be generated at the end of the drives. > If I move these drives to other linux system, will > this > system recognise the RAID setup without reconfiguring > the Linux ? If the CHS / LBA settings are the same, and the kernel is the same : Yes. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
> This is not an option for us, unfortunately. Many of our IP addresses > are dynamically assigned, with the DNS tables dynamically updated. Not an option in that case. > Thank you for the patch to syslogd, though! Can you try to get your > "-x" option into the standard distributions of syslogd, or should I > work up a bug report / feature request for Red Hat myself? I have no idea who officially maintains it.. putting a bug report with RH should be a good idea. The patch is untested, so someone needs to verify that remote logging indeed nog is IP only. > - Pat > Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
> Sadly, you WILL still lose entries if the system crashes before fs metadata > has been flushed to disk. Unless the inode has the correct size stored, the > crap fsync()ed to disk doesn't make much difference. Yep. I can't really think of a case where you wouldn't lose data in case of for example a hard lock. > (This is amplified by dcache.) I'm not that familiar with kernel internals.. To bring up that point : Anyone had a good advice on a good OS internals book ?? I'm gonna read the 2.2.x kernel sources, so I could use a good background. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Big file support in Linux 2.2
> Hello, > > For one of our projects here, we've crashed head first into the 2 gig file size > limitation in Linux 2.2 kernels. While I know that this has been solved in > 2.3/2.4, has there been any work to backport this feature into a Linux 2.2 > kernel? I'm looking for a temporary solution until we can move to Linux 2.4 > directly, but obviously not until after it's been "really" released. :) > > Yes, I know this is likely to be relatively unstable. (Probably almost as > unstable as running a 2.4-pre kernel in production), but at least it would give > us a start. Seek for LFS on Freshmeat. Requires a kernel patch, and a glibc recompile. I'm still having some problems with it, mainly cp -ar giving some wonderful weard strace results. > > Thanks for your help, > > Joe Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mkraid
On Fri, 27 Oct 2000, [iso-8859-1] Jakob Østergaard wrote: > On Fri, Oct 27, 2000 at 10:56:16AM -0700, Anil kumar wrote: > > Hi, > > > > I have a problem with mkraid > > This is Linux-RAID specific and not material for the linux-kernel > list. > > Please, just post your questions to linux-raid, not linux-kernel. > > And most importantly, when you ask me these exact same questions in direct > e-mail anyway, it is a little wasteful to also trouble this list with your > question as well. > > Thank you, > (and you got the answer in the reply to the direct mail two minutes ago) He isn't reading the docs.. I agree that making RAID fully work (including RAID'ed root-fs) takes some nicely hacking, but not that can be done without docs. I did it, so can anyone else Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID superblock
On Sun, 29 Oct 2000, Peter Samuelson wrote: > [Wakko Warner] > > While this subject is fresh, what would be wrong with using the > > entire drive as opposed to creating a partition and adding the > > partition to the raid? > > Does it autodetect an entire drive? The autodetect logic for > partitions looks at the 'partition type' byte, which of course doesn't > exist for a whole drive. > > Just a thought .. I don't run RAID here. A good one. I seriously doubt that it indeed will detect drives. The're not partitions, the're drives. Don't think the current RAID code handles entire drives. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
> > It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a > > Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack, > admin stupidity) then I sure don't want the system freezing up. In some cases, I find the syslog messages of more importance then a working system. I like to know what's going on on my machines. > ( heh... at work on Solaris I monitor 300+ systems, and it's not unusual > to find 1 box a week with syslog not running for some reason or another. > I can't decide whether it's admin stupidity or bugs in Solaris syslog - of > which there are many :-(( ) > > syslog is not meant to be a secure audit system. Messages can be > legitimately dropped. I find dropping messages unacceptable. > Applications have been coded assuming that they > will not be frozen in syslog(). Linux should not be different in this > respect. Hmm... it might be nice to be this a system tunable parameter > but I'm not sure the best way of doing that (glibc maybe?) I needs to be in glibc, yes. > > Stephen Harris Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
