New directions for kernel development

Hi all, Recently, I've been thinking a lot about where Linux development should head now that 2.4 is out. Specifically, I've been thinking about how we ought to make some cultural changes as well as technical changes. Now I'm not *entirely* sure what directions we should head in as we m

Re: w9966cf v4l driver homepage

On Sunday 01 April 2001 02:16, Jakob Kemi wrote: > The w9966cf webcam v4l driver now has a homepage: > http://hem.fyristorg.com/mogul/w9966.html > Hi Jakob, i've looked at your sources and i wonder why you use "return _RGB_ or _YUV_ data in read() mode" better find use VIDIOCSPICT to

Re: New directions for kernel development

Heh.. Not even 5 minutes into the smegging day, and it's already started. ;) BL. -- Brad Littlejohn | Email:[EMAIL PROTECTED] Unix Systems Administrator, | [EMAIL PROTE

Re: New directions for kernel development

On Sunday 01 April 2001 10:24, A Guy Called Tyketto wrote: > Heh.. > > Not even 5 minutes into the smegging day, and it's already started. > ;) > > BL. 5 mins? In germany ppl fool me since 10 hours :) ;) Bye Bye Niko --

Re: [lkml]Re: Matrox G400 Dualhead

On Sat, Mar 31, 2001 at 05:46:38PM +, J Brook wrote: > > I have a similar problem with my G450, booting into the framebuffer, > > then loading xdm and working in X, and then switching back to the > > console. I may have another detail to add in that when I switch back > > to the console from

Re: Serial port latency

Pavel Machek wrote: > > > > > > > I've seen similar bugs. If you hook something on schedule_tq and > > forget > > > to set current->need_resched, this is exactly what you get. > > > > > I'm running with a patch that printk's if cpu_idle() is called while a > > softirq is pending. > > If I access

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

In article you write: >With ioctl, I can easily match a response of any kind to a request. I can >even return an English text message if I want to be friendly. But ioctl requires allocation of numbers. Ugly and hard to scale. Alex Viro's i

RE: New directions for kernel development

So according to the below, Linux development should be considered an environmental hazard? Maybe it is in the best interest of Planet Earth that we should provide some safe place, possibly some South Pacific island, where we could set up a quarrantine camp for hardcore linux developers. All of th

Re: New directions for kernel development

Linus Torvalds writes: Ho, hum. No, he didn't. It's April Wankers^WFools again. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linu

Re: Version 6.1.6 of the aic7xxx driver availalbe

"Justin T. Gibbs" wrote: > >"Justin T. Gibbs" wrote: > > > >> >I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scs > >i > >> >bus. > >> >I also upgraded to the "latest" aic7xxx driver but still the sam problems. > >> >A typical revery in my logs. > > This really looks like

Re: Asus CUV4X-D, 2.4.3 crashes at boot

