On Fri, Nov 17, 2000 at 11:25:50PM -0800, Ben Ford wrote:
> Here is lspci output from the laptop in question. Is this not UHCI?
Yes it is. Just a bit funny if you think about it, but with Intel and
Via putting the UHCI core into their chipsets I guess it makes sense.
One note for the archives,
Hello,
On Thu, Nov 16, 2000 at 09:28:44AM -0500, Admin Mailing Lists wrote:
> Was running 2.2.15pre18 with no eepro problems.
> Upgraded to 2.2.18pre20 and started experiencing transmit timed out errors
> a day into the boot. eth0 was unresponsive in/out. down/uping the
> interface had no effect.
Linus Torvalds wrote:
>
> I sure as hell hope this isn't an Athlon issue. Can other people try
> the test-program and see if we have a pattern (ie "it happens only on
> Athlons", or "Linus is on drugs and it happens for everybody else").
I've tried both variants (fesetenv and inline-asm) with g
On Sat, 18 Nov 2000 00:15:35 -0500,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>What is the difference between a module that exports no symbols and
>includes EXPORT_NO_SYMBOLS reference, and such a module that lacks
>EXPORT_NO_SYMBOLS?
When modules were first introduced, all symbols were automatical
Here is lspci output from the laptop in question. Is this not UHCI?
[ben@Juanita ben]$ /sbin/lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corporati
On 17 Nov 2000, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> =?iso-8859-1?q?Markus=20Schoder?= <[EMAIL PROTECTED]> wrote:
> >The following small program (linked against glibc 2.1.3) reliably
> >freezes my system (Athlon Thunderbird CPU) with at least kernels
> >2.4.0-test10 and 2.
Greg KH wrote:
>
> On Fri, Nov 17, 2000 at 09:27:19PM -0800, David Ford wrote:
> >
> > The second issue is usb. I now have two machines that lockup on boot in USB.
> > One is the above workstation, the second is a Compaq laptop. Unfortunately
> > I have no way of unplugging the USB hardware ins
Fixes osb4 ServerWorks ATA-33
TaskfileNative.
Only because I needed this for Ute-Linux Distro, did I feel obligated to
push and do a backport to 2.2.17
Additionally DiskPerf-1.0 is available.
DO NOT ENABLE WRITE MODE OF TESTS
DESTRUCTIVE TESTS!!
IT IS CONFIGURED FOR READO
On Fri, Nov 17, 2000 at 09:27:19PM -0800, David Ford wrote:
>
> The second issue is usb. I now have two machines that lockup on boot in USB.
> One is the above workstation, the second is a Compaq laptop. Unfortunately
> I have no way of unplugging the USB hardware inside the laptop :P
Can't yo
Dear Linus,
I haven't seen any announcements of recent test and test-pre releases.
Can you begin sending those again, please?
Best wishes,
Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ a
"Adam J. Richter" wrote:
> Hello Alan,
>
> Jeff Garzik tells me that you, with some help from some other
> kernel developers, are hacking on the sound drivers right now. I
> would like to add PCI MODULE_DEVICE_TABLE entries to three of
> the four PCI sound drivers: cmpci, cs46xx and nm25
I tried sending this to Alan Cox, but his mailer complained
that we are connected via AboveNet, which blocks ORBS (which is true,
and which I have complained about to our ISP many times). It is
primary intended for Alan, but anyone else who wants to chime in
is welcome to.
Adam
---
In article <[EMAIL PROTECTED]>,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>Also, somewhere on the path from kernel 2.2 to 2.4 the call to
>do_notify_parent() was moved inside the tasklist lock. Why was this?
Ehh.. Because that is also what protects our "parent" pointer.
Linus
> > The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
> > difficult because the lockups appear to be kdb-specific (and kdb itself
[...]
> It could be that -test5 and -test6 break some assumption kdb makes.
> It has been eminently stable here.
Whether or not the assumptio
What is the difference between a module that exports no symbols and
includes EXPORT_NO_SYMBOLS reference, and such a module that lacks
EXPORT_NO_SYMBOLS?
Alan once upbraided me for assuming they were the same :)
--
Jeff Garzik |
Building 1024 | The chief enemy of creativit
On Sat, 18 Nov 2000, Keith Owens wrote:
> On Fri, 17 Nov 2000 17:21:53 -0800 (PST),
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >There's a test11-pre7 there now, and I'd really ask people to check out
> >the isofs changes because slight worry about those is what held me up from
> >just calli
On Fri, 17 Nov 2000 20:00:49 + (GMT),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
>difficult because the lockups appear to be kdb-specific (and kdb itself
>goes mad) but when there is no kdb there is very little useful
On Fri, 17 Nov 2000 17:21:53 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>There's a test11-pre7 there now, and I'd really ask people to check out
>the isofs changes because slight worry about those is what held me up from
>just calling it test11 outright.
>
>It's almost guaranteed to b
This is an update from the main DRM tree, but with cosmetic changes
removed and only meat left. This patch is already in VA's shipping
kernel, so you know we really trust it. :-,
BTW, this patch is not fluff: It includes bug fixes. But it's pretty
big, so if you want to wait until 2.2.19 I'll
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?q?Markus=20Schoder?= <[EMAIL PROTECTED]> wrote:
>The following small program (linked against glibc 2.1.3) reliably
>freezes my system (Athlon Thunderbird CPU) with at least kernels
>2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work
>
The call to disassociate_ctty() in exit_notify() is very dangerous. If
disassociate_ctty() calls schedule() then either:
- a parent process who is spinning in fork.c:release() will stop
spinning and will proceed to deallocate the child process's kernel
stack. This will probably have advers
This patch modestly improves the scalability and straight-line
performance of x86 semaphores by removing the semaphore_lock and using
the per-semaphore lock instead. If removes several spinlock operations
and allows concurrent operations on separate semaphores.
No bugs were harmed in the prepar
This patch removes tq_scheduler from the kernel. All uses of
tq_scheduler are migrated over to use schedule_task().
Notes:
- In two places: drivers/block/paride/pseudo.h and
drivers/net/wan/sdlamain.c we are re-adding tasks to tq_scheduler
within the callback. That means that these functi
[ Sorry - the last one was bogus test11-pre4 stuff ]
Linus,
this patch removes the final things which can cause oopses and other
sad events to deadlock without providing diagnostics.
I've changed it a little since Ingo provided comments - the
poke_blanked_console() changes have been simplified.
Linus,
patch removes the last deadlock opportunity in the x86 oops and
NMI oopser path, namely the call to wake_up_interruptible()
within printk itself. (Apart from vga_lock, which isn't
worth the fuss).
bust_spinlocks() disappears again in favour of a global integer
`oops_in_progress'.
I've o
Linus,
There is an SMP race on process exit.
The exitting process sets TASK_ZOMBIE and calles schedule(). The next
task to run clears the exitting tasks's task_struct.has_cpu in
__schedule_tail. At this point in time the parent, which may be
spinning in fork.c:release() is free to go ahead and
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?q?Markus=20Schoder?= <[EMAIL PROTECTED]> wrote:
>The following small program (linked against glibc 2.1.3) reliably
>freezes my system (Athlon Thunderbird CPU) with at least kernels
>2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work
>
In article <[EMAIL PROTECTED]>, J Sloan <[EMAIL PROTECTED]> wrote:
>
>looks like the md fixes broke something -
>
>In file included from /usr/src/linux/include/linux/pagemap.h:17,
> from /usr/src/linux/include/linux/locks.h:9,
> from /usr/src/linux/include/linux/ra
In article <[EMAIL PROTECTED]> you wrote:
> Sorry, ignoring some values of timestamp is simply impossible.
> It is PAWS. One packet is more than enough to kill you. 8)
Hmm... Isnt this only important for the first SYN with a Zero Timestamp
which is not very critical for PAWS?
Greetings
Bernd
-
T
In article <[EMAIL PROTECTED]> you wrote:
> Timestamp is not a random number, so that probability of PAWS failure
> does not depend on restricting it at all. The only thing which can help
> to reduce probability is dropping all tpacket with ts_val==0
> or shutting down your machine while time of y
In article <[EMAIL PROTECTED]> you wrote:
> But also scalability: 2TB is a problem for me in some cases, 32bit just don't
> cut it all the time - but I need to circumvent the storage problem even on a
> 32bit system. And adding disks to the system while running is desireable.
Why do you run 32bit
Hi everyone.
When compiling Andreas aa2 patch I got:
/usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-O4 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe
-fno-strength-reduce -march=i686 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=686 -c -o
I wrote:
>[...] the cost of incorrectly
>using __initdata when __devinitdata was correct is that the user's
>KERNEL WILL CRASH when the notebook is inserted or removed from such a
>docking station, even when the kernel is built with CONFIG_HOTPLUG.
My statement above, without some missin
Followup to: <[EMAIL PROTECTED]>
By author:Olivier Galibert <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> What guarantees you that:
> 1- No device will respond 0x for an address it decodes
> 2- No device will crap up on you simply because you've read one
> particular address
>
On 18 Nov 2000, Nix wrote:
> Alexander Viro <[EMAIL PROTECTED]> writes:
>
> > If every way from foo to target goes through the source rename(source,target)
> > _will_ make the graph disconnected. Checking that for generic DAG is a hell.
>
> Why do you say this? Algorithms for cycle detection
Alexander Viro <[EMAIL PROTECTED]> writes:
> If every way from foo to target goes through the source rename(source,target)
> _will_ make the graph disconnected. Checking that for generic DAG is a hell.
Why do you say this? Algorithms for cycle detection are comparatively
computationally expensiv
>I am willing to consider adding __devxxx only when other __devxxx
>entries already exist.
>These conversions to _devxxx are too late in the freeze, and only have
>value for isolated cases --which you admit you don't even know exist--.
>Linus Rule 1: Don't overdesign.
Even ignoring Card
Peter Samuelson <[EMAIL PROTECTED]> writes:
> Two easy "get out of jail free" cards. There are other, more complex
> exploits. You have added one more. They all require root privileges.
Unless I'm missing something, not all of them do. I haven't checked this
or anything, but it seems to me th
The following small program (linked against glibc
2.1.3) reliably
freezes my system (Athlon Thunderbird CPU) with at
least kernels
2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq
keys do not work
after the freeze.
Older kernels (e.g. 2.3.40) seem to work. Any Ideas?
Just a quick heads-up -
looks like the md fixes broke something -
In file included from /usr/src/linux/include/linux/pagemap.h:17,
from /usr/src/linux/include/linux/locks.h:9,
from /usr/src/linux/include/linux/raid/md.h:37,
from init/main.c:25:
On Fri, 17 Nov 2000, Jeff V. Merkey wrote:
>
> This is probably a configuration mismatch of some kind, but I just
> finished building my 2.4.0 RPM skeletons and am installting them from
> our latest CD burn, and I am seeing the following
> problem when I upgrade our 2.2.17 kernel versio
We dfound it. 2.2.X .configs are incompatible with 2.4.0 and the
upgrade RPMs sucked them in. Since IDE is a unique CONFIG option, this
will break.
Jeff
"Jeff V. Merkey" wrote:
>
>
> This is probably a configuration mismatch of some kind, but I just
> finished building my 2.4.0 RPM skelet
Daniel Phillips <[EMAIL PROTECTED]> writes:
> Actually, I was planning on doing on putting in a hack to do something
> like that: calculate a checksum after every buffer data update and check
> it after write completion, to make sure nothing scribbled in the buffer
> in the interim. This would a
Patch against test11-pre6
- Converts struct video_device to named initializers
- Fixes radio-maestro init
- Removes superfluous initialize functions (those that just return 0)
--
Brian Gerst
diff -urN linux-2.4.0t11p6/drivers/media/radio/radio-a
There's a test11-pre7 there now, and I'd really ask people to check out
the isofs changes because slight worry about those is what held me up from
just calling it test11 outright.
It's almost guaranteed to be better than what we had before, but anyway..
Linus
-
To unsubscribe
On Fri, Nov 17, 2000 at 03:27:28PM -0500, Richard B. Johnson wrote:
> Then, you read the port as a WORD (16 bits). If nothing responds,
> you get the value of 0x. If somebody is responding, you will
> read something if it's enabled for writes by devices (reads by the CPU).
What guarantees you
On Fri, 17 Nov 2000 14:49:38 Rasmus Andersen wrote:
> Hi.
>
> I get an oops reproducably with 2.2.17 and 2.2.18pre21 on a stock RH 6.2
> system. I cannot trigger it with the RH supplied kernel (2.2.14-5.0).
> I also got it with 2.2.17pre10 which prompted me to upgrade the kernel.
> I initially s
This is probably a configuration mismatch of some kind, but I just
finished building my 2.4.0 RPM skeletons and am installting them from
our latest CD burn, and I am seeing the following
problem when I upgrade our 2.2.17 kernel versions with 2.4.0-test10,
then reboot them under 2.4:
req
Hi Linus et al,
I've applied your semaphore fairness patch (slightly fixed) below. It
fixes my original bug report of vmstat, ps etc. stalls waiting for the
mmap_sem. I can now run my memory 'hog' processes and actually see
vmstat update every second even under heavy memory pressure. More
impo
On Fri, 17 Nov 2000 20:00:49 + (GMT),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
>difficult because the lockups appear to be kdb-specific (and kdb itself
>goes mad) but when there is no kdb there is very little useful
>> I take it you'll also do the third part?
> Are you talking about isofs_lookup_grandparent()?
No, about isofs_read_inode.
Andries
-
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/l
On Fri, Nov 17, 2000 at 03:59:13PM -0800, H . J . Lu wrote:
> # gcc x.c
> # ./a.out
> lseek on -10: -10
> write: File too large
>
> Should kernel allow negative offsets for lseek/llseek?
>
>
Never mind. I was running the wrong kernel.
H.J.
-
To unsubscribe from this list: send the lin
# gcc x.c
# ./a.out
lseek on -10: -10
write: File too large
Should kernel allow negative offsets for lseek/llseek?
--
H.J. Lu ([EMAIL PROTECTED])
---
#include
#include
#include
extern loff_t llseek (int fd, loff_t offset, int whence);
int
main ()
{
int fd = open ("/tmp/foo.out",
Oh, and sorry - the last patch doesn't contain the (obvious) fixes to the
header files to take some of the calling convention changes into account.
Linus
---
--- v2.4.0-test10/linux/include/linux/iso_fs.h Fri Sep 8 12:52:56 2000
+++ linux/include/linux/iso_fs.hFri No
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote:
>
> But now that you did two-thirds of the job I take it you'll
> also do the third part? It is again precisely the same stuff.
Are you talking about isofs_lookup_grandparent()?
The code is now dead, and has been for a long time actually (as the VF
> Some clues here
> ... escd.html ... escd.rtf
Thanks! I already had the former (but it refers to the EISA
spec for most details) will look for the latter.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
On Fri, 17 Nov 2000, Harald Koenig wrote:
>
> Linus:0.380u 76.850s 1:19.12 97.6%0+0k 0+0io 113pf+0w
> Andries: 0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
The biggest difference is just the system times and the fact that it's
more efficient coding.
> BUT: the
Linus:
> How about this version (full patch against test10 - it includes a
> slightly corrected version of my earlier dir.c patch)?
> It's entirely untested, but it looks good and compiles. Ship it!
There are three files that have to be changed.
You changed dir.c yesterday, and namei.c today
bu
> My code does something like
>
> /*
> * EISA board N has a 4-byte ID that can be read from 0xNc80-0xNc83
> * return 0 for success, -1 for failure (no EISA card in slot) and
> * 1 when a card is present but still needs to be configured.
> */
> static int
> get_eisa_id(int board, char *id) {
Hello,
this fixes some typos and pathnames in pointers from Configure.help to
files in the Documentation subtree.
Not much, but better than nothing.
Diff is against 2.4.0-test10.
Matthias
--- Documentation/Configure.help.orig Sat Nov 18 00:14:01 2000
+++ Documentation/Configure.helpF
Hello,
this fixes some typos and pathnames in pointers from Configure.help to
files in the Documentation subtree.
Not much, but better than nothing.
Matthias
--- Documentation/Configure.help.orig Sat Nov 18 00:14:01 2000
+++ Documentation/Configure.helpFri Nov 17 23:35:47 2000
@@ -77
On Nov 17, Linus Torvalds wrote:
>
>
> On Fri, 17 Nov 2000, Harald Koenig wrote:
> >
> > this seems to make things much worse: starting with ~90M free memory
> > "du" again started leaking (or maybe just using memory?) down to ~80M free
> > memory when the system suddently locked up completel
Hi Ingo & lists,
due to the xor.c cleanup in 2.4.0-test11-pre5+, raid5 compiled into the
kernel fails when booting, because the calibrate_xor_block function
hasn't been called while registering a raid5 volume; this leads to a
panic, as no checksumming function has been chosen.
Here's a tiny patc
"Adam J. Richter" wrote:
> Jeff Garzik writes:
> >Are you aware of any hotplug sunhme hardware? If no, don't change it to
> >__devinit...
>
> Can I have a hot plug PCI bridge card that connects to
> a regular PCI backplane (perhaps as some kind of CardBus docking
> station card)? If so,
On Nov 17, [EMAIL PROTECTED] wrote:
>
> > > + if (cpnt)
> > > + kfree(cpnt);
>
> > this seems to make things much worse
>
> Yes, I meant
>
> if (cpnt) {
> kfree(cpnt);
> cpnt = NULL;
>
> --On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom
> > How about adding an ifdef CONFIG_SMP then print ugly warning to all known
> > SMP unsafe drivers? A message could be printed booth at compile and load
> > time.
Frank Davis wrote:
> I would rather fix those non-SMP compl
On Fri, 17 Nov 2000, Harald Koenig wrote:
>
> this seems to make things much worse: starting with ~90M free memory
> "du" again started leaking (or maybe just using memory?) down to ~80M free
> memory when the system suddently locked up completely, no console switch
> was possible anymore (but
I would rather fix those non-SMP compliant drivers to be SMP compliant,
then keeping them 'broken'. Adding the print statements would only be a
temporary solution.
Regards,
Frank
--On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom
> How about adding an ifdef CONFIG_SMP then
Jeff Garzik writes:
>Are you aware of any hotplug sunhme hardware? If no, don't change it to
>__devinit...
Can I have a hot plug PCI bridge card that connects to
a regular PCI backplane (perhaps as some kind of CardBus docking
station card)? If so, all PCI drivers should use __dev{init
Michael Rothwell wrote:
> 4) A high reliability internal file system.
>
> Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems
> book, Ext2 throws safety to the wind to achieve speed. This also ties
> into Linux' convoluted VM system, and is shot in the foot by NFS. We
> would need
Followup to: <[EMAIL PROTECTED]>
By author:Matthew Kirkwood <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Fri, 17 Nov 2000, Russell King wrote:
>
> > Therefore, it should be reserved independent of whether we have the
> > driver loaded/in kernel or not.
>
> Is this not an argume
On Wed, Nov 15, 2000 at 06:16:00AM -0500, Paul Gortmaker wrote:
> > What use is knowing that a machine has EISA slots? As far as I can see
> > the only use is to ask for the EISA ID of the card.
> > Should we? I collected 1200 .cfg files and estimate that this is
> > less than 10% of what exists
On Fri, 17 Nov 2000, Russell King wrote:
> Therefore, it should be reserved independent of whether we have the
> driver loaded/in kernel or not.
Is this not an argument for a more flexible resource allocation
API? One offering both:
res = allocate_resource(restype, dev, RES_ALLOC_UNUSED, re
"Adam J. Richter" wrote:
> -static struct happy_meal *root_happy_dev = NULL;
> -
> #ifdef CONFIG_SBUS
> +static struct happy_meal *root_happy_dev = NULL;
> static struct quattro *qfe_sbus_list = NULL;
> #endif
don't initialize static to zero/null explicitly..
> - if (dev == NULL) {
> -
[EMAIL PROTECTED] ("Richard B. Johnson") writes:
[about PCI setup code]
> This stuff has to be set up before you
> have any resources necessary to execute the output of a 'C' compiler,
> so, if you are looking for 'C' syntax, you are out of luck.
Sorry, but that's plain rubbish.
Some things in
On Nov 17, [EMAIL PROTECTED] wrote:
> > memory leak
>
> Aha. Must be a missing kfree().
> Does this help?
>
> --- namei.c~Fri Nov 17 00:48:37 2000
> +++ namei.c Fri Nov 17 21:59:49 2000
> @@ -197,6 +197,8 @@
> bh = NULL;
> break;
>
> memory leak
Aha. Must be a missing kfree().
Does this help?
--- namei.c~Fri Nov 17 00:48:37 2000
+++ namei.c Fri Nov 17 21:59:49 2000
@@ -197,6 +197,8 @@
bh = NULL;
break;
}
+ if (cpnt)
+
"Adam J. Richter" wrote:
>
> Both linux-2.4.0-test12-pre6/drivers/net/rtl8129.c and
> Don Becker's version at ftp.sycld.com appear to have identical
> PCI device ID and vendor ID values for these two cards:
rtl8129 is going away as soon as humanly possible. :) RealTek sent me
a RTL8130
On Fri, Nov 17, 2000 at 12:30:38PM -0800, Barry K. Nathan wrote:
>
> I do understand that the in-kernel support isn't as mature as the external
> support yet. However, it isn't universally broken and useless either.
That's certainly true; it should work fine for the large majority of
configurati
On Fri, 17 Nov 2000, Adam J. Richter wrote:
> Both linux-2.4.0-test12-pre6/drivers/net/rtl8129.c and
> Don Becker's version at ftp.sycld.com appear to have identical
> PCI device ID and vendor ID values for these two cards:
>
> SMC1211TX EZCard 10/100 (RealTek RTL8139)
>
Both linux-2.4.0-test12-pre6/drivers/net/rtl8129.c and
Don Becker's version at ftp.sycld.com appear to have identical
PCI device ID and vendor ID values for these two cards:
SMC1211TX EZCard 10/100 (RealTek RTL8139)
Accton MPX5030 (RealTek RTL8139)
-BEGIN PGP SIGNED MESSAGE-
Last night I attempted to install a firewall system that runs over a
thousand processes (useing the TIS FWTK proxies). I upped the NR_TASKS to
4090 to allow them all to run.
the way the particular proxies work is to have a listener for each port
that forks off
On Fri, 17 Nov 2000 [EMAIL PROTECTED] wrote:
>
> Hi James,
>
> here is a patch for vgacon.c could you please check it?
Okay. Thank for for posting it not as a attachment.
> 1) removes explicit 0 initialisation of statics
Those are fine. I already have in the ruby tree for the linux c
On Nov 17, [EMAIL PROTECTED] wrote:
> > both 2.2.x and 2.4.x kernels can't read `real sky' CDs
>
> Yes. 2.0.38 is OK. I just made a patch that seems to work.
>
> Harald, could you try
> ftp.xx.kernel.org/.../people/aeb/linux-2.4.0test9-isofs-patch
> and report?
works -- sort of:( I've
Linus Torvalds wrote:
> Right now, I suspect that the in-kernel pcmcia code is actually at the
> point where it _is_ possible to use it. David Hinds has been keeping the
> cs layer in synch with the external versions, and tons of people have
> helped make the low-level drivers stable again.
>
>
On 17 Nov 2000, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:Russell King <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Richard B. Johnson writes:
> > > The code necessary to find the lowest unaliased address looks like
> > > this:
> >
> > Any chance o
> I've checked that and it works both on 2.2 and 2.4 but another test won't
> hurt :-)
No problems here :-)
-
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/
On Fri, 17 Nov 2000, Russell King wrote:
> Richard B. Johnson writes:
> > It's Intel assembly on Intel machines. It's a hell of a lot more
> > readable than AT&T assembly. This stuff has to be set up before you
> > have any resources necessary to execute the output of a 'C' compiler,
> > so, if y
On Fri, 17 Nov 2000, Guest section DW wrote:
> I see that an entire discussion has taken place. Let me just remark this,
> quoting the Austin draft:
>
> If the path argument refers to a path whose final component is either
> dot or dot-dot, rmdir( ) shall fail.
>
> EINVALThe path argu
Werner Almesberger wrote:
> The BTTV driver 0.7.48 doesn't detect my old Hauppauge card anymore.
Yes. I've taken out the detection heuristics for bt848 cards. The code
is very old, from the days where only 2-3 different bt848 cards where
available. It simply did'nt work correctly and often use
> > 2) removes an apparently unnecesary line in vgacon_scroll:
> > as I see it scr_end is computed anyway after the if statement so
> > no need to put it on the else branch.
>
> Hum. Never noticed that one. I will try this part out just to make sure
> their is no problem.
>
I've checked t
Followup to: <[EMAIL PROTECTED]>
By author:Russell King <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Richard B. Johnson writes:
> > The code necessary to find the lowest unaliased address looks like
> > this:
>
> Any chance of providing something more readable? I may be able to re
> or in any way responsible for it?
> James Simmons maybe ?
I do some console work but mostly for 2.5.X. Their is no offical
maintainer for this sub system as of now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Pl
Hi James,
here is a patch for vgacon.c could you please check it?
1) removes explicit 0 initialisation of statics
2) removes an apparently unnecesary line in vgacon_scroll:
as I see it scr_end is computed anyway after the if statement so
no need to put it on the else branch.
J
Followup to: <[EMAIL PROTECTED]>
By author:Tigran Aivazian <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Hi,
>
> The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
> difficult because the lockups appear to be kdb-specific (and kdb itself
> goes mad) but when t
Richard B. Johnson writes:
> It's Intel assembly on Intel machines. It's a hell of a lot more
> readable than AT&T assembly. This stuff has to be set up before you
> have any resources necessary to execute the output of a 'C' compiler,
> so, if you are looking for 'C' syntax, you are out of luck.
> 2. Even when I specify cs_irq=27, it resorts to polling:
>
> Intel PCIC probe:
> Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x00, 2 sockets
> host opts [0]: none
> host opts [1]: none
> ISA irqs (default) = none! polling interval =
On Fri, 17 Nov 2000, Russell King wrote:
> Richard B. Johnson writes:
> > The code necessary to find the lowest unaliased address looks like
> > this:
>
> Any chance of providing something more readable? I may be able to read
> some x86 asm, but I don't have the time to try to decode that lot.
Hi,
The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
difficult because the lockups appear to be kdb-specific (and kdb itself
goes mad) but when there is no kdb there is very little useful information
one can extract from a dead system...
I will start removing kernel subs
Richard B. Johnson writes:
> The code necessary to find the lowest unaliased address looks like
> this:
Any chance of providing something more readable? I may be able to read
some x86 asm, but I don't have the time to try to decode that lot.
_
|_| ---
1 - 100 of 246 matches
Mail list logo
