I really need to get rid of this 8139 card. Since
yall are the oracle, which nice 100mbs card is fine
hardware and is coupled with a well debugged driver?
I don't want to have any more network card problems.
I'm tired of this crappy 8139.
I have an 8139 card and it's on a 2.4 testN kernel
Manfred wrote:
> David wrote:
> >
> > Same old story, bugger still does it. Have to set the link down/up to
> > get it running again.
> >
> > 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
> > 20)
> >
>
> I missed your earlier mails, could you resend the details?
> I'm
Same old story, bugger still does it. Have to set the link down/up to
get it running again. I had to reset two systems tonight, one up for
~60 days, one up for two days. Both have this card. Unrelated traffic.
This is kernel 2.4.0-test13-pre4
00:12.0 Ethernet controller: Lite-On
Same old story, bugger still does it. Have to set the link down/up to
get it running again. I had to reset two systems tonight, one up for
~60 days, one up for two days. Both have this card. Unrelated traffic.
This is kernel 2.4.0-test13-pre4
00:12.0 Ethernet controller: Lite-On
Manfred wrote:
David wrote:
Same old story, bugger still does it. Have to set the link down/up to
get it running again.
00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
20)
I missed your earlier mails, could you resend the details?
I'm interested in the
Mikulas Patocka wrote:
> > Oh, and try to eat atomic memory by ping -f kORBit-ized box.
>
> When linux is out of atomic memory, it will die anyway.
Only if you subscribe to the "we don't need to handle exceptions or check return
values" programmers guild...i.e. lazy error prone coders.
I tend
Mikulas Patocka wrote:
Oh, and try to eat atomic memory by ping -f kORBit-ized box.
When linux is out of atomic memory, it will die anyway.
Only if you subscribe to the "we don't need to handle exceptions or check return
values" programmers guild...i.e. lazy error prone coders.
I tend to
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686-c -o journal.o journal.c
journal.c: In function `reiserfs_journal_commit_thread':
journal.c:1816: invalid operands to binary !=
There seem to be quite a lot of compile failures wrt tq_struct.
Does anyone have a template patch to use to start fixing these?
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
"Mohammad A. Haque" wrote:
> Hit http://www.lm-sensors.nu/
does anyone have an IP address for cvs.lm-sensors.nu?
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
note;quoted-printable:GPG
"Mohammad A. Haque" wrote:
Hit http://www.lm-sensors.nu/
does anyone have an IP address for cvs.lm-sensors.nu?
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
note;quoted-printable:GPG
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686-c -o journal.o journal.c
journal.c: In function `reiserfs_journal_commit_thread':
journal.c:1816: invalid operands to binary !=
> but a last one i cannot resist...
>
>
> but why are your ideas not widespread and
> so successful like kde,gnome,windows?
> maybe because they suck at some point?
>
>
> Regards (and please flame me private ... :))
Last time I checked you needed a kernel...
-d
begin:vcard
n:Ford;David
> I can't swapoff. Therefore filesystem is busy (it must be -- kernel
> might be writing to file on it!). And no way to get out of that.
It's busy because some portion of memory is in use. manually kill things as
best you can. this will clean out the swap. once you've gotten all
applications
I can't swapoff. Therefore filesystem is busy (it must be -- kernel
might be writing to file on it!). And no way to get out of that.
It's busy because some portion of memory is in use. manually kill things as
best you can. this will clean out the swap. once you've gotten all
applications
but a last one i cannot resist...
sarcasm
but why are your ideas not widespread and
so successful like kde,gnome,windows?
maybe because they suck at some point?
/sarcasm
Regards (and please flame me private ... :))
Last time I checked you needed a kernel...
-d
begin:vcard
> > * We can now write device drivers in perl, and let them run on the iMAC
> > across the hall from you. :)
>
> Why would you *ever* want to write a device driver in perl???
So you can easily facilitate opportunities for viruses ;)
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
* We can now write device drivers in perl, and let them run on the iMAC
across the hall from you. :)
Why would you *ever* want to write a device driver in perl???
So you can easily facilitate opportunities for viruses ;)
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
Igmar Palsenberg wrote:
> > This is standard stuff... You are really pissing into the wind here ;)
>
> Guess I am. Still isn't an explaination why I see a lot of broken code out
> there regarding this issue.
>
> Igmar
Broken code due to broken programmers.
-d
begin:vcard
Igmar Palsenberg wrote:
This is standard stuff... You are really pissing into the wind here ;)
Guess I am. Still isn't an explaination why I see a lot of broken code out
there regarding this issue.
Igmar
Broken code due to broken programmers.
-d
begin:vcard
n:Ford;David
Igmar Palsenberg wrote:
> > For a blocking fd, read(2) has always blocked until some data is
> > available. There has never been a guarantee, for any driver, that
> > a read(2) will return the full amount of bytes requested.
>
> I know. Still leaves lot's of people that assume that reading
Igmar Palsenberg wrote:
For a blocking fd, read(2) has always blocked until some data is
available. There has never been a guarantee, for any driver, that
a read(2) will return the full amount of bytes requested.
I know. Still leaves lot's of people that assume that reading /dev/random
usb-uhci.c: interrupt, status 2, frame# 532
usb-uhci.c: interrupt, status 2, frame# 546
usb.c: USB disconnect on device 6
usb-uhci.c: interrupt, status 2, frame# 569
hub.c: USB new device connect on bus1/1, assigned device number 7
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new
yet another apm related bug. this one is the odd one, frequently i
update my kernel on this laptop. every once in a while, i'd say about
one out of five kernels..upon apm resume, the floppy drive motor will
start spinning. nothing stops it from spinning except i attempt to
mount a non-existing
> Seems to have broken my IntelliMouse Optical (logs from the third time
> I inserted usb-uhci):
>
> Nov 29 17:12:08 sasami kernel: usb-uhci.c: Detected 2 ports
> Nov 29 17:12:08 sasami kernel: usb.c: new USB bus registered, assigned bus number 1
> Nov 29 17:12:08 sasami kernel: hub.c: USB hub
Unable to handle kernel NULL pointer dereference at virtual address
00fc
c02b3527
*pde = 02253067
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010293
eax: ebx: c90cb800 ecx: c03826a8 edx: 0001
esi: 0003 edi:
Unable to handle kernel NULL pointer dereference at virtual address
00fc
c02b3527
*pde = 02253067
Oops:
CPU:0
EIP:0010:[c02b3527]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010293
eax: ebx: c90cb800 ecx: c03826a8 edx: 0001
esi: 0003 edi:
Seems to have broken my IntelliMouse Optical (logs from the third time
I inserted usb-uhci):
Nov 29 17:12:08 sasami kernel: usb-uhci.c: Detected 2 ports
Nov 29 17:12:08 sasami kernel: usb.c: new USB bus registered, assigned bus number 1
Nov 29 17:12:08 sasami kernel: hub.c: USB hub found
yet another apm related bug. this one is the odd one, frequently i
update my kernel on this laptop. every once in a while, i'd say about
one out of five kernels..upon apm resume, the floppy drive motor will
start spinning. nothing stops it from spinning except i attempt to
mount a non-existing
usb-uhci.c: interrupt, status 2, frame# 532
usb-uhci.c: interrupt, status 2, frame# 546
usb.c: USB disconnect on device 6
usb-uhci.c: interrupt, status 2, frame# 569
hub.c: USB new device connect on bus1/1, assigned device number 7
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new
I can't say who's fault it is, but I suggest this test12-pre2 patch for clarity
--- fs/buffer.c~Tue Nov 28 05:11:56 2000
+++ fs/buffer.c Tue Nov 28 06:27:05 2000
@@ -1133,7 +1133,7 @@
atomic_dec(>b_count);
return;
}
- printk("VFS: brelse:
I can't say who's fault it is, but I suggest this test12-pre2 patch for clarity
--- fs/buffer.c~Tue Nov 28 05:11:56 2000
+++ fs/buffer.c Tue Nov 28 06:27:05 2000
@@ -1133,7 +1133,7 @@
atomic_dec(buf-b_count);
return;
}
- printk("VFS: brelse:
"Jeff V. Merkey" wrote:
> On Sun, Nov 26, 2000 at 06:02:35PM -0500, Mohammad A. Haque wrote:
> > I'd rather have Anaconda changed rather than special casing standard
> > utils to account for distro handling.
>
> Great. Then tell RedHat to rewrite it without the need for these switches.
> They
"Jeff V. Merkey" wrote:
> On Sun, Nov 26, 2000 at 10:46:35PM +, Alan Cox wrote:
> > > + {"ignore-versions", 0, 0, 'i'},
> >
> > I dont think we should encourage anyone to ignore symbol versions
>
> Anaconda will barf and require over 850+ changes to the scripts without
> it. If
"Jeff V. Merkey" wrote:
On Sun, Nov 26, 2000 at 10:46:35PM +, Alan Cox wrote:
+ {"ignore-versions", 0, 0, 'i'},
I dont think we should encourage anyone to ignore symbol versions
Anaconda will barf and require over 850+ changes to the scripts without
it. If you look at
"Jeff V. Merkey" wrote:
On Sun, Nov 26, 2000 at 06:02:35PM -0500, Mohammad A. Haque wrote:
I'd rather have Anaconda changed rather than special casing standard
utils to account for distro handling.
Great. Then tell RedHat to rewrite it without the need for these switches.
They will say
Charles Peterman wrote:
> Thanks, I had to putz with the gain to get sound out of it without
> turning my amp to 11, but yes it works. Do you know if anyone is
> putting in the effort to make the six channel useful?
>
> Thanks again,
Dunno about that, I use gmix for my mixer and it sounds
Charles Peterman wrote:
Thanks, I had to putz with the gain to get sound out of it without
turning my amp to 11, but yes it works. Do you know if anyone is
putting in the effort to make the six channel useful?
Thanks again,
Dunno about that, I use gmix for my mixer and it sounds fine, I
> > * Remove compile warnings in xstrcat.
> > * snprintf cleanups.
> > * Set safemode when uid != euid.
> > * Strip quotes from shell responses.
> + add RedHat ism's with a --rhc (red hat compatible) -i -m (-F)
>
> RedHat kind of is the standard in the commercial
Something appears to be broken. One of my servers is going through
seemingly random spontaneous reboots with nothing to indicate why.
model name : Pentium III (Coppermine)
features: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
It's a VIA
Something appears to be broken. One of my servers is going through
seemingly random spontaneous reboots with nothing to indicate why.
model name : Pentium III (Coppermine)
features: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
It's a VIA
rpc.portmap isn't running, your login configuration/nss requires yp or something
provided ans an RPC.
-d
"M.H.VanLeeuwen" wrote:
> I had occasion to "telinit 1" today and found that it took a long time
> to login after root passwd was entered. this doesn't happen with 2.2.X
> kernels.
>
> Is
My guess is that it's a plugin, the source for xmms doesn't have "cpuinfo" anywhere in
it.
-d
Gianluca Anzolin wrote:
> it seems there has been a change in the format of the /proc/cpuinfo file: infact
>'flags: ' became 'features: '
>
> This change broke xmms and could broke any other program
Christer Weinigel wrote:
> >Kernel on writeprotected floppy disk...
>
> So change the CMOS-settings so that the BIOS changes the boot order
> from A, C, CD-ROM to C first instead. *grin* How long do you want
> to keep playing Tic-Tac-Toe?
>
> Of course, using capabilities and totally disabling
> Why not? /me has nearly everything compiled as modules.
Some people have extensive sh, awk and sed scripts to manage their systems, some
have compiled programs.
> > There is an introduced security weakness by using kernels.
>
> ??? Guess you mean "by using modules"? Which weakness? Other
Gerd Knorr wrote:
> Why? What is the point in compiling bttv statically into the kernel?
> Unlike filesystems/ide/scsi/... you don't need it to get the box up.
> No problem to compile the driver as module and configure it with
> /etc/modules.conf ...
Huh?
Some systems are built without module
"Eric W. Biederman" wrote:
> > Be sure lo is established before eth0 and you won't see this message.
>
> Hmm. How does the interaction work. I've been meaning to track it for
> a while but haven't yet.
>
> >From the cases I have observed it seems to be connected with arp requests
> that aren't
"Eric W. Biederman" wrote:
Be sure lo is established before eth0 and you won't see this message.
Hmm. How does the interaction work. I've been meaning to track it for
a while but haven't yet.
From the cases I have observed it seems to be connected with arp requests
that aren't
Gerd Knorr wrote:
Why? What is the point in compiling bttv statically into the kernel?
Unlike filesystems/ide/scsi/... you don't need it to get the box up.
No problem to compile the driver as module and configure it with
/etc/modules.conf ...
Huh?
Some systems are built without module
Why not? /me has nearly everything compiled as modules.
Some people have extensive sh, awk and sed scripts to manage their systems, some
have compiled programs.
There is an introduced security weakness by using kernels.
??? Guess you mean "by using modules"? Which weakness? Other than
Christer Weinigel wrote:
Kernel on writeprotected floppy disk...
So change the CMOS-settings so that the BIOS changes the boot order
from A, C, CD-ROM to C first instead. *grin* How long do you want
to keep playing Tic-Tac-Toe?
Of course, using capabilities and totally disabling access
My guess is that it's a plugin, the source for xmms doesn't have "cpuinfo" anywhere in
it.
-d
Gianluca Anzolin wrote:
it seems there has been a change in the format of the /proc/cpuinfo file: infact
'flags: ' became 'features: '
This change broke xmms and could broke any other program
rpc.portmap isn't running, your login configuration/nss requires yp or something
provided ans an RPC.
-d
"M.H.VanLeeuwen" wrote:
I had occasion to "telinit 1" today and found that it took a long time
to login after root passwd was entered. this doesn't happen with 2.2.X
kernels.
Is this
Andrew Park wrote:
> I get a message
>
> neighbour table overflow
>
> What does that mean? It seems that
>
> net/ipv4/route.c
>
> is the place where it prints this. But under what circumstances
> does this happen?
> Thanks
It means you set the link state of eth0 up before lo.
ock.
eth1: MII transceiver #0 config 3000 status 7809 advertising 01e1.
call_usermodehelper[/sbin/hotplug]: no root fs
Linus Torvalds wrote:
> On Sat, 18 Nov 2000, David Ford wrote:
> > Linus Torvalds wrote:
> >
> > > Can you (you've probably done this before, but
Linus Torvalds wrote:
> Can you (you've probably done this before, but anyway) enable DEBUG in
> arch/i386/kernel/pci-i386.h? I wonder if the kernel for some strange
> reason doesn't find your router, even though "dump_pirq" obviously does..
> If there's something wrong with the checksumming for
Johannes Erdfelt wrote:
> > # dmesg
> > hub.c: USB new device connect on bus1/1, assigned device number 6
> > usb-uhci.c: interrupt, status 2, frame# 121
> > usb.c: USB device not accepting new address=6 (error=-110)
> > hub.c: USB new device connect on bus1/1, assigned device number 7
>
>
I've been trying [unsuccessfully :S] to get the kernel's pcmcia
working. I woke up this morning and found the following oops:
Unable to handle kernel NULL pointer dereference at virtual address
001b
c01d4dca
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops
Here's another one for the books. In the recent test11 series, timing
appears to be partially broken for dev addr assignments. If I'm lucky a
new usb device will answer back and get all the numbers set up
properly. Regularly however a new device gets plugged in and I get
several of the below
Linus Torvalds wrote:
[...]
> If somebody still has a problem with the in-kernel stuff, speak up.
The kernel's irq detection for the card sockets doesn't work for me. It's the NEC
Versa LX story. The DH code also reports no IRQ found but still figures out a
working IRQ (normally 3) and
Linus Torvalds wrote:
[...]
If somebody still has a problem with the in-kernel stuff, speak up.
The kernel's irq detection for the card sockets doesn't work for me. It's the NEC
Versa LX story. The DH code also reports no IRQ found but still figures out a
working IRQ (normally 3) and assigns
Here's another one for the books. In the recent test11 series, timing
appears to be partially broken for dev addr assignments. If I'm lucky a
new usb device will answer back and get all the numbers set up
properly. Regularly however a new device gets plugged in and I get
several of the below
I've been trying [unsuccessfully :S] to get the kernel's pcmcia
working. I woke up this morning and found the following oops:
Unable to handle kernel NULL pointer dereference at virtual address
001b
c01d4dca
*pde =
Oops:
CPU:0
EIP:0010:[c01d4dca]
Using defaults from
Johannes Erdfelt wrote:
# dmesg
hub.c: USB new device connect on bus1/1, assigned device number 6
usb-uhci.c: interrupt, status 2, frame# 121
usb.c: USB device not accepting new address=6 (error=-110)
hub.c: USB new device connect on bus1/1, assigned device number 7
Status 2 means
Linus Torvalds wrote:
Can you (you've probably done this before, but anyway) enable DEBUG in
arch/i386/kernel/pci-i386.h? I wonder if the kernel for some strange
reason doesn't find your router, even though "dump_pirq" obviously does..
If there's something wrong with the checksumming for
transceiver #0 config 3000 status 7809 advertising 01e1.
call_usermodehelper[/sbin/hotplug]: no root fs
Linus Torvalds wrote:
On Sat, 18 Nov 2000, David Ford wrote:
Linus Torvalds wrote:
Can you (you've probably done this before, but anyway) enable DEBUG in
arch/i386/kernel/pci-i386.h? I
> > 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
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 assumptions
Jeff Garzik wrote:
> > * 2.4.0-test10 pcmcia fails to detect IRQ's correctly, and will
> >sometimes kill all software interrupts on card insertion on a NEC
> > Versa LX (David Ford)
>
> Still does this with test11-pre-latest?
I'll test this tomorr
I have found that lowering the MTU helps a lot. If it is a particular route,
simply add an additional route with the lower limit set. The tradeoff of
efficiency v.s. reliability is improved.
-d
Horst von Brand wrote:
> In my experience, if you try to send large messages over unreliable
>
I have found that lowering the MTU helps a lot. If it is a particular route,
simply add an additional route with the lower limit set. The tradeoff of
efficiency v.s. reliability is improved.
-d
Horst von Brand wrote:
In my experience, if you try to send large messages over unreliable
Jeff Garzik wrote:
* 2.4.0-test10 pcmcia fails to detect IRQ's correctly, and will
sometimes kill all software interrupts on card insertion on a NEC
Versa LX (David Ford)
Still does this with test11-pre-latest?
I'll test this tomorrow, I can't interrupt my laptop
> They're not modprobes, they're misnamed processes sleeping from NWFS.
If they're sleeping, why are they in D state? That ups the load average.
> I got the fix from someone so now they display their proper names.
> top displays the names correctly, ps does not. Several people have
>
> > With a handle like
> > "Assmann", deviation is proably something you already understand quite
> > well ...
>
> Don't be a moron. Claus is German, Assman really is his last name and
> not some "handle", and it's pronounced "Oss-man".
Claus is a well liked, knowledgable and well
The only
defaults I've really had to change are the max children and some of the
timing simply because I want stalled connections (read routing loss) to
requeue quickly.
-d
"Jeff V. Merkey" wrote:
> David Ford wrote:
>
> David,
>
> We got to the bottom of it. send
Some wild blatherings about sendmail...
- Uses lots of memory to send a big file.
Incorrect. I just verified it with a 10 meg file which became a 14 meg attachment.
Sendmail consumed an additional 5 megs combined while handling the input and output
v.s.
an idle daemon. Idle is 1.8M, recv
.
Chris Mason wrote:
> On Friday, November 10, 2000 06:15:40 -0800 David Ford <[EMAIL PROTECTED]>
> wrote:
>
> > Over the last three weeks my box has been locking up w/ a black screen
> > of death. This time I had kdb patched in and got the following:
> >
> >
Over the last three weeks my box has been locking up w/ a black screen
of death. This time I had kdb patched in and got the following:
Entering kdb (current=0xcf906000, pid 16808) Panic: invalid operand
due to panic @ 0xc0163d7a
eax = 0x001a ebx = 0xcf907d8c ecx = 0xcf906000 edx =
Over the last three weeks my box has been locking up w/ a black screen
of death. This time I had kdb patched in and got the following:
Entering kdb (current=0xcf906000, pid 16808) Panic: invalid operand
due to panic @ 0xc0163d7a
eax = 0x001a ebx = 0xcf907d8c ecx = 0xcf906000 edx =
.
Chris Mason wrote:
On Friday, November 10, 2000 06:15:40 -0800 David Ford [EMAIL PROTECTED]
wrote:
Over the last three weeks my box has been locking up w/ a black screen
of death. This time I had kdb patched in and got the following:
Entering kdb (current=0xcf906000, pid 16808) Panic
Some wild blatherings about sendmail...
- Uses lots of memory to send a big file.
Incorrect. I just verified it with a 10 meg file which became a 14 meg attachment.
Sendmail consumed an additional 5 megs combined while handling the input and output
v.s.
an idle daemon. Idle is 1.8M, recv
The only
defaults I've really had to change are the max children and some of the
timing simply because I want stalled connections (read routing loss) to
requeue quickly.
-d
"Jeff V. Merkey" wrote:
David Ford wrote:
David,
We got to the bottom of it. sendmail is using a BSD meth
They're not modprobes, they're misnamed processes sleeping from NWFS.
If they're sleeping, why are they in D state? That ups the load average.
I got the fix from someone so now they display their proper names.
top displays the names correctly, ps does not. Several people have
verified
"Dunlap, Randy" wrote:
> > Either. Currently bus (self) powered. This hub has worked
> > fine on my other
> > computers without any adverse affect.
>
> Bus-powered != self-powered.
It had been a long day. I really do know the distinction :)
It is currently bus powered and I've only once had
"Dunlap, Randy" wrote:
Either. Currently bus (self) powered. This hub has worked
fine on my other
computers without any adverse affect.
Bus-powered != self-powered.
It had been a long day. I really do know the distinction :)
It is currently bus powered and I've only once had it self
Sigh. That's not the real hang position. I needed to step slower.
kdb> ss
0xc01100f8 pci_conf1_write_config_word+0x40: outw %ax,(%dx)
SS trap at 0xc01100fa (pci_conf1_write_config_word+0x42)
0xc01100fa pci_conf1_write_config_word+0x42: popl %ebx
kdb> ss
0xc01100fa
More data:
kdb> bp pci_conf1_write_config_word+0x3a
Instruction(i) BP #1 at 0xc01100f2 (pci_conf1_write_config_word+0x3a)
is enabled globally adjust 1
kdb> go
Instruction(i) breakpoint #1 at 0xc01100f2 (adjusted)
0xc01100f2 pci_conf1_write_config_word+0x3a: orl$0xcfc,%edx
Entering kdb
Greg KH wrote:
> On Wed, Nov 08, 2000 at 08:19:13PM -0800, David Ford wrote:
> > I am going thru the steps atm. The JE driver also hangs.
>
> Thanks for doing this.
np.
> > More information. I have an external USB 4 port hub, in which I have one
> > logitech mouse
> The NMI oopser for UP only trips in when the cpu is spinning. If the
> cpu is in a halt state then NMI does not run. But in a halt state you
> should be able to activate kdb via the pause key. The only time you
> cannot get kdb via pause is if interrupts are disabled (but then the
> cpu
I am going thru the steps atm. The JE driver also hangs.
More information. I have an external USB 4 port hub, in which I have one
logitech mouse at the moment. I can cold boot and reboot to my heart's
delight fine. But if I unplug/plug in the mouse and reboot, it will hang.
Note, I have to
Crystal 4280/461x + AC97 Audio, version 0.09, 16:07:04 Nov 8 2000
cs461x: Card found at 0xc780 and 0xc700, IRQ 11
cs461x: Voyetra at 0xc780/0xc700, IRQ 11
Unable to handle kernel paging request at virtual address a1d60878
printing eip:
a1d60878
*pde =
Oops:
CPU:
I just recompiled using the JE driver and it doesn't lock up on boot.
-d
Georg Nikodym wrote:
> >>>>> "DF" == David Ford <[EMAIL PROTECTED]> writes:
>
> DF> Ok, in test10, for every 2 out of 5 boots, this particular
> DF> workstation lock
support that I need ?
> Its nicely commented out in drivers/net/pcmcia/Config.in
>
> I remember everything working fine up until about test3/4, since then I've
> had to revert to the pcmcia-cs package.
>
> Just wondering whats going on ?
>
> / Brett
>
> On Wed, 8
Ok, in test10, for every 2 out of 5 boots, this particular workstation
locks up hard as it reaches the following:
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.242 $ time 15:53:47 Nov 8 2000
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB
With a few exceptions, it should work. The problematic systems are few.
-d
David Feuer wrote:
> What is the current status of PC-card support? I've seen ominous signs on
> this list about the state of support I have a laptop with a PCMCIA
> network card (a 3com thing). Will it work?
--
With a few exceptions, it should work. The problematic systems are few.
-d
David Feuer wrote:
What is the current status of PC-card support? I've seen ominous signs on
this list about the state of support I have a laptop with a PCMCIA
network card (a 3com thing). Will it work?
--
Ok, in test10, for every 2 out of 5 boots, this particular workstation
locks up hard as it reaches the following:
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.242 $ time 15:53:47 Nov 8 2000
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB
commented out in drivers/net/pcmcia/Config.in
I remember everything working fine up until about test3/4, since then I've
had to revert to the pcmcia-cs package.
Just wondering whats going on ?
/ Brett
On Wed, 8 Nov 2000, David Ford wrote:
With a few exceptions, it should work
I just recompiled using the JE driver and it doesn't lock up on boot.
-d
Georg Nikodym wrote:
"DF" == David Ford [EMAIL PROTECTED] writes:
DF Ok, in test10, for every 2 out of 5 boots, this particular
DF workstation locks up hard as it reaches the following:
I have a simil
Crystal 4280/461x + AC97 Audio, version 0.09, 16:07:04 Nov 8 2000
cs461x: Card found at 0xc780 and 0xc700, IRQ 11
cs461x: Voyetra at 0xc780/0xc700, IRQ 11
Unable to handle kernel paging request at virtual address a1d60878
printing eip:
a1d60878
*pde =
Oops:
CPU:
201 - 300 of 516 matches
Mail list logo