From: "Allen Campbell" <[EMAIL PROTECTED]> > I've seen the exact same behavior with my CUV4X-D (2x1GHz) under > 2.4.2 (debian woody). In addition, the kernel would sometimes hang > around NMI watchdog enable. At least, I think it's trying to > `enable'. The hang would occur around 50% of boot

Re: New directions for kernel development

On Sun, Apr 01, 2001 at 12:05:32AM -0800, Linus Torvalds wrote: > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 > Hi all, This is why OpenPGP signatures must be used more often. PGP signature

Re: Asus CUV4X-D, 2.4.3 crashes at boot

On Sun, Apr 01, 2001 at 09:18:25PM +1200, Simon Garner wrote: > From: "Allen Campbell" <[EMAIL PROTECTED]> > > > I've seen the exact same behavior with my CUV4X-D (2x1GHz) under > > 2.4.2 (debian woody). In addition, the kernel would sometimes hang > > around NMI watchdog enable. At least, I th

Re: Asus CUV4X-D, 2.4.3 crashes at boot

From: "Mikael Pettersson" <[EMAIL PROTECTED]> > Boot with "nmi_watchdog=0" as a boot parameter. Does it work now? > > Some people have reported before here that the IO-APIC driven NMI > watchdog itself can cause boot-time hangs. > > /Mikael Thanks, but I do not have watchdog support compiled

Re: Asus CUV4X-D, 2.4.3 crashes at boot

Simon Garner wrote: >I've compiled kernel 2.4.3 on the following RH7 system, and I'm now getting >random crashes at boot, during IO-APIC initialisation. Random meaning that >sometimes it boots fine, other times it doesn't, and it hangs in different >places (but always around IO-APIC stuff). It al

unresolved symbol queue_task !

Hello sirs ; A part of my source is like this : static struct tq_struct Task = { /* Some inits */ }; queue_task(&Task,&tq_timer); With the line #include When ever I compile my source as a module ,insmod tells me "Unresolved symbole queue_task" .It seems that I have problem with _

Re: Asus CUV4X-D, 2.4.3 crashes at boot

On Sun, Apr 01, 2001 at 10:04:17PM +1200, Simon Garner wrote: > From: "Mikael Pettersson" <[EMAIL PROTECTED]> > > > Boot with "nmi_watchdog=0" as a boot parameter. Does it work now? > > > > Some people have reported before here that the IO-APIC driven NMI > > watchdog itself can cause boot-time

Bug in proc permition checks.

Somewhere between 2.2.16 and 2.4.1 a bug in vfs_permission() in the file "fs/namei.c" has been fixed. S_ISDIR(mode) was incorrect, S_ISDIR(inode->i_mode) is correct. The same piece of code exist in the proc filesystem, here the bug has not been fixed. I wonder why does the function exist in the

kernel crash

This is a general plea for help .. We were told Linux was the most stable OS for embedded work so we put it to use in running our ARM based pacemaker. It did well on the preliminary tests using simulated output we managed 3 weeks with no problems and almost perfect rhythm generation. On the four

Re: TCP Vegas implementation for Linux

Our (VA's) kernel includes a Vegas patch: ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2 -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the

Re: New directions for kernel development

On Sun, Apr 01, 2001 at 01:22:48AM -0800, Richard Gooch wrote: > Linus Torvalds writes: > > Ho, hum. No, he didn't. It's April Wankers^WFools again. we aussies are supposed to have a good sense of humour :P j. -- "Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson - To unsu

Re: TCP Vegas implementation for Linux

On Sun, 1 Apr 2001, Chip Salzenberg wrote: > Our (VA's) kernel includes a Vegas patch: >ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2 tcp vegas performs very badly for me on asymmetric links (e.g. adsl), about 50% performance loss vs non-vegas. -Dan - To unsubscribe from th

Re: TCP Vegas implementation for Linux

Chip Salzenberg writes: > Our (VA's) kernel includes a Vegas patch: > >ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2 Slight typo in the URL, it's: ftp://ftp.valinux.com/pub/people/chip/kernel/linux-vegas-v2-patch-2.2 Later, David S. Miller [EMAIL PROTECTED] - To unsubs

Promise 20267 "working" but no UDMA

Anybody manage to get UDMA 66/100 working with an on-board Promise 20267 chip? Hardware: Tyan Tiger LE (with ServerWorks OSB4 _and_ Promise 20267 on-board) Kernel: 2.4.3 with ide.2.4.3-p8.all.03242001.patch by Andre Hedrick (or stock 2.4.3 with more or less same results) FastTrack config: only

Re: Minor 2.4.3 Adaptec Driver Problems

> Umm. This isn't an aic7xxx driver problem at all. The SCSI layer > determines the order of bus attachment *amongst* the various > SCSI HBA (or SCSI HBA like) drivers in the system. In this case, > it has decided to probe your IDE devices as SCSI devices first. > Why it does this I don't reall

Re: TCP Vegas implementation for Linux

Dan Hollis writes: > tcp vegas performs very badly for me on asymmetric links (e.g. adsl), > about 50% performance loss vs non-vegas. This among other reasons is why I ripped out vegas from the kernel a couple years ago. I'm actually disappointed vendors have added this patch because it is st

Re: Minor 2.4.3 Adaptec Driver Problems

On Sun, Apr 01, 2001 at 01:09:30PM -0700, Earle Nietzel wrote: > > Umm. This isn't an aic7xxx driver problem at all. The SCSI layer > > determines the order of bus attachment *amongst* the various > > SCSI HBA (or SCSI HBA like) drivers in the system. In this case, > > it has decided to probe y

Re: Asus CUV4X-D, 2.4.3 crashes at boot

On Sun, 1 Apr 2001 12:09:18 +0200, David Weinehall <[EMAIL PROTECTED]> wrote: >On Sun, Apr 01, 2001 at 10:04:17PM +1200, Simon Garner wrote: >> Thanks, but I do not have watchdog support compiled into the kernel. > >Doesn't matter. The NMI-watchdog tries to detect SMP-lockups, and is >always pres

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

On Sun, 01 Apr 2001 01:01:59 -0800, [EMAIL PROTECTED] (Chip Salzenberg) wrote: >In article you write: >Why not have a kernel thread and use standard RPC techniques like >sockets? Then you'd not have to invent anything unimportant like >Yet An

Re: epic100 aka smc etherpower II

Daniel Nofftz <[EMAIL PROTECTED]> écrit : [...] > i can`t get my smc etherpower ii working with the 2.4.3 kernel. > now i have downgraded to 2.4.2 and it works again ... > does anyone have a suggestion, what the problem is ? [...] > Mar 31 19:23:29 hyperion kernel: eth0: Setting half-duplex based

