Re: 2.6.16.32 stuck in generic_file_aio_write()
Hi, > I can not make sure it is hardware problem, but I have interest in this > case's reproducing. > If you tell me your platform's construction, I will try it and give you good > solution. > Does your RAID adapter's firmware version work on 1.42? > Areca firmware had fix some hardware bugs and rare sg length handle in this > version. I've hacked up the sysrq code so that it gives me another command : j , which dumps the current IRQ status on the console : SysRq : Show IRQ status .. Showing info for IRQ 14 status : depth : 0 wake_depth : 0 irq_count : 38717 irqs_unhandled : 0 Showing info for IRQ 15 status : DISABLED depth : 1 wake_depth : 0 irq_count : 22 irqs_unhandled : 0 which is a the (incomplete) result on my machine after loading a module that does disable_irq(15) on module load. I've put the patch at http://www.jdi-ict.nl/areca/sysrq-j.patch I'll do a follow-up when anything usefull comes out. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
Hi, > I can not make sure it is hardware problem, but I have interest in this > case's reproducing. > If you tell me your platform's construction, I will try it and give you good > solution. The machines giving problems are almost identical when it comes to hardware specs : Intel SE7520BD2 mainbord (SE7520 chipset) Dual Intel Xeon 2.8 Ghz (other machine : Dual Xeon 3.2 Ghz) 4 GB PC3200 ECC (400 Mhz) Corsair (other machine : 2GB PC3200 ECC) > Does your RAID adapter's firmware version work on 1.42? > Areca firmware had fix some hardware bugs and rare sg length handle in this > version. It's currently at 1.41. I'll see if I can upgrade it to 1.42. For now, I've put all available stacktraces when it hung on http://www.jdi-ict.nl/areca, together with a lspci -v -v and a copy of the kernel's .config Please let me know if you need anything else. Regards, Igmar -- Igmar Palsenberg JDI ICT Zutphensestraatweg 85 6953 CJ Dieren Tel: +31 (0)313 - 496741 Fax: +31 (0)313 - 420996 The Netherlands mailto: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> Does the other machine have the same problems? It does. It seems to depend on the interrupt frequency : Setting KERNEL_HZ=250 makes it ony appear once a month or so, with KERNEL_HZ=1000, it will occur within a week. It does happen a lot less with the other machine, which isn't under disk activity load as much as the other machine. > Are you able to rule out a hardware failure? Well.. It's too much coincidence that 2 (almost identical) machines show the same weard behaviour. What strikes me that only *disk* interrupts after a while don't get handled. The machine itself is alive, just all disk IO is blocked, which makes it pretty much useless. Erich, could this be some sort of hardware problem ? I know it's a PITA to reproduce, but setting CONFIG_HZ to 1000 and bashing the machine with diskactivity seems to help :) Regards, Igmar -- Igmar Palsenberg JDI ICT Zutphensestraatweg 85 6953 CJ Dieren Tel: +31 (0)313 - 496741 Fax: +31 (0)313 - 420996 The Netherlands mailto: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> > See below. The other machine is mostly identifical, except for i8042 > > missing (probably due to running an older kernel, or small differences in > > the kernel config). > > > > Does the other machine have the same problems? No, but that machine has a lot less disk and networkactivity. > Are you able to rule out a hardware failure? 100% ? No, but the hardware is relatively new (about a year old), and of good quality. It's hard to reprodure, so looking at it when it starts to fault isn't possible either :( > The disk interrupt is unshared, which rules out a few software problems, I > guess. Indeed. Bah, I hate these kind of things :( Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> > Hmm.. Switching CONFIG_HZ from 1000 to 250 seems to 'fix' the problem. > > I haven't seen the issue in nearly a week now. This makes Andrew's theory > > about missing interrupts very likely. > > > > Andrew / others : Is there a way to find out if it *is* missing > > interrupts ? > > > > umm, nasty. What's in /proc/interrupts? See below. The other machine is mostly identifical, except for i8042 missing (probably due to running an older kernel, or small differences in the kernel config). Regards, Igmar [EMAIL PROTECTED] ~]$ cat /proc/interrupts CPU0 CPU1 0: 73702693 74509271 IO-APIC-edge timer 1: 1 1 IO-APIC-edge i8042 4: 2289 8389 IO-APIC-edge serial 8: 0 1 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 3 1 IO-APIC-edge i8042 16: 203127788 0 IO-APIC-fasteoi uhci_hcd:usb2, eth0 17:525492 IO-APIC-fasteoi uhci_hcd:usb4 18: 1370 67584889 IO-APIC-fasteoi arcmsr 19: 0 0 IO-APIC-fasteoi ehci_hcd:usb1 20: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 NMI: 0 0 LOC: 148127756 148133476 ERR: 0 MIS: 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> > I'll put a .config and a dmesg of the machine booting at > > http://www.jdi-ict.nl/plain/ for those who want to look at it. > > dmesg : http://www.jdi-ict.nl/plain/lnx01.dmesg > Kernel config : http://www.jdi-ict.nl/plain/lnx01.config Hmm.. Switching CONFIG_HZ from 1000 to 250 seems to 'fix' the problem. I haven't seen the issue in nearly a week now. This makes Andrew's theory about missing interrupts very likely. Andrew / others : Is there a way to find out if it *is* missing interrupts ? Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> I've enabled most debugging now, I'll see of i can run both a disk and VM > stresstest. Running stress now : stress -c 2 -i 2 -m 8 -d 8 --vm-bytes 20M --vm-hang 5 --hdd-bytes 20M I'll see what this results in. > I'll put a .config and a dmesg of the machine booting at > http://www.jdi-ict.nl/plain/ for those who want to look at it. dmesg : http://www.jdi-ict.nl/plain/lnx01.dmesg Kernel config : http://www.jdi-ict.nl/plain/lnx01.config regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> I thought it was, but from my look through yout 8-billion-task backtrace, > no task was stuck in D-state with the appropriate call trace. I was afraid of that... Where is the lock on the i_mutex suppose to be released ? I can't grasp the codepath from within an interrupt back to the fs layer. > So I don't know what's causing this. In the first trace you have at least > four D-state kjournalds and a lot of processes stuck on an i_mutex. I > guess it's consistent with an IO system which is losing completion > interrupts. AFAICT in the second trace all you have is a lot of processes > stuck on i_mutex for no obvious reason - I don't know why that would > happen. Is there any way to see if it is missing interrupts ? Enabling the debugging in the areca driver isn't a good idea on this machine, it's a heavely IO loaded machine, and the problem seems to take some time to occur. I *does* happen less often with a 2.6.19 kernel however. The task dump takes > 10 seconds, which causes the softlock detector to trigger. Is there any objection to a patch which disables the lockup detector during the dump ? It isn't a big issue, since al it does is dump a stacktrace. I've enabled most debugging now, I'll see of i can run both a disk and VM stresstest. I'll put a .config and a dmesg of the machine booting at http://www.jdi-ict.nl/plain/ for those who want to look at it. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> > Done some more digging : isn't http://lkml.org/lkml/2006/10/13/139 somehow > > related ? I do see pagefaults, and inode locks and mmap_locks. > > > > I thought it was, but from my look through yout 8-billion-task backtrace, > no task was stuck in D-state with the appropriate call trace. > > So I don't know what's causing this. In the first trace you have at least > four D-state kjournalds and a lot of processes stuck on an i_mutex. I > guess it's consistent with an IO system which is losing completion > interrupts. Hmm.. Is there any way to make sure ? I've got a second machine (almost identical), which doesn't show this. The main difference is the running kernel. I've had them at the same kernel, at which bad machine still crashes. /proc/interrupts Bad machine : 18: 11160637 11235698 IO-APIC-fasteoi arcmsr Good machine : 18: 61658630 79352227 IO-APIC-level arcmsr Bad machine is running 2.6.19, good is running 2.6.14.7-grsec, which probably accounts for these changes. > AFAICT in the second trace all you have is a lot of processes > stuck on i_mutex for no obvious reason - I don't know why that would > happen. It's consequent, also the traces. > How long does it take for this to happen? Days to a week tops. It does happen less frequent with the 2.6.19, 2.6.16.32 triggered it almost daily. > Yes, lockdep might find something. I've enabled most debug options. I'll boot the other kernel tomorrow. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> > It's rather large, but for those who want to look at it : > > http://www.jdi-ict.nl/plain/serial-28112006.txt > > The same problem, this time with 2.6.19. I've done a show tasks, a show > locks, a show regs, and after that, a sync + reboot :) > > Log is at http://www.jdi-ict.nl/plain/serial-04122006.txt . > > If anyone needs more info : please tell me. Done some more digging : isn't http://lkml.org/lkml/2006/10/13/139 somehow related ? I do see pagefaults, and inode locks and mmap_locks. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
> It's rather large, but for those who want to look at it : > http://www.jdi-ict.nl/plain/serial-28112006.txt The same problem, this time with 2.6.19. I've done a show tasks, a show locks, a show regs, and after that, a sync + reboot :) Log is at http://www.jdi-ict.nl/plain/serial-04122006.txt . If anyone needs more info : please tell me. Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
Hi, > > I've got a machine which occasionally locks up. I can still sysrq it from > > a serial console, so it's not entirely dead. > > > > A sysrq-t learns me that it's got a large number of httpd processes stuck > > in D state : > > There are known deadlocks in generic_file_write() in kernels up to and > including 2.6.17. Pagefaults are involved and I'd need to see the entire > sysrq-T output to determine if you're hitting that bug. It's rather large, but for those who want to look at it : http://www.jdi-ict.nl/plain/serial-28112006.txt There is also a dump from a day later, but halfway the Areca controller decided to kick out the array, on which a lot of unwritten data needed to be written :) That dump is at http://www.jdi-ict.nl/plain/serial-29112006.txt Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
Hi, > If you are working on arcmsr 1.20.00.13 for official kernel version. > This is the last version. I'm already on that version. I'll see if I can upgrade to 2.6.19 today. > Could you check your RAID controller event and tell someting to me? > You can check "MBIOS"=>"Physical Drive Information"=>"View Drive > Information"=>"Select The Drive"=>"Timeout Count".. > It could tell you which disk had bad behavior cause your RAID volume > offline. I need to be in the BIOS right ? I couldn't find anything usefull with the cli32 tool. > About the message dump from arcmsr, it said that your RAID volume had > something wrong and kicked out from the system. > How about your RAID config? CLI> disk info Ch ModelNameSerial# FirmRev Capacity State === 1 HDT722516DLA380 VDK71BTCDB90KE V43OA91A 164.7GB RaidSet Member(1) 2 HDT722516DLA380 VDN71BTCDEPH7G V43OA91A 164.7GB RaidSet Member(1) 3 HDT722516DLA380 VDN71BTCDES96G V43OA91A 164.7GB RaidSet Member(1) 4 HDT722516DLA380 VDN71BTCDE15KG V43OA91A 164.7GB RaidSet Member(1) === CLI> rsf info Num Name Disks TotalCap FreeCap DiskChannels State === 1 Raid Set # 004 640.0GB0.0GB 1234 Normal === CLI> vsf info # Name Raid# Level Capacity Ch/Id/Lun State === 1 ARC-1110-VOL#001 Raid5480.0GB 00/00/00 Normal === A plain RAID 5 config with 4 disks. > Areca had new firmware released (1.42). > If you are working on "sg" device with scsi passthrough ioctl method to feed > data into Areca's RAID volume. > You need to limit your data under 512 blocks (256K) each transfer. > The new firmware will enlarge it into 4096 blocks (2M) each transfer. > The firmware version 1.42 is on releasing procedure but not yet put it on > Areca ftp site. I don't use the sg driver at all. Is the upgrade worth it ? I usually don't mess with firmware unless being told to do so. > If you need it, please tell me again. Can you send it to me ? Installing it won't hurt I guess :) Regards, Igmar -- Igmar Palsenberg JDI ICT Zutphensestraatweg 85 6953 CJ Dieren Tel: +31 (0)313 - 496741 Fax: +31 (0)313 - 420996 The Netherlands mailto: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.16.32 stuck in generic_file_aio_write()
Hi,
A followup. It crashed again, giving me :
arcmsr0: scsi id=0 lun=0 ccb='0xf7c984e0' poll command abort successfully
end_request: I/O error, dev sda, sector 3724719
and
sd 0:0:0:0: rejecting I/O to offline device
about 15k times.
I'll see if I can upgrade the RAID driver.
Igmar
--
Igmar Palsenberg
JDI ICT
Zutphensestraatweg 85
6953 CJ Dieren
Tel: +31 (0)313 - 496741
Fax: +31 (0)313 - 420996
The Netherlands
mailto: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.16.32 stuck in generic_file_aio_write()
Hi,
I've got a machine which occasionally locks up. I can still sysrq it from
a serial console, so it's not entirely dead.
A sysrq-t learns me that it's got a large number of httpd processes stuck
in D state :
httpd D F7619440 2160 11635 2057 11636 (NOTLB)
dbb7ae14 cc9b0550 c33224a0 f7619440 de187604 00b3 0001
00b3 d374a550 c33224a0 0005b8d8 f04af800
000f75e7
d374a550 cc9b0550 cc9b0678 ef7d33ec ef7d33e8 cc9b0550 ef7d33fc
c041bf70
Call Trace:
[] __mutex_lock_slowpath+0x92/0x43e
[] generic_file_aio_write+0x5c/0xfa
[] generic_file_aio_write+0x5c/0xfa
[] generic_file_aio_write+0x5c/0xfa
[] permission+0xad/0xcb
[] ext3_file_write+0x3b/0xb0
[] do_sync_write+0xd5/0x130
[] _spin_unlock+0xb/0xf
[] autoremove_wake_function+0x0/0x4b
[] vfs_write+0x1a3/0x1a8
[] sys_write+0x4b/0x74
[] sysenter_past_esp+0x54/0x75
After this, the machine is rendered useless (probably due to the fact that
disk IO isn't working anymore).
The lock debugging gives me this :
D httpd:11635 [cc9b0550, 116] blocked on mutex: [ef7d33e8]
{inode_init_once}
.. held by: httpd: 506 [d67e1000, 121]
... acquired at: generic_file_aio_write+0x5c/0xfa
I see similiar things as mentioned in http://lkml.org/lkml/2006/1/10/64,
with the difference that I'm not running software RAID or SATA (it's an
Areca ARC-1110).
I can't reproduce it until now, it 'just' happens. Can someone give me a
pointer where to start looking ?
Erich, I've CC-ed you since the machine is running an Areca RAID config.
It's also the only used disk subsystem in this machine.
Regards,
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.4.x deadlocking
Hi,
My collegue has a Lifetec 9888 laptop (PII) that suffers from IRQ
deadlocking :
His TI PCMCIA bridge locates itself on IRQ 12, and so does his mouse.
System boots fine, but as soon as he types anything or moves his mouse,
the keyboard locks.
2.2.x doesn't seem to allocate a IRQ to the bridge, so no problems there.
Remote access is still possible, and the system works fine excepts that
his keyboard / mouse are dead :)
Not starting GPM prevents the lock.
Is there any way to tell the PCI subsystem to leave IRQ 12 alone ? The
pci_setup() routine seems to be a pretty noop.
Regards,
Igmar Palsenberg
--
Igmar Palsenberg
JDI Media Solutions
Boulevard Heuvelink 102
6828 KT 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]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.4.5 strange behaviour
Hi, 2.4.5 keeps thinking I can change a CDROM 20 times a second or so. System : Compaq Armada 7360 DMT Relevant stuff from dmesg : Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PCI_IDE: unknown IDE controller on PCI bus 00 device 71, VID=0e11, DID=ae33 PCI: Device 00:0e.1 not available because of resource collisions PCI_IDE: chipset revision 3 PCI_IDE: not 100% native mode: will probe irqs later hda: IBM-DTCA-23240, ATA DISK drive hdb: COMPAQ CRD-S88P, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 6354432 sectors (3253 MB) w/468KiB Cache, CHS=788/128/63 hdb: ATAPI 8X CD-ROM drive, 256kB Cache Uniform CD-ROM driver Revision: 3.12 If starts spitting messages in the form of VFS: Disk change detected on device ide0(3,64) The behaviour seems to be triggered by some event, and if that happens the only way to resolve == reboot Second think is that the IrDA subsystem seems to have stopped working. I'm looking into that (irattach goes fine, detection also, but no contact with the device itself) I'm going back to 2.4.4 to see if thing go better. Igmar -- Igmar Palsenberg JDI Media Solutions Boulevard Heuvelink 102 6828 KT 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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";
}
}
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";
}
}
Re: Vanilla 2.4.0 ext2fs error
On Wed, 31 Jan 2001, bert hubert wrote: > On Wed, Jan 31, 2001 at 06:21:04PM +0100, Igmar Palsenberg wrote: > > > Jan 31 18:01:57 base kernel: EXT2-fs error (device ide0(3,71)): > > ext2_new_inode: > > reserved inode or inode > inodes count - block_group = 0,inode=1 > > does fsck run on this fs find any errors? Haven't tried, but highly unlikely.. The FS was formatted about 20 seconds before the error :) I'll give it a try. > Huge .sig! I like 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: Why isn't init PID 1?
On Wed, 31 Jan 2001, Paul Powell wrote: > Hello, > > I have a bootable linux CD that runs a custom init. > Under most versions of linux init runs as process ID > one. Under my bootable CD, it runs as process ID 15. > I need it to run as PID 1 so that I can execute a > kill(-1,15) without killing init. > > The boot CD uses and initrd image to load drivers. > The linuxrc file looks like: > > #!/bin/sash > > aliasall > > echo "Loading aic7xxx module" > insmod /lib/aic7xxx.o > echo "Loading ips module" > insmod /lib/ips.o ips=ioctlsize:512000 > echo "Loading sg module" > insmod /lib/sg.o > echo "Loading FAT modules" > insmod /lib/fat.o > insmod /lib/vfat.o > > echo "Mounting /proc" > mount -t proc /proc /proc > init > umount /proc > > Does it run as PID 15 because I execute insmod and > mount before running init? Yes. First program to run get PID 1. Solution : fork() in init and load the modules in the child. 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/
Vanilla 2.4.0 et2fs errors
Hi, Can someone 'translate' this for me ? Jan 31 18:01:57 base kernel: EXT2-fs error (device ide0(3,71)): ext2_new_inode: reserved inode or inode > inodes count - block_group = 0,inode=1 It's reproducable, but doesn't seem to give any problems. It happens when on a (almost) empty FS an links is attempted to a directory that doesn't exist at that point. I'll try 2.4.1 when I get back and see what that 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/
Vanilla 2.4.0 ext2fs error
Hi,
Can someone 'translate' this for me ?
Jan 31 18:01:57 base kernel: EXT2-fs error (device ide0(3,71)):
ext2_new_inode:
reserved inode or inode > inodes count - block_group = 0,inode=1
It's reproducable, but doesn't seem to give any problems.
It happens when on a (almost) emty FS an links is attempted to a directory
that doesn't exist at that point.
I'll try 2.4.1 when I get back and see what that does..
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: winsock 2
On Tue, 23 Jan 2001, Rajiv Majumdar wrote: > > > does winsock support raw sockets?if not, how do we implement an "ip spoof" > in winsock? This is a LINUX mailing list, now a windblows one. Please post to a windows list, not this one. > 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: 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: 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: 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: 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/
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: 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/
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
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
> 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
> > > 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
> 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/
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
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/
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/
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: 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: 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: 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: 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)
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: 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)
> > 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: 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)
> 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)
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)
> 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, 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)
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)
> 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/
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/
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/
Re: TCP keepalive seems to send to only one port
> Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x > (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO > somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I > bet it'll be hard. ipchains -S timeoutval 0 0 is the only way to do 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: kapm-idled : is this a bug?
> > Doing it this way is _way_ better for system > > stability, because kidle-apmd sometimes dies due to APM > > bug. kidle-apmd dying is recoverable error; swapper dieing is as fatal > > as it can be. > > Good. Maybe the bugs will get fixed then. If the bugs are in > the BIOS or motherboard hardware, we can have a blacklist. If the're a lot of buggy APM BIOS'es out there it may indeed not be a wise idea to throw everything on one pile. 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: kapm-idled : is this a bug?
> > Agree that it is different. But it confuses people to have two > > idle-tasks. I suggest that we throw it one big pile, unless having a > > separate apm idle task has a purpose. > > You can't do that. Doing it this way is _way_ better for system > stability, because kidle-apmd sometimes dies due to APM > bug. kidle-apmd dying is recoverable error; swapper dieing is as fatal > as it can be. Hmm.. Means two idle task then :) 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: kapm-idled : is this a bug?
> > What's the problem with using PID 0 as the idle task ? That's 'standard' > > with OS'ses that display the idle task. > > Linux has already another thread with pid 0, called "swapper" which is > in fact idle. kidle-apmd is different beast. Agree that it is different. But it confuses people to have two idle-tasks. I suggest that we throw it one big pile, unless having a separate apm idle task has a purpose. > Pavel 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 with 3c59x and 3C905B
On Mon, 18 Dec 2000 [EMAIL PROTECTED] wrote: > Andrew Morton wrote: > > > > Working out why your switch isn't talking full-duplex would > > probably make things work too, but it's not a fix. > > > > He said he has a 10/100 hub (NG DS104) -- it is a half-duplex only 10/100 > hub. 10/100 hub doesn't imply half-duplex to me. I've also got a 10/100 thingy, but it is full duplex. Bit that still doesn't explainn why the driver lies :) > Regards, > JGoins > [EMAIL PROTECTED] 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 with 3c59x and 3C905B
On Mon, 18 Dec 2000, Michael Illgner wrote: > Hi folks, > I have some trouble using a 3COM NIC905B and the 3c59x driver with kernel > 2.2.x > and 2.4.0.testx. First of all the card works fine with Windows or with linux > 2.2.18 > using the 3c90x driver supplied by 3COM. But with the 3c59x driver I get > transfer rates This kernel is a stock 2.2.17 with acl patches (doesn't change anything network-related). Bootup msg : 3c59x.c 16Aug00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905B Cyclone 100baseTx at 0x6c00, 00:10:5a:68:ea:ad, IRQ 11 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. MII transceiver found at address 0, status 786d. Enabling bus-master transmits and whole-frame receives. > below 10k/s or even lower. The card is connected to a 10/100 Hub (Netgear > DS104). You're sure that hub can handle full-fuplex mode ? Because that's what the card uses in your case. > Here are some informations > > Kernel version > > 2.2.18 SMP and 2.4.0.test12 SMP (latest kernel) but the problem seems > to be independent of the kernel version. > > > Banner message > > Dec 17 19:44:48 ganerc kernel: 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker > and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ > Dec 17 19:44:48 ganerc kernel: See Documentation/networking/vortex.txt > Dec 17 19:44:48 ganerc kernel: eth0: 3Com PCI 3c905B Cyclone 100baseTx at > 0xdc00, 00:10:5a:d8:25:f1, IRQ 19 > Dec 17 19:44:48 ganerc kernel: Full duplex capable > Dec 17 19:44:48 ganerc kernel: 8K byte-wide RAM 5:3 Rx:Tx split, > autoselect/Autonegotiate interface. > Dec 17 19:44:48 ganerc kernel: MII transceiver found at address 24, status > 786d. > Dec 17 19:44:48 ganerc kernel: MII transceiver found at address 0, status > 786d. > Dec 17 19:44:48 ganerc kernel: Enabling bus-master transmits and > whole-frame receives. > Dec 17 19:44:48 ganerc kernel: eth0: using NWAY autonegotiation Ik hate everything that has the word 'auto' in it. Usually means problems. I suggest you start at that hub. The fact that you state that is is kernel independant makes me think it's not a kernel / driver bug, but that your network chokes on the autoconfig. 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: kapm-idled : is this a bug?
> How about adding a flag to FLAGS, or a new letter in STATE in > /proc/pid/stat, to mean "this is an idle task"? > > ps & top could easily by taught to recognise the flag. What's the problem with using PID 0 as the idle task ? That's 'standard' with OS'ses that display the idle task. It's also the 'right' thing to do, and should directly work with top / ps 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: Is there a Linux trademark issue with sun?
> On Fri, Dec 15, 2000 at 12:54:21PM +0100, Igmar Palsenberg wrote: > > > > > Heads up everybody. Scott McNealy has apparently been > > > calling Solaris Sun's implementation of Linux. > > > Trademark violation time. > > > > It's probably a marketing guy that has no idea about what he is talking > > about. I've seen good Linux related stuff come from Sun and I hardly can > > imagine that such a person would make this statement. > > Ehrm. If I'm not all wrong, Scott McNealy is the CEO of Sun... Yes, someone also noted that to me. His words sound like those of some marketing guy, or some politican (for the Dutch guys : Kok :-)) 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: Is there a Linux trademark issue with sun?
> > >When asked by a reporter why Sun's new clustering > > >software was restricted to Solaris and not available > > >on Linux, McNealy's aggravation seemed to peak. "You > > >people just don't get it, do you? All Linux > > >applications run on Solaris, which is our > > >implementation of Linux. Now ask the question again," > > I wouldn't worry about this. It's only a question of time > before people will start to ask him why Sun isn't shipping > the "original Linux" but has their own, strange, version ;) hahahaha... I like that view.. Nice one for my infoline :) 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: Is there a Linux trademark issue with sun?
> Heads up everybody. Scott McNealy has apparently been > calling Solaris Sun's implementation of Linux. > Trademark violation time. It's probably a marketing guy that has no idea about what he is talking about. I've seen good Linux related stuff come from Sun and I hardly can imagine that such a person would make this statement. 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: Dropping chars on 16550
> Yeah. most of this crap is manufactured as all-in-1 chips. (IDE, FDC, SER, > PAR, etc.) and right along with that, you get 2 16550AFN's. Now. they > hyped the heck out of 16550's when they came out, because "You can use > your 28.8kbps modem without overruns!". Yeah. clocking it at 38400 or > 57600 on a system doing NOTHING ELSE BUT SERIAL. > > For a little extra cost - approx. $2.50 (this number could skew a bit, > depending on in what quantity they buy), they could put 16652's in there. In that case you're talking a few dollars on a motherboard that costs at least $100 to produce. I've seen this with all hardware I've seen : The famous HP scanner series come with some kind of totally shitty SCSI card just to save $15 or so. > Not much support for it on an enduser system yet (our serial.c does, but > the MS folks dont support 'em in their generic driver, I dont think) so I > think this has some weight in why it doesn't become defacto standard, > either. > > > Well.. Why is the i386 the defacto standard ? There architectures that are > > a lot better. Reason it is that the some big company used it, and it got > > populair. > > Heh. Well, serial doesn't even have anything to do with architecture. As > long as the machine supports addressable I/O, its capable of running a > UART. I know. I just named the Intel as an example. The Alpha architecture is on most things superiours to the Intel, en the current PIII arcitecture still has the some bloat of the old archtecture carried along, thing that comes in mind is the old 80x86 compability mode. My point was that getting rid of something that most users have is very hard, even if the're better things on the market. > And what kind of serial ports do you find on your Alpha? 16550's! Your > PowerPC? 16550's! Your PA-RISC box? 16550's! Hey! Even RS/6000's use > 16550's! I want an Alpha.. That's my gift I give to myself after I graduate ;) > So while i concur with your statement, it still doesn't explain why the > business hasn't chosen to move on yet. > NOTE: The same can also be stated about FLOPPY DRIVES. Why on EARTH would > we want 1.44mb media - on a drive that costs $15, and media that costs > $.10/ea - when there are things like Zipdrives, where you can get > 100mb internal drives for $50, and media for $4? (Thats what FLOPPY DRIVES > used to cost!! $60 for the drive, $1-2/ea for the media.) 1.44 MB is anchient, and hardlike suitable for anything else then a recue disk. Problem that when the 3.5 inch disk was introduced it was the only thing that was cheap and available on the market. So it became a standard, and it is still widely used. Today an LS drive can keep 120 MB, that is a lot better, especially if you realize what the avarage diskstorage is today. > > Indeed.. Why do they save $15 bucks on a modem chipset, and replace it > > with a buggy software driven solution... Making things as cheap as > > possible, to make sure the're chaper then their compatitor. > > Good point. But in this particular model, it obviously explains why > electronics technology expands in the particular way that it does. > > In the year 1970, everyone thought that we'd have transporter beams and > spaceships and computers named Hal in the year 2000. What do we *REALLY* > have? Technology that makes things more CONVENIENT for people. They also > CATER to people who don't want to spend any money. > > Celphones. Pagers. Microwaves. > > Hey. we even have Web-based grocery delivery guys that > arrive in pretty vans. and all you had to do was click! > > Our computers use parts that were designed 10 years previous, because > nobody wants to spend the money on newer and better stuff. Indeed.. People want to pay $.10 to sit on the first row in the theatre. I choose to pay for good hardware that I buy, plug in and it works. Nog plug in, install 20 megs of software, and then the bloody thing still refuses to work :( > Chad 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: Is this a compromise and how?
> Pretty cool huh? > > Let me know if you would like a copy of the code. > > A quick strace shows that it binds to port 24000. > > It also contains a list of 5 IP addrs. I suspect it doesn't > broadcast, but allows people in from those IPs. > > Anyone know what has happened? I religiously install the redhat > updates, and am subscribed to the CERT advistors and install > the fixes the moment I get them. > > The system was RedHat 6.2, linux 2.2.17pre14 at the time the > breakin occured. > > I've been running firewalled with only services I provide turned > on for access, and in /etc/inetd.conf. > > What is keeping strlib.h from appearing ls's? A hacked ls command? Yep. Looks like a rootkit to me. 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: Dropping chars on 16550
> there are many situations in which a 16550 is KNOWN to be overrunable, all > of which can occur in your common PPP connection. > > More importantly - if you have 2 16550's talking together (Which is > EXACTLY what you have, when you hook it to a modem) there are even MORE > overrun possibilities. (For instance, when you fill the transmitter up to > 16 bytes - on a uart, and then the receiving side suddenly drops RTS, > there is *NO* way for that 16550 to stop its transmitter. Once the bytes > are in its fifo, it HAS TO SEND THEM.) Indeed. I saw this behaviour some years ago when I was debugging a controller that went beserk when been talked to at a 115k2 buad rate. My modem isn't on 115k2 now, so I don't see the problem often. I'm gonne setup a second machine with remote kernel debugging, since I'm sick of rebooting when I want to scan something. > This is where a 654 or an 854 (I'm only listing startech design chips. > there are others that would do the job.) come in handy. They can pause > their transmitter WITH bytes in their fifo. (Automated hardware/software > flow control.) Indeed. Most chips I've seen are 1 16550, or pretend to be. Probably an issue of cost (At least, I think :)) > I have no idea why the 16550 caught on as the "De facto standard" like it > did. there are UARTS out there that are more efficient, yet cost only a > few dollars more to manufacture. Well.. Why is the i386 the defacto standard ? There architectures that are a lot better. Reason it is that the some big company used it, and it got populair. > (Your common QUAD 16654 chip costs $20 to an end user, nowadays. Your > common QUAD 16554 costs about $15.) > > Imagine what the 2-UART chips would cost. (or, mass-produced all-in-1 > sets even.) > > Really makes you think. Indeed.. Why do they save $15 bucks on a modem chipset, and replace it with a buggy software driven solution... Making things as cheap as possible, to make sure the're chaper then their compatitor. > Chad 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 release notes
> - metrics -- L1 cacheline size is the important one: you align array > elements to this size when you want a per-cpu array, so that multiple > CPUs do not share a cacheline for accessing their "own" structure. > Proper alignment avoids "cacheline ping-pong", as it's called, > whenever two CPUs need to access "their" element of the same array at > the same time. Anyone can give me some pointers on how this is done runtime ? (name of the .c file is fine). I'm still looking at the basic stuff, but haven't bumped into this one yet... 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: Dropping chars on 16550
> > Use handshaking > > Heh...do what I did. Go on eBay and pick up a Hayes ESP card. Hmm.. High speed comm is fine here, as long is I use handshaking. If I don't, I'll loose chars. > I have a fairly weak system by todays standards, and I found that > even with a 16550 serial port, I'd get tcp/ip errors in my logs > (and lots of 'em). Mine used to be a 200MMX until last week :) > -- > Mark Orr > [EMAIL PROTECTED] 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: Dropping chars on 16550
On Sun, 10 Dec 2000 [EMAIL PROTECTED] wrote: > Hi folks > > What should I do, when I run cdda2wav | gogo (riping CD from a ATAPI > CD thru mp3 encoder) and get a continuous dropping of characters, on a 16550- > enhanced serial port, without handshake, with full-duplex load of 115200 bps? > About 1 of 320 bytes is miscommunicated. Use handshaking 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: /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)
> > 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)
> > 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)
> "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)
> 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)
> 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: 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: 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: 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: 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..."
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: 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: 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/
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: 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/
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: 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: 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: sound problems caused by masking irq for too long
On Sun, 12 Nov 2000, Alexander V. Lukyanov wrote: > Hi! > > In some cases sound gets interrupted for a moment, this happens in two > occasions. When unmaskirq flag is off on ide cdrom and it is accessed, > and when tdfxfb console (800x600) flashes (tput flash, or `set bell-style > visible' in .inputrc). > > It seems the problem is caused by masking irq for too long, and then > the sound dma buffer underruns. This is fixed by unmasking irq for ide > cdrom by `hdparm -u1 /dev/cdrom', and by changing spin_(un)lock_irq > in console.c to spin_(un)lock_bh. > > This was observed on 2.4.0-pre10, the problem with ide also exists on > 2.2.17, the console.c in 2.2.17 only disables CONSOLE_BH. The above story also explains why my sound 'hickups' when I switch from console to X (yes, and I do that a lot). Is this a recent change from 2.2.15 -> >= 2.2.16 or so ? > The audio card is old awe32 (isa), sound driver is modular. This is a SB16 PnP 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.17 wont compile on AMD k6@-550
On Fri, 10 Nov 2000, root wrote: > Hello kernel hackers, > > I am having problems with compiling a kernel on an AMD K62-550. > I am running Red Hat 6.2, and am getting error messages like this: > > cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 > -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce > -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c > -o tcp_output.o tcp_output.c > cc: Internal compiler error: program cc1 got fatal signal 11 SIG11 is almost always a hardware problem. Read the SIG11-HOWTO (is that called that way ?) > Kind Regards > Timothy A. DeWees 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]
> > > Turn on encryption, and try sending attachements > 1MB and tell me if > > > you see any problems, like emails sitting in /var/spool/mqueue for a day > > > or two until they go out. I can guarantee you will. > > > > Are you talking client -> MTA encryption, or MTA -> MTA encryption ?? > > slow or blocked connection problems with all configs listed above. Ah. I'll go kick this sendmail setup, and see what it does.. > 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]
> > It ran out of memory. The file got sent fine after I got rid of > > all the memory-consumers. Looks like a sendmail bug where they > > expect to load a whole file into memory all at once before sending > > it. I always thought you could read from a file, then write to > > a socket. Maybe I'm old fashioned. Sending a 50 MB file is OK here. So it's not a TCP/IP bug. > Claus, > > Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and > OpenLinux all exhibit this behavior, which means they're all broken. > Reading an entire file into memory must be a BSD feature. I have > enabled an SSH account for you, so you can come in and debug. Richard > also can get in and will be helping. > > 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: [Fwd: sendmail fails to deliver mail with attachments in/var/spool/mqueue]
On Fri, 10 Nov 2000, [iso-8859-1] willy tarreau wrote: > Dick, have you tried a simple "strace -f -p " ? > This often gives enough info. > > BTW, there's one version of sendmail that tests the > capability security hole of a previous kernel version > (2.2.15 ?), and refuses to launch if it discovers it. > It may be possible that sendmail does other tests like > this one. All recent version of sendmail check the kernel if it has the famous 'I don't drop my root privs entirely' bug. This bug isn't the issue, sendmail complains loudly when it finds a kernel with that bug, and won't even start. I'm testing with a 50 MB file now.. See how it goes :) > Regards, > Willy 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]
> Turn on encryption, and try sending attachements > 1MB and tell me if > you see any problems, like emails sitting in /var/spool/mqueue for a day > or two until they go out. I can guarantee you will. Are you talking client -> MTA encryption, or MTA -> MTA encryption ?? > 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: [Fwd: sendmail fails to deliver mail with attachments in/var/spool/mqueue]
> > Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses > > encryption. > > I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over > the place, many of them so old it is scary. No problems seen at this end. > This is to be expected, BTW: They can't just go in and release an MTA which > doesn't talk to the rest ot the world, now can they. The only things sendmails < 8.10.x all suffer from is the crappy mapper code. This causes all kinds of weard problems (logging not complete, undelivered mail), especially if an external problem mucks around with the mapper files (those .db things for example). I had no problems with 8.11.x not talking to qmail or any other MTA. 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]
> > What about sendmail 8.11.1? Is the problem there too? > > Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses > encryption. Depends on how you configure it. An enabled encryption doesn't always mean it has problems taking to other sendmails. This sendmail here has no problems forwarding a mail > 400 Kb (I used 1.2 MB). This is 8.11.1 with the MySQL mapper patch. > > > ANyone have any ideas if what the sendmail people are saying is on the > > > level, or is this just another sendmail bug. I can't reproduce on 8.11.1 Maybe I can if someones tells me the exact procedure to reproduce it. > > > > > > Jeff > > > > wfms 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: malloc(1/0) ??
> Where the heck did you get idea? By reading the man page in the middle of the night and reading realloc() as malloc(). My error. > -hpa 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/
