Re: EXT2-fs error and geometry walk ... ???
Erm. What version it was? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
On Mon, Sep 18, 2000 at 01:44:04PM +0200, Alan Cox wrote: > > On Mon, Sep 18, 2000 at 12:34:03PM +0200, Alan Cox wrote: > > > > The problem is really that SI_SIGIO is negative, but it should be positive > > > > to make SI_FROMUSER return false on it. > > > > > > > > Changing it would unfortunately break binary compatibility. This patch > > > > > > Why ? > > > > If a program checks info->si_code for incoming signals. > > ok now what does the value the kernel passes have to do with the value we > write on the user stack - at the moment we blindly copy but we could just > use a tiny lookup table to 'dekernelize' the ID. In fact if you picked a bitflag > you could just mask it That would not help much, the user could just still set the non mapped value in sigqueueinfo() [which would need to be forbidden to avoid users faking kernel signals, which my patch exactly does] -Andi -- This is like TV. I don't like TV. - 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: weird PCI problems...
On Mon, 18 Sep 2000, Tigran Aivazian wrote:
> But one needs to understand your fix first. Shouldn't that
> !is_cardbus be is_cardbus instead?
Yes, doing it like this works:
--- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000
+++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000
@@ -714,7 +714,7 @@
* We need to blast all three values with a single write.
*/
pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
- if (!is_cardbus) {
+ if (is_cardbus) {
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
Martin, is this totally wrong? I.e. will it break the case of multiple
peer PCI buses? Note that with the above I see absolutely all my devices,
like this:
# lspci -tv
-+-[03]---00.0 3Com Corporation: Unknown device 5257
\-[00]-+-00.0 Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
+-01.0-[01]00.0 ATI Technologies Inc 3D Rage P/M Mobility AGP
2x
+-03.0 Texas Instruments PCI1225
+-03.1 Texas Instruments PCI1225
+-07.0 Intel Corporation 82371AB PIIX4 ISA
+-07.1 Intel Corporation 82371AB PIIX4 IDE
+-07.2 Intel Corporation 82371AB PIIX4 USB
+-07.3 Intel Corporation 82371AB PIIX4 ACPI
+-08.0 ESS Technology ES1978 Maestro 2E
\-11.0-[02]--+-01.0 Realtek Semiconductor Co., Ltd. RTL-8139
+-02.0 Intel Corporation 82557 [Ethernet Pro 100]
+-05.0 CMD Technology Inc PCI0646
+-07.0 Adaptec AIC-7880U
\-08.0 3Com Corporation 3c905C-TX [Fast Etherlink]
Regards,
Tigran
-
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: weird PCI problems...
Hi Andrew, On Mon, 18 Sep 2000, Andrew Morton wrote: > Because Cardbus on this recent Dell laptop has > suddenly stopped working: yes, looks like we do have similar Dell laptops ;) > I don't see where we _ever_ scan behind a Cardbus bridge??? > > As a datapoint, this hack makes Cardbus work again: indeed it does! I now have all my 4 NICs working on this laptop again, thank you. But one needs to understand your fix first. Shouldn't that !is_cardbus be is_cardbus instead? I attached my latest boot.log below. Regards, Tigran Linux version 2.4.0-test9 (root@penguin) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #3 Mon Sep 18 12:43:19 BST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 07ef @ 0010 (usable) BIOS-e820: 0001 @ 07ff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 32752 zone(0): 4096 pages. zone(1): 28656 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=240test9 ro root=302 Initializing CPU#0 Detected 448626242 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 894.57 BogoMIPS Memory: 126676k/131008k available (1304k kernel code, 3944k reserved, 91k data, 172k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Intel Pentium III (Coppermine) stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router default [8086/1234] at 00:07.0 Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) P6 Microcode Update Driver v1.07 Starting kswapd v1.8 pty: 256 Unix98 ptys configured Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x0860-0x0867, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x0868-0x086f, BIOS settings: hdc:DMA, hdd:pio CMD646: IDE controller on PCI bus 02 dev 28 CMD646: chipset revision 7 CMD646: chipset revision 0x07, UltraDMA Capable CMD646: 100% native mode on irq 10 ide2: BM-DMA at 0xf880-0xf887, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xf888-0xf88f, BIOS settings: hdg:pio, hdh:pio hda: IBM-DARA-206000, ATA DISK drive hdc: SAMSUNG CD-ROM SN-124, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 11733120 sectors (6007 MB) w/418KiB Cache, CHS=730/255/63, UDMA(33) hdc: ATAPI 24X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.11 Partition check: hda: hda1 hda2 hda3 hda4 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Real Time Clock Driver v1.10c 3c59x.c:LK1.1.9 2 Sep 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.38 $ See Documentation/networking/vortex.txt eth0: 3Com PCI 3c905C Tornado at 0xf800, 00:b0:d0:2e:b7:34, IRQ 10 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.33 $ 2000/05/24 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others eth1: Intel Corporation 82557 [Ethernet Pro 100], 00:D0:B7:23:B4:B8, IRQ 10. Receiver lock-up bug exists -- enabling work-around. Board assembly 721383-008, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). 8139too Fast Ethernet driver 0.9.10 loaded eth2: RealTek RTL8139 Fast Ethernet at 0xc8802c00, 00:a0:d2:11:b6:5d, IRQ 10 eth2: Identified 8139 chip type 'RTL-8139A' maestro: version 0.14 time 12:44:28 Sep 18 200
Re: Linux 2.2.18pre9
[EMAIL PROTECTED] (Alan Cox) writes: >Resynchronize the USB stuff and starting bringing the ARM into line >2.2.18pre9 [...] >o NFSv3 support and NFS updates (Trond Myklebust and co) Biggest understatement this side of Linux 2.4. :-) Cool. Will test. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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/
EXT2-fs error and geometry walk ... ???
Please not that all of this is the same boot. Disregard the weird device major:minor Sep 18 04:22:20 cascade kernel: EXT2-fs error (device ide2(33,1)): ext2_readdir: bad entry in directory #2: rec_len % 4 != 0 - offset=0, inode=2, rec_len=14, name_len=1 Sep 18 04:22:20 cascade kernel: EXT2-fs error (device ide2(33,17)): ext2_readdir: bad entry in directory #2: rec_len % 4 != 0 - offset=0, inode=2, rec_len=14, name_len=1 Sep 18 04:22:20 cascade kernel: EXT2-fs error (device ide2(33,33)): ext2_readdir: bad entry in directory #2: rec_len % 4 != 0 - offset=0, inode=2, rec_len=14, name_len=1 Sep 18 04:22:20 cascade kernel: EXT2-fs error (device ide2(33,49)): ext2_readdir: bad entry in directory #2: rec_len % 4 != 0 - offset=0, inode=2, rec_len=14, name_len=1 This did not happen in the past. cat /proc/partitions 33 0 15087744 ide/host2/bus0/target0/lun0/disc 33 1 15085003 ide/host2/bus0/target0/lun0/part1 33167543872 ide/host2/bus0/target1/lun0/disc 33177542486 ide/host2/bus0/target1/lun0/part1 33327543872 ide/host2/bus0/target2/lun0/disc 33337542486 ide/host2/bus0/target2/lun0/part1 3348 15087744 ide/host2/bus0/target3/lun0/disc 3349 15085003 ide/host2/bus0/target3/lun0/part1 cat /proc/ide/hde*/geometry physical 29936/16/63 logical 1878/255/63 physical 14968/16/63 logical 939/255/63 physical 14968/16/63 logical 939/255/63 physical 29936/16/63 logical 1878/255/63 I need to know what is going on in ext2 that now makes this error. What is causing the geometry walk? Disk /dev/hdea: 255 heads, 63 sectors, 1878 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /dev/hdea1 9 1895 15150539+ 83 Linux Disk /dev/hdeb: 255 heads, 63 sectors, 939 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /dev/hdeb1 9 948 7542486 83 Linux Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 1, 3) logical=(8, 41, 33) Partition 1 has different physical/logical endings: phys=(938, 254, 63) logical=(947, 40, 32) Disk /dev/hdec: 255 heads, 63 sectors, 939 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /dev/hdec1 9 948 7542486 83 Linux Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 1, 3) logical=(8, 41, 33) Partition 1 has different physical/logical endings: phys=(938, 254, 63) logical=(947, 40, 32) Disk /dev/hded: 255 heads, 63 sectors, 1878 cylinders Units = cylinders of 16065 * 512 bytes Device BootStart EndBlocks Id System /dev/hded1 9 1895 15150539+ 83 Linux Sep 18 04:36:21 cascade kernel: /dev/ide/host2/bus0/target3/lun0: p1 p2 p3 p4 Sep 18 04:37:04 cascade kernel: /dev/ide/host2/bus0/target2/lun0: p1 p2 p3 p4 Sep 18 04:37:06 cascade kernel: /dev/ide/host2/bus0/target2/lun0: p1 p2 p3 p4 Sep 18 04:37:22 cascade kernel: /dev/ide/host2/bus0/target1/lun0: p1 p2 p3 p4 Sep 18 04:41:19 cascade kernel: /dev/ide/host2/bus0/target0/lun0: p1 p2 p3 p4 Expert command (m for help): p Disk /dev/hdea: 255 heads, 63 sectors, 1878 cylinders Nr AF Hd Sec Cyl Hd Sec CylStart Size ID 1 00 0 00 0 0000 00 2 00 0 20 0 20 131072 131072 00 3 00 0 20 0 20 131072 131072 00 4 00 0 20 0 20 131072 131072 00 out of expert mode and delete all 4 bogus partitions. back in expert mode Expert command (m for help): p Disk /dev/hdea: 255 heads, 63 sectors, 1878 cylinders Nr AF Hd Sec Cyl Hd Sec CylStart Size ID 1 00 0 00 0 0000 00 2 00 0 00 0 0000 00 3 00 0 00 0 0000 00 4 00 0 00 0 0000 00 cat /proc/partitions 33 0 15087744 ide/host2/bus0/target0/lun0/disc 33 1 65536 ide/host2/bus0/target0/lun0/part1 33 2 65536 ide/host2/bus0/target0/lun0/part2 33 3 65536 ide/host2/bus0/target0/lun0/part3 33 4 65536 ide/host2/bus0/target0/lun0/part4 33167543872 ide/host2/bus0/target1/lun0/disc 3317 65536 ide/host2/bus0/target1/lun0/part1 3318 65536 ide/host2/bus0/target1/lun0/part2 3319 65536 ide/host2/bus0/target1/lun0/part3 3320 65536 ide/host2/bus0/target1/lun0/part4 33327543872 ide/host2/bus0/target2/lun0/disc 3333 65536 ide/host2/bus0/target2/lun0/part1 3334 65536 ide/host2/bus0/target2/lun0/part2 3335 65536 ide/host2/bus0/target2/lun0/part3 3336 65536 ide/host2/bus0/target2/lun0/part4 3348 15087744 ide/host2/bus0/target3/lun0/disc 3349 65536 ide/host2/bus0/target3/lun0/p
Re: Q: sock output serialization
[EMAIL PROTECTED] said: > I think its fixable to make it do the RR/RNR after bouncing it up the > stack. - ARCnet does ACK in hardware. Packets don't hit the wire until the destination has indicated that it's got a buffer available. You really want to be able to reserve space on the queue before telling the chip to accept another incoming packet - not just realise afterwards that you've screwed up. Strictly speaking, this fact is irrelevant to the case in question, but if we're modifying the generic code for LAPB, we might as well think about other protocols which require similar treatment. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
> On Mon, Sep 18, 2000 at 12:34:03PM +0200, Alan Cox wrote: > > > The problem is really that SI_SIGIO is negative, but it should be positive > > > to make SI_FROMUSER return false on it. > > > > > > Changing it would unfortunately break binary compatibility. This patch > > > > Why ? > > If a program checks info->si_code for incoming signals. ok now what does the value the kernel passes have to do with the value we write on the user stack - at the moment we blindly copy but we could just use a tiny lookup table to 'dekernelize' the ID. In fact if you picked a bitflag you could just mask it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
On Mon, Sep 18, 2000 at 12:34:03PM +0200, Alan Cox wrote: > > The problem is really that SI_SIGIO is negative, but it should be positive > > to make SI_FROMUSER return false on it. > > > > Changing it would unfortunately break binary compatibility. This patch > > Why ? If a program checks info->si_code for incoming signals. -Andi -- This is like TV. I don't like TV. - 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/
Ptrace broken since 2.4.0-test8pre4?...
Hi! Beeing an active user mode linux user :-) I can say that since 2.4.0-test8 (host kernel) I cannot run uml-linux successfully. In contrast with popular feeling that "threaded programes screwed signal handling on test8.", it is actually a small change to arch/i386/ptrace.c introduced since test8pre4. Also, I remember complains from Andi Kleen noticed that new kernels break ups (an alternative debugger). See the following postings - http://kernelnotes.org/lnxlists/linux-kernel/lk_0009_01/msg00265.html http://kernelnotes.org/lnxlists/linux-kernel/lk_0009_01/msg00283.html resulted in this change - --- v2.4.0-test7/linux/arch/i386/kernel/ptrace.c Fri Jun 23 21:55:07 2000 +++ linux/arch/i386/kernel/ptrace.c Sat Sep 2 12:00:02 2000 @@ -99,6 +99,11 @@ case EFL: value &= FLAG_MASK; value |= get_stack_long(child, EFL_OFFSET) & ~FLAG_MASK; + break; + case EIP: + /* Mark us as not being in a system call, so that no restart +issues happen */ + put_stack_long(child, 4*ORIG_EAX - sizeof(struct pt_regs), -1); + break; } if (regno > GS*4) regno -= 2*4; While I cannot comment on the above change from technical point of view, it seems the patch breaks more then it cures. Time to consider reversing? Regards, Yuri Pudgorodsky - 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: weird PCI problems...
Tigran Aivazian wrote:
>
> Hi Martin,
>
> I just found out that my earlier statement "2.2.x is okay" should be
> changed to "win98 is okay" so there are definitely problems with sharing
> PCI irqs between eepro100/3c59x/(rtl)8139(too) in both 2.2.x and 2.4.x. I
> utterly don't care about 2.2.x but I am in the mood to find out what's
> wrong with 2.4.x.
>
Perhaps that patch was applied in test9-pre2?
Because Cardbus on this recent Dell laptop has
suddenly stopped working:
Sep 11 22:52:52 dell kernel: Yenta IRQ list 0498, PCI irq11
Sep 11 22:52:52 dell kernel: Socket status: 3006
Sep 11 22:52:52 dell kernel: cs: cb_alloc(bus 2): vendor 0x10b7, device 0x
Sep 11 22:52:52 dell kernel: PCI: Failed to allocate resource 3 for PCI device
10b7:
Sep 11 22:52:52 dell kernel: PCI: Failed to allocate resource 4 for PCI device
10b7:
Sep 11 22:52:52 dell kernel: PCI: Failed to allocate resource 5 for PCI device
10b7:
Sep 11 22:52:52 dell kernel: PCI: Enabling device 02:00.0 ( -> 0003)
I don't see where we _ever_ scan behind a Cardbus bridge???
As a datapoint, this hack makes Cardbus work again:
--- linux-2.4.0-test9-pre2/drivers/pci/pci.cMon Sep 18 20:31:49 2000
+++ linux-akpm/drivers/pci/pci.cMon Sep 18 22:17:39 2000
@@ -714,7 +714,7 @@
* We need to blast all three values with a single write.
*/
pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
- if (!is_cardbus) {
+ if (1 || !is_cardbus) {
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
-
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/
bzImage Problem (?)
Hi! I just got the 2.4.0-test8 (test9 did the same), set it up, compiled it (same procedure as I always do when I'm installing a new kernel): make menuconfig make dep clean zlilo modules modules_install Okay, 2.4.0-testX said it was too big, so I tried bzImage instead of zlilo and did a cp arch/i386/boot/bzImage /vmlinuz && lilo (PS: I even tried with make install instead of make bzImage, cp, lilo) but everything I got was "Uncompressing the kernel... Ok, now booting Linux" (don't know if it's the exact message, but it's the second line while booting, so I think, you know what I mean) and after this line, the system is laying around and doing nothing. My configuration: Siemens Primergy 4-way (4x PPro 200), Kernel optimized for 6x86 which did with 2.3.9 256 MB of SDRAM, Adaptec 2940U(W?) (included aic7xxx-driver static), Mylex DAC960PD (compiled as module, because the aic has the boot disk), but will be disabled till I get a firmware-upgrade. Intel EtherExpress (included eepro100 static) When I compiled the 2.3.9, everything worked okay (but it has no Mylex support). My .config: # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_M686FXSR is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=32 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set CONFIG_BLK_DEV_DAC960=m # CONFIG_BLK_DEV_LOOP is not set CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_LVM is not set CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Networking options # # CONFIG_PACKET is not set CONFIG_NETLINK=y # CONFIG_RTNETLINK is not set # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=m CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # # CONFIG_IDE is not set # CONFIG_BLK_DEV_IDE_MODES is not set # CONFIG_BLK_DEV_HD is not set # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=m CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 # CONFIG_CHR_DEV_SG is not set CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W__RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 # CONFIG_AIC7XXX_PROC_STATS is not set CONFIG_AIC7XXX_RESET_DELAY=5 # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is
Re: test9-pre2 fails to compile with ipv6 enabled
I've fixed this and sent a patch to Linus. Later, David S. Miller [EMAIL PROTECTED] - 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/
weird PCI problems...
Hi Martin, I just found out that my earlier statement "2.2.x is okay" should be changed to "win98 is okay" so there are definitely problems with sharing PCI irqs between eepro100/3c59x/(rtl)8139(too) in both 2.2.x and 2.4.x. I utterly don't care about 2.2.x but I am in the mood to find out what's wrong with 2.4.x. If you have already fixed it all and I would be rediscovering the wheel, please let me know. Otherwise, I will (very very slowly!) get to the bottom of all this... This may be driver-related or may be generally PCI-resource-related - I don't know yet. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
> The problem is really that SI_SIGIO is negative, but it should be positive > to make SI_FROMUSER return false on it. > > Changing it would unfortunately break binary compatibility. This patch Why ? > It'll break programs that try to send SI_SIGIO (=-5) signals from userspace, > but I think that is ok. Why not just add SI_KERNSIGINFO .. and use that ? - 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/
Problems with bzImage (?)
Hi! I just got the 2.4.0-test8 (test9 did the same), set it up, compiled it (same procedure as I always do when I'm installing a new kernel): make menuconfig make dep clean zlilo modules modules_install Okay, 2.4.0-testX said it was too big, so I tried bzImage instead of zlilo and did a cp arch/i386/boot/bzImage /vmlinuz && lilo but everything I got was "Uncompressing the kernel... Ok, now booting Linux" (don't know if it's the exact message, but it's the second line while booting, so I think, you know what I mean) and after this line, the system is laying around and doing nothing. My configuration: Siemens Primergy 4-way (4x PPro 200), Kernel optimized for 6x86 which did with 2.3.9 256 MB of SDRAM, Adaptec 2940U(W?) (included aic7xxx-driver static), Mylex DAC960PD (compiled as module, because the aic has the boot disk), but will be disabled till I get a firmware-upgrade. Intel EtherExpress (included eepro100 static) When I compiled the 2.3.9, everything worked okay (but it has no Mylex support). My .config: # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_M686FXSR is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=32 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set CONFIG_BLK_DEV_DAC960=m # CONFIG_BLK_DEV_LOOP is not set CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_LVM is not set CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Networking options # # CONFIG_PACKET is not set CONFIG_NETLINK=y # CONFIG_RTNETLINK is not set # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=m CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # # CONFIG_IDE is not set # CONFIG_BLK_DEV_IDE_MODES is not set # CONFIG_BLK_DEV_HD is not set # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=m CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 # CONFIG_CHR_DEV_SG is not set CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W__RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 # CONFIG_AIC7XXX_PROC_STATS is not set CONFIG_AIC7XXX_RESET_DELAY=5 # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not
Re: Availability of kdb
Marty Fouts writes: > Here's another piece of free advice, worth less than you paid for it: in 25 > years, only the computer history trivia geeks are going to remember you, > just as only a very small handful of us now remember who wrote OS/360. You mean like Fred Brooks who managed the development of OS/360, had some innovative ideas about how large software projects should be run, whose ideas clashed with contemporary ones, who became a celebrity? You don't spot any parallels there? He whose book "Mythical Man Month" with "No Silver Bullet" and "The Second System Effect" are quoted around the industry decades later? And you think that's only a small handful of people? --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Unix Systems Programmer Oxford University Computing Services - 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: New topic (PowerPC Linux PCI HELL)
> All I wanted was a function that allows the driver to decide that which
> needs to be enabled.
>
> pci_enable_device(struct pci_dev *dev, byte enable_mask)
>
> This would allow drivers to enable that which it needs and not weird out
> the hardware that does not like all of this extra fluff.
Sounds not too daft
static inline int pci_enable_device(struct pci_device *dev)
{
return pci_enable_device_features(USE_IO|USE_MM);
}
and then just go and turn the existing enable_device into enable_device_Features ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix queued SIGIO
Linus, please think this over before applying Andi's patch. Andi Kleen wrote: > The problem is really that SI_SIGIO is negative, but it should be positive > to make SI_FROMUSER return false on it. This is an old problem. There was a thread on this topic last March. Look for "accept() improvements for rt signals". SI_SIGIO is not the only signal that's broken: SI_ASYNCIO, SI_TIMER and SI_MESGQ have the same problem. When those signals are used you'll be adding more and more exceptions to the SI_FROMUSER macro. (For example the POSIX timers patch actually does exactly the same as Andi's patch, but for SI_TIMER instead of SI_SIGIO). It's obvious that SI_SIGIO, SI_ASYNCIO, SI_TIMER and SI_MESGQ should all return false from SI_FROMUSER, assuming SI_FROMUSER is the right thing to use in any case. > Changing it would unfortunately break binary compatibility. This patch > instead changes the definition of SI_FROMUSER/KERNEL to check explicitely > for SI_SIGIO and make it appear like a kernel generated signal type. This > prevents send_sig_info from looking at current . That looks like major band-aid. What does SI_FROMUSER mean anyway? I looked it up on the web. It doesn't appear in manual pages on the web in general, and I didn't find it in Single Unix. Let's investigate. /* * si_code values * Digital reserves positive values for kernel-generated signals. */ Hmm... Inherited from Digital Unix perhaps? Let's try Digital UNIX V4.0F... /usr/include/sys/siginfo.h: /* negative si_codes are reserved for user-generated signals */ #define SI_QUEUE-1 /* sent by sigqueue */ #define SI_USER 0 /* sent by kill, sigsend, raise, etc. */ #define SI_NOINFO 1 /* unknown source */ #define SI_TIMER0x10/* sent by timer expiration */ #define SI_ASYNCIO 0x20/* sent by AIO completion */ #define SI_MESGQ0x40/* sent by realtime mesq state transition */ #define SI_FROMUSER(siptr) ((siptr)->si_code <= 0) #define SI_FROMKERNEL(siptr)((siptr)->si_code > 0) Looks like DEC got this right, Linux blindly copied some of the definitions and made up some of the others (by setting SI_TIMER etc. to negative values but keeping the same definition of SI_FROMUSER). _Something_ of binary compatibility will have to be broken to fix this problem. Either change the SI_TIMER etc. signal numbers, or change the SI_FROMUSER macro. Both of can potentially break applications. Changing SI_SIGINFO would obviously be the most serious. I'd posit that changing SI_FROMUSER is the right fix. But changed to include SI_TIMER, SI_MESGQ and SI_ASYNCIO as well. Andi says: > It'll break programs that try to send SI_SIGIO (=-5) signals from userspace, > but I think that is ok. Actually rt_sigqueueinfo has this test hard-coded in it: if (info.si_code >= 0) return -EPERM; with a comment "not even root is allowed to send signals from the kernel". Changing SI_FROMUSER won't affect this. Perhaps it should. Do we consider SI_SIGIO, SI_TIMER etc. to be in the "not even root is allowed" category or not? have a nice day, -- Jamie - 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: New topic (PowerPC Linux PCI HELL)
On Mon, 18 Sep 2000, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > Andre Hedrick wrote:
> > >All I wanted was a function that allows the driver to decide that which
> > >needs to be enabled.
> > >
> > >pci_enable_device(struct pci_dev *dev, byte enable_mask)
>
> > This is indeed interesting.
> >
> > Some devices, for example, will provide several apertures (can eat much
> > bus space) while only one of them is actually needed by the driver.
> > Having the driver be able to only enable (and possibly claim) one of them
> > would free up some bus space for other devices (I'm thinking here about
> > hot swap devices that will dynamically claim bus space, like cardbus).
>
> Perhaps I was mistaken, but I was thinking about enable_mask only
> applied to PCI_COMMAND_{IO,MEM}. If that is the case, it sounds like
> your needs would only be met if one set of apertures was driven via
> ISA-style port I/O, and the other set of apertures via PCI shared mem
> (MMIO).
Then change it to :
pci_enable_device(struct pci_dev *dev, struct pci_enable *enable_set)
typedef union {
unsigned all: 8;
struct {
unsigned bar0 : 1;
unsigned bar1 : 1;
unsigned bar2 : 1;
unsigned bar3 : 1;
unsigned bar4 : 1;
unsigned bar5 : 1;
unsigned reserved : 2;
} bar;
} pci_t;
struct pci_enable {
pci_t io_bars;
pci_t mem_bars;
...
pci_t wtf_bars;
...
unsigned long reg[6];
...
(pick and add whatever gets the job done)
};
I am not picky, just want it simple so that It can be tabled out by device
classes.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
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: partions on floppy
Adam writes: > (why I try to do this? I'm trying empirically verify if 'mkswap' will > check for partion type (ie is this '82') before mkswap-ing it. IMHO, it > shouldl ) No it doesn't, and how can it? There are lots of partitioning formats out there, so making "mkswap" read the PC BIOS partition sector to verify that it was a Linux swap partition would be brain dead, especially as you'd have to bloat mkswap with lots of extra code to go around reading all these different partition table formats. Note that floppy disks don't have partitions, and therefore if you create a partition on a floppy disk, Linux will ignore it. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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: Terrible elevator performance in Linux 2.4.0-test8
From: Andrea Arcangeli ([EMAIL PROTECTED]) Date: Thu Sep 14 2000 - 09:30:52 EST On Thu, Sep 14, 2000 at 07:40:12PM +1000, Robert Cohen wrote: >> With kernel version 2.4.0-test1-ac22, I saw adequate performance. >In 2.4.0-test1-ac22 there were a latency-driven elevator (the one we have >now since test2 can't provide good latency anymore). >So if something it should be the other way around, the elevator that we >have since test2 should provide _better_ throghput and _less_ seeks. Thus >it can't be the elevator algorithm but maybe as Ingo said something in >the >plugging that broke during the test2 changes. > In 2.4.0-test3 - test6, the default max_bombs value became 0. And the > performance with this setting was terrible. >It's zero because in reality is not limited anymore, this just mean it >should provide better performance and worse latency. Your correct, I thought for a while I was seeing performance improvements by changing max_bombs with elvtune in test6, but it seems that was just random fluctuation. >> Although I still saw a tendency for a client to get write starved. >Are you doing synchronous writes, right? >> Unfortunately, the benchmarks don't show any improvement. >tiotest should provide better numbers with the elevator from test2 (>compared to the test1 one). Ive done some tiotest benchmarks. Tiotest doesnt show any significant performance problems. In kernel versions test1- test6 I see roughly comparable performance. Write 8Meg/sec, read 5 Meg/sec. So performance didnt change when the elevator was rewritten in test2. In test9pre2 I see a jump in read perforance from 5 Meg/sec to 10 Meg/sec. While write stays the same. While that is all well and good, the fact remains that the netatalk benchmark remains terrible. With 2.4.0-test9pre2, throughput drops from 2000 blocks/5 seconds (according to vmstat) with 2 clients to 100 blocks/ 5 secs with 4 clients. Ive double checked, the test is not using Sync writes. I'm also seeing a tendency for clients to get write starved. Also while the benchmark is running the machine is basically unusable for other actions. Programs can't be started from the command prompt. They just hang, presumably waiting on disk IO. Sometimes top and vmstat stop updating. I saw this to some extent while running tiotest as well. The only kernel I have been able to find with good performance on this benchmark was 2.4.0-test1-ac22. Ingo's patch for test9pre1 didnt seem to make any difference. -- Robert Cohen TLTSU, Australian National University. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning]
> On Sun, 17 Sep 2000, Linus Torvalds wrote: > That's another case where the SCSI layer is module dependent. If it's a > module, we use the "init_module()" in scsi/scsi.c, and if not, we instead > use "scsi_dev_init()". They do some of the same things (well, they > obviously would have to, otherwise there wouldn't be any point to having a > init routine at all), but in general do it in very different ways for no > good reason I can see. > I agree. The scsi subsystem has been like this for ages, and I've taken the task of cleaning it up. The reason for not doing the _big_ patch right away, was because of the complextity of this paticular layer. This complexity is _not_ needed, as the recent changes to the network layer has taught us. In fact I think making the scsi layer behave more like the network layer in terms of initialization would benefit not only those hacking on scsi, but all of those maintaining scsi host drivers. > Torben, would you mind terribly expanding on your previous patch a bit, > and also cleaning this part up? As far as I can tell, we should just > remove scsi_dev_init() completely, and use the module init code with an > initcall(). Two less regions of #ifdef MODULE, and one less different > code-path to worry about.. > I'll do this. I agree about the scsi_dev_init part. We _need_ one entry point into each module (scsi/host/device). This change will actually make some code a duplicate and therefore needs to be removed which I consider a good ting. -- Regards, Torben Mathiasen - 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: New topic (PowerPC Linux PCI HELL)
> >All I wanted was a function that allows the driver to decide that which >needs to be enabled. > >pci_enable_device(struct pci_dev *dev, byte enable_mask) > >This would allow drivers to enable that which it needs and not weird out >the hardware that does not like all of this extra fluff. This is indeed interesting. Some devices, for example, will provide several apertures (can eat much bus space) while only one of them is actually needed by the driver. Having the driver be able to only enable (and possibly claim) one of them would free up some bus space for other devices (I'm thinking here about hot swap devices that will dynamically claim bus space, like cardbus). Ben. - 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.4.0-test9-pre2
H. Peter Anvin wrote: > Ideally, the linker should have some kind of merging pass to merge > these multiple instances -- this really could help C++ template > instantiation problems as well -- but for now, the only "safe" way is > pretty much to provide a library with non-inlined versions and hope > nothing gets linked from it. The linker does merge multiple instances of C++ template functions. It's GCC you'd need to teach about merging the non-inlined functions. - 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: partions on floppy
On Mon, Sep 18, 2000 at 01:24:58AM -0500, Adam wrote: > > Ok, I made a parition on floppy, now do I access it? > > Command (m for help): p > > Disk /dev/fd0: 2 heads, 18 sectors, 80 cylinders > Units = cylinders of 36 * 512 bytes > > Device BootStart EndBlocks Id System > /dev/fd0p1 180 1431 83 Linux > > I did > mknod /dev/fd0p1 b 2 1 > > However, neither 'mkswap' nor 'mke2fs' seems to work on '/dev/fd0p1' Say "ls -l /dev/fd*" and "man 4 fd" to see what current minors exist and how they behave. (The minor is used to select size and density, not partition.) Andries - 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/
PATCH 2.4.0.9.2: export ethtool interface
This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
domain of the sparc ports into include/linux. This publishes an
existing interface, and has been discussed before. (search past lkml
subject headers for "media tool" and "ethtool")
This updated patch should take some of the past threads into account.
The differences from the current sparc ethtool.h are:
* bitmask for advertising as well as supported media types
* interrupt mitigation hints max{tx,rx}pkt (Jes suggestion)
* four reserved u32 slots for future expansion
* assigned an ioctl: SIOCETHTOOL (0x8944)
Questions, comments, and feedback welcome. If there are no objections,
I'll submit to DaveM for inclusion in 2.4.0-test9-whatever, after this
current round of discussion.
Jeff
diff -urN vanilla/linux-2.4.0-test9-pre2/include/linux/ethtool.h
linux_2_3/include/linux/ethtool.h
--- vanilla/linux-2.4.0-test9-pre2/include/linux/ethtool.h Wed Dec 31 19:00:00
1969
+++ linux_2_3/include/linux/ethtool.h Sun Sep 17 17:29:10 2000
@@ -0,0 +1,96 @@
+/* $Id: ethtool.h,v 1.1.186.1 2000/09/16 20:13:14 jgarzik Exp $
+ * ethtool.h: Defines for Linux ethtool.
+ *
+ * Copyright (C) 1998 David S. Miller ([EMAIL PROTECTED])
+ */
+
+#ifndef _LINUX_ETHTOOL_H
+#define _LINUX_ETHTOOL_H
+
+
+/* This should work for both 32 and 64 bit userland. */
+struct ethtool_cmd {
+ u32 cmd;
+ u32 supported; /* Features this interface supports */
+ u32 advertising;/* Features this interface advertises */
+ u16 speed; /* The forced speed, 10Mb, 100Mb, gigabit */
+ u8 duplex; /* Duplex, half or full */
+ u8 port; /* Which connector port */
+ u8 phy_address;
+ u8 transceiver;/* Which tranceiver to use */
+ u8 autoneg;/* Enable or disable autonegotiation */
+ u32 maxtxpkt; /* Tx pkts before generating tx int */
+ u32 maxrxpkt; /* Rx pkts before generating rx int */
+ u32 reserved[4];
+};
+
+
+/* CMDs currently supported */
+#define ETHTOOL_GSET 0x0001 /* Get settings, non-privileged. */
+#define ETHTOOL_SSET 0x0002 /* Set settings, privileged. */
+
+/* compatibility with older code */
+#define SPARC_ETH_GSET ETHTOOL_GSET
+#define SPARC_ETH_SSET ETHTOOL_SSET
+
+/* Indicates what features are supported by the interface. */
+#define SUPPORTED_10baseT_Half (1 << 0)
+#define SUPPORTED_10baseT_Full (1 << 1)
+#define SUPPORTED_100baseT_Half(1 << 2)
+#define SUPPORTED_100baseT_Full(1 << 3)
+#define SUPPORTED_1000baseT_Half (1 << 4)
+#define SUPPORTED_1000baseT_Full (1 << 5)
+#define SUPPORTED_Autoneg (1 << 6)
+#define SUPPORTED_TP (1 << 7)
+#define SUPPORTED_AUI (1 << 8)
+#define SUPPORTED_MII (1 << 9)
+#define SUPPORTED_FIBRE(1 << 10)
+
+/* Indicates what features are advertised by the interface. */
+#define ADVERTISED_10baseT_Half(1 << 0)
+#define ADVERTISED_10baseT_Full(1 << 1)
+#define ADVERTISED_100baseT_Half (1 << 2)
+#define ADVERTISED_100baseT_Full (1 << 3)
+#define ADVERTISED_1000baseT_Half (1 << 4)
+#define ADVERTISED_1000baseT_Full (1 << 5)
+#define ADVERTISED_Autoneg (1 << 6)
+#define ADVERTISED_TP (1 << 7)
+#define ADVERTISED_AUI (1 << 8)
+#define ADVERTISED_MII (1 << 9)
+#define ADVERTISED_FIBRE (1 << 10)
+
+/* The following are all involved in forcing a particular link
+ * mode for the device for setting things. When getting the
+ * devices settings, these indicate the current mode and whether
+ * it was foced up into this mode or autonegotiated.
+ */
+
+/* The forced speed, 10Mb, 100Mb, gigabit. */
+#define SPEED_10 10
+#define SPEED_100 100
+#define SPEED_1000 1000
+
+/* Duplex, half or full. */
+#define DUPLEX_HALF0x00
+#define DUPLEX_FULL0x01
+
+/* Which connector port. */
+#define PORT_TP0x00
+#define PORT_AUI 0x01
+#define PORT_MII 0x02
+#define PORT_FIBRE 0x03
+
+/* Which tranceiver to use. */
+#define XCVR_INTERNAL 0x00
+#define XCVR_EXTERNAL 0x01
+#define XCVR_DUMMY10x02
+#define XCVR_DUMMY20x03
+#define XCVR_DUMMY30x04
+
+/* Enable or disable autonegotiation. If this is set to enable,
+ * the forced link modes above are completely ignored.
+ */
+#define AUTONEG_DISABLE0x00
+#define AUTONEG_ENABLE 0x01
+
+#endif /* _LINUX_ETHTOOL_H */
diff -urN vanilla/linux-2.4.0-test9-pre2/drivers/net/sunhme.c
linux_2_3/drivers/net/sunhme.c
--- vanilla/linux-2.4.0-test9-pre2/drivers/net/sunhme.c Thu Sep 7 11:32:00 2000
+++ linux_2_3/drivers/net/sun
RE: Availability of kdb
On Sun, 17 Sep 2000, Marty Fouts wrote: > I've probably debugged more operating systems under more varied environments > than nearly anyone here, having brought up a new OS, compiler, and CPU yea yea yea, if you are so good then you should be concentrating on giving your goodness and wisdom and experience to us and not boast about it. For to give is more blessed than receive. Regards, Tigran - 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/
[PATCH] Fix queued SIGIO
Hallo Linus, The siginfo signal sending uses SI_FROMUSER to see if it should look at current to check if the sending process is allowed to send the signal. Unfortunately SI_FROMUSER() is true for SI_SIGIO signals generated by the network stack for queued SIGIO. This leads to the SIGIO behaviour vary based on the process that runs by chance while the network softirq is active (between queued SIGIO and fallback SIGIO -- fallback SIGIO doesn't have that bug). [this problem is not on Ted's list yet, but it would clearly belong there because it makes the queued SIGIO interface near unusable] The problem is really that SI_SIGIO is negative, but it should be positive to make SI_FROMUSER return false on it. Changing it would unfortunately break binary compatibility. This patch instead changes the definition of SI_FROMUSER/KERNEL to check explicitely for SI_SIGIO and make it appear like a kernel generated signal type. This prevents send_sig_info from looking at current . It'll break programs that try to send SI_SIGIO (=-5) signals from userspace, but I think that is ok. Patch against 2.4.0test9pre1 -Andi --- include/asm-alpha/siginfo.h-SIG Mon Sep 11 16:06:54 2000 +++ include/asm-alpha/siginfo.h Sun Sep 17 20:00:27 2000 @@ -108,8 +108,9 @@ #define SI_ASYNCIO -4 /* sent by AIO completion */ #define SI_SIGIO -5 /* sent by queued SIGIO */ -#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0) -#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0) + +#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0 && (siptr)->si_code != SI_SIGIO) +#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0 || (siptr)->si_code == SI_SIGIO) /* * SIGILL si_codes --- include/asm-arm/siginfo.h-SIG Mon Sep 11 16:06:55 2000 +++ include/asm-arm/siginfo.h Sun Sep 17 20:00:39 2000 @@ -108,8 +108,8 @@ #define SI_ASYNCIO -4 /* sent by AIO completion */ #define SI_SIGIO -5 /* sent by queued SIGIO */ -#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0) -#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0) +#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0 && (siptr)->si_code != SI_SIGIO) +#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0 || (siptr)->si_code == SI_SIGIO) /* * SIGILL si_codes --- include/asm-i386/siginfo.h-SIG Wed Sep 13 23:30:51 2000 +++ include/asm-i386/siginfo.h Sun Sep 17 19:59:20 2000 @@ -108,8 +108,8 @@ #define SI_ASYNCIO -4 /* sent by AIO completion */ #define SI_SIGIO -5 /* sent by queued SIGIO */ -#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0) -#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0) +#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0 && (siptr)->si_code != SI_SIGIO) +#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0 || (siptr)->si_code == SI_SIGIO) /* * SIGILL si_codes --- include/asm-ia64/siginfo.h-SIG Mon Sep 11 16:06:56 2000 +++ include/asm-ia64/siginfo.h Sun Sep 17 20:00:59 2000 @@ -117,8 +117,8 @@ #define SI_ASYNCIO -4 /* sent by AIO completion */ #define SI_SIGIO -5 /* sent by queued SIGIO */ -#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0) -#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0) +#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0 && (siptr)->si_code != SI_SIGIO) +#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0 || (siptr)->si_code == SI_SIGIO) /* * SIGILL si_codes --- include/asm-m68k/siginfo.h-SIG Mon Sep 11 16:06:57 2000 +++ include/asm-m68k/siginfo.h Sun Sep 17 20:01:16 2000 @@ -108,8 +108,8 @@ #define SI_ASYNCIO -4 /* sent by AIO completion */ #define SI_SIGIO -5 /* sent by queued SIGIO */ -#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0) -#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0) +#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0 && (siptr)->si_code != SI_SIGIO) +#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0 || (siptr)->si_code == SI_SIGIO) /* * SIGILL si_codes --- include/asm-mips/siginfo.h-SIG Mon Sep 11 16:06:59 2000 +++ include/asm-mips/siginfo.h Sun Sep 17 20:01:39 2000 @@ -128,8 +128,9 @@ #define SI_MESGQ -4 /* sent by real time mesq state change */ #define SI_SIGIO -5 /* sent by queued SIGIO */ -#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0) -#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0) + +#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0 && (siptr)->si_code != SI_SIGIO) +#define SI_FROMKERNEL(siptr) ((siptr)->si_code > 0 || (siptr)->si_code == SI_SIGIO) /* * SIGILL si_codes --- include/asm-mips64/siginfo.h-SIGMon Sep 11 16:07:02 2000 +++ include/asm-mips64/siginfo.hSun Sep 17 20:01:55 2000 @@ -128,8 +128,9 @@ #define SI_MESGQ -4 /* sent by real time mesq state change */ #define SI_SIGIO -5 /* sent by queued SIGIO */ -#define SI_FROMUSER(siptr) ((sip
2.4.0-test9-pre1: Memory in use grows rapidly with no application responsible
[Disclaimer: I'm a newbie.] I was closely monitoring the memory usage on my system while testing something. I decided to run updatedb to try to make the system less responsive and see if a realtime program would hold up. For no apparent reason, while updatedb was running free(1) reported that the memory in use (+/- buffers/cache) was skyrocketing steadily. Looking at the process lists, no application was anywhere near the 95mb that the used memory had risen by. After the updatedb process had completed, the memory in use stopped climbing but it never went down below the 95mb that the memory usage had exploded by, even after killing X and just about every process. I have seen similar situations occur with various 2.4.0-test kernels. Even dropping down to single-user mode still reports that a lot of memory is in use, and no process is anywhere near large enough to be a significant part of it. The system is an Athlon with an IDE disk drive and an ext2 filesystem on that drive. I can provide further information if would be helpful. Thanks, Aaron Lehmann p.s. please CC: me in on replys ... thanks - 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.0test9-pre2 and pre1 wont boot
On Sun, 17 Sep 2000, Christoph Lameter wrote: > On 18 Sep 2000, Juan J. Quintela wrote: > > > > "christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes: > > > > christoph> With both version I get the "booting linux" message and then the >first > > christoph> line of the kernel messages. Then its dead. Have tried to change the >kernel > > christoph> configuration but to no avail. > > > > christoph> 2.4.0test2 works fine. > > > > > > Could you send your .config and a description of your system??? > > AMD K2-400. 64M Ram. VIA chipset. I just want to let you know that I am experiencing the same problem with 2.4.0test9-pre1. This is with an old ISA 486 box with 32M. Behavior is a little bit different: I don't see the first line of the kernel messages and I get a hard reset. 2.4.0test8 booted fine and I have stripped the test9-pre1 patch down to 80k because the rest (acpi, drivers/net, drivers/usb, for example) was not configured in. The problem stays... The patch still contains (from memory): - mktime movement - char/mem.c - char/nvram.c - scsi/sd.c - everything from fs/ (except nfs, not enabled) - everything from kernel/ - Rik's VM patches - net/core/sock.c The biggest part that is still in the patch are Rik's VM enhancements although I do not think that they are the cause of the problem in this early stage. Seems to be a strange side effect... I cannot give you much more information since I am in the office now but feel free to ask. Matze -- Matthias Hanischmailto:[EMAIL PROTECTED]phone: +49 8137 935-219 - 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/
PROBLEM: umount report "busy" on r/o remount of root filesystem
Umount report "busy" when i try r/o remount the root filesystem at end of halt script. My halt script ends with: # Begin of halt kill -9 -1 umount -a mount -n -o remount,ro / halt # End of halt Umount (and mount on next line too) report "/: device is busy" and the root filesystem stay not correctly unmounted. But when i press magic key "u" (emergency remount), the filesystem is correctly remounted. All other mounted filesystems are correctly unmounted by "umount -a". This bug is present only on my motherboard with SiS5513 chipset; on other motherboard with VIA chipset and the totaly same linux it's all right. The second thing is, that on kernels 2.2.X (up to 2.2.13, later i've not tested) it's ok too. The version of mount has not any influence. hardware: Pentium 75, SiS chipset, 64MB RAM HDD WDC AC36400L 6449MB, DMA disabled, PIO 4 software: kernel 2.4.0-test7 gcc 2.95.2 binutils 2.10 mount 2.10o glibc 2.1.3 Part of dmegs: VFS: Diskquotas version dquot_6.4.0 initialized CPU: Intel Pentium 75 - 200 stepping 05 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. Intel Pentium with F0 0F bug - workaround enabled. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfcb60, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware ... Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 SIS5513: chipset revision 7 SIS5513: not 100% native mode: will probe irqs later SiS5511 SIS5513: simplex device: DMA disabled ide0: SIS5513 Bus-Master DMA disabled (BIOS) SIS5513: simplex device: DMA disabled ide1: SIS5513 Bus-Master DMA disabled (BIOS) hda: WDC AC36400L, ATA DISK drive hdd: ATAPI CDROM, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 12594960 sectors (6449 MB) w/256KiB Cache, CHS=784/255/63 hdd: ATAPI 32X CD-ROM drive, 128kB Cache Uniform CD-ROM driver Revision: 3.11 Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 Output of lspci -vvv: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5511/5512 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at d400 [size=16] 00:0a.0 VGA compatible controller: ATI Technologies Inc 215CT [Mach64 CT] (rev 41) (prog-if 00 [VGA]) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) Subsystem: Realtek Semiconductor Co., Ltd. RT8029(AS) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- - 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: Format of /proc/meminfo
I'd rather see a new /proc/memoryinfo with a lot of thought given to the current and future structure of it than adding kludges into what already exists. Userland utils need to be more tolerant of "junk" and not rely on static content locations. -d Dan Kegel wrote: > Rik van Riel wrote: > > > The only thing it can be a problem for an alternate VM if there > > > would be user<->kernel API differences realted to the very > > > internal of the memory management so if possible I'd like if > > > that could be avoided. > > > > Sure, lets get rid of /proc/meminfo ;) > > > > But serious, if /proc/meminfo isn't there to give information > > about the internal memory use of the system, why do we have > > it? I don't see /proc/meminfo doing anything else than that... > > Andrea is worried about userland utilities getting confused > because of differences in /proc/meminfo for various VM systems. > Maybe it would be enough to put the entries that are > VM-version specific after the generic ones, and preface them > with the name of the VM system, e.g. -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: Oops on boot with both 2.2.17 and 2.4.0t8p6
On Sun, Sep 17, 2000 at 10:53:55PM -0300, Marcelo Tosatti wrote:
>
> AFAIK most distros use CONFIG_PCI_GOANY, which causes the kernel to try to
> detect the PCI devices directly, and in case this fails, it tries to
> detect via BIOS.
I thought so too from reading the help regarding this option, but the
code seems to (in case of CONFIG_GOANY) to check through the bios,
check directly and pick the direct mapping (if not NULL) and otherwise
pick the BIOS mapping (if not NULL) (this is from arch/i386/kernel/
pci-pc.c). This is not what I expected from reading the help text.
Would it be more correct for the code to check directly first (if con-
figured so and not excluded at boot time etc) and then only check through
BIOS if the direct mapping failed?
Example patch (probably fubar'ed):
--- pci-pc.c.orgMon Sep 18 09:14:48 2000
+++ pci-pc.cMon Sep 18 09:16:01 2000
@@ -962,15 +962,15 @@
struct pci_ops *bios = NULL;
struct pci_ops *dir = NULL;
+#ifdef CONFIG_PCI_DIRECT
+ if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
+ dir = pci_check_direct();
+#endif
#ifdef CONFIG_PCI_BIOS
- if ((pci_probe & PCI_PROBE_BIOS) && ((bios = pci_find_bios( {
+ if ((pci_probe & PCI_PROBE_BIOS) && (!dir) && ((bios = pci_find_bios( {
pci_probe |= PCI_BIOS_SORT;
pci_bios_present = 1;
}
-#endif
-#ifdef CONFIG_PCI_DIRECT
- if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
- dir = pci_check_direct();
#endif
if (dir)
pci_root_ops = dir;
Comments?
Regards,
Rasmus
-
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: test9-pre1 hang when loading scsi-ide cdrom
On Sun, Sep 17, 2000 at 03:20:17PM +0200, Torben Mathiasen wrote: > > > > The problem seems to reside in the ide-scsi driver; if the cdrom (sr_mod) is > > not loaded, I get during initialisation of the ide-scsi module a lockup > > after printing the information about the 1st host (dies after the 'Type: > > CDROM' line). Probing the 2nd host seems to fail. > > > > When did this start to happen? I sustect this is something similar to what has > been happening with sd because of the module_init/exit stuff. Latest version that worked for me was test7. > > Some people are seeing lockups because of the sd changes, going back to init_module > cures it. The problems is within the scsi subsystem itself. > > Could you try reverting the init_sr/exit_sr to init_module/cleanup_module and > removing module_init/exit please? I tried but this didn't make any difference. No surprise because the ide-scsi also causes a hangup if the sr driver is not loaded. Since the test9-pre2 was out yesterday evening I gave it a try. No difference, also hangs after probing the first ide device. I understood there are some problems in the scsi subsystem; especially difference in behaviour regarding if modules are used or not. In my config the adaptec aha-2940uw (AIC7) is included in the kernel image, while the ide-scsi is compiled as a module. Perhaps this does matter... from my .configure: # # SCSI support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_DEBUG_QUEUES=y # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI low-level drivers # CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_PROC_STATS=y CONFIG_AIC7XXX_RESET_DELAY=5 Frank. -- + --- -- - - -- |Frank van de Pol -o) | [EMAIL PROTECTED] /\\ | _\_v |Linux - Why use Windows, since there is a door? - 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: Attempting to mount Zip causes floppy access (2.2.16)
On Sat, Sep 16, 2000 at 10:23:13PM +0200, Andries Brouwer wrote: > On Sat, Sep 16, 2000 at 11:35:24AM +0100, Nick Holloway wrote: > > There are two questions. Firstly, why did the mount process get stuck > > in the kernel, and secondly (and more importantly) what was it doing > > accessing "/dev/fd0"? > > Does that follow? Maybe the floppy I/O error occurred at some other > time, or for some other reason. Can you reproduce access of device 02:00 > using mount /dev/sda4? The floppy I/O error occurred 13 seconds after the partition table was printed (I'd removed the timestamps to make the messages easier to read), and the machine wasn't doing anything else -- that is why I believe the floppy access was triggered by attempting to mount the zip. However, I have just tried to reproduce it, and I just get the hang in wait_on_buffer, and not the floppy access. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - 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/