2.4.3 SMP aic7895 oops on boot

Hi: I just tried upgrading to the 2.4.3 kernel [ currently running 2.2.18/Debian/woody ] and I got [or rather I should say get - it happens every time] a kernel panic on boot, just after the lines: [ Apologies if two message like this turn up - I sent the last one some time ago, and it hasn't

Re: Original destination of transparent proxied connections?

In message <[EMAIL PROTECTED]> you write: [ cut 50 lines ] > If I were to perhaps send linuxdoc.org a check or > something, might a day come to pass when learning to > do seemingly obvious things under linux does NOT > require fairly good forensic investigation skills? I > ask merely for inform

Re: PCMCIA problems on IBM ThinkPad 600X

There are problems with some PCMCIA drivers included in the kernel. For example, support for cardbus 3com cards was moved to 3c59x.o driver. It works (on 600X at least) only of you compile it in. It will not work as a module. I think a much better solution right now is to use drivers from pcm

sysctl

Hi, I am working on rebuilding a modified kernel. This is for version 2.2.18 and on Slackware distro. I have been looking for the command "sysctl" in my */sbin directories and I can't seem to find it. Is this something that is an independent program that is compiled during the kernel build? I d

aic7xxx 6.1.8 for 2.2.19

Was getting ready to compile 2.2.19 this AM and went to Justin's site to grab the latest aic7xxx driver. Unfortunately, he doesn't have a patch for 2.2.19 and the 2.2.18 patch doesn't apply cleanly because the stock driver changed. It's a long story, but the short version is that the stock drive

VIA 82c686b and IOMega ATAPI ZIP 100 problem

I'm experiencing serious problems with Linux, VIA vt82c686b IDE interface (as included on VIA KT133 (latest revisions), KT133A and newer chipsets) and IOMega ATAPI ZIP 100 drive. Error description and system information are included below. That is a known problem with this chip. Something bad happ

Re: [lkml]Re: Matrox G400 Dualhead

>If I use X on an accelerated, normal Matrox screen, my monitor complains >on exit: > >fH 49.4 KHz, fV 39.8 Hz > >(and it doesn't sync at 40 Hz vertical refresh :-( ). > >This is _half_ of the normal 80 Hz. Using fbset -a "1600x1200-80" before >X, of after X, doesn't do anything. Does anybody kno

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

>No, it's the Trident Cyber9525 Sorry. I only have a early driver for trident 9750 and 9850. Their is a gropup working on trident framebuffers. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. Jam

Re: aic7xxx 6.1.8 for 2.2.19

At 10:54 AM 4/1/01, Mike Bennett wrote: >Was getting ready to compile 2.2.19 this AM and went to >Justin's site to grab the latest aic7xxx driver. > >Unfortunately, he doesn't have a patch for 2.2.19 and the >2.2.18 patch doesn't apply cleanly because the stock driver >changed. > >It's a long stor

Re: add-single-device won't work in 2.4.3

hi! problem resolved: the first scsi adaptor is scsi1 NOT scsi0 as in <=2.4.2. so i did add/remove devices from a non existend controller ... thanks for posting your /proc/scsi/scsi, i compared it with mine from 2.4.2 and voila! i hope this is a "wanted" behavior ... thanks for all your fast r

scsi bus numbering

For some reason, the order of initializing the scsi drivers changed between 2.4.2 and 2.4.3: If both, ncr53c8xx and aic7xxx drivers are included in the kernel, up to version 2.4.2, the adaptec driver always came first (so the first disk on an adaptec controller ended up as /dev/sda) while in 2.4.

Re: New directions for kernel development

Linus Torvalds wrote: It's definitely time for you to show up on Saturday Night Live! You are one funny guy. :-) Happy April Fools Day. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: New directions for kernel development

Linus Torvalds wrote: Uhm, yeah... I don't know who wrote this, but it came from Washington state and was written with MS Outlook... Something tells me that this April Fool's joke wasn't Linus'. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: RFC: configuring net interfaces

Jeff Garzik <[EMAIL PROTECTED]> writes: > I'm not suggesting you modify ethtool for your needs :) But ethtool > perfectly illustrates the technique of using a single socket ioctl > (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls > (ETHTOOL_xxx) to Linux networking drivers. I

Re: New directions for kernel development

On Sun, 1 Apr 2001, Linus Torvalds wrote: > Hi all, > > Recently, I've been thinking a lot about where Linux development should > head now that 2.4 is out. Specifically, I've been thinking about how we > ought to make some cultural changes as well as technical changes. Now I'm > not *enti

Re: tmpfs in 2.4.3 and AC

In linux-kernel, [EMAIL PROTECTED] wrote: : Hi, : : tmpfs (or shmfs or whatever name you like) is still different in official : series (2.4.3) and in ac series. Its a kick in the ass for multiboot, : as offcial 2.4.3 does not recognise 'tmpfs' in fstab: : : shmfs /dev/shmtmpfs ... :

unistd.h and 'extern's and 'syscall' "standard(?)"

I have a question. Some architectures have "system calls" implemented as library calls (calls that are "system calls" on ia32) For example, the expectation on 'arm', seems to be that sys_sync is in a library. On alpha, sys_open appears to be in a library. Is this correct? Is it

Re: scsi bus numbering

Peter Daum <[EMAIL PROTECTED]> wrote: > For some reason, the order of initializing the scsi drivers > changed between 2.4.2 and 2.4.3: If both, ncr53c8xx and aic7xxx > drivers are included in the kernel, up to version 2.4.2, the > adaptec driver always came first (so the first disk on an adaptec >

pthreads & fork & execve

Hi, I have question regarding use of pthreads, forks and execve's which appears to not work very well :-) First let me explain the reasoning though We have an app that launches a few other apps and keeps track of their status, resource consumption etc. If one of the apps crashes, it is restart

Re: Version 6.1.6 of the aic7xxx driver availalbe

>> >> >A typical revery in my logs. >> >> This really looks like you bus is not up to snuff. We timeout during >> a write to the drive. Although the chip has data to write, the target >> has stopped asking for data. This is a classic symptom of a lost signal >> transition on the bus. The old d

Re: PCMCIA problems on IBM ThinkPad 600X

On Sun, 1 Apr 2001, Constantine Gavrilov wrote: > There are problems with some PCMCIA drivers included in the kernel. For > example, support for cardbus 3com cards was moved to 3c59x.o driver. It > works (on 600X at least) only of you compile it in. It will not work as > a module. It works jus

Serial, 115Kbps, 2.2, 2.4

I am trying to find out if I am the only one who has pppd drop packets as bogus when the port is set at 115Kbps. I only get it at that speed. It causes stall outs etc. There may be a possibility this is machine specific, because if it is meant to forward the packet to the internal net and I

Re: New directions for kernel development

On Sun, 1 Apr 2001, David Riley wrote: > Linus Torvalds wrote: > > Uhm, yeah... I don't know who wrote this, but it came from Washington > state and was written with MS Outlook... Something tells me that this > April Fool's joke wasn't Linus'. :-) Yeah, the quality of these jokes has reall

bug database braindump from the kernel summit

Folks, since bug tracking is the next thing we are attacking here at BitMover, I have a great deal of interest in the bug tracking discussion which happened last night at the summit. We already have a prototyped bug tracking system which we are integrating into BitKeeper, but as usual, it isn't g

2.4.3, new AIC7XX fails to compile, old works.

the ../config*works gets a successful build (yet to test kernel). using the new AIC driver blows up w/ undefined reference. full config file incl. as an attachment. pgcc-2.95.2 /lib/libc-2.1.3.so 1097 : dizzy : linux # diff .config ../config-2.4.3-works 228,230c228,231 < CONFIG_SCSI_AIC7XXX=y

Re: New directions for kernel development

Chris Meadors wrote: > On Sun, 1 Apr 2001, David Riley wrote: > >> Linus Torvalds wrote: >> >> Uhm, yeah... I don't know who wrote this, but it came from Washington >> state and was written with MS Outlook... Something tells me that this >> April Fool's joke wasn't Linus'. :-) > > > Yeah

Re: PCMCIA problems on IBM ThinkPad 600X

Jeff Garzik wrote: > On Sun, 1 Apr 2001, Constantine Gavrilov wrote: > >> There are problems with some PCMCIA drivers included in the kernel. For >> example, support for cardbus 3com cards was moved to 3c59x.o driver. It >> works (on 600X at least) only of you compile it in. It will not work a

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentatio

[EMAIL PROTECTED] (Chip Salzenberg) wrote on 01.04.01 in : > Why not have a kernel thread and use standard RPC techniques like > sockets? Then you'd not have to invent anything unimportant like > Yet Another IPC Technique. You can, of course, transfer the exact same R

Re: New directions for kernel development

[EMAIL PROTECTED] (john slee) wrote on 01.04.01 in <[EMAIL PROTECTED]>: > On Sun, Apr 01, 2001 at 01:22:48AM -0800, Richard Gooch wrote: > > Linus Torvalds writes: > > > > Ho, hum. No, he didn't. It's April Wankers^WFools again. > > we aussies are supposed to have a good sense of humour :P Yea

Re: unistd.h and 'extern's and 'syscall' "standard(?)"

LA Walsh <[EMAIL PROTECTED]> writes: |> I have a question. Some architectures have "system calls" |> implemented as library calls (calls that are "system calls" on ia32) |> For example, the expectation on 'arm', seems to be that sys_sync |> is in a library. On alpha, sys_open appears to

PROBLEM:Bug when installing NVidia Driver Module

[1.] Bug when installing NVidia Driver Module on "athlon" architecture [2.] the following error comes up when i attempt to install NVdriver module from NVidia. I build the Nvidia driver from the NVIDIA_kernel-0.9-769.tar.gz found at www.nvidia.com command insmod /lib/modules/2.4.3/video/NVDriver

Re: New directions for kernel development

> > Uhm, yeah... I don't know who wrote this, but it came from Washington > > state and was written with MS Outlook... Something tells me that this > > April Fool's joke wasn't Linus'. :-) > > Yeah, the quality of these jokes has really gone down hill. Last year we > had forged headers and co

