Re: Incorrect UDMA timing on VIA vt82c596b
Hi!
Ok, that means Andre's patch works. Congrats, Andre! Now, could you send
me 'hdparm -i /dev/hdb' for the ZIP? It seems to be in SWDMA0 mode,
which is interesting, because I thought it can't do that. You probably
have some newer model.
Do all your drives work correctly now?
Thanks for your effort,
Vojtech
On Tue, Oct 10, 2000 at 06:40:42AM -0500, Jordan wrote:
I am currently booted into a 2.4.0-test10-pre1 kernel with two
modifications, the VIA 3.6 drivers you have provided and the Patch from
Andre that you sent. My IBM is the primary master with the zip as its
slave and the Kenwood is the secondary master with the Plextor as its
slave. Here is my /proc/ide/via file:
--VIA BusMastering IDE Configuration
Driver Version: 3.6
South Bridge: VIA vt82c596b (cf/cg)
Revision: ISA 0x23 IDE 0x10
BM-DMA base:0xd000
PCI clock: 33MHz
Master Read Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
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:yes yes
Prefetch Buffer: yes yes
Post Write Buffer:yes yes
Enabled: yes yes
Simplex only: no no
---drive0drive1drive2drive3-
Transfer Mode: UDMA DMA UDMA DMA
Address Setup: 30ns 60ns 30ns 30ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery:90ns 90ns 30ns 30ns
Data Active: 90ns 240ns 90ns 90ns
Data Recovery: 30ns 240ns 30ns 30ns
Cycle Time: 30ns 480ns 60ns 120ns
Transfer Rate: 66.0MB/s 4.1MB/s 33.0MB/s 16.5MB/s
Here is the apporiate portion of /var/log/dmesg:
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: VIA vt82c596b (cf/cg) IDE UDMA66 controller on pci0:7.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IBM-DTLA-307075, ATA DISK drive
hdb: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
hdc: KENWOOD CD-ROM UCR-421 V226G, ATAPI CDROM drive
hdd: PLEXTOR CD-R PX-W1210A, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=9345/255/63, UDMA(66)
hdc: ATAPI 68X CD-ROM drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.11
hdb: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdb: set_drive_speed_status: error=0x04
hdb: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
Partition check:
hda: hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 hda10 hda11
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.4.0-test9 and Cisco Pix Firewall - Might be a bug???
echo "0" /proc/sys/net/ipv4/tcp_ecn Yes, Cisco does know about the bug in their product. Later, David S. Miller [EMAIL PROTECTED] -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
RE: getting struct pci_dev from struct netdevice
hi all, given struct netdevice for any pci network device, is there any way to get corresponding "struct pci_dev". No. Not directly, but pci_dev knows about netdevice, so you can scan the pci_dev's to find a match with the required netdevice. (Or do a similar match search on base_addr) Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Calling current() from interrupt context
Based of my measurement on i386 smp configuration, If a system has plenty of runnable tasks, schedule() produces noticable amount of cache misses at runqueue-head traversing and the goodness calculations. David S. Miller writes: Some of us actually have instrumented it :-) I added a coloring mechanism to the task/kstack allocator on sparc64. It made no noticable difference whatsoever to any real life measurement I attempted. Did you slide task-struct itself? -- Computer Systems Laboratory, Fujitsu Labs. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: getting struct pci_dev from struct netdevice
"Phillips, Mike" wrote: hi all, given struct netdevice for any pci network device, is there any way to get corresponding "struct pci_dev". No. Not directly, but pci_dev knows about netdevice, so you can scan the pci_dev's to find a match with the required netdevice Or really? Exactly how does one do this? (Or do a similar match search on base_addr) Doesn't work on 64-bit platforms, I don't think. Not all net drivers set base_address in any case. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spurious 8259A interrupt?
On Mon, 9 Oct 2000, Daniel Lange wrote: Periodically, I get the following error with the 2.4.0test9 kernel: spurious 8259A interrupt: IRQ7. [SNIPPED...] This will sometimes happen with the 8259A and really should not even be logged. There is a default handler for all interrupts. If this handler gets control from an unallocated interrupt, it writes this message, ACKs the interrupt, then returns. Initializing CPU#0 You are using a SMP kernel on a `386 UP machine. That tends to make these burps show up. It is harmless, though. Console: colour VGA+ 80x25 Calibrating delay loop... 3.10 BogoMIPS This shows something I don't understand. Either the counter wrapped, a timer is mis-programmed, or the CPU clock speed is about 1.5 MHz. You should look into this. Older kernels generally show the BogoMIPS as being about equal to the CPU clock speed +/- 20%. Newer kernels generally show it being about 2 times the clock speed +/- 20%. CPU: 386 Checking 'hlt' instruction... OK. Checking for popad bug... Buggy. I have one of these too. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
[EMAIL PROTECTED] wrote: 3. Security * Fix module remove race bug (still to be done: TTY, ldisc, I2C, video_device - Al Viro) (Rogier Wolff will handle ATM) Patch for tty and ldisc is in your inbox... ... 8. Fix Exists But Isnt Merged ... * Many network device drivers don't call MOD_INC_USE_COUNT in dev-open. (Paul Gortmaker has patches) This should be rephrased "Many network device drivers call MOD_INC_USE_COUNT too late in dev-open()". And it has been proposed (frequently, by me) that the dev_hold()/dev_put()/unregister_netdevice() logic ensures that netdevice drivers are _not_ race prone wrt module removal and so no development is needed here. Unless someone squeaks I suggest you take the red pen to this one. ... 9. To Do ... * Misc locking problems + drivers/pcmcia/ds.c: ds_read ds_write. SMP locks are missing, on UP the sleep_on() use is unsafe. It is my understanding that hen's teeth easily outnumber SMP PCMCIA systems. spinlocks in drivers/pcmcia/ and drivers/net/pcmcia/ are almost nonexistent. So I propose that this item be removed simply by stating "Linux 2.4 does not support PCMCIA on multiprocessors". Comments, David? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SCSI lock-up when scanning with SNAPSCAN1236
Hi There! 1.: SCSI lock-up when scanning with SNAPSCAN1236 2.: I have an AGFA SNAP-scan 1236S and used it with the kernel 2.2.16 and with the new beta-test-kernel 2.4.0-test9. The SCSI-Controller is a aha152x and is working fine with the 2.2.16 kernel except that there is an error message from the aha152x module but the scan is ok: Oct 10 13:19:43 snoopy kernel: aha152x: more data than expected (128 bytes) Oct 10 13:19:43 snoopy kernel: aha152x: data ( 3 3 3 3 3 3 3 3 4 6 6 6 6 7 6 7 37 1d 11 25 2c 16 c 11 ab ff ab 9e 2 25 16 1d 19 19 16 19 20 2a 28 16 0 1d 23 16 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 2 3 3 3 2 3 3 2 2 3 3 3 3 3 3 3 3 2 2 2 3 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 3 3 3 3 5 6 6 6 6 6 6 6 37 1d 11 25 2c 16 c 11 ab ff ab 9d ) But with the new test-kernel only the detection of the scanner is working fine. When I start the scan process the whole SCSI-Bus is locked up. I tested the SCSI bus with and without parity but the problem was still the same (I could only switch off the parity with modifying the code but this is another problem). This is the detection of the scanner by the aha152x-module: Oct 7 18:14:57 snoopy kernel: aha152x0: vital data: rev=3, io=0x340 (0x340/0x34 0), irq=9, scsiid=7, reconnect=disabled, parity=disabled, synchronous=disabled, delay=100, extended translation=disabled Oct 7 18:14:57 snoopy kernel: aha152x0: trying software interrupt, ok. Oct 7 18:14:57 snoopy kernel: scsi0 : Adaptec 152x SCSI driver; $Revision: 2.0 $ Oct 7 18:14:57 snoopy kernel: scsi : 1 host. Oct 7 18:14:58 snoopy kernel: Vendor: AGFA Model: SNAPSCAN 1236 Rev: 1.50 Oct 7 18:14:58 snoopy kernel: Type: Scanner ANSI SCSI revision: 02 Oct 7 18:16:57 snoopy kernel: Detected scsi generic sg0 at scsi0, channel 0, id 2, lun 0, type 6 after that you could start xscanimage but it locked up. 4.: 2.4.0-test9 5.: 6.: scanimage/xscanimage (latest version, sane 1.0.3). 7.2: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 2 cpu MHz : 501.142 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 pn mmx fxsr xmm bogomips: 999.42 7.4.: -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 0210-021f : 3c509 02f8-02ff : serial(auto) 0340-035f : aha152x 0378-037a : parport0 03bc-03be : parport1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 7.6.: Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: SEAGATE Model: ST43400N Rev: 0116 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: AGFA Model: SNAPSCAN 1236Rev: 1.50 Type: Scanner ANSI SCSI revision: 02 8.: I used an update directly from the snapscan-developer-page but the result was the same. Cheers /Bernd --- http://www.neurop.ruhr-uni-bochum.de/~porr http://www.cn.stir.ac.uk/~bp1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Linus Torvalds wrote: On Mon, 9 Oct 2000, Rik van Riel wrote: I'd prefer just X having a higher "mm nice level" or something. Which it has, because: 1) CAP_RAW_IO 2) p-euid == 0 Oh, I agree, but we might want to generalize this a bit so that root could say "this process is important" and then drop root privileges and still get "credited" for the fact that it's important. It's not a big deal. It works for X right now. How about using p-rlim[RLIMIT_AS].rlim_cur to weight the badness point for a process? On my system, a 128MB RAM + 256MB swap, it defaults to some (insane?) value: bash$ ulimit -vH -vS virtual memory (kbytes) 4194302 virtual memory (kbytes) 2105343 for every process, which just means it is unused. The idea is: 1) set default for rlim[RLIMIT_AS].rlim_max to a saner value; 2) processes with higher rlim[RLIMIT_AS].rlim_cur get lower badness. This way, the badness of a process is not proportional to its absolute size, but to the fraction of allowed AS it is using. Processes that are capable(CAP_SYS_RESOURCE) can set RLIMIT_AS to a very high value, so they get less badness point. X is a perfect candidate. User's runaway processes (netscape) will have lower rlim[RLIMIT_AS].rlim_cur, thus will get higher badness. Something like: - points = p-mm-total_vm; + points = p-mm-total_vm / (p-rlim[RLIMIT_AS].rlim_cur AS_FACTOR); with #define AS_FACTOR 30 maybe? (this is Rik's call, he knows better than me how to balance it...) It's simple, it's configurable. 1) may be enforced by the kernel, or completely left to user space. On my system, in its default configuration (no use of RLIMIT_AS), it has no impact at all (all processes have the same limit). Sounds good or am I missing something? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lowish-latency patch for 2.4.0-test9
Andi Kleen wrote: On Fri, Oct 06, 2000 at 10:00:36PM +1100, Andrew Morton wrote: The little-low-latency patch for test9 is at http://www.uow.edu.au/~andrewm/linux/2.4.0-test9-low-latency.patch Notes: - It now passes Benno's tests with 50% headroom (thanks to Ingo's scheduler race fix). What was that race exactly ? Not completely sure. I _think_ the problem was that when the kernel was switching from your SCHED_FIFO process to some other process, and an interrupt occurred between the reenabling of interrupts and the switch_to() in schedule(), and that interrupt tried to wake the SCHED_FIFO process, it wasn't noticed until the next timeslice. That was as far as I got when the problem magically disappeared. Due to this hunk: switch_to(prev, next, prev); __schedule_tail(prev); same_process: reacquire_kernel_lock(current); + if (current-need_resched) + goto tq_scheduler_back; return; There is a scheduler race which may also hurt (and is harder to fix): when the timer interrupt hits in syscall exit after the need_resched check was done then you may lose a time slice. The window can be quite long when signals are handled (after do_signal returned there is no reschedule check). Without signals it is only a few instructions window. I have not checked if it really is a problem in practice though. With lots of signals it may be a problem. Is it not a matter of: a): checking need_resched after the call to do_signal() and b): disabling local interrupts prior to the final need_resched check to make this test atomic wrt interrupts. RESTORE_ALL will do the right thing and an intervening smp_send_reschedule() will be blocked until the return to user space. Seems too simple... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: getting struct pci_dev from struct netdevice
Hi Andrew, Take a look at the olympic driver (drivers/net/tokenring/olympic.c) function olympic_proc_info. This is called from a read into the proc filesystem. When we get the read we want to print out details on all the olympic devices in the system so we have to scan the pci tree and find a match based on base_addr. This works in both 2.2 and 2.4 Jeff: Or really? Exactly how does one do this? pdev-driver_data = dev Of course the driver has to implement this. Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Calling current() from interrupt context
"Jeff V. Merkey" wrote:
"Jeff V. Merkey" wrote:
"David S. Miller" wrote:
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
behind an I/O interface that is slower than ideal
Where would you put it for IA32 ? I don't know any free MSR that could
be abused for that, and acessing MSRs is insanely slow anyways. Any
other ideas ?
The local APIC holds the hardware cpu number (which happens to equal
the logical cpu number in the current x86 code). And I believe the
local APIC has a 32-bit scratch register or 2 as well... but don't
quote me on that one.
Accessing the CPUID from the local APIC is slower than mollasses. The
reason for this is due to the fact that the APIC address ranges are
treated as non-cacheable memory, and will always generate a
non-cacheable memory reference when you read from the APIC_ID register
and shift the ID.
You can verify this with a logic analyzer and watch the system get really slow, I/O
performance go down after you read the memory mapped APIC registers from a context
switch loop, i.e.
while (1)
{
read_local_apic(); // OINK OINK OINK -- bus utilitization will go
through the roof.
schedule()
}
and watch it oink...
A simpler solution is to use the CR2 register to store the CPU number,
and always reload the register after a page fault (since CR2 will hold a
faulting address). This is even better than Linus' stack based method
for storing the number since you just are reading a register, which is
fast. The other methods are slower.
this is how it's done in NetWare and MANOS. It works
:-)
Jeff
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Fwd: set_rtc_mmss ?
Oops.. sorry for the typo. The server in question is running linux-2.2.16 tarball from ftp.kernel.org instead of 2.2.17 . Thanks! - Forwarded message from [EMAIL PROTECTED] - Date: Tue, 10 Oct 2000 21:28:14 +0800 (SGT) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: set_rtc_mmss ? To: [EMAIL PROTECTED] Hello! I am currently running the tarball linux-2.2.17 from ftp.kernel.org on a RedHat Linux 6.2 server. The server is a Dell PowerEdge 4300 with 1GB RAM , 2 x PIII600 and a DRAC PERC2/SC RAID controller. The server mainly runs software like MySQL Server, Samba Server, NFS Server and LDAP Server. All is working well except that randomly, sometimes afer a few days or sometimes after many weeks, the following error message would appear when I type dmesg at the shell prompt. set_rtc_mmss: can't update from 50 to 1 set_rtc_mmss: can't update from 50 to 2 set_rtc_mmss: can't update from 50 to 3 set_rtc_mmss: can't update from 50 to 4 set_rtc_mmss: can't update from 53 to 4 set_rtc_mmss: can't update from 53 to 5 set_rtc_mmss: can't update from 53 to 6 set_rtc_mmss: can't update from 53 to 7 set_rtc_mmss: can't update from 49 to 0 set_rtc_mmss: can't update from 49 to 1 set_rtc_mmss: can't update from 49 to 2 set_rtc_mmss: can't update from 49 to 3 set_rtc_mmss: can't update from 56 to 7 set_rtc_mmss: can't update from 56 to 8 set_rtc_mmss: can't update from 56 to 9 set_rtc_mmss: can't update from 56 to 10 And when I check up on /proc/rtc, it is no longer running and is stuck at the time when the first set_rtc_mmss error occurs. When I tried to run programs like setclock to update the hardware clock, it just jams there for a very long time and a strace shows that it is trying to access /proc/rtc . server:~# date Tue Oct 10 21:21:04 SGT 2000 server:~# uptime 9:21pm up 36 days, 4:54, 1 user, load average: 2.88, 2.04, 1.83 server:~# cat /proc/rtc rtc_time: 17:41:57 rtc_date: 2000-10-09 rtc_epoch : 1900 alarm : 04:33:37 DST_enable : no BCD : yes 24hr: yes square_wave : no alarm_IRQ : no update_IRQ : no periodic_IRQ: no periodic_freq : 1024 batt_status : okay server:~# fuser -u -a -v /proc/rtc USERPID ACCESS COMMAND /proc/rtc No process references; use -v for the complete list Does anyone have any idea what could be causing this problem? The only solution that I came across till date is to reboot the server and then set back the correct date/time in the CMOS before allowing the server to bootup. Many thanks in advance! - End forwarded message - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Matrox framebuffer
I have problem with Matrox G400 framebuffer. After turn on computer, kernel freez durning boot with snow on my monitor. When I start it with options video=matrox:disbled, and run XFree86 4.0.1 with official drivers from Matrox web page, and reboot my computer again - everything works fine. From dmesg: matroxfb: Matrox unknown G400 (AGP) detected matroxfb: MTRR's turned on matroxfb: cannot set xres to 800, rounded up to 832 matroxfb: cannot set xres to 800, rounded up to 832 matroxfb: 800x600x8bpp (virtual: 832x20160) matroxfb: framebuffer at 0x4200, mapped to 0xc8805000, size 16777216 Console: switching to colour frame buffer device 100x37 fb0: MATROX VGA frame buffer device And lspci -v: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G400 16Mb SGRAM Flags: medium devsel, IRQ 11 Memory at 4200 (32-bit, prefetchable) [size=32M] Memory at 4080 (32-bit, non-prefetchable) [size=16K] Memory at 4000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at unassigned [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [f0] AGP version 2.0 uname -a Linux random 2.4.0-test9 #1 Tue Oct 10 15:05:22 CEST 2000 i686 unknown -- Daniel Podlejski [EMAIL PROTECTED] ... When you're through with life and all hope is lost, Hold out your hand cos right till the end - friends will be friends ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Tue, Oct 10, 2000 at 04:38:02AM +0100, Philipp Rumpf wrote: Init should never die. If we get to do_exit in init we'll panic which is the right thing to do (reboot on critical systems). If the page fault can fail with OOM on init, init will get a SIGSEGV while running a signal handler (copy-user will return -EFAULT regardless it was an oom or a real segfault) and it _won't_ panic and the system is unusable. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
OnStream SCSI tape driver osst
Hi Linus, hi Alan, I'd like to get some driver included into the mainstream kernels. The driver is a new high-level SCSI driver, which was derived from the standard st driver. It drives the OnStream tape drives SC-30/50 (SCSI) and DI-30 (IDE, via ide-scsi) and USB-30 (USB, via usb-storage). The parallel port drive (DP-30) could also be driven, if there was a SCSI emulation layer for it ... The reason why this driver is needed, is that the OnStream drives are not completely conforming with the SCSI-2 spec for Serial Access Storage Devices (commonly named tapes), which basically is the same as QIC-157. Therefore st fails to drive those OnStream tape drives. (There is a second generation drive, ADR-x0, which has a much more advanced firmware and does fully comply with SCSI-2 spec, BTW.) The commands are rather QIC-172 and especially the error handling is a little bit tricky. Apart from this problem, the drives are rather nice devices, offering good performance (15/25 GB uncompressed at 1MB/s (IDE, USB) or 2MB/s (SCSI)) for reasonable prices. OnStream was interested to get those drives supported by Linux and provided docu, test devices and help to get the driver working. Some people were found to work on this. After some discussion with Kai Makisara, the decision was taken to not integrate lots of if (onstream) code into the standard st, but instead fork a new st like driver osst (OnStream Scsi Tape). A new char device has been registered for it (char-major-206) with HPA. A beta driver is out there since almost half a year now (see http://linux1.onstream.nl/ ) and has proven to work very well. So, I think it's time to get the driver into the mainstream kernel, so normal users can profit from it. Of course, the driver is GPL'ed. I know that this is rather late for 2.4, and I know what the term feature freeze means. Sorry about this! I meant to ask you for inclusion of the driver some weeks ago, already, but the problem was that I really do not want to send you a patch, which has rejects due to the changes in SCSI. Now, as SCSI seems to be stable again (and better than before), I could do some serious final testing again and would really like to get it included now. The risk of destabilizing the kernel is zero: * Kai already integrated a patch into st to reject the non st-compatible OnStream tape drives [static char * st_incompatible(Scsi_Device* SDp)] * osst will only try to drive the OnStream devices * Thanks to the recent changes in SCSI of 2.4 kernels, we do not even need to touch any other SCSI driver file. (The patch to st just does include the signatures for rejection from a different file, which is also used by osst; this way duplication of information is avoided.) * Lots of testers squashed out the bugs. (No, I'm not crazy and claim that there are none left.) So, it's just an additional driver for some nice hardware that was not supported before. It would be nice to get it included ASAP. If 2.4.0 is not possible any more, 2.4.1 would still be a good solution ... (Should I try to get Ted to put this on the TODO list?) BTW, Kai supports inclusion of it into the mainstream kernel. Linus, Alan, the whole driver stuff can be downloaded from http://linux1.onstream.nl/test/ I'll create a patch against the most recent 2.4 and 2.2 trees I can find, and send it via PM to you, so you do not need to do a combined patch copy procedure. I'd like to not forget to mention the people who actually did the work. Willem Riede [EMAIL PROTECTED] did by far the largest part of the coding. He is the MAINTAINER, and the patch adds his name to the list. Some code was copied from or modelled after Gadi Oxmans ide-tape [EMAIL PROTECTED] and Terry Hardies userspace application osg [EMAIL PROTECTED]. I did also contribute some code. Thanks also go to Kai Makisara [EMAIL PROTECTED] (the st maintainer) for discussing design issues with us. Jack Bombeeck [EMAIL PROTECTED] and some of his colleagues helped wherever they could and will need to take care not to get addicted to Linux ;-) I'd also like to thank Matthew Darm and David Brown for their usb-storage work and all the testers who sent reports. Regards, -- Kurt Garloff [EMAIL PROTECTED] [Eindhoven, NL] Physics: Plasma simulations [EMAIL PROTECTED] [TU Eindhoven, NL] Linux: SCSI, Security [EMAIL PROTECTED] [SuSE Nuernberg, FRG] (See mail header or public key servers for PGP2 and GPG public keys.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
I tried the patch, but the result is the same... Uncompressing Linux...,
now booting the kernel..., NOTHING
These Winchips need all the help they can get, so if you know something
else I might try...
Ok, I've narrowed it down to the changes to mtrr.c in test8
Looks like the Cyrix III changes broke things.
Didn't something similar happen when these changes made it into
a 2.2.18pre ? Alan?
For now reverse the diff below by patching with -R
I'll take a look at a proper fix after lectures later today[1]..
unless someone else spots the error in the meantime.
regards,
Dave.
[1] Why do all the fun things happen on my busiest days ? :)
--
| Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej
| SuSE Labs
diff -u --recursive --new-file v2.4.0-test8/linux/arch/i386/kernel/mtrr.c
linux/arch/i386/kernel/mtrr.c
--- v2.4.0-test8/linux/arch/i386/kernel/mtrr.c Wed Jul 12 21:58:41 2000
+++ linux/arch/i386/kernel/mtrr.c Sun Oct 1 20:35:15 2000
@@ -319,10 +319,10 @@
#endif
#ifdef USERSPACE_INTERFACE
-static char *ascii_buffer = NULL;
-static unsigned int ascii_buf_bytes = 0;
+static char *ascii_buffer;
+static unsigned int ascii_buf_bytes;
#endif
-static unsigned int *usage_table = NULL;
+static unsigned int *usage_table;
static DECLARE_MUTEX(main_lock);
/* Private functions */
@@ -356,7 +356,8 @@
if (boot_cpu_data.x86 = 6) break; /* Athlon and post-Athlon CPUs */
/* else fall through */
case X86_VENDOR_CENTAUR:
- return;
+ if(boot_cpu_data.x86 != 6)
+ return;
/*break;*/
}
/* Save value of CR4 and clear Page Global Enable (bit 7) */
@@ -380,6 +381,7 @@
{
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
+ case X86_VENDOR_CENTAUR:
/* Disable MTRRs, and set the default type to uncached */
rdmsr (MTRRdefType_MSR, ctxt-deftype_lo, ctxt-deftype_hi);
wrmsr (MTRRdefType_MSR, ctxt-deftype_lo 0xf300UL, ctxt-deftype_hi);
@@ -403,8 +405,11 @@
if (boot_cpu_data.x86 = 6) break; /* Athlon and post-Athlon CPUs */
/* else fall through */
case X86_VENDOR_CENTAUR:
- __restore_flags (ctxt-flags);
- return;
+ if(boot_cpu_data.x86 != 6)
+ {
+ __restore_flags (ctxt-flags);
+ return;
+ }
/*break;*/
}
/* Flush caches and TLBs */
@@ -415,6 +420,7 @@
{
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
+ case X86_VENDOR_CENTAUR:
wrmsr (MTRRdefType_MSR, ctxt-deftype_lo, ctxt-deftype_hi);
break;
case X86_VENDOR_CYRIX:
@@ -453,9 +459,17 @@
/*break;*/
case X86_VENDOR_CYRIX:
/* Cyrix have 8 ARRs */
+ return 8;
case X86_VENDOR_CENTAUR:
/* and Centaur has 8 MCR's */
- return 8;
+ if(boot_cpu_data.x86==5)
+ return 8;
+ /* the cyrix III has intel compatible MTRR */
+ if(boot_cpu_data.x86==6)
+ {
+ rdmsr (MTRRcap_MSR, config, dummy);
+ return (config 0xff);
+ }
/*break;*/
}
return 0;
@@ -471,12 +485,15 @@
case X86_VENDOR_AMD:
if (boot_cpu_data.x86 6) return 1; /* pre-Athlon CPUs */
/* else fall through */
+ case X86_VENDOR_CENTAUR:
+if (boot_cpu_data.x86 == 5)
+ return 1; /* C6 */
+/* CyrixIII is Intel like */
case X86_VENDOR_INTEL:
rdmsr (MTRRcap_MSR, config, dummy);
return (config (110));
/*break;*/
case X86_VENDOR_CYRIX:
- case X86_VENDOR_CENTAUR:
return 1;
/*break;*/
}
@@ -623,7 +640,7 @@
} /* End Function centaur_get_mcr */
static void (*get_mtrr) (unsigned int reg, unsigned long *base,
-unsigned long *size, mtrr_type *type) = NULL;
+unsigned long *size, mtrr_type *type);
static void intel_set_mtrr_up (unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type, int do_safe)
@@ -766,7 +783,7 @@
static void (*set_mtrr_up) (unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type,
- int do_safe) = NULL;
+ int do_safe);
#ifdef CONFIG_SMP
@@ -1194,7 +1211,7 @@
printk ("mtrr: size: %lx base: %lx\n", size, base);
return -EINVAL;
}
-if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR)
+if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR boot_cpu_data.x86 == 5)
{
if (type != MTRR_TYPE_WRCOMB)
{
@@ -1779,8 +1796,16 @@
get_free_region = cyrix_get_free_region;
break;
case X86_VENDOR_CENTAUR:
-get_mtrr = centaur_get_mcr;
-set_mtrr_up = centaur_set_mcr_up;
+if(boot_cpu_data.x86 == 5)
+{
+ get_mtrr = centaur_get_mcr;
+ set_mtrr_up =
A patch to loop.c for better cryption support
Hi,
First some explanation. Most cryption algorithms initialize
the cryption process with some init values, called IV (by me :-).
This means that two identical clear messages will give
different encrypted messages, if different IVs are used.
The loop device supports different IVs;
the IVs are initilized with the requested block
number.
I believe a better way is to use the requested
sector number from CURRENT-sector.
Using this value should make the encryption and decryption
process completely independent from the underlying device.
This is especially important when using a backing file.
At the moment (as far as i heard) you can't use a backing
file on a harddisk and then burn it to a CD, because the
blocksize changes. Using sectors as atomic encryption unit
should solve this problem.
There is one drawback: The cryption algorithms have to
know this semantic. At the moment most of the cryption algorithms
use CBC mode to crypt a stream. When sector numbers are
used as IV's the CBC mode has to be restarted periodically
after 512 bytes with an incremented sector number as new IV's.
(Please CC me if you want to comment :-) )
so long
Ingo
PS: Please have a look at the patch. It is against linux-2.4test9.
I already mailed this patch to Alexander Kjeldaas who
maintains the international crypto patch, but I don't know
who maintains the loop device. (I know that it was originally
written by Theodore Ts'o, but is he also the Maintainer ?)
Please include the patch into the main tree...
--- linux-2.4test9/drivers/block/loop_old.c Tue Oct 10 14:25:10 2000
+++ linux-2.4test9/drivers/block/loop.c Tue Oct 10 16:09:11 2000
@@ -169,7 +169,7 @@
}
static int lo_send(struct loop_device *lo, char *data, int len, loff_t pos,
- int blksize)
+ int IV)
{
struct file *file = lo-lo_backing_file; /* kudos to NFsckingS */
struct address_space *mapping = lo-lo_dentry-d_inode-i_mapping;
@@ -182,7 +182,6 @@
index = pos PAGE_CACHE_SHIFT;
offset = pos (PAGE_CACHE_SIZE - 1);
while (len 0) {
- int IV = index * (PAGE_CACHE_SIZE/blksize) + offset/blksize;
size = PAGE_CACHE_SIZE - offset;
if (size len)
size = len;
@@ -221,7 +220,7 @@
struct lo_read_data {
struct loop_device *lo;
char *data;
- int blksize;
+ int IV;
};
static int lo_read_actor(read_descriptor_t * desc, struct page *page, unsigned long
offset, unsigned long size)
@@ -230,8 +229,8 @@
unsigned long count = desc-count;
struct lo_read_data *p = (struct lo_read_data*)desc-buf;
struct loop_device *lo = p-lo;
- int IV = page-index * (PAGE_CACHE_SIZE/p-blksize) + offset/p-blksize;
-
+ int IV = p-IV;
+
if (size count)
size = count;
@@ -251,7 +250,7 @@
}
static int lo_receive(struct loop_device *lo, char *data, int len, loff_t pos,
- int blksize)
+ int IV)
{
struct file *file = lo-lo_backing_file;
struct lo_read_data cookie;
@@ -259,7 +258,7 @@
cookie.lo = lo;
cookie.data = data;
- cookie.blksize = blksize;
+ cookie.IV = IV;
desc.written = 0;
desc.count = len;
desc.buf = (char*)cookie;
@@ -270,7 +269,7 @@
static void do_lo_request(request_queue_t * q)
{
- int block, offset, len, blksize, size;
+ int sector, block, offset, len, blksize, size;
char*dest_addr;
struct loop_device *lo;
struct buffer_head *bh;
@@ -296,8 +295,9 @@
}
dest_addr = current_request-buffer;
+ sector = current_request-sector;
len = current_request-current_nr_sectors 9;
-
+
blksize = BLOCK_SIZE;
if (blksize_size[MAJOR(lo-lo_device)]) {
blksize = blksize_size[MAJOR(lo-lo_device)][MINOR(lo-lo_device)];
@@ -348,7 +348,7 @@
if ((lo-transfer)(lo, current_request-cmd,
bh-b_data + offset,
- dest_addr, size, block)) {
+ dest_addr, size, sector)) {
printk(KERN_ERR "loop: transfer error block %d\n",
block);
brelse(bh);
@@ -371,10 +371,10 @@
pos = ((loff_t)current_request-sector 9) + lo-lo_offset;
spin_unlock_irq(io_request_lock);
if (current_request-cmd == WRITE) {
- if (lo_send(lo, dest_addr, len, pos, blksize))
+ if (lo_send(lo, dest_addr, len, pos, sector))
goto error_out_lock;
} else {
- if (lo_receive(lo, dest_addr, len, pos, blksize))
+ if (lo_receive(lo, dest_addr, len, pos, sector))
goto error_out_lock;
}
done:
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Tue, Oct 10, 2000 at 09:06:49AM +0200, Helge Hafting wrote: If you want init to live - prove that it don't eat too much memory. I don't see why the machine should be stable only if init is small. My kernel won't be stable only if init is small since it doesn't cost anything to handle correctly the big init case. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Linus Torvalds wrote: Basically, the only thing _I_ think X can do is to really say "oh, please don't count my memory, because everything I do I do for my clients, not for myself". THAT is my argument. Basically there is nothing we can reliably account. So we might as well fall back on just saying "X is more important than some random client", and have a mm niceness level. Which right now is obviously approximated by the IO capabilities tests etc. FYI: I ran my machine out of memory (without crashing by the way) this weekend by loading a whole bunch of large images into netscape. I noticed not being able to open more windows when I saw my swapspace exhausted. I noticed the large netscape, and killed it. At that moment my X was still taking 80Mb of RAM. I manually killed it and restarted it to get rid of that memory. So if Netscape can "pump" 40 extra megabytes of memory out of X, this can be exploited. Now we're back to the point that a heuristic can never be right all the time.. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OnStream SCSI tape driver osst
(There is a second generation drive, ADR-x0, which has a much more advanced firmware and does fully comply with SCSI-2 spec, BTW.) 'fully'? Not. This latter drive has had problems too, but it seems to me that the arrival of the ADR-50 should preclude the need to support the ADR-30. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Segfaults using xawtv
Hi... I _hate_ to do this, but I couldn't find (except for a reference to "others who have segfaults using glibc") no reference to this problem. Insmod of i2c, videodev and bttv succeed without problems or any message in /var/log/debug, messages or syslog. Also, though I'm surely no expert, I tested a bit with gdb such, and suspect there may be a problem that's not directly xawtv/bttv related. Any suggestions? John ---insmod insmod i2c insmod videodev (insmod tuner type=4) insmod bttv card=30 ---dmesg: i2c: initialized Linux video capture interface: v1.00 bttv0: Brooktree Bt878 (rev 2) bus: 0, devfn: 80, irq: 5, memory: 0xe700. PCI: Enabling bus mastering for device 00:50 bttv: 1 Bt8xx card(s) found. bttv0: NO fader chip: TEA6300 bttv0: model: BT878 ---lsmod: Module Size Used by tuner 2180 1 bttv 33824 0 videodev2592 2 [bttv] i2c 3488 2 [tuner bttv] ppp_deflate40800 0 (autoclean) ide-cd 23924 1 (autoclean) cdrom 27324 0 (autoclean) [ide-cd] bsd_comp3816 0 lp 4728 0 (unused) ---Versions: xawtv: 3.21 bttv: 0.7.44 kernel: 2.2.16, with USB and I2C patches TV norm here: PAL/N, which is US channel spacing, Euro-50Hz PAL image. but I'm testing with a PAL-B camera. board: Flyvideo 98 error messages: see below ---Backtrace: (I recompiled with -ggdb, to get more info. The error messages are the same using -g or -ggdb) Starting program: /usr/local/src/multimedia/xawtv-3.21/src/xawtv This is xawtv-3.21, running on Linux/i586 (2.2.16) visual: id=0x22 class=4 (TrueColor), depth=24 x11: 1024x768, 32 bit/pixel, 4096 byte/scanline, DGA waitpid: No child processes waitpid: No child processes Program received signal SIGSEGV, Segmentation fault. 0x4021c27d in memset () from /lib/libc.so.6 (gdb) bt #0 0x4021c27d in memset () from /lib/libc.so.6 #1 0x806f8e6 in capability () #2 0x8055fb7 in grabber_open (device=0x8061cd1 "/dev/video", sw=1024, sh=768, base=0xe540, format=8, width=4096) at grab.c:111 #3 0x8050c88 in grabber_init () at xt.c:303 #4 0x8050579 in main (argc=1, argv=0xb784) at main.c:2365 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Tue, 10 Oct 2000, Philipp Rumpf wrote: The algorithm you posted on the list in this thread will kill init if on 4Mbyte machine without swap init is large 3 Mbytes and you execute a task that grows over 1M. This sounds suspiciously like the description of a DEAD system ;) But wouldn't a watchdog daemon which doesn't allocate any memory still get run ? Indeed, it would. It would also /prevent/ the system from automatically rebooting itself into a usable state ;) (in which case you simply don't care if init is being killed or not) You care about getting an automatic reboot. So you need to be sure the watchdog daemon gets killed first or you panic() after some time. echo 30 /proc/sys/kernel/panic regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
[OOM killer war]
Hi there,
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to allow replacing the OOM killer at runtime.
You can even use modules, if you are careful (see khttpd on how
to do this without refcouting).
So now you can stop arguing about the one and only OOM killer,
implement it, provide it as module and get back to the important
stuff ;-)
PS: Patch is against test10-pre1.
Thanks for listening
Ingo Oeser
--- linux-2.4.0-test10-pre1/mm/oom_kill.c Tue Oct 10 16:31:08 2000
+++ linux-2.4.0-test10-pre1-ioe/mm/oom_kill.c Tue Oct 10 16:59:27 2000
@@ -13,6 +13,8 @@
* machine) this file will double as a 'coding guide' and a signpost
* for newbie kernel hackers. It features several pointers to major
* kernel subsystems and hints as to where to find out what things do.
+ *
+ * Added oom_killer API for special needs - Ingo Oeser
*/
#include linux/mm.h
@@ -136,7 +138,7 @@
}
/**
- * oom_kill - kill the "best" process when we run out of memory
+ * oom_kill_rik - kill the "best" process when we run out of memory
*
* If we run out of memory, we have the choice between either
* killing a random task (bad), letting the system crash (worse)
@@ -147,7 +149,9 @@
* CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
* we select a process with CAP_SYS_RAW_IO set).
*/
-void oom_kill(void)
+
+
+static void oom_kill_rik(void)
{
struct task_struct *p = select_bad_process();
@@ -207,4 +211,63 @@
/* Else... */
return 1;
+}
+
+/* Protects oom_killer against resetting during its execution */
+static rwlock_t oom_kill_lock = RW_LOCK_UNLOCKED;
+
+static oom_killer_t oom_killer = oom_kill_rik;
+
+/**
+ * oom_kill - the oom_kill wrapper for installable OOM killers
+ *
+ * Wraper around the OOM killers, that can be installed via
+ * install_oom_killer and reset_default_oom_killer.
+ *
+ * This gets called from kswapd() in linux/mm/vmscan.c when we
+ * really run out of memory.
+ */
+void oom_kill(void) {
+ read_lock(oom_kill_lock);
+ oom_killer();
+ read_unlock(oom_kill_lock);
+}
+
+/**
+ * install_oom_killer - install alternate OOM killer
+ * @new_oom_kill: the alternate OOM killer provided by the caller
+ *
+ * Since the default OOM killer (oom_kill_rik) is not suitable
+ * for everyone, we provide an interface to install custom OOM killers.
+ *
+ * You can take the most appropriate action for your application if the
+ * kernel goes OOM.
+ *
+ * Providing an NULL argument just returns the current OOM killer.
+ *
+ * Returns: The OOM killer, which has been installed so far.
+ *
+ * NOTE: We don't do refcounting on OOM killers, so be careful with
+ * modules
+ */
+oom_killer_t install_oom_killer(oom_killer_t new_oom_kill) {
+ oom_killer_t tmp;
+ write_lock(oom_kill_lock);
+ tmp=oom_killer;
+ if (new_oom_kill)
+ oom_killer=new_oom_kill;
+ write_unlock(oom_kill_lock);
+ return tmp;
+}
+
+/**
+ * reset_default_oom_killer - reset back to default OOM killer
+ *
+ * If you are going to unload the module which provided
+ * your OOM killer, you can install the default one by this.
+ *
+ * Returns: The OOM killer, which has been installed so far.
+ */
+oom_killer_t reset_default_oom_killer(void) {
+ return install_oom_killer(oom_kill_rik);
}
--- linux-2.4.0-test10-pre1/include/linux/swap.hTue Oct 10 16:31:08 2000
+++ linux-2.4.0-test10-pre1-ioe/include/linux/swap.hTue Oct 10 16:44:22 2000
@@ -127,8 +127,14 @@
#define read_swap_cache(entry) read_swap_cache_async(entry, 1);
/* linux/mm/oom_kill.c */
+typedef void (*oom_killer_t)(void);
+
extern int out_of_memory(void);
extern void oom_kill(void);
+
+oom_killer_t install_oom_killer(oom_killer_t new_oom_kill);
+oom_killer_t reset_default_oom_killer(void);
+
/*
* Make these inline later once they are working properly.
--
Feel the power of the penguin - run [EMAIL PROTECTED]
esc:x
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: getting struct pci_dev from struct netdevice
Doesn't work for all devices. Also since base_addr is truncated to 16-bits when passed to ifconfig, this gets even nastier for userspace. You do the best you can with what's available :) ...and noone but the driver can trust this information to be pointing to an up-to-date struct netdevice. Shame, perhaps this can be enforced as part of the new pci api. Since struct pci_dev is probably going to morph into a more generic struct hw_dev, maybe struct netdevice needs a pci_dev member... Would be nice, or perhaps netdevice should expose a function to return the information and let the driver provide the specifics. Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
On Tue, Oct 10, 2000 at 12:06:07PM -0300, Rik van Riel wrote:
On Tue, 10 Oct 2000, Philipp Rumpf wrote:
The algorithm you posted on the list in this thread will kill
init if on 4Mbyte machine without swap init is large 3 Mbytes
and you execute a task that grows over 1M.
This sounds suspiciously like the description of a DEAD system ;)
But wouldn't a watchdog daemon which doesn't allocate any memory
still get run ?
Indeed, it would. It would also /prevent/ the system
from automatically rebooting itself into a usable state ;)
So it's not dead in the "oh, it'll be back in 30 seconds" sense.
So our behaviour is broken (more so than random process
killing).
*nod*
Not killing init when we "should" definately prevents
embedded systems from auto-rebooting when they should
do so.
(OTOH, I don't think embedded systems will run into
this OOM issue too much)
You care about getting an automatic reboot. So you need to be sure the
watchdog daemon gets killed first or you panic() after some time.
echo 30 /proc/sys/kernel/panic
that's what I said. we need to be sure to _get_ a panic() though.
I believe the kernel automatically panic()s when init
dies ... from kernel/exit.c::do_exit()
if (tsk-pid == 1)
panic("Attempted to kill init!");
[which will make our system auto-reboot and be back on its feet
in a healty state again soon]
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On Tue, 10 Oct 2000, Ingo Oeser wrote: before you argue endlessly about the "Right OOM Killer (TM)", I did a small patch to allow replacing the OOM killer at runtime. So now you can stop arguing about the one and only OOM killer, implement it, provide it as module and get back to the important stuff ;-) This is definately a cool toy for people who have doubts that my OOM killer will do the wrong thing in their workloads. If anyone can demonstrate that the current OOM killer is doing the wrong thing and has a replacement algorithm available, please let us know ... ;) [lets move the discussion back to a less theoretical and more practical point of view] regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect UDMA timing on VIA vt82c596b
On Tue, Oct 10, 2000 at 07:21:05AM -0500, Jordan wrote: Everything is working great! I can access my hard drive quickly, both CD drives are working and I can read and write to my zip as a partitioned drive or as a block device for Tar archives. Thanks for all of the help. Great. Thanks for your help, too. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Tue, Oct 10, 2000 at 12:30:51PM -0300, Rik van Riel wrote:
Not killing init when we "should" definately prevents
embedded systems from auto-rebooting when they should
do so.
(OTOH, I don't think embedded systems will run into
this OOM issue too much)
but when they do, they're hard to fix. Think about an elevator control
system with a single process that happens to implement a somewhat broken
version of the elevator algorithm ;)
that's what I said. we need to be sure to _get_ a panic() though.
I believe the kernel automatically panic()s when init
dies ... from kernel/exit.c::do_exit()
if (tsk-pid == 1)
panic("Attempted to kill init!");
guess who added that code. We still kill init with SIGTERM which doesn't
seem to work though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote:
So now you can stop arguing about the one and only OOM killer,
implement it, provide it as module and get back to the important
stuff ;-)
This is definately a cool toy for people who have doubts
that my OOM killer will do the wrong thing in their
workloads.
Thanks ;-)
But I forgot to include my changes to the mm/Makefile (to export
the API for modules).
Here is a _working_ one:
--- linux-2.4.0-test10-pre1/mm/oom_kill.c Tue Oct 10 16:31:08 2000
+++ linux-2.4.0-test10-pre1-ioe/mm/oom_kill.c Tue Oct 10 16:59:27 2000
@@ -13,6 +13,8 @@
* machine) this file will double as a 'coding guide' and a signpost
* for newbie kernel hackers. It features several pointers to major
* kernel subsystems and hints as to where to find out what things do.
+ *
+ * Added oom_killer API for special needs - Ingo Oeser
*/
#include linux/mm.h
@@ -136,7 +138,7 @@
}
/**
- * oom_kill - kill the "best" process when we run out of memory
+ * oom_kill_rik - kill the "best" process when we run out of memory
*
* If we run out of memory, we have the choice between either
* killing a random task (bad), letting the system crash (worse)
@@ -147,7 +149,9 @@
* CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
* we select a process with CAP_SYS_RAW_IO set).
*/
-void oom_kill(void)
+
+
+static void oom_kill_rik(void)
{
struct task_struct *p = select_bad_process();
@@ -207,4 +211,63 @@
/* Else... */
return 1;
+}
+
+/* Protects oom_killer against resetting during its execution */
+static rwlock_t oom_kill_lock = RW_LOCK_UNLOCKED;
+
+static oom_killer_t oom_killer = oom_kill_rik;
+
+/**
+ * oom_kill - the oom_kill wrapper for installable OOM killers
+ *
+ * Wraper around the OOM killers, that can be installed via
+ * install_oom_killer and reset_default_oom_killer.
+ *
+ * This gets called from kswapd() in linux/mm/vmscan.c when we
+ * really run out of memory.
+ */
+void oom_kill(void) {
+ read_lock(oom_kill_lock);
+ oom_killer();
+ read_unlock(oom_kill_lock);
+}
+
+/**
+ * install_oom_killer - install alternate OOM killer
+ * @new_oom_kill: the alternate OOM killer provided by the caller
+ *
+ * Since the default OOM killer (oom_kill_rik) is not suitable
+ * for everyone, we provide an interface to install custom OOM killers.
+ *
+ * You can take the most appropriate action for your application if the
+ * kernel goes OOM.
+ *
+ * Providing an NULL argument just returns the current OOM killer.
+ *
+ * Returns: The OOM killer, which has been installed so far.
+ *
+ * NOTE: We don't do refcounting on OOM killers, so be careful with
+ * modules
+ */
+oom_killer_t install_oom_killer(oom_killer_t new_oom_kill) {
+ oom_killer_t tmp;
+ write_lock(oom_kill_lock);
+ tmp=oom_killer;
+ if (new_oom_kill)
+ oom_killer=new_oom_kill;
+ write_unlock(oom_kill_lock);
+ return tmp;
+}
+
+/**
+ * reset_default_oom_killer - reset back to default OOM killer
+ *
+ * If you are going to unload the module which provided
+ * your OOM killer, you can install the default one by this.
+ *
+ * Returns: The OOM killer, which has been installed so far.
+ */
+oom_killer_t reset_default_oom_killer(void) {
+ return install_oom_killer(oom_kill_rik);
}
--- linux-2.4.0-test10-pre1/include/linux/swap.hTue Oct 10 16:31:08 2000
+++ linux-2.4.0-test10-pre1-ioe/include/linux/swap.hTue Oct 10 16:44:22 2000
@@ -127,8 +127,14 @@
#define read_swap_cache(entry) read_swap_cache_async(entry, 1);
/* linux/mm/oom_kill.c */
+typedef void (*oom_killer_t)(void);
+
extern int out_of_memory(void);
extern void oom_kill(void);
+
+oom_killer_t install_oom_killer(oom_killer_t new_oom_kill);
+oom_killer_t reset_default_oom_killer(void);
+
/*
* Make these inline later once they are working properly.
--- linux-2.4.0-test10-pre1/mm/Makefile Tue Oct 10 16:31:08 2000
+++ linux-2.4.0-test10-pre1-ioe/mm/Makefile Tue Oct 10 16:34:06 2000
@@ -10,7 +10,8 @@
O_TARGET := mm.o
O_OBJS := memory.o mmap.o filemap.o mprotect.o mlock.o mremap.o \
vmalloc.o slab.o bootmem.o swap.o vmscan.o page_io.o \
- page_alloc.o swap_state.o swapfile.o numa.o oom_kill.o
+ page_alloc.o swap_state.o swapfile.o numa.o
+OX_OBJS := oom_kill.o
ifeq ($(CONFIG_HIGHMEM),y)
O_OBJS += highmem.o
Regards
Ingo Oeser
--
Feel the power of the penguin - run [EMAIL PROTECTED]
esc:x
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: tmscsim update for Linux 2.2.18pre15?
Kurt Garloff wrote: Actually, 2.0e3 did include one rather important fix which solved the trouble: Some devices get upset, when the driver tries to negotiate sync (or wide) connections, but the device actually does not support it. So, the driver now waits for the first INQUIRY result and parses the relevant fields to determine, whether sync should be tried. As far as I can conclude from the reports I got since the 2.0e3 release (two weeks ago), it solves the remaining issues. I believe I sent the successful report to Kurt, but just in case, the latest tmscsim driver from the web page worked just fine. In my case, it negotiated the sync transfer with the hard disks successfully while it didn't with the old async CD drive. Expected correct behavior. This is with 2.4.0-test9.(Oh, I think when I reported to Kurt, it was test9-prexxx, but it now works with test-9 on my PC.) I would like to thank Kurt for continueing to maintain the old tmscsim driver for the new kernel. Happy Hacking, Chiaki Ishikawa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] in check_asm.c on sun4m
Hi, While trying 2.4.0-test10-pre1 on my Sun4m SparcSystem600, i'm getting an error during 'make dep' ;(( I don't know anything about assembly, so there I can't help, but here's the output: galaxy:/usr/src/kernel-source-2.4-0-test10-pre1# make dep make -C arch/sparc/kernel check_asm make[1]: Entering directory `/usr/src/kernel-source-2.4-0-test10-pre1/arch/sparc/kernel' gcc272 -E -D__KERNEL__ -I/usr/src/kernel-source-2.4-0-test10-pre1/include tmp.c -o tmp.i /bin/sh ./check_asm.sh -data task tmp.i check_asm_data.c /bin/sh ./check_asm.sh -data mm tmp.i check_asm_data.c /bin/sh ./check_asm.sh -data thread tmp.i check_asm_data.c gcc272 -D__KERNEL__ -I/usr/src/kernel-source-2.4-0-test10-pre1/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7 -S -o check_asm_data.s check_asm_data.c /bin/sh ./check_asm.sh -ints check_asm_data.s check_asm.c /bin/sh ./check_asm.sh -printf task tmp.i check_asm.c /bin/sh ./check_asm.sh -printf mm tmp.i check_asm.c /bin/sh ./check_asm.sh -printf thread tmp.i check_asm.c gcc272 -o check_asm check_asm.c check_asm.c:5: parse error before `0' make[1]: *** [check_asm] Error 1 make[1]: Leaving directory `/usr/src/kernel-source-2.4-0-test10-pre1/arch/sparc/kernel' make: *** [check_asm] Error 2 galaxy:/usr/src/kernel-source-2.4-0-test10-pre1# Anyone knows what the problem could be ?? please cc me, 'cuz i'm not on the lk list... Greetz, Taco. --- "I was only 75 years old when I met her and I was still a kid" -- Duncan McLeod - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAID setup
Hi, I want to setup RAID. I am working on kernel version 2.2.12. I am using RAID patches available. I create a RAID configuring file called /etc/raidtab #mkraid /dev/md0/*md0 is the device I am selecting*/ After this when I check /proc/mdstat , I find that /dev/md0 is not running. The /proc/mdstat gives message: device md0:inactive. Where am I wrong? should I be doing something else before after mkraid? I am not able to post messages to linu-raid group. May I know what is the correct mail id for this group? with regards, Anil __ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect UDMA timing on VIA vt82c596b
On Tue, Oct 10, 2000 at 12:20:07PM -0400, Mark Hahn wrote: Btw, reading the ATA/ATAPI-6 specs I think UDMA66 should work on a setup where would be just one drive and a really short, 40-wire cable without problems as well. I've even seen systems shipped like that. uh, what part of the spec leads you to that conclusion? I've haven't seen a draft more recent than ~1h2000, but they've been unambiguous about absolutely requiring 80-conductors for = ata66, and that two-connector cables must be 5=l=18, and three-connector cables 10=l=18. ATA/ATAPI-6 draft rev. 0a, page 14 (sheet 28 of 404), table 2, row 4, column 1, plus comment 4 in the same table. And from the engineering point of view, it seems reasonable, too. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Calling current() from interrupt context
In article [EMAIL PROTECTED], Jamie Lokier [EMAIL PROTECTED] wrote: Linus Torvalds wrote: You can also still do the stack pointer plaything by just using indirection: and when you context switch you switch the pointer around at the base of the per-cpu interrupt stack. Indirection, à la "current = *(stack ~8191)" might not be a bad idea in general. As Ralf Baechle noted, having all the task structs at the same offset isn't good for the cache. Well, indirection is worse. You get a cache killer there too, and added to that your "current" lookup is just noticeably slower even without any cache issues.. Also, there's a very simple rule of thumb that a lot of otherwise smart people forget: hardware gets better. In particular, direct-mapped caches basically do not exist any more in any reasonable CPU. Sure, the L1 is still direct-mapped on some setups, but (a) that's going away, and (b) if the CPU is reasonable the only reason for this is that the L1 is really close and really fast, and the L2 is good. With CPU technology of today, any good CPU architect will work _hard_ at making cache misses less likely, and there are absolutely no signs of this changing - rather the reverse. Which means that you should expect caches to go from the current four-way to eigth and more (with the L1 possibly staying at direct or two-way, but with low latency for a L2 miss). Yes, it's "expensive" in area and in cycle time, but it's less expensive than missing more. And most work-loads of today are not well-behaved fortran stuff, so there are no longer any excuses for cache coloring and trying to hide bad hardware that way. Finally, most of the uses of "current" are _not_ of the type where you look at multiple task structures in a row. The scheduler is in fact pretty much the only case that this really happens in (oh, "wakeup()" can do it, but if you have multiple processes waiting non-exclusively on a wakeup, you have _other_ performance problems). In the end it hasn't been much of a problem in Linux (scheduler performance issues have tended to be _much_ more about avoiding unnecessary scheduling and selecting the _right_ process than about trying to avoid two cache misses). I'm personally convinced that anybody who would try to make "current" lookup more complicated to get cache coloring effects is looking at a losing proposition - you may find machines where it would win, but never in the long run. Give it up. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH] Re: wasting time on page fault
On Tue, 10 Oct 2000, Jamie Lokier wrote: The assembler doesn't use nops for alignment -- it inserts longer instructions that are effectively nops, either 1 or two. For larger stretches, the assembler inserts a jmp itself for alignment. Note that some of them are not very good no-ops. At least at some point the "long" no-op was lea 0x(%esi),%esi and you could cause AGI stalls and non-pairing with two of them in a row - making the long no-op sequence potentially quite slow. The one-byte no-op is recognized by the CPU as being a no-op (even though technically it originally was a "xchg ax,ax" instruction decoding-wise - it doesn't actually get executed as that in any modern CPU and thus avoids all the dependencies implied in the traditional decode). It may be that the special "lea" no-op is also recognized as such in newer CPU's, but it wasn't in the early ones. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
On Mon, 9 Oct 2000, Byron Stanoszek wrote: it also might be good to have options to kill anything connected to a pty first, and to not kill anything attatched to the console. obviously these leave ways for admins to shoot themselves in the foot, but they could be useful. I _had_ thought of that, but I don't know how clear that is in the process structure. Malicious users can simply run setsid() to detach from a controlling tty, thereby defeating the rule. Well, I wasn't thinking about killing pty-attatched processes as being necessarily 100% effective or secure, but merely potentially useful. Clearly it doesn't help in the case of a malicious forkbombing user. Sparing console processes seems like it should be reasonably secure though (at least as secure as your console is). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Tue, 10 Oct 2000, Rogier Wolff wrote: So if Netscape can "pump" 40 extra megabytes of memory out of X, this can be exploited. Now we're back to the point that a heuristic can never be right all the time.. I agree. In fact, we never left that. Nothing is perfect. In fact, a lot of engineering is _recognizing_ that you can never achieve "perfect", and you're much better off not even trying - and having a simple system that is "good enough". This is the old adage of "perfect is the enemy of good" - trying too hard is actually _detrimental_ in 99% of all cases. We should have simple heuristics that work most of the time, instead of trying to cajole a complex system like X to help us do some complicated resource management system. Complexity will just result in the OOM killer failing in surprising ways. A simple heuristic will mean that the OOM killer will still fail, but at least it won't be be in subtle and surprising ways. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH] Re: wasting time on page fault
Linus Torvalds wrote: The assembler doesn't use nops for alignment -- it inserts longer instructions that are effectively nops, either 1 or two. For larger stretches, the assembler inserts a jmp itself for alignment. Note that some of them are not very good no-ops. At least at some point the "long" no-op was lea 0x(%esi),%esi and you could cause AGI stalls and non-pairing with two of them in a row - making the long no-op sequence potentially quite slow. When it must emit two no-ops in a row, it uses %esi and then %edi so there's no AGI from that. However, the assembler doesn't check preceding instructions to pick a decent register for the no-op instruction. Solution: avoid writing to %esi before an alignment op. It may be that the special "lea" no-op is also recognized as such in newer CPU's, but it wasn't in the early ones. Does Crusoe recognise that? :-) -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt/Sleep deadlock
On Thu, 28 Sep 2000, Ivan Passos wrote: In order to get the configuration of a board, I have to send, from userspace, an ioctl to the driver and wait for the board to complete its action. The way this is implemented is as follows: - In the ioctl, the driver sends a command to the board and then goes to sleep (interruptible_sleep_on(info-config_wait)); - The board receives the command, handles it and answers back with an interrupt; - The driver's interrupt handler schedules a bottom-half action. - The bottom-half calls wake_up_interuptible(info-config_wait). - The ioctl returns and the userspace application has the board configuration. Now, the problem: the board is so fast that it interrupts back _before_ the driver goes to sleep, i.e.: - Driver sends command to board; - Driver goes to sl... interrupt back from board!! - Interrupt handler schedules bottom-half. - Bottom-half calls wake_up. - Ioctl continues, and _then_ goes to sleep. System locked. I can't disable interrupts before going to sleep, because the event that wakes me up is an interrupt. However, if I don't protect it from the interrupts, the system locks ... Is there any other way in Linux to implement this?!?!?! This e-mail is to thank everybody who answered, and to let you know that the solution I'm using is the one suggested by Nigel Gamble [EMAIL PROTECTED]: "You could use a semaphore for this. Initialize it to 0, then call down() from the ioctl, and up() from the interrupt handler. If the up() happens before the down(), the down() won't go to sleep." Initializing it to 0 means: cfg_sem = MUTEX_LOCKED; It's the simplest to understand, and it works great!! Does anybody see a problem with this implementation?? Thanks again!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel.org verification key updated
I cannot verify this signature with gpg or pgp. gpg says gpg: invalid radix64 character 00 skipped gpg: Signature made Tue Oct 10 08:26:46 2000 MEST using DSA key ID 2BCBC621 gpg: BAD signature from "H. Peter Anvin (hpa) [EMAIL PROTECTED]" Walter -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I just wanted to let everyone know that we have changed the cryptographic key for the Linux Kernel Archives. The reason is that the original key was generated with an expiration date, and unfortunately it appears that too much software out there doesn't support changing the expiration date on an already valid key (the ability to do that, arguably, makes the expiration date useless anyway.) Therefore, we have revoked key 1E1A8782 generated 1999-10-15 and replaced it with key 517D0F0E generated 2000-10-10. Please see http://www.kernel.org/signature.html for more information. The archive machine is currently in process of generating new signature files; they should be distributed to mirrors shortly thereafter in normal order. -hpa - -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE54ramfZ3uzivLxiERAnw7AJ4mNH5RUMz/OGtfCIY0qVNE9ETFggCeOfPo IInpWMaytVNCW1vqWMRG+50= =zatN -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
Dave,
This patch fixed the problems, for now. The system now boots OK, and seems to
run OK (have not hit it very hard yet since it currently runs without a
heatsink). Tnanks...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ Hacker for Hire \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ Hacker: http://www.jargon.org/html/entry/hacker.html ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
Either you forgot to attach the patch for it was bigger than 40K. On Tue, 10 Oct 2000, Frank de Lange wrote: Dave, This patch fixed the problems, for now. The system now boots OK, and seems to run OK (have not hit it very hard yet since it currently runs without a heatsink). Tnanks... Cheers//Frank -- W ___ ## o o\/ Frank de Lange \ }# \| / \ ##---# _/ Hacker for Hire \ \ +31-320-252965/ \[EMAIL PROTECTED]/ - [ Hacker: http://www.jargon.org/html/entry/hacker.html ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
James,
The patch I referred to can be found in Dave's message... I gave him some
feedback on the problems with Winchips...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ Hacker for Hire \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ Hacker: http://www.jargon.org/html/entry/hacker.html ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt/Sleep deadlock
In article [EMAIL PROTECTED], Ivan Passos [EMAIL PROTECTED] wrote: "You could use a semaphore for this. Initialize it to 0, then call down() from the ioctl, and up() from the interrupt handler. If the up() happens before the down(), the down() won't go to sleep." Initializing it to 0 means: cfg_sem = MUTEX_LOCKED; It's the simplest to understand, and it works great!! Does anybody see a problem with this implementation?? No. This is in fact how the SCSI layer has handled similar issues for a _loong_ time now, so it had better work - and it does. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OT] linux article with kernel references
http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html good article, several unfortunate truths within. -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BTTV/TDA card, msp34xx keeps trying to come up
bttv0: model: BT848A( *** UNKNOWN *** ) [autodetected] How about fixing this first? The card list knows about a few cards where it better should'nt load the msp3400 driver... i2c-dev.o: Registered 'bt848 #0' as minor 0 msp34xx: I/O error #1 (read 0x12/0x1e) msp34xx: I/O error #2 (read 0x12/0x1e) msp34xx: I/O error #3 (read 0x12/0x1e) msp34xx: giving up, reseting chip. Sound will go off, sorry folks :-| [ ... ] msp34xx: init: chip=MSP34255?-?31, has NICAM support Looks like some other chip sits on the msp3400 address (0x80). --FC65C078C8667B167104A05D Content-Type: text/x-vcard; charset=us-ascii; name="david.vcf" Plese disable this. Gerd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
OOPS REPORT: Will someone _please_ look at this? (was Re: BUG OOPS REPORT: /proc/scsi/ entries not properly cleaned up)
Yet more followup with myself I can reproduce this problem on 2.4.0-test10-pre1 every time. I'm using the ide-scsi and usb-storage modules to trigger the bug -- loading and then unloading either one causes /proc/scsi to not be cleaned up properly. As yet, nobody has indicated to me that they are looking into this problem. I've taken a few experimental pokes at it, and it seems that the SCSI layer is, in fact, calling the procfs function to remove the entries. At least, I think it is -- I'm not sure if it's the right entry. Will someone _please_ look at this? I consider this a critical item for 2.4.0, and I hope others do too. Matt On Mon, Oct 02, 2000 at 06:00:53PM -0700, Matthew Dharm wrote: Following up yet some more with myself... is anyone actually looking at this stuff? I can provide even more information if desired, but I'd really like to know that at least one person who understands this code is looking at it Anyway, I managed to get a better OOPS trace. Here it is: ksymoops 0.7c on i586 2.4.0-test9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9/ (default) -m /boot/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Reading Oops report from the terminal Unable to handle kernel paging request at virtual address d38c2010 c0145032 *pde = 01594063 Oops: 0002 CPU:0 EIP:0010:[c0145032] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: d38c2000 ebx: cf93f0a0 ecx: c1466fc0 edx: 0023 esi: c6c1a360 edi: cf93f0f4 ebp: ffea esp: c8be7ef0 ds: 0018 es: 0018 ss: 0018 Process ls (pid: 11563, stackpage=c8be7000) Stack: c7f81360 c49c17e0 c0146a9c c144b800 1190 cf93f0a0 fff4 c7f81360 c49c17e0 c49c1834 c0137083 c49c17e0 c7f81360 c8be7f68 c9f0f013 c01377c4 c7f812e0 c8be7f68 c9f0f000 c8be7fa4 Call Trace: [c0146a9c] [c0137083] [c01377c4] [f27a545f] [c0137daa] [c0134a71] [c010a413] Code: ff 40 10 8b 43 24 80 48 14 18 66 8b 43 08 25 00 f0 ff ff 66 EIP; c0145032 proc_get_inode+96/108 = Trace; c0146a9c proc_lookup+68/8c Trace; c0137083 real_lookup+4f/b8 Trace; c01377c4 path_walk+5a0/7ec Trace; f27a545f END_OF_CODE+1eebbdb8/ Trace; c0137daa __user_walk+3a/54 Trace; c0134a71 sys_newlstat+15/70 Trace; c010a413 system_call+33/40 Code; c0145032 proc_get_inode+96/108 _EIP: Code; c0145032 proc_get_inode+96/108 = 0: ff 40 10 incl 0x10(%eax) = Code; c0145035 proc_get_inode+99/108 3: 8b 43 24 movl 0x24(%ebx),%eax Code; c0145038 proc_get_inode+9c/108 6: 80 48 14 18 orb$0x18,0x14(%eax) Code; c014503c proc_get_inode+a0/108 a: 66 8b 43 08 movw 0x8(%ebx),%ax Code; c0145040 proc_get_inode+a4/108 e: 25 00 f0 ff ffandl $0xf000,%eax Code; c0145045 proc_get_inode+a9/108 13: 66 00 00 addb %al,(%eax) 1 warning issued. Results may not be reliable. This is under the same test scenario as before -- load ide-scsi, unload ide-scsi, ls /proc/scsi It's interesting to note that 'cat /proc/scsi/scsi' works just fine -- only getting the directory listing seems to be broken, not the actual reading of files. Again, this was collected on 2.4.0-test9-pre7 -- but the behavior is the same for 2.4.0-test9-pre9. Matt On Sun, Oct 01, 2000 at 06:32:38PM -0700, Matthew Dharm wrote: Just to follow-up to my own post, I have some more datapoints... The bug definatley seems to be in either the SCSI layer or the procfs layer. The behavior is the same if I use either ide-scsi or usb-storage, which are the only two SCSI modules I can test. Matt On Fri, Sep 29, 2000 at 03:19:23PM -0700, Matthew Dharm wrote: I'm using 2.4.0-test9-pre7 and have a _very_ reproducable OOPS with the SCSI layer. Everything relevant is compiled as a module (except for the /proc support). The test scenario is this: (1) Boot the machine (2) modprobe ide-scsi (note this autoloads scsi_mod but nothing else) (3) rmmod ide-scsi (4) ls /proc/scsi Then the OOPS happens. If, instead of step (4), I instead re-modprobe ide-scsi again, then an 'ls /proc/scsi/' will show (without an immediate OOPS): [root@zen mdharm]# ls /proc/scsi/ ide-scsi/ ide-scsi/ scsi No, the double ide-scsi entry isn't a typo -- this is what ls reports as being there. The OOPS case is decoded
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Olaf Titz wrote: Still, it would be nice to recover that 4 MB when the system doesn't have any memory left. Yup. The X server could give back the memory for some cases like the background without too much hackery. Then Linux only needs to implement SIGDANGER, which has been talked about for years... X would be a good candidate to implement a handler for it. Others are Emacs, Mozilla or JVMs - basically everything which has a GC of some sort. It could even be used to implement a configurable user mode OOM killer. It would be good to talk to the KDE and Gnome folks about this as well. I am pretty sure they have large blocks of memory that could be flushed or freed in a low-memory or OOM condition. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect UDMA timing on VIA vt82c596b
Sorry if you get multiple copies of this--I have tried sending twice
already and have yet to see it on the kernel-list.
Jordan
Here are hdparms for all my devices--
`hdparm -i /dev/hda` IBM Deskstar 7200 RPM:
/dev/hda:
Model=IBM-DTLA-307075, FwRev=TXAOA50C, SerialNo=YS0YSF3Z455
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=3(DualPortCache), BuffSize=1916kB, MaxMultSect=16,
MultSect=off
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
CurCHS=4047/16/255, CurSects=-217054981, LBA=yes, LBAsects=150136560
tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 mode2 mode3 *mode4 mode5
`hdparm -i /dev/hdb` Iomega Zip 250 internal:
/dev/hdb:
HDIO_GET_MULTCOUNT failed: Input/output error
Model=IOMEGA ZIP 250 ATAPI, FwRev=51.G, SerialNo=
Config={ SpinMotCtl Removeable nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=0(?), BuffSize=0kB, MaxMultSect=0
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
tDMA={min:180,rec:180}, DMA modes: mword0
IORDY=on/off, tPIO={min:500,w/IORDY:180}, PIO modes: mode3
`hdparm -i /dev/hdc` Kenwood 72x CDROM:
/dev/hdc:
HDIO_GET_MULTCOUNT failed: Invalid argument
Model=KENWOOD CD-ROM UCR-421 V226G, FwRev=226, SerialNo=eSNr0 21S
:W.797*
Config={ Fixed Removeable DTR=5Mbs DTR10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=0(?), BuffSize=256kB, MaxMultSect=0
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
mword2
IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode4
UDMA modes: mode0 mode1 *mode2
`hdparm -i /dev/hdd` Plextor 12x10x32x CDRW:
/dev/hdd:
HDIO_GET_MULTCOUNT failed: Input/output error
Model=PLEXTOR CD-R PX-W1210A, FwRev=1.04, SerialNo=
Config={ Fixed Removeable DTR=5Mbs DTR10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=0(?), BuffSize=0kB, MaxMultSect=0
DblWordIO=no, OldPIO=4, DMA=yes, OldDMA=2
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
*mword2
IORDY=on/off, tPIO={min:180,w/IORDY:120}, PIO modes: mode3 mode4
Everything is working great! I can access my hard drive quickly, both
CD drives are working and I can read and write to my zip as a
partitioned drive or as a block device for Tar archives. Thanks for all
of the help.
Jordan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect UDMA timing on VIA vt82c596b
On Tue, Oct 10, 2000 at 01:42:51PM -0400, Mark Hahn wrote: Btw, reading the ATA/ATAPI-6 specs I think UDMA66 should work on a setup where would be just one drive and a really short, 40-wire cable without problems as well. I've even seen systems shipped like that. uh, what part of the spec leads you to that conclusion? I've haven't seen a draft more recent than ~1h2000, but they've been unambiguous about absolutely requiring 80-conductors for = ata66, and that two-connector cables must be 5=l=18, and three-connector cables 10=l=18. ATA/ATAPI-6 draft rev. 0a, page 14 (sheet 28 of 404), table 2, row 4, column 1, plus comment 4 in the same table. guess I should get a more up-to-date draft! And from the engineering point of view, it seems reasonable, too. noise/crosstalk-wise, sure. does the new spec also permit a min length less than 5" between host and dev1? The spec talks about three types of connection - "40-wire assembly", "80-wire assembly", both being three-connector cables with the limitations you cite. Plus it talks about a "direct point-to-point connection" for a single device case. There isn't any minimum length specified for that case. This may be some relict in the spec, though. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
vgaconsole driver SMP safe fix against linux-2.4.0-test9
My first contribution to kernel =) Someone please look over this one
carefully =)
Thanks
--- vgacon.c.bakTue Oct 10 13:50:09 2000
+++ vgacon.cTue Oct 10 14:48:06 2000
@@ -27,6 +27,9 @@
* flashing on RHS of screen during heavy console scrolling .
* Oct 1996, Paul Gortmaker.
*
+ * Change cli()/sti() to SMP safe spin_lock_irqsave()
+ * /spin_unlock_irqrestore() calls, Yong Chi.
+ * Oct-10-2000 [EMAIL PROTECTED]
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive for
@@ -50,6 +53,7 @@
#include linux/init.h
#include asm/io.h
+#include asm/spinlock.h
#define BLANK 0x0020
@@ -122,6 +126,10 @@
static intvga_video_font_height;
static unsigned intvga_rolled_over = 0;
+/*
+ * Spinlock used for irq atomic operations
+ */
+static spinlock_t irq_lock = SPIN_LOCK_UNLOCKED;
static int __init no_scroll(char *str)
{
@@ -152,8 +160,7 @@
* ddprintk might set the console position from interrupt
* handlers, thus the write has to be IRQ-atomic.
*/
- save_flags(flags);
- cli();
+ spin_lock_irqsave(irq_lock, flags);
#ifndef SLOW_VGA
v1 = reg + (val 0xff00);
@@ -166,7 +173,7 @@
outb_p(reg+1, vga_video_port_reg);
outb_p(val 0xff, vga_video_port_val);
#endif
- restore_flags(flags);
+ spin_unlock_irqrestore(irq_lock, flags);
}
static const char __init *vgacon_startup(void)
@@ -415,7 +422,7 @@
if ((from == lastfrom) (to == lastto)) return;
lastfrom = from; lastto = to;
- save_flags(flags); cli();
+ spin_lock_irqsave(irq_lock, flags);
outb_p(0x0a, vga_video_port_reg); /* Cursor start */
curs = inb_p(vga_video_port_val);
outb_p(0x0b, vga_video_port_reg); /* Cursor end */
@@ -428,7 +435,7 @@
outb_p(curs, vga_video_port_val);
outb_p(0x0b, vga_video_port_reg); /* Cursor end */
outb_p(cure, vga_video_port_val);
- restore_flags(flags);
+ spin_unlock_irqrestore(irq_lock, flags);
}
static void vgacon_cursor(struct vc_data *c, int mode)
@@ -531,13 +538,14 @@
static void vga_vesa_blank(int mode)
{
+ unsigned long flags;
/* save original values of VGA controller registers */
if(!vga_vesa_blanked) {
- cli();
+ spin_lock_irqsave(irq_lock, flags);
vga_state.SeqCtrlIndex = inb_p(seq_port_reg);
vga_state.CrtCtrlIndex = inb_p(vga_video_port_reg);
vga_state.CrtMiscIO = inb_p(video_misc_rd);
- sti();
+ spin_unlock_irqrestore(irq_lock, flags);
outb_p(0x00,vga_video_port_reg);/* HorizontalTotal */
vga_state.HorizontalTotal = inb_p(vga_video_port_val);
@@ -561,7 +569,7 @@
/* assure that video is enabled */
/* "0x20" is VIDEO_ENABLE_bit in register 01 of sequencer */
- cli();
+ spin_lock_irqsave(irq_lock, flags);
outb_p(0x01,seq_port_reg);
outb_p(vga_state.ClockingMode | 0x20,seq_port_val);
@@ -598,13 +606,15 @@
/* restore both index registers */
outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
- sti();
+ spin_unlock_irqrestore(irq_lock, flags);
}
static void vga_vesa_unblank(void)
{
+ unsigned long flags;
+
/* restore original values of VGA controller registers */
- cli();
+ spin_lock_irqsave(irq_lock, flags);
outb_p(vga_state.CrtMiscIO,video_misc_wr);
outb_p(0x00,vga_video_port_reg);/* HorizontalTotal */
@@ -629,7 +639,7 @@
/* restore index/control registers */
outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
- sti();
+ spin_unlock_irqrestore(irq_lock, flags);
}
static void vga_pal_blank(void)
@@ -710,6 +720,7 @@
int beg;
unsigned short video_port_status = vga_video_port_reg + 6;
int font_select = 0x00;
+ unsigned long flags;
if (vga_video_type != VIDEO_TYPE_EGAM) {
charmap = (char *)VGA_MAP_MEM(colourmap);
@@ -750,7 +761,7 @@
charmap += 4*cmapsz;
#endif
- cli();
+ spin_lock_irqsave(irq_lock, flags);
outb_p( 0x00, seq_port_reg ); /* First, the sequencer */
outb_p( 0x01, seq_port_val ); /* Synchronous reset */
outb_p( 0x02, seq_port_reg );
@@ -766,7 +777,7 @@
outb_p( 0x00, gr_port_val );/* disable odd-even addressing */
outb_p( 0x06, gr_port_reg );
outb_p( 0x00, gr_port_val );/* map start at A000: */
- sti();
+ spin_unlock_irqrestore(irq_lock, flags);
if (arg) {
if (set)
@@ -793,7 +804,7 @@
}
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote: On Tue, 10 Oct 2000, Ingo Oeser wrote: before you argue endlessly about the "Right OOM Killer (TM)", I did a small patch to allow replacing the OOM killer at runtime. So now you can stop arguing about the one and only OOM killer, implement it, provide it as module and get back to the important stuff ;-) This is definately a cool toy for people who have doubts that my OOM killer will do the wrong thing in their workloads. I think this can be useful for more than just a cool toy. I think that the main thing that this discusion has shown is no OOM killer will please 100% of the people 100% of the time. I think we should try and have a good generic OOM killer that kills the right process most of the time. People can impliment (and submit) different-style OOM killers as needed. Or at least get 'em on freshmeat. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel.org verification key updated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems that there was some mangling problems going on with the message I sent last night, so I wanted to try to re-send it with a proper signature this time... Hi everyone, I just wanted to let everyone know that we have changed the cryptographic key for the Linux Kernel Archives. The reason is that the original key was generated with an expiration date, and unfortunately it appears that too much software out there doesn't support changing the expiration date on an already valid key (the ability to do that, arguably, makes the expiration date useless anyway.) Therefore, we have revoked key 1E1A8782 generated 1999-10-15 [that should have been 1999-10-05] and replaced it with key 517D0F0E generated 2000-10-10. Please see http://www.kernel.org/signature.html for more information. The archive machine is currently in process of generating new signature files; they should be distributed to mirrors shortly thereafter in normal order. -hpa - -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.3 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE542mjfZ3uzivLxiERAtyTAKDeRq72ew710rxqGnRf51pBrNgVzACcDFaF ctVXZ3QxiYrpgtgGAdtfpeM= =hUKH -END PGP SIGNATURE- -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DProbes with LTT
Karim, I've been back through an initial evaluation we did for LTT, back in May. One of the feature we highlighted we'd like to see was an ability to specify custom formatting templates. Our original OS/2 trace facility allowed the user to generate formatting templates which would specify printf-like controls. The templates were defined per major-minor code specification, which was used to identify uniquly a formatting type and was recorded with the trace record in the header. We'd like to see that functionality in LTT. Would port the code from OS/2 if LTT had a suitable formatting exit for custom events. Any thoughts on this? Richard Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
On Tue, Oct 10, 2000 at 02:08:45PM -0400, [EMAIL PROTECTED] wrote: I am one of those people that uses PCMCIA on an SMP machine, I also use 2.4. Aside from the very occasional problem, I don't see any locking issues. Is it possible to just leave it as is with a warning? I think the configuration should still permit it; the probability of hitting the locking issue in the ds module is vanishingly small. The problem of non-SMP-tested PCMCIA drivers is more serious, but I'd really call all the 2.4 PCMCIA code "experimental" at this point. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.3.99 pre2 CBQ
Hi all Has anyone tried testing CBQ with 2.3.99 pre2 kernel. I tried to set up CBQ on an ATM interface and was not able to notice any differentiation or treatment to packets even when I use 'bounded' with the tc commands. I tried to test it with a 2.2.10 kernel using ds-8 and appropriate tc, and it works perfectly, i.e. I can see the class differentiation. Do I have to add some patch to the 2.3.99 pre2 kernel to make it capable of providing appropriate treatment. I believe the 2.3.99 kernels themselves have the inbuilt support for the same. I would be greatful if someone can give me some clue or pointers to the same. thanks, Ramesh. P.S : Please CC the reply to me coz I haven't subscribed to the list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] Re: test [PATCH] new vgacon and vga16fb Part II
And I suggest this addition (cfr. the other fbcon-*.c since 2.4.0-test5-pre5): Done. I have alot more big changes coming :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
2. Capable Of Corrupting Your FS/data
* Non-atomic page-map operations can cause loss of dirty bit on
pages (sct, alan)
Is anybody looking into fixing this bug ?
9. To Do
* mm-rss is modified in some places without holding the
page_table_lock (sct)
Probably not a show-stopper, but we're looking for
volunteers to fix this one anyway ;)
* VM: Out of Memory handling {CRITICAL}
Seems to work now, except for the fact that it is possible
to end up with a heavily thrashing system that /just/ didn't
run out of memory and doesn't get anything killed.
Then again, you can end up with a heavily thrashing system
where you can't get anything done without running out of swap
anyway ... the proper fix for this is probably some form of
thrashing control...
* VM: Fix the highmem deadlock, where the swapper cannot create low
memory bounce buffers OR swap out low memory because it has
consumed all resources {CRITICAL} (old bug, already reported in
2.4.0test6)
Haven't been able to reproduce it on my 1GB test machine,
but it might still be there. Can anyone confirm if this
bug is still present ?
* VM: page-mapping-flush() callback in page_lauder() for easier
integration with journaling filesystem and maybe the network
filesystems
Possibly a 2.5 issue, or something to merge later in 2.4,
since we don't have journaling filesystems in the kernel
anyway. I guess we'll want it for the network filesystems
though.
But this is a fairly simple thing to integrate:
1) have an appropriate function in the filesystems
2) insert function pointer in the right struct
3) call the function from vmscan.c::page_launder()
* VM: maybe rebalance the swapper a bit... we do page aging now so
maybe refill_inactive_scan() / shm_swap() and swap_out() need to
be rebalanced a bit
I'll try to look into this (3 days to go before I have to
leave for Miami) and see how things can be improved here.
11. To Check
* VFS?VM - mmap/write deadlock (demo code seems to show lock is
there)
Does anyone have the demo code at hand so we can verify if this
still happens ?
* Stressing the VM (IOPS SPEC SFS) with HIGHMEM turned on can hang
system (linux-2.4.0test5, Ying Chen, Rik van Riel)
Ditto. Can this still be reproduced with the latest VM or was
it simply a side effect of something else in the VM that got
fixed recently ?
(the highmem code itself looks ok so the bug might well have
been caused by a side effect of something else)
12. Probably Post 2.4
* addres_space needs a VM pressure/flush callback (Ingo)
[duplicate item?]
We may want this to better support the journaling filesystems
in 2.4 but I agree that it should probably be post 2.4.0.
* VM: physical-virtual reverse mapping, so we can do much better
page aging with less CPU usage spikes
* VM: better IO clustering for swap (and filesystem) IO
* VM: move all the global VM variables, lists, etc. into the pgdat
struct for better NUMA scalability
* VM: (maybe) some QoS things, as far as they are major improvements
with minor intrusion
These 4 seem /definate/ 2.5 issues, though I hope to have them
(except maybe QoS?) ready in an patch before 2.5.0 is split off.
* VM: thrashing control, maybe process suspension with some forced
swapping ?
* VM: include Ben LaHaise's code, which moves readahead to the VMA
level, this way we can do streaming swap IO, complete with
drop_behind()
These two are fairly simple and may well be done in the next
few weeks. If no bug reports about the current 2.4 VM pop up,
I'll probably look into some of the issues above...
FYI, my personal VM TODO list:
- see if refill_inactive_scan(), swapout_shm(), swap_out(), etc...
need rebalancing
- anti-thrashing code (if no hidden nasties are present)
- better IO clustering + readahead at VMA level
AFAIK Juan Quintela is already looking into the -flush()
callback for journaling filesystems.
And one more TODO item:
* pinned page reservation system for journaling filesystems
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On Tue, 10 Oct 2000, Tom Rini wrote: On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote: On Tue, 10 Oct 2000, Ingo Oeser wrote: before you argue endlessly about the "Right OOM Killer (TM)", I did a small patch to allow replacing the OOM killer at runtime. So now you can stop arguing about the one and only OOM killer, implement it, provide it as module and get back to the important stuff ;-) This is definately a cool toy for people who have doubts that my OOM killer will do the wrong thing in their workloads. I think this can be useful for more than just a cool toy. I think that the main thing that this discusion has shown is no OOM killer will please 100% of the people 100% of the time. I think we should try and have a good generic OOM killer that kills the right process most of the time. People can impliment (and submit) different-style OOM killers as needed. Indeed, though I suspect most of the people trying this would fall into the trap of over-engineering their OOM killer, after which it mostly becomes less predictable ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
__bad_udelay in 2.2.18pre15
2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : ... extern void __bad_udelay(void); ... #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Marcelo Tosatti [EMAIL PROTECTED] writes: 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : ... extern void __bad_udelay(void); ... #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. Which is the whole point - you wouldn't want to call a bad function, would you? If you reference __bad_udelay() you are doing something wrong and should be using mdelay() instead. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 452062 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0test-9: IDE problems
Hi,
Finally got around to trying out 2.4.0test9. I'm going to do some VM
performance comparisons (incidentally because VM should be a carefully
measured science not random cool idea of the day which we have seen too
much of recently).
Unfortunately, I can't start fair tests yet because UDMA3 refuses to
activate in 2.4.0test-9.
I get these messages on boot
ide0: Speed warnings UDMA 3/4/5 is not functional.
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide0: reset: success
hda: DMA disabled
Subsequently, if I run
hdparm -d1 -X67 /dev/hda
I get told
ide0: Speed warnings UDMA 3/4/5 is not functional.
And this leaves me with
/dev/hda:
Timing buffered disk reads: 64 MB in 5.71 seconds = 11.21 MB/sec
Under the stock 2.2 RedHat 7.0 kernel, the same hdparm tuning gives me
about 17Mb/s.
Anyone got any hints? I selected the ATA option. Might this be causing the
failure?
Anyone got any hints?
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Further info on CDR-writing problems under 2.2.16
On Mon, Aug 14, 2000 at 11:55:13PM +0100, Athanasius wrote: I'm on 2.2.17pre13 (not the latest I know, I need to sort out compiling latest and a reboot), my Mitsumi CR-4804TE CD-R/RW drive seems to work happily enough with xcdroast to write one disk, but then goes into super sulk mode, even getting to the stage of not wanting to mount and read a normal CD (I don't think it's actively objecting to the old Win95 CD I used to test...). The first time this happened a reboot seemed to clear it up. I prefer not to reboot unless I have to so haven't again yet. Ok, I'm on 2.2.18pre15 now, and using mkisofs and cdrecord directly. I'm also using 'speed=2' on the cdrecord commandline. If it's relevant, this is using IDE-SCSI emulation. Now, I've just managed to write 4 CDs in a row on one bootup fine, but the 5th one bombed out nastily (as I was writing the first version of this email, it must have been watching). I'm trying again with a: echo 1 /proc/sys/dev/cdrom/debug Ah, it's just crapped out again, all be it twice as far in this time (95MB in rather than 43MB). H, those first 4 burns mostly had big gaps inbetween (1 and 2 had quite a gap, 2 to 3 was 12 hours and more, 3 and 4 were done right after each other). I wonder if I simply have some overheating problem in the drive. Anyways, some more data to add to the pile, hopefully it helps someone track down the culprit. thanks, -Ath -- - Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/ Finger athan(at)fysh.org for PGP key "Hold on. Hold on to yourself. For this is gonna hurt like hell. Hold on. Hold on to yourself. I know that only time will tell." - Sarah McLachlan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
On Tue, Oct 10, 2000 at 06:10:48PM -0700, James Simmons wrote:
Dave,
This patch fixed the problems, for now. The system now boots OK, and seems to
run OK (have not hit it very hard yet since it currently runs without a
heatsink). Tnanks...
Cheers//Frank
Oops... looks like I was too quick to cry success... It does NOT work, even
with the patch. I tried it again and again, and could not get it to boot. I
probably put a wrong (Pentium MMX) kernel on the flashdisk when I first tested
your patch, which led me to believe it did, indeed, work. After repeated
experiments I can only conclude thay Winchip2A is still hosed, even when
reverse-applying the patch Dave sent. I'll try to find out where it stops using
the DISPLAY_.. trick...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ Hacker for Hire \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ Hacker: http://www.jargon.org/html/entry/hacker.html ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: tmscsim update for Linux 2.2.18pre15?
On Tue, 10 Oct 2000, Kurt Garloff wrote: Actually, 2.0e3 did include one rather important fix which solved the Uh. Fix? This sounds like working around very broken devices to me, or are devices allowed to wreak havoc if sync negotiation is tried in spite of not being advertised in inquiry data? I'll happily sent a patch against 2.4.0t9 and/or 2.2.18p15 to Linus/Alan to get an updated version included in the mainstream kernel. Sounds good. Thanks a lot! PGP signature
Re: 2.4.0test-9: IDE problems
Basically you have drive that caught in the word93 rules change.
However, the error you got were real and the kernel did properly respeed
the drive to one step slower. The problem above prevented you from going
from ATA66 to ATA44, thus you fell to ATA33.
You RHS 7.0 kernel does not have all the fallback and rules testing to
keep things running the very best and in the safest way. Also you do not
have the rules for testing if the driver/host/device register and report
that all signals are valid and stable.
If you did not set TUNING option if the chipset has it specifically
flagged then you will not be able to retune the chipset/drive and the IO
will be out of sync.
At best it will reject DMA attempts, at worst this will do bad things to
data.
The stuff that 2.4 has that 2.2 does not have is following the rules and
guidelines set forth by the folks writing the rules.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
diff -urN linux-2.4.0-t10-1-pristine/drivers/ide/ide-features.c
linux-2.4.0-t10-1.smsc/drivers/ide/ide-features.c
--- linux-2.4.0-t10-1-pristine/drivers/ide/ide-features.c Thu Aug 3 16:07:42
2000
+++ linux-2.4.0-t10-1.smsc/drivers/ide/ide-features.c Tue Oct 10 00:00:38 2000
@@ -224,7 +224,8 @@
#ifndef CONFIG_IDEDMA_IVB
if ((drive-id-hw_config 0x6000) == 0) {
#else /* !CONFIG_IDEDMA_IVB */
- if ((drive-id-hw_config 0x2000) == 0) {
+ if (((drive-id-hw_config 0x2000) == 0) ||
+ ((drive-id-hw_config 0x4000) == 0)) {
#endif /* CONFIG_IDEDMA_IVB */
printk("%s: Speed warnings UDMA 3/4/5 is not functional.\n",
drive-name);
return 1;
@@ -260,7 +261,7 @@
#ifndef CONFIG_IDEDMA_IVB
(drive-id-hw_config 0x4000)
#endif /* CONFIG_IDEDMA_IVB */
- (drive-id-hw_config 0x2000)) ? 1 : 0);
+ (drive-id-hw_config 0x6000)) ? 1 : 0);
}
/*
Re: 2.4.0test-9: IDE problems
On Tue, 10 Oct 2000, Andre Hedrick wrote: Basically you have drive that caught in the word93 rules change. However, the error you got were real and the kernel did properly respeed the drive to one step slower. The problem above prevented you from going from ATA66 to ATA44, thus you fell to ATA33. You RHS 7.0 kernel does not have all the fallback and rules testing to keep things running the very best and in the safest way. Also you do not have the rules for testing if the driver/host/device register and report that all signals are valid and stable. Yes, I had some "interesting" modifications to a lot of my /usr when I tried to activate UDMA4 under RH7.0 (I don't believe my hardware is capable of UDMA4!) If you did not set TUNING option if the chipset has it specifically flagged then you will not be able to retune the chipset/drive and the IO will be out of sync. Shortly after my first post, I noticed and activated the Intel PIIX4 support + tuning. This got rid of the nasty errors but didn't get my 17Mb/sec. Trying your patch now. Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: getting struct pci_dev from struct netdevice
Not directly, but pci_dev knows about netdevice, so you can scan the pci_dev's to find a match with the required netdevice. (Or do a similar match search on base_addr) Not I suspect reliably. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spurious 8259A interrupt?
Initializing CPU#0 You are using a SMP kernel on a `386 UP machine. That tends to make these burps show up. It is harmless, though. It says this either way Console: colour VGA+ 80x25 Calibrating delay loop... 3.10 BogoMIPS This shows something I don't understand. Either the counter wrapped, a timer is mis-programmed, or the CPU clock speed is about 1.5 MHz. 3 bogomips is right for a 386SX You should look into this. Older kernels generally show the BogoMIPS as being about equal to the CPU clock speed +/- 20%. Newer kernels generally show it being about 2 times the clock speed +/- 20%. Only if they have a TSC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
Ok, I've narrowed it down to the changes to mtrr.c in test8 Looks like the Cyrix III changes broke things. Didn't something similar happen when these changes made it into a 2.2.18pre ? Alan? 2.2.18pre12 or so had a bug with Winchip but its fixed in pre15 I believe, at least my winchip is running 2.2.18pre15 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0test-9: IDE problems
Also set this option "CONFIG_IDEDMA_IVB" because you are in the transistion period of drive manufacturing. On Tue, 10 Oct 2000, Chris Evans wrote: On Tue, 10 Oct 2000, Andre Hedrick wrote: Basically you have drive that caught in the word93 rules change. However, the error you got were real and the kernel did properly respeed the drive to one step slower. The problem above prevented you from going from ATA66 to ATA44, thus you fell to ATA33. You RHS 7.0 kernel does not have all the fallback and rules testing to keep things running the very best and in the safest way. Also you do not have the rules for testing if the driver/host/device register and report that all signals are valid and stable. Yes, I had some "interesting" modifications to a lot of my /usr when I tried to activate UDMA4 under RH7.0 (I don't believe my hardware is capable of UDMA4!) If you did not set TUNING option if the chipset has it specifically flagged then you will not be able to retune the chipset/drive and the IO will be out of sync. Shortly after my first post, I noticed and activated the Intel PIIX4 support + tuning. This got rid of the nasty errors but didn't get my 17Mb/sec. Trying your patch now. Cheers Chris Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On Tue, Oct 10, 2000 at 05:58:46PM -0300, Rik van Riel wrote: On Tue, 10 Oct 2000, Tom Rini wrote: On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote: On Tue, 10 Oct 2000, Ingo Oeser wrote: before you argue endlessly about the "Right OOM Killer (TM)", I did a small patch to allow replacing the OOM killer at runtime. So now you can stop arguing about the one and only OOM killer, implement it, provide it as module and get back to the important stuff ;-) This is definately a cool toy for people who have doubts that my OOM killer will do the wrong thing in their workloads. I think this can be useful for more than just a cool toy. I think that the main thing that this discusion has shown is no OOM killer will please 100% of the people 100% of the time. I think we should try and have a good generic OOM killer that kills the right process most of the time. People can impliment (and submit) different-style OOM killers as needed. Indeed, though I suspect most of the people trying this would fall into the trap of over-engineering their OOM killer, after which it mostly becomes less predictable ;) I was thinking more along the lines of ones w/ "safety" features that not everyone might like/need (ie /usr/local/bin/foo is always good, those sugjestions). It seems like useful functionality at little/no cost. And a neat toy for now. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Announce: modutils 2.3.18 is available
ftp://ftp.country.kernel.org/pub/linux/utils/kernel/modutils/v2.3 patch-modutils-2.3.18.bz2 Patch from modutils 2.3.17 to 2.3.18 modutils-2.3.18.tar.bz2 Source tarball, includes RPM spec file modutils-2.3.18-1.src.rpm As above, in SRPM format modutils-2.3.18-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2 Changelog extract * Correct typo in modutils.spec use of mandir. * Ignore addressless symbols in System.map, by Ivan Kokshaysky. * No error on unexpected relocate sections if they are empty. * Generate modules.isapnpmap from MODULE_DEVICE_TABLE(isapnp) and ISAPNP_CARD_TABLE. * Add .rhkmvtag to prune list. * Include filename in "not an ELF file" message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: getting struct pci_dev from struct netdevice
Since struct pci_dev is probably going to morph into a more generic struct hw_dev, maybe struct netdevice needs a pci_dev member... There is no guarantee there would be a meaningful pci_dev. In addition in a hot pluggable box the pointer is useless since it will change arbitarily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DProbes with LTT
Richard,
Definitely a good idea. Enabling the programmer to specify the format of
the custom data to be printed would be great. Having this in mind, this
is why LTT has two events to enable custom tracing, the "New event" and
the "custom event". Therefore, extending the definition of "New event"
leaves a lot of possibilities open.
Here's what I had in mind for LTT (feel free to comment on this as it
is only a design for now):
In the creation of a new event, the caller of the "create event ID"
function would provide the following information:
1) An event-type string that will mainly be used to identify this
amongst the other events. ex: an IRQ entry has a string describing
it which is "IRQ entry", it also has a string describing the event in
detail, this is the purpose of #2 below.
2) A printf-style string used to print out the formatted event string.
ex: "XYZ Driver received unknown event %d on I/O port %03X with error %C"
3) A 0-terminated table containing a structure-type which has 2 entries:
-A data-length type (fixed or variable)
-A data-length (if fixed)
Each entry would describe each of the data types that will be used with
the printf-like string
ex using the above string: the "%d" would be the first entry with a fixed
data-length of 4 bytes, the "%03X" would be the second entry with a fixed
data-length of 4 bytes, the "%C" would be the third entry with a fixed
data-length of 2 bytes. In the case of a "%s", the data-length type would
be "variable". The last entry in the table would be filled with zeros
as to show the table's end.
As previously mentioned, the "create event ID" would return a unique
event Id for the newly created event.
With this scheme, recording a custom event would amount to providing
the existing trace function with the custom event ID and a pointer to
a buffer containing the packed data to be used with the pre-provided
string. Using the example above, the caller would pass a buffer
containing the following data packed in a single buffer:
4 bytes data for "%d", 4 bytes data for "%03X", 2 bytes for "%C", for
a total of a 10 byte-buffer. The tracing function will automatically
determine the length of the buffer since it was determined upon event ID
creation. In the case that the buffer contained a string, the first word
before the string would contain the string size so that the function would
determine the exact length of the whole buffer. That said, it must be
stressed that using strings in trace statements is expensive given the
processing cost of finding out buffer lengths and so on. Therefore,
strings should be regarded as a last resort.
Once the trace is complete, the trace visualization tool would retrieve
the custom events list and read the trace according to those descriptions.
It would then output the description strings and the details string to
signal the event's occurrence in the trace. To print out the details string,
printf or one of it's variants would be provided with the printf-like
string, provided upon event-type creation, and the data belonging to the
event traced. With the example above, this would be something like:
printf("XYZ Driver received unknown event %d on I/O port %03X with error %C",
"the 4 bytes given for %d",
"the 4 bytes given for %03X"
,
etc.);
This is figurative as the real parameters would most likely be pointers and
since the printf call would have a variable amount of parameters (as always).
The advantage of using this rather than major-minor code is that the data
formatting capabilities provided are exactly the ones most programmers are
already familiar with. Though I might have missed some limitations of this
scheme that the major-minor code scheme overcomes.
What do you think?
Karim
[EMAIL PROTECTED] wrote:
Karim,
I've been back through an initial evaluation we did for LTT, back in May.
One of the feature we highlighted we'd like to see was an ability to
specify custom formatting templates. Our original OS/2 trace facility
allowed the user to generate formatting templates which would specify
printf-like controls. The templates were defined per major-minor code
specification, which was used to identify uniquly a formatting type and was
recorded with the trace record in the header.
We'd like to see that functionality in LTT. Would port the code from OS/2
if LTT had a suitable formatting exit for custom events. Any thoughts on
this?
Richard
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from
Is 2.4.0 ready for the AMD 760 MP dual Athlon chip set?
Hello, AMD has rolled out the new AMD 760 MP dual Athlon chip set at the 2000 Microprocessor Forum. Here are the links: http://www.amd.com/news/prodpr/20165.html http://www.amd.com/news/virtualpress/mpf/richheyepres.pdf Someone working on support for it? The chip set seems like the Alpha Tsunami to me. Thanks for response. Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
It is not a configuration that I currently test. I am told it mostly works, though some client drivers are not SMP safe. It is something that should be fixed eventually, for sure, but given the number of open issues with PCMCIA in 2.4, I don't think it is high on the list. If you want to say that PCMCIA on SMP is unsupported until someone carefully checks it out and fixes these things, I suppose that's fine. If we wish to do this then we might as well be honest about the current code and say 'power management doesnt work on SMP either' alternatively the right thing to do is to fix both PM and the pcmcia. Most of the PCMCIA can be fixed for 2.4 by dropping lock_kernel() around the relevant areas. Sure its ugly but PCMCIA hot swapping is not a critical performance code path. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] linux article with kernel references
http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html good article, several unfortunate truths within. Really, must be a wrong URL you posted then 8) The average Linux kernel hacker right now is late 20's to early 30's with a degree and working professionally on the kernel (Its entertaining to go over the contents of MAINTAINERS now and 2 years ago and see who then and now is paid to work on Linux) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : extern void __bad_udelay(void); #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. Correct. Its a compile time error trap - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0test-9: IDE problems
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Bad CRC is a cable error. That could be misconfiguration but could also be
crap cables
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0test-9: IDE problems
On Tue, 10 Oct 2000, Andre Hedrick wrote: Also set this option "CONFIG_IDEDMA_IVB" because you are in the transistion period of drive manufacturing. Turned that on, applied the patch. BTW, your patch seems to make the "Speed warnings" failure _more_ likely?? Still refuses to activate UDMA3. 11.5Mb/sec vs. 17Mb/sec in 2.2. Is my hardware trying to tell me that 2.2 shouldn't be allowing me to run with UDMA3? It's rock solid and yes I've given it a pounding. Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0test-9: IDE problems
have the rules for testing if the driver/host/device register and report that all signals are valid and stable. Yes, I had some "interesting" modifications to a lot of my /usr when I tried to activate UDMA4 under RH7.0 (I don't believe my hardware is capable of UDMA4!) The 2.2 kernel we ship doesnt have the ide patches either so Im not suprised it got upset 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0test-9: IDE problems
On Wed, 11 Oct 2000, Alan Cox wrote:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Bad CRC is a cable error. That could be misconfiguration but could also be
crap cables
It went away when I enabled PIIX4 support + PIIX4 tuning support.
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0test-9: IDE problems
On Wed, 11 Oct 2000, Alan Cox wrote: The 2.2 kernel we ship doesnt have the ide patches either so Im not suprised it got upset 8) Ah yes you're correct. I saw the patch in the kernel SRPM but didn't look far enough to see: ... # IDE patch provides UDMA66 support, but is known to corrupt filesystems # on a few systems, so is not applied by default. Patch151: linux-2.2.16-ide-2805.patch ... # Dangerous IDE patch available but off by default #%patch151 -p1 ... Still, with hdparm -d1 -X67, I can presumably get UDMA3 and good 2.2 speeds (17Mb/s, or 21Mb/s with rawio) without this patch. Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0test-9: IDE problems
On Wed, 11 Oct 2000, Chris Evans wrote: ... # IDE patch provides UDMA66 support, but is known to corrupt filesystems # on a few systems, so is not applied by default. Patch151: linux-2.2.16-ide-2805.patch ... # Dangerous IDE patch available but off by default #%patch151 -p1 ... Should I send RedHat an unpatch for 2.4? Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
OK, some more info on the hang with the Winchip2A:
it seems to hang in arch/i386/kernel/setup.c, function print_memory_map, on the
first iteration of the loop. If I target to Pentium MMX and run it on the same
(Win)chip, all's well. There's something wrong here, but it is not in that
piece of code I presume... Will continue the search from here...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ Hacker for Hire \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ Hacker: http://www.jargon.org/html/entry/hacker.html ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
new 3dfx framebuffer driver released
Hi Linus, I'm maintaining a more recent driver for 3dfx cards than that one in the kernel now. A made my latest release as a patch for 2.4.0-test9. It can be downloaded from http://www.medex.hu/~danthe/tdfx. I won't attach it, because it's too long. Main changes: - voodoo5 support - MIPS support - multihead support - support other than 8 bit width fonts - 2.4 style device initialization (pci_driver API) - many bugfixes and testing Please apply. Bye, Attila Kesmarki [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: new 3dfx framebuffer driver released
Hi, A forgot to use the [PATCH] in the subject of my last mail, so I just send it again. Sorry. Bye, Attila -- Forwarded Message -- Hi Linus, I'm maintaining a more recent driver for 3dfx cards than that one in the kernel now. A made my latest release as a patch for 2.4.0-test9. It can be downloaded from http://www.medex.hu/~danthe/tdfx. I won't attach it, because it's too long. Main changes: - voodoo5 support - MIPS support - multihead support - support other than 8 bit width fonts - 2.4 style device initialization (pci_driver API) - many bugfixes and testing Please apply. Bye, Attila Kesmarki [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0test9 vm: disappointing streaming i/o under load
Hi, Finally got round to checking out 2.4.0test9. Unfortunately, 2.4.0test9 exhibits poor streaming i/o performance when under a bit of memory pressure. The test is this: boot with mem=32M, log onto GNOME and start xmms playing a big .wav ripped from a CD (this requires 100-200k read i/o per second). Then, I start then kill netscape. I then started a find / and started gnumeric firing up at the same time. Results === 2.2 RH7.0: the music skipped maybe twice briefly during the test. 2.4.0test9: music stuttered repeatedly while netscape started. Worse, when firing up gnumeric with the find / on the go, there were big pauses in sound output. On pause was over 5 seconds!!! So not so hot. Could this perhaps be related to the drop_behind magic penalizing streaming i/o pages too much? Perhaps the greater ago on the i/o pages means that when there is a little memory pressure, they are getting thrown out the page cache before the app (xmms) gets a chance to use them! Might it be useful for me to try pre10-1, I note it has more "balancing fixes". Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] linux article with kernel references
Hi, On Wed, 11 Oct 2000, Alan Cox wrote: http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html good article, several unfortunate truths within. Really, must be a wrong URL you posted then 8) The average Linux kernel hacker right now is late 20's to early 30's with a degree and working professionally on the kernel The article isn't that wrong, that several people get paid now for hacking doesn't change much. It's more about proper software engineering, some people call it "a matter of taste" and are born with it, but for other people it's a hard learning process. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] linux article with kernel references
On Wed, 11 Oct 2000 02:06:52 +0200 (MET DST), Roman Zippel [EMAIL PROTECTED] wrote: Hi, On Wed, 11 Oct 2000, Alan Cox wrote: http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html good article, several unfortunate truths within. Really, must be a wrong URL you posted then 8) The average Linux kernel hacker right now is late 20's to early 30's with a degree and working professionally on the kernel The article isn't that wrong, that several people get paid now for hacking doesn't change much. It's more about proper software engineering, some people call it "a matter of taste" and are born with it, but for other people it's a hard learning process. The opinion piece is also (probably) about non-kernel software. It is hard to tell because he gives no examples at all. It was not pursuasive to me. I've seen terrible code on every system from IBM mainframes to Mac. That is not news. john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: new 3dfx framebuffer driver released
From: Kesmarki Attila [EMAIL PROTECTED]
Date:Wed, 11 Oct 2000 02:02:24 +0200
A made my latest release as a patch for 2.4.0-test9. It can be
downloaded from http://www.medex.hu/~danthe/tdfx. I won't attach
it, because it's too long.
One bug spotted, in tdfxfb_probe():
+ info-bufbase_virt =
+ ioremap_nocache(info-bufbase_phys, info-bufbase_size);
+
+ if (!info-regbase_virt) {
+ printk("fb: Can't remap %s framebuffer.\n", name);
+ iounmap(info-regbase_virt);
+ goto err3;
+ }
Looks like a cutpaste error, you need to check info-bufbase_virt
against NULL, not info-regbase_virt ;-)
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: new 3dfx framebuffer driver released
Another bug, fb_info_tdfx uses "unsigned long" for the "iobase" member, which is correct, but much code casts this value to a "u32" before using it which will break such I/O port accesses on Alpha and Sparc64 and perhaps other 64-bit platforms. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
Hi'all,
Solved the problem with Winchip not booting. It turns out they do not like the
code generated by gcc (gcc version 2.95.2 19991024 (release)) when the
-march=i686 flag is set. Changing this flag to -march=i586 makes to box boot
like it should.
I do not have a working egcs 1.1.x or gcc 2.7.2x here, but I presume they DO
produce working code, if only because the earlier compilers lacked specific
support for pentium and above. It seems the arch/i386/Makefile is incorrect in
stating that these Winchips are in fact i686 compatible, or it might be that
gcc does bad things to these processors. Anyway, included is a small patch to
solve these problems with Winchips.
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ Hacker for Hire \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ Hacker: http://www.jargon.org/html/entry/hacker.html ]
*** linux/arch/i386/Makefile.orgWed Oct 11 02:22:26 2000
--- linux/arch/i386/MakefileWed Oct 11 02:22:41 2000
***
*** 70,84
endif
ifdef CONFIG_MWINCHIPC6
! CFLAGS += $(shell if $(CC) -march=i686 -S -o /dev/null -xc /dev/null /dev/null
21; then echo "-march=i686"; fi)
endif
ifdef CONFIG_MWINCHIP2
! CFLAGS += $(shell if $(CC) -march=i686 -S -o /dev/null -xc /dev/null /dev/null
21; then echo "-march=i686"; fi)
endif
ifdef CONFIG_MWINCHIP3D
! CFLAGS += $(shell if $(CC) -march=i686 -S -o /dev/null -xc /dev/null /dev/null
21; then echo "-march=i686"; fi)
endif
HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
--- 70,84
endif
ifdef CONFIG_MWINCHIPC6
! CFLAGS += $(shell if $(CC) -march=i586 -S -o /dev/null -xc /dev/null /dev/null
21; then echo "-march=i586"; fi)
endif
ifdef CONFIG_MWINCHIP2
! CFLAGS += $(shell if $(CC) -march=i586 -S -o /dev/null -xc /dev/null /dev/null
21; then echo "-march=i586"; fi)
endif
ifdef CONFIG_MWINCHIP3D
! CFLAGS += $(shell if $(CC) -march=i586 -S -o /dev/null -xc /dev/null /dev/null
21; then echo "-march=i586"; fi)
endif
HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
Re: [PATCH] drivers/usb/Config.in
James Simmons wrote: Not needed. This is a misunderstanding. Maybe that needs some work (in Help maybe), but not this patch. Yes please. It can be very misleading. Then if you select USB HID support, that builds the hid driver, which handles mice, keyboards, joysticks, gamepads, speaker buttons, any-old-kind-of buttons, toaster buttons, etc. I didn't realize USB had this level of functionality. OTOH, if you want just some basic USB mouse keyboard support, you don't have to use the hid driver, you can use the HIDBP (HID Boot Protocol) drivers instead. However, these drivers (hid and hidbp) are mutually exclusive and you shouldn't try to select both of them. Okay I see. James, Please let me know if the attached patch helps to clarify this any (or enough). I tried adding a line between HID and HIDBP support options, but that didn't work out, so it's not there. Thanks, ~Randy --- linux/Documentation/Configure.help.org Mon Oct 9 16:47:42 2000 +++ linux/Documentation/Configure.help Tue Oct 10 17:22:12 2000 @@ -9982,12 +9982,13 @@ The module will be called usb-ohci.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. -USB Human Interface Device (HID) support +USB Human Interface Device (full HID) support CONFIG_USB_HID - Say Y here if you want to connect keyboards, mice, joysticks, - graphic tablets, or any other HID based devices to your - computer via USB. More information is available: - Documentation/usb/input.txt. + Say Y here if you want full HID support to connect keyboards, + mice, joysticks, graphic tablets, or any other HID based devices + to your computer via USB. You can't use this driver and the + HIDBP (Boot Protocol) keyboard and mouse drivers at the same time. + More information is available: Documentation/usb/input.txt. If unsure, say Y. @@ -9996,11 +9997,11 @@ The module will be called hid.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. -USB HIDBP Keyboard support +USB HIDBP Keyboard (basic) support CONFIG_USB_KBD Say Y here if you don't want to use the generic HID driver for your USB keyboard and prefer to use the keyboard in its limited Boot - Protocol mode. This driver is much smaller than the HID one. + Protocol mode instead. This driver is much smaller than the HID one. This code is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). @@ -10009,11 +10010,11 @@ If unsure, say N. -USB HIDBP Mouse support +USB HIDBP Mouse (basic) support CONFIG_USB_MOUSE Say Y here if you don't want to use the generic HID driver for your USB mouse and prefer to use the mouse in its limited Boot Protocol - mode. This driver is much smaller than the HID one. + mode instead. This driver is much smaller than the HID one. This code is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). --- linux/drivers/usb/Config.in.org Mon Sep 18 15:23:30 2000 +++ linux/drivers/usb/Config.in Tue Oct 10 17:41:44 2000 @@ -79,10 +79,10 @@ if [ "$CONFIG_INPUT" = "n" ]; then comment ' Input core support is needed for USB HID' else - dep_tristate ' USB Human Interface Device (HID) support' CONFIG_USB_HID $CONFIG_USB $CONFIG_INPUT + dep_tristate ' USB Human Interface Device (full HID) support' CONFIG_USB_HID +$CONFIG_USB $CONFIG_INPUT if [ "$CONFIG_USB_HID" != "y" ]; then - dep_tristate ' USB HIDBP Keyboard support' CONFIG_USB_KBD $CONFIG_USB $CONFIG_INPUT - dep_tristate ' USB HIDBP Mouse support' CONFIG_USB_MOUSE $CONFIG_USB $CONFIG_INPUT + dep_tristate ' USB HIDBP Keyboard (basic) support' CONFIG_USB_KBD +$CONFIG_USB $CONFIG_INPUT + dep_tristate ' USB HIDBP Mouse (basic) support' CONFIG_USB_MOUSE +$CONFIG_USB $CONFIG_INPUT fi dep_tristate ' Wacom Intuos/Graphire tablet support' CONFIG_USB_WACOM $CONFIG_USB $CONFIG_INPUT fi
Re: Linux 2.2.18pre15
On Mon, 02 Oct 2000, Alan Cox wrote: 2.2.18pre11 o Fix dead/clashing define for NFS(Trond Myklebust) 2.2.18pre9 o NFSv3 support and NFS updates (Trond Myklebust and co) 2.2.18pre15's NFS support looks strange to me. My menuconfig screen looks like this: x x * NFS filesystem support x x * NFS server support x x [ ]Emulate SUN NFS server x x [*]NFS Version 3 While 2.2.17 + Trond's + Dave's NFSv3 patches looks like this: x x * NFS filesystem support x x [*]NFS Version 3 filesystem support x x * NFS server support x x [*]NFS Version 3 server support (EXPERIMENTAL) It looks as if the NFS v3 Server patches did not make it, but they make up the part that is actually interesting for interoperability, with e. g. Solaris. Frankly, I don't personally care for Linux NFS v3 client support, the server patches are the interesting part. They get Linux rid of the long-awaited SysV-NFS-client incompatibilities. Did you merge Dave Higgens' NFS v3 Server patches completely? Did you reject parts of the patches? -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
CVS for kernel
What is the current state of the vger CVS tree? LKML FAQ points to ftp://vger.kernel.org/pub/linux/README.CVS which either gets connection refused or no route to host. The mirror at samba.org is too slow, to the extent that even doing a sync at 6AM local time gives up part way through. Trying to connect to a CVS pserver at vger.kernel.org gets connection refused. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Segfaults using xawtv
On Tue, 10 Oct 2000 12:07:15 -0300, John Coppens blurted forth: Hi... I _hate_ to do this, but I couldn't find (except for a reference to "others who have segfaults using glibc") no reference to this problem. Insmod of i2c, videodev and bttv succeed without problems or any message in /var/log/debug, messages or syslog. Also, though I'm surely no expert, I tested a bit with gdb such, and suspect there may be a problem that's not directly xawtv/bttv related. Any suggestions? [snip] You may want to, if you have Gnome installed, try out an app called Zapping. I had some weird problems with newer version of xawtv too (my bad for not testing it further and sending bug reports to the xawtv author(s), i've been pretty busy and i needed a quick fix at the time, i'll get off my ass and do something about this soon i hope) but zapping works really well and does a better job of syncing frames in a larger window, it's at http://zapping.sourceforge.net (this is also a good idea so u can see if it's xawtv that has problems, or if the problem is kernel-level) -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: __bad_udelay in 2.2.18pre15
Marcelo Tosatti [EMAIL PROTECTED] said: 2.2.18pre15 defines udelay as (in file include/asm-i386/delay.h) : ... extern void __bad_udelay(void); ... #define udelay(n) (__builtin_constant_p(n) ? \ ((n) 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ __udelay(n)) ... It seems __bad_udelay is not defined anywhere in the kernel source. That is precisely the idea: Flag the places where udelay() is called with a large constant value. Just won't find out uses with large _variable_ arguments, but it is a start. Netted one in PCMCIA-CS... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
