Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable
On Mon, 11 Jun 2001, Alan Cox wrote: > "The source code for a work means the preferred form of the work for ^ Preferred by whom? The FSF? Richard Stallman? Hackers in general when they take a vote? Programmers in general? What if the market is full of VB programmers who prefer VB? What if none of them know assembly? They might all vote that assembly isn't a preferred form. If they aren't the ones who count, then who does? Maybe the authors count for more than other people? If so then it does seem they might like to write binaries because they're crazy and they think it's fun or something. I think that the intention of the GPL is clear here but the language is not... > making modifications to it. For an executable work, complete source > code means all the source code for all modules it contains, plus any > associated interface definition files, plus the scripts used to > control compilation and installation of the executable." All of this chunk talks about what ``complete'' means not what ``source code'' means. -Jacob -- This is the moment where the joystick snaps off in Comstock's hand. Still, he can pound haplessly on the control panel. - Neal Stephenson, ``Cryptonomicon'' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable
On Mon, 11 Jun 2001, Alan Cox wrote: The source code for a work means the preferred form of the work for ^ Preferred by whom? The FSF? Richard Stallman? Hackers in general when they take a vote? Programmers in general? What if the market is full of VB programmers who prefer VB? What if none of them know assembly? They might all vote that assembly isn't a preferred form. If they aren't the ones who count, then who does? Maybe the authors count for more than other people? If so then it does seem they might like to write binaries because they're crazy and they think it's fun or something. I think that the intention of the GPL is clear here but the language is not... making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. All of this chunk talks about what ``complete'' means not what ``source code'' means. -Jacob -- This is the moment where the joystick snaps off in Comstock's hand. Still, he can pound haplessly on the control panel. - Neal Stephenson, ``Cryptonomicon'' - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
On Fri, 25 May 2001, Adam J. Richter wrote: > 1 : a group, body, or mass composed of many distinct parts > or individuals > 2 a : the collecting of units or parts into a mass or whole > b : the condition of being so collected > > You have to argue that absolutely nothing more than this > is being done. For example, the code the parts are not working > together. Um. So you mean that if I use a processor with proprietary microcode then I can't run Linux on it? ;-) Seems the argument is about where an arbitrary boundry should be placed and clearly it's not black and white. -Jacob -- At a global level, the most developed countries "stabilize" the wars among the outcasts depending on how important each conflict is to the global economy. - ``The Hacker Ethic'' by Pekka Himanen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
On Fri, 25 May 2001, Adam J. Richter wrote: 1 : a group, body, or mass composed of many distinct parts or individuals 2 a : the collecting of units or parts into a mass or whole b : the condition of being so collected You have to argue that absolutely nothing more than this is being done. For example, the code the parts are not working together. Um. So you mean that if I use a processor with proprietary microcode then I can't run Linux on it? ;-) Seems the argument is about where an arbitrary boundry should be placed and clearly it's not black and white. -Jacob -- At a global level, the most developed countries stabilize the wars among the outcasts depending on how important each conflict is to the global economy. - ``The Hacker Ethic'' by Pekka Himanen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 del_timer_sync oops in schedule_timeout
On Mon, 21 May 2001, Andrew Morton wrote:
> It could be timer-list corruption. Someone released some memory
> which had a live timer in it. The memory got recycled and then
> the timer list traversal fell over it.
Well I do have another oops now (artsd this time). Once again it's in
del_timer_sync in 2.4.4, same computer after a reboot, same kernel. It is
a UP system (SMP kernel) btw.
Could it be that the aic7xxx driver is improperly destroying a timer? I
am having some problems with a scanner attached to the SCSI card in
question that usually result in the driver setting the scanner inactive
until I reset the scanner and rmmod/insmod the driver again.
Unable to handle kernel paging request at virtual address 2d5ca71f
printing eip:
c011bf13
*pde =
Oops: 0002
CPU:0
EIP:0010:[del_timer_sync+47/132]
EFLAGS: 00013006
eax: a2e17a6a ebx: 3246 ecx: c4047f28 edx: 2d5ca71b
esi: edi: 0010 ebp: c4045f3c esp: c4045f0c
ds: 0018 es: 0018 ss: 0018
Process artsd (pid: 2873, stackpage=c4045000)
Stack: c4047f28 0061afd0 c0112b54 c4047f28 c4045f28 c78143e0
0061afd0 c4044000 c0112a80 c4045f70 c0140b7c 0001 0004
c305c9d8 0304 c4044000 0014 0005
Call Trace: [schedule_timeout+120/144] [process_timeout+0/92]
[do_select+456/512] [sys_select+816/1136] [system_call+55/64]
Code: 89 42 04 89 10 b8 01 00 00 00 01 c6 a1 68 20 30 c0 c7 41 04
-Jacob
--
At a global level, the most developed countries "stabilize" the wars
among the outcasts depending on how important each conflict is to the
global economy.
- ``The Hacker Ethic'' by Pekka Himanen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 del_timer_sync oops in schedule_timeout
On Mon, 21 May 2001, Andrew Morton wrote:
It could be timer-list corruption. Someone released some memory
which had a live timer in it. The memory got recycled and then
the timer list traversal fell over it.
Well I do have another oops now (artsd this time). Once again it's in
del_timer_sync in 2.4.4, same computer after a reboot, same kernel. It is
a UP system (SMP kernel) btw.
Could it be that the aic7xxx driver is improperly destroying a timer? I
am having some problems with a scanner attached to the SCSI card in
question that usually result in the driver setting the scanner inactive
until I reset the scanner and rmmod/insmod the driver again.
Unable to handle kernel paging request at virtual address 2d5ca71f
printing eip:
c011bf13
*pde =
Oops: 0002
CPU:0
EIP:0010:[del_timer_sync+47/132]
EFLAGS: 00013006
eax: a2e17a6a ebx: 3246 ecx: c4047f28 edx: 2d5ca71b
esi: edi: 0010 ebp: c4045f3c esp: c4045f0c
ds: 0018 es: 0018 ss: 0018
Process artsd (pid: 2873, stackpage=c4045000)
Stack: c4047f28 0061afd0 c0112b54 c4047f28 c4045f28 c78143e0
0061afd0 c4044000 c0112a80 c4045f70 c0140b7c 0001 0004
c305c9d8 0304 c4044000 0014 0005
Call Trace: [schedule_timeout+120/144] [process_timeout+0/92]
[do_select+456/512] [sys_select+816/1136] [system_call+55/64]
Code: 89 42 04 89 10 b8 01 00 00 00 01 c6 a1 68 20 30 c0 c7 41 04
-Jacob
--
At a global level, the most developed countries stabilize the wars
among the outcasts depending on how important each conflict is to the
global economy.
- ``The Hacker Ethic'' by Pekka Himanen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 del_timer_sync oops in schedule_timeout
On Sun, 20 May 2001, Ingo Molnar wrote: > > Unable to handle kernel paging request at virtual address 78626970 > this appears to be some sort of DMA-corruption or other memory scribble > problem. hexa 78626970 is ASCII "pibx", which shows in the direction of > some sort of disk-related DMA corruption. > we havent had any similar crash in del_timer_sync() for ages. Ahh. Thanks then, I'll go look hard at the disk in that box. :) -Jacob -- Only when work uses up all energy and people are too tired to enjoy the persuit of their passions are they ready to be reduced to the passively receptive state suitable for television. - ``The Hacker Ethic'' by Pekka Himanen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 del_timer_sync oops in schedule_timeout
On Sun, 20 May 2001, Ingo Molnar wrote: Unable to handle kernel paging request at virtual address 78626970 this appears to be some sort of DMA-corruption or other memory scribble problem. hexa 78626970 is ASCII pibx, which shows in the direction of some sort of disk-related DMA corruption. we havent had any similar crash in del_timer_sync() for ages. Ahh. Thanks then, I'll go look hard at the disk in that box. :) -Jacob -- Only when work uses up all energy and people are too tired to enjoy the persuit of their passions are they ready to be reduced to the passively receptive state suitable for television. - ``The Hacker Ethic'' by Pekka Himanen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4 del_timer_sync oops in schedule_timeout
This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in. The oops got eaten by klogd, my apologies, but it seems sane even so. I haven't tried newer -ac or -pre kernels so I'm sure it's probably already fixed there but just in case it isn't... kdm[350]: Server for display :0 terminated unexpectedly: 2816 Unable to handle kernel paging request at virtual address 78626970 printing eip: c011bf13 *pde = Oops: 0002 CPU:0 EIP:0010:[del_timer_sync+47/132] EFLAGS: 00010006 eax: 732e7872 ebx: 0246 ecx: c651ff28 edx: 7862696c esi: edi: 0010 ebp: c651df3c esp: c651df0c ds: 0018 es: 0018 ss: 0018 Process XFree86 (pid: 356, stackpage=c651d000) Stack: c651ff28 0007edbb c0112b54 c651ff28 c651df28 c3b45260 c02ec12c c02ec12c 0007edbb c651c000 c0112a80 c651df70 c0140b7c 0008 0020 c7aea140 0304 c651c000 2d24 0015 Call Trace: [schedule_timeout+120/144] [process_timeout+0/92] [do_select+456/512] [sys_select+816/1136] [system_call+55/64] Code: 89 42 04 89 10 b8 01 00 00 00 01 c6 a1 68 20 30 c0 c7 41 04 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4 del_timer_sync oops in schedule_timeout
This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in. The oops got eaten by klogd, my apologies, but it seems sane even so. I haven't tried newer -ac or -pre kernels so I'm sure it's probably already fixed there but just in case it isn't... kdm[350]: Server for display :0 terminated unexpectedly: 2816 Unable to handle kernel paging request at virtual address 78626970 printing eip: c011bf13 *pde = Oops: 0002 CPU:0 EIP:0010:[del_timer_sync+47/132] EFLAGS: 00010006 eax: 732e7872 ebx: 0246 ecx: c651ff28 edx: 7862696c esi: edi: 0010 ebp: c651df3c esp: c651df0c ds: 0018 es: 0018 ss: 0018 Process XFree86 (pid: 356, stackpage=c651d000) Stack: c651ff28 0007edbb c0112b54 c651ff28 c651df28 c3b45260 c02ec12c c02ec12c 0007edbb c651c000 c0112a80 c651df70 c0140b7c 0008 0020 c7aea140 0304 c651c000 2d24 0015 Call Trace: [schedule_timeout+120/144] [process_timeout+0/92] [do_select+456/512] [sys_select+816/1136] [system_call+55/64] Code: 89 42 04 89 10 b8 01 00 00 00 01 c6 a1 68 20 30 c0 c7 41 04 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tulip driver broken in 2.4.4?
Well, I guess I should chip in here with the rather amusing fact that 2.4.4 is the first kernel *not* to do this to me... ;-) I am, of course, glad to help out testing stuff if needed. My card is also a LinkSys LNE100TX v4.1, which the tulip driver identifies as an ADMtek Comet rev 17 (although somebody told me it's really a Centaur). -Jacob On Tue, 1 May 2001, Ronny Haryanto wrote: > On 01-May-2001, Jeff Garzik wrote: > > Ronny Haryanto wrote: > > > > > > Just tried 2.4.4 yesterday and found that my eth1 was dead after 5 minutes. > > > > Does 2.4.3 work for you? > > Yes. I just tried 2.4.3, and it works fine. So it looks like there's a bug > introduced between 2.4.3 and 2.4.4. Too bad I can't use 2.4.3; I need 2.4.4 > due to the VIA chipset bug. Is there any other info that I could provide > from here to help debugging? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tulip driver broken in 2.4.4?
Well, I guess I should chip in here with the rather amusing fact that 2.4.4 is the first kernel *not* to do this to me... ;-) I am, of course, glad to help out testing stuff if needed. My card is also a LinkSys LNE100TX v4.1, which the tulip driver identifies as an ADMtek Comet rev 17 (although somebody told me it's really a Centaur). -Jacob On Tue, 1 May 2001, Ronny Haryanto wrote: On 01-May-2001, Jeff Garzik wrote: Ronny Haryanto wrote: Just tried 2.4.4 yesterday and found that my eth1 was dead after 5 minutes. Does 2.4.3 work for you? Yes. I just tried 2.4.3, and it works fine. So it looks like there's a bug introduced between 2.4.3 and 2.4.4. Too bad I can't use 2.4.3; I need 2.4.4 due to the VIA chipset bug. Is there any other info that I could provide from here to help debugging? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
use the kernel to change an irq?
Oh Great Gurus: I have an agp video card that seems quite picky about interrupts, and a bios that is insisting on sharing the video card's interrupt with whatever is in the first pci slot. So my question is, is there any way for the kernel to more or less say ``screw you'' to the bios and pick the irq for the video card itself? I have a spare irq I'd love for it to use... Oh, almost forgot: Yes, I'd just vacate the pci slot below the video card, but sadly all my pci slots are in use. :( Ok, I'll admit the card is an nVidia card and I'm trying to use the (evil) binary drivers. But note I'm *not* asking for help with that directly. I'm merely asking if there's a way to avoid sharing the interrupt... Thanks Muchly, -Jacob -- The authoritarian attitude has to be fought wherever you find it, lest it smother you and other hackers. - Eric S. Raymond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
use the kernel to change an irq?
Oh Great Gurus: I have an agp video card that seems quite picky about interrupts, and a bios that is insisting on sharing the video card's interrupt with whatever is in the first pci slot. So my question is, is there any way for the kernel to more or less say ``screw you'' to the bios and pick the irq for the video card itself? I have a spare irq I'd love for it to use... Oh, almost forgot: Yes, I'd just vacate the pci slot below the video card, but sadly all my pci slots are in use. :( Ok, I'll admit the card is an nVidia card and I'm trying to use the (evil) binary drivers. But note I'm *not* asking for help with that directly. I'm merely asking if there's a way to avoid sharing the interrupt... Thanks Muchly, -Jacob -- The authoritarian attitude has to be fought wherever you find it, lest it smother you and other hackers. - Eric S. Raymond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
> Speaking as a Linux _USER_, if this happens, can I get said print > engine working on my ARM machines with these closed source drivers? > Can Alpha users get this print system working? Can Sparc uses > get it working? What? I can't? They can't? Well, its no good to > me nor them. You've just made the system x86 specific. Well done, > thats a step backwards, not forwards. Just out of curiosity, why can't the specification be along the lines of a vendor data file saying ``if you want the printer to do x then say y'' and ``if the printer says x then it means y''. That ought to add a lot of functionality right there. Sure there are evil winprinters that this wouldn't be enough for but it would be hardware independant, yes? Or alternatively what about getting vendors to release their source to a middleman as a trade secret? The middleman could then release binaries for the various arches... Distasteful, but I'd love to be able to use *all* the features of my Lexmark OptraColor 45... ;) -Jacob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Speaking as a Linux _USER_, if this happens, can I get said print engine working on my ARM machines with these closed source drivers? Can Alpha users get this print system working? Can Sparc uses get it working? What? I can't? They can't? Well, its no good to me nor them. You've just made the system x86 specific. Well done, thats a step backwards, not forwards. Just out of curiosity, why can't the specification be along the lines of a vendor data file saying ``if you want the printer to do x then say y'' and ``if the printer says x then it means y''. That ought to add a lot of functionality right there. Sure there are evil winprinters that this wouldn't be enough for but it would be hardware independant, yes? Or alternatively what about getting vendors to release their source to a middleman as a trade secret? The middleman could then release binaries for the various arches... Distasteful, but I'd love to be able to use *all* the features of my Lexmark OptraColor 45... ;) -Jacob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdd: set_drive_speed_status: status=0x51 { DriveReady SeekCompleteError }
I gave it a whirl. Sadly, no change. On Sat, 27 Jan 2001, Jens Axboe wrote: > My gut tells me that this is the 'get last written' command, and even > with the quiet flag we get the IDE error status printed. Could you > try and add > > goto use_toc; > > add the top of drivers/cdrom/cdrom.c:cdrom_get_last_written() and > see if that makes the error disappear? -Jacob -- Reechani, Sentrosi, Vasi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
hdd: set_drive_speed_status: status=0x51 { DriveReady SeekCompleteError }
I've been getting this during the boot sequence for quite some time now.
They don't seem to impact the functionality of the drive any though. Just
another extra-verbose kernel message I should ignore? :)
(This is from the 2.4.1-pre10 btw.)
hdd: CD-ROM TW 120D, ATAPI CD/DVD-ROM drive
hdd: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdd: set_drive_speed_status: error=0x04
[...]
hdd: ATAPI 12X CD-ROM drive, 240kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
-Jacob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
hdd: set_drive_speed_status: status=0x51 { DriveReady SeekCompleteError }
I've been getting this during the boot sequence for quite some time now.
They don't seem to impact the functionality of the drive any though. Just
another extra-verbose kernel message I should ignore? :)
(This is from the 2.4.1-pre10 btw.)
hdd: CD-ROM TW 120D, ATAPI CD/DVD-ROM drive
hdd: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdd: set_drive_speed_status: error=0x04
[...]
hdd: ATAPI 12X CD-ROM drive, 240kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
-Jacob
-
To unsubscribe from this list: send 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: hdd: set_drive_speed_status: status=0x51 { DriveReady SeekCompleteError }
I gave it a whirl. Sadly, no change. On Sat, 27 Jan 2001, Jens Axboe wrote: My gut tells me that this is the 'get last written' command, and even with the quiet flag we get the IDE error status printed. Could you try and add goto use_toc; add the top of drivers/cdrom/cdrom.c:cdrom_get_last_written() and see if that makes the error disappear? -Jacob -- Reechani, Sentrosi, Vasi - To unsubscribe from this list: send 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: test-10 tulip "eth0 timed out" (smp, heavy IDE use)
> > Linksys LNE version 4, 00:0d.0 Ethernet controller: Bridgecom, Inc: > > Unknown device 0985 (rev 11) [...] > > Nov 28 04:04:52 twoey kernel: NETDEV WATCHDOG: eth0: transmit timed out > > Nov 28 04:04:52 twoey kernel: eth0: Transmit timed out, status fc664010, > > CSR12 , resetting... I can replicate this message any day you want. It seems that this card is perhaps a bit too sensitive to high interrupt latencies or something to that effect. Dan Hollis worked on my box for several days and we found that the problem tends to trigger (in my case) when nfs is in use. But I still haven't had time to explore further. :( Dan tells me the chip in question is a Centaur so I presume eventually kernels will identify it correctly once somebody adds it to the list. :) -Jacob -- " ... mutant DEC .au files ... " -http://ocean.hhardy.net/ftp/systems/linux/snd/Lsox/Sox/ [1999.09.22 - sorry, link is dead nowadays] - To unsubscribe from this list: send 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: test-10 tulip eth0 timed out (smp, heavy IDE use)
Linksys LNE version 4, 00:0d.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11) [...] Nov 28 04:04:52 twoey kernel: NETDEV WATCHDOG: eth0: transmit timed out Nov 28 04:04:52 twoey kernel: eth0: Transmit timed out, status fc664010, CSR12 , resetting... I can replicate this message any day you want. It seems that this card is perhaps a bit too sensitive to high interrupt latencies or something to that effect. Dan Hollis worked on my box for several days and we found that the problem tends to trigger (in my case) when nfs is in use. But I still haven't had time to explore further. :( Dan tells me the chip in question is a Centaur so I presume eventually kernels will identify it correctly once somebody adds it to the list. :) -Jacob -- " ... mutant DEC .au files ... " -http://ocean.hhardy.net/ftp/systems/linux/snd/Lsox/Sox/ [1999.09.22 - sorry, link is dead nowadays] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (2.4)] atomic use count for proc_dir_entry
On Fri, 17 Nov 2000, Dan Aloni wrote: > If you are right, I guess put_files_struct() of kernel/exit.c would > have cleaned files_struct everytime someones called it. > Everywhere in the kernel, objects are freed when > atomic_dec_and_test() returns true. Indeed, after studying the asm in question I think I see how it ticks. What is the reasoning behind reversing the result of the test instead of returning the new value of the counter? (Thanks for taking time to set me straight on this. :) -Jacob -- Why you say you no bunny rabbit when you have little powder-puff tail? -- The Tasmanian Devil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (2.4)] atomic use count for proc_dir_entry
On Fri, 17 Nov 2000, Dan Aloni wrote: If you are right, I guess put_files_struct() of kernel/exit.c would have cleaned files_struct everytime someones called it. Everywhere in the kernel, objects are freed when atomic_dec_and_test() returns true. Indeed, after studying the asm in question I think I see how it ticks. What is the reasoning behind reversing the result of the test instead of returning the new value of the counter? (Thanks for taking time to set me straight on this. :) -Jacob -- Why you say you no bunny rabbit when you have little powder-puff tail? -- The Tasmanian Devil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (2.4)] atomic use count for proc_dir_entry
I'm not (yet) a kernel guru, so just point and laugh if I'm wrong, but...
On Thu, 16 Nov 2000, Dan Aloni wrote:
> - if (!--de->count) {
> + if (atomic_dec_and_test(>count)) {
Doesn't this reverse the sense of the test?
-Jacob
--
"My my, the cruelest lies are often told without a word.
My my, the kindest truths are often spoke, but never heard."
-Ben Folds Five, "The Last Polka"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (2.4)] atomic use count for proc_dir_entry
I'm not (yet) a kernel guru, so just point and laugh if I'm wrong, but...
On Thu, 16 Nov 2000, Dan Aloni wrote:
- if (!--de-count) {
+ if (atomic_dec_and_test(de-count)) {
Doesn't this reverse the sense of the test?
-Jacob
--
"My my, the cruelest lies are often told without a word.
My my, the kindest truths are often spoke, but never heard."
-Ben Folds Five, "The Last Polka"
-
To unsubscribe from this list: send 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 BUG at page_alloc.c:176, 2.4.0test9pre7
This bug, which I posted about earlier tonight, appears to be resolved by Rik van Riel's latest vm patch (www.surriel.com/patches/2.4.0-t9p7-vmpatch) although I can't be certain. But prior to the patch I could trigger the BUG quite easily with a kernel compile or such and I have been compiling kernels since it came out with no more BUGs. Thanks, Rik... -Jacob -- 847.63 -The Simpsons - To unsubscribe from this list: send 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 BUG at page_alloc.c:176, 2.4.0test9pre7
This bug, which I posted about earlier tonight, appears to be resolved by Rik van Riel's latest vm patch (www.surriel.com/patches/2.4.0-t9p7-vmpatch) although I can't be certain. But prior to the patch I could trigger the BUG quite easily with a kernel compile or such and I have been compiling kernels since it came out with no more BUGs. Thanks, Rik... -Jacob -- 847.63 -The Simpsons - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