Re: bug database braindump from the kernel summit

> There was a lot of discussion about possible tools > that would dig out the /proc/pci info I think the tools should not dig too much information out of the system. I remember some Microsoft (win98 beta?) bugtracking software that insisted on sending a several hundert kB long compressed blob wit

Temporary disk space leak

[root@Jay Giu]# du -c /home [...] 320120 /home 320120 total [root@Jay Giu]# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda8 253823 65909174807 27% / /dev/sda7 2158320750672 1296240 37% /usr /dev/sda5 2193082

Re: bug database braindump from the kernel summit

> Problem details > Bug report quality > There was lots of discussion on this. The main agreement was that we > wanted the bug reporting system to dig out as much info as possible > and prefill that. There was a lot of discussion about possible tools > that would dig

Re: Temporary disk space leak

On Sat, 31 Mar 2001, Giuliano Pochini wrote: > > [root@Jay Giu]# du -c /home > [...] > 320120/home > 320120total > [root@Jay Giu]# df > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/sda8 253823 65909174807 27% / > /dev/sda7

Re: scsi bus numbering

On Sun, 1 Apr 2001, Douglas Gilbert wrote: [...] > > scsihosts < > > As a boot time option try: > scsihosts=aic7xxx:ncr53c8xxx > or if you are using lilo, in /etc/lilo.conf add: > append="scsihosts=aic7xxx:ncr53c8xxx" that does indeed change the bus numbering. Unfortun

