Re: [PATCH for 2.5] preemptible kernel
Rusty Russell wrote:
>
> In message <[EMAIL PROTECTED]> you write:
> > Here is an attempt at a possible version of synchronize_kernel() that
> > should work on a preemptible kernel. I haven't tested it yet.
>
> It's close, but...
>
> Those who suggest that we don't do preemtion on SMP make this much
> easier (synchronize_kernel() is a NOP on UP), and I'm starting to
> agree with them. Anyway:
>
> > if (p->state == TASK_RUNNING ||
> > (p->state == (TASK_RUNNING|TASK_PREEMPTED))) {
> > p->flags |= PF_SYNCING;
>
> Setting a running task's flags brings races, AFAICT, and checking
> p->state is NOT sufficient, consider wait_event(): you need p->has_cpu
> here I think. You could do it for TASK_PREEMPTED only, but you'd have
> to do the "unreal priority" part of synchronize_kernel() with some
> method to say "don't preempt anyone", but it will hurt latency.
> Hmmm...
>
> The only way I can see is to have a new element in "struct
> task_struct" saying "syncing now", which is protected by the runqueue
> lock. This looks like (and I prefer wait queues, they have such nice
> helpers):
>
> static DECLARE_WAIT_QUEUE_HEAD(syncing_task);
> static DECLARE_MUTEX(synchronize_kernel_mtx);
> static int sync_count = 0;
>
> schedule():
> if (!(prev->state & TASK_PREEMPTED) && prev->syncing)
> if (--sync_count == 0) wake_up(&syncing_task);
>
> synchronize_kernel():
> {
> struct list_head *tmp;
> struct task_struct *p;
>
> /* Guard against multiple calls to this function */
> down(&synchronize_kernel_mtx);
>
> /* Everyone running now or currently preempted must
>voluntarily schedule before we know we are safe. */
> spin_lock_irq(&runqueue_lock);
> list_for_each(tmp, &runqueue_head) {
> p = list_entry(tmp, struct task_struct, run_list);
> if (p->has_cpu || p->state == (TASK_RUNNING|TASK_PREEMPTED)) {
I think this should be:
if (p->has_cpu || p->state & TASK_PREEMPTED)) {
to catch tasks that were preempted with other states. The lse Multi
Queue scheduler folks are going to love this.
George
> p->syncing = 1;
> sync_count++;
> }
> }
> spin_unlock_irq(&runqueue_lock);
>
> /* Wait for them all */
> wait_event(syncing_task, sync_count == 0);
> up(&synchronize_kernel_mtx);
> }
>
> Also untested 8),
> Rusty.
> --
> Premature optmztion is rt of all evl. --DK
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
VIA 82C686 Audio Codec: Clicks
Hi folks, Has anybody an idea how to get rid of the annoying clicks of the VIA 82C686 audio codec? Using xmms (just as an example) I get a click with each new track, when I move and release the track slider, etc. Even this echo -n "" >/dev/dsp produces a click. Regards Harri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revised memory-management stuff (was: OOM killer)
On Sat, Mar 31, 2001 at 10:03:28PM -0800, Jonathan Morton wrote: [snip] > Issue 3: > The OOM killer was frequently killing the "wrong" process. I have > developed an improved badness selector, and devised a possible means of > specifying "don't touch" PIDs at runtime. PID 1 is never selected for > killing. I am debating whether to allow selection of *any* process > labelled "init" and running as root for the chop, since one of the "unusual > but frequently encountered" scenarios is for a second init to be running > during an install or recovery procedure. This might make it's way in as an > optional feature. IO/memory direct hardware access capability holding processes should be at the bottom of the list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Revised memory-management stuff (was: OOM killer)
There's clearly been lots of discussion about OOM (and memory management in general) over the last week, so it looks like it's time to summarise it and work out the solution that's actually going to find it's way into the kernel. Issue 1: The OOM killer was activating too early. I have a 4-line fix for this problem, which has already appeared on the list. Maybe I should forward a copy directly to Alan and/or Linus. Issue 2: Applications are not warned when memory is running low, either in terms of reserved or allocated memory. I have implemented an improvement on this state of affairs, which makes memory reservation (whether by fork or malloc type operations) fail for applications which are larger than 4 times the unallocated space available. This also applies to reserved memory, but the memory-accounting code needs debugging before this will work reliably. The reason for stopping large processes short of the hard OOM line is so that smaller (mostly interactive) processes can still be started and run reliably. I will probably need some help with debugging the memory-accounting code, since it goes into bits of the kernel I know nothing (rather than "very little") about. Some posters suggested SIGDANGER, a feature from AIX, to warn processes when the system became dangerously low on memory. Other posters pointed out some disadvantages of SIGDANGER, which however (thankfully) only apply when SIGDANGER is used in isolation. For example, a malicious process designed to reserve memory within it's SIGDANGER handler could be thwarted by malloc() simply failing cleanly as above. If the process had already reserved memory and merely attempted to allocate it (by accessing it), the non-memory-overcommit code could defeat it by guaranteeing that the reserved memory was already available to be allocated. Without the non-memory-overcommit code, the OOM killer would be triggered - but with the improved algorithm I came up with as promised, the effects would be less severe on average (and most likely kill the malicious process in preference to a valuable batch job or system daemon). I have not implemented SIGDANGER, but I don't see any reason why it shouldn't be implemented. Certain implementation details will need some care. Issue 3: The OOM killer was frequently killing the "wrong" process. I have developed an improved badness selector, and devised a possible means of specifying "don't touch" PIDs at runtime. PID 1 is never selected for killing. I am debating whether to allow selection of *any* process labelled "init" and running as root for the chop, since one of the "unusual but frequently encountered" scenarios is for a second init to be running during an install or recovery procedure. This might make it's way in as an optional feature. Issue 4: Memory overcommit. I totally agree with those posters who point out that there are situations where this is a Bad Thing, specifically in mission-critical environments. However, for the "average" system, I still quite firmly believe it has some advantages. Since the non-memory-overcommit code needs a fair amount of debugging (after I hacksawed it in to fit the latest kernels), I hope the solutions to the first 3 issues are sufficient to satisfy most people for the time being. Issue 5: VM balancing needs a *lot* of work. During my exercising of the memory-management code, I noticed that memory-hogging applications could completely stall the machine, even when there is a lot of physical RAM available. I'm considering some simple algorithms to help alleviate this - these generally amount to a variation on the "suspend some processes when thrashing" theory. I'll need to think about these for a bit though, and try to implement them when I have time. Expect to see patches (containing the fixes mentioned above) on the list soon. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel compilation errors
Hello. I'm trying to compile new kernel 2.4.3 and I get some errors: yakov:/usr/src/linux$ make modules make[2]: Entering directory `/home/linux-2.4.3/drivers/block' gcc -D__KERNEL__ -I/home/linux-2.4.3/include -Wall -Wstrict-prototypes -O2 -fomi t-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev4 -Wa, -mev6 -DMODULE -DMODVERSIONS -include /home/linux-2.4.3/include/linux/modversion s.h -DEXPORT_SYMTAB -c loop.c In file included from /home/linux-2.4.3/include/linux/highmem.h:6, from /home/linux-2.4.3/include/linux/pagemap.h:17, from /home/linux-2.4.3/include/linux/locks.h:9, from /home/linux-2.4.3/include/linux/blk.h:6, from loop.c:65: /home/linux-2.4.3/include/asm/pgalloc.h:334: conflicting types for `pte_alloc' /home/linux-2.4.3/include/linux/mm.h:399: previous declaration of `pte_alloc' /home/linux-2.4.3/include/asm/pgalloc.h:352: conflicting types for `pmd_alloc' /home/linux-2.4.3/include/linux/mm.h:412: previous declaration of `pmd_alloc' make[2]: *** [loop.o] Error 1 make[2]: Leaving directory `/home/linux-2.4.3/drivers/block' make[1]: *** [_modsubdir_block] Error 2 make[1]: Leaving directory `/home/linux-2.4.3/drivers' make: *** [_mod_drivers] Error 2 Here's the output of scripts/ver_linux: Linux yakov.dls.net 2.4.0 #1 Sat Jan 6 20:17:19 CST 2001 alpha unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.10.0.18 util-linux 2.10m modutils 2.4.2 e2fsprogs 1.19 Linux C Library> libc.2.2 Dynamic linker (ldd) 2.2 Procps 2.0.7 Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded autofs yakov:/usr/src/linux$ cat /proc/cpuinfo cpu : Alpha cpu model : EV4 cpu variation : 0 cpu revision: 0 cpu serial number : Linux_is_Great! system type : Avanti system variation: 0 system revision : 0 system serial number: MILO-2.0.35-c5. cycle frequency [Hz]: 233313724 timer frequency [Hz]: 1024.00 page size [bytes] : 8192 phys. address bits : 34 max. addr. space # : 63 BogoMIPS: 459.64 kernel unaligned acc: 8 (pc=fc40e100,va=fc1c79f2) user unaligned acc : 8184 (pc=1200016dc,va=116c2) platform string : N/A cpus detected : 0 Thank you, Arc C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asus CUV4X-D, 2.4.3 crashes at boot
On Sun, Apr 01, 2001 at 04:15:38PM +1200, Simon Garner wrote: > Hi, > > I've compiled kernel 2.4.3 on the following RH7 system, and I'm now getting > random crashes at boot, during IO-APIC initialisation. Random meaning that > sometimes it boots fine, other times it doesn't, and it hangs in different > places (but always around IO-APIC stuff). It almost always hangs after a > cold boot - if I do a Ctrl+Alt+Del then it will usually boot up OK. > > System: Asus CUV4X-D motherboard, Dual P3 800EB. > > The last thing I see on the screen when it hangs is, for example: [snip] I've seen the exact same behavior with my CUV4X-D (2x1GHz) under 2.4.2 (debian woody). In addition, the kernel would sometimes hang around NMI watchdog enable. At least, I think it's trying to `enable'. The hang would occur around 50% of boot attempts. Once booted, everything was stable. A non-SMP 2.4.2 kernel (no IO-APIC either, sorry, didn't test that) always booted without hangs. Strangely, (happily for me,) the boot hangs stopped with 2.4.3. I've booted maybe 10 times (hot and cold) since I built 2.4.3 and I've had no hangs. When I get back to the box, I'll try booting a few dozen more times and see if I can confirm your observation. -- Allen Campbell [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Version 6.1.6 of the aic7xxx driver availalbe
>"Justin T. Gibbs" wrote: > >> >I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scs >i >> >bus. >> >I also upgraded to the "latest" aic7xxx driver but still the sam problems. >> >A typical revery in my logs. This really looks like you bus is not up to snuff. We timeout during a write to the drive. Although the chip has data to write, the target has stopped asking for data. This is a classic symptom of a lost signal transition on the bus. The old driver may have worked in the past because it was not quite as fast at driving the bus. 2.2.19 uses the "old" aic7xxx driver but includes some performance improvements over 2.2.18. The new driver has similar improvements. Check your cables. Check your terminators. Etc. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"device or resource busy" - why??
Hi, could you please help me figure out why is that happenning: After succesfull pivot_root & chroot from initrd, I *do* unmount /initrd, (no directories, no mapped files...), but I can *not* free the memory: "blockdev --flushbufs /dev/rd/0" returns "BLKFLSBUF: Device or resource busy". --- What is keeping it busy? I got really stuck with that. This is linux-2.4.3-pre6 SMP with devfs and blockdev from util-linux-2.11a and cramfs on initrd. I have the following processes running at that moment: - 1 0 /bin/bash 2 1 [keventd] 3 1 [kswapd] 4 1 [kreclaimd] 5 1 [bdflush] 6 1 [kupdated] 137 1 [mdrecoveryd] 160 1 [kreiserfsd] - And the following modules loaded: - reiserfs raid0 md sd_mod sym53c8xx scsi_mod - I thought I've checked everything I could, but with no luck. Could that be a cramfs issue? Thank you, Art. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Asus CUV4X-D, 2.4.3 crashes at boot
Hi, I've compiled kernel 2.4.3 on the following RH7 system, and I'm now getting random crashes at boot, during IO-APIC initialisation. Random meaning that sometimes it boots fine, other times it doesn't, and it hangs in different places (but always around IO-APIC stuff). It almost always hangs after a cold boot - if I do a Ctrl+Alt+Del then it will usually boot up OK. System: Asus CUV4X-D motherboard, Dual P3 800EB. The last thing I see on the screen when it hangs is, for example: CPU1: Intel Pentium III (Coppermine) stepping 06 CPU has booted. Before bogomips. Total of 2 processors activated (3207.98 BogoMIPS). Before bogocount - setting activated=1. Boot done. ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. ...TIMER: vector=49 pin1=2 pin2=0 Sometimes it gets a little further, but it's always somewhere near the IO-APIC stuff. When it does boot, I get: CPU1: Intel Pentium III (Coppermine) stepping 06 CPU has booted. Before bogomips. Total of 2 processors activated (3207.98 BogoMIPS). Before bogocount - setting activated=1. Boot done. ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 2-5, 2-10, 2-11, 2-13, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 number of MP IRQ sources: 17. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00178011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] register #02: ... : arbitration: 00 Full dmesg output: http://www.expio.co.nz/~sgarner/orion/smp/dmesg.txt My kernel .config: http://www.expio.co.nz/~sgarner/orion/smp/config.txt Output from lspci -xx: http://www.expio.co.nz/~sgarner/orion/smp/lspcixx.txt Any ideas? Thanks in advance, Simon Garner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Version 6.1.6 of the aic7xxx driver availalbe
"Justin T. Gibbs" wrote: > >I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scsi > >bus. > >I also upgraded to the "latest" aic7xxx driver but still the sam problems. > >A typical revery in my logs. > > Can you resend the recovery information after booting with "aic7xxx=verbose". > This will provide more information about the timeout which will hopefully > allow me to narrow down the problem. A full dmesg of the system would > be useful too as that will include the device inquiry data. > > -- > Justin > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ OK. This is it: Mar 31 16:39:03 pescadero kernel: UnexpecteMar 31 17:37:48 pescadero kernel: klogd 1.3-3, log source = /proc/kmsg started. Mar 31 17:37:48 pescadero kernel: Cannot find map file. Mar 31 17:37:48 pescadero kernel: No module symbols loaded. Mar 31 17:37:48 pescadero kernel: IRQ 00, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 13, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 18, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 10, APIC ID 2, APIC INT 12 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 14, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 18, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 1c, APIC ID 2, APIC INT 11 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 2c, APIC ID 2, APIC INT 11 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Lint: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 00 Mar 31 17:37:48 pescadero kernel: Lint: type 1, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 01 Mar 31 17:37:48 pescadero kernel: Processors: 2 Mar 31 17:37:48 pescadero kernel: mapped APIC to e000 (fee0) Mar 31 17:37:48 pescadero kernel: mapped IOAPIC to d000 (fec0) Mar 31 17:37:48 pescadero kernel: Kernel command line: BOOT_IMAGE=linux.test1 ro root=801 aic7xxx=verbose pirq=0,0,0,0,18,16,17,5,19,19,19,19 ether=9,0,eth0 ether=9,0,eth1 ether=9,0,eth2 ether=9,0,eth3 Mar 31 17:37:48 pescadero kernel: PIRQ redirection, working around broken MP-BIOS. Mar 31 17:37:48 pescadero kernel: ... PIRQ0 -> IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ1 -> IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ2 -> IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ3 -> IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ4 -> IRQ 18 Mar 31 17:37:48 pescadero kernel: ... PIRQ5 -> IRQ 16 Mar 31 17:37:48 pescadero kernel: ... PIRQ6 -> IRQ 17 Mar 31 17:37:48 pescadero kernel: ... PIRQ7 -> IRQ 5 Mar 31 17:37:48 pescadero kernel: Initializing CPU#0 Mar 31 17:37:48 pescadero kernel: Detected 300.687 MHz processor. Mar 31 17:37:48 pescadero kernel: Console: colour VGA+ 132x60 Mar 31 17:37:48 pescadero kernel: Calibrating delay loop... 599.65 BogoMIPS Mar 31 17:37:48 pescadero kernel: Memory: 125936k/131060k available (1458k kernel code, 4736k reserved, 554k data, 200k init, 0k highmem) Mar 31 17:37:48 pescadero kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Mar 31 17:37:48 pescadero kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Mar 31 17:37:48 pescadero kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Mar 31 17:37:48 pescadero kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Mar 31 17:37:48 pescadero kernel: CPU: Before vendor init, caps: 0080fbff , vendor = 0 Mar 31 17:37:48 pescadero kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Mar 31 17:37:48 pescadero kernel: CPU: L2 cache: 512K Mar 31 17:37:48 pescadero kernel: Intel machine check architecture supported. Mar 31 17:37:48 pescadero kernel: Intel machine check reporting enabled on CPU#0. Mar 31 17:37:48 pescadero kernel: CPU: After vendor init, caps: 0080fbff Mar 31 17:37:48 pescadero kernel: CPU: After generic, caps: 0080fbff Mar 31 17:37:48 pescadero kernel: CPU: Common caps: 0080fbff Mar 31 17:37:48 pescadero kernel: Checking 'hlt' instruction... OK. Mar 31 17:37:48 pescadero kernel: POSIX conformance testing by UNIFIX Mar 31 17:37:48 pescadero kernel: mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) Mar 31 17:37:48 pescadero kernel: mtrr: detected mtrr type: Intel Mar 31 17:37:48 pescadero kernel: CPU: Before vendor init, caps: 0080fbff , vendor = 0 Mar 31 17:37:48 pescadero kernel: CPU:
Re: Loopback device hangs on mount command
> [1.] Loopback device hangs on mount command. > > [2.] Mounting a loopback device hangs the process. Eg. Issuing > > losetup /dev/loop0 fsimg > mount /dev/loop0 /mnt > > will hang at the mount command. The mount process cannot be > killed, nor can the loopback device be destroyed with losetup. > > [4.] Linux mantissa 2.4.2 #15 Wed Mar 28 11:00:17 EST 2001 i686 Widely known and reported problem with 2.4 kernels before 2.4.3. Please search archives before posting such problems. Either apply Jens loop patches (available on via your ftp.kernel.org mirror), apply a recent -ac patch (which includes Jens patches), or upgrade to 2.4.3 (which also includes Jens patches). Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tmpfs in 2.4.3 and AC
On Fri, 30 Mar 2001, [EMAIL PROTECTED] wrote: > tmpfs (or shmfs or whatever name you like) is still different in > official series (2.4.3) and in ac series. Its a kick in the ass for > multiboot, as offcial 2.4.3 does not recognise 'tmpfs' in fstab: > > shmfs /dev/shmtmpfs ... Use type shm. It works in both versions. > Any reason, or is because it has been forgotten ? Alan picked up the tmpfs extensions. Linus didn't. Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loopback device hangs on mount command
On Sat, Mar 31 2001, Bill Rossi wrote: > > [1.] Loopback device hangs on mount command. use 2.4.3, known and fixed bug -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
what is pci=biosirq
I have an ALi chipset motherboard that seems to function normally. K6-2 450, 256mb ram, 20gb ide fujitsu hard disk. Every time I boot up I get this unsettling message about PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pci=biosirq. It turns out that 00:0f.0 is my ALi ide controller: 00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c1) Is this normal, or what should I do to "fix" it? Changing plug and play OS in the bios has no effect. dmesg and lspci follow: Linux version 2.4.3 (root@coffee) (gcc version 2.95.3 20010315 (release)) #2 Sat Mar 31 17:50:50 PST 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0fffc000 (usable) BIOS-e820: 0fffc000 - 0000 (ACPI data) BIOS-e820: 0000 - 1000 (ACPI NVS) BIOS-e820: - 0001 (reserved) On node 0 totalpages: 65532 zone(0): 4096 pages. zone(1): 61436 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 451.019 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 901.12 BogoMIPS Memory: 255860k/262128k available (826k kernel code, 5880k reserved, 271k data, 176k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: PCI BIOS revision 2.10 entry at 0xf0720, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router ALI [10b9/1533] at 00:07.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd v1.8 pty: 512 Unix98 ptys configured block: queued sectors max/low 170010kB/56670kB, 512 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 ALI15X3: IDE controller on PCI bus 00 dev 78 PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pci=biosirq. ALI15X3: chipset revision 193 ALI15X3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:pio, hdd:pio hda: FUJITSU MPF3204AT, ATA DISK drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hdc: RICOH CD-R/RW MP7040A, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 40031712 sectors (20496 MB) w/512KiB Cache, CHS=2491/255/63, UDMA(33) Partition check: hda: hda1 hda2 < hda5 hda6 > hda3 hda4 Serial driver version 5.05 (2000-12-13) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A PPP generic driver version 2.4.1 PPP Deflate Compression module registered PPP BSD Compression module registered NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 16384) ip_tables: (c)2000 Netfilter core team NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. cryptoapi: Registered sha1 (0) cryptoapi: Registered rijndael-ecb (0) cryptoapi: Registered rijndael-cbc (65536) cryptoapi: Registered aes-ecb (0) cryptoapi: Registered aes-cbc (65536) cryptoapi: Registered blowfish-ecb (0) cryptoapi: Registered blowfish-cbc (65536) cryptoapi: Registered des-ecb (0) cryptoapi: Registered des-cbc (65536) cryptoapi: Registered des_ede3-ecb (0) cryptoapi: Registered des_ede3-cbc (65536) VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 176k freed Adding Swap: 128516k swap-space (priority -1) PCI: Found IRQ 3 for device 00:09.0 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt eth0: 3Com PCI 3c900 Boomerang 10baseT at 0xb800, 00:60:97:c7:a6:82, IRQ 3 product code 4843 rev 00.0 date 09-07-00 8K word-wide RAM 3:5 Rx:Tx split, autoselect/10baseT interface. Enabling bus-master transmits and whole-frame receives. eth0: scatter/gather enabled. h/w checksums disabled Real Time Clock Driver v1.10d inserting floppy driver fo
KernelWiki Lives
Out of the ashes arises a better KernelWiki, with more expressive power, more features, more pages and a _lot_ of work to be done to update all your excellent submissions to the new PhpWiki syntax ;) enjoy: http://kernelbook.sourceforge.net/wiki/index.php -- Gary Lawrence Murphy <[EMAIL PROTECTED]> TeleDynamics Communications Inc Business Innovations Through Open Source Systems: http://www.teledyn.com "Computers are useless. They can only give you answers."(Pablo Picasso) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Loopback device hangs on mount command
[1.] Loopback device hangs on mount command. [2.] Mounting a loopback device hangs the process. Eg. Issuing losetup /dev/loop0 fsimg mount /dev/loop0 /mnt will hang at the mount command. The mount process cannot be killed, nor can the loopback device be destroyed with losetup. [3.] modules kernel loop [4.] Linux mantissa 2.4.2 #15 Wed Mar 28 11:00:17 EST 2001 i686 -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux mantissa 2.4.2 #15 Wed Mar 28 11:00:17 EST 2001 i686 Kernel modules 2.4.3 Gnu C 2.95.2 Gnu Make 3.75 Binutils 2.6.0.14 Linux C Library5.4.46 Dynamic linker ldd: version 1.9.9 Linux C++ Library 27.1.4 Linux C++ Library 10.0.so Procps 0.99 Mount 2.10s Net-tools V Kbd0.89 Sh-utils 1.12 Modules Loaded sg loop isofs sr_mod cdrom ide-scsi aic7xxx 3c59x unix serial es1371 ac97_codec uart401 sound soundcore Thank you, Bill Rossi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] smbfs: caching problems
Hello, there is something wrong with smbfs caching which makes my applications fail. The behaviour happens with linux-2.4.3-pre4 and linux-2.4.3-final. Consider following shell script: (where /mnt/n is a smbmounted smb share from a Win98SE box) router|/mnt/n/temp/smbfs> I=0; while test $I -lt 127; do echo "abc" >>/tmp/test.abc; I=$((I+1)); done # create a 508 bytes file router|/mnt/n/temp/smbfs> I=0; while test $I -lt 129; do echo "xyz" >>/tmp/test.xyz; I=$((I+1)); done # create a 516 bytes file router|/mnt/n/temp/smbfs> while true; do cp /tmp/test.abc testfile; tail -1 testfile; cp /tmp/test.xyz testfile; tail -1 testfile; done # copy the files alternatingly and read the destination file after it has bean overwritten abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc [...Ctrl-C...] router|/mnt/n/temp/smbfs> cd /tmp # the same on reiserfs router|/tmp> while true; do cp /tmp/test.abc testfile; tail -1 testfile; cp /tmp/test.xyz testfile; tail -1 testfile; done # here it works abc xyz abc xyz abc xyz abc xyz abc xyz abc xyz abc xyz abc xyz abc xyz abc xyz abc xyz abc xyz abc xyz abc [...Ctrl-C...] router|/tmp> uname -a Linux router 2.4.3 #5 Fri Mar 30 14:02:24 CEST 2001 i586 unknown router|/tmp> Obviously, the smbfs behaviour is wrong. Interstingly, the change in the filesize of the file overwritten seems to need to cross a 512-block-boundary in order to show the bug. Contact me if you need more info. Xuân. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
oops in uhci.c running 2.4.2-ac28
Hi. While running kernel 2.4.2-ac28, I switched on spinlock debugging and verbose BUG() reporting (I always use sysrq). Anyway, while running this I got an oops after about 2 or 3 minutes running, several times, exact same place each time, which I traced back to rh_int_timer_do(). This was in uhci.c (I used CONFIG_USB_UHCI_ALT). The oops was at [], and rh_int_timer_do starts at [] (I'd calculate the offset in the function, but it's too late at night). I recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get the oops any more. Using nm vmlinux, I got this stack: rh_int_timer_do timer_bh bh_action tasklet_hi_action gcc_compiled. (?) do_IRQ default_idle If more info is needed, I'll be glad to reproduce the bug and copy the oops here. Also, the reason I started all this debugging was that I have a freecom usb CD-RW that stops when I try to access it (the process is in uninterruptible sleep and never comes out) when I access some files on some CDs. If anyone knows about this, I'd appreciate any tips. Also, if anyone has the technical specs on it, I'd even be willing to (try to) look at it to see if I can spot something with the freecom code... haven't found anything on www.freecom.com yet. Linux XX 2.4.2-ac28 #3 Sun Apr 1 01:16:44 CEST 2001 i686 unknown Gnu C egcs-2.91.66 Gnu make 3.78.1 binutils 2.9.5.0.22 util-linux 2.10f mount 2.10f modutils 2.4.2 e2fsprogs 1.19 pcmcia-cs 3.1.8 PPP2.4.0b1 Linux C Library2.1.3 Dynamic linker (ldd) 2.1.3 Procps 2.0.6 Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded ne 8390 vfat fat ufs Kind Regards, Ketil Froyn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: epic100 aka smc etherpower II
Daniel Nofftz <[EMAIL PROTECTED]> wrote: > i can`t get my smc etherpower ii working with the 2.4.3 kernel. > now i have downgraded to 2.4.2 and it works again ... > does anyone have a suggestion, what the problem is ? Looks to me like the problem I had in Febuary, see the thread "epic100 in current -ac kernels" at http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg28523.html After I had upgraded my BIOS, the problems were gone and I stopped looking into it. The DMA mapping code first introduced in 2.4.0-ac2 (smallest diff here) originally triggered the bug, which had different symptoms depending on the configuration of the chipset. Note that I have a VIA VT8363 (KT133) chipset while this is a VT82C595 (VP2) chipset, so it is appearantly not limited to one very specific configuration. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
w9966cf v4l driver homepage
The w9966cf webcam v4l driver now has a homepage: http://hem.fyristorg.com/mogul/w9966.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tcgetattr fails in 2.4.3
ppp chat script stopped working under 2.4.3. I ran a program of my own that opens ttyS1 and it also fails on a tcgetattr with errno=5 (IO error). The ppp chat script and my program both work fine under 2.4.2 and older. jpd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Matrox G400 Dualhead
On Sat, 31 Mar 2001 07:17:19, "Rafael E. Herrera" <[EMAIL PROTECTED]> wrote: > J Brook wrote: > > > > >With 2.4.2 it was working just fine. > > > > I have also noticed problems with the 2.4.3 release. I have a G450 > > 32Mb, that I use in single-head mode. The console framebuffer runs > > fine at boot time, but when I load X (4.0.3 compiled with Matrox HAL > > library) and then return to the console, I get a blank screen (signal > > lost). > > In my case, when lilo boots my G450 on any video mode other than > 'normal', going into X and then back into console, leads to a blank > screen. I've observed this behavior in 2.2 and 2.4. Otherwise, I've no > problem using the card in single or dual head. I get this as well on my G200. From observation it appears that the refresh rate is being doubled when you exit X and that's why the console appears blank. On my system I normally use modprobe matroxfb vesa=263 fv=85 to give a large text console. On return from X, if I blindly type fbset "640x480-60" then I get a visible screen back but my monitor tells me that it's running at 640x480@119Hz. Same thing for 800x600-60 only this one says 120Hz. Base system is SuSE 7.1 using XFree86 4.0.2. If I switch to 3.3.6 then it works OK. If I don't load matroxfb then it also works OK. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.3 and SysRq over serial console
Hello all. Without the attached patch, SysRq doesn't work over a serial
console here. Has anyone else seen this problem?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
diff -Nru a/linux/drivers/char/n_tty.c b/linux/drivers/char/n_tty.c
--- a/linux/drivers/char/n_tty.cSat Mar 31 16:30:44 2001
+++ b/linux/drivers/char/n_tty.cSat Mar 31 16:30:44 2001
@@ -40,6 +40,10 @@
#include
#include
#include
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+#include
+#include
+#endif
#include
#include
@@ -458,6 +462,12 @@
static inline void n_tty_receive_break(struct tty_struct *tty)
{
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+ struct console *c = console_drivers;
+ if (c && c->device && (c->device(c) == tty->device)
+ && !test_and_change_bit(TTY_DOING_SYSRQ, &tty->flags))
+ return;
+#endif
if (I_IGNBRK(tty))
return;
if (I_BRKINT(tty)) {
@@ -506,6 +516,12 @@
{
unsigned long flags;
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+ if (test_and_clear_bit(TTY_DOING_SYSRQ, &tty->flags)) {
+ handle_sysrq(c, NULL, NULL, tty);
+ return;
+ }
+#endif
if (tty->raw) {
put_tty_queue(c, tty);
return;
diff -Nru a/linux/include/linux/tty.h b/linux/include/linux/tty.h
--- a/linux/include/linux/tty.h Sat Mar 31 16:30:44 2001
+++ b/linux/include/linux/tty.h Sat Mar 31 16:30:44 2001
@@ -329,6 +329,9 @@
#define TTY_PUSH 6
#define TTY_CLOSING 7
#define TTY_DONT_FLIP 8
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+#define TTY_DOING_SYSRQ 9
+#endif
#define TTY_HW_COOK_OUT 14
#define TTY_HW_COOK_IN 15
#define TTY_PTY_LOCK 16
Magik1 and pci=biosirq
I reported this a while back but no fix went into the 2.4.3 kernel so I thought I'd ask again. Is this just a problem waiting for a driver? Or have I missed a setting? I have the ALi Magick1 chipset and on boot (and in dmesg) I get the following messages: PCI: PCI BIOS revision 2.10 entry at 0xfb310, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router default [10b9/1647] at 00:00.0 ALI15X3: IDE controller on PCI bus 00 dev 20 PCI: No IRQ known for interrupt pin A of device 00:04.0. ALI15X3: chipset revision 196 ALI15X3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA This is my system (/proc/pci) PCI devices found: Bus 0, device 0, function 0: Host bridge: PCI device 10b9:1647 (Acer Laboratories Inc. [ALi]) (rev 2). Prefetchable 32 bit memory at 0xf000 [0xf3ff]. Bus 0, device 1, function 0: PCI bridge: Acer Laboratories Inc. [ALi] M5247 (rev 0). Master Capable. No bursts. Min Gnt=14. Bus 0, device 2, function 0: USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 3). IRQ 5. Master Capable. Latency=32. Max Lat=80. Non-prefetchable 32 bit memory at 0xdf001000 [0xdf001fff]. Bus 0, device 4, function 0: IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev 196). Master Capable. Latency=32. Min Gnt=2.Max Lat=4. I/O at 0xd000 [0xd00f]. Bus 0, device 7, function 0: ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] (rev 0). Bus 0, device 10, function 0: Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 8). IRQ 12. Master Capable. Latency=32. Min Gnt=2.Max Lat=20. I/O at 0xd400 [0xd41f]. Bus 0, device 10, function 1: Input device controller: Creative Labs SB Live! (rev 8). Master Capable. Latency=32. I/O at 0xd800 [0xd807]. Bus 0, device 11, function 0: SCSI storage controller: Adaptec AHA-2940U2/W (rev 0). IRQ 10. Master Capable. Latency=32. Min Gnt=39.Max Lat=25. I/O at 0xdc00 [0xdcff]. Non-prefetchable 64 bit memory at 0xdf00 [0xdf000fff]. Bus 0, device 12, function 0: Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (rev 0). IRQ 11. Master Capable. Latency=32. Min Gnt=3.Max Lat=8. I/O at 0xe000 [0xe03f]. Bus 0, device 17, function 0: Bridge: Acer Laboratories Inc. [ALi] M7101 PMU (rev 0). Bus 1, device 0, function 0: VGA compatible controller: nVidia Corporation GeForce 256 DDR (rev 16). IRQ 11. Master Capable. Latency=248. Min Gnt=5.Max Lat=1. Non-prefetchable 32 bit memory at 0xdc00 [0xdcff]. Prefetchable 32 bit memory at 0xd000 [0xd7ff]. and finally my .config: # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII 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=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP 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=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_ACPI=y 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=y # CONFIG_APM_RTC_IS_GMT is not set CONFIG_APM_ALLOW_INTS=y # 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=y # CONFIG_PARPORT_PC_SUPERIO
Re: ipx wont compile in 2.4.3
Em Sat, Mar 31, 2001 at 01:55:23PM -0600, Stephen Crowley escreveu: > Trying to compile 2.4.3 with ipx support gives the following > > net/network.o(.data+0x3e48): undefined reference to sysctl_ipx_pprop_broadcasting' oops, Linus/David, can you please apply this? - Arnaldo --- linux-2.4.3/net/ipx/af_ipx.cFri Mar 30 08:12:58 2001 +++ linux-2.4.3.acme/net/ipx/af_ipx.c Fri Mar 30 09:15:26 2001 @@ -123,7 +123,7 @@ static unsigned char ipxcfg_max_hops = 16; static char ipxcfg_auto_select_primary; static char ipxcfg_auto_create_interfaces; -static int sysctl_ipx_pprop_broadcasting = 1; +int sysctl_ipx_pprop_broadcasting = 1; /* Global Variables */ static struct datalink_proto *p8022_datalink; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile linux 0.0.0.1?
Leif Sawyer <[EMAIL PROTECTED]> writes: > > Yeah, but then you have to find the buffalo and that gets > > hard. (Actually Linus used a carabou, but those are even > > harder to find...) > > Well, I remember back to 0.12ish and the Caribou around here > (Alaska) were plentiful then. Ah, those were the days. They are still plentiful in Norway, and I suspect they are in Finland as well. Harald. -- Foreningen for engelsk ord deling kjemper for at sammen satte ord som leke plass og kjøle skap skal skilles for aldri mer å se hver andre. Foreningen føler at den langt på vei har lykkes i sitt pioner arbeid. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [speculation] Partitioning the kernel
On Saturday 31 March 2001 22:55, Sandy Harris wrote: > I'm wondering whether we have or need a formalisation of how work might be > divided in future kernels. > > The question I'm interested in is how the work gets split up among various > components at different levels within a single box (not SMP with many at > the same level, or various multi-box techniques), in particular how you > separate computation and I/O given some intelligence in devices other than > the main CPU (or SMP set). > > There are a bunch of examples to look at: > > IBM mainframe > "channel processors" do all the I/O > main CPU sets up a control block, does an EXCP instruction > there's an interrupt when operation completes or fails > > VAX 782: basically two 780s with a big cable between busses > one has disk controllers, most of the (VMS) kernel > other has serial I/O, runs all user processes > > various smart network or disk controllers > and really smart ones that do RAID or Crypto > > I2O stuff on newer PCs > > Larry McVoy's suggestion that the right way to run, say, a 32-CPU > box is with something like 8 separate kernels, each using 4 CPUs > If one of those runs the file system for everyone, this somewhat > overlaps the techniques listed above. > > All of these demonstrably work, but each partitions the work between > processors in a somewhat different way. > > What I'm wondering is whether, given that many drivers have a top-half > vs. bottom-half split as a fairly basic part of their design, it would > make sense to make it a design goal to have a clean partition at that > boundary. > > On well-endowed systems, you then have the main CPUs running the top half > of everything, while I2O processors handle all the bottom halves and the > I/O interrupts. On lesser boxes, the CPU does both halves. > > It seems to me this might give a cleaner design than one where the work > is partitioned between devices at some other boundary. > > If the locks you need between top and bottom halves of the driver are also > controlling most or all CPU-to-I2O communication, it might go some way > toward avoiding the "locking cliff" McVoy talks of. A small cheap processor to do this with would be the ETRAX 100LX (LX = Linux) Put an ETRAX100LX (integrated IDE, ethernet, and ...) on an IDE controller. Telnet / SSH to your PCI boards :-) Cheapest possible system might be one without a main CPU... It would be possible to rebalance where to create the interface over time. /RogerL -- Roger Larsson Skellefteå Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Assumption in sym53c8xx.c failed
Hi, I'm currently running 2.4.2-ac28 and today I got a failing assumption in sym53c8xx.c. I'm not sure about the exact steps that I did to produce this error, but it must have been something like: cdparanoia -blank=all, then sending Ctrl+C to this process and after it's been killed cdparanoia -blank=fast. I then got assertion: k!=-1 failed. But I found no hint about this in the messages or syslog file. So I looked through sym53c8xx.c to find this code and it seems like line 10123 is responsible for creating this error and kernel panic. Should this be the normal behaviour or is this a bug in the code? Christian -- Truth is the most valuable thing we have -- so let us economize it. -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE driver status ?
It should support both, to my knowledge (which is very limited, mind
you). I also went out to the store and purchased a new cable, which
made the driver recognize the cable correctly, whereas it did not
before. I wonder if there is not a serious deficiency in the cables
sent out with motherboards, which is contributing to the problems a lot
of people are having in this area. Hope this helps some.
Chris
On 31 Mar 2001 15:14:47 -0300, Frédéric L. W. Meunier wrote:
> I'm not overclocking. It's an ASUS A7Pro with Athlon 1000. I
> had the same problem with an ASUS K7V with Athlon 700. But
> the processor died after my cooler failed for 20 minutes!
>
> BTW, how do I know if my cable is ATA100/ATA66, not only ATA66
> ? The manual from the A7Pro says it supports both, but at the
> site it says the cable shipped with this motherboard is ATA66.
>
> On Sat, Mar 31, 2001 at 12:00:41PM -0600, Glenn C. Hofmann wrote:
> > I am not sure if this applies in your case, but I was getting problems
> > such as this on my Abit KT7-RAID and had the correct cables, also. One
> > day, on a hunch after reading a post from Alan about overclocking, I
> > took my Athlon 750 down to 850 from 1.05 GHz and all is working great
> > now. If your overclocking, I would suggest not doing so (at least not
> > so much), based on my experience. I am also using the v4.0 driver.
> >
> > Chris
> >
> > On 31 Mar 2001 00:41:32 -0300, Frédéric L. W. Meunier wrote:
> > > Hi. I really can't get UDMA66 with the VIA driver. I tried
> > > everything, also a new motherboard (ASUS A7Pro) with a
> > > ATA100/ATA66 cable (using both ends...)!
> > >
> > > All I get are the usual CRC error messages.
> > >
> > > So, there's no UDMA66 for any vt82c686a ? I'm using 2.4.3.
> > >
> > > If there's no UDMA66, what are the advantages using this
> > > driver ?
> > >
> > > TIA.
>
> --
> 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]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ipc/shm.c ifdef CONFIG_PROC_FS
missing for line 73 at 2.4.0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[speculation] Partitioning the kernel
I'm wondering whether we have or need a formalisation of how work might be divided in future kernels. The question I'm interested in is how the work gets split up among various components at different levels within a single box (not SMP with many at the same level, or various multi-box techniques), in particular how you separate computation and I/O given some intelligence in devices other than the main CPU (or SMP set). There are a bunch of examples to look at: IBM mainframe "channel processors" do all the I/O main CPU sets up a control block, does an EXCP instruction there's an interrupt when operation completes or fails VAX 782: basically two 780s with a big cable between busses one has disk controllers, most of the (VMS) kernel other has serial I/O, runs all user processes various smart network or disk controllers and really smart ones that do RAID or Crypto I2O stuff on newer PCs Larry McVoy's suggestion that the right way to run, say, a 32-CPU box is with something like 8 separate kernels, each using 4 CPUs If one of those runs the file system for everyone, this somewhat overlaps the techniques listed above. All of these demonstrably work, but each partitions the work between processors in a somewhat different way. What I'm wondering is whether, given that many drivers have a top-half vs. bottom-half split as a fairly basic part of their design, it would make sense to make it a design goal to have a clean partition at that boundary. On well-endowed systems, you then have the main CPUs running the top half of everything, while I2O processors handle all the bottom halves and the I/O interrupts. On lesser boxes, the CPU does both halves. It seems to me this might give a cleaner design than one where the work is partitioned between devices at some other boundary. If the locks you need between top and bottom halves of the driver are also controlling most or all CPU-to-I2O communication, it might go some way toward avoiding the "locking cliff" McVoy talks of. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: Resend - more info
?? -- Mircea Damian E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED] WebPage: http://taz.mania.k.ro/~dmircea/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question about SysRq
Hi.
I managed fullowing situation: user with no ulimits will run script like
this:
#! /usr/bin/perl
while (1)
{
fork();
};
on say tty2. The processes get created pretty fast. After a short while
I supposed a single solution to this to kill all session by alt+sysrq+k,
but nothing happened. Under normal averagely loaded situation, this will
imidiately kill all processes on current vt and bring getty prompt.
Shouldn't it function similiarily in former case ? I see all processes on vt
get SIGKILL, so what's hapenned ? Maybe I had to wait
a bit longer for kernel to accomplish that ? Killing all processes with init
(alt+sysrq+i) seems to be immediate.
Thought, i really love all sysrq properties of linux, so i need less often
to make hardware resets an then await and fear, what fsck will print.
One more property, that i'd like to have should be request key to force the
most basic text mode (say 80x25) on the console, when eg. X freezes and
i kill its session, then last gfx mode resides on the screen and see no way
to restore back the text mode - /usr/bin/reset or something alike will not
do it. But it seems to be not a good idea at all, does it ?
Cheers B.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Disk Corruption with 2.4.3 / NOT with AC kernels
In mailing-lists.linux-kernel, you wrote: > I run into some major disk corruptions on my IDE disk with the new > 2.4.3 kernel version. [ . . . ] Now I did some more testing and found > out that the Alan Cox series of kernel patches does not show these > problems. Hmm, 2.4.2-ac28 and 2.4.3 have the same collection of VIA fixups in arch/i386/kernel/pci-pc.c. Something else must be causing this? > I was using the same .config file for all tests to make sure that the > problem was not caused by a kernel configuration issue. Did you run the .config through a 'make oldconfig' on each kernel, to catch CONFIG name changes and so forth? > This is my hardware: > - ABit KT7 board (KT133 chipset reported by lspci) Does the BIOS have a setting that sounds like "System performance setting" with choices such as "Optimal" or "Normal"? If so, try both settings. The terminology above is what is used on the ASUS A7V. >Here is the output of lspci: What would be quite useful, I think, is the output of 'lspci -xxx -s 0:0' under both the non-corrupting kernel (2.4.2-ac28) and the corrupting kernel (2.4.3). The output of 'dmesg' under both kernels would also be good. I find that a good way to present information like that, where most of it should be the same and one is looking for the differences, is via 'diff -u --unified=1000 a b'. Cheers, Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
via busmaster driver
hi!
when i enable the ultra dma 33 mode on my computer, the disk
performance goes down by around 30 % compared to normal pio mode 4. is
this a bug, or is there any solution to get this ultra dma working
correctly ? this happens with 2.4.2 and 2.4.3 ...
i have a shuttle hot-603 motherboard with the amd640 aka Via Apollo
VP2/97 chipset. the diskdrive is an Maxtor 33073U4, ATA DISK drive (ultra
dma 66 possible).
any suggestions ?
daniel
lspci output:
00:00.0 Host bridge: VIA Technologies, Inc. VT82C595/97 [Apollo VP2/97]
(rev 03)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo
VP] (rev 31)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
06)
00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 01)
hdparm -i /dev/hda :
Model=Maxtor 33073U4, FwRev=BAC51KJ0, SerialNo=N40SZZ8C
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=512kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=60030432
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
cat /proc/ide/via :
--VIA BusMastering IDE Configuration
Driver Version: 3.20
South Bridge: VIA vt82c586b
Revision: ISA 0x31 IDE 0x6
BM-DMA base:0x6300
PCI clock: 33MHz
Master Read Cycle IRDY:1ws
Master Write Cycle IRDY:1ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: yes yes
Post Write Buffer:yes no
Enabled: yes yes
Simplex only: no no
Cable Type: 40w 40w
---drive0drive1drive2drive3-
Transfer Mode: UDMA PIO UDMA PIO
Address Setup: 30ns 120ns 30ns 90ns
Cmd Active: 90ns 90ns 330ns 330ns
Cmd Recovery:30ns 30ns 270ns 270ns
Data Active: 90ns 330ns 90ns 300ns
Data Recovery: 30ns 270ns 30ns 300ns
Cycle Time: 60ns 600ns 60ns 600ns
Transfer Rate: 33.0MB/s 3.3MB/s 33.0MB/s 3.3MB/s
other devices conneted:
Mar 31 19:50:31 hyperion kernel: hda: Maxtor 33073U4, ATA DISK drive
Mar 31 19:50:31 hyperion kernel: hdc: TOSHIBA CD-ROM XM-6702B, ATAPI
CD/DVD-ROM drive
Mar 31 19:50:31 hyperion kernel: hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY
drive
driveroutput during boottime:
Mar 31 19:50:31 hyperion kernel: Uniform Multi-Platform E-IDE driver
Revision: 6.31
Mar 31 19:50:31 hyperion kernel: ide: Assuming 33MHz system bus speed for
PIO modes; override with idebus=xx
Mar 31 19:50:31 hyperion kernel: VP_IDE: IDE controller on PCI bus 00 dev
39
Mar 31 19:50:31 hyperion kernel: VP_IDE: chipset revision 6
Mar 31 19:50:31 hyperion kernel: VP_IDE: not 100%% native mode: will probe
irqs later
Mar 31 19:50:31 hyperion kernel: ide: Assuming 33MHz system bus speed for
PIO modes; override with idebus=xx
Mar 31 19:50:31 hyperion kernel: VP_IDE: VIA vt82c586b (rev 31) IDE UDMA33
controller on pci00:07.1
Mar 31 19:50:31 hyperion kernel: ide0: BM-DMA at 0x6300-0x6307, BIOS
settings: hda:pio, hdb:pio
Mar 31 19:50:31 hyperion kernel: ide1: BM-DMA at 0x6308-0x630f, BIOS
settings: hdc:pio, hdd:pio
***
Daniel Nofftz
Sysadmin CIP Pool der Informatik
Universität Trier, V 103
Mail: [EMAIL PROTECTED]
***
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Third Reich Promotional Ad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ipx wont compile in 2.4.3
Trying to compile 2.4.3 with ipx support gives the following net/network.o(.data+0x3e48): undefined reference to sysctl_ipx_pprop_broadcasting' --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
epic100 aka smc etherpower II
hi!
i can`t get my smc etherpower ii working with the 2.4.3 kernel.
now i have downgraded to 2.4.2 and it works again ...
does anyone have a suggestion, what the problem is ?
daniel
this are the interesting lines from /var/log/messages:
during the bootup:
(debugging enabled in the driver)
Mar 31 18:52:17 hyperion kernel: epic100.c:v1.11 1/7/2001 Written by
Donald Becker <[EMAIL PROTECTED]>
Mar 31 18:52:17 hyperion
kernel: http://www.scyld.com/network/epic100.html
Mar 31 18:52:17 hyperion kernel: (unofficial 2.4.x kernel port, version
1.1.6, January 11, 2001)
Mar 31 18:52:17 hyperion kernel: e000 0c29 a15a f000 001d 1c08 10b8 a011
Mar 31 18:52:17 hyperion kernel:
Mar 31 18:52:17 hyperion kernel: 0010 1980 2100 0003
0701 4d53 3943 3334 5432
Mar 31 18:52:17 hyperion kernel: 2058 2020 0280
Mar 31 18:52:17 hyperion kernel: epic100(00:09.0): MII transceiver #3
control 3000 status 7809.
Mar 31 18:52:17 hyperion kernel: epic100(00:09.0): Autonegotiation
advertising 01e1 link partner 0001.
Mar 31 18:52:17 hyperion kernel: eth0: SMSC EPIC/100 83c170 at 0x6500, IRQ
11, 00:e0:29:0c:5a:a1.
later, short after end of bootup:
Mar 31 19:23:29 hyperion kernel: eth0: Setting half-duplex based on MII
xcvr 3 register read of 0001.
Mar 31 19:23:29 hyperion kernel: Real Time Clock Driver v1.10d
Mar 31 19:23:29 hyperion kernel: eth0: Setting full-duplex based on MII #3
link partner capability of 45e1.
Mar 31 19:24:31 hyperion kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 31 19:24:31 hyperion kernel: eth0: Transmit timeout using MII device,
Tx status 4003.
Mar 31 19:24:33 hyperion kernel: eth0: Setting half-duplex based on MII #3
link partner capability of 0001.
Mar 31 19:24:35 hyperion kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 31 19:24:35 hyperion kernel: eth0: Transmit timeout using MII device,
Tx status 0003.
aditional there was the error message : to much work at interrupt ...
lspci output:
00:00.0 Host bridge: VIA Technologies, Inc. VT82C595/97 [Apollo VP2/97]
(rev 03)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo
VP] (rev 31)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
06)
00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 01)
00:08.0 Multimedia video controller: 3Dfx Interactive, Inc. Voodoo 2 (rev
02)
00:09.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF
(rev 06)
00:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev
08)
00:0a.1 Input device controller: Creative Labs SB Live! (rev 08)
00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W
[Millennium II]
network hardware:
smc etherpower ii connected to an 10/100 mbit nway autoneg. switch
***
Daniel Nofftz
Sysadmin CIP Pool der Informatik
Universität Trier, V 103
Mail: [EMAIL PROTECTED]
***
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Third Reich Promotional Ad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Minor 2.4.3 Adaptec Driver Problems
> >I just got 2.4.3 up a running (on Abit BP6 Dual Celeron ) and > >it reorderd my SCSI id's. Take a look. I don't like that my ZIP drive > >becomes sda because if I ever remove it then I'll @#$% my harddrive dev > >mappings again and have to change them again. Adaptec Driver 6.1.5 > >:-( > > Upgrade to version 6.1.8 of the aic7xxx driver from here. This was > fixed just after 6.1.5 was released: > > http://people.FreeBSD.org/~gibbs/linux > > Use the 2.4.3-pre6 patch. I upgraded to the level 6.1.8 but It is still booting the scsi generic(sg) driver before my hard drives. I have verified that I am using Rev 6.1.8 from dmesg. I did applied patch 2.4.3-pre6 on a stock 2.4.3 kernel. ideas? Earle (please email me directly) _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE Disk Corruption with 2.4.3 / NOT with AC kernels
Hello, I just got my first fs corruption too(2.4.3), but using reiserfs on LVM , and the volume group is also on IDE. Accessing some /usr/src/linux/... file my system "hang" or just rebooted. using reiserfsck "fixed" this for me. I'm using the Asus A7V board, but comparable chipset, with the athlon 1.1GHz. # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:0b.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875J (rev 04) 00:0c.0 Ethernet controller: 3Com Corporation 3c985 1000BaseSX (rev 01) 00:0d.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 07) 00:0d.1 Input device controller: Creative Labs SB Live! (rev 07) 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation Riva TnT2 [NV5] (rev 15) On Sat, 31 Mar 2001, Karl Heinz Kremer wrote: > I run into some major disk corruptions on my IDE disk with the new > 2.4.3 kernel version. I did see the same corruptions with 2.4.2 > - but back then I blamed reiserfs and went back to 2.4.1. > > Now I did some more testing and found out that the Alan Cox > series of kernel patches does not show these problems. I tried > one from the 2.4.1-ac series (I think it was ac8) and 2.4.2-ac20 > with nothing but success. I was using the same .config file for > all tests to make sure that the problem was not caused by > a kernel configuration issue. > > This is my hardware: > > - ABit KT7 board (KT133 chipset reported by lspci) > - 1GHz Athlon > - QUANTUM FIREBALLP AS40.0 disk (cat /proc/ide/hda/model) > > Here is the output of lspci: > > khk@specht:~ > /sbin/lspci > 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] > 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) > 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) > 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) > 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) > 00:09.0 Multimedia video controller: Zoran Corporation ZR36057PQC Video cutting >chipset (rev 02) > 00:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 21) > 00:0f.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 > 00:11.0 SCSI storage controller: Adaptec AHA-7850 (rev 03) > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) > > I can provide more information on request, I can also test patches - I have a test > partition that I'm using to test new kernel configurations without affecting my > "normal" system. > > I am following the list only through the archives on the web, so if you want to > get in touch with me, please CC [EMAIL PROTECTED] > > Karl Heinz > > -- Arjan Filius mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: udp <-> tcp connect
Hello! > I want to bind to non-local IP and send/receive UDP packets. This is impossible, apparently. > but in tcp_v4_connect: > tmp = ip_route_connect(&rt, nexthop, sk->saddr, > RT_TOS(sk->ip_tos)|RTO_CONN|sk->localroute, sk->bound_dev_if); > ^^^ And this is __terrible__ bug. RTO_CONN cannot be set here. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE driver status ?
I'm not overclocking. It's an ASUS A7Pro with Athlon 1000. I
had the same problem with an ASUS K7V with Athlon 700. But
the processor died after my cooler failed for 20 minutes!
BTW, how do I know if my cable is ATA100/ATA66, not only ATA66
? The manual from the A7Pro says it supports both, but at the
site it says the cable shipped with this motherboard is ATA66.
On Sat, Mar 31, 2001 at 12:00:41PM -0600, Glenn C. Hofmann wrote:
> I am not sure if this applies in your case, but I was getting problems
> such as this on my Abit KT7-RAID and had the correct cables, also. One
> day, on a hunch after reading a post from Alan about overclocking, I
> took my Athlon 750 down to 850 from 1.05 GHz and all is working great
> now. If your overclocking, I would suggest not doing so (at least not
> so much), based on my experience. I am also using the v4.0 driver.
>
> Chris
>
> On 31 Mar 2001 00:41:32 -0300, Frédéric L. W. Meunier wrote:
> > Hi. I really can't get UDMA66 with the VIA driver. I tried
> > everything, also a new motherboard (ASUS A7Pro) with a
> > ATA100/ATA66 cable (using both ends...)!
> >
> > All I get are the usual CRC error messages.
> >
> > So, there's no UDMA66 for any vt82c686a ? I'm using 2.4.3.
> >
> > If there's no UDMA66, what are the advantages using this
> > driver ?
> >
> > TIA.
--
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]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE driver status ?
I am not sure if this applies in your case, but I was getting problems
such as this on my Abit KT7-RAID and had the correct cables, also. One
day, on a hunch after reading a post from Alan about overclocking, I
took my Athlon 750 down to 850 from 1.05 GHz and all is working great
now. If your overclocking, I would suggest not doing so (at least not
so much), based on my experience. I am also using the v4.0 driver.
Chris
On 31 Mar 2001 00:41:32 -0300, Frédéric L. W. Meunier wrote:
> Hi. I really can't get UDMA66 with the VIA driver. I tried
> everything, also a new motherboard (ASUS A7Pro) with a
> ATA100/ATA66 cable (using both ends...)!
>
> All I get are the usual CRC error messages.
>
> So, there's no UDMA66 for any vt82c686a ? I'm using 2.4.3.
>
> If there's no UDMA66, what are the advantages using this
> driver ?
>
> TIA.
>
> --
> 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]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: add-single-device won't work in 2.4.3
Armin, It works for me: $ uname -a Linux frig 2.4.3 #1 Fri Mar 30 16:33:45 EST 2001 i586 unknown $ cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: IBM Model: DNES-309170W Rev: SA30 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi2 Channel: 00 Id: 05 Lun: 00 Vendor: UMAX Model: Astra 1220S Rev: V1.2 Type: Scanner ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 06 Lun: 00 Vendor: YAMAHA Model: CRW4416S Rev: 1.0g Type: CD-ROM ANSI SCSI revision: 02 $ echo "scsi remove-single-device 2 0 5 0" > /proc/scsi/scsi $ cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: IBM Model: DNES-309170W Rev: SA30 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi2 Channel: 00 Id: 06 Lun: 00 Vendor: YAMAHA Model: CRW4416S Rev: 1.0g Type: CD-ROM ANSI SCSI revision: 02 $ echo "scsi add-single-device 2 0 5 0" > /proc/scsi/scsi $ cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: IBM Model: DNES-309170W Rev: SA30 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi2 Channel: 00 Id: 06 Lun: 00 Vendor: YAMAHA Model: CRW4416S Rev: 1.0g Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 05 Lun: 00 Vendor: UMAX Model: Astra 1220S Rev: V1.2 Type: Scanner ANSI SCSI revision: 02 $ sg_scan -i /dev/sg0: scsi1 channel=0 id=1 lun=0 type=0 IBM DNES-309170W SA30 [wide=1 sync=1 cmdq=1 sftre=0 pq=0x0] /dev/sg1: scsi2 channel=0 id=6 lun=0 type=5 YAMAHACRW4416S 1.0g [wide=0 sync=1 cmdq=0 sftre=0 pq=0x0] /dev/sg2: scsi2 channel=0 id=5 lun=0 type=6 UMAX Astra 1220S V1.2 [wide=0 sync=0 cmdq=0 sftre=0 pq=0x0] This last command is from sg_utils and it sends actual INQUIRY commands rather than relying on data held in the midlayer. This demonstrates the devices are responding. Run on a AMD K6-2 500MHz machine with 2 advansys adapters. Could you retest. If it continues to fail then it may be a problem with the new aic7xxx driver. You also have the option of building with the "old" (i.e. former) aic7xxx driver. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
using ioctls (was: RE: Larger dev_t)
Hi- Tangential question (I think). Not for an IOCTL request 8;) [as the JFS request last week]. [When] is it OK to use (new) IOCTLs vs. using procfs read/write? And are there some alternative methods besides these two? Thanks, ~Randy > -Original Message- > From: Linus Torvalds [mailto:[EMAIL PROTECTED]] > ... > We should encourage people to not need major numbers. It's easy. The > driver exports a /proc entry in /proc/driver/xxx or similar . Or the > driver writer says "if you want to use this device, use devfs", and > exports the name there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux connectivity trashed.
On Thu, Mar 29, 2001 at 08:34:06AM -0500, Richard B. Johnson wrote: > So, now I hooked up my lap-top, installed Windows and here I am. > Only windows machines are allowed to access the outside world. That is a shame. I can think of two things that might be of use under these circumstances: - Recent MS operating systems offer a limited version of IP masquerading; - Monster.com has numerous jobs available. Best luck for a speedy resolution. -- John Kodis <[EMAIL PROTECTED]> Phone: 301-286-7376 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Matrox G400 Dualhead
> I have a similar problem with my G450, booting into the framebuffer, > then loading xdm and working in X, and then switching back to the > console. I may have another detail to add in that when I switch back > to the console from X, my monitor blanks and displays the warning > that the frequencies are out of range. I think I have a work around. Boot up 2.4.3 with the framebuffer enabled as normal. Log in as root and use the fbset program to change the settings for all the framebuffers. eg. fbset -a 1024x768-70 or whatever works for you. fbset has its own man page. This makes everything hunky-dory for me, in that after running fbset I can go in and out of X without ever losing the video signal. Petr, I had a look at the drivers/video/matrox subdir and there's no difference between 2.4.2 and 2.4.3, however there are differences in the drivers/video dir to do with framebuffers. The files that have been changed in drivers/video/ are: creatorfb.c fbmem.c fonts.c modedb.c sbus.c I know nothing about the nature of the changes that have been made though! It does seem to be a kernel problem rather than a X4.0.3 problem seeing as how 4.0.3 works fine under 2.4.2, and that using fbset on the framebuffer console in 2.4.3 solves the problem. John [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug report: select on unconnected sockets
On Sun, 1 Apr 2001 02:15 +1000, john slee wrote:
> On Sat, Mar 31, 2001 at 06:44:20PM +0300, Radu Greab wrote:
> > Sorry if this is already known: on a RH 7.0 system with kernel 2.4.2
> > or 2.4.3, a select on an unconnected socket incorrectly says that the
> > socket is ready for input and output. Of course, reading from the socket
> > file descriptor returns -1 and errno is set to ENOTCONN as shown in
> > the strace output:
> >
> > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
> > select(4, [3], [3], [3], {0, 0})= 2 (in [3], out [3], left {0, 0})
> > read(3, 0xb668, 1024) = -1 ENOTCONN (Transport endpoint is not
>connected)
> >
> > I attached a small example program to reproduce the bug.
>
> bleah. which one is supposed to be right?
I think that the Solaris one is right.
>
> linux 2.4
> -
> $ uname -a
> Linux X 2.4.2-ac20 #8 Wed Mar 14 01:53:05 EST 2001 i686 unknown
> $ ./t
> select result=2
> read: Transport endpoint is not connected
Select says that the socket is ready for both input and output. A read
results in ENOTCONN, a write results in EPIPE.
> linux 2.2
> -
> $ uname -a
> Linux X 2.2.18 #1 Thu Dec 21 21:13:10 EST 2000 i586 unknown
> $ ./t
> select result=1
Select says that the socket is ready for output, but a write results
in EPIPE.
>
> solaris
> ---
> $ uname -a
> SunOS X 5.7 Generic_106541-07 sun4m sparc sun4m
> $ ./t
> select result=0
And Digital Unix is right too:
$ uname -a
OSF1 XXX V4.0 1229 alpha
$ ./a.out
select result=0
Thanks,
Radu Greab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bug report: select on unconnected sockets
On Sat, Mar 31, 2001 at 06:44:20PM +0300, Radu Greab wrote:
> Sorry if this is already known: on a RH 7.0 system with kernel 2.4.2
> or 2.4.3, a select on an unconnected socket incorrectly says that the
> socket is ready for input and output. Of course, reading from the socket
> file descriptor returns -1 and errno is set to ENOTCONN as shown in
> the strace output:
>
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
> select(4, [3], [3], [3], {0, 0})= 2 (in [3], out [3], left {0, 0})
> read(3, 0xb668, 1024) = -1 ENOTCONN (Transport endpoint is not
>connected)
>
> I attached a small example program to reproduce the bug.
bleah. which one is supposed to be right?
linux 2.4
-
$ uname -a
Linux X 2.4.2-ac20 #8 Wed Mar 14 01:53:05 EST 2001 i686 unknown
$ ./t
select result=2
read: Transport endpoint is not connected
linux 2.2
-
$ uname -a
Linux X 2.2.18 #1 Thu Dec 21 21:13:10 EST 2000 i586 unknown
$ ./t
select result=1
solaris
---
$ uname -a
SunOS X 5.7 Generic_106541-07 sun4m sparc sun4m
$ ./t
select result=0
--
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Possible SCSI + block-layer bugs
Hi,
I've never seen these trigger, but they look theoretically possible.
When processing the completion of a SCSI request in a bottom-half,
__scsi_end_request() can find all the buffers associated with the request
haven't been completed (ie. leftovers).
One question is; can this ever happen?
If it can't then the code should be removed from __scsi_end_request(),
if it can happen then there appears to be a few problems;
The request is re-queued to the block layer via
scsi_queue_next_request(), which uses the "special" pointer in the request
structure to remember the Scsi_Cmnd associated with the request. The SCSI
request function is then called, but doesn't guarantee to immediately
process the re-queued request even though it was added at the head (say,
the queue has become plugged). This can trigger two possible bugs.
The first is that __scsi_end_request() doesn't decrement the
hard_nr_sectors count in the request. As the request is back on the
queue, it is possible for newly arriving buffer-heads to merge with the
heads already hanging off the request. This merging uses the
hard_nr_sectors when calculating both the merged hard_nr_sectors and
nr_sectors counts.
As the request is at the head, only back-merging can occur, but if
__scsi_end_request() triggers another uncompleted request to be re-queued,
it is possible to get front merging as well.
The merging of a re-queued request looks safe, except for the
hard_nr_sectors. This patch corrects the hard_nr_sectors accounting.
The second bug is from request merging in attempt_merge().
For a re-queued request, the request structure is the one embedded in
the Scsi_Cmnd (which is a copy of the request taken in the
scsi_request_fn).
In attempt_merge(), q->merge_requests_fn() is called to see the requests
are allowed to merge. __scsi_merge_requests_fn() checks number of
segments, etc, but doesn't check if one of the requests is a re-queued one
(ie. no test against ->special).
This can lead to attempt_merge() releasing the embedded request
structure (which, as an extract copy, has the ->q set, so to
blkdev_release_request() it looks like a request which originated from
the block layer). This isn't too healthy.
The fix here is to add a check in __scsi_merge_requests_fn() to check
for ->special being non-NULL.
The attached patch is against 2.4.3.
Jens, Eric, anyone, comments?
Mark
diff -urN -X dontdiff linux-2.4.3/drivers/scsi/scsi_lib.c
markhe-2.4.3/drivers/scsi/scsi_lib.c
--- linux-2.4.3/drivers/scsi/scsi_lib.c Sat Mar 3 02:38:39 2001
+++ markhe-2.4.3/drivers/scsi/scsi_lib.cSat Mar 31 16:56:31 2001
@@ -377,12 +377,15 @@
nsect = bh->b_size >> 9;
blk_finished_io(nsect);
req->bh = bh->b_reqnext;
- req->nr_sectors -= nsect;
- req->sector += nsect;
bh->b_reqnext = NULL;
sectors -= nsect;
bh->b_end_io(bh, uptodate);
if ((bh = req->bh) != NULL) {
+ req->hard_sector += nsect;
+ req->hard_nr_sectors -= nsect;
+ req->sector += nsect;
+ req->nr_sectors -= nsect;
+
req->current_nr_sectors = bh->b_size >> 9;
if (req->nr_sectors < req->current_nr_sectors) {
req->nr_sectors = req->current_nr_sectors;
diff -urN -X dontdiff linux-2.4.3/drivers/scsi/scsi_merge.c
markhe-2.4.3/drivers/scsi/scsi_merge.c
--- linux-2.4.3/drivers/scsi/scsi_merge.c Fri Feb 9 19:30:23 2001
+++ markhe-2.4.3/drivers/scsi/scsi_merge.c Sat Mar 31 16:38:27 2001
@@ -597,6 +597,13 @@
Scsi_Device *SDpnt;
struct Scsi_Host *SHpnt;
+ /*
+* First check if the either of the requests are re-queued
+* requests. Can't merge them if they are.
+*/
+ if (req->special || next->special)
+ return 0;
+
SDpnt = (Scsi_Device *) q->queuedata;
SHpnt = SDpnt->host;
bug report: select on unconnected sockets
Sorry if this is already known: on a RH 7.0 system with kernel 2.4.2
or 2.4.3, a select on an unconnected socket incorrectly says that the
socket is ready for input and output. Of course, reading from the socket
file descriptor returns -1 and errno is set to ENOTCONN as shown in
the strace output:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
select(4, [3], [3], [3], {0, 0})= 2 (in [3], out [3], left {0, 0})
read(3, 0xb668, 1024) = -1 ENOTCONN (Transport endpoint is not
connected)
I attached a small example program to reproduce the bug.
Thanks,
Radu Greab
PS: please CC me your eventual replies as I'm not subscribed to the
list.
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
fd_set rfds, wfds, efds;
int s, rc;
struct timeval timeout;
char buf[1025];
s = socket(PF_INET, SOCK_STREAM, 0);
if (s == -1) {
perror("couldn't create socket");
return -1;
}
FD_ZERO(&rfds);
FD_SET(s, &rfds);
FD_ZERO(&wfds);
FD_SET(s, &wfds);
FD_ZERO(&efds);
FD_SET(s, &efds);
timeout.tv_sec = timeout.tv_usec = 0;
rc = select(s + 1, &rfds, &wfds, &efds, &timeout);
if (rc == -1) {
perror("select");
return -1;
}
printf("select result=%d\n", rc);
if (FD_ISSET(s, &rfds)) {
rc = read(s, buf, 1024);
if (rc == -1) {
perror("read");
return -1;
}
printf("read result=%d\n", rc);
}
return 0;
}
2.4.3 compile fail (conflicting types) - Alpha processor - init/main.c
I didn't turn up a previous reference to this with a quick search in the mailing list archive, so here it goes. Compiling 2.4.3 on an Alpha processor system failed on 'init/main.c' with 'conflicting types' errors for 'pte_alloc' and 'pmd_alloc'. If I'm reading things right, it's a discrepency between 'include/asm/pgalloc.h' and 'include/linux/mm.h'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP layer bug?
Hello! > Hm. But comment in linux/skbuff.h says: The comment is about more difficult case: transmit path, where cb is used both by top level protocol and lower layers: f.e. TCP -> IP -> device. cb is dirty from the moment of skb creation in this case. Also, note that the second sentence in the comment is obsolete. Passing not cloned skbs between layers is strongly deprecated practice (I hope it is not used in any place) and cb of skb entering to lower layer is property of the layer. RX path is simpler: cb must be kept clean, that's all. General rule is minimization redundant clearings of the area. > Why not document it somewhere, so that others will not fall into the same trap? Indeed. 8) You got the experience, which you expect to be useful for people, it is time to prepare some note recording this. 8) Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Minor 2.4.3 Adaptec Driver Problems
>I just got 2.4.3 up a running (on Abit BP6 Dual Celeron ) and >it reorderd my SCSI id's. Take a look. I don't like that my ZIP drive >becomes sda because if I ever remove it then I'll @#$% my harddrive dev >mappings again and have to change them again. Adaptec Driver 6.1.5 >:-( Upgrade to version 6.1.8 of the aic7xxx driver from here. This was fixed just after 6.1.5 was released: http://people.FreeBSD.org/~gibbs/linux Use the 2.4.3-pre6 patch. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: add-single-device won't work in 2.4.3
>hi! > >as in the subject, yesterday i upgraded to 2.4.3 (plain, no patches). >add-single-device/del-single-device did not work anymore. > >tried with: > >controller: adaptec-19160 >device: yamaha-4260 Do you get any error messages? Does the problem persist with the latest driver? http://people.FreeBSD.org/~gibbs/linux Use the 2.4.3-pre6 patch. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP layer bug?
Hello! On Fri, Mar 30, 2001 at 09:13:40PM +0400, [EMAIL PROTECTED] wrote: > >For now I workarounded it with filling skb->cb with zeroes before > >netif_rx(), > This is right. For another examples look into tunnels. Hm. But comment in linux/skbuff.h says: /* * This is the control buffer. It is free to use for every * layer. Please put your private variables there. If you * want to keep them across layers you have to do a skb_clone() * first. This is owned by whoever has the skb queued ATM. */ Which does not imply I should clear buffer after I am passing ownership. > > but I believe it is a kludge and networking layer should be fixed instead. > No. > alloc_skb() creates skb with clean cb. ip_rcv() and other protocol handlers > do not redo this work. If device uses cb internally, it must clear it > before handing skb to netif_rx(). Why not document it somewhere, so that others will not fall into the same trap? Bye, Oleg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Version 6.1.6 of the aic7xxx driver availalbe
>I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scsi >bus. >I also upgraded to the "latest" aic7xxx driver but still the sam problems. >A typical revery in my logs. Can you resend the recovery information after booting with "aic7xxx=verbose". This will provide more information about the timeout which will hopefully allow me to narrow down the problem. A full dmesg of the system would be useful too as that will include the device inquiry data. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kmap performance
Hi,
Two performance changes against 2.4.3.
flush_all_zero_pkmaps() is guarding against a race which cannot happen,
and thus hurting performance.
It uses the atomic fetch-and-clear "ptep_get_and_clear()" operation,
which is much stronger than needed. No-one has the page mapped, and
cannot get at the page's virtual address without taking the kmap_lock,
which flush_all_zero_pkmaps() holds. Even with speculative execution,
there are no races which need to be closed via an atomic op.
On a two-way, Pentium-III system, flush_all_zero_pkmaps() was taking
over 200K CPU cycles (with the flush_tlb_all() only accounting for ~9K of
those cycles).
This patch replaces ptep_get_and_clear() with a pte_page(), and
pte_clear(). This reduces flush_all_zero_pkmaps() to around 75K cycles.
The second part of this patch adds a conditional guard to the
wake_up() call in kunmap_high().
With most usage patterns, a page will not be simultaneously mapped more
than once, hence the most common case (by far) is for pkmap_count[] to
decrement to 1. This was causing an unconditional call to wake_up(), when
(again) the common case is to have no tasks in the wait-queue.
This patches adds a guard to the wake_up() using an inlined
waitqueue_active(), and so avoids unnecessary function calls.
It also drops the actual wake_up() to be outside of the spinlock. This
is safe, as any waiters will have placed themselves onto the queue under
the kmap_lock, and kunmap_high() tests the queue under this lock.
Mark
diff -urN -X dontdiff linux-2.4.3/mm/highmem.c markhe-2.4.3/mm/highmem.c
--- linux-2.4.3/mm/highmem.cTue Nov 28 20:31:02 2000
+++ markhe-2.4.3/mm/highmem.c Sat Mar 31 15:03:43 2001
@@ -46,7 +46,7 @@
for (i = 0; i < LAST_PKMAP; i++) {
struct page *page;
- pte_t pte;
+
/*
* zero means we don't have anything to do,
* >1 means that it is still in use. Only
@@ -56,10 +56,21 @@
if (pkmap_count[i] != 1)
continue;
pkmap_count[i] = 0;
- pte = ptep_get_and_clear(pkmap_page_table+i);
- if (pte_none(pte))
+
+ /* sanity check */
+ if (pte_none(pkmap_page_table[i]))
BUG();
- page = pte_page(pte);
+
+ /*
+* Don't need an atomic fetch-and-clear op here;
+* no-one has the page mapped, and cannot get at
+* its virtual address (and hence PTE) without first
+* getting the kmap_lock (which is held here).
+* So no dangers, even with speculative execution.
+*/
+ page = pte_page(pkmap_page_table[i]);
+ pte_clear(&pkmap_page_table[i]);
+
page->virtual = NULL;
}
flush_tlb_all();
@@ -139,6 +150,7 @@
{
unsigned long vaddr;
unsigned long nr;
+ int need_wakeup;
spin_lock(&kmap_lock);
vaddr = (unsigned long) page->virtual;
@@ -150,13 +162,31 @@
* A count must never go down to zero
* without a TLB flush!
*/
+ need_wakeup = 0;
switch (--pkmap_count[nr]) {
case 0:
BUG();
case 1:
- wake_up(&pkmap_map_wait);
+ /*
+* Avoid an unnecessary wake_up() function call.
+* The common case is pkmap_count[] == 1, but
+* no waiters.
+* The tasks queued in the wait-queue are guarded
+* by both the lock in the wait-queue-head and by
+* the kmap_lock. As the kmap_lock is held here,
+* no need for the wait-queue-head's lock. Simply
+* test if the queue is empty.
+*/
+ need_wakeup = waitqueue_active(&pkmap_map_wait);
}
spin_unlock(&kmap_lock);
+
+ /*
+* Can do wake-up, if needed, race-free outside of
+* the spinlock.
+*/
+ if (need_wakeup)
+ wake_up(&pkmap_map_wait);
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for 2.5
On 2001-03-31T09:36:33, James Lewis Nance <[EMAIL PROTECTED]> said: > > > 4) What is the time frame of releasing 2.5.x-final (or 2.6.x) ? > > wow that's jumping the gun a bit. > But its easy to answer. It will come out about 1 year after whatever > target date we initially set :-) Sorry, s/we initially set/we assume at any given time/. (Recursion, noun: see recursion) Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for 2.5
On Fri, Mar 30, 2001 at 07:54:44PM -0800, Joel Jaeggli wrote: > On Thu, 29 Mar 2001, Hen, Shmulik wrote: > > 4) What is the time frame of releasing 2.5.x-final (or 2.6.x) ? > > wow that's jumping the gun a bit. But its easy to answer. It will come out about 1 year after whatever target date we initially set :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent problems with APM and XFree86-4.0.1
Stephen Rothwell wrote: > > On that theme of power management with X problems, I have been having > > trouble with my laptop crashing when the lid is closed, instead of > > suspending as it used to. The laptop is a Toshiba Satellite 4070CDT. > > Can you please try adding > Option "NoPM" > to the device section of XF86Config or (XF86Config) and then try suspending > and resuming. > > This made suspend/resume much more reliable on the Thinkpad 600E with > XFree86 4. Also you could try XFree86 4.0.2, as I know that it actually > does interact with APM (4.0.1 may have as well - I am not sure). I'll try Option "NoPM", and XFree86 4.0.2 if I can find a conveniently RH7 compatible RPM. I should point out that I've been using _some_ version of XFree86 4 since before version 4.0 was released. (XFree86 3 doesn't support this laptop's video adapter). Suspend/resume worked fine and reliably until recently. Another problem is that occasionally when X starts now, it will freeze the system. So I suspect a bug was introduced in XFree86 4.0.1. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTRR on AMD THUNDERBIRD
On Sat, 31 Mar 2001, Stephen E. Clark wrote: > Anyone know the status of mtrr the AMD Thunderbird? It does not seem to > work for me anymore. > reg00: base=0x ( 0MB), size=16711936MB: write-back, count=1 > Linux version 2.4.2-ac18 ([EMAIL PROTECTED]) (gcc version ^^ Fixed in 2.4.2-ac20 and higher. Read Changelogs 8) regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
James Simmons wrote: > > > You have same toshiba satellite as me, right? > > > > Yes > > Is this the NeoMagic chipset? No, it's the Trident Cyber9525 -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problem in drivers/block/Config.in (PATCH)
On Fri, Mar 30, 2001 at 10:17:08PM +0200, Herbert Rosmanith wrote: > > hi, > > I noticed that the option CONFIG_PARIDE_PARPORT will always be "y", > even if CONFIG_PARIDE_PARPORT="n". I checked with kernels 2.2.18 > and 2.2.19. > > the file responsible is "drivers/block/Config.in", around line 126. > it reads: > > # PARIDE doesn't need PARPORT, but if PARPORT is configured as a module, > # PARIDE must also be a module. The bogus CONFIG_PARIDE_PARPORT option > # controls the choices given to the user ... > > if [ "$CONFIG_PARPORT" = "y" -o "$CONFIG_PARPORT" = "n" ] ; then >define_bool CONFIG_PARIDE_PARPORT y > else >define_bool CONFIG_PARIDE_PARPORT m > fi > > so, as you can see, CONFIG_PARIDE_PARPORT will be set to "yes" even > if CONFIG_PARPORT="no". > > why not simply write: > > define_bool CONFIG_PARIDE_PARPORT $CONFIG_PARPORT > > instead? In fact, if we want to get what is said in the comment, we should write: if [ "$CONFIG_PARPORT" = "m" -a "$CONFIG_PARIDE_PARPORT" = "y" ] ; then define_bool CONFIG_PARIDE_PARPORT m fi regards, Balazs Pozsar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcnet32 (maybe more) hosed in 2.4.3
On Fri, 30 Mar 2001, Scott G. Miller wrote:
> Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in
> 2.4.3, pcnet32 loads, gives an error message:
2.4.3 (and -ac's) are also broken as guest in VMWware due to the pcnet32
changes [doing 32 bit IO on 16 bit regs on the 79C970A controller].
Reverting this part of patch-2.4.3 below made things work again.
Szaka
@@ -528,11 +535,13 @@
pcnet32_dwio_reset(ioaddr);
pcnet32_wio_reset(ioaddr);
-if (pcnet32_wio_read_csr (ioaddr, 0) == 4 && pcnet32_wio_check (ioaddr)) {
- a = &pcnet32_wio;
+/* Important to do the check for dwio mode first. */
+if (pcnet32_dwio_read_csr(ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
+a = &pcnet32_dwio;
} else {
- if (pcnet32_dwio_read_csr (ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
- a = &pcnet32_dwio;
+if (pcnet32_wio_read_csr(ioaddr, 0) == 4 &&
+ pcnet32_wio_check(ioaddr)) {
+ a = &pcnet32_wio;
} else
return -ENODEV;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
add-single-device won't work in 2.4.3
hi! as in the subject, yesterday i upgraded to 2.4.3 (plain, no patches). add-single-device/del-single-device did not work anymore. tried with: controller: adaptec-19160 device: yamaha-4260 MfG, Armin Obersteiner -- [EMAIL PROTECTED]pgp public key on requestCU - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE Disk Corruption with 2.4.3 / NOT with AC kernels
I run into some major disk corruptions on my IDE disk with the new 2.4.3 kernel version. I did see the same corruptions with 2.4.2 - but back then I blamed reiserfs and went back to 2.4.1. Now I did some more testing and found out that the Alan Cox series of kernel patches does not show these problems. I tried one from the 2.4.1-ac series (I think it was ac8) and 2.4.2-ac20 with nothing but success. I was using the same .config file for all tests to make sure that the problem was not caused by a kernel configuration issue. This is my hardware: - ABit KT7 board (KT133 chipset reported by lspci) - 1GHz Athlon - QUANTUM FIREBALLP AS40.0 disk (cat /proc/ide/hda/model) Here is the output of lspci: khk@specht:~ > /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:09.0 Multimedia video controller: Zoran Corporation ZR36057PQC Video cutting chipset (rev 02) 00:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 21) 00:0f.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 00:11.0 SCSI storage controller: Adaptec AHA-7850 (rev 03) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) I can provide more information on request, I can also test patches - I have a test partition that I'm using to test new kernel configurations without affecting my "normal" system. I am following the list only through the archives on the web, so if you want to get in touch with me, please CC [EMAIL PROTECTED] Karl Heinz PGP signature
MTRR on AMD THUNDERBIRD
Anyone know the status of mtrr the AMD Thunderbird? It does not seem to work for me anymore. cat /proc/mtrr reg00: base=0x ( 0MB), size=16711936MB: write-back, count=1 joker:/ # echo "base=0xd400 size=0x200 type=write-combining" >| /proc/mtrr joker:/ # cat /proc/mtrr reg00: base=0x ( 0MB), size=16711936MB: write-back, count=1 Linux version 2.4.2-ac18 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 Mon Mar 19 17:42:56 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 3000 @ 0fff (ACPI NVS) BIOS-e820: d000 @ 0fff3000 (ACPI data) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 65536 zone(0): 4096 pages. zone(1): 61440 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=l-2.4.2ac18pnp ro root=1601 ramdisk=0 mem=256M Initializing CPU#0 Detected 800.056 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1595.80 BogoMIPS Memory: 255176k/262144k available (1327k kernel code, 6580k reserved, 422k data, 224k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. 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 0xfb430, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Bus master Pipeline request disabled PCI: Disabled enhanced CPU to PCI writes PCI: Bursting cornercase bug worked around PCI: Post Write Fail set to Retry PCI: Using IRQ router VIA [1106/0686] at 00:07.0 isapnp: Scanning for PnP cards... isapnp: Card 'SMC EtherEZ (8416)' isapnp: 1 Plug & Play card detected total Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd v1.8 parport_pc: Strange, can't probe Via 686A parallel port: io=0x378, irq=7, dma=-1parport0: PC-style at 0x378 [PCSPP(,...)] also *** any ideas about the above message * i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. i2c-algo-bit.o: i2c bit algorithm module pty: 256 Unix98 ptys configured lp0: using parport0 (polling). block: queued sectors max/low 169546kB/56515kB, 512 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 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 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA hda: JTS CORPORATION CHAMPION MODEL C3200-2A, ATA DISK drive hdb: Maxtor 91366U4, ATA DISK drive hdc: Maxtor 53073H4, ATA DISK drive hdd: ATAPI 52X CDROM, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 6306048 sectors (3229 MB) w/512KiB Cache, CHS=6256/16/63, DMA hdb: 26684784 sectors (13663 MB) w/2048KiB Cache, CHS=1661/255/63, UDMA(66) hdc: 60030432 sectors (30736 MB) w/2048KiB Cache, CHS=59554/16/63, UDMA(66) hdd: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 hda3 hda4 hdb: hdb1 hdb2 hdb3 hdc: hdc1 hdc2 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 smc-ultra.c: ISAPnP reports SMC EtherEZ (8416) at i/o 0x240, irq 5. smc-ultra.c:v2.02 2/3/98 Donald Becker ([EMAIL PROTECTED]) eth0: SMC EtherEZ at 0x240, 00 E0 29 03 E5 92,assigned IRQ 5 memory 0xc8000-0xc9fff. SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256). loop: loaded (max 8 devices) Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 1655
Minor 2.4.3 Adaptec Driver Problems
I just got 2.4.3 up a running (on Abit BP6 Dual Celeron ) and it reorderd my SCSI id's. Take a look. I don't like that my ZIP drive becomes sda because if I ever remove it then I'll @#$% my harddrive dev mappings again and have to change them again. Adaptec Driver 6.1.5 :-( <2.4.3 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 10, lun 0 Detected scsi removable disk sdc at scsi1, channel 0, id 0, lun 0 Detected scsi CD-ROM sr0 at scsi1, channel 0, id 1, lun 0 Detected scsi CD-ROM sr1 at scsi1, channel 0, id 2, lun 0 >2.4.3 Detected scsi removable disk sda at scsi0, channel 0, id 0, lun 0 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 1, lun 0 Detected scsi CD-ROM sr1 at scsi0, channel 0, id 2, lun 0 Detected scsi disk sdb at scsi1, channel 0, id 6, lun 0 Detected scsi disk sdc at scsi1, channel 0, id 10, lun 0 I am not a participant on this mail list so please mail replies directly to me. Earle _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile linux 0.0.0.1?
Alan Olsen writes: > On Fri, 30 Mar 2001, Bruno Avila wrote: > > >I can't find this anywhere. What is the version of the tools to > > compile linux kernel 0.0.0.1 (../Historic)? And where can i find them? > > Well, first you have to find a good source of obsidean, a couple of sharp > rocks, and some flint... If you wish to make a [kernel] truly from scratch, you must first invent the universe. -Carl Saga -- Drew Bertola | Send a text message to my pager or cell ... | http://jpager.com/Drew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Version 6.1.6 of the aic7xxx driver availalbe
I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scsi bus. I also upgraded to the "latest" aic7xxx driver but still the sam problems. A typical revery in my logs. Mar 31 09:34:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:35 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:35 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:35 pescadero kernel: Recovery code sleeping Mar 31 09:34:40 pescadero kernel: Recovery code awake Mar 31 09:34:40 pescadero kernel: Timer Expired Mar 31 09:34:40 pescadero kernel: aic7xxx_abort returns 8195 Mar 31 09:34:40 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:40 pescadero kernel: Recovery SCB completes Mar 31 09:34:40 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:40 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:40 pescadero kernel: Recovery code sleeping Mar 31 09:34:40 pescadero kernel: Recovery code awake Mar 31 09:34:40 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:34:50 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Device is active, asserting ATN Mar 31 09:34:50 pescadero kernel: Recovery code sleeping Mar 31 09:34:55 pescadero kernel: Recovery code awake Mar 31 09:34:55 pescadero kernel: Timer Expired Mar 31 09:34:55 pescadero kernel: aic7xxx_abort returns 8195 Mar 31 09:34:55 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:55 pescadero kernel: Recovery SCB completes Mar 31 09:34:55 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:55 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:55 pescadero kernel: Recovery code sleeping Mar 31 09:34:55 pescadero kernel: Recovery code awake Mar 31 09:34:55 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:05 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:05 pescadero kernel: Recovery SCB completes Mar 31 09:35:05 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:05 pescadero kernel: Recovery code sleeping Mar 31 09:35:05 pescadero kernel: Recovery code awake Mar 31 09:35:05 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:15 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:15 pescadero kernel: Recovery SCB completes Mar 31 09:35:15 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:15 pescadero kernel: Recovery code sleeping Mar 31 09:35:15 pescadero kernel: Recovery code awake Mar 31 09:35:15 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:25 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:25 pescadero kernel: Recovery SCB completes Mar 31 09:35:25 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:25 pescadero kernel: Recovery code sleeping Mar 31 09:35:25 pescadero kernel: Recovery code awake Mar 31 09:35:25 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:35 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:35 pescadero kernel: Recovery SCB completes Mar 31 09:35:35 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:35 pescadero kernel: Recovery code sleeping Mar 31 09:35:35 pescadero kernel: Recovery code awake Mar 31 09:35:35 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:45 pescadero kernel: scsi0:0:4:0: Attemptin
