Re: 2.4.x and SMP fails to compile (`current' undefined)
David Ford wrote: > > Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP? > > > > -d > > Stephen Frost wrote: > > > * David Ford ([EMAIL PROTECTED]) wrote: > > > A person just brought up a problem in #kernelnewbies, building an SMP > > > kernel doesn't work very well, current is undefined. I don't have more > > > time to debug it but I'll strip the config and put it up at > > > http://stuph.org/smp-config > > > > They're trying to compile SMP for Athlon/K7 (CONFIG_MK7=y). > It's not an incompatibility with the k7 chip, just bad code in include/asm-i386/string.h. in_interrupt() cannot be called from there. I have posted a patch here many times since last May. Most recent was Saturday. Tom -- The Daemons lurk and are dumb. -- Emerson - 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: WOL and 3c59x (3c905c-tx)
On Wed, 31 Jan 2001, Tobias Ringstrom wrote: > Would it be enough to port the acpi_wake function to 2.4? If so, I can do > that myself. In fact, I think I'll try that right away. Who needs > breakfast anyway? :-) Ok, I tried it, and it works. I can now start my computer using WOL packets after an "init 0" in Linux. I do not how it behaves in a suspend/wake-up situation, though. Let me know when you have a patch for 2.4, and I'll try it. /Tobias - 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-audio-dev] low-latency scheduling patch for 2.4.0
Joe deBlaquiere wrote: ~snip~ > The locical answer is run with HZ=1 so you get 100us intervals, > right ;o). Lets not assume we need the overhead of HZ=1 to get 100us alarm/timer resolution. How about a timer that ticks when we need the next tick... On systems with multiple hardware timers you could kick off a > single event at 200us, couldn't you? I've done that before with the > extra timer assigned exclusively to a resource. With the right hardware resource, one high res counter can give you all the various tick resolutions you need. BTDT on HPRT. George It's not a giant time > slice, but at least you feel like you're allowing something to happen, > right? > >> >> -- >> 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: VT82C686A corruption with 2.4.x
On Wednesday, 31 January 2001, at 08:36:42 (+0100),
Vojtech Pavlik wrote:
> Hi!
>
> 1) You don't seem to have any drives on the VIA controller. If this is
> true, I don't think this can be a VIA IDE driver problem.
>
Hi, Are you referring to Mark or me?
I have drives on my VIA (only..) IDE controller:
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 51536H2, ATA DISK drive
hdb: Maxtor 94098U8, ATA DISK drive
hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2
hdb: hdb1
> 2) In your original message you suggest bs=1024M, which isn't a very
> good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> fine.
>
> 3) You sent next to none VIA related debugging info. lspci -v itself
> isn't much valuable because I don't get the register contents. Also
> hdparm -i of the drives attached to the VIA chip would be useful. Plus
> also the contents of /proc/ide/via.
I didn't supply anything either, even though my configuration works great it
might prove useful to someone comparing:
bash-2.04# hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
bash-2.04# hdparm -i /dev/hdb
/dev/hdb:
Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
bash-2.04#
bash-2.04# cat /proc/ide/via
--VIA BusMastering IDE Configuration
Driver Version: 2.1e
South Bridge: VIA vt82c686a rev 0x22
Command register: 0x7
Latency timer: 32
PCI clock: 33MHz
Master Read Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry: on
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: on on
End Sect. FIFO flush: on on
Prefetch Buffer: on on
Post Write Buffer: on on
FIFO size: 8 8
Threshold Prim.: 1/2 1/2
Bytes Per Sector: 512 512
Both channels togth: yes yes
---drive0drive1drive2drive3-
BMDMA enabled:yes yes yesno
Transfer Mode: UDMA UDMA UDMA DMA/PIO
Address Setup: 30ns 30ns 30ns 120ns
Active Pulse:90ns 90ns 90ns 330ns
Recovery Time: 30ns 30ns 30ns 270ns
Cycle Time: 30ns 30ns 60ns 600ns
Transfer Rate: 66.0MB/s 66.0MB/s 33.0MB/s 3.3MB/s
bash-2.04# lspci -v (trimmed)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
Flags: bus master, medium devsel, latency 8
Memory at e000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00
[Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 9000-9fff
Memory behind bridge: dde0-dfef
Prefetchable memory behind bridge: cdc0-ddcf
Capabilities: [80] Power Management version 2
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
Error compiling 2.4.1/2.4.0 with pcmica and no SMP
Hi, When compiling either 2.4.1 or 2.4.0 without SMP support on a Compaq Armada E500 running RH 7.0 (yes I do use kgcc) I get the following error: ld -m elf_i386 -T /root/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head. o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm. o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net. o drivers/media/media.o drivers/parport/driver.o drivers/char/drm/drm. o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver. o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pcmcia/pcmcia. o drivers/net/pcmcia/pcmcia_net.o drivers/pnp/pnp.o drivers/video/video. o drivers/usb/usbdrv.o \ net/network.o \ /root/linux/arch/i386/lib/lib.a /root/linux/lib/lib.a /root/linux/arch/i386/lib/lib. a \ --end-group \ -o vmlinux drivers/pcmcia/pcmcia.o: In function `yenta_close': drivers/pcmcia/pcmcia.o(.text+0x9b55): undefined reference to `del_timer_sync' make: *** [vmlinux] Error 1 Is this a known problem or am I doing something wrong here? It looks like del_timer_sync is defined in linux/timer.h and from what I can see this is defined to be the same as del_timer when SMP is disabled. From what I can see linux/timer.h gets included, but still the linking fails. Here is a copy of the comfiguration used to compile the kernels: # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y 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_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_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_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR 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_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82365 is not set # CONFIG_TCIC 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=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y 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 # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m
Re: VT82C686A corruption with 2.4.x
Hi! 1) You don't seem to have any drives on the VIA controller. If this is true, I don't think this can be a VIA IDE driver problem. 2) In your original message you suggest bs=1024M, which isn't a very good idea, even on a 768 MB system. Here with bs=1024k it seems to run fine. 3) You sent next to none VIA related debugging info. lspci -v itself isn't much valuable because I don't get the register contents. Also hdparm -i of the drives attached to the VIA chip would be useful. Plus also the contents of /proc/ide/via. 4) Did you check the problem you're experiencing isn't a memory problem? That'd go away with removing some RAM. Vojtech PS. I'm not sure how wise is to use both ACPI and APM at once. Well, I never used either in a server environment - I don't think it makes much sense. PPS. What should I do with a ksyms dump of the Advansys SCSI and a Tulip NIC drivers? It isn't related anyhow. -- Vojtech Pavlik SuSE Labs - 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: gprof cannot profile multi-threaded programs
> http://opensource.corel.com/cprof.html > > I haven't used it yet, myself. > I have. cprof is no good - extremely slow and generates a 100MB trace even with a simple hello world program. - Mohit - 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: WOL and 3c59x (3c905c-tx)
On Wed, 31 Jan 2001, Andrew Morton wrote: > The code was broken, so I disabled it. Because of the loss of state bug with Cyclone, and the "missing" acpi_wake workaround, right? > I "fixed" WOL in the 2.2.19-pre candidate driver. It's > at http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.2.19-pre6-1.gz > > I'd really appreciate it if you could test the WOL in > that driver. Then we can port it into 2.4 and try to > fool Linus into thinking it's a bugfix :) Of course it is a bug-fix! I'm very bugged by the current behaviour! Doesn't that count? :-) Ugh. Is the 2.2 driver more advanced than the 2.4 one? Only temporary, I hope... :-) But alas, I cannot easily test this patch, since I need 2.4 for my ATA100 IDE controller, but please send me a patch for 2.4 as soon as you have one, and I'll help you test it. Would it be enough to port the acpi_wake function to 2.4? If so, I can do that myself. In fact, I think I'll try that right away. Who needs breakfast anyway? :-) /Tobias, the one smiley per sentence 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: 2.4.x and SMP fails to compile (`current' undefined)
[David Ford] > Mhm. Is it worth the effort to make a dependancy on the CPU type for > SMP? Yes. 'make config' should not allow unsupported configurations, at least where convenient. So - are any of the other chip types also incompatible with SMP support (the Winchips, maybe)? Peter --- 2.4.1/arch/i386/config.in~ Tue Jan 30 14:46:04 2001 +++ 2.4.1/arch/i386/config.in Wed Jan 31 01:08:00 2001 @@ -154,7 +154,10 @@ bool 'Math emulation' CONFIG_MATH_EMULATION bool 'MTRR (Memory Type Range Register) support' CONFIG_MTRR -bool 'Symmetric multi-processing support' CONFIG_SMP +# AMD SMP - not yet +if [ "$CONFIG_MK6" != "y" -a "$CONFIG_MK7" != "y" ]; then + bool 'Symmetric multi-processing support' CONFIG_SMP +fi if [ "$CONFIG_SMP" != "y" ]; then bool 'APIC and IO-APIC support on uniprocessors' CONFIG_X86_UP_IOAPIC if [ "$CONFIG_X86_UP_IOAPIC" = "y" ]; then - 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.1 -- Unresolved symbols in radio-miropcm20.o
Thanks Keith, I don't get any errors if I add these lines to my .config file: CONFIG_SOUND_OSS=m CONFIG_SOUND_ACI_MIXER=m Ruurd, are you maintaining this driver? If not, is anyone else willing to hack the config scripts to enforce this dependency? This is not my area of competency. Thanks, Miles Keith Owens wrote: > > On Tue, 30 Jan 2001 13:08:12 -0800, > Miles Lane <[EMAIL PROTECTED]> wrote: > >depmod: *** Unresolved symbols in > >/lib/modules/2.4.1/kernel/drivers/media/radio/radio-miropcm20.o > >depmod:aci_write_cmd > >depmod:aci_indexed_cmd > >depmod:aci_write_cmd_d > > Those symbols are defined in drivers/sound/aci.c but are not exported > for other modules to use. The aci and miropcm20 code needs to be > changed to support use as modules. Also the config.in files need > fixing for these files, it is possible to select combinations of aci > and miropcm20 that will fail to link (miropcm20 built in, aci not > selected or selected as a module) or fail to load (miropcm20 selected > as a module, aci not selected). > > - > 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/ - 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.X inode cache bug
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > Excuse me for the lack of patch in this mail,... > In 2.4.x, linux/fs/inode.c has a hash() function with a small > slip-up. The inode hash-value is initialized with "unsigned > long tmp = i_ino | ((unsigned long) sb / L1_CACHE_BYTES);". > ... I believe this is a > slip-up, because you should NEVER use bitwise-or in a hash > formula. This creates a slanted distribution, and depending on > the address of the superblock block, can cause severe > inefficiency in the code. > Just replacing the | with ^ imroves hash-table efficiency > noticeably,... Then maybe the attached patch is what you want? This also replaces `+' on the next line with `^' to avoid slanted distribution. --== Sent via Deja.com ==-- http://www.deja.com/ jukka.patch
Re: OT: mount/umount doesn't track used resources correctly?
[Miles Lane] > I think the problem may be due to usermode tools not handling the new > "mount multiple devices to a single mount point" feature, but I'm not > sure. Yes, quite possibly. Rumor has it that util-linux has recently acquired some wisdom in this area. (I can't confirm or deny.) Try upgrading, or just trust /proc/mounts for the real story.. Peter - 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: Request: increase in PCI bus limit
[Bernd Eckenfels] > May even decrease the kernel for systems < 4 busses. Be careful, though. Users may set this thinking "I have a generic system with only one PCI bus" without realizing that AGP, cardbus and some motherboard devices are all counted. Pad the CONFIG option by about 4 busses and we'll be OK.. Peter - 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: VIA VT82C686X
You system did something funny or the new VIA code did it.
But because you observed this pattern the new feature that on Linux has
kicked in and hopefull recovered the system for you.
On Wed, 31 Jan 2001, [iso-8859-1] Frédéric L. W. Meunier wrote:
> Me too. But I couldn't get UDMA 66 after changing my BIOS
> settings and booting. With 33 it's very stable (what I used
> with 2.4.0). A diff:
>
> -hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(33)
> +hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
> ...
> +hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> +hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> VFS: Mounted root (ext2 filesystem) readonly.
> -Freeing unused kernel memory: 200k freed
> +Freeing unused kernel memory: 204k freed
> +hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> +hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> +hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> +hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> +hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> +hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> +hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> +hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> +ide0: reset: success
Because you did not see DMA_DISABLED
The auto_dma_crc downgrade feature turned down the transfer rate of the
drive/host pair until the iCRC issue stablized.
Cheers,
> I know this is a known issue, but I thought testing would be
> OK. ASUS K7V with the shipped cable.
>
> --
> 0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
On Tue, 30 Jan 2001, David D.W. Downey wrote: > > Woohoo! Just found out that ATA66 on the VIA aint too great. > > I set the kernel boot options idebus=66 ide0=ata66 enabling ATA66 Sorry but you are not right in this world ... Where in you manual does is "QUOTE" you can drive the ATA/IDE bus at 66MHz? > according to dmesg. The HDD is a WDC UDMA100 30.5GB drive. I retried the > > dd if=/dev/hda7 of=/tmp/testing2.img bs=1024k count=2000 > > on one VT, ran renice -20 on the dd process then ran procinfo on another > and top on a 3rd. I logged into a fourth and ran sync;sync;sync;sync;sync. > > After @30 seconds the machine became totally unresponsive, locking up all > but the current VT. > > I let it sit there and waited until the dd finished in case the renice was > what killed the control. When dd finished I tried running any type of > command but the tty was completely frozen. All other VTs were non > responsive as well. > > > This is gonna be fun when I test the Promise controller. hehe > > > David D.W. Downey > > > - > 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/ > Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Ruined boot sector on X20/W2K
[Richard B. Johnson] > Then, simply: > cp /boot/boot.0800 /dev/whatever Ah, but that reverts the partition table, which may have been changed since first installing lilo. To avoid this, just type 'lilo -U', which does much the same thing but without touching the partition table. Peter - 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/
VFAT access times in 2.4.1 kernel
Hello, I just switched to 2.4.1 from 2.2.18 and have the kernel set up in generally the same manner in terms of functionality. I've found that VFAT access is incredibly slow in directories with a large number of files. I have a single directory with approximately 1500 items, all 3-5MB apiece, and if I do 'ls -alt dir/ |more' on that directory, it takes a full 2 seconds do list the contents of the first page. If I do so again immediately afterwards it displays immediately, but the same effects occur if I wait any considerable amount of time (> 2 minutes). I've experienced no such problems under 2.2.18, and I'm running a 20GB Maxtor drive running at UDMA(33) without any known issues. Any ideas? Brian J. Conway [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/
Re: Version 2.4.1 cannot be built.
[Richard B. Johnson] > Bob Tracy found the problem: the second ':' really needs to be > escaped even though newer versions of make allow what was written. > -$(MODINCL)/%.ver: CFLAGS := -I./include $(CFLAGS) > +$(MODINCL)/%.ver: CFLAGS \:= -I./include $(CFLAGS) No, that's a workaround in that it subverts the purpose of the line. (In which case, better to delete the line entirely.) The correct fix is to upgrade to a version of 'make' that understands the syntax used there. Yes, the FSF being the FSF, they keep adding features to their software. And yes, some of us are using some of those features. It could have been worse. Documentation/Changes lists version 3.77, from July 1998. We (at least I) actually considered using features from 3.78, but that was quickly shot down since 3.78 is too new - September 1999. Peter - 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: gprof cannot profile multi-threaded programs
See http://opensource.corel.com/cprof.html I haven't used it yet, myself. - Dan - 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/
gprof cannot profile multi-threaded programs
Hi, I'm using Linux-2.2 and discovered a problem with the profiling of a multi-threaded program (uses Linux pthreads). Basically, upon compiling the program with '-pg' option, running it and invoking gprof on the gmon.out file only shows the profile information corresponding to the computation done by the first thread (that starts in main()). The computation performed by any other thread (created using pthread_create()) is not accounted for. I analyzed the problem to be the following. Linux uses periodic SIGPROF signals for profiling (Linux doesn't use the profil system call used in other OS's like Solaris where the kernel does the profiling on behalf of the process). All profile information is collected in the context of the signal handler for the SIGPROF signal in Linux. Unfortunately, any thread that's created using pthread_create() does not get these periodic SIGPROF signals. Hence any thread other than the first thread is not profiled. The fix is to use setitimer() system call immediately in the thread startup function for any new thread to make the SIGPROF signal to be delivered at the designated interrupt frequency (every 10ms). With this fix, the profile produced by gprof reflects the overall computation done by all threads in the process. A more general fix would be to fix the kernel to make any new threads inherit the setitimer() settings for the parent thread. Does anyone know if this problem has already been fixed ? If so, please send me a pointer to the patch. Thanks, - Mohit - 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: [Off-Topic?] Mixer device and controls (/dev/mixer)
[Michael B. Trausch] > > I've noticed that with some audio devices, I have a Bass and Treble > > setting that I can play with (and usually do, becuase it makes > > things sound MUCH better). Why don't I have that in some devices, > > and is there a way (through the kernel, or through a userspace > > program) to make up the difference? [Daniel Chemko] > I have not really looked into this but I think this option is only > supported when the audio hardware supports bass and treble. ...and in case the hardware does *not* have such mixer settings, the right place to introduce them is probably 'esd' or equivalent. I don't remember if mpg123 (or its 21st-century equivalent, ogg123) support esd but I think they do, and if not they should be hacked to. > > I am building myself a new installation of Linux (from the kernel > > on up ;p... the Distributions aren't keeping up as much as I want I've just got to ask: what exactly do you feel you need for which Debian 'unstable' is not up-to-date? (Check http://packages.debian.org to see what versions of things are available in 'unstable'.) I ask because in my experience, they have very rarely been more than a few weeks out of date on any major software, except where a significant architecture change was involved (such as the migration to xfree86 4.x), or a feature not deemed "ready for prime time" (BIND 9.0).. > > and I want all my own home-built software anyway, except for X, > > 'cuz that's a bitch to attempt to compile on my own). Well, that's understandable - don't compile in support for features you know you won't need, etc, save maybe 10% of your disk space that way.. Peter - 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+ipchains+sparc 450= CRASH!
Rusty Russell writes: > Oops. Thanks to Anton for testing and touching up this patch. > > The 2.0/2.2 setsockopt code used to do the copy_from_user for you... I've applied this to my tree, thanks a lot. 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/
Re: VIA VT82C686X
On Tue, 30 Jan 2001, Byron Stanoszek wrote: > (unless you're overclocking). Setting it to 66 will cause the VIA driver to > believe your PCI bus is running at 66MHz and will program the IDE controller to > run at half the speed to maintain 33MHz. In reality, your controller now runs > at 16. I removed the ide and ata setting. System is running stably as in no kernel crashes, but I am getting daemon and shell crashes. With this current kernel I've had 1 kernel crash in about 3 hours as compared to 1 every 10 or 15 minutes. Crash, reboot, 10 minutes or so crash, reboot. ect ect. I'm wanting to test something else out. I'm wondering if there isn't some hardware issue with the RAM. This particular board will do 1GB of PC133, or 2.5GB of PC100. I'm wondering if there isn't something wrong with how it reads the speed and the appropriate limitation. It's running stably if I only run 768MB of PC133 RAM. But if I run a solid 1GB of PC133 I get segfaults and sig11 crashes constantly. All the RAM has been professionally tested and certified. Any clues would be appreciated. David - 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] vma limited swapin readahead
Hi, The current swapin readahead code reads a number of pages (1 >> page_cluster) which are physically contiguous on disk with reference to the page which needs to be faulted in. However, the pages which are contiguous on swap are not necessarily contiguous in the virtual memory area where the fault happened. That means the swapin readahead code may read pages which are not related to the process which suffered a page fault. I've changed the swapin code to not readahead pages if they are not virtually contiguous on the vma which is being faulted to avoid the problem described above. Testers are very welcome since I'm unable to test this in various workloads. The patch is available at http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre10/swapin_readahead.patch - 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.x and SMP fails to compile (`current' undefined)
Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP? -d Stephen Frost wrote: > * David Ford ([EMAIL PROTECTED]) wrote: > > A person just brought up a problem in #kernelnewbies, building an SMP > > kernel doesn't work very well, current is undefined. I don't have more > > time to debug it but I'll strip the config and put it up at > > http://stuph.org/smp-config > > They're trying to compile SMP for Athlon/K7 (CONFIG_MK7=y). -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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/
[BUG] 2.4.1 Detects 64 MB RAM, actual 192MB
2.4.1 detects 64 MB, but 2.4.0 detects 192 (Maybe 191, not sure). dmesg attached. Linux version 2.4.1 (root@tabriel) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #9 Tue Jan 30 15:35:21 EST 2001 BIOS-provided physical RAM map: BIOS-88: 0009f000 @ (usable) BIOS-88: 03ff @ 0010 (usable) On node 0 totalpages: 16624 zone(0): 4096 pages. zone(1): 12528 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=k241 ro root=341 Initializing CPU#0 Detected 598.848 MHz processor. Console: colour VGA+ 132x43 Calibrating delay loop... 1196.03 BogoMIPS Memory: 63276k/66496k available (961k kernel code, 2832k reserved, 321k data, 204k 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: Before vendor init, caps: 0081f9ff c0c1f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After vendor init, caps: 0081f9ff c0c1f9ff CPU: After generic, caps: 0081f9ff c0c1f9ff CPU: Common caps: 0081f9ff c0c1f9ff CPU: AMD-K7(tm) Processor stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfb470, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket DMI 2.2 present. 39 structures occupying 1001 bytes. DMI table at 0x000F0800. BIOS Vendor: Award Software International, Inc. BIOS Version: 6.0 PG BIOS Release: 11/23/99 Board Vendor: MICRO-STAR INTERNATIONAL CO., LTD. Board Name: MS-6167 (AMD751). Board Version: 1.X. apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14) Starting kswapd v1.8 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 16 0x378: readIntrThreshold is 16 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x10 cfgB=0x48 0x378: ECP settings irq=7 dma= parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,EPP,ECP] parport0: irq 7 detected parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) pty: 256 Unix98 ptys configured lp0: using parport0 (polling). block: queued sectors max/low 41821kB/13940kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx AMD7409: IDE controller on PCI bus 00 dev 39 AMD7409: chipset revision 3 AMD7409: not 100% native mode: will probe irqs later AMD7409: disabling single-word DMA support (revision < C4) ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio hda: WDC AC28400R, ATA DISK drive hdb: IBM-DHEA-38451, ATA DISK drive hdc: TOSHIBA DVD-ROM SD-M1202, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 16514064 sectors (8455 MB) w/512KiB Cache, CHS=1027/255/63, UDMA(33) hdb: 16514064 sectors (8455 MB) w/472KiB Cache, CHS=1027/255/63, UDMA(33) Partition check: /dev/ide/host0/bus0/target0/lun0: p1 /dev/ide/host0/bus0/target1/lun0: p1 p2 < p5 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Real Time Clock Driver v1.10d ppdev: user-space parallel port driver Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 28M agpgart: Detected AMD Irongate chipset agpgart: AGP aperture is 32M @ 0xd800 usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.251 $ time 15:34:20 Jan 30 2001 usb-uhci.c: High bandwidth mode enabled usb.c: registered new driver usbscanner scanner.c: USB Scanner support registered. usb.c: registered new driver usblp usb.c: registered new driver rio500 rio500.c: USB Rio support registered. 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 4096 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED]) devfs: devfs_debug: 0x0 devfs: boot_options: 0x0 VFS: Mounted root (ext2 filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 204k freed Adding Swap: 136512k swap-space (priority -1)
[2.4.1] mkreiserfs on loopdevice freezes kernel
Hello,
if I run mkreiserfs on a 32megablocks /dev/loop0 it will lock up while
generating the journaling information. Sometimes at 20% sometimes at 60%.
Since mkreiserfs is not using the kernel module i guess this is a loop
device problem in 2.4.1 kernels.
There is no dmesg message at the lookup. mkreiserfs is in state 'D'. The
system issomewhat useable (X) but some programs just lock in syscalls (no su
or login possible).
If I run losetup -d /dev/loop0 on that device i will get a message that it
is busy, but the program will not return enymore. It is in 'D' also.
This is an unecncrypted loop device on a ext2 filesystem on a AIC-7861. Loop
is autoloaded as a module.
Wanted to try reiserfs with some verbose debugging for some time. Well,
perhaps md is my friend...
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
-
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] 2.4.1 find_page_nolock fixes
On Tue, 30 Jan 2001, Rik van Riel wrote: > Hi Linus, > > the patch below contains 3 small changes to mm/filemap.c: > > 1. replace the aging in __find_page_nolock() with setting >PageReferenced(), otherwise a large number of small >reads from (or writes to) a page can drive up the page >age unfairly > > 2. remove the wakeup of kswapd from __find_page_nolock(), >the wakeup condition is complex and leaving out the >wakeup has no influence on any workload I tested in >the last few weeks > > 3. add a __find_page_simple(), which is like __find_page_nolock() >but only needs 2 arguments and doesn't touch the page ... this >can be used by IO clustering and other things that really don't >want to influence page aging, removing the 3rd argument also >keeps things simple The swapin readahead still makes the page referenced bit set, and it should not as we discussed previously. - 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+ipchains+sparc 450= CRASH!
In message <01013014063301.15042@Petete> you write:
> I use kernel 2.4.0 + ipchains compatibilty. I use ipchains 1.3.9
>
> This code:
>
> ipchains -A input -p tcp --dport 80 -s 192.168.0.35 -j REDIRECT 81
Oops. Thanks to Anton for testing and touching up this patch.
The 2.0/2.2 setsockopt code used to do the copy_from_user for you...
Rusty.
PS. No security worries, as you need CAP_NET_ADMIN for this...
--
Premature optmztion is rt of all evl. --DK
diff -ru --exclude-from=exclude linux/net/ipv4/netfilter/ip_fw_compat.c
linux_work/net/ipv4/netfilter/ip_fw_compat.c
--- linux/net/ipv4/netfilter/ip_fw_compat.c Wed Jan 31 14:47:42 2001
+++ linux_work/net/ipv4/netfilter/ip_fw_compat.cWed Jan 31 14:43:23 2001
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -198,14 +199,28 @@
return NF_ACCEPT;
}
-extern int ip_fw_ctl(int optval, void *user, unsigned int len);
+extern int ip_fw_ctl(int optval, void *m, unsigned int len);
static int sock_fn(struct sock *sk, int optval, void *user, unsigned int len)
{
+ /* MAX of:
+ 2.2: sizeof(struct ip_fwtest) (~14x4 + 3x4 = 17x4)
+ 2.2: sizeof(struct ip_fwnew) (~1x4 + 15x4 + 3x4 + 3x4 = 22x4)
+ 2.0: sizeof(struct ip_fw) (~25x4)
+
+ We can't include both 2.0 and 2.2 headers, they conflict.
+ Hence, 200 is a good number. --RR */
+ char tmp_fw[200];
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- return -ip_fw_ctl(optval, user, len);
+ if (len > sizeof(tmp_fw) || len < 1)
+ return -EINVAL;
+
+ if (copy_from_user(_fw, user, len))
+ return -EFAULT;
+
+ return -ip_fw_ctl(optval, _fw, len);
}
static struct nf_hook_ops preroute_ops
-
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.1 doesn't boot on athlon
Hi, Compiled 2.4.1 with the same options as 2.4.0, it hangs right after "Freed kernel memory: 228k". If needed: Kernel config avaible @ http://nriaz.resnet.rutgers.edu/~bleh/kernel-config-2.4.1.gz Computer config @ http://nut.dhs.org/mycomputer.php3 Thanks in advance. -- Nadeem - 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.1 with pppd 2.4.0: log problem
Hi. It worked without any problems with 2.4.0. Now with 2.4.1 I
don't get anymore the usual messages in /var/log/messages (like
pppd start and local and remote IP). The only change was the
addition of devfs, but I don't think it's causing this problem.
Any hints? I didn't change anything on my machine.
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
user-mode port 0.38-2.4.1
The user-mode port of 2.4.1 is available. I added support for attaching file descriptors and pts devices to UML serial lines and consoles, plus specifying input and output channels separately. 'no-xterm' can now be duplicated with 'con0=fd:0,fd:1 con=pty'. There is now page dirty and access bit support. Fixed various bugs - gdb is now told where the binary really is, rather than assuming that it is ./linux, kreiserfsd now exits correctly, rather than hanging the system when it returns, and a recursively segfaulting process no longer crashes the system. Several more symbols were exported. The project's home page is http://user-mode-linux.sourceforge.net Downloads are available at http://sourceforge.net/project/filelist.php?group_id =429 and ftp://ftp.nl.linux.org/pub/uml/ Jeff - 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: Disk is cheap?
On Tue, Jan 30, 2001 at 06:58:22PM -, mirabilos wrote: > I accept donations in IDE and SCSI, as well as parport devices. I have a parport device (one of the few things left from my XT). I can send it to you if you pay shipping. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: Saints should always be judged guilty until they are proven innocent. - George Orwell - 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: VIA VT82C686X
Me too. But I couldn't get UDMA 66 after changing my BIOS
settings and booting. With 33 it's very stable (what I used
with 2.4.0). A diff:
-hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(33)
+hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
...
+hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
+hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
VFS: Mounted root (ext2 filesystem) readonly.
-Freeing unused kernel memory: 200k freed
+Freeing unused kernel memory: 204k freed
+hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
+hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
+hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
+hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
+hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
+hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
+hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
+hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
+ide0: reset: success
I know this is a known issue, but I thought testing would be
OK. ASUS K7V with the shipped cable.
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Crash using DRI with 2.4.0 and 2.4.1
This is fixed in the -ac series against 2.4.0, from I think -ac2. I don't think the fix made the mainstream kernel yet. -- /* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */ #include "stddiscl.h" - 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: VIA VT82C686X
On Tue, 30 Jan 2001, David D.W. Downey wrote: > > Woohoo! Just found out that ATA66 on the VIA aint too great. > > I set the kernel boot options idebus=66 ide0=ata66 enabling ATA66 > according to dmesg. The HDD is a WDC UDMA100 30.5GB drive. I retried the The 'idebus=xx' parameter doesn't refer to the speed of the IDE drive, but instead the speed of the PCI bus. On the VIA686, that speed should always be 33 (unless you're overclocking). Setting it to 66 will cause the VIA driver to believe your PCI bus is running at 66MHz and will program the IDE controller to run at half the speed to maintain 33MHz. In reality, your controller now runs at 16. I believe v3.20 of the via82cxxx.c driver disallows any setting lower than 20 or higher than 50. AFAIK the driver auto-selects the speed of your drive based on how it is configured in the BIOS, and whether you have the 40- or 80-wire cable. The 'ide0=ata66' option should not be necessary. To others, I've been running this driver with both a KX133 and a KT133 (both via686a) for quite some time now and have never seen any problems. Just make sure 'idebus=xx' matches the speed of your PCICLK as shown in the bios and you'll be fine (Default is 33). Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [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/
Re: 2.4.x and SMP fails to compile (`current' undefined)
* David Ford ([EMAIL PROTECTED]) wrote: > A person just brought up a problem in #kernelnewbies, building an SMP > kernel doesn't work very well, current is undefined. I don't have more > time to debug it but I'll strip the config and put it up at > http://stuph.org/smp-config They're trying to compile SMP for Athlon/K7 (CONFIG_MK7=y). Stephen PGP signature
Kernel 2.2.18: Protocol 0008 is buggy
Hello, I have a customer who's getting tons of these msgs in his LOGs: kernel: protocol 0008 is buggy, dev hdlc0 kernel: protocol 0608 is buggy, dev hdlc0 The msg comes from net/core/dev.c, and this device is using the Cisco HDLC protocol in drivers/net/hdlc.c . However, AFAIK, 0008 and 0608 represent IP and ARP (respectively), not Cisco HDLC. So ... What I'd like to know is: what exactly causes this msg?? It seems that it's printed when someone sends a packet without properly setting skb->nh.raw first, but who's supposed to set skb->nh.raw?? The HW driver?? The data link (HDLC) driver?? The kernel protocol drivers? How should I go about fixing this problem, where should I start?? I'm at a total loss here. Any help would be really appreciated. Later, Ivan - 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/
VIA VT82C686X
Woohoo! Just found out that ATA66 on the VIA aint too great. I set the kernel boot options idebus=66 ide0=ata66 enabling ATA66 according to dmesg. The HDD is a WDC UDMA100 30.5GB drive. I retried the dd if=/dev/hda7 of=/tmp/testing2.img bs=1024k count=2000 on one VT, ran renice -20 on the dd process then ran procinfo on another and top on a 3rd. I logged into a fourth and ran sync;sync;sync;sync;sync. After @30 seconds the machine became totally unresponsive, locking up all but the current VT. I let it sit there and waited until the dd finished in case the renice was what killed the control. When dd finished I tried running any type of command but the tty was completely frozen. All other VTs were non responsive as well. This is gonna be fun when I test the Promise controller. hehe David D.W. Downey - 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.x and SMP fails to compile (`current' undefined)
A person just brought up a problem in #kernelnewbies, building an SMP kernel doesn't work very well, current is undefined. I don't have more time to debug it but I'll strip the config and put it up at http://stuph.org/smp-config -d -- There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum - 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: unresolved symbol in 2.4.1 depmod.
On Tue, 30 Jan 2001 18:27:40 -0500, [EMAIL PROTECTED] wrote: >In article <[EMAIL PROTECTED]> you write: >> On Tue, 30 Jan 2001 14:15:20 -0600 (CST), >> Jason Michaelson <[EMAIL PROTECTED]> wrote: >> >Greetings. I've just procured myself a copy of 2.4.1, and tried to build >> >it. At the tail end of a make modules_install, the following error occurs: >> > >> >depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/drivers/md/md.o >> >depmod: name_to_kdev_t >> >> name_to_kdev_t is defined in init/main.c. It is not exported so it >> cannot be called from modules. name_to_kdev_t *cannot* be exported >> because it is defined as __init, the code has gone by the time the >> module is loaded. Ask the md maintainer for a fix. > >How did this used to work, then? The call to name_to_kdev_t has been >in the md code since (according to the code comments) May, 2000; the >module worked fine as of 2.4.1-pre10, which is the last version I used. It might have worked as built in code, I would be astounded if it ever worked as a module on a standard kernel after that code was added. name_to_kdev_t has been defined as this since at least 2.4.0-test1. kdev_t __init name_to_kdev_t(char *line) You cannot export a symbol marked __init and expect it to work. - 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: Multiple SCSI host adapters, naming of attached devices
Michael Pacey writes: > But it looks like I can change the order in driver/scsi/hosts.c, though > this is not an elegant solution :( You can compile the "primary (rootfs)" adapter into the kernel, and load the second adapter as a module. This is supposed to work. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todowith ECN)
> > How does ZC/SG change the nature of the packets presented to the NIC? > > what do you mean? I am _sure_ you know how SG/ZC work. So i am suspecting > more than socratic view on life here. Could be influence from Aristotle;-> Well, I don't know the specifics of Linux, but I gather from what I've read on the list thusfar, that prior to implementing SG support, Linux NIC drivers would copy packets into single contiguous buffers that were then sent to the NIC yes? If so, the implication is with SG going, that copy no longer takes place, and so a chain of buffers is given to the NIC. Also, if one is fully ZC :) pesky things like protocol headers can naturally end-up in separate buffers. So, now you have to ask how well any given NIC follows chains of buffers. At what number of buffers is the overhead in the NIC of following the chains enough to keep it from achieving link-rate? One way to try and deduce that would be to meld some of the SG and preSG behaviours and copy packets into varying numbers of buffers per packet and measure the resulting impact on throughput through the NIC. rick jones As time marches on, the orders of magnitude of the constants may change, but basic concepts still remain, and the "lessons" learned in the past by one generation tend to get relearned in the next :) for example - there is no such a thing as a free lunch... :) -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... - 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: Multiple SCSI host adapters, naming of attached devices
On Wed, 31 Jan 2001 01:05:51 Andreas Dilger wrote: > > If you are using ext2 filesystems, you don't care which is which, because > you can mount by filesystem UUID or LABEL, so just ignore the device > names. > The same is true with LVM. Well, I tried changing the order of driver loading in driver/scsi/hosts.c after reading something on the web but that didn't work. Then I tried what you (and another kind soul) suggested, i.e. mount by label, and the machine fails to mount the / filesystem read-write on boot, though I can do it manually. This is a Debian potato system. Well, I'm tired and I've had too much wine and whisky so I am going to bed, but I will attack this afresh tomorrow night... Thanks for the advice, perhaps I'll need more tomorrow :) -- Michael Pacey [EMAIL PROTECTED] ICQ: 105498469 wd21 ltd - world domination in the 21st century - 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: bttv problems in 2.4.0/2.4.1
On Tue, 30 Jan 2001, adrian wrote: >I have a bt848 based video capture card, and get near the same results: > 2.4.0-test10 through 2.4.1 all lock when i2c registers the device. The > card has its own interrupt. With 2.2.18, the card initialized and the > kernel continued to boot. Interesting. 2 questions: What card in particular do you have? What version of the bttv drivers were you using in 2.4.0-test10? It comes with 0.7.38; did you patch it to a higher version? -- -Matt Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson - 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: VT82C686A corruption with 2.4.x
OK, just completed the upgrade to 2.4.1-pre12 + via82c.diff. SYSTEM SPECS CHANGES === Shut off ACPI Shut off 2nd IDE controller in BIOS Shut off APM Disabled UDMA support in BIOS Removed 256MB RAM (768M total RAM) * Everything is running stabler now. Here's what I've got set up right now. VIA SUPPORT 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 PROMISE SUPPORT === PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. DMESG - VIA == PCI: Using IRQ router VIA [1106/0686] at 00:07.0 System Vendor: VIA Technologies, Inc.. VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB DD TESTING == [root@timberwolf /root]# dd if=/dev/hda7 of=/tmp/testing.img bs=1024k count=20002000+0 records in 2000+0 records out [root@timberwolf /root]# ls -al /tmp/testing.img -rw-r--r--1 root root 2097152000 Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# ls -alh /tmp/testing.img -rw-r--r--1 root root 2.0G Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# I'm also attaching a ksyms dump. David D.W. Downey Address SymbolDefined by f286a060 advansys_proc_info[advansys] f286a060 __insmod_advansys_S.text_L60896 [advansys] f286caf0 advansys_reset[advansys] f286c770 advansys_abort[advansys] f286c660 advansys_command [advansys] f286a58c advansys_detect [advansys] f286d084 advansys_biosparam[advansys] f287b0e0 __insmod_advansys_S.data_L15488 [advansys] f287ef00 __insmod_advansys_S.bss_L128 [advansys] f2878e60 __insmod_advansys_S.rodata_L8808 [advansys] f286c350 advansys_release [advansys] f286c698 advansys_queuecommand [advansys] f286a000 __insmod_advansys_O/lib/modules/2.4.1-pre12/kernel/drivers/scsi/advansys.o_M3A761A3A_V132097 [advansys] f286c444 advansys_info [advansys] f286d10c advansys_setup
2.4.X inode cache bug
Excuse me for the lack of patch in this mail, but I'm currently suffering some connection-troubles... Please Cc replies to me. In 2.4.x, linux/fs/inode.c has a hash() function with a small slip-up. The inode hash-value is initialized with "unsigned long tmp = i_ino | ((unsigned long) sb / L1_CACHE_BYTES);". The intention seems to be to take some cache-affinity from the extra operations, but it isn't working. I believe this is a slip-up, because you should NEVER use bitwise-or in a hash formula. This creates a slanted distribution, and depending on the address of the superblock block, can cause severe inefficiency in the code. Just replacing the | with ^ imroves hash-table efficiency noticeably, making a clear difference in system profiling and seems to improve system responsiveness during disk-I/O tremendously. Ofcourse, this is not perfect for cache coverage, but I doubt the cache-coverage for bucket heads has any practical effect with the extra instructions calculating it requires. Might be a good excuse to look into that quadratic hash too ;) Please correct this asap, as it can cause severe performance degradation for things like news-servers compared to 2.2 series. Ps. speaking of function profiling, linux/drivers/char/console.c:do_con_write() prohibits the IRQ's for far too long while. This makes it impossible to tell if the code within is inefficient by profiling, but also wreaks havoc with any timing critical code (Such as, network routing...) because something as innocent as writing long strings to console can lock things for while. On top of that the spin-lock logic for this fuction is solid, since some nominally non-re-entrant code remains outside the spinlock! Hopefully somebody more knowledgeabe in the console control-flow will take a swipe at making the (IRQ-masked) critical-section one-character long at most. -Donwulff - 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: bttv problems in 2.4.0/2.4.1
Hmmm, I have a bt848 based video capture card, and get near the same results: 2.4.0-test10 through 2.4.1 all lock when i2c registers the device. The card has its own interrupt. With 2.2.18, the card initialized and the kernel continued to boot. Interesting. Regards, Adrian On Tue, 30 Jan 2001, Prasanna P Subash wrote: > I have experienced similar issues with 2.4.0 and its test. I have a bttv848 chipset. > I even tried compiling in kdb as a part of the kernel to see if it oopses, but no >luck. > > I will try trying 0.7.47 today. > > this works on 2.2.16, last time i tried. > > -- > Prasanna Subash --- [EMAIL PROTECTED] --- TurboLinux, INC > > Linux, the choice | "You've got to think about tomorrow!" > of a GNU generation -o) | "TOMORROW! I haven't even prepared for > Kernel 2.4.0-ac4 /\\ | yesterday* yet!" > on a i686_\\_v | >| > > > On Tue, Jan 30, 2001 at 07:53:11PM -0500, John Jasen wrote: > > On Tue, 30 Jan 2001, Matthew Gabeler-Lee wrote: > > > > > These errors all occur in the same way (as near as I can tell) in > > > kernels 2.4.0 and 2.4.1, using bttv drivers 0.7.50 (incl. w/ kernel), > > > 0.7.53, and 0.7.55. > > > > > > I am currently using 2.4.0-test10 with bttv 0.7.47, which works fine. > > > > > > I have sent all this info to Gerd Knorr but, as far as I know, he hasn't > > > been able to track down the bug yet. I thought that by posting here, > > > more eyes might at least make more reports of similar situations that > > > might help track down the problem. > > > > Try flipping the card into a different slot. A lot of the cards > > exceptionally do not like IRQ/DMA sharing, and a lot of the motherboards > > share them between different slots. > > > > -- > > -- John E. Jasen ([EMAIL PROTECTED]) > > -- In theory, theory and practise are the same. In practise, they aren't. > > > > - > > 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/ > > > - 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: Crash using DRI with 2.4.0 and 2.4.1
Miguel Rodriguez Perez <[EMAIL PROTECTED]> writes: > Hi, I have a Matrox G200 card installed on an Ali motherboard. > Sometimes when I use any opengl program my box crashes. It is more > likely that it will crash if I have used the xvideo extension or the > matroxfb, but this is not a must, it simply increases the chance of > a crash, which is very high anyway. > I have tried both 2.4.0 and 2.4.1 kernels with Xfree 4.0.2 both with > the same results. Are you sure you get the same results with 2.4.1? I'm in the exact same position (G200 on a Gigabyte GA5AX with ALi M1541/3). There was a patch to properly support AGP on these boards which went in between 2.4.0 and 2.4.1 which solved the problem for me (at least in 2.4.0; I haven't tested DRI throughly in 2.4.1 yet). -- Adam Sampson [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/
Re: [NFS] Linux 2.2.18 nfs v3 server bug (was: Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export)
On Thursday January 25, [EMAIL PROTECTED] wrote: > On Wed, 24 Jan 2001, Matthias Andree wrote: > > > This looks better and it makes FreeBSD able to ls the directory, and on > > touch /mnt/try, I get EROFS on the client, so this is okay; however, the > > access reply does not include EXECUTE permissions which I find strange, > > since the client lists this: > > > > My fault. NFSv3 has a different permission partitioning than local file > systems have, I did not see that. So Linux does the right > thing for ACCESS with Neil's patch. Neil, could you submit that patch to > Alan or bless it for inclusion into 2.2.19(pre)? The FreeBSD people > could then sleep well again. :-) I have sent bunch of patches to Alan some weeks ago, but no 2.2.19pre release has appeared since. When the 2.2.19pre series gets going again, I will certainly sent this patch, and a few others that I have collected. NeilBrown - 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: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing to dowith ECN)
On Tue, 30 Jan 2001, Rick Jones wrote: > > ** I reported that there was also an oddity in throughput values, > > unfortunately since no one (other than me) seems to have access > > to a gige cards in the ZC list, nobody can confirm or disprove > > what i posted. Here again as a reminder: > > > > Kernel | tput | sender-CPU | receiver-CPU | > > - > > 2.4.0-pre3 | 99MB/s | 87% | 23% | > > NSF||| | > > - > > 2.4.0-pre3 | 86MB/s | 100% | 17% | > > SF ||| | > > - > > 2.4.0-pre3 | 66.2 | 60% | 11% | > > +ZC| MB/s || | > > - > > 2.4.0-pre3 | 68 | 8% | 8% | > > +ZC SF| MB/s || | > > - > > > > Just ignore the CPU readings, focus on throughput. And could someone plese > > post results? > > In the spirit of the socratic method :) ;-> > > Is your gige card based on Alteon? Yes, sir, it is. To be precise: ** Sender: SMP-PII-450Mhz, ASUS m/board; 3com version of acenic - 1M version ** receiver: same hardware; acenic alteon card - 1M version > How does ZC/SG change the nature of the packets presented to the NIC? what do you mean? I am _sure_ you know how SG/ZC work. So i am suspecting more than socratic view on life here. Could be influence from Aristotle;-> > How well does the NIC do with that changed nature? > Hard question to answer ;-> I havent done any analysis at that level cheers, jamal - 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: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
In article <[EMAIL PROTECTED]> you wrote: > On Tue, Jan 30, 2001 at 02:17:57PM -0800, David S. Miller wrote: > 8.5MB/sec sounds like half-duplex 100baseT. > No; I'm 100% its FD; HD gives 40k/sec TCP because of collisions and > such like. > Positive you are running at full duplex all the way to the > netapp, and if so how many switches sit between you and this > netapp? > It's FD all the way (we hardwire everything to 100-FD and never trust > auto-negotiate); I see no errors or such like anywhere. > There are ... ... 3 switches between four switches in > between, mostly linked via GE. I'm not sure if latency might be an > issue here, is it was critical I can imagine 10 km of glass might be > a problem but it's not _that_ far... > --cw > - > 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/ > --- >Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste. > Antworten nur per Mail an die im Reply-To-Header angegebene Adresse. >Fragen zum Gateway -> [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/
Re: Request: increase in PCI bus limit
He's probably sending it to the list the same reason why most in tech circles do. To cut down on the amount of work required. Personally I would love to have all my custom changes put into a 'standard' distribution that way I wouldn't need to keep as many custom notes for x,y,z platforms or what-else. Also for the fact that it gives something back (generally if I run into a situation there is a good chance that someone else will run into it as well, so if I can make _his_ life easier if he doesn't have the same knowledge it's worth it). Steve - Original Message - From: "Timur Tabi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 30, 2001 18:36 Subject: Re: Request: increase in PCI bus limit > ** Reply to message from Christopher Neufeld <[EMAIL PROTECTED]> on Tue, 30 > Jan 2001 16:08:32 -0800 > > > > Would it be possible to bump it up to 128, or even > > 256, in later 2.4.* kernel releases? That would allow this customer to > > work with an unpatched kernel, at the cost of an additional 3.5 kB of > > variables in the kernel. > > I don't think that's going to happen. If we did this for your obscure system, > then we'd have to do it for every obscure system, and before you know it, the > kernel is 200KB larger. > > Besides, why is your client afraid of patched kernels? It sounds like a very > odd request from someone with a linuxcare.com email address. I would think that > you'd WANT to provide patched kernels so that the customer can keep paying you > (until they learn how to use a text editor, at which point they can patch the > kernel themselves!!!) > > > -- > Timur Tabi - [EMAIL PROTECTED] > Interactive Silicon - http://www.interactivesi.com > > When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. > > - > 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/ > - 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: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todo with ECN)
On Wed, 31 Jan 2001, Ingo Molnar wrote: > > On Tue, 30 Jan 2001, jamal wrote: > > > > - is this UDP or TCP based? (UDP i guess) > > > > > TCP > > well then i'd suggest to do: > > echo 10 10 10 > /proc/sys/net/ipv4/tcp_wmem > > does this make any difference? According to my notes, i dont see this. however, 262144 into /proc/sys/net/core/*mem_max/default. I have access to my h/ware this weekend. Hopefully i should get something better than ttcp to use. cheers, jamal - 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: Request: increase in PCI bus limit
In article <[EMAIL PROTECTED]> you wrote: > I guess the cleanest solution would be to allow variable setting of the > maximum number of PCI busses in the config file, similar to the > CONFIG_UNIX98_PTY_COUNT setting, so that "exotic" users with 32+ PCI > busses can boost the standard value according to their needs, without > having to increase kernel size for the normal users. May even decrease the kernel for systems < 4 busses. - 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: Request: increase in PCI bus limit
In article <[EMAIL PROTECTED]> you wrote:
> 256, in later 2.4.* kernel releases? That would allow this customer to
> work with an unpatched kernel, at the cost of an additional 3.5 kB of
> variables in the kernel.
Don't think this is fairly common. So especially since I consider that kind of
hardware (what is it) to require finetuning ("enterprise kernel") anyway,
there is no real gain out of it, as long as the structure is not dynamically.
Is that some kind of file server or masspar system? Intel?
Greetings
Bernd
-
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: Multiple SCSI host adapters, naming of attached devices
On Wed, 31 Jan 2001 01:05:51 Andreas Dilger wrote: > If you are using ext2 filesystems, you don't care which is which, because > you can mount by filesystem UUID or LABEL, so just ignore the device > names. > The same is true with LVM. > > Cheers, Andreas Well, I do care... This machine is confusing it's root filesystem with an external SCSI disk. But it looks like I can change the order in driver/scsi/hosts.c, though this is not an elegant solution :( Trying it now -- Michael Pacey [EMAIL PROTECTED] ICQ: 105498469 wd21 ltd - world domination in the 21st century - 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: VT82C686A corruption with 2.4.x
OK, here is the output of lspci -v on the SMP box I'm having trouble with as requested... 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 - 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/
OT: mount/umount doesn't track used resources correctly?
I am having trouble removing the usbide module which enables me to access my USB external hard drive. I think the problem may be due to usermode tools not handling the new "mount multiple devices to a single mount point" feature, but I'm not sure. Here was my mount configuration for /dev/pda devices (the partitions on my USB BusLink drive) before I unmounted all these partitions: /dev/pda8 201601620 1913584 0% /mnt/pda8 /dev/pda8 201601620 1913584 0% /mnt/pda9 /dev/pda9 201601620 1913584 0% /mnt/pda9 Currently, mount shows: /dev/hda7 on / type ext2 (rw) none on /proc type proc (rw) none on /dev/pts type devpts (rw,mode=0620) /dev/hda8 on /home type ext2 (rw) /dev/hda1 on /mnt/Win98 type vfat (rw,nosuid,nodev,umask=0) none on /proc/bus/usb type usbdevfs (rw) Any ideas? Miles - 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: bttv problems in 2.4.0/2.4.1
I have experienced similar issues with 2.4.0 and its test. I have a bttv848 chipset. I even tried compiling in kdb as a part of the kernel to see if it oopses, but no luck. I will try trying 0.7.47 today. this works on 2.2.16, last time i tried. -- Prasanna Subash --- [EMAIL PROTECTED] --- TurboLinux, INC Linux, the choice | "You've got to think about tomorrow!" of a GNU generation -o) | "TOMORROW! I haven't even prepared for Kernel 2.4.0-ac4 /\\ | yesterday* yet!" on a i686_\\_v | | On Tue, Jan 30, 2001 at 07:53:11PM -0500, John Jasen wrote: > On Tue, 30 Jan 2001, Matthew Gabeler-Lee wrote: > > > These errors all occur in the same way (as near as I can tell) in > > kernels 2.4.0 and 2.4.1, using bttv drivers 0.7.50 (incl. w/ kernel), > > 0.7.53, and 0.7.55. > > > > I am currently using 2.4.0-test10 with bttv 0.7.47, which works fine. > > > > I have sent all this info to Gerd Knorr but, as far as I know, he hasn't > > been able to track down the bug yet. I thought that by posting here, > > more eyes might at least make more reports of similar situations that > > might help track down the problem. > > Try flipping the card into a different slot. A lot of the cards > exceptionally do not like IRQ/DMA sharing, and a lot of the motherboards > share them between different slots. > > -- > -- John E. Jasen ([EMAIL PROTECTED]) > -- In theory, theory and practise are the same. In practise, they aren't. > > - > 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/ PGP signature
Re: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todo with ECN)
On Tue, 30 Jan 2001, jamal wrote: > > - is this UDP or TCP based? (UDP i guess) > > > TCP well then i'd suggest to do: echo 10 10 10 > /proc/sys/net/ipv4/tcp_wmem does this make any difference? Ingo - 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: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing to dowith ECN)
> ** I reported that there was also an oddity in throughput values, > unfortunately since no one (other than me) seems to have access > to a gige cards in the ZC list, nobody can confirm or disprove > what i posted. Here again as a reminder: > > Kernel | tput | sender-CPU | receiver-CPU | > - > 2.4.0-pre3 | 99MB/s | 87% | 23% | > NSF||| | > - > 2.4.0-pre3 | 86MB/s | 100% | 17% | > SF ||| | > - > 2.4.0-pre3 | 66.2 | 60% | 11% | > +ZC| MB/s || | > - > 2.4.0-pre3 | 68 | 8% | 8% | > +ZC SF| MB/s || | > - > > Just ignore the CPU readings, focus on throughput. And could someone plese > post results? In the spirit of the socratic method :) Is your gige card based on Alteon? How does ZC/SG change the nature of the packets presented to the NIC? How well does the NIC do with that changed nature? rick jones sometimes, performance tuning is like squeezing a balloon. one part gets smaller, but then you start to see the rest of the balloon... -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... - 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: bttv problems in 2.4.0/2.4.1
On Tue, 30 Jan 2001, John Jasen wrote: > On Tue, 30 Jan 2001, Matthew Gabeler-Lee wrote: > > > These errors all occur in the same way (as near as I can tell) in > > kernels 2.4.0 and 2.4.1, using bttv drivers 0.7.50 (incl. w/ kernel), > > 0.7.53, and 0.7.55. > > > > I am currently using 2.4.0-test10 with bttv 0.7.47, which works fine. > > > > I have sent all this info to Gerd Knorr but, as far as I know, he hasn't > > been able to track down the bug yet. I thought that by posting here, > > more eyes might at least make more reports of similar situations that > > might help track down the problem. > > Try flipping the card into a different slot. A lot of the cards > exceptionally do not like IRQ/DMA sharing, and a lot of the motherboards > share them between different slots. I will try this, but my card has (and does) worked with irq sharing for a long time. Its entry in /proc/interrupts: 9: 164935 165896 IO-APIC-level acpi, bttv I find it strange that a driver that had worked with shared interrupts for a long time would suddenly cease to function with shared interrupts, and would consider this a bug. I will try changing the slot, but getting it to not share interrupts will be difficult considering the number of pci devices I have. -- -Matt Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson - 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: Multiple SCSI host adapters, naming of attached devices
Michael Pacey writes: > Given two host adapters each with 1 disk of ID 0, how do I tell Linux which > is sda and which sdb? You can't - you need to make sure either the cards are different and check the SCSI host probe order, or the detection order in the PCI bus. You should only need to do this once, and simply use the order you get. > After this I'll be filling the 2nd SCSI chain completely, so assigning a > different ID is not an option. If you are using ext2 filesystems, you don't care which is which, because you can mount by filesystem UUID or LABEL, so just ignore the device names. The same is true with LVM. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todo with ECN)
On Wed, 31 Jan 2001, Ingo Molnar wrote: > > On Tue, 30 Jan 2001, jamal wrote: > > > Kernel | tput | sender-CPU | receiver-CPU | > > - > > 2.4.0-pre3 | 99MB/s | 87% | 23% | > > NSF||| | > > - > > 2.4.0-pre3 | 68 | 8% | 8% | > > +ZC SF| MB/s || | > > - > > isnt the CPU utilization difference amazing? :-) > With a caveat, sadly ;-> ttcp uses times() system call (or a diff of times() one at the beggining and another at the end). So the cpu measurements are not reflective. > a couple of questions: > > - is this UDP or TCP based? (UDP i guess) > TCP > - what wsize/rsize are you using? How do these requests look like on the > network, ie. are they suffieciently MTU-sized? yes. writes vary from 8K->64K but not much difference over the long period of time. > > - what happens if you run multiple instances of the testcode, does it > saturate bandwidth (or CPU)? This is something of great interest. I havent tried it. I should. I suspect this would be where the value of the ZC changes will become evident. cheers, jamal - 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: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todo with ECN)
On Tue, 30 Jan 2001, jamal wrote: > Kernel | tput | sender-CPU | receiver-CPU | > - > 2.4.0-pre3 | 99MB/s | 87% | 23% | > NSF||| | > - > 2.4.0-pre3 | 68 | 8% | 8% | > +ZC SF| MB/s || | > - isnt the CPU utilization difference amazing? :-) a couple of questions: - is this UDP or TCP based? (UDP i guess) - what wsize/rsize are you using? How do these requests look like on the network, ie. are they suffieciently MTU-sized? - what happens if you run multiple instances of the testcode, does it saturate bandwidth (or CPU)? Ingo - 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: AGPGART problems with VIA KX133 chipsets under 2.2.18/2.4.0
Congratulations to all involved in fixing the subject problem. With the 2.4.1 kernel, I can now actually use agpgart with my GeForce2 MX on a Tyan S1590S motherboard. Just thought someone might appreciate another data point, because prior to 2.4.1 I had to leave out agpgart support :-(. --Bob [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/
Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing to dowith ECN)
On Mon, 29 Jan 2001, Ion Badulescu wrote: > On Mon, 29 Jan 2001, jamal wrote: > > > > 11.5kBps, quite consistently. > > > > This gige card is really sick. Are you sure? Please double check. > > Umm.. the starfire chipset is 100Mbit only. So 11.5MBps (sorry, that was a > typo, it's mega not kilo) is really all I'd expect out of it. > not good. So far all the tests have been around CPU. The general trend seems to be: - sendfile + ZC good for CPU - write() + ZC not good for CPU (i might have forgotten something from Andrew's results). This happens (even with my bogus cpu measure) to be similar. That seems to be explainable. ** I reported that there was also an oddity in throughput values, unfortunately since no one (other than me) seems to have access to a gige cards in the ZC list, nobody can confirm or disprove what i posted. Here again as a reminder: Kernel | tput | sender-CPU | receiver-CPU | - 2.4.0-pre3 | 99MB/s | 87% | 23% | NSF||| | - 2.4.0-pre3 | 86MB/s | 100% | 17% | SF ||| | - 2.4.0-pre3 | 66.2 | 60% | 11% | +ZC| MB/s || | - 2.4.0-pre3 | 68 | 8% | 8% | +ZC SF| MB/s || | - Just ignore the CPU readings, focus on throughput. And could someone plese post results? cheers, jamal - 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: bttv problems in 2.4.0/2.4.1
On Tue, 30 Jan 2001, Matthew Gabeler-Lee wrote: > These errors all occur in the same way (as near as I can tell) in > kernels 2.4.0 and 2.4.1, using bttv drivers 0.7.50 (incl. w/ kernel), > 0.7.53, and 0.7.55. > > I am currently using 2.4.0-test10 with bttv 0.7.47, which works fine. > > I have sent all this info to Gerd Knorr but, as far as I know, he hasn't > been able to track down the bug yet. I thought that by posting here, > more eyes might at least make more reports of similar situations that > might help track down the problem. Try flipping the card into a different slot. A lot of the cards exceptionally do not like IRQ/DMA sharing, and a lot of the motherboards share them between different slots. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
Chris Wedgwood writes: > There are ... ... 3 switches between four switches in > between, mostly linked via GE. I'm not sure if latency might be an > issue here, is it was critical I can imagine 10 km of glass might be > a problem but it's not _that_ far... Other than this, I don't know what to postulate. Really, most reports and my own experimentation (directly connected Linux knfsd to 2.4.x nfs client) supports the fact that our client can saturate 100baseT rather fully. 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/
Re: Request: increase in PCI bus limit
Christopher Neufeld wrote: > The only patch > which has to be applied to make Linux run stably on these systems is to > increase that limit. Would it be possible to bump it up to 128, or even > 256, in later 2.4.* kernel releases? That would allow this customer to > work with an unpatched kernel, at the cost of an additional 3.5 kB of > variables in the kernel. I guess the cleanest solution would be to allow variable setting of the maximum number of PCI busses in the config file, similar to the CONFIG_UNIX98_PTY_COUNT setting, so that "exotic" users with 32+ PCI busses can boost the standard value according to their needs, without having to increase kernel size for the normal users. Regards, Udo. - 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: Request: increase in PCI bus limit
** Reply to message from Christopher Neufeld <[EMAIL PROTECTED]> on Tue, 30 Jan 2001 16:08:32 -0800 > Would it be possible to bump it up to 128, or even > 256, in later 2.4.* kernel releases? That would allow this customer to > work with an unpatched kernel, at the cost of an additional 3.5 kB of > variables in the kernel. I don't think that's going to happen. If we did this for your obscure system, then we'd have to do it for every obscure system, and before you know it, the kernel is 200KB larger. Besides, why is your client afraid of patched kernels? It sounds like a very odd request from someone with a linuxcare.com email address. I would think that you'd WANT to provide patched kernels so that the customer can keep paying you (until they learn how to use a text editor, at which point they can patch the kernel themselves!!!) -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - 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: Multiple SCSI host adapters, naming of attached devices
Hi, > Given two host adapters each with 1 disk of ID 0, how do I tell Linux which > is sda and which sdb? [...] which leads me to the question: Is there any reason for the (IMHO stupid) "dynamic" naming of SCSI devices (in contrast to e.g. IDE devices or the "physical" device naming used in Solaris)? It may be possible always maintaining the "right" order with one SCSI chain, but as soon as there is a second bus, it is really a pain. Is devfs the only solution? Regards, Wolfgang - 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: Reiserfs problem was: Re: Version 2.4.1 cannot be built.
On Tuesday, January 30, 2001 03:42:36 PM -0800 "Brett G. Person" <[EMAIL PROTECTED]> wrote: > Worked fine here but i am getting segfaults on my Reiser filesystems. > I've been distracted by a project over the last few days. Is what I'm > seeing a symptom of the fs corruption people were talking about last week? > If reiserfs is the cause you should have some clues in /var/log/messages. Does the kernel compile on ext2 on the same box? -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.0: [kswapd+116/272]
On 31 Jan 01 at 0:36, Andreas Ackermann (Acki) wrote: > Jan 29 08:17:39 ane kernel: CPU:0 > Jan 29 08:17:39 ane kernel: EIP:0010:[prune_dcache+24/328] > Jan 29 08:17:39 ane kernel: EFLAGS: 00010216 > Jan 29 08:17:39 ane kernel: Call Trace: [shrink_dcache_memory+33/48] > [do_try_to_free_pages+83/128] [kswapd+116/272] [kernel_thread+40/56] > Jan 29 08:17:39 ane kernel: > > If this tells somebody what it's all about I can provide further > information about system etc. I also can provide three similar excerpts > form my logfile ;-) Is it always in prune_dcache? Which filesystems you have mounted at oops, or just before oops? ncpfs? smbfs? vfat? Thanks, Petr Vandrovec [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/
Re: [ANNOUNCE] Kernel Janitor's TODO list
** Reply to message from Daniel Phillips <[EMAIL PROTECTED]> on Wed, 31 Jan 2001 01:06:08 +0100 > > What is wrong with sleep_on()? > > If you have a task that looks like: > > loop: > > sleep_on(q) > > And you do wakeup(q) hoping to get something important done, then if the > task isn't sleeping at the time of the wakeup it will ignore the wakeup > and go to sleep, which imay not be what you wanted. Ok, so how should this code have been written? -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Kernel Janitor's TODO list
Timur Tabi wrote: > > ** Reply to message from David Woodhouse > > > Note that this is _precisely_ the reason I'm advocating the removal of > > sleep_on(). When I was young and stupid (ok, "younger and stupider") I used > > sleep_on() in my code. I pondered briefly the fact that I really couldn't > > convince myself that it was safe, but because it was used in so many other > > places, I decided I had to be missing something, and used it anyway. > > > > I was wrong. I was copying broken code. And now I want to remove all those > > bad examples - for the benefit of those who are looking at them now and are > > tempted to copy them. > > What is wrong with sleep_on()? If you have a task that looks like: loop: sleep_on(q) And you do wakeup(q) hoping to get something important done, then if the task isn't sleeping at the time of the wakeup it will ignore the wakeup and go to sleep, which imay not be what you wanted. -- Daniel - 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/
Request: increase in PCI bus limit
Hello,
I'm working at a customer site with custom hardware. The 2.4.0 series
kernel almost works out of the box, but the machine has 52 PCI busses.
Plans are to produce a 4-way box which would have over 80 PCI busses. The
file include/asm-i386/mpspec.h allocates space for 32 busses in the
definition of the macro MAX_MP_BUSSES. When 52 busses are probed, some
arrays are filled out past their ends (there is no bounds checking
performed on the array filling), and the kernel oopses out. The only patch
which has to be applied to make Linux run stably on these systems is to
increase that limit. Would it be possible to bump it up to 128, or even
256, in later 2.4.* kernel releases? That would allow this customer to
work with an unpatched kernel, at the cost of an additional 3.5 kB of
variables in the kernel.
Thank you for any help.
For completeness, here's the patch (against 2.4.0):
--- linux-2.4.0/include/asm-i386/mpspec.h.orig Tue Jan 30 16:06:08 2001
+++ linux-2.4.0/include/asm-i386/mpspec.h Tue Jan 30 16:06:21 2001
@@ -157,7 +157,7 @@
*/
#define MAX_IRQ_SOURCES 128
-#define MAX_MP_BUSSES 32
+#define MAX_MP_BUSSES 256
enum mp_bustype {
MP_BUS_ISA = 1,
MP_BUS_EISA,
--
Christopher Neufeld [EMAIL PROTECTED]
Home page: http://caliban.physics.utoronto.ca/neufeld/Intro.html
"Don't edit reality for the sake of simplicity"
-
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: Unresolved symbols
In message <[EMAIL PROTECTED]> you write: > Hi again Rusty God I'm an idiot. I swear I've fixed this before. <>. Yep, I did. And before that, the same bug in the conntrack code. This fixed the `core nat compiled in, rest as modules' case, of course, by actually exporting the symbols. Rusty. -- Premature optmztion is rt of all evl. --DK diff -urN -I \$.*\$ -X /tmp/kerndiff.GyILWe --minimal linux-2.4.0-official/net/ipv4/netfilter/ip_nat_standalone.c working-2.4.0/net/ipv4/netfilter/ip_nat_standalone.c --- linux-2.4.0-official/net/ipv4/netfilter/ip_nat_standalone.c Tue Oct 31 09:27:49 2000 +++ working-2.4.0/net/ipv4/netfilter/ip_nat_standalone.cWed Jan 31 10:50:50 +2001 @@ -330,11 +330,9 @@ module_init(init); module_exit(fini); -#ifdef MODULE EXPORT_SYMBOL(ip_nat_setup_info); EXPORT_SYMBOL(ip_nat_helper_register); EXPORT_SYMBOL(ip_nat_helper_unregister); EXPORT_SYMBOL(ip_nat_expect_register); EXPORT_SYMBOL(ip_nat_expect_unregister); EXPORT_SYMBOL(ip_nat_cheat_check); -#endif - 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/
bttv problems in 2.4.0/2.4.1
In 2.4.0 and 2.4.1, when I try to load the bttv driver, one of two things happens: the system hangs (even alt-sysrq doesn't work!), or the system powers off by itself (ATX mobo). Instant power-off usually happens after a soft reboot (init 6), while it usually hangs up after a hard reboot (power cycling). When it hangs, I noticed a very strange thing. If I push the power on/off button briefly, it un-hangs and seems to proceed as normal. The kernel does report an APIC error on each cpu (dual p3 700 system) when this happens. These errors all occur in the same way (as near as I can tell) in kernels 2.4.0 and 2.4.1, using bttv drivers 0.7.50 (incl. w/ kernel), 0.7.53, and 0.7.55. I am currently using 2.4.0-test10 with bttv 0.7.47, which works fine. I have sent all this info to Gerd Knorr but, as far as I know, he hasn't been able to track down the bug yet. I thought that by posting here, more eyes might at least make more reports of similar situations that might help track down the problem. PS: I'm not on the linux-kernel list, so please CC replies to me. -- -Matt Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson - 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/
Reiserfs problem was: Re: Version 2.4.1 cannot be built.
Worked fine here but i am getting segfaults on my Reiser filesystems. I've been distracted by a project over the last few days. Is what I'm seeing a symptom of the fs corruption people were talking about last week? Brett G. Person 415-358-2656 [EMAIL PROTECTED] Penguin Computing - The World's Most Reliable Linux Systems On Tue, 30 Jan 2001, Rik van Riel wrote: > On Tue, 30 Jan 2001, Richard B. Johnson wrote: > > > The subject says it all. `make dep` is now broken. > > It worked fine here, with 2.4.1 unpacked from the tarball. > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com.br/ > > - > 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/ > - 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/
RAID-cleanups in 2.4.1
I assume I'm not the first one to notice, but the RAID-cleanups that made it into 2.4.1-pre12 (and thus also the final) resulted in "unresolved symbols" when compiling the RAID-stuff as modules (worked fine in 2.4.1-pre11). Any patches/fixes anyone? Ole André - 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/
Oops in 2.4.0: [kswapd+116/272]
Hi folks, using the new Kernel it now occured for the 4th time that I get an Oops some minutes after bootup, with X-Windows running. However, if I get past this 'criticak period' the system seems to run ok (it never crashed a second time although running all day), even when heavily loaded (avifile, mtvp, transfers using samba etc.). Here's the log: ... Jan 29 08:08:25 ane kernel: at 0x300 irq 10 dma 0,0 Jan 29 08:08:25 ane kernel: sb: 1 Soundblaster PnP card(s) found. Jan 29 08:08:25 ane kernel: lirc_serial: compile the serial port driver as module and Jan 29 08:08:25 ane kernel: lirc_serial: make sure this module is loaded first Jan 29 08:08:26 ane kernel: lirc_serial: auto-detected active low receiver Jan 29 08:08:27 ane lpd[212]: restarted Jan 29 08:17:39 ane kernel: printing eip: Jan 29 08:17:39 ane kernel: c013d838 Jan 29 08:17:39 ane kernel: Oops: 0002 Jan 29 08:17:39 ane kernel: CPU:0 Jan 29 08:17:39 ane kernel: EIP:0010:[prune_dcache+24/328] Jan 29 08:17:39 ane kernel: EFLAGS: 00010216 Jan 29 08:17:39 ane kernel: eax: c021903c ebx: c8b929c0 ecx: c8b12000 edx: ff20 Jan 29 08:17:39 ane kernel: esi: c8b12920 edi: c8aff800 ebp: 0d8d esp: cbfe7fa8 Jan 29 08:17:39 ane kernel: ds: 0018 es: 0018 ss: 0018 Jan 29 08:17:39 ane kernel: Process kswapd (pid: 3, stackpage=cbfe7000) Jan 29 08:17:39 ane kernel: Stack: 00010f00 0004 0002 c013dbd1 0f8f c01278eb 0006 Jan 29 08:17:39 ane kernel:0004 00010f00 c01dae77 cbfe6239 0008e000 c012798c 0004 Jan 29 08:17:39 ane kernel:c133ffb8 c0107418 0078 c0229fd8 Jan 29 08:17:39 ane kernel: Call Trace: [shrink_dcache_memory+33/48] [do_try_to_free_pages+83/128] [kswapd+116/272] [kernel_thread+40/56] Jan 29 08:17:39 ane kernel: Jan 29 08:17:39 ane kernel: Code: 89 02 89 1b 89 5b 04 8d 73 e0 8b 43 e4 a8 08 74 27 24 f7 89 Jan 29 08:20:58 ane syslogd 1.3-3#33.1: restart. Jan 29 08:20:58 ane kernel: klogd 1.3-3#33.1, log source = /proc/kmsg started. Jan 29 08:20:58 ane kernel: Inspecting /boot/System.map-2.4.0 Jan 29 08:20:59 ane kernel: Loaded 13095 symbols from /boot/System.map-2.4.0. Jan 29 08:20:59 ane kernel: Symbols match kernel version 2.4.0. Jan 29 08:20:59 ane kernel: Loaded 219 symbols from 13 modules. If this tells somebody what it's all about I can provide further information about system etc. I also can provide three similar excerpts form my logfile ;-) Yours -Andreas --- http://www.acki-netz.de email: [EMAIL PROTECTED] // (+49)[0]9131/409500 or (+49)[0]9286/6399 \X/acki or acki2 on #rommelwood No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced. - 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: Matrox G450 problems with 2.4.0 and xfree
On 31 Jan 01 at 0:06, Marcel J.E. Mol wrote: > > > Installed a Matrox G450 on my linux system. Now it has problems > > > booting. The kernel is compiled with framebuffer support so is supposed > > > to boot up with the Linux logo. Unfortunately the systems hangs when > > > the kernel switches to the graphics mode. When I first boot into windoze > > > and the reboot to linux it works fine. So it looks like an > > > initialisation problem... Well, first to problem with G450. I was trying very hard to find what's wrong, last few weeks together with guys from some other OSes (I'm not sure if I can mention them publicaly) and we were not able to find what's wrong - and without datasheets we hardly can. Problem is that sometime G450 is in strange state, where doing accelerated operations which does both read and write (not simple fill) locks accelerator. Windows drivers works around somehow, as after booting to Windows matroxfb works fine - but without Windows it is just pure luck. You can try powering off your box again and again - and sometime it will boot, and from this time it will boot always until you poweroff computer. It looks like that if you compile 'agpgart' into kernel, chances that it will work are better, but I have also reports that it did not changed anything. So currently I do not know. Only 100% safe way I know is booting with 'video=matrox:noaccel' - but at cost of completely disabled acceleration. And if you'll start accelerated X with non-matrox mga driver (and with 'Option "UseFBDev"', of course) on such hardware, your computer locks again... > On Tue, Jan 30, 2001 at 04:53:45PM -0500, tc lewis wrote: > > > > try the latest driver that matrox provides. i had to do this with just a > > stock redhat 7.0 system. i don't think the standard kernel distributions > > redhat packages use a driver that knows about the 450 yet. > > > > http://www.matrox.com/mga/support/drivers/files/linux_04.cfm > > In the G400 time I tried the 1.0.1, 1.0.3 and 1.0.4 matrox driver > with XFree 4.0.1 but only 1.0.1 worked. After installing XFree 4.0.2 > I get the same results (the matrox drivers are build for XFree 4.0.1 > but I guess the should work for 4.0.2 to as they are 'modules'...). I'm currently using Matrox driver 1.0.4 and XF 4.0.2 with 'Options "UseFBDev"' and 'Options "HWCursor" "off"' - I'm using 'UseFBDev' because of I want to manage first/second head by hand (matroxset) and not by XFree. You can get it to work with xfree mga driver too (using usefbdev), but mga driver in XF4.0.2 ignores usefbdev option when using DGA - so for VMware you need mga driver from Matrox, anything else fails... > > > Previously I had a matrox G400 card and that worked without any problems. > > > > > > Also xfree fails when using the svga module (Xfree 4.0.2). When using the > > > fbdev module it works fine. Again, using the G400 card works fine with svga > > > module. > > > > > > And yes, it really is a G450! Revision >= 80 => G450 : G400, DDRAM memory interface, different VCO, better dualhead... And probably another BES used by CRTC2 in TVOut mode... Best regards, Petr Vandrovec [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/
Re: Version 2.4.1 cannot be built.
On Tue, 30 Jan 2001 18:09:48 -0500 (EST), "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: >On Wed, 31 Jan 2001, Keith Owens wrote: >> You mean that nobody reads Documentation/Changes any more? > >Seldom, only once or twice a day. Guess that's not often enough >to keep up on the new tool requirements. make 3.77 was added to Documentation/Changes in 2.4.0-test7-pre4.1, approx. 15 Aug 2000. - 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: unresolved symbol in 2.4.1 depmod.
In article <[EMAIL PROTECTED]> you write: > On Tue, 30 Jan 2001 14:15:20 -0600 (CST), > Jason Michaelson <[EMAIL PROTECTED]> wrote: > >Greetings. I've just procured myself a copy of 2.4.1, and tried to build > >it. At the tail end of a make modules_install, the following error occurs: > > > >depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/drivers/md/md.o > >depmod: name_to_kdev_t > > name_to_kdev_t is defined in init/main.c. It is not exported so it > cannot be called from modules. name_to_kdev_t *cannot* be exported > because it is defined as __init, the code has gone by the time the > module is loaded. Ask the md maintainer for a fix. How did this used to work, then? The call to name_to_kdev_t has been in the md code since (according to the code comments) May, 2000; the module worked fine as of 2.4.1-pre10, which is the last version I used. -- Dave Meyer [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/
Re: digiboard support in linux
Kenneth Yeung wrote: > Hello all > > Can anyone tell me where I can find infomation on digiboard support in > linux specifically the PC/X model? > > THanks > -Ken > > - > 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/ yes i used it often in my installations and no problem with that since 2.0.x 2.2.x works good too never tried with linux 2.4.x driver is supported by digiboard itself and by linux you have the choice of 2 drivers for these boards i used for my part the PC/8e PC/16e and PC/32e In ISA versions and never had any problems... (except figuring out how to install for the first time) but it is very simple if you know how to read install instructions Martin Laberge [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/
thread core dumps
Is there a way to get threaded applications to dump core properly on 2.4.0? There is a patch floating around for 2.2.x, but the patch is not applicable to the 2.4. code. Any help is appreciated af - 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: Version 2.4.1 cannot be built.
On Wed, 31 Jan 2001, Keith Owens wrote: > On Tue, 30 Jan 2001 17:57:44 -0500 (EST), > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > >On Wed, 31 Jan 2001, Keith Owens wrote: > > > >> On Tue, 30 Jan 2001 16:45:16 -0500 (EST), > >> "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > >> >The subject says it all. `make dep` is now broken. > >> >make[4]: Entering directory `/usr/src/linux-2.4.1/drivers/acpi' > >> >Makefile:29: *** target pattern contains no `%'. Stop. > >> > >> Which version of make are you running? > >> > > 3.74 > > > >y'a mean even make isn't make anymore? > > You mean that nobody reads Documentation/Changes any more? Seldom, only once or twice a day. Guess that's not often enough to keep up on the new tool requirements. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Version 2.4.1 cannot be built.
On Tue, 30 Jan 2001, Richard B. Johnson wrote: > On Wed, 31 Jan 2001, Keith Owens wrote: > > > On Tue, 30 Jan 2001 16:45:16 -0500 (EST), > > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > > >The subject says it all. `make dep` is now broken. > > >make[4]: Entering directory `/usr/src/linux-2.4.1/drivers/acpi' > > >Makefile:29: *** target pattern contains no `%'. Stop. > > > > Which version of make are you running? > > > 3.74 > > > y'a mean even make isn't make anymore? > Temporary 'fix' was `make -i` for the dependencies. All files I > need built okay. > > Cheers, > Dick Johnson > > Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). > Bob Tracy found the problem: the second ':' really needs to be escaped even though newer versions of make allow what was written. > make[4]: Entering directory `/usr/src/linux-2.4.1/drivers/acpi' > Makefile:29: *** target pattern contains no `%'. Stop. Try the following small patch. Make version 3.77 works fine, but I ran into the same problem you did with version 3.75. --CUT HERE-- --- linux/drivers/acpi/Makefile.origTue Jan 30 09:01:26 2001 +++ linux/drivers/acpi/Makefile Tue Jan 30 09:00:10 2001 @@ -26,7 +26,7 @@ # will hit everything, too risky in 2.4.0-prerelease. Bandaid by tweaking # CFLAGS only for .ver targets. Review after 2.4.0 release. KAO -$(MODINCL)/%.ver: CFLAGS := -I./include $(CFLAGS) +$(MODINCL)/%.ver: CFLAGS \:= -I./include $(CFLAGS) acpi-subdirs := common dispatcher events hardware \ interpreter namespace parser resources tables --CUT HERE-- Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Matrox G450 problems with 2.4.0 and xfree
On Tue, Jan 30, 2001 at 04:53:45PM -0500, tc lewis wrote: > > try the latest driver that matrox provides. i had to do this with just a > stock redhat 7.0 system. i don't think the standard kernel distributions > redhat packages use a driver that knows about the 450 yet. > > http://www.matrox.com/mga/support/drivers/files/linux_04.cfm In the G400 time I tried the 1.0.1, 1.0.3 and 1.0.4 matrox driver with XFree 4.0.1 but only 1.0.1 worked. After installing XFree 4.0.2 I get the same results (the matrox drivers are build for XFree 4.0.1 but I guess the should work for 4.0.2 to as they are 'modules'...). PS: This is not a redhat distro or any other for that matter. It is just my own 'distro', started from slackware 0.1 or so. It has always been very stable. I've run many development kernels on it and only very few gave rise to problems... -Marcel > On Tue, 30 Jan 2001, Marcel J.E. Mol wrote: > > > Hi, > > > > Installed a Matrox G450 on my linux system. Now it has problems > > booting. The kernel is compiled with framebuffer support so is supposed > > to boot up with the Linux logo. Unfortunately the systems hangs when > > the kernel switches to the graphics mode. When I first boot into windoze > > and the reboot to linux it works fine. So it looks like an > > initialisation problem... > > > > Previously I had a matrox G400 card and that worked without any problems. > > > > Also xfree fails when using the svga module (Xfree 4.0.2). When using the > > fbdev module it works fine. Again, using the G400 card works fine with svga > > module. > > > > > > lspci shows: > > > > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) >(prog-if 00 [VGA]) > > Subsystem: Matrox Graphics, Inc.: Unknown device 0641 > > Flags: bus master, medium devsel, latency 64, IRQ 11 > > Memory at e200 (32-bit, prefetchable) [size=32M] > > Memory at df80 (32-bit, non-prefetchable) [size=16K] > > Memory at df00 (32-bit, non-prefetchable) [size=8M] > > Expansion ROM at e1fe [disabled] [size=128K] > > Capabilities: > > > > And yes, it really is a G450! > > > > Below follows .config for the 2.4.0 kernel. > > > > If any other info/tests are needed I'll be happy to supply them... > > > > -Marcel > > -- > > == Marcel J.E. MolMESA Consulting B.V. > > ===-ph. +31-(0)6-54724868 P.O. Box 112 > > ===-[EMAIL PROTECTED] 2630 AC Nootdorp > > __ www.mesa.nl ---U_n_i_x__I_n_t_e_r_n_e_t The Netherlands > > They couldn't think of a number, so they gave me a name! > > -- Rupert Hine http://www.ruperthine.com/ > > > > # > > # 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=y > > > > # > > # Loadable module support > > # > > CONFIG_MODULES=y > > CONFIG_MODVERSIONS=y > > 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 is not set > > # CONFIG_M686FXSR is not set > > # CONFIG_MPENTIUM4 is not set > > # CONFIG_MK6 is not set > > CONFIG_MK7=y > > # 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_SHIFT=6 > > CONFIG_X86_TSC=y > > CONFIG_X86_GOOD_APIC=y > > CONFIG_X86_USE_3DNOW=y > > CONFIG_X86_PGE=y > > CONFIG_X86_USE_PPRO_CHECKSUM=y > > # CONFIG_TOSHIBA is not set > > # CONFIG_MICROCODE is not set > > CONFIG_X86_MSR=m > > CONFIG_X86_CPUID=m > > CONFIG_NOHIGHMEM=y > > # CONFIG_HIGHMEM4G is not set > > # CONFIG_HIGHMEM64G is not set > > # CONFIG_MATH_EMULATION is not set > > CONFIG_MTRR=y > > # CONFIG_SMP is not set > > CONFIG_X86_UP_IOAPIC=y > > CONFIG_X86_IO_APIC=y > > CONFIG_X86_LOCAL_APIC=y > > > > # > > # General setup > > # > > CONFIG_NET=y > > # CONFIG_VISWS is not set > > 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_EISA is not set > > # CONFIG_MCA is not set > > CONFIG_HOTPLUG=y > > > > # > > # PCMCIA/CardBus support > > # > > # 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=y > > CONFIG_ACPI=y > > CONFIG_APM=m > > # CONFIG_APM_IGNORE_USER_SUSPEND is not
Re: Multiple SCSI host adapters, naming of attached devices
Of course I should have said this is linux kernel 2.2.17, an IBM PS/2 9585, in-built 'IBM MCA' SCSI adapter and an AHA-1640 MCA card. I now realise that in 2.4 I can use scsihosts=ibmmca:aha1542, but have no info for 2.2.17. Sorry for the lack of info previously :) Thanks again. On Tue, 30 Jan 2001 22:49:12 Michael Pacey wrote: > Sorry for posting this here, I'm sure you're all busy with 2.4.1 and > 2.2.18 > but I'm read the SCSI HOWTO and asked on #LinPeople to no avail: > > Given two host adapters each with 1 disk of ID 0, how do I tell Linux > which > is sda and which sdb? > > After this I'll be filling the 2nd SCSI chain completely, so assigning a > different ID is not an option. > > Thanks in advance. > > -- > Michael Pacey > [EMAIL PROTECTED] > ICQ: 105498469 > > wd21 ltd - world domination in the 21st century > > - > 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/ > > -- Michael Pacey [EMAIL PROTECTED] ICQ: 105498469 wd21 ltd - world domination in the 21st century - 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: Version 2.4.1 cannot be built.
On Tue, 30 Jan 2001 17:57:44 -0500 (EST), "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: >On Wed, 31 Jan 2001, Keith Owens wrote: > >> On Tue, 30 Jan 2001 16:45:16 -0500 (EST), >> "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: >> >The subject says it all. `make dep` is now broken. >> >make[4]: Entering directory `/usr/src/linux-2.4.1/drivers/acpi' >> >Makefile:29: *** target pattern contains no `%'. Stop. >> >> Which version of make are you running? >> > 3.74 > >y'a mean even make isn't make anymore? You mean that nobody reads Documentation/Changes any more? Current Minimal Requirements o Gnu make 3.77# make --version PEBCAK. - 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/
can't compile kernel 2.4.1 with Athlon/K7 option
Hi ! I had a similar problem also for the 2.4.0-test10 kernel ... if I switch from the standard settings in the .config file and change only the processor type to Athlon/K7 compilation fails and I waited for a newer kernel ... I'm using a RedHat 7.0 distribution (with all available updates and bugfixes for this version). Actually I'm running a 2.4.0-test11 kernel ... with processor type Athlon/K7 etc. and everything works (compiles) fine ... ith the newest kernel 2.4.1 I have these errors: 1. make dep (ended with no errors) 2. [root@home linux]# make boot scripts/split-include include/linux/autoconf.h include/config gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=athlon-c -o init/main.o init/main.c In file included from /usr/src/linux/include/linux/irq.h:58, from /usr/src/linux/include/asm/hardirq.h:7, from /usr/src/linux/include/linux/interrupt.h:46, from /usr/src/linux/include/asm/string.h:297, from /usr/src/linux/include/linux/string.h:22, from /usr/src/linux/include/linux/fs.h:24, from /usr/src/linux/include/linux/capability.h:18, from /usr/src/linux/include/linux/binfmts.h:6, from /usr/src/linux/include/linux/sched.h:10, from /usr/src/linux/include/linux/mm.h:5, from /usr/src/linux/include/linux/slab.h:15, from /usr/src/linux/include/linux/malloc.h:5, from /usr/src/linux/include/linux/proc_fs.h:6, from init/main.c:16: /usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile': /usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use in this function) /usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is reported only once /usr/src/linux/include/asm/hw_irq.h:198: for each function it appears in.) In file included from /usr/src/linux/include/asm/string.h:297, from /usr/src/linux/include/linux/string.h:22, from /usr/src/linux/include/linux/fs.h:24, from /usr/src/linux/include/linux/capability.h:18, from /usr/src/linux/include/linux/binfmts.h:6, from /usr/src/linux/include/linux/sched.h:10, from /usr/src/linux/include/linux/mm.h:5, from /usr/src/linux/include/linux/slab.h:15, from /usr/src/linux/include/linux/malloc.h:5, from /usr/src/linux/include/linux/proc_fs.h:6, from init/main.c:16: /usr/src/linux/include/linux/interrupt.h: In function `raise_softirq': /usr/src/linux/include/linux/interrupt.h:89: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_schedule': /usr/src/linux/include/linux/interrupt.h:160: `current' undeclared (first use in this function) /usr/src/linux/include/linux/interrupt.h: In function `tasklet_hi_schedule': /usr/src/linux/include/linux/interrupt.h:174: `current' undeclared (first use in this function) In file included from /usr/src/linux/include/linux/string.h:22, from /usr/src/linux/include/linux/fs.h:24, from /usr/src/linux/include/linux/capability.h:18, from /usr/src/linux/include/linux/binfmts.h:6, from /usr/src/linux/include/linux/sched.h:10, from /usr/src/linux/include/linux/mm.h:5, from /usr/src/linux/include/linux/slab.h:15, from /usr/src/linux/include/linux/malloc.h:5, from /usr/src/linux/include/linux/proc_fs.h:6, from init/main.c:16: /usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d': /usr/src/linux/include/asm/string.h:305: `current' undeclared (first use in this function) /usr/src/linux/include/asm/string.h: In function `__memcpy3d': /usr/src/linux/include/asm/string.h:312: `current' undeclared (first use in this function) In file included from /usr/src/linux/include/linux/raid/md.h:51, from init/main.c:25: /usr/src/linux/include/linux/raid/md_k.h: In function `pers_to_level': /usr/src/linux/include/linux/raid/md_k.h:39: warning: control reaches end of non -void function make: *** [init/main.o] Error 1 [root@home linux]# Should I wait again for newer kernel versions ?? Thanks in advance, Arno Heister. - 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: Version 2.4.1 cannot be built.
"Richard B. Johnson" wrote: > On Wed, 31 Jan 2001, Keith Owens wrote: > > > On Tue, 30 Jan 2001 16:45:16 -0500 (EST), > > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > > >The subject says it all. `make dep` is now broken. > > >make[4]: Entering directory `/usr/src/linux-2.4.1/drivers/acpi' > > >Makefile:29: *** target pattern contains no `%'. Stop. > > > > Which version of make are you running? > > > 3.74 > > y'a mean even make isn't make anymore? > Temporary 'fix' was `make -i` for the dependencies. All files I > need built okay. I experienced similar problems with make 3.76.1. After upgrading to 3.79.1, the problems were gone. > > > Cheers, > Dick Johnson > > Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). > > "Memory is like gasoline. You use it up when you are running. Of > course you get it all back when you reboot..."; Actual explanation > obtained from the Micro$oft help desk. > > - > 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/ - 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: Version 2.4.1 cannot be built.
On Wed, 31 Jan 2001, Keith Owens wrote: > On Tue, 30 Jan 2001 16:45:16 -0500 (EST), > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > >The subject says it all. `make dep` is now broken. > >make[4]: Entering directory `/usr/src/linux-2.4.1/drivers/acpi' > >Makefile:29: *** target pattern contains no `%'. Stop. > > Which version of make are you running? > 3.74 y'a mean even make isn't make anymore? Temporary 'fix' was `make -i` for the dependencies. All files I need built okay. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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.1 -- Unresolved symbols in radio-miropcm20.o
On Tue, 30 Jan 2001 13:08:12 -0800, Miles Lane <[EMAIL PROTECTED]> wrote: >depmod: *** Unresolved symbols in >/lib/modules/2.4.1/kernel/drivers/media/radio/radio-miropcm20.o >depmod:aci_write_cmd >depmod:aci_indexed_cmd >depmod:aci_write_cmd_d Those symbols are defined in drivers/sound/aci.c but are not exported for other modules to use. The aci and miropcm20 code needs to be changed to support use as modules. Also the config.in files need fixing for these files, it is possible to select combinations of aci and miropcm20 that will fail to link (miropcm20 built in, aci not selected or selected as a module) or fail to load (miropcm20 selected as a module, aci not selected). - 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: WOL and 3c59x (3c905c-tx)
Tobias Ringstrom wrote: > > When shutting down my computer with Linux, I cannot wake it up using > wake-on-LAN, which I can do if I shut it down from WinME or the LILO > prompt using the power button. > > I see some "interesting" code in 3c59x.c and acpi_set_WOL, and there is > the following little comment: "AKPM: This kills the 905". > > So, what's up? Does it break all 905s? And will not changing the state > to D3, as a comment a few lines down says, shut the card down, which seems > to be a bad thing to do in a function called from vortex_probe1... I know > this code is currently bypassed, but still, what is this? > The code was broken, so I disabled it. I "fixed" WOL in the 2.2.19-pre candidate driver. It's at http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.2.19-pre6-1.gz I'd really appreciate it if you could test the WOL in that driver. Then we can port it into 2.4 and try to fool Linus into thinking it's a bugfix :) - - 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/
Multiple SCSI host adapters, naming of attached devices
Sorry for posting this here, I'm sure you're all busy with 2.4.1 and 2.2.18 but I'm read the SCSI HOWTO and asked on #LinPeople to no avail: Given two host adapters each with 1 disk of ID 0, how do I tell Linux which is sda and which sdb? After this I'll be filling the 2nd SCSI chain completely, so assigning a different ID is not an option. Thanks in advance. -- Michael Pacey [EMAIL PROTECTED] ICQ: 105498469 wd21 ltd - world domination in the 21st century - 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: unresolved symbol in 2.4.1 depmod.
On Tue, 30 Jan 2001 14:15:20 -0600 (CST), Jason Michaelson <[EMAIL PROTECTED]> wrote: >Greetings. I've just procured myself a copy of 2.4.1, and tried to build >it. At the tail end of a make modules_install, the following error occurs: > >depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/drivers/md/md.o >depmod: name_to_kdev_t name_to_kdev_t is defined in init/main.c. It is not exported so it cannot be called from modules. name_to_kdev_t *cannot* be exported because it is defined as __init, the code has gone by the time the module is loaded. Ask the md maintainer for a fix. - 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/