Re: how mmap() works?

On Thu, Mar 29, 2001 at 02:14:51PM -0800, Jerry Hong wrote: > Hi, > mmap() creates a mmaped memory associated with a > physical file. If a process updates the mmaped memory, > Linux will updates the file "automatically". If this > is the case, why do we need msync()? For the same reason you mi

Re: bug database braindump from the kernel summit

On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote: > I'm really sick of being buried in useless information. The signal > gets lost in the noise. It is easy to discard automatically generated > bug reports, and way too annoying to wade through the crud. > > When network connection

Re: bug database braindump from the kernel summit

Manfred Spraul writes: > [Larry McVoy] >> There was a lot of discussion about possible tools >> that would dig out the /proc/pci info > > I think the tools should not dig too much information out of the system. > I remember some Microsoft (win98 beta?) bugtracking software that > insisted on send

Re: how mmap() works?

> Without syncing, Linux writes whenever it thinks it's appropriate, e.g. > when pages have to be freed (I think also when the bdflush writes back > data, i.e. every 30 seconds by default). what about mmap() on non-filesystem files (/dev/mem, /proc/bus/pci...) ? - To unsubscribe from this list:

Re: New directions for kernel development

On Sun, Apr 01, 2001 at 03:05:47PM -0500, Adam wrote: > BZZT, wrong. Headers were forged intentionally to show pine since it is > what Linus uses. > > I had a joke for this year as well, but I didn't hear back from Linus if > that's cool with him to send it to LKML (I suppose I should have asked

Re: unistd.h and 'extern's and 'syscall' "standard(?)"

Andreas Schwab wrote: > Don't use kernel headers in user programs. Just use syscall(3). > > Andreas. --- I'm on a SuSE71 system and have all the manpages installed: law> man syscall No manual entry for syscall The problem is not so much for user programs as library writers that

Re: unistd.h and 'extern's and 'syscall' "standard(?)"

>of action to take. Seeing as you work for suse, would you know >where this 'syscall(3)' interface should be documented? Is it >supposed to be present in all distro's? It's documented in the glibc manual. Yes, it should be present in all glibc based distributions. p. - To unsubscribe fro

Re: bug database braindump from the kernel summit

Gregory Maxwell writes: > On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote: >> I'm really sick of being buried in useless information. The signal >> gets lost in the noise. It is easy to discard automatically generated >> bug reports, and way too annoying to wade through the crud

Re: Matrox G400 Dualhead

I solved the problem with dualhead!!! Second head from 2.4.3 is /dev/fb2 rather than /dev/fb1. Just had to look to the messages. About matroxfb + X11 what I have seen is that if you use the same resolution with the same number of colors as in X11 ,most of the times it will work(except if I am in t

Re: bug database braindump from the kernel summit

On Sun, 1 Apr 2001, Manfred Spraul wrote: > > There was a lot of discussion about possible tools > > that would dig out the /proc/pci info > > I think the tools should not dig too much information out of the system. > I remember some Microsoft (win98 beta?) bugtracking software that > insisted on

Re: problem in drivers/block/Config.in (PATCH)

On Sat, Mar 31, 2001 at 04:00:27PM +0200, Pozsar Balazs wrote: > On Fri, Mar 30, 2001 at 10:17:08PM +0200, Herbert Rosmanith wrote: > In fact, if we want to get what is said in the comment, we should write: > > if [ "$CONFIG_PARPORT" = "m" -a "$CONFIG_PARIDE_PARPORT" = "y" ] ; then >define_b

Re: [PATCH for 2.5] preemptible kernel

On Sat, 31 Mar 2001, george anzinger wrote: > I think this should be: > if (p->has_cpu || p->state & TASK_PREEMPTED)) { > to catch tasks that were preempted with other states. But the other states are all part of the state change that happens at a non-preemtive schedule() point, a

Re: bug database braindump from the kernel summit

On Sun, 1 Apr 2001, Albert D. Cahalan wrote: > Manfred Spraul writes: > > [Larry McVoy] > > >> There was a lot of discussion about possible tools > >> that would dig out the /proc/pci info > > I think the tools should not dig too much information out of the system. > > I remember some Microsoft

Re: [PATCH for 2.5] preemptible kernel

On Sat, 31 Mar 2001, Rusty Russell wrote: > > if (p->state == TASK_RUNNING || > > (p->state == (TASK_RUNNING|TASK_PREEMPTED))) { > > p->flags |= PF_SYNCING; > > Setting a running task's flags brings races, AFAICT, and checking > p->state

Re: bug database braindump from the kernel summit

On Sun, 1 Apr 2001, Larry McVoy wrote: when generating the auto bug reports make sure that the system tells the user exactly what data is being sent. sending a large chunk of unknown data off the machine is a big concern to many people. David Lang - To unsubscribe from this list: send the lin

Re: bug database braindump from the kernel summit

oops, I was going to quote a section from Larry's mail then decided not to and forgot to delete the header. David Lang On Sun, 1 Apr 2001, David Lang wrote: > Date: Sun, 1 Apr 2001 14:16:57 -0700 (PDT) > From: David Lang <[EMAIL PROTECTED]> > To: Larry McVoy <[EMAIL PROTECTED]> > Cc: [EMAIL PRO

Re: scsi bus numbering

Peter Daum wrote: > > On Sun, 1 Apr 2001, Douglas Gilbert wrote: > > [...] > > > > scsihosts < > > > > As a boot time option try: > > scsihosts=aic7xxx:ncr53c8xxx > > or if you are using lilo, in /etc/lilo.conf add: > > append="scsihosts=aic7xxx:ncr53c8xxx" > > that d

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

James Simmons wrote: > >No, it's the Trident Cyber9525 > > Sorry. I only have a early driver for trident 9750 and 9850. Their is a > gropup working on trident framebuffers. Is it possible that "jump scroll" would provide more performance benefit than an accelerated driver anyway? Seeing as you

Re: Recent problems with APM and XFree86-4.0.1

Jamie Lokier wrote: > > > On that theme of power management with X problems, I have been having > > > trouble with my laptop crashing when the lid is closed, instead of > > > suspending as it used to. The laptop is a Toshiba Satellite 4070CDT. > > > > Can you please try adding > > Option "N

EXT2-fs error on 2.4.2 & 2.4.3

Hello I'm using 2.4.2 and 2.4.3, sometimes after cron jobs like slocate process or checking md5sum on my file system(heavy load disk), i gets errors from the kernel: EXT2-fs error (device sd(8,3)): ext2_free_blocks: bit already cleared for block 80275 EXT2-fs error (device sd(8,3)): ext2_free_bl

Re: bug database braindump from the kernel summit

From: "Jeff Garzik" <[EMAIL PROTECTED]> > > /proc/pci data alone with every bug report is usually invaluable. Even if the bug is a compile error? E.g. BUG REPORT (a real one, I didn't have the time yet to post a patch): kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected Descr

Re: RFC: configuring net interfaces

On 1 Apr 2001, Krzysztof Halasa wrote: > Jeff Garzik <[EMAIL PROTECTED]> writes: > > I'm not suggesting you modify ethtool for your needs :) But ethtool > > perfectly illustrates the technique of using a single socket ioctl > > (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls >

Re: bug database braindump from the kernel summit

At 10:54 AM 4/1/01 -0700, Larry McVoy wrote: > - one key observation: let bugs "expire" much like news expires. If > nobody has been whining enough that it gets into the high signal > bug db then it probably isn't real. We really want a way where no > activity means let it

Re: Recent problems with APM and XFree86-4.0.1

Jamie Lokier wrote: > > I've noticed other changes in suspend/resume. I'm running Gnome now, > and it insists on running xscreensaver whenever I close the lid. > Somehow it is noticing the APM event, because this is very consistent. > Does anyone know how to disable this? The setting "No screen

Re: unistd.h and 'extern's and 'syscall' "standard(?)"

And furthermore, it's been around in Unix and unix-like systems for a very long time. Sounds like the lack of man page is an oversight. Anybody want to write one ? Tim On Sun, Apr 01, 2001 at 09:38:24PM +0100, Philip Blundell wrote: > >of action to take. Seeing as you work for suse, would you k

Re: bug database braindump from the kernel summit

On Sun, 1 Apr 2001, Manfred Spraul wrote: > From: "Jeff Garzik" <[EMAIL PROTECTED]> > > > > /proc/pci data alone with every bug report is usually invaluable. > > Even if the bug is a compile error? In fact, yes. Having the tuple of: .config, /proc/pci, and compile error output, you can see addi

Re: bug database braindump from the kernel summit

if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old /proc/config flamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script. David Lang On Sun

Re: bug database braindump from the kernel summit

On Sun, 1 Apr 2001, David Lang wrote: > /proc/config may be bloat, but we do need a way for the kernel config to > be tied to the kernel image that is running, however it is made available. /sbin/installkernel copies stuff into /boot, appending a version number. One way might be to have this scri

Re: bug database braindump from the kernel summit

On Sun, 1 Apr 2001, David Lang wrote: > if we want to get the .config as part of the report then we need to make > it part of the kernel in some standard way (the old /proc/config flamewar) > it's difficult enough sometimes for the sysadmin of a box to know what > kernel is running on it, let alon

Re: bug database braindump from the kernel summit

Jeff, if the sysadmin had anything to do with setting up the box I would agree with you, but there are cases where one person will boot a machine and another will then need to find out what is going on. I have seen systems with multiple kernels available on boot get booted from the wrong kernel

Re: bug database braindump from the kernel summit

On Sun, 1 Apr 2001, Larry McVoy wrote: > Problem details > Bug report quality [...] > But the main thing was to extract all the info we could > automatically. One thing was the machine config (hardware and > at least kernel version). The other thing was extract any oops >

Re: bug database braindump from the kernel summit

could be, /sbin/installkernel doesn't exist on my systems David Lang On Sun, 1 Apr 2001, Jeff Garzik wrote: > Date: Sun, 1 Apr 2001 18:34:07 -0500 (CDT) > From: Jeff Garzik <[EMAIL PROTECTED]> > To: David Lang <[EMAIL PROTECTED]> > Cc: Manfred Spraul <[EMAIL PROTECTED]>, > Albert D. Cahala

Re: bug database braindump from the kernel summit

Jeff, my point was that not all systems will have this script. also it won't do you any good if the system you are compiling on is not the same system the kernel will be running on but we are starting the wrong discussion here :-) David Lang On Sun, 1 Apr 2001, Jeff Garzik wrote: > On Sun, 1 A

  1   2   >