Re: No sound (es1371) after test7
In article <[EMAIL PROTECTED]>, Jon Evans <[EMAIL PROTECTED]> wrote: >On Fri, Sep 22, 2000 at 09:14:23AM -0400, Kernel Related Emails wrote: > >> Well everythings working fine in test9-pre5 except for the fact that sound >> has stopped functioning on my es1371 card. I had no problems with it at >> all in test7 but since then it doesn't work. On boot it detects normally, >> pops and crackles for a second, and then just doesn't work. Any >> ideas? I'm getting no kernel messages or any output that would indicate >> the problem. > >Just as a data point, I have the same problem. /dev/dsp seems to block when opened. Ehh. One of the differences in the test9-pre kernels is a "trivial bugfix" that actually makes one of the "schedule_timeout()" calls in drivers/sound/ac97_codec.c actually _do_ something. Go into "drivers/sound/ac97_codec.c" to around line 570 or so, and comment out the line that says current->state = TASK_UNINTERRUPTIBLE; and see if that fixes the problem. Now, removing the above line will basically make the schdule_timeout() be a no-op, so on the face of it the code has always before been completely nonsensical. But maybe the nonsensical code works, and the logical code is broken. As far as I can tell, no other changes have happened in the sound drivers, which is why I'd ask people to do this apparently idiotic reversal of that single line.. 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: 2.4.0-test9-pre6 shmem problems revisited
I think there's problem in both the kernel and in X. Why? Work machine: * test9-pre2 w/ X 4.0d ... uptime 5 days nothing reporting shm errors like my other boxes. This machine gets hit pretty hard when I'm on it. Co-worker's machine: * 2.2.16 w/ X 4.0.1c ... getting reports of shm errors but no lockups. This guy tortures his machine. Home machine: * test7 w/ X 4.0.1c ... getting reports of shm errors but no lockups * test9-pre* w/ X 4.0.1c ... can't stay up for more than a couple hours before locking up. To do: * Try test 8 * Try X from about a week or two ago (or futher back if needed) Not very scientific I know. But so far the thing I see in common is that using kernels before test9-pre* with or without X 4.0.1c and your machine wont lock up in a relatively short period of time. use test9-pre* w/ X 4.0.1c and you're not gonna be up for more than a couple hours. i may be lumping all the test9-pre versions in here when I shouldnt be. Like someone stated earlier, I think this is like the truncate bug. Something has been changed that just brought this bug out to the front. Daniel Stone wrote: > > > d > > -- > Daniel Stone > Kernel Hacker (or at least has aspirations to be) > [EMAIL PROTECTED] > http://dustpuppy.ods.org > - > 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/ -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [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-pre6 shmem problems revisited
> On Sun, 24 Sep 2000, Daniel Stone wrote: > > The problem is most definitely NOT X as I experienced the exact same > > problems and reported it to l-k yesterday; and my box has no trace of X on > > it. gcc and grep take it down though. > > I have been running 2.4.0-test9-pre2 for some time now and have not experienc ed > any deadlock or shared memory problem, except for one instance. Byron - test9-pre2 was fine for me (bar that deadlock after 2 hours idle thing), it's test9-pre6 that seems to really badly blow goats. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - 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.0-test9-pre6 shmem problems revisited
On Sun, 24 Sep 2000, Daniel Stone wrote: > > Somehow i cant help but think this is somehow linked to an OOM problem > > that has yet to be fixed with the 2.4.0-testX series. It seems > > suspiciously like the kernel is killing init when X decides it would be > > peachy to gobble up all the ram. i dont know of any way to prove > > this though. > > The problem is most definitely NOT X as I experienced the exact same > problems and reported it to l-k yesterday; and my box has no trace of X on > it. gcc and grep take it down though. I have been running 2.4.0-test9-pre2 for some time now and have not experienced any deadlock or shared memory problem, except for one instance. Any time I do a 'hdparm -tT /dev/hda', it really screws up all the memory segments in the kernel. A subsequent 'df' or 'w' will print either garbage or 'no data in /etc/wtmp' file, etc. So it really looks like the cache is being messed with. I don't think it affects programs whose ram is already in userspace. This problem I've noticed has existed in 2.4.0-test7 and on through to test9-pre2. I do not know if pre6 has the same problem, but I suspect it does. I'm using hdparm 1.6, and at quick glance of the code, it does use shared memory to do its timing runs from the disk. This leads me to believe shm is very buggy, and perhaps Rik van Riel's latest patches have just brought the bug into the spotlight, analogous to how the test8 patches uncovered the truncate problem. Linus, I think you should hold off a little before removing Rik's VM patches from the kernel, and let the Linux community spend more time tracking down this problem. Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BTTV Driver under 2.2.18preX bug
Hello Mark! I wrote Alan about it a while ago, and I got no response.. Do you maybe have an idea who made this change in the code ? As far as I see, Alan is responsible for the video4linux thing, so maybe it's him. I'll re-write him soon if I'll get no response.. btw, a weird thing.. In wmtv it works great.. but kwintv & xawtv makes problems, and they're the more complicated programs, so It's a bug in the kernel.. Cya, Oren. On Sat, 23 Sep 2000, Mark Cooke wrote: > On Sun, 24 Sep 2000 [EMAIL PROTECTED] wrote: > > > Anybody else encountered a bug with the bttv driver under kernel > > 2.2.18preX (All the Pre-releases) ? > > Or the other thing- anybody got bttv driver to work under these kernels ? > > > > When I'm using this kernel with 2.2.17 bttv.o , it works great.. > > Hiya, > > Using xawtv 3.19 with 2.2.18pre9 doesn't appear to work correctly here > either. It was working fine with 2.2.17pre20. Haven't tried any > other of the 2.2.18pre series as I only just got finished with > repackaging my kernel rpm not to include usb/nfs patches. > > v4l-conf is reporting that the base address disagrees between v4l and > dga during xawtv startup. Not sure if this was the case with 2.2.17, > as I start xawtv from the gnome panel usually (no terminal > window). xawtv was certainly in overlay mode when I was running > 2.2.17pre20. > > WARNING: v4l and dga disagree about the framebuffer base > WARNING: Is v4l-conf installed correctly? ov_fbuf.base=0xe100, base=0xd800 > WARNING: overlay mode disabled > > I hadn't reported yet because I'm using the NVidia binary module > (0.95, recompiled against 2.2.18pre9 headers), and wanted to try to > isolate the problem specifically to some change in pre9, and not > something in the NVidia module for XFree 4.01 not liking something > else in pre9 (like the agp stuff). > > Trying various -nodga/-noxv/-novm flags to xawtv produces an > interesting array of hard locks and xawtv crashing. > > I'll try a 2.2.18pre9 with the 2.2.17 bttv.c/h tomorrow morning. > > Regards, > > Mark > > +-+ > Mark Cooke The views expressed above are mine and are not > Systems Programmer necessarily representative of university policy > University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ > +-+ > - 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/
Current CVS version of X does indeed break wrt SHM
(cc: to [EMAIL PROTECTED] and to [EMAIL PROTECTED] - this should be the last post to LKML for this subject) Known historical items: -All shm segments get used up in very fast order. -Everyone noticing it maintains it is 4.01c versioned -It happens on multiple versions of Linux kernels, 2.2 and 2.4 (no other OS in tests) New items: - I did a completely fresh checkout of X a few hours ago and built it modular, I now get the shm bug - I have -not- changed my kernel but I have changed kernel source. - X itself doesn't seem to be getting the SHM segments but child processes are and someone isn't detaching from them, particularly starting enlightenment causes a flurry of SHM allocations. The sequence of events by my running gdb on both X and enlightenment and trapping all shm calls is this: enlightenment creates and attaches to a segment X attaches they chit chat over the shared mem enlightenment detaches and destroys the segment X remains attached to the segment ...repeat until exit at exit of X, segments are detached by default (gdb) E Breakpoint 1, shmget (key=0, size=32768, shmflg=1023) E Breakpoint 4, shmat (shmid=567279622, shmaddr=0x0, shmflg=0) ipcs refcount=1 X Breakpoint 13, shmat (shmid=567279622, shmaddr=0x0, shmflg=0) ipcs refcount=2 X Breakpoint 15, shmctl (shmid=567279622, cmd=2, buf=0xb1fc) (buffer write/reads) E Breakpoint 2, shmdt (shmaddr=0x40014000) ipcs refcount=1 ipcs shmid marked destroyed X is still attached to this shmid, it will not do anything else on this shmid for the remainder of it's life. Interim conclusion: X is at fault. Linux kernel is fine. X simply doesn't detach any of these client requested segments. It -does- detach the segments it started itself. That being said, it is very possible that X (and other processes) depended on a default action. Recently SHM handling changed in the Linux Kernel which is still correct but may tickle processes that need to have code updated. I suspect X simply needs the shm handling tweaked. I've diffed the CVS code all the way back to April and there are no relevant SHM changes. Above we see that X does an shmctl() with IPC_STAT as the cmd, but never detaches from it. As we see below, X calls shmdt() the next time it gets a message from the client. In the current CVS code it never calls shmdt() Here's a paste of a working X compiled and installed on September 4th. E - Breakpoint 4, shmget (key=0, size=32768, shmflg=1023) 0x 698023942 david 777 32768 0 E - Breakpoint 1, shmat (shmid=698023942, shmaddr=0x0, shmflg=0) 0x 698023942 david 777 32768 1 X - Breakpoint 1, shmat (shmid=698023942, shmaddr=0x0, shmflg=0) 0x 698023942 david 777 32768 2 E - Breakpoint 2, shmdt (shmaddr=0x40014000) 0x 698023942 david 777 32768 1 Breakpoint 3, shmctl (shmid=698023942, cmd=0, buf=0x0) 0x 698023942 david 777 32768 1 dest E - Breakpoint 4, shmget (key=0, size=524288, shmflg=1023) E - Breakpoint 1, shmat (shmid=698056711, shmaddr=0x0, shmflg=0) 0x 698056711 david 777 5242881 X - Breakpoint 2, shmdt (shmaddr=0x40015000) (first segment removed) Here is what enlightenment is doing (invert the part sequence): (gdb) bt #0 shmat (shmid=698089478, shmaddr=0x0, shmflg=0) at ../sysdeps/unix/sysv/linux/shmat.c:39 #1 0x40091c77 in Imlib_render (id=0x81090f0, im=0x811d4a0, w=447, h=162) at rend.c:6468 #2 0x8078d0a in SetBackgroundTo (imd=0x81090f0, win=2097191, dsk=0x8114430, setbg=1 '\001') at desktops.c:912 [...] #2 0x4019396e in _XRead (dpy=0x8107e80, data=0xbfffc19c "\\\002\b\001q\030(J\001", size=32) at XlibInt.c:1032 #3 0x4019428b in _XReply (dpy=0x8107e80, rep=0xbfffc19c, extra=0, discard=1) at XlibInt.c:1667 #4 0x401900fe in XSync (dpy=0x8107e80, discard=0) at Sync.c:41 [more to come - dinner calls - please feel free to comment and provide information] -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
ip forwarding/tunneling for WIN PPTP broken in 2.2.18pre9?
Linux kernel, I had been using 2.2.14pre16 to forward Win PPTP from my winblows machine to our Corp Business network. I upgraded to 2.2.18pre9 and used make oldconfig using my .config file from my 2.2.14 directory. I can no longer log into our Corp network using my Linux system as ip-forwarder for my winblows machine using VPN. I rebooted 2.2.14 and things worked fine. Am I missing something? Is there anything special I need to do for 2.2.18? Any help would be greatly appreciated. Steve - 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: how interesting are data->bss patches?
On Sat, 23 Sep 2000 20:59:59 -0500 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote: >(A related question: __initdata *does* have to be initialized, right?) If __initdata is not initialized then it ends up in the global .bss. This would defeat the purpose of using __initdata. - 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/
how interesting are data->bss patches?
Not that any of us who don't do embedded projects ought to care very much, but I was curious. I grepped test9pre6 for globals initialized to 0 or NULL and came up with 2495 lines, first iteration. At 4-byte alignment this works out to something over 9k of .data that should be .bss (not that anyone compiles very much of this in at a time). A lot of recent Linus patches seem to have this conversion in them, so it seems someone *does* care about image size. (Presumably people running the kernel in-place from flash, right?) Would anyone be interested in patches to uninitialize these variables? I'd be willing to proofread my grep output. (A related question: __initdata *does* have to be initialized, right?) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with 2.4.0-test9-pre6 seems to be SHM
> safemode wrote: > > > Mark Hahn wrote: > > > >> this has nothing to do with the linux kernel. > >> X itself does not use shm for anything. apps may use > >> an X extension (XSHM) which uses shm segments to exchange > >> image data without copying through a socket, but that's > >> an extension, not inherent to X. > >> > >> > Ok, compiling using a cvs of X i got a couple hours ago, I'm just > >> > >> > wondering what the average segment number is for SHM on an X > >> session > >> > that has been up for a while i'll get back with any sort of > >> info > >> > on if the SHM problem has been solved with this latest CVS or if > >> it > >> > continues to look like a kernel SHM problem. So far though, > >> > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to > >> test9, > >> > which died in 2 hours upon booting ...and it didn't have the added > >> > >> > stress of compiling X. > >> > > >> > - > >> > > > > > > I think it has a lot to do with the kernel, and with X. Since i > > havn't upgraded anything but X (and thus the extensions) ... now it's > > obvious that X is at fault for providing us with a wonderful shared > > memory leak. But, the kernel too, has something to do with it since > > test9 seems to be fairly unstable with it, causing all sorts of weird > > happenings before totally freezing up like test8-vm3 does. This > > problems only manifests in VERY recent X cvs copies so most people > > will not see this problem. The problem i'm wondering about is if the > > Kernel is handling shared memory correctly or if this is entirely X's > > fault. > > > > Somehow i cant help but think this is somehow linked to an OOM problem > that has yet to be fixed with the 2.4.0-testX series. It seems > suspiciously like the kernel is killing init when X decides it would be > peachy to gobble up all the ram. i dont know of any way to prove > this though. The problem is most definitely NOT X as I experienced the exact same problems and reported it to l-k yesterday; and my box has no trace of X on it. gcc and grep take it down though. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - 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: (Fwd) CD-ROM (SCSI and IDE) not mounting disk
Another interesting thing that I just noticed, I can still play music CD's in either drive. On 23 Sep 2000, at 20:10 Glenn C. Hofmann wrote: > I will try to recompile some older kernels and see where it breaks, but here is the >output in the > logs when I try to mount the CD. I enabled debugging, as well. > > Found in debug logfile: > > Sep 23 19:58:05 hofmann1 kernel: VFS: Disk change detected on device ide1(22,64) > Sep 23 19:58:05 hofmann1 last message repeated 2 times > Sep 23 20:01:07 hofmann1 kernel: VFS: Disk change detected on device ide1(22,64) > Sep 23 20:01:07 hofmann1 last message repeated 2 times > > And in messages logfile: > > Sep 23 20:06:52 hofmann1 kernel: cdrom: entering cdrom_open > Sep 23 20:06:52 hofmann1 kernel: cdrom: entering open_for_data > Sep 23 20:06:52 hofmann1 kernel: cdrom: drive_status=2 > Sep 23 20:06:52 hofmann1 kernel: cdrom: the tray is open... > Sep 23 20:06:52 hofmann1 kernel: cdrom: trying to close the tray. > Sep 23 20:06:52 hofmann1 kernel: cdrom: bummer. the tray is still not closed. > Sep 23 20:06:52 hofmann1 kernel: cdrom: tray might not contain a medium. > Sep 23 20:06:52 hofmann1 kernel: cdrom: open failed. > Sep 23 20:06:52 hofmann1 kernel: cdrom: door unlocked. > Sep 23 20:06:52 hofmann1 kernel: cdrom: Use count for "/dev/hdd" now 0 > Sep 23 20:06:52 hofmann1 kernel: cdrom: entering cdrom_open > Sep 23 20:06:52 hofmann1 kernel: cdrom: entering cdrom_open > Sep 23 20:06:52 hofmann1 kernel: cdrom: entering open_for_data > Sep 23 20:06:52 hofmann1 kernel: cdrom: drive_status=2 > Sep 23 20:06:52 hofmann1 kernel: cdrom: the tray is open... > Sep 23 20:06:52 hofmann1 kernel: cdrom: trying to close the tray. > Sep 23 20:06:52 hofmann1 kernel: cdrom: bummer. the tray is still not closed. > Sep 23 20:06:52 hofmann1 kernel: cdrom: tray might not contain a medium. > Sep 23 20:06:52 hofmann1 kernel: cdrom: open failed. > Sep 23 20:06:52 hofmann1 kernel: cdrom: door unlocked. > Sep 23 20:06:52 hofmann1 kernel: cdrom: Use count for "/dev/hdd" now 0 > Sep 23 20:06:52 hofmann1 kernel: cdrom: entering cdrom_open > Sep 23 20:06:52 hofmann1 kernel: cdrom: entering open_for_data > Sep 23 20:06:52 hofmann1 kernel: cdrom: drive_status=2 > Sep 23 20:06:52 hofmann1 kernel: cdrom: the tray is open... > Sep 23 20:06:52 hofmann1 kernel: cdrom: trying to close the tray. > Sep 23 20:06:52 hofmann1 kernel: cdrom: bummer. the tray is still not closed. > Sep 23 20:06:52 hofmann1 kernel: cdrom: tray might not contain a medium. > Sep 23 20:06:52 hofmann1 kernel: cdrom: open failed. > Sep 23 20:06:52 hofmann1 kernel: cdrom: door unlocked. > Sep 23 20:06:52 hofmann1 kernel: cdrom: Use count for "/dev/hdd" now 0 > > > On 24 Sep 2000, at 2:43 Jens Axboe wrote: > > > On Sat, Sep 23 2000, Glenn C. Hofmann wrote: > > > As of the more recent kernels (2.4.0-test8,7,6 for sure) both my IDE and > > > SCSI CD-ROM drives will not mount a disk. They fail and tell me that > > > there is no disk in the drive. I booted into an old 2.0.36 kernel just > > > to make sure it wasn't a strange hardware failure and the CD mounted fine. > > > I have attached my .config and dmesg, which shows that the drives are > > > recognised. If there is any further information that I can give, I would > > > be happy to. Thanks in advance for any help. > > > > Could you try and isolate the kernel that breaks this? It sounds very > > odd that both your ATAPI and SCSI drive is affected. Also, could you > > try and mount a drive with debugging enabled in the uniform cd layer? > > > > echo "1" > /proc/sys/dev/cdrom/debug > > > > -- > > * Jens Axboe <[EMAIL PROTECTED]> > > * 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/ - 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/
reserve= specifies ..... iomem or ioport?
This may be obvious to a programmer, but...: ./Documentation/more kernel-parameters.txt : reserve=[KNL,BUGS] force the kernel to ignore some iomem area. http://cuip.uchicago.edu/doc/lilo-0.21/ : reserve=,,... reserves IO port regions. This can be used to prevent device drivers from auto-probing addresses where other devices are located, which get confused by the probing. 'man bootparam' : `reserve=...' This is used to protect I/O port regions from probes. The form of the command is: reserve=iobase,extent[,iobase,extent]... In some machines it may be necessary to prevent device drivers from checking for devices (auto-probing) in a specific region. This may be because of hardware that reacts badly to the probing, or hardware that would be mistakenly identified, or merely hardware you don't want the kernel to initialize. The reserve boot-time argument specifies an I/O port region that shouldn't be probed. A device driver will not probe a reserved region, unless another boot argument explicitly specifies that it do so. For example, the boot line reserve=0x300,32 blah=0x300 keeps all device drivers except the driver for `blah' from probing 0x300-0x31f. The more recent Linux documentation says iomem, while the majority of other documentation says io port. Given that /proc/ contains both, I'd like to see a clearification... Dag B - 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: (Fwd) CD-ROM (SCSI and IDE) not mounting disk
I will try to recompile some older kernels and see where it breaks, but here is the output in the logs when I try to mount the CD. I enabled debugging, as well. Found in debug logfile: Sep 23 19:58:05 hofmann1 kernel: VFS: Disk change detected on device ide1(22,64) Sep 23 19:58:05 hofmann1 last message repeated 2 times Sep 23 20:01:07 hofmann1 kernel: VFS: Disk change detected on device ide1(22,64) Sep 23 20:01:07 hofmann1 last message repeated 2 times And in messages logfile: Sep 23 20:06:52 hofmann1 kernel: cdrom: entering cdrom_open Sep 23 20:06:52 hofmann1 kernel: cdrom: entering open_for_data Sep 23 20:06:52 hofmann1 kernel: cdrom: drive_status=2 Sep 23 20:06:52 hofmann1 kernel: cdrom: the tray is open... Sep 23 20:06:52 hofmann1 kernel: cdrom: trying to close the tray. Sep 23 20:06:52 hofmann1 kernel: cdrom: bummer. the tray is still not closed. Sep 23 20:06:52 hofmann1 kernel: cdrom: tray might not contain a medium. Sep 23 20:06:52 hofmann1 kernel: cdrom: open failed. Sep 23 20:06:52 hofmann1 kernel: cdrom: door unlocked. Sep 23 20:06:52 hofmann1 kernel: cdrom: Use count for "/dev/hdd" now 0 Sep 23 20:06:52 hofmann1 kernel: cdrom: entering cdrom_open Sep 23 20:06:52 hofmann1 kernel: cdrom: entering cdrom_open Sep 23 20:06:52 hofmann1 kernel: cdrom: entering open_for_data Sep 23 20:06:52 hofmann1 kernel: cdrom: drive_status=2 Sep 23 20:06:52 hofmann1 kernel: cdrom: the tray is open... Sep 23 20:06:52 hofmann1 kernel: cdrom: trying to close the tray. Sep 23 20:06:52 hofmann1 kernel: cdrom: bummer. the tray is still not closed. Sep 23 20:06:52 hofmann1 kernel: cdrom: tray might not contain a medium. Sep 23 20:06:52 hofmann1 kernel: cdrom: open failed. Sep 23 20:06:52 hofmann1 kernel: cdrom: door unlocked. Sep 23 20:06:52 hofmann1 kernel: cdrom: Use count for "/dev/hdd" now 0 Sep 23 20:06:52 hofmann1 kernel: cdrom: entering cdrom_open Sep 23 20:06:52 hofmann1 kernel: cdrom: entering open_for_data Sep 23 20:06:52 hofmann1 kernel: cdrom: drive_status=2 Sep 23 20:06:52 hofmann1 kernel: cdrom: the tray is open... Sep 23 20:06:52 hofmann1 kernel: cdrom: trying to close the tray. Sep 23 20:06:52 hofmann1 kernel: cdrom: bummer. the tray is still not closed. Sep 23 20:06:52 hofmann1 kernel: cdrom: tray might not contain a medium. Sep 23 20:06:52 hofmann1 kernel: cdrom: open failed. Sep 23 20:06:52 hofmann1 kernel: cdrom: door unlocked. Sep 23 20:06:52 hofmann1 kernel: cdrom: Use count for "/dev/hdd" now 0 On 24 Sep 2000, at 2:43 Jens Axboe wrote: > On Sat, Sep 23 2000, Glenn C. Hofmann wrote: > > As of the more recent kernels (2.4.0-test8,7,6 for sure) both my IDE and > > SCSI CD-ROM drives will not mount a disk. They fail and tell me that > > there is no disk in the drive. I booted into an old 2.0.36 kernel just > > to make sure it wasn't a strange hardware failure and the CD mounted fine. > > I have attached my .config and dmesg, which shows that the drives are > > recognised. If there is any further information that I can give, I would > > be happy to. Thanks in advance for any help. > > Could you try and isolate the kernel that breaks this? It sounds very > odd that both your ATAPI and SCSI drive is affected. Also, could you > try and mount a drive with debugging enabled in the uniform cd layer? > > echo "1" > /proc/sys/dev/cdrom/debug > > -- > * Jens Axboe <[EMAIL PROTECTED]> > * 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: No sound (es1371) after test7
On Fri, Sep 22, 2000 at 09:14:23AM -0400, Kernel Related Emails wrote: > Well everythings working fine in test9-pre5 except for the fact that sound > has stopped functioning on my es1371 card. I had no problems with it at > all in test7 but since then it doesn't work. On boot it detects normally, > pops and crackles for a second, and then just doesn't work. Any > ideas? I'm getting no kernel messages or any output that would indicate > the problem. Just as a data point, I have the same problem. /dev/dsp seems to block when opened. kernel: es1371: version v0.26 time 21:39:34 Sep 21 2000 kernel: es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08 kernel: es1371: found es1371 rev 8 at io 0xc400 irq 19 kernel: es1371: features: joystick 0x0 kernel: ac97_codec: AC97 audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) Jon. -- Jon Evans / Red Internet Ltd. / +44 1869 337977 - 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: (Fwd) CD-ROM (SCSI and IDE) not mounting disk
On Sat, Sep 23 2000, Glenn C. Hofmann wrote: > As of the more recent kernels (2.4.0-test8,7,6 for sure) both my IDE and > SCSI CD-ROM drives will not mount a disk. They fail and tell me that > there is no disk in the drive. I booted into an old 2.0.36 kernel just > to make sure it wasn't a strange hardware failure and the CD mounted fine. > I have attached my .config and dmesg, which shows that the drives are > recognised. If there is any further information that I can give, I would > be happy to. Thanks in advance for any help. Could you try and isolate the kernel that breaks this? It sounds very odd that both your ATAPI and SCSI drive is affected. Also, could you try and mount a drive with debugging enabled in the uniform cd layer? echo "1" > /proc/sys/dev/cdrom/debug -- * Jens Axboe <[EMAIL PROTECTED]> * 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/
(Fwd) CD-ROM (SCSI and IDE) not mounting disk
Sorry, the files are attached this time... --- Forwarded message follows --- Date sent: Sun, 24 Sep 2000 00:35:57 + (GMT) From: "Glenn C. Hofmann" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date sent: Sat, 23 Sep 2000 19:40:19 -0500 Subject:CD-ROM (SCSI and IDE) not mounting disk Send reply to: [EMAIL PROTECTED] As of the more recent kernels (2.4.0-test8,7,6 for sure) both my IDE and SCSI CD-ROM drives will not mount a disk. They fail and tell me that there is no disk in the drive. I booted into an old 2.0.36 kernel just to make sure it wasn't a strange hardware failure and the CD mounted fine. I have attached my .config and dmesg, which shows that the drives are recognised. If there is any further information that I can give, I would be happy to. Thanks in advance for any help. Chris Hofmann --==-- "Our scientific power has outrun our spiritual power. We have guided missiles and misguided men - Martin Luther King, Jr --==-- - 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/ --- End of forwarded message --- Chris Hofmann --==-- "An open mind, in questions that are not ultimate, is useful. But an open mind about ultimate foundations either of Theoretical or Practical Reason is idiocy. If a manÆs mind is open on these things, let his mouth at least be shut. " --C. S. Lewis "The Abolition Of Man" --==-- Linux version 2.4.0-test9 (root@hofmann1) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #4 Sat Sep 23 14:27:57 CDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 05ef @ 0010 (usable) BIOS-e820: 8000 @ 05ff (ACPI data) BIOS-e820: 8000 @ 05ff8000 (ACPI NVS) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0002 @ fffe (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 24560 zone(0): 4096 pages. zone(1): 20464 pages. zone(2): 0 pages. mapped APIC to e000 (0119a000) Kernel command line: BOOT_IMAGE=test ro root=344 BOOT_FILE=/vm2.4b Initializing CPU#0 Detected 233.031 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 465.31 BogoMIPS Memory: 93632k/98240k available (1994k kernel code, 4220k reserved, 132k data, 228k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: L1 I Cache: 32K L1 D Cache: 32K (32 bytes/line) CPU: AMD-K6tm w/ multimedia extensions stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfdba1, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) GRE over IPv4 tunneling driver early initialization of device gre0 is deferred Linux IP multicast router 0.06 plus PIM-SM IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver early initialization of device sit0 is deferred NET4: Linux IPX 0.38 for NET4.0 IPX Portions Copyright (c) 1995 Caldera, Inc. Registered PPPoX v0.5 Registered PPPoE v0.5 ACPI: "AMIINT" found at 0x000f71d0 Starting kswapd v1.8 Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ... SMSC Super-IO detection, now testing Ports 2F0, 370 ... 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: possible IRQ conflict! 0x378: ECP port cfgA=0x14 cfgB=0x00 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,EPP,ECP] parport0: cpp_mux: aa55f00f52ad51(bf) parport0: cpp_daisy: aa5500ff87(b8) parport0: assign_addrs: aa5500ff87(b8) parport0: Printer, EPSON STYLUS COLOR II i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. piix4.o version 2.5.2 (2709) i2c-dev.o: Registered 'SMBus PIIX4 adapter at fcb0' as minor 0 i2c-core.o: adapter SMBus PIIX4 adapter at fcb0 registered as
CD-ROM (SCSI and IDE) not mounting disk
As of the more recent kernels (2.4.0-test8,7,6 for sure) both my IDE and SCSI CD-ROM drives will not mount a disk. They fail and tell me that there is no disk in the drive. I booted into an old 2.0.36 kernel just to make sure it wasn't a strange hardware failure and the CD mounted fine. I have attached my .config and dmesg, which shows that the drives are recognised. If there is any further information that I can give, I would be happy to. Thanks in advance for any help. Chris Hofmann --==-- "Our scientific power has outrun our spiritual power. We have guided missiles and misguided men - Martin Luther King, Jr --==-- - 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: Given an image, how can show its config?
Keith Owens <[EMAIL PROTECTED]> said: [...] > I worry about anything that increases the on disk size of bzImage, even > if the extra data does not get loaded into kernel memory. > > 629590 2.2.16/arch/i386/boot/bzImage > 786273 2.4.0-test8/arch/i386/boot/bzImage > > cat .config System.map | gzip | wc -c > 107591 > > That would take my 2.4.0 bzImage to 893864, it does not leave much room > out of a 1.4Mb floppy for LILO files. We could have multiple make > targets, with and without appended config/map but that just complicates > the build environment. Boot floppies shouldn't use "full" kernels with bells and whistles in any case. > This is all to protect those few poor 'administrators' who cannot keep > track of three separate files. We should not coddle such idiots, if > they cannot track 3 files they should not be configuring Linux. > Anybody who loses their config and System.map will learn from their > mistake and only do it once or they will never learn, in which case > they are better off running Windows. Very true. -- 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/
Re: FW: cdrecord and 'invalid field in parameter list' error
Joerg Schilling wrote: > > >From [EMAIL PROTECTED] Sun Sep 24 00:43:57 2000 > > >By the way, I looked like my message sent from a different host went through > >to this address. Can you please check and see if your admin has a > >blacklist/ip restriction against 208.18.12.x or 208.18.13.x? At one point, > >another site had a similar problem and it was because for some reason they > >had blocked a whole bunch of 208.8.x addresses, possibly due to previous > >ownership of those address and spam/etc. > > >-- Nathan > > >-Original Message- > >From: Jens Axboe [mailto:[EMAIL PROTECTED]] > >Sent: Saturday, September 23, 2000 5:33 PM > >To: Nathan Neulinger > >Cc: [EMAIL PROTECTED] > >Subject: Re: cdrecord and 'invalid field in parameter list' error > > >On Sat, Sep 23 2000, Nathan Neulinger wrote: > >> CDB: 55 10 00 00 00 00 00 00 3C 00 > >> status: 0x2 (CHECK CONDITION) > >> Sense Bytes: 70 00 05 00 00 00 00 12 00 00 00 00 26 00 00 8B > >> Sense Key: 0x5 Illegal Request, Segment 0 > >> Sense Code: 0x26 Qual 0x00 (invalid field in parameter list) Fru 0x0 > >> Sense flags: Blk 0 (not valid) error refers to data part, bit ptr 3 > >> (valid) field ptr 0 > >> cmd finished after 0.006s timeout 40s > >> cdrecord: Warning: using default CD write parameter data. > >> Mode Select Data 00 11 00 00 05 32 01 E4 08 00 00 00 20 00 00 00 00 20 > >> 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > >This isn't a kernel bug, rather cdrecord doing something it shouldn't. > >Judging by the above sense and mode select data, cdrecord has set > >the fixed packet bit with a write type of trace-at-once and this > >isn't valid. So that's probably why the drive is complaining. > > This is a bug in the firmware. > > It seems that the drive does not follow SCSI standard rules that request > every mode data retrived by the drive should be accepted by the drive > with mode select. > > Cdrecord is only making small modifications to mode page 5. If the drive > send invalid data, it will get invali data in return. Ok. So, what do you suggest as a workaround? I know I have sucessfully written CD's with this drive on linux, so something has changed either in the kernel or in cdrecord that is suddenly causing things to fail. Additionally, why is the drive listed as supported on your cdrecord page down at the bottom then (in the section on drives that have been donated to you) or are you trying to say that it is a problem with the firmware on this specific piece of hardware? > > Jörg > > EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin >[EMAIL PROTECTED] (uni) If you don't have iso-8859-1 >[EMAIL PROTECTED] (work) chars I am J"org Schilling > URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 CIS - Systems ProgrammingFax: (573) 341-4216 - 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 compiled with frame pointer
On Sat, 23 Sep 2000 15:02:26 +0530 (IST), Sushil <[EMAIL PROTECTED]> wrote: >While writing kernel code what is the correct way to find out if the >kernel is being compiled with frame pointer? Sad to say, you cannot. This is an extract from the kdb patch http://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.4-2.4.0-test9-pre6.gz * An activation record runs from the return address for a function * through to the return address for the next function or sp, whichever * comes first. For each activation record we extract :- * * startAddress of the activation record. * end Address of the last byte+1 in the activation record. * ret Return address to caller. * oldfpFrame pointer to previous frame, 0 if this function was *not compiled with frame pointers. * fp Frame pointer for the current frame, 0 if this function *was not compiled with frame pointers or fp has not been *set yet. * arg0 Address of the first argument (in the previous activation *record). * locals Bytes allocated to locals and automatics. * regs Bytes allocated to saved registers. * args Bytes allocated to arguments (in the previous activation *record). * setupBytes allocated to setup data on stack (return address, * frame pointer). * * Although the kernel might be compiled with frame pointers, we still * have to assume the worst and validate the frame. Some calls from * asm code to C code might not use frame pointers. Third party binary * only modules might be compiled without frame pointers, even when the * rest of the kernel has frame pointers. Some routines are always * compiled with frame pointers, even if the overall kernel is not. A * routine compiled with frame pointers can be called from a routine * without frame pointers, the previous "frame pointer" is saved on * stack but it contains garbage. * * We check the object code to see if it saved a frame pointer and we * validate that pointer. Basically frame pointers are hints. >Is the following code correct? > >#ifdef CONFIG_FRAME_POINTER > code assuming frame pointer >#else > code assuming no frame pointer Not really, see above. You code might be compiled with frame pointers but you can never tell how your caller was compiled so you cannot trust the "frame pointer" that you were given. >The top level Makefile that comes with the standard kernels (the ones >which can be downloaded from kernel.org etc.) adds -fomit-frame-pointer to >CFLAGS by default and it does not have something like > >ifdef CONFIG_FRAME_POINTER >CFLAGS += -fomit-frame-pointer >endif > >Is CONFIG_FRAME_POINTER a part of some external patch? >If yes, then is there a way to find the above in the standard >kernels? Some architectures require you to have a frame pointer, on those -fomit-frame-pointer is a null flag. On other architectures it is optional and they tend to have extra flags in arch/xxx/Makefile. >What about CONFIG_KDB_FRAMEPTR? Is it correct to use this in a standard >kernel to find whether the kernel is being compiled with frame pointer? I don't know which kernel you are looking at. CONFIG_KDB_FRAMEPTR is part of an old kdb patch, not part of the standard kernel. It has been removed from current kdb patches, kdb patches after May 9 2000 use CONFIG_FRAME_POINTER. Keith Owens, kdb maintainer. - 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] Remove unneeded symbols from System.map
On Sat, 23 Sep 2000 20:08:25 +0200, Daniel Phillips <[EMAIL PROTECTED]> wrote: >Keith Owens wrote: >> Please do not apply. The size of System.map is almost irrelevant. >> Having the __kstrtab_ and __ksymtab_ symbols in the map helps when >> debugging EXPORT_SYMBOL problems. I expect that other people find the >> __device entries to be useful. > >Hmmm, this couldn't be the same Keith Owens who claimed that >System.map is too large to be zipped and appended to bzImage could it? The size is irrelevant as long as the System.map is separate. Adding System.map to bzImage changes the criteria for what is "too big". BTW, modutils 2.3.17 fixes a bug in depmod -F System.map. It used to extract all global symbols from the map, now it only extracts symbols that are exported, global or static. And it needs __kstrtab_ to do it correctly. Removing __kstrtab_ would break modutils 2.3.17. > $(NM) vmlinux | grep -v -f scripts/System.map-filter | sort >System.map > >just a little bit more readable than: > > $(NM) vmlinux | grep -v >'\(compiled\)\|\(\.o$$\)\|\([aU]\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map > >More flexible too. I don't object to moving the exclude list to a scripts file, but excluding symbols that people use is wrong. - 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/
1023rd thread crashes 2.4.0-test8 from non-root user
Greetings. I have already done some high level searchs of the linux-kernel mailing list, as well as linux24.sourceforge.net (tytso's 2.4 todo list) and haven't seen mention of a problem referencing this problem. The problem is large numbers of threads in 2.4.0-test8 can result in a hard crash of the entire kernel. This can be done as a non-root user. Code to reproduce the problem (using perl-threads), as well as my kernel-config are available at http://www.psyber.com/~ted/linux24crash/ [1] The code creates X threads and lets them run Y seconds. When X > 1000 instabilty sets in, with segfaults on exit. For X > 1025 (or so) a ctrl-c during the run will cause a kernel crash. This happens even if the process is running as a non-root user. Instant kernel take-down. (1200 to 1500 threads with a ctrl-c guarantee a crash on my machine.) The machine is an Athlon 750 w/ 128mb (crucial memory) on a Asus K7V, running Debian/potato (partly w/ "unstable" packages") and the 2.4.0-test8 kernel. This test didn't phase a 2.2.13 kernel, but only 253 threads started sucessfully (limited by "max user processes" I assume). 2.4.0-test8 seems limited by some sort of max-files-per-process problem on process cleanup/exit, _although_ changing the open-files via ulimit on 2.4.0-test8 or 2.2.13 had no affect (either to a value of 1500 or 130). Obviously this is a major bug that should hold up the 2.4 release until it is resolved. I apologize for not having a patch or a C version of the code... the new job is keeping me more busy than I'd like. [1] http://www.psyber.com/~ted/linux24crash/ I figured 20k of extra traffic to the list should be avoided as probably less than 20 of you will look deeply at this. -- Ted Deppner http://www.psyber.com/~ted/ - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
safemode wrote: > Mark Hahn wrote: > >> this has nothing to do with the linux kernel. >> X itself does not use shm for anything. apps may use >> an X extension (XSHM) which uses shm segments to exchange >> image data without copying through a socket, but that's >> an extension, not inherent to X. >> >> > Ok, compiling using a cvs of X i got a couple hours ago, I'm just >> >> > wondering what the average segment number is for SHM on an X >> session >> > that has been up for a while i'll get back with any sort of >> info >> > on if the SHM problem has been solved with this latest CVS or if >> it >> > continues to look like a kernel SHM problem. So far though, >> > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to >> test9, >> > which died in 2 hours upon booting ...and it didn't have the added >> >> > stress of compiling X. >> > >> > - >> > > > I think it has a lot to do with the kernel, and with X. Since i > havn't upgraded anything but X (and thus the extensions) ... now it's > obvious that X is at fault for providing us with a wonderful shared > memory leak. But, the kernel too, has something to do with it since > test9 seems to be fairly unstable with it, causing all sorts of weird > happenings before totally freezing up like test8-vm3 does. This > problems only manifests in VERY recent X cvs copies so most people > will not see this problem. The problem i'm wondering about is if the > Kernel is handling shared memory correctly or if this is entirely X's > fault. > Somehow i cant help but think this is somehow linked to an OOM problem that has yet to be fixed with the 2.4.0-testX series. It seems suspiciously like the kernel is killing init when X decides it would be peachy to gobble up all the ram. i dont know of any way to prove this 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: cdrecord and 'invalid field in parameter list' error
> Basically, when attempting to write a disk with any version of cdrecord, > I get this error. I am running 2.2.17 (also 2.2.16) on x86 with > hedrick's ide patch, and the reiserfs patch, and the replacement SG > driver from the cdrecord page. If you use their cdrecord and their patch why not ask the cdrecord folk to sort it out. Also try a different cd recording app. - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
Mark Hahn wrote: this has nothing to do with the linux kernel. X itself does not use shm for anything. apps may use an X extension (XSHM) which uses shm segments to exchange image data without copying through a socket, but that's an extension, not inherent to X. > Ok, compiling using a cvs of X i got a couple hours ago, I'm just > wondering what the average segment number is for SHM on an X session > that has been up for a while i'll get back with any sort of info > on if the SHM problem has been solved with this latest CVS or if it > continues to look like a kernel SHM problem. So far though, > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to test9, > which died in 2 hours upon booting ...and it didn't have the added > stress of compiling X. > > - I think it has a lot to do with the kernel, and with X. Since i havn't upgraded anything but X (and thus the extensions) ... now it's obvious that X is at fault for providing us with a wonderful shared memory leak. But, the kernel too, has something to do with it since test9 seems to be fairly unstable with it, causing all sorts of weird happenings before totally freezing up like test8-vm3 does. This problems only manifests in VERY recent X cvs copies so most people will not see this problem. The problem i'm wondering about is if the Kernel is handling shared memory correctly or if this is entirely X's fault.
Re: cdrecord and 'invalid field in parameter list' error
On Sat, Sep 23 2000, Nathan Neulinger wrote: > CDB: 55 10 00 00 00 00 00 00 3C 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 05 00 00 00 00 12 00 00 00 00 26 00 00 8B > Sense Key: 0x5 Illegal Request, Segment 0 > Sense Code: 0x26 Qual 0x00 (invalid field in parameter list) Fru 0x0 > Sense flags: Blk 0 (not valid) error refers to data part, bit ptr 3 > (valid) field ptr 0 > cmd finished after 0.006s timeout 40s > cdrecord: Warning: using default CD write parameter data. > Mode Select Data 00 11 00 00 05 32 01 E4 08 00 00 00 20 00 00 00 00 20 > 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This isn't a kernel bug, rather cdrecord doing something it shouldn't. Judging by the above sense and mode select data, cdrecord has set the fixed packet bit with a write type of trace-at-once and this isn't valid. So that's probably why the drive is complaining. -- * Jens Axboe <[EMAIL PROTECTED]> * 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: cdrecord and 'invalid field in parameter list' error
Thomas Molina wrote: > > On Sat, 23 Sep 2000, Nathan Neulinger wrote: > > > I've seen mentions of this problem before on linux-kernel and on > > numerous other lists, but have never seen a solution to it. > > > > Basically, when attempting to write a disk with any version of cdrecord, > > I get this error. I am running 2.2.17 (also 2.2.16) on x86 with > > hedrick's ide patch, and the reiserfs patch, and the replacement SG > > driver from the cdrecord page. > > Check and replace data cables, ensure power line is plugged in and good, > use a lens cleaner. Otherwise you may have a drive going bad, but I > doubt that. Ah... Perhaps I should have mentioned that the drive works just fine reading. I.e. I can pull 100MB files off cd's on that drive without any errors occurring. I would think that would negate any of the above suggestions. I do know that the drive/case is quite warm, but I wouldn't think that would yield such a repeatable error. -- Nathan Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 CIS - Systems ProgrammingFax: (573) 341-4216 - 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] Reply to headder..
> Reply ALL also results in 2 mails being sent instead of one but of > course this is usually not a problem since one is going direct and the > other is going through vger, but still... it's kind of wasteful to > resources and i dont see any harm in Reply-to being sent in the > header. > Proftpd's mailing list seems to work fine with it. Is your position > against it just due to client incompatibility? Yes, it increases list traffic with things that don't need to be on the list. The odd second email isn't nearly as bad as seeing 100 posts that don't need to be on the lists accidentally sent here. In practice the majority of my linux-kernel email replies tend to not be back to the list. Which is more wasteful of resources: 100 second emails? or 10 extras sent to a few thousand subscribers? The majority of my linux-kernel email replies tend to not be back to the list. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
safemode wrote: > SHM segments are increasing (they only go away when X closes) .. swap seems > to be stable for nowhere is the ipcs -u output If they all go away when X closes, it seems that X is at fault. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
Re: Problem with 2.4.0-test9-pre6 seems to be SHM
Alan Cox wrote: > I have about 16 after 2 days. Thats a fairly typical desktop (gnome panel, > gfm and everything else is a terminal window) Whoa now?! 16 shm segments?if that's true something is terribly wrong with either X or the kernel's handling of shm that's scary. this is currently what i'm seeing after only 30 min of X -- Shared Memory Status segments allocated 2008 pages allocated 13842 pages resident 12281 pages swapped 1120 Swap performance: 5517 attempts 1120 successes -- Semaphore Status used arrays = 0 allocated semaphores = 0 -- Messages: Status allocated queues = 0 used headers = 0 used space = 0 bytes It increases every time i execute the command ipcs -u i am not even running the amount of apps i normally do. This seems to be a leak, but i'm not sure if it's from X or the kernel. I'm leaning towards X at this point. But the real problem i have with is the kernel is crashing when the requests for shm segments goes over the max for a while. (could not mail back directly to alan *shrugs* ) <[EMAIL PROTECTED]>: 194.168.151.1 does not like recipient. 550 rejected: administrative prohibition Giving up on 194.168.151.1. go figure - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
19.5 day uptime on test8 and 4.01b, ~13 segments, ~350K all user 'david'. 4 day uptime on test8 and 4.01c, ~16 segments, 256 bytes used by user 'postgres'. test9 is very broken, we know it is :] There are a bunch of OOPSes and complaints about the VM. -d safemode wrote: > Ok, compiling using a cvs of X i got a couple hours ago, I'm just > wondering what the average segment number is for SHM on an X session > that has been up for a while i'll get back with any sort of info > on if the SHM problem has been solved with this latest CVS or if it > continues to look like a kernel SHM problem. So far though, > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to test9, > which died in 2 hours upon booting ...and it didn't have the added > stress of compiling X. -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
cdrecord and 'invalid field in parameter list' error
I've seen mentions of this problem before on linux-kernel and on numerous other lists, but have never seen a solution to it. Basically, when attempting to write a disk with any version of cdrecord, I get this error. I am running 2.2.17 (also 2.2.16) on x86 with hedrick's ide patch, and the reiserfs patch, and the replacement SG driver from the cdrecord page. Starting to write CD/DVD at speed 8 in write mode for multi session. Last chance to quit, starting real write in 1 seconds. Waiting for reader process to fill input buffer ... input buffer ready. cdrecord: Input/output error. mode select g1: scsi sendcmd: retryable error CDB: 55 10 00 00 00 00 00 00 3C 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 12 00 00 00 00 26 00 00 8B Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x26 Qual 0x00 (invalid field in parameter list) Fru 0x0 Sense flags: Blk 0 (not valid) error refers to data part, bit ptr 3 (valid) field ptr 0 cmd finished after 0.006s timeout 40s cdrecord: Warning: using default CD write parameter data. Mode Select Data 00 11 00 00 05 32 01 E4 08 00 00 00 20 00 00 00 00 20 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cdrecord: Cannot open new session. cdrecord: fifo had 128 puts and 0 gets. cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%. There isn't any information in the cdrecord docs/etc. about this problem. All it ever talks about is that unable to allocate memory error, which went away as soon as I put in the replacement scsi-generic driver. Any ideas? Please cc responses. -- Nathan Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 CIS - Systems ProgrammingFax: (573) 341-4216 - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
safemode wrote: > Ok, compiling using a cvs of X i got a couple hours ago, I'm just > wondering what the average segment number is for SHM on an X session > that has been up for a while i'll get back with any sort of info > on if the SHM problem has been solved with this latest CVS or if it > continues to look like a kernel SHM problem. So far though, > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to test9, > which died in 2 hours upon booting ...and it didn't have the added > stress of compiling X. > It only took me 45 min to have X crash 2.4.0-test8-vm3, It occurred when i opened and closed xawtv a few times while the system was under stress from other apps (~1 load ) ... the shm segments kept increasing and i noticed something strange. -- Semaphore Status used arrays = 1 allocated semaphores = 14 It's always been 0 with the previous tests and with this test9-pre6 kernel. Not sure what the significance of it is. SHM segments are increasing (they only go away when X closes) .. swap seems to be stable for nowhere is the ipcs -u output -- Shared Memory Status segments allocated 1379 pages allocated 8770 pages resident 8329 pages swapped 0 Swap performance: 2956 attempts 0 successes -- Semaphore Status used arrays = 0 allocated semaphores = 0 -- Messages: Status allocated queues = 0 used headers = 0 used space = 0 bytes I'm not sure how that swap performance is supposed to be, i need someone to compare to that has this stuff working and does not have the SHM problem ... i expect to crash within an hour. - 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 Driver under 2.2.18preX bug
On Sun, 24 Sep 2000 [EMAIL PROTECTED] wrote: > Anybody else encountered a bug with the bttv driver under kernel > 2.2.18preX (All the Pre-releases) ? > Or the other thing- anybody got bttv driver to work under these kernels ? > > When I'm using this kernel with 2.2.17 bttv.o , it works great.. Hiya, Using xawtv 3.19 with 2.2.18pre9 doesn't appear to work correctly here either. It was working fine with 2.2.17pre20. Haven't tried any other of the 2.2.18pre series as I only just got finished with repackaging my kernel rpm not to include usb/nfs patches. v4l-conf is reporting that the base address disagrees between v4l and dga during xawtv startup. Not sure if this was the case with 2.2.17, as I start xawtv from the gnome panel usually (no terminal window). xawtv was certainly in overlay mode when I was running 2.2.17pre20. WARNING: v4l and dga disagree about the framebuffer base WARNING: Is v4l-conf installed correctly? ov_fbuf.base=0xe100, base=0xd800 WARNING: overlay mode disabled I hadn't reported yet because I'm using the NVidia binary module (0.95, recompiled against 2.2.18pre9 headers), and wanted to try to isolate the problem specifically to some change in pre9, and not something in the NVidia module for XFree 4.01 not liking something else in pre9 (like the agp stuff). Trying various -nodga/-noxv/-novm flags to xawtv produces an interesting array of hard locks and xawtv crashing. I'll try a 2.2.18pre9 with the 2.2.17 bttv.c/h tomorrow morning. Regards, Mark +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - 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 compiled with frame pointer
Sushil writes: > #ifdef CONFIG_FRAME_POINTER > code assuming frame pointer > #else > code assuming no frame pointer You want #endif here. > Is CONFIG_FRAME_POINTER a part of some external patch? I think you've been looking at some of the ARM code. Yes, we do manipulate the CFLAGS (have a look in arch/arm/Makefile) depending on the state of CONFIG_FRAME_POINTER. This is currently an ARM only feature though. It would be helpful if you can give some hints about what you're trying to do. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Given an image, how can show its config?
On Sat, 23 Sep 2000, David Ford wrote: > Keith Owens wrote: > > > That would take my 2.4.0 bzImage to 893864, it does not leave much room > > out of a 1.4Mb floppy for LILO files. We could have multiple make > > targets, with and without appended config/map but that just complicates > > the build environment. > > I normally occupy over a meg with my image and I frequently build a LILO boot > disk for safekeeping. I strip my config down to only enabled options and > further strip the CONFIG_ from it, then bzip2 -s -9 the both of config and > system map and it comes out to about 122K > > > > This is all to protect those few poor 'administrators' who cannot keep > > track of three separate files. We should not coddle such idiots, if > > they cannot track 3 files they should not be configuring Linux. > > Anybody who loses their config and System.map will learn from their > > mistake and only do it once or they will never learn, in which case > > they are better off running Windows. > > The same idiots who have multiple patch trees that haven't been merged and > different builds of a kernel to test effects? I.e. those who really do the > work on LKML? > > > > "Think of it as evolution in action". > > After you're looking down the ladder of evolution, think to look up the > ladder. > > Personally, /proc/ksyms has what I need for symbols but 1.3K for a .config is > trivial enough to add to the image. Some people want this, and some people dont. Make it configurable (as people already told) and the discussion is over. - 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: ISAPnP + Soundblaster doesn't work without 'multiple=0'
Hi Paul, Thanx very much for your patch for sb_card.c. I have tested it with 2.4.0-test9-pre6. The Oops is gone. Have a nice weekend Harri -- Harald Dunkel | [EMAIL PROTECTED] | If your operating system seems to Synopsys GmbH | Kaiserstr. 100 | be made by Dr. Frankenstein, then 52134 Herzogenrath, Germany| it is time for a change. +49 2407 9558 (fax? 44: 0) |Try Linux! --- Paul Laufer wrote: > > Here is the patch that I sent to Linus, but he hasn't applied it yet. > This bug, my bug, has been present since 2.4.0-test7. > > Paul Laufer > > > > >sb_card.c.2.4.0-test9-pre2.patchName: sb_card.c.2.4.0-test9-pre2.patch >Type: Plain Text (text/plain) - 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: Given an image, how can show its config?
Keith Owens wrote: > That would take my 2.4.0 bzImage to 893864, it does not leave much room > out of a 1.4Mb floppy for LILO files. We could have multiple make > targets, with and without appended config/map but that just complicates > the build environment. I normally occupy over a meg with my image and I frequently build a LILO boot disk for safekeeping. I strip my config down to only enabled options and further strip the CONFIG_ from it, then bzip2 -s -9 the both of config and system map and it comes out to about 122K > This is all to protect those few poor 'administrators' who cannot keep > track of three separate files. We should not coddle such idiots, if > they cannot track 3 files they should not be configuring Linux. > Anybody who loses their config and System.map will learn from their > mistake and only do it once or they will never learn, in which case > they are better off running Windows. The same idiots who have multiple patch trees that haven't been merged and different builds of a kernel to test effects? I.e. those who really do the work on LKML? > "Think of it as evolution in action". After you're looking down the ladder of evolution, think to look up the ladder. Personally, /proc/ksyms has what I need for symbols but 1.3K for a .config is trivial enough to add to the image. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
BTTV Driver under 2.2.18preX bug
Hello Everyone! Anybody else encountered a bug with the bttv driver under kernel 2.2.18preX (All the Pre-releases) ? Or the other thing- anybody got bttv driver to work under these kernels ? When I'm using this kernel with 2.2.17 bttv.o , it works great.. Cya, Oren. - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
Ok, compiling using a cvs of X i got a couple hours ago, I'm just wondering what the average segment number is for SHM on an X session that has been up for a while i'll get back with any sort of info on if the SHM problem has been solved with this latest CVS or if it continues to look like a kernel SHM problem. So far though, 2.4.0-test8-vm3 is handling the problem Quite well as opposed to test9, which died in 2 hours upon booting ...and it didn't have the added stress of compiling 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: Given an image, how can show its config?
> On Sat, 23 Sep 2000 11:33:31 +0200, > Daniel Phillips <[EMAIL PROTECTED]> wrote: > >I'd just like to remind you of Alan Cox's suggestion about appending > >.config.gz to bzImage so that it doesn't get loaded into memory, and > >my suggestion to put System.map.gz there as well. > > I worry about anything that increases the on disk size of bzImage, even > if the extra data does not get loaded into kernel memory. > > 629590 2.2.16/arch/i386/boot/bzImage > 786273 2.4.0-test8/arch/i386/boot/bzImage > > cat .config System.map | gzip | wc -c > 107591 Definitely, this feature should be optional. > This is all to protect those few poor 'administrators' who cannot keep > track of three separate files. We should not coddle such idiots, if > they cannot track 3 files they should not be configuring Linux. Did you ever try to manage ~50 different kernels built from the same source tree ? 3 * 50 = 150 Andrzej - 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.2.16/2.2.17 + Reiserfs + NFS patches?
Are there any known problems with using a reiserfs patched 2.2.16 or 2.2.17 with the NFS patches? If not, does the patch order matter? Also, what is the URL to get the NFS patches for the above kernels? TIA -- Mike A. Harris - Linux advocate - Open source advocate Copyright 2000 all rights reserved -- Need general help or technical support with Red Hat Linux 6.2? Join the user support mailing list by sending a message to "[EMAIL PROTECTED]" with the word "subscribe" on the subject line. - 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] mkdep mishandles apostrophes in // comments
Hi,
I ran into a problem with my own kernel source files in the Linux VR project
where 'make dep' was missing CONFIG_* dependencies for some files with C++
style comments. It turns out that mkdep doesn't check for // at all, so it
will misinterpret apostrophes in those comments as single quotes and ignore
the rest of the file up to the next single quote.
I realize some people don't much like C++ style comments in the kernel
source, but a quick grep shows them all over the place, some of which do
have apostrophes not used as quotes. Anyway, the following patch (partly
from Pavel Machek) appears to fix the problem. This is against current 2.4
kernel.
Mike Klar
Index: scripts/mkdep.c
===
RCS file: /cvsroot/linux-vr/linux/scripts/mkdep.c,v
retrieving revision 1.1.1.5
diff -u -d -r1.1.1.5 mkdep.c
--- scripts/mkdep.c 2000/07/12 08:43:00 1.1.1.5
+++ scripts/mkdep.c 2000/09/23 21:07:44
@@ -294,6 +294,7 @@
* The state machine looks for (approximately) these Perl regular
expressions:
*
*m|\/\*.*?\*\/|
+ *m|\/\/.*|
*m|'.*?'|
*m|".*?"|
*m|#\s*include\s*"(.*?)"|
@@ -326,9 +327,18 @@
CASE('C', cee);
goto start;
+/* // */
+slash_slash:
+ GETNEXT
+ CASE('\n', start);
+ NOTCASE('\\', slash_slash);
+ GETNEXT
+ goto slash_slash;
+
/* / */
slash:
GETNEXT
+ CASE('/', slash_slash);
NOTCASE('*', __start);
slash_star_dot_star:
GETNEXT
-
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] net/ipv4/arp.c #20000923
Attached is the most recent version of arp.c patch, it incorporates the
following:
- fixes the IP and hardware type collision
- removes the %s, "*" as the arp mask won't ever be incorporated here
-d
--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."
--- net/ipv4/arp.c.orig Fri Aug 4 18:18:49 2000
+++ net/ipv4/arp.c Sat Sep 23 12:47:03 2000
@@ -65,6 +65,7 @@
* clean up the APFDDI & gen. FDDI bits.
* Alexey Kuznetsov: new arp state machine;
* now it is in net/core/neighbour.c.
+ * David Ford : More fixes cleaning up the proc output
*/
/* RFC1122 Status:
@@ -1025,6 +1026,7 @@
char hbuffer[HBUFFERLEN];
int i,j,k;
const char hexbuf[] = "0123456789ABCDEF";
+ char abuf[16];
size = sprintf(buffer,"IP address HW type Flags HW address
Mask Device\n");
@@ -1063,20 +1065,15 @@
}
#endif
- {
- char tbuf[16];
- sprintf(tbuf, "%u.%u.%u.%u",
NIPQUAD(*(u32*)n->primary_key));
-
- size = sprintf(buffer+len, "%-16s 0x%-10x0x%-10x%s",
- tbuf,
- hatype,
- arp_state_to_flags(n),
- hbuffer);
-
- size += sprintf(buffer+len+size,
-" %-8s %s\n",
-"*", dev->name);
- }
+ size = sprintf(buffer+len, "%-16s 0x%-10x0x%-10x%s",
+ in_ntoa2(*(u32*)n->primary_key, abuf),
+ hatype,
+ arp_state_to_flags(n),
+ hbuffer);
+
+ size += sprintf(buffer+len+size,
+ " *%-16s\n",
+ dev->name);
read_unlock(>lock);
@@ -1099,15 +1096,15 @@
struct net_device *dev = n->dev;
int hatype = dev ? dev->type : 0;
- size = sprintf(buffer+len,
- "%u.%u.%u.%u0x%-10x0x%-10x%s",
- NIPQUAD(*(u32*)n->key),
+ size = sprintf(buffer+len, "%-16s 0x%-10x0x%-10x%s",
+ in_ntoa2(*(u32*)n->key, abuf),
hatype,
ATF_PUBL|ATF_PERM,
"00:00:00:00:00:00");
+
size += sprintf(buffer+len+size,
-" %-17s %s\n",
-"*", dev ? dev->name : "*");
+ " *%-16s\n",
+ dev ? dev->name : "*");
len += size;
pos += size;
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard
Re: [DOC] Debugging early kernel hangs
Benjamin Herrenschmidt wrote: > > >Hmm, good idea, but how does this work on, say, non-x86 architectures > >which don't have a VGA text frame buffer, or whose VGA text frame buffer > >is not mapped in, or whose VGA text frame buffer is not initialised. > > > >You will still end up with those "my kernel hangs during boot" messages. > > > >A lot of the problems with debugging early kernel hangs is that you > >don't have a display set up, or you don't have enough of the memory > >subsystem initialised (eg, before pci_init) to be able to access > >devices (eg, before paging_init). > > [.../...] > > I've implemented a similar mecanism on the PPC 2.2.x kernel. It's not in > the main tree since it requires a couple of lines of change to printk.c > in order to handle correctly the removal of the last console. > > Basically, I setup a "struct console" during very-early boot (almost at > the firmware level) that can basically display text on screen (using the > firmware pre-inited fb) using a very basic engine, and is setup by > default as the printk console. > > Then, in the main VT code, I unregister this boot console just before > registering the VT one. > > It's a bit hackish and so is not meant to be merged in the main tree, but > it's useful when I release test kernels for new Apple hardware, to have > printk work from the very beginning of boot. I don't see what is hackish about it. It is right to vector the console output and update the vector as you boot. When you shut down you do the same in reverse order, and that way you catch problems that otherwise would go completely unnoticed. Similarly, the panic function should be vectored. On entry to panic, set the panic vector to a simpler panic function and that way a recursive panic will not turn into an uninformative hang. And likewise, the notifier call chain for panic should be processed one call at a time with the call chain pointer updated in a static variable so that if/when there is a panic inside the notify chain the panic handler still makes forward progress. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel compiled with frame pointer
Hi, While writing kernel code what is the correct way to find out if the kernel is being compiled with frame pointer? Is the following code correct? #ifdef CONFIG_FRAME_POINTER code assuming frame pointer #else code assuming no frame pointer The top level Makefile that comes with the standard kernels (the ones which can be downloaded from kernel.org etc.) adds -fomit-frame-pointer to CFLAGS by default and it does not have something like ifdef CONFIG_FRAME_POINTER CFLAGS += -fomit-frame-pointer endif Is CONFIG_FRAME_POINTER a part of some external patch? If yes, then is there a way to find the above in the standard kernels? What about CONFIG_KDB_FRAMEPTR? Is it correct to use this in a standard kernel to find whether the kernel is being compiled with frame pointer? Thanks and Regards, Sushil. - 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] lkml reply-to header (was: Re: problem with 2.4.0-test9-pre6 seems to be SHM)
safemode wrote: > Reply ALL also results in 2 mails being sent instead of one but of course this is >usually not a problem since one is going direct and the other is going through vger, >but still... it's kind of wasteful to > resources and i dont see any harm in Reply-to being sent in the header. Proftpd's >mailing list seems to work fine with it. Is your position against it just due to >client incompatibility? It's only wasteful if you don't remove unwanted addresses from the list. No, my position isn't due to client incompatibility on the contrary my client is pretty good at making it easy for me to include/exclude addresses and react to headers appropriately. It's purely due to RFC guidelines and common practice requests. I wrote and maintain a mailing list server and have done scads of research on RFCs and documents written by other authors on this. Frankly I just reply-all, hilite the recipient and type 'lkml'. You're more than welcome to use procmail/formail and insert a reply-to header on your own mailbox if you want to make it easy for yourself. -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > i'll get back about the latest xfree86 in about 2 hours .. but if anyone has any >other ideas > > or info i can give ...it's not problem. test8 seems stable enough to keep itself >up until > > i'm ready to reboot. > > I should hope, I have a 20 day uptime so far. > > -d > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President hrmm.. It seems not even the mighty test8-pre6 can handle the cvs of X.. i'm using 90MB of swap at the moment... and almost 4000 segments in shm.. it's like they never go away unless i kill X ...still trying to find the latest cvs.. it appears the module xc is not the latest .. confusing ..anyways .. soon i will be compiling a new X and we shall see how it works. - 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: problem with 2.4.0-test9-pre6 seems to be SHM
In article <[EMAIL PROTECTED]>, safemode <[EMAIL PROTECTED]> wrote: >One more little complaint.. why doesn't vger replace the FROM to >[EMAIL PROTECTED] like any other sane mailing list ... i >keep going to Reply and not sending to the list. At least add a >reply-to tag like the proftpd mailing list has if you want to keep the >FROM tag as the original sender. The linux-kernel mailing list is the sane one, the other ones aren't. See http://www.unicom.com/pw/reply-to-harmful.html for an explanation Mike. -- Q: What is the one true indent width? A: 42. - 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 magic
Anton Altaparmakov wrote: > > I can't remember anything about protected mode interrupt handlers nor have > I ever looked at Linux interrupt handling but at least in real mode from my > good old PC/DOS programming days I seem to remember that if you are hooking > a hardware interrupt vector then you have to issue a end of interrupt (EOI) > to the 8259A interrupt controller (PIC) before doing the iret, for example > like so: > > ; Note: this uses "dst, src" operand ordering not the > ; "reversed" ordering used by gcc asm. > push ax > mov al,20h ; Nonspecific EOI > out 20h,al ; Write PIC output control word OCW2 > pop ax > iret > > Might this be the problem (or whatever the equivalent specific is in Linux > / pmode)? Oh yes, nothing has changed, this is still required, and don't forget to signal the slave PIC as well if your IRQ is 8 or higher. Lovely stuff. :P -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Munging reply-to headers etc. (was: Re: problem with 2.4.0-test9-pre6 seems to be SHM)
In <[EMAIL PROTECTED]> safemode <[EMAIL PROTECTED]> writes: [mega snip] See http://www.unicom.com/pw/reply-to-harmful.html for all of the good reasons why the vger lists behave just the way they should. -- Henrik Storner | "Crackers thrive on code secrecy. Cockcroaches breed <[EMAIL PROTECTED]> | in the dark. It's time to let the sunlight in." | | Eric S. Raymond, re. the Frontpage backdoor - 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: problem with 2.4.0-test9-pre6 seems to be SHM
safemode wrote: > i'll get back about the latest xfree86 in about 2 hours .. but if anyone has any >other ideas > or info i can give ...it's not problem. test8 seems stable enough to keep itself up >until > i'm ready to reboot. I should hope, I have a 20 day uptime so far. -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Linux 2.2.18pre10
More USB synchronziation. Other fixes of stuff that crept in from the big changes before and a few longer term bug fixes 2.2.18pre10 o Add printk level to partition printk messages (me) o Fix bluesmoke address report/serialize (Andrea Arcangeli) o Add 2.4pre CPUID/MSR docs to 2.2.18pre (Adrian Bunk) o Update to the 2.4pre via audio driver (Jeff Garzik) o Fix small SMP race in set_current_state (Andrea Arcangeli) o Fix __KERNEL__ checks in sparc headers (Dave Miller) o Fix ADFS root directory bug added in pre9 (Russell King) o Trap incorrect swap partition sizes (Andries Brouwer) o Fix nfsroot bootp/dhcp on sparc64 (Dave Miller) o Tidy up tcp opt parsing (Dave Miller) o Check range on port range sysctl(Dave Miller) o Back out erroneous i2c.h change (Arjan van de Ven) o Fix trident hangs due to over zealous addition (Eric Brombaugh) of midi support o Fix big endian/macro bug in ext2fs (Andi Kleen) o Bring dabusb driver into line with 2.4 (Greg Kroah-Hartman) o Bring event drivers into line with 2.4 (Franz Sirl, Greg Kroah-Hartman) o Fix usb help texts (Greg Kroah-Hartman) o Generic frame diverter (Benoit Locher) o Bring USB serial back into line with 2.4(Greg Kroah-Hartman) o Fix DVD driver rpc state bug(Jens Axboe) o Fix extra sunrpc printk (Tim Mann) o USB init tidy up(Greg Kroah-Hartman) o Allow PlanB video on generic PPC(Michel Lanners) o Doc fixes/trim cvs logs on isdn drivers (Kai Germaschewski) o USB hid, hub, ibmcam, dsbr100 devices updates (Greg Kroah-Hartman) o Return EAFNOSUPPORT for out of range families o Fix SMP locking on floppy driver(Jonathan Corbet) o Add module author info to acm.c (Greg Kroah-Hartman) o Update CREDITS to reflect all the USB guys (Greg Kroah-Hartman) o ipfw wrong allocation flag fix (Rusty Russell) o Implement Sun style lockf/nfs cache barriers(Trond Myklebust) o Updated ISI serial driver (Multitech) | You may well need their newer firmware set/loader for the | later cards too 2.2.18pre9 o Fix usb module load oops(Thomas Sailer) o Bring USB boot drivers in line with 2.4t8 (Greg Kroah-Hartman) o And USB print drivers (Greg Kroah-Hartman) o And USB Rio driver (Greg Kroah-Hartman) o And USB dc2xx driver(Greg Kroah-Hartman) o And USB mdc800 driver (Greg Kroah-Hartman) o NFSv3 support and NFS updates (Trond Myklebust and co) o Compaq 64bit/66Mhz PCI Fibrechannel driver (Amy Vanzant-Hodge) o Disable microtouch driver (doesnt work in 2.2 (Greg Kroah-Hartman) currently) o Update ADFS support (Russell King) o Update ARM arch specific code and includes (Russell King) o Update ARM specific drivers (Russell King) o Use both fast and slow A20 gating on boot (Kira Brown) | if your box doesnt boot I want to know about it... | Needed for stuff like the AMD Elan 2.2.18pre8 o Fix mtrr compile bug(Peter Blomgren) o Alpha PCI boot up fix (Michal Jaegermann) o Fix vt/keyboard dependancy in USB config(Arjan van de Ven) o Fix sound hangs on cs4281 (Tom Woller) o Fix Alpha vmlinuz.lds (Andrea Arcangeli) o Fix CDROMPLAYTRKIND bug, allow root to open (Jens Axboe) the cd door whenver. o Update ov511 to match 2.4 (Greg Kroah-Hartman) o Further devio.c fix (Greg Kroah-Hartman) o Update NR_TASKS comment (Jarkko Kovala) o Further sparc64 ioctl translator fixes (Andi Kleen) 2.2.18pre7 o Fix the AGP compile in bug (Arjan van de Ven) o Revert old incorrect syncppp state change (Ivan Passos) o Fix i810 rng to actually get built in (Arjan van de Ven) o Megaraid compile fix, joystick, mkiss fixes (Arjan van de Ven) o Kawasaki USB ethernet depends on net(Arjan van de Ven) o Compaq cpqarray update (Charles White) o Fix usb problem with
Re: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > One more little complaint.. why doesn't vger replace the FROM to > > [EMAIL PROTECTED] like any other sane mailing list ... i > > keep going to Reply and not sending to the list. At least add a > > reply-to tag like the proftpd mailing list has if you want to keep the > > FROM tag as the original sender. > > reply->all works wonderful. > > It's not proper to replace the header and advised against as a common practice. >Adding a reply-to is also advised against but is somewhat 50/50 in practical use. >Clients are suggested to use their reply-to-all > feature instead. Normally you get both the sender and the list. > > -d > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President Reply ALL also results in 2 mails being sent instead of one but of course this is usually not a problem since one is going direct and the other is going through vger, but still... it's kind of wasteful to resources and i dont see any harm in Reply-to being sent in the header. Proftpd's mailing list seems to work fine with it. Is your position against it just due to client incompatibility? - 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: problem with 2.4.0-test9-pre6 seems to be SHM
2.4.0-test8-vm3 seems quite stable with this CVS of X After running xawtv and gqmpeg ...which would quickly die due to shm being maxed .. it still works and shows ~ 839 segments ..not really moving from it And after 20 min with all the apps i had open before, still not in swap. Which on test9, i would be ~50MB into swap. . and shortly around an hour 90MB Something is wrong with test9 or the interaction with test9 and 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: alloc_skb called nonatomically from interrupt
On Sat, 23 Sep 2000, Jesper Juhl wrote: > Hello people, > > This is probably nothing important, but I thought I'd post it anyway in > case it's of use to somebody. Actually its important. > I just checked my syslog and noticed these strange messages: > > Aug 29 19:05:19 dustpuppy kernel: Unable to handle kernel paging request > at virtual address f006f004 > Aug 29 19:05:19 dustpuppy kernel: current->tss.cr3 = 03d34000, %cr3 = > 03d34000 > Aug 29 19:05:19 dustpuppy kernel: *pde = > Aug 29 19:05:19 dustpuppy kernel: current->tss.cr3 = 03d34000, %cr3 = > 03d34000 > Aug 29 19:05:19 dustpuppy kernel: *pde = > Aug 29 19:32:49 dustpuppy kernel: alloc_skb called nonatomically from > interrupt c0188061 > Aug 29 19:32:49 dustpuppy kernel: alloc_skb called nonatomically from > interrupt c016d60d > > I don't recall having any problems with my machine lately, so this > puzzels me. > > The kernel I was running at the time was 2.2.13 (unfortunately I don't > have that specific kernel anymore - upgraded to 2.2.17). > My hardware is a IBM Thinkpad 600 - 233Mhz Pentium MMX with 64MB RAM. If you have this problem with 2.2.17, put your System.map available to download somewhere and mail this list again. Thanks for your report. - 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: lvm in 2.4.0-test9pre5
On Sat, Sep 23, 2000 at 01:34:33PM -0500, Peter Samuelson wrote: > common association. It's a documentation issue as much as anything, Agreed. > and you've basically taken care of that in -pre6. Looks fine to me too. 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > It seems to me that test8-vm3 handles this fine. in test9 upon loading X i was > > already using swap and down to 10MB ... here i have netscape loaded and some other > > stuff along with gaim and i've got 36MB free still. I'm not so sure you can chalk > > this up totally to X test9 is a VERY VERY poor kernel compared to test8-vm3 > > I fully agree. There is much too high of a problem factor with the test9 series for >me > to use them on my workstations and I don't have time to debug them due to priorities. > > I recommend you do a fresh checkout (not update) of X (current version is 4.01d), >and use > test8 and we'll go from that point. Verify that test8 is clean, apply Rik's VM >patch, > test again, then step to test9. > > There are three issues: > > 1) 100% use of SHM segments appears to cause instability > 2) SHM segments count keeps increasing using X 4.01c possibly due to corrupted cvs >tree, > fresh checkout fixed it for one person > 3) test-9...don't even go there ;) > > -d > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President Indeed It will take approximately 2 hours for me to have the new X installed and reboot to use it and get any results. However, test8-vm3 would be AWESOME if it didn't have that deadlock that makes it crash after a while. it seems to be devoid of any of the annoying problems test9 has. One thing that seems to be overlooked too and i'm not sure if it's related or not is my DMA's timeout on test9 this does not occur on test8-vm3. Well, i'll get back about the latest xfree86 in about 2 hours .. but if anyone has any other ideas or info i can give ...it's not problem. test8 seems stable enough to keep itself up until i'm ready to reboot. - 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: lvm in 2.4.0-test9pre5
[Peter Samuelson] > > "md", on the other hand, is well-established as referring to Linux > > RAID, but if you add lvm the label is too narrow. [Linus] > Yes, we have all thes _historical_ reasons why people think "md" > refers to the particular RAID code in question. But so what? LVM is > also very much an issue of handling multiple disks, and organizing > them. "md" as shorthand for "multiple disks" works fine for LVM too. Well, I just thought there could be confusion between 'md' -> 'multiple disks' versus 'md' -> 'Linux RAID drivers' which is probably the more common association. It's a documentation issue as much as anything, and you've basically taken care of that in -pre6. > Does anybody have any real technical arguments against it, or are all > arguments of the type "I'm used to 'md' meaning RAID, and I am not > willing to reconsider"? No, actually I was more arguing against 'sm' than anything else. Originally I thought the directory 'md' was just fine; it was only when Andrea brought up the name issue that I started thinking of LVM and the alternatives. By all means leave it as it is. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with 2.4.0-test9-pre6 seems to be SHM
safemode wrote: > It seems to me that test8-vm3 handles this fine. in test9 upon loading X i was > already using swap and down to 10MB ... here i have netscape loaded and some other > stuff along with gaim and i've got 36MB free still. I'm not so sure you can chalk > this up totally to X test9 is a VERY VERY poor kernel compared to test8-vm3 I fully agree. There is much too high of a problem factor with the test9 series for me to use them on my workstations and I don't have time to debug them due to priorities. I recommend you do a fresh checkout (not update) of X (current version is 4.01d), and use test8 and we'll go from that point. Verify that test8 is clean, apply Rik's VM patch, test again, then step to test9. There are three issues: 1) 100% use of SHM segments appears to cause instability 2) SHM segments count keeps increasing using X 4.01c possibly due to corrupted cvs tree, fresh checkout fixed it for one person 3) test-9...don't even go there ;) -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: [PATCH] Remove unneeded symbols from System.map
Keith Owens wrote: > > Brian Gerst <[EMAIL PROTECTED]> wrote: > >Currently, System.map contains a significant number of automatically > >generated symbols. These symbols are unnecessary for debugging since > >they represent individual elements of the exported symbol and PCI device > >tables, yet represent about 60% of the symbols in System.map. This > >patch adds a filter to remove these symbols. > > Please do not apply. The size of System.map is almost irrelevant. > Having the __kstrtab_ and __ksymtab_ symbols in the map helps when > debugging EXPORT_SYMBOL problems. I expect that other people find the > __device entries to be useful. Hmmm, this couldn't be the same Keith Owens who claimed that System.map is too large to be zipped and appended to bzImage could it? Seriously, don't you find: $(NM) vmlinux | grep -v -f scripts/System.map-filter | sort >System.map just a little bit more readable than: $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\([aU]\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map More flexible too. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > XFree86 Version 4.0.1b / X Window System > (protocol Version 11, revision 0, vendor release 6400) > Release Date: 11 August 2000 > > =) > > Are you by chance using cvs X from after september 10th? If so, hop on the > [EMAIL PROTECTED] mailing list and post your comments there. There is another > gentlemen with a similar problem. I'm changing pace here, I believe the kernel is > fine and it is an X issue as it occurs on 2.2 as well. Visit the tail of: > http://www.xfree86.org/pipermail/xpert/2000-September/thread.html. > > -d > > safemode wrote: > > > When in doubt. . Blame it on the biggest piece of crap around .. X.One can > > say using a cvs of X is the cause of this by somehow i doubt it would matter. X > > needs a sane make system and i'll bet 10:1 that it's the root of this shm usage. > > But it should not be crashing the OS ...which does occur since i just went down a > > couple minutes ago. Right now it's increasing 1 segment a second it seems. it's > > at 1200 now and i give it about 30 more minutes before i crash again. I'm gonna > > run this on the test8-vm3 patched kernel i had before that was VERY good except > > for that deadlock problem that caused me to crash after 7 days. If the shm usage > > is insane on that then i'll believe it is X's fault. be back with the results > > in a few minutes. > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President XFree86 Version 4.0.1c / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 28 August 2000 i cvs'd and compiled this last night Sept 22 ipcs -u -- Shared Memory Status segments allocated 439 pages allocated 2990 pages resident 2645 pages swapped 0 Swap performance: 0 attempts 0 successes -- Semaphore Status used arrays = 0 allocated semaphores = 0 -- Messages: Status allocated queues = 0 used headers = 0 used space = 0 bytes cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 130011136 93089792 369213440 1347584 39284736 Swap: 2052710400 205271040 MemTotal: 126964 kB MemFree: 36056 kB MemShared: 0 kB Buffers: 1316 kB Cached: 38364 kB Active: 18760 kB Inact_dirty: 20920 kB Inact_clean: 0 kB Inact_target: 260 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 126964 kB LowFree: 36056 kB SwapTotal: 200460 kB SwapFree: 200460 kB df shm8388608 11996 8376612 1% /var/shm It seems to me that test8-vm3 handles this fine. in test9 upon loading X i was already using swap and down to 10MB ... here i have netscape loaded and some other stuff along with gaim and i've got 36MB free still. I'm not so sure you can chalk this up totally to X test9 is a VERY VERY poor kernel compared to test8-vm3 - 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: problem with 2.4.0-test9-pre6 seems to be SHM
safemode wrote: > One more little complaint.. why doesn't vger replace the FROM to > [EMAIL PROTECTED] like any other sane mailing list ... i > keep going to Reply and not sending to the list. At least add a > reply-to tag like the proftpd mailing list has if you want to keep the > FROM tag as the original sender. reply->all works wonderful. It's not proper to replace the header and advised against as a common practice. Adding a reply-to is also advised against but is somewhat 50/50 in practical use. Clients are suggested to use their reply-to-all feature instead. Normally you get both the sender and the list. -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: lvm in 2.4.0-test9pre5
On Fri, 22 Sep 2000, Peter Samuelson wrote: > > But most if not all block drivers, and some char drivers for that > matter, could be considered part of "storage management". So the label > is too broad. "md", on the other hand, is well-established as > referring to Linux RAID, but if you add lvm the label is too narrow. Why? Yes, we have all thes _historical_ reasons why people think "md" refers to the particular RAID code in question. But so what? LVM is also very much an issue of handling multiple disks, and organizing them. "md" as shorthand for "multiple disks" works fine for LVM too. I think most people who complain about the "md" directory naming do so just because they have this emotional attachement to "md" as the particular implementation that it implied a year ago, and they've gotten used to that association. But I don't think there is anything wrong with grouping RAID and LVM under the title "md", and just leaving it as such. If you look at pre6, the comments changed a bit to make it clearer that MD now includes both LVM and RAID as equal partners, and I don't see any problem with that setup. Does anybody have any real technical arguments against it, or are all arguments of the type "I'm used to 'md' meaning RAID, and I am not willing to reconsider"? Sure, it could be called "sm" for "storage management" too. Or "dm" for "disk management". Or it could be under drivers/block/multi. Or it could validly be called any number of things. I just think that "md" was a valid name too, and I got the patch with that name, so.. 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: problem with 2.4.0-test9-pre6 seems to be SHM
Shaw Starr repored on [EMAIL PROTECTED] that a fresh checkout of 4.01d and fresh build of X resulted in a fixed/working shm w/ X. -d safemode wrote: > When in doubt. . Blame it on the biggest piece of crap around .. X.One can > say using a cvs of X is the cause of this by somehow i doubt it would matter. X > needs a sane make system and i'll bet 10:1 that it's the root of this shm usage. > But it should not be crashing the OS ...which does occur since i just went down a > couple minutes ago. Right now it's increasing 1 segment a second it seems. it's > at 1200 now and i give it about 30 more minutes before i crash again. I'm gonna > run this on the test8-vm3 patched kernel i had before that was VERY good except > for that deadlock problem that caused me to crash after 7 days. If the shm usage > is insane on that then i'll believe it is X's fault. be back with the results > in a few minutes. -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: problem with 2.4.0-test9-pre6 seems to be SHM
Use your client Reply all function. that'll get itint here. I personally think the list is fine the way it is because I dont need to worry about whether or not the person who sent the message is on the list or not by default. But that's just me. safemode wrote: > > One more little complaint.. why doesn't vger replace the FROM to > [EMAIL PROTECTED] like any other sane mailing list ... i > keep going to Reply and not sending to the list. At least add a > reply-to tag like the proftpd mailing list has if you want to keep the > FROM tag as the original sender. > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [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: problem with 2.4.0-test9-pre6 seems to be SHM
XFree86 Version 4.0.1b / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 11 August 2000 =) Are you by chance using cvs X from after september 10th? If so, hop on the [EMAIL PROTECTED] mailing list and post your comments there. There is another gentlemen with a similar problem. I'm changing pace here, I believe the kernel is fine and it is an X issue as it occurs on 2.2 as well. Visit the tail of: http://www.xfree86.org/pipermail/xpert/2000-September/thread.html. -d safemode wrote: > When in doubt. . Blame it on the biggest piece of crap around .. X.One can > say using a cvs of X is the cause of this by somehow i doubt it would matter. X > needs a sane make system and i'll bet 10:1 that it's the root of this shm usage. > But it should not be crashing the OS ...which does occur since i just went down a > couple minutes ago. Right now it's increasing 1 segment a second it seems. it's > at 1200 now and i give it about 30 more minutes before i crash again. I'm gonna > run this on the test8-vm3 patched kernel i had before that was VERY good except > for that deadlock problem that caused me to crash after 7 days. If the shm usage > is insane on that then i'll believe it is X's fault. be back with the results > in a few minutes. -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: problem with 2.4.0-test9-pre6 seems to be SHM
One more little complaint.. why doesn't vger replace the FROM to [EMAIL PROTECTED] like any other sane mailing list ... i keep going to Reply and not sending to the list. At least add a reply-to tag like the proftpd mailing list has if you want to keep the FROM tag as the original sender. David Ford wrote: > I think it's time to get Christoph on the line and see what he has to say. The > 4096 number is a limit to the system, you can have a max of 4096 shared memory > segments systemwide. Do you know offhand which programs are using(abusing) > shm? > > -d > > safemode wrote: > > > David Ford wrote: > > > > > No, those two are often empty. Does the total of the first group's bytes > > > column match the used column of df? > > > > > > -d > > > > The sum of the Bytes used in the 4096 entries ipcs shows is WAY off from the > > bytes used in df if that's what you wanted to know.df shows 109K in > > use... and that's easily beaten by the first entry in ipcs > > > > -- Shared Memory Segments > > key shmid owner perms bytes nattchstatus > > 0x 32769 root 600 5038082 dest > > 0x0002 131074root 600 1966082 > > 0x0003 163843root 600 6553602 > > 0x 3997700 root 777 5240 1 dest > > 0x 4030469 root 777 5060 1 dest > > 0x 4063238 root 777 4700 1 dest > > > > this is the first 6 entries ... i'm not sure what you're getting at with > > this though.. > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President When in doubt. . Blame it on the biggest piece of crap around .. X.One can say using a cvs of X is the cause of this by somehow i doubt it would matter. X needs a sane make system and i'll bet 10:1 that it's the root of this shm usage. But it should not be crashing the OS ...which does occur since i just went down a couple minutes ago. Right now it's increasing 1 segment a second it seems. it's at 1200 now and i give it about 30 more minutes before i crash again. I'm gonna run this on the test8-vm3 patched kernel i had before that was VERY good except for that deadlock problem that caused me to crash after 7 days. If the shm usage is insane on that then i'll believe it is X's fault. be back with the results in a few minutes.
Re: problem with 2.4.0-test9-pre6 seems to be SHM
I think it's time to get Christoph on the line and see what he has to say. The 4096 number is a limit to the system, you can have a max of 4096 shared memory segments systemwide. Do you know offhand which programs are using(abusing) shm? -d safemode wrote: > David Ford wrote: > > > No, those two are often empty. Does the total of the first group's bytes > > column match the used column of df? > > > > -d > > The sum of the Bytes used in the 4096 entries ipcs shows is WAY off from the > bytes used in df if that's what you wanted to know.df shows 109K in > use... and that's easily beaten by the first entry in ipcs > > -- Shared Memory Segments > key shmid owner perms bytes nattchstatus > 0x 32769 root 600 5038082 dest > 0x0002 131074root 600 1966082 > 0x0003 163843root 600 6553602 > 0x 3997700 root 777 5240 1 dest > 0x 4030469 root 777 5060 1 dest > 0x 4063238 root 777 4700 1 dest > > this is the first 6 entries ... i'm not sure what you're getting at with > this though.. -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
Re: alloc_skb called nonatomically from interrupt
> > This is probably nothing important, but I thought I'd post it anyway in > > case it's of use to somebody. > > it is important, but unless you are unable to provide a System.map from > exactly the kernel image you were running at that time, it is useless. > > -- > Live long and prosper > - Harald Welte / [EMAIL PROTECTED] I'm affraid I no longer have that specific System.map file - I'll save them in the future! - Jesper Juhl [EMAIL PROTECTED] (please CC on replies) - 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > No, those two are often empty. Does the total of the first group's bytes > column match the used column of df? > > -d The sum of the Bytes used in the 4096 entries ipcs shows is WAY off from the bytes used in df if that's what you wanted to know.df shows 109K in use... and that's easily beaten by the first entry in ipcs -- Shared Memory Segments key shmid owner perms bytes nattchstatus 0x 32769 root 600 5038082 dest 0x0002 131074root 600 1966082 0x0003 163843root 600 6553602 0x 3997700 root 777 5240 1 dest 0x 4030469 root 777 5060 1 dest 0x 4063238 root 777 4700 1 dest this is the first 6 entries ... i'm not sure what you're getting at with this 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > xawtv will still work but gqmpeg cannot run. shget returns no memory > > available on any app trying to access it. Well, hope that tells > > someone something because i'm stumped .. something in shm seems > > broken.. or the vm is. > > what does 'ipcs' show? a huge list or a lot of large segments? how about > 'df' if you have shmfs mounted. the 'used' part should match the tally of > ipcs. > > -d > Oops, forgot to read the -h on ipcs .. . here is a better idea of what is goin on -- Shared Memory Status segments allocated 4097 pages allocated 27362 pages resident 8744 pages swapped 18179 Swap performance: 25422 attempts 18180 successes -- Semaphore Status used arrays = 0 allocated semaphores = 0 -- Messages: Status allocated queues = 0 used headers = 0 used space = 0 bytes hope that says something
Re: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > xawtv will still work but gqmpeg cannot run. shget returns no memory > > available on any app trying to access it. Well, hope that tells > > someone something because i'm stumped .. something in shm seems > > broken.. or the vm is. > > what does 'ipcs' show? a huge list or a lot of large segments? how about > 'df' if you have shmfs mounted. the 'used' part should match the tally of > ipcs. > > -d my first post shows what df says ..but here it is again ipcs shows A VERY HUGE LIST... ending with this -- Semaphore Arrays key semid owner perms nsems status -- Message Queues key msqid owner perms used-bytes messages yes, they are empty... is this a problem too? df shows Filesystem 1k-blocks Used Available Use% Mounted on shm8388608109448 8279160 2% /var/shm
Re: Tailmerging for Ext2 - release 0.0
Daniel Phillips wrote: > I see that Ingo Molnar has been working on a btree directory extension for Ext2... Oops, I mispoke, Ted Ts'o is actually doing that work, sorry Ted. Um, did it work? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Tone of the Race to 2.4....
Seems a little like people are racing to get this kernel out.. and getting frustrated with the little things that keep cropping up.. Sounds so much like our business where it was starting to seem like we were racing from one fire to another, and wondering how come we got to that point.. The way we got back on track was to remember the basics.. And FORCE ourselves to make time to do them ALL, or don't do it at all.. Looking back is easier, and we can see that we let these basics slip..the basics we agree need to be done are... 1) Does it work?? 2) Is it tested? 3) Does it look pretty?? (syntactically, comments, and flow...) 4) Looking back in hindsight, could I have done it in a better way?? The more often we let ourselves get to the point where we start sacrificing 2,3, and 4, the more fires we have to put out, the less time we seem to have, and we use that as justification to let 2,3, and 4 slide even more.. Pretty soon we are in catch 22 land... Sometimes forcing ourselves to slow down, actually ends up saving time... and we think a lot clearer too.. Just an observation from the sidelines.. And not pointing any fingers.. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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: Given an image, how can show its config?
Andreas Haumer wrote: > > Keith Owens wrote: > > > > I worry about anything that increases the on disk size of bzImage, even > > if the extra data does not get loaded into kernel memory. > > > You also have to consider filesize restrictions with some > network bootproms loading the kernel image with TFTP. > > At least, that feature should be optional! Yes, it could be two config options: bzImage includes System map bzImage includes System config But actually we're not talking about a kernel build option at all, we're just talking about cat'ing one or two gzip files onto the end of bzImage, and so the only reason for making it a config option would be for taking care of really clueless people like me who don't know that. Otherwise it would just be a little script or perhaps an option on 'make install'. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre6 and GFP_BUFFER allocations
On Sat, 23 Sep 2000, Roger Larsson wrote: > One approach could be: only goto try_again if GFP_IO is set. > And alloc one page from the critical memory pool. > I will try this. i'll try this too. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Given an image, how can show its config?
Keith Owens wrote: > Daniel Phillips <[EMAIL PROTECTED]> wrote: > > I'd just like to remind you of Alan Cox's suggestion about appending > > .config.gz to bzImage so that it doesn't get loaded into memory, and > > my suggestion to put System.map.gz there as well. > > I worry about anything that increases the on disk size of bzImage, even > if the extra data does not get loaded into kernel memory. > > 629590 2.2.16/arch/i386/boot/bzImage > 786273 2.4.0-test8/arch/i386/boot/bzImage > > cat .config System.map | gzip | wc -c > 107591 > > That would take my 2.4.0 bzImage to 893864, it does not leave much room > out of a 1.4Mb floppy for LILO files. We could have multiple make > targets, with and without appended config/map but that just complicates > the build environment. This is no argument when talking about hard disks. You are talking only about floppy disks. I think you are smart enough to leave out the gzip files if you are building for a floppy. The zipped .config is considerably smaller than the system map, only about 4K in size. Surely you would have no problem with that? > Anybody who loses their config and System.map will learn from their > mistake and only do it once or they will never learn, in which case > they are better off running Windows. > > "Think of it as evolution in action". OK, I'm thinking about it that way. I concluded that somebody who accidently selects both the 'bzImage includes System map' and 'bzImage includes System config' options then complains that the boot file is too big needs to be selected out. Please note that when you're talking about idiots you're talking about people like me and Alan, and we idiots resent that. ;-) -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre6 and GFP_BUFFER allocations
On Sat, 23 Sep 2000, Roger Larsson wrote: > * Won't we end up in an infinite loop? FYI, i still see a rare deadlock, even under test9-pre6. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problem with 2.4.0-test9-pre6 seems to be SHM
In running xawtv i stumbled upon a very interesting message shmget: No space left on device yet df -m shows shm 8192 108 8084 2% /var/shm I'm not sure what's going on here, /var/shm shows a BUNCH of files in it.. and none of my partitions are even close to being full according to df -m also. any hints would be helpful - 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/
test9-pre6 and GFP_BUFFER allocations
Hi, What will happen in this scenario: a process * grabs a fs semaphore * needs some buffers to do IO, calls __alloc_pages(GFP_BUFFER) Suppose the system is MIN on free mem, has no inactive_clean pages. We will end up around line 446 in pages_alloc.c and issue a try_to_free_pages(...). Then goto try_again. * In our case this is unlikely to work - not allowed to do IO. * Will we sleep? Probably not, not even in refill_inactive (no GFP_IO) BTW, Why can't we schedule if GFP_IO is not set??? * Will we free any page, to get above MIN - only if there are enough clean pages in active list. * Won't we end up in an infinite loop? Suppose it does sleep. Will kswapd then be able to free any page assuming we are holding a critical fs semaphore... Or am I missing something, again? One approach could be: only goto try_again if GFP_IO is set. And alloc one page from the critical memory pool. I will try this. /RogerL -- Home page: http://www.norran.net/nra02596/ - 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] ISAPNP using an invalid IO_APIC IRQ
Alan Cox wrote: > > IRQ 5 may well have gone to an onboard device. > > There are two things to note here: > > 1. By default if you boot with non PnP OS the BIOS will assign IRQ's > to PnP devices and we would be best to try and keep the existing value when > possible (so the PCI/ISA routing is correct) Yes, when I tell the BIOS that the OS is not PnP aware it assigns IRQ 9 to NIC, yet Linux tries to assign it to IRQ 5. Martin - 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: Given an image, how can show its config?
On Sat, 23 Sep 2000, Keith Owens wrote: > I worry about anything that increases the on disk size of bzImage, even > if the extra data does not get loaded into kernel memory. > > 629590 2.2.16/arch/i386/boot/bzImage > 786273 2.4.0-test8/arch/i386/boot/bzImage > > cat .config System.map | gzip | wc -c > 107591 > > That would take my 2.4.0 bzImage to 893864, it does not leave much room > out of a 1.4Mb floppy for LILO files. So (a) make it optional during the configuration stage, (b) extend strip or some other user-land tool to rip 'em off afterwards for the corner cases that don't want them, or (c) do both (a) and (b). > This is all to protect those few poor 'administrators' who cannot keep > track of three separate files. We should not coddle such idiots, if > they cannot track 3 files they should not be configuring Linux. By reductio ad absurdum, we should also get rid of gcc. It's just coddling the idiots who can't do everything in assembly, after all, and therefore shouldn't be programming Linux If appending them doesn't hurt anything, and makes life easier for people, why not? It'd certainly make life easier for both kernel developers (since bug report quality will increase with the lowered chance of said idiots using the wrong System.map / no System.map) and for the ksymoops maintainer (since you'll finally have one standard place to have it look for System.map). Granted, there are other ways to do the same thing. We could, for example, combine what's now /boot and /lib/modules into one directory like /lib/kernel, and have make install drop bzImage, System.map, .config, and modules in /lib/kernel/'uname -r'/ . People would have to mount /lib/kernel as a separate partition like they currently do /boot, and they'd have to modify lilo.conf, ksymoops, and modutils, but after that it would work and we'd still have a semi-idiocy-proof standard > "Think of it as evolution in action". *shrug* It's "evolution in action" to append .config / System.map to bzImage as well. What's your point? later, chris -- Chris Ricker [EMAIL PROTECTED] [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: problem with kmalloc
you didn't use GFP_KERNEL priority in the interrupt handler, did you? GFP_KERNEL allocations can sleep so cannot be used in the interrupt handler. Use GFP_ATOMIC instead. On Sat, 23 Sep 2000 [EMAIL PROTECTED] wrote: > hi! > this is related to previous problem, > when i tried to allocate 64k of physical memory by calling > kmalloc(64*1024-1, GFP_KERNEL), it allocated the memory, also wrote the > memory, but when i read it, it gave Ayeei message, saying interrupt > handlers has been killed..and computer hanged, its kernel-2.2.14-5.0 > what could be the reason?? > > note:please cc the answer > > > - > 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: No sound (es1371) after test7
On 2000-9-23 06:26:27 "H. Peter Anvin" wrote: >With 2.4.0-test9-pre6, I don't get anything (writers on /dev/dsp block >indefinitely) using the es1371 driver, with the following specs: > >es1371: version v0.26 time 21:30:39 Sep 22 2000 >es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08 >es1371: found es1371 rev 8 at io 0xef00 irq 18 >es1371: features: joystick 0x0 >ac97_codec: AC97 audio codec, id: 0x8384:0x7609 (SigmaTel STAC9721/23) I'm running 2.4.0-test9-pre6 with my es1371 sound working just fine. Here is a snippet from messages: kernel: <6>es1371: version v0.26 time 08:02:58 Sep 23 2000 kernel: <6>es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x06 kernel: <6>es1371: found es1371 rev 6 at io 0x1080 irq 11 kernel: <6>es1371: features: joystick 0x0 sound: Loading sound module (es1371) succeeded I also first ran the system with support for es1371 compiled in, and that worked fine too. This is running on sparkling new Linux-Mandrake 7.2 beta 3 distro. One possible glitch with the sound; the mixer on my system was defaulted to zero volume at first, so you obviously have to crank that up to hear anything. Good luck to all. Regards, Steven Cole - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
weird mem crap in test9-pre6
I'd like to start out by saying Rik's latest patch to test8 was working GREAT except that deadlock problem which after 7 days of uptime in X finally occurred. So, I thought, updating to the latest normal kernel should have that and it fixed. Obviously I was wrong. The kernel is displaying either A. the wrong mem usage in ps and /proc/meminfo or B. is totally fucked up in the VM or C. someone decided FULL utilization of all available memory was necessary in linux. Like the pre-rik vm fixes, my kernel is now obviously using a whole lot of swap for no apparant reason except the kernel likes to hurt the hdd. Also i'm getting DMA timeouts again causing infinite ide reset loops (which btw are very cool.. you should try it sometimes *hint* someone make a limit where the system just reboots after so many of these damn things ...i see no reason why it should loop to infinite), anyways, if anyone wants some mem info about this tell me ..i'll paste the contents of /proc/meminfo here ..but i'm not sure what else you'll need to figure out why it's being weird. I'm using linux-2.4.0-test9-pre6 on a pii 300 440lx without DRI and framebuffer but with scsi emu cdrom support. i'm using DMA on one hdd at the moment in hopes it wont timeout ..but i used to be able to use it on both hdd's. This was compiled by gcc-2.95.2 /proc/mtrr: reg00: base=0x ( 0MB), size= 128MB: write-back, count=1 reg01: base=0xec00 (3776MB), size= 32MB: write-combining, count=1 /proc/meminfo: total:used:free: shared: buffers: cached: Mem: 130060288 127926272 21340160 749568 33042432 Swap: 205271040 80523264 124747776 MemTotal: 127012 kB MemFree: 2084 kB MemShared: 0 kB Buffers: 732 kB Cached: 32268 kB Active: 15520 kB Inact_dirty: 7912 kB Inact_clean: 9568 kB Inact_target: 300 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 127012 kB LowFree: 2084 kB SwapTotal: 200460 kB SwapFree: 121824 kB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
problem with kmalloc
hi! this is related to previous problem, when i tried to allocate 64k of physical memory by calling kmalloc(64*1024-1, GFP_KERNEL), it allocated the memory, also wrote the memory, but when i read it, it gave Ayeei message, saying interrupt handlers has been killed..and computer hanged, its kernel-2.2.14-5.0 what could be the reason?? note:please cc the answer - 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] abuse of macros in swab.h
> +static inline __u64 ___swab16(__u64 x)
> +{
> + return (__u64)((x & (__u64)0x00ffULL) << 56) |
> + (__u64)((x & (__u64)0xff00ULL) << 40) |
> + (__u64)((x & (__u64)0x00ffULL) << 24) |
> + (__u64)((x & (__u64)0xff00ULL) << 8) |
> + (__u64)((x & (__u64)0x00ffULL) >> 8) |
> + (__u64)((x & (__u64)0xff00ULL) >> 24) |
> + (__u64)((x & (__u64)0x00ffULL) >> 40) |
> + (__u64)((x & (__u64)0xff00ULL) >> 56);
> +}
And something like this ?
static inline __u64 ___swab16(__u64 x){
__u64 n;
n = (x>>32) | (x<<32);
n = ((n & 0xLL)<<16) | (n & 0xLL)>>16;
n = ((n & 0x00ff00ff00ff00ffLL)<<8) | (n & 0xff00ff00ff00ff00LL)>>8;
return(n);
}
Bye.
-
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 foreign modules - proc_register() gone ?
I'm in the process of migrating my foreign modules to 2.4, and it now appears that proc_register() and proc_unregister() are no longer exported from the kernel. Bug or feature? I know that Linus reserves the right to change interfaces, but I couldn't find any mention in the archives of deleting this, presumably in favor of create_proc_entry(). Or maybe we should just go back to using ioctl()? :) -- Robert - 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: [DOC] Debugging early kernel hangs
On Sat, Sep 23, 2000 at 09:57:38PM +1100, Keith Owens wrote: > On Sat, 23 Sep 2000 12:42:13 +0200, > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > >However, there's still a huge gap between the last progress() message and > >availability of the frame buffer device. The simple console has the > >advantage of outputing existing printk messages. (basically, it's a > >console using prom_printf). > > Something I forgot to mention about debugging using screen writes. If > the problem is caused by incorrect compiler output then even printk can > fail. Not because the C code is wrong but because the generated > assembler is wrong. Writing direct to screen memory is as simple as it > gets and gives the compiler little or no chance to get it wrong. How about the possibility to use architecture specific backends? E.g. my little Alpha machine has an 8-bit debugging LED port that would be very suited for this. Or you could use a parallel port in a similar manner (for those vga-less server machines...). Other machines may have a LED system display for displaying HEX-digits. So when you use an 8-bit value and display it as 2 hex-digits (ok that would be 2 assembler insns instead of one..) this kind of devices could be supported equally well. my 0.02 EUR Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - 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: PROBLEM: Is remap_page_range() working properly?
Thanx for the answer. > You can only remap reserved or I/O space > Read drivers/sound a bit - it has code that allocates, reserves and remaps > memory Oh, now I see why I found so many references to remap_page_range() in sound cards code. But there is still something that seems odd to me: 1) Why using the remap_page_range() to perform the mmap() of /dev/mem ? In this way, as I happened to find out, you can mmap() only the reserved pages of physical memory, when theoretically /dev/mem should grant you access to the whole physical memory in the system; and performing a read() or write() system call on /dev/mem affects even non-reserved pages (I tested the read(), and the code of write() seems to me to behave in the same way). Is there any theoretical reason that suggests that mmap() should not be able to read pages accessible with read() and write()? 2) Wouldn't it be a good idea to change the comment about the remap_page_range()? It states: > maps a range of physical memory into the requested pages. the > old mappings are removed. any references to nonexistent pages > results in null mappings (currently treated as "copy-on-access") There is no reference to the fact that only the reserved pages in physical memory can be mapped. No mention of I/O addresses is present, as well. And no mention that references to non-reserved physical pages will result in null mappings. just my 2c, of course. -Andrea Santoro - [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/
[BUG] test9-pre6: semi-deadlocks
In test9-pre6, when going to compile something - just hit make, gcc kicked in - and grepping, my system came to a semi-deadlock both times. By this I mean that you can switch between vconsoles pretty snappily (this system has no X), but you cannot type at all on those consoles (I think 5 minutes was a pretty adequate timeout). This sucks pretty hard. I tryed SysRq-S(ync), -U(nmount), which printed SysRq: Emergency Sync and SysRq: Emergency Remount R/O respectively, but I didn't get the confirmation messages telling me that it actually worked, even after waiting about a minute. Mercifully, the SysRq reboot works. A belated bug report: My system sits idling, logged out at home, and in test9-pre4, I'd get home to the exact same situation; could've been that 2-hour-idle bug. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - 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/
kmalloc and get_free_pages failure
i tried to allocate physical memory of 128k by calling kmalloc function, passing parameter of (128k-1)bytes, but the computer hanged. when i made it to 32k , the computer rebooted, i am using 2.2.14-5.0 kernel. same was the case with get_free_pages() service.. note:please cc the answer - 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: [DOC] Debugging early kernel hangs
On Sat, 23 Sep 2000 13:02:38 +, Thorsten Kranzkowski <[EMAIL PROTECTED]> wrote: >How about the possibility to use architecture specific backends? E.g. my >little Alpha machine has an 8-bit debugging LED port that would be very suited >for this. You can define VIDEO_CHAR() to do whatever makes sense for your hardware. The only problem with an 8 bit port is you cannot use both "screen" position and value to indicate where you are, you can only use a value. But the same idea holds, whatever works until the console can display output. - 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: Given an image, how can show its config?
Hi! Keith Owens wrote: > > On Sat, 23 Sep 2000 11:33:31 +0200, > Daniel Phillips <[EMAIL PROTECTED]> wrote: > >I'd just like to remind you of Alan Cox's suggestion about appending > >.config.gz to bzImage so that it doesn't get loaded into memory, and > >my suggestion to put System.map.gz there as well. > > I worry about anything that increases the on disk size of bzImage, even > if the extra data does not get loaded into kernel memory. > You also have to consider filesize restrictions with some network bootproms loading the kernel image with TFTP. At least, that feature should be optional! My 0,02 EUR... - andreas -- Andreas Haumer | mailto:[EMAIL PROTECTED] *x Software + Systeme | http://www.xss.co.at/ Karmarschgasse 51/2/20 | Tel: +43-1-6060114-0 A-1100 Vienna, Austria | Fax: +43-1-6060114-71 - 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: Is now possible to mount the same filesystem at multiple mountpoints?
[Alvaro Lopes] > So, I have now the same filesystem mounted in two mountpoints. > > Is this OK ? It used not to be. Yes. Part of Al Viro's vfs overhaul a couple months back. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: interrupt magic
I can't remember anything about protected mode interrupt handlers nor have I ever looked at Linux interrupt handling but at least in real mode from my good old PC/DOS programming days I seem to remember that if you are hooking a hardware interrupt vector then you have to issue a end of interrupt (EOI) to the 8259A interrupt controller (PIC) before doing the iret, for example like so: ; Note: this uses "dst, src" operand ordering not the ; "reversed" ordering used by gcc asm. push ax mov al,20h ; Nonspecific EOI out 20h,al ; Write PIC output control word OCW2 pop ax iret Might this be the problem (or whatever the equivalent specific is in Linux / pmode)? Just my 2p. Regards, Anton At 07:49 23/09/2000, Julien Oster wrote: >Hello, > >I'm currently using 2.4.0-test5 and no APIC. > >I'm trying to learn a bit about protected mode programming on i386 >architectures. > >Looking at the interrupts, the interrupt descriptor table, interrupt gates >and all those things I wanted to experiment a bit to see if I understood >correctly. > >So I wrote the opcode 0xCF (IRET) into the first byte of the interrupt >handler for the keyboard controller (I got the address of the handler >directly from the IDT) and checked if I still have a keyboard. > >No, I had no keyboard, but one thing confused me. After waiting a bit, >I got the kernel complaining about lost interrupts from the harddisk. The >ethernet card said pretty much the same thing. And plugging in an USB >device made the kernel also complain. > >So it seems that I "masked" out a little bit more than the keyboard >interrupt (IRQ 1, entry 0x21 in the IDT). And it happens with _every_ >interrupt I try with: when it gets called once, the kernel fails. > >I did a lot of debugging, read a lot of C and assembler source code... but >I simply can't find what it is that renders the computer in such an >unusable state. > >So... what do interrupt handlers, even the dummy standard ones, do to keep >the system running... and why won't it work without that? > >Thanks, >Julien > > > >- >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/ -- "Education is what remains after one has forgotten everything he learned in school." - Albert Einstein -- Anton Altaparmakov Voice: 01223-333541(lab) / 07712-632205(mobile) Christ's CollegeeMail: [EMAIL PROTECTED] Cambridge CB2 3BUICQ: 8561279 United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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/
alloc_skb called nonatomically from interrupt
Hello people, This is probably nothing important, but I thought I'd post it anyway in case it's of use to somebody. I just checked my syslog and noticed these strange messages: Aug 29 19:05:19 dustpuppy kernel: Unable to handle kernel paging request at virtual address f006f004 Aug 29 19:05:19 dustpuppy kernel: current->tss.cr3 = 03d34000, %cr3 = 03d34000 Aug 29 19:05:19 dustpuppy kernel: *pde = Aug 29 19:05:19 dustpuppy kernel: current->tss.cr3 = 03d34000, %cr3 = 03d34000 Aug 29 19:05:19 dustpuppy kernel: *pde = Aug 29 19:32:49 dustpuppy kernel: alloc_skb called nonatomically from interrupt c0188061 Aug 29 19:32:49 dustpuppy kernel: alloc_skb called nonatomically from interrupt c016d60d I don't recall having any problems with my machine lately, so this puzzels me. The kernel I was running at the time was 2.2.13 (unfortunately I don't have that specific kernel anymore - upgraded to 2.2.17). My hardware is a IBM Thinkpad 600 - 233Mhz Pentium MMX with 64MB RAM. I hope this is usefull to you guys! BTW: Please CC me any replies to this, as I'm not on the list. Best regards, Jesper Juhl [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: Tailmerging for Ext2 - release 0.0
Marc Lehmann wrote: > > On Sat, Sep 16, 2000 at 10:59:54PM +0200, Daniel Phillips ><[EMAIL PROTECTED]> wrote: > > Here we are, finally: code. I do not make any claim that this code is > > elegant, correct, complete, esthetically pleasing or that it will > > refrain from eating your hard disk. > > > > What this code will do is let you verify for yourself whether my > > proposed approach to tailmerging for Ext2 is worth the effort. After > > Well, if ext2 gets some decent directory speed up soon + some journaling > (soon as well ;) then this could be a very viable alternative to reiserfs! Ext2 already has journalling - it's called Ext3. I see that Ingo Molnar has been working on a btree directory extension for Ext2 but I don't know what state it's in. With these three extensions most of Ext2's remaining problems won't hurt much until you get into terabyte filesystems. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x NIC overruns with multicast makes networking freeze
The description of the NICs in question as found in /etc/sysconfig/hwconf are: 3Com Corporation|3c900B-TPO [Etherlink XL TPO] 3Com Corporation|3c905C-TX [Fast Etherlink] In one machine it's the first which is getting lots of overruns; in the other it's the second. Depends on which one is connected to the network with 60% usage. The machines are dual-processor capable, but only a few of them have 2 processors inside. Yes, they're using standard IDE drives. (I've been telling the people at my company we *need* SCSI drives forever... :-P) I don't think the 3c95x driver uses promiscuous mode for multicasting, or does it ? BTW I'm not sure I understand Documentation/networking/multicast.txt. (Is it still up-to-date ?) I suppose IP-MRoute, and thus AllMulti's only relevant for routers while IP-Multicast is relevant for nodes transmitting and receiving multicast. So that means for nodes "hardware filters really help", so we really shouldn't be using 3c59x-drivers, right ? Am I correct that Intel EtherExpress Pro 10/100 cards would be a better choice ? On Sat, Sep 23, 2000 at 03:23:45PM +1100, Andrew Morton wrote: > Arnaud Installe wrote: > > > > Hi, > > > > Has anyone else seen a lot of overruns while serving multicast on a pretty > > loaded (60%) network, with 3c59x cards ? > > This is the first I've heard of it. Which sort of 3com card? > > > (BTW What exactly are > > "overruns" ? Are they buffer overflows on the NIC side or buffer > > overflows on the kernel side, because the software can't follow, or even > > something completely different ?) > > The NIC has an 8 kbyte on-board FIFO, some of which (3-5k) is used for > buffering incoming data. > > An Rx overrun occurs when that on-board FIFO has filled up, and more > data needs to go into it. It shouldn't fill up. This can be caused by > excessive PCI traffic, or by the software not being able to feed the NIC > new Rx buffers fast enough, or by the driver leaving the Rx engine in > the stalled state for too long. Do I understand correctly that those Rx buffers are DMA buffers provided by the kernel ? > You should try the 2.2.17 driver. There's a copy at > http://www.uow.edu.au/~andrewm/linux/3c59x-2.2.17+.gz So it's included in linux-2.2.17.tar.gz, is it ? Is it also included in any of the 2.4.0-test kernels ? > If it still happens (and it probably will) there are some things you can > look at: > > - Get a faster computer! How quick is it? Pentium III 450MHz dual-processor. I thought there might be some locking problem with the SMP code, so I installed a single-processor kernel. Problem didn't go away though. > - Change the driver by doubling the value of RX_RING_SIZE. Keep it a > power of two. This is a bit desperate, but it will give you some more > elasticity. What's the RX_RING_SIZE used for ? > - Make sure the NIC isn't sharing an interrupt with another device. > Look at /proc/interrupts and if it's shared, have a poke in the BIOS. Both NICs have their own IRQ. > - It's also possible that some other device exists on your system which > has a slow interrupt service routine, and is interrupting the 3c59x ISR > for a long time while the Rx engine is stalled. This is a pretty > unlikely scenario. Disabling interrupts around the call to > boomerang_rx() would be slightly interesting. I suppose IDE drives have slow ISRs ? Does unmasking the IRQs for hd's work reliably with most of today's IDE drives and controllers ? The IDE controller is an "Intel Corporation|82371AB PIIX4 IDE". > > After a while the network freezes. I can't ping nor ssh to the machine. > > Restarting the network scripts solves the problem. > > There was a bug in the driver which was fixed 6-8 weeks ago. If the > driver's Rx path completely runs out of memory and cannot allocate a new > buffer 16 times in a row, the receive path gets stuck and the interface > needs to be taken down. Moving to the 2.2.17 driver should eliminate > this possibility. Hmmm... I suppose when this happens it's normal a lot of overruns occur ? Upgrading the driver will make the networking stable, but I suppose that won't prevent a lot of multicast UDP packets from getting dropped, or will it ? (Though unmasking the hd IRQ might.) > You should also try > > echo "512 1024 1536" > /proc/sys/vm/freepages > > to double the amount of memory which is reserved for drivers and such. > This change put a big smile on the face of a 2.2.12 user earlier this > week. (He had 512 megs and a reasonable, but heavy workload. I think > we're setting this too low). Ok. > Please let me know the outcome. I sure will. Thanks, Arnaud -- Arnaud Installe [EMAIL PROTECTED] Administration: An ingenious abstraction in politics, designed to receive the kicks and cuffs due to the premier or president. -- Ambrose Bierce - To unsubscribe from this list: send the line
