Re: Promise, DMA and RAID5 problems running 2.4.1

[Vojtech Pavlik]

On Wed, Feb 07, 2001 at 12:53:36PM -0800, Andre Hedrick wrote:
> On Wed, 7 Feb 2001, Alan Cox wrote:
> 
> > > Iff CONFIG_BLK_DEV_IDECS is set then yes, doing schedule is better.
> > > But I do not see any benefit in doing
> > > 
> > > unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
> > > while (0 < (signed long)(timeout - jiffies));
> > 
> > On that bit we agree.
> 
> What do you want fixed?
> Send a patch and lets try it

How about this?

-- 
Vojtech Pavlik
SuSE Labs


--- pdc202xx.c.old  Fri Jul 28 21:08:30 2000
+++ pdc202xx.c  Fri Feb  9 09:08:55 2001
@@ -747,14 +747,11 @@
 {
unsigned long high_16   = pci_resource_start(HWIF(drive)->pci_dev, 4);
byte udma_speed_flag= inb(high_16 + 0x001f);
-   int i   = 0;
 
OUT_BYTE(udma_speed_flag | 0x10, high_16 + 0x001f);
-   ide_delay_50ms();
-   ide_delay_50ms();
+   mdelay(100)
OUT_BYTE(udma_speed_flag & ~0x10, high_16 + 0x001f);
-   for (i = 0; i < 40; i++)
-   ide_delay_50ms();
+   mdelay(2000);   /* 2 seconds ?! */
 }
 
 unsigned int __init pci_init_pdc202xx (struct pci_dev *dev, const char *name)
@@ -767,7 +764,6 @@
if ((dev->device == PCI_DEVICE_ID_PROMISE_20262) ||
(dev->device == PCI_DEVICE_ID_PROMISE_20265) ||
(dev->device == PCI_DEVICE_ID_PROMISE_20267)) {
-   int i = 0;
/*
 * software reset -  this is required because the bios
 * will set UDMA timing on if the hdd supports it. The
@@ -779,11 +775,9 @@
 */
 
OUT_BYTE(udma_speed_flag | 0x10, high_16 + 0x001f);
-   ide_delay_50ms();
-   ide_delay_50ms();
+   mdelay(100);
OUT_BYTE(udma_speed_flag & ~0x10, high_16 + 0x001f);
-   for (i=0; i<40; i++)
-   ide_delay_50ms();
+   mdelay(2000);   /* 2 seconds ?! */
}
 
if (dev->resource[PCI_ROM_RESOURCE].start) {

Re: [PATCH] modify ver_linux to check e2fsprogs and more.

[Jochen Striepe]

Hi,

On 08 Feb 2001, Steven Cole <[EMAIL PROTECTED]> wrote:
> 
> But, there is an easy solution:
> [root@localhost scripts]# ifconfig --version
> net-tools 1.57
> ifconfig 1.40 (2000-05-21)
> 
> I replaced the old code for Net-tools with this:
> 
> ifconfig --version 2>&1 | grep tools | awk \
> 'NR==1{print "Net-tools ", $NF}'
> 
> That should work.  I hope.  Try it please.

This works great for me. Thanks!


Greetings from Germany,

Jochen Striepe.

-- 
"Gosh that takes me back ... or forward.  That's the trouble with time
travel, you never can tell."
-- Dr. Who


 PGP signature

Re: Problem with schedule_timeout..

[Avinash vyas]

Hi 
Yes the problem was what Sir Alan Cox told, when i called my
device driver poll function after making the TASK_INTERRUPTIBLE, it made
the process state again to RUNNING (In a rpc_call() function).

Thanx

 
 # Avinash Vyas #
 # M.Tech. CSE  #
 # IIT Kanpur   #
 #  # 
 #   Address: C-302,#
 #Hall IV,  #
 #IIT Kanpur.   #
 #   E-mail: [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/

VIA Rhine on Alpha bug

[Kaj-Michael Lang]

I don't know if it should work or not but using a VIA Rhine compatible card
on my LX164 locks it solid when transfering large packets:
ping -f host.on.100mbit.lan works
ping -f -s 1024 same.host locks it solid as does
untarring to a NFS mount.

No oops/panic, just locks solid.

Kaj-Michael Lang
[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: DNS goofups galore...

[Jan Gyselinck]

On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> Followup to:  <[EMAIL PROTECTED]>
> By author:Gerhard Mack <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Thanklfully bind 9 barfs if you even try this sort of thing.
> > 
> 
> Personally I find it puzzling what's wrong with MX -> CNAME at all; it
> seems like a useful setup without the pitfalls that either NS -> CNAME
> or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
> irreducible situations; CNAME -> CNAME would require a link maximum
> count which could result in obscure breakage.)
> 
>   -hpa

There's not really something wrong with MX's pointing to CNAME's.  It's just that some 
mailservers could (can?) not handle this.  So if you want to be able to receive mail 
from all kinds of mailservers, don't use CNAME's for MX's.

Regards


Jan Gyselinck
-
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/

multiple 3c509 problems

[David Carlson]

Hi, I've been experiencing numerous problems with the 3c509 driver in 2.4.1.
When I force it to go to both cards (ether=10,0x300,eth0
ether=11,0x210,eth1), they both act strange (and also claim to be BNC when
they are both TP).  The link light at the hub flashes three times
repeatedly.

Donald Becker thinks it is a problem specific to the conversion to 2.4

Dave Carlson

-
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: [ANNOUNCE] Animated framebuffer logo for 2.4.1

[Mike Galbraith]

On Thu, 8 Feb 2001, christophe barbe wrote:

> Ok it seems not important to have a nice boot process but each time you show a linux 
>machine to a M$ normal user (normal = not a programmer) his first reaction is 
>something like ""what are all these strange output lines?". And it's the first thing 
>that keep Windows user in the dark side. 
> Windows hides (or try to do) all messages by a blue screen (light blue, when you are 
>lucky). 
> 
> For these reason, I use LPP (linux patch progress). It's a little patch. The main 
>idea is : redirect all boot messages on the second console, display on the first one 
>a bigger framebuffer logo (screen size) and draw on it the progress bar, progress 
>text and warning messages. A proc interface is provided for the second part of the 
>boot process (echo "starting X Font Server" > /proc/progress).
> 
> The boot is not significantly longer (and with a well fitted kernel, is really 
>faster than M$ Wx) and suddendly the first linux impression is really good.
> 
> I hope this kind of patch can be integrated in the kernel.

I hope that nothing like this is _ever_ integrated (and doubt I need
be concerned;).  IMHO, hiding output from users arrogantly assumes
that they are too stupid/ignorant to have any use for such information.

-Mike

-
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 using ppp on serial modem for kernel 2.4.x

[hingwah]

Hello all,

Recently I try to upgrade kernel 2.2.x to 2.4.x (the problem occur
both for 2.4.0 and 2.4.1). When I use kernel 2.2.x before and use the serial modem to 
connect internet and telnet to some Chinese bbs ( in which 8-bit character is used,e.g 
bbs.e-fever.org ,bbs.org.hk  ,it work fine. However,when I change to use kernel 
2.4.x). Problem occur and the telnet seem hang in the menu, I try to telnet to other 
machine first and telnet to the bbs again,the problem still occur. However, if I use 
ssh to connect to other machine and connect to the bbs again, it work fine. I wonder 
if there is some 8-bit character treated as some control code for pppd. Should I set 
something about asyncmap in /etc/ppp/options?
I have tried enable "asyncmap 0" or use "defaultasyncmap" or "escape 11,13,ff) but it 
seem don't work.


P.S I have upgraded to pppd 2.4.x and the address machine can be login by "guest" 
after the login prompt

-
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] cosmetic: missing includes (net/sched)

[David S. Miller]

Werner Almesberger writes:
 > This patch for 2.4.2-pre1 adds a few includes I forgot in sch_atm.c and
 > sch_dsmark.c

Applied, thanks.

Later,
David S. Miller
[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: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()

[Thomas Hood]

Okay, I now know the cause of this problem.  It's a bug in
the ipx driver.  (This also closes pcmcia-cs bug #126563.)

Through copious use of printk()s I was able to track down
the point at which the dev->refcnt for my card was being
erroneously decremented.  It was being erroneously decremented
by "notifier_call_chain(&netdev_chain, NETDEV_DOWN, dev);"
near the end of the "dev_close()" function in net/core/dev.c.
This indicated that one of the registered notifiers
was doing an improper "dev_put()".  I rmmod-ed the ipx module
from my system and the problem magically disappeared.  The
refcnt is no longer inappropriately decremented and there
are no more inappropriate calls to netdev_finish_unregister()
in the absence of a prior call to unregister_netdevice()
(which is what resulted in the "Freeing alive device" messages).

Where is the bug?  It is in the ipx driver.  When I configure
eth0 for ipx, the device gets added to the ipx driver's linked
list of devices headed at "ipx_interfaces".  The ipx driver
registers the following function to be notified of net events.
It's clear that the ipx driver will do a __ipxitf_put (which
decrements dev-refcnt and does a dev_put() on dev) every time
eth0 is taken down with "ifconfig eth0 down"!  That would be
okay, I guess, if the opposite were done on an "ifconfig eth0 up"
but it isn't.  This needs to be fixed somehow.  I'll leave it
up to the maintainers and other gurus to figure out how.  In
the meantime I'll just avoid using ipx.

 net/ipx/af_ipx.c ---
static int ipxitf_device_event(struct notifier_block *notifier,
unsigned long event, void *ptr)
{
struct net_device *dev = ptr;
ipx_interface *i, *tmp;

if (event != NETDEV_DOWN)
return NOTIFY_DONE;

spin_lock_bh(&ipx_interfaces_lock);
for (i = ipx_interfaces; i;) {
tmp = i->if_next;
if (i->if_dev == dev)
__ipxitf_put(i);
i = tmp;

}
spin_unlock_bh(&ipx_interfaces_lock);
return NOTIFY_DONE;
}
--

--
Thomas Hood
Please reply to me at:  jdthood_AT_yahoo.co.uk

I wrote:
> Earlier I reported error messages when I tried to eject 
> a Xircom CEM56 network card under Linux 2.4.x. (See below. 
> I also submitted this patch as a followup to that thread.) 
> 
> Here is a patch which may not solve the underlying 
> problem but which does prevent the kernel from generating 
> an infinite number of 
> "unregister_netdevice: waiting for eth0 to become free. 
>  Usage count = -1" 
> messages on "cardctl eject" and from hanging up at shutdown. 
> 
> - 
> root@thanatos:/usr/src/kernel-source-2.4.1-ac3/net/core# diff -Naur dev.c_ORIG dev.c 
> --- dev.c_ORIG Mon Feb 5 17:39:31 2001 
> +++ dev.c Wed Feb 7 18:35:45 2001 
> @@ -2555,7 +2555,7 @@ 
>   */ 
>   
>  now = warning_time = jiffies; 
> - while (atomic_read(&dev->refcnt) != 1) { 
> + while (atomic_read(&dev->refcnt) > 1) { 
>  if ((jiffies - now) > 1*HZ) { 
>  /* Rebroadcast unregister notification */ 
>  notifier_call_chain(&netdev_chain, NETDEV_UNREGISTER, dev); 
> --- 
> 
> The underlying problem seem so be that refcnt is zero or 
> less at this point. This is erroneous. The error in 
> maintaining the refcnt appears to occur only when 
> I configure the eth0 interface (using pump or dhclient). 
> The more times I "ifup eth0" and "ifdown eth0" before 
> ejecting the card, the lower the "usage count" is 
> reported to be (i.e., the larger the negative number!). 
> 
> Be that as it may, because of the erroneous refcnt, 
> the above while loop within unregister_netdevice() 
> loops forever in the original code. As modified it 
> falls through; and this makes the kernel usable for me. 
> 
> In order to avoid the 
>"KERNEL: assertion(dev->ip_ptr==NULL)failed at 
> dev.c(2422):netdev_finish_unregister" 
> message and the occasional 
>"Freeing alive device" 
> message it seems to suffice that I kill the dhclient 
> process before running "ifdown eth0". Am I right in 
> assuming that the latter messages aren't serious? 
> 
> I hope the networking gurus can find the real bugs here. 
> 
> Thomas Hood
-
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: ARP out the wrong interface

[Stephen Degler]

Hi,

What you describe below is having the client mis-addressed to have
the same IP as the server.  Is this what you meant?

skd


On Thu, Feb 08, 2001 at 09:09:49PM -0800, dean gaudet wrote:
> this appears to occur with both 2.2.16 and 2.4.1.
> 
> server:
> 
> eth0 is 192.168.250.11 netmask 255.255.255.0
> eth1 is 192.168.251.11 netmask 255.255.255.0
> 
> they're both connected to the same switch.
> 
> client:
> 
> eth0 is 192.168.251.11 netmask 255.255.255.0
> 
> connected to the same switch as both of server's eth.
> 
> on client i try "ping 192.168.251.11".
> 
> responses come back from both eth0 and eth1, listing each of their
> respective MAC addresses...  it's essentially a race condition at this
> point as to whether i'll get the right MAC address.  ("right" means the
> MAC for server:eth1).
> 
> client# tcpdump -n arp
> Kernel filter, protocol ALL, datagram packet socket
> tcpdump: listening on all devices
> 21:03:05.695089 eth0 > arp who-has 192.168.251.11 tell 192.168.251.25 
>(0:3:47:0:25:80)
> 21:03:05.695405 eth0 < arp reply 192.168.251.11 is-at 0:d0:b7:be:3e:aa 
>(0:3:47:0:25:80)
> 21:03:05.695523 eth0 < arp reply 192.168.251.11 is-at 0:d0:b7:1f:ea:35 
>(0:3:47:0:25:80)
> 
> 
> server# cat /proc/sys/net/ipv4/ip_forward
> 0
> server# cat /proc/sys/net/ipv4/conf/*/proxy_arp
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 
> is this expected?  it seems broken.
> 
> thanks
> -dean
> 
> -
> 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: [OT] Re: 2.4.x, drm, g400 and pci_set_master

[Paul Jakma]

replying to myself..

On Fri, 9 Feb 2001, Paul Jakma wrote:

> why put in mga specific code?

last time i asked why 2x74x hardware iommu wasn't supported i was told
something along the lines of cause generic kernel driver interfaces
wouldn't support it. so support for the alpha hardware would require
changing certain global interfaces (and all the drivers using them).

so for the short-term i guess you will have to implement a dri-local
hack.  However for the 2x17x boards you could make use of the IOMMU
and at least prove the usefullness of it. (and a speed benefit.)

--paulj

-
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: ARP out the wrong interface

[dean gaudet]

oops typo.

On Thu, 8 Feb 2001, dean gaudet wrote:

> this appears to occur with both 2.2.16 and 2.4.1.
>
> server:
>
> eth0 is 192.168.250.11 netmask 255.255.255.0
> eth1 is 192.168.251.11 netmask 255.255.255.0
>
> they're both connected to the same switch.
>
> client:
>
> eth0 is 192.168.251.11 netmask 255.255.255.0

er, i meant to say the client is 192.168.251.25 there.

> connected to the same switch as both of server's eth.
>
> on client i try "ping 192.168.251.11".
>
> responses come back from both eth0 and eth1, listing each of their
> respective MAC addresses...  it's essentially a race condition at this
> point as to whether i'll get the right MAC address.  ("right" means the
> MAC for server:eth1).
>
> client# tcpdump -n arp
> Kernel filter, protocol ALL, datagram packet socket
> tcpdump: listening on all devices
> 21:03:05.695089 eth0 > arp who-has 192.168.251.11 tell 192.168.251.25 
>(0:3:47:0:25:80)
> 21:03:05.695405 eth0 < arp reply 192.168.251.11 is-at 0:d0:b7:be:3e:aa 
>(0:3:47:0:25:80)
> 21:03:05.695523 eth0 < arp reply 192.168.251.11 is-at 0:d0:b7:1f:ea:35 
>(0:3:47:0:25:80)
>
>
> server# cat /proc/sys/net/ipv4/ip_forward
> 0
> server# cat /proc/sys/net/ipv4/conf/*/proxy_arp
> 0
> 0
> 0
> 0
> 0
> 0
> 0
>
> is this expected?  it seems broken.
>
> thanks
> -dean
>
> -
> 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/

ARP out the wrong interface

[dean gaudet]

this appears to occur with both 2.2.16 and 2.4.1.

server:

eth0 is 192.168.250.11 netmask 255.255.255.0
eth1 is 192.168.251.11 netmask 255.255.255.0

they're both connected to the same switch.

client:

eth0 is 192.168.251.11 netmask 255.255.255.0

connected to the same switch as both of server's eth.

on client i try "ping 192.168.251.11".

responses come back from both eth0 and eth1, listing each of their
respective MAC addresses...  it's essentially a race condition at this
point as to whether i'll get the right MAC address.  ("right" means the
MAC for server:eth1).

client# tcpdump -n arp
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on all devices
21:03:05.695089 eth0 > arp who-has 192.168.251.11 tell 192.168.251.25 (0:3:47:0:25:80)
21:03:05.695405 eth0 < arp reply 192.168.251.11 is-at 0:d0:b7:be:3e:aa (0:3:47:0:25:80)
21:03:05.695523 eth0 < arp reply 192.168.251.11 is-at 0:d0:b7:1f:ea:35 (0:3:47:0:25:80)


server# cat /proc/sys/net/ipv4/ip_forward
0
server# cat /proc/sys/net/ipv4/conf/*/proxy_arp
0
0
0
0
0
0
0

is this expected?  it seems broken.

thanks
-dean

-
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] Re: 2.4.x, drm, g400 and pci_set_master

[Paul Jakma]

On Thu, 8 Feb 2001, Alex Deucher wrote:

> There is preliminary support for pcigart in the dri tree.  I believe
> some people have had some success with it.

but there doesn't need to be. DEC 2x17x Alpha chipsets have an IOMMU
for hardware scatter-gather support. (ie generic agpgart for the PCI
bus).

why put in mga specific code? generic support for the IOMMU
capabilities of every recent (since the 20172 chipset at least iirc)
DEC chipset would benefit everything from cheap sound cards, to
high-end IO (scatter-gather even if hardware does not support it and
direct access to/from host memory > 4GB without needing bounce
buffers).

only machines without this IOMMU are the AMD chipset machines, but
they have AGP.

>
> Alex

--paulj

-
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: Bug: 2.4.0 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister

[Thomas Hood]

This problem has been resolved (sort of).  See the follow up to 
"[PATCH] to deal with bad dev->refcnt in unregister_netdevice()"

Thomas Hood

> Here is a patch which may not solve the underlying
> problem but which does prevent the kernel from 
> generating an infinite number of error messages
> on "cardctl eject" and from hanging up on shutdown.
> 
> 
> jdthood@thanatos:/usr/src/kernel-source-2.4.1-ac3/net/core# diff dev.c_ORIG dev.c
> 2558c2558
> < while (atomic_read(&dev->refcnt) != 1) {
> ---
> > while (atomic_read(&dev->refcnt) > 1) {
> -
> 
> The underlying problem is that refcnt is zero or less
> at this point.  This is erroneous.  The error in 
> maintaining the refcnt appears to occur only when 
> I configure the eth0 interface using pump or dhclient.
> Be that as it may, because of the erroneous refcnt,
> this while loop loops forever in the original.  As
> modified it falls through; and this makes the kernel
> usable for me.
> 
> I hope the networking gurus can find the real bug.
> 
> Thomas Hood
>
-
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/

Panic in 2.2.2-pre2 SMP several panics

[Stephen Carr]

Dear Kernel Gurus

Sorry if this is a bit of a repeat - I think the prior message was 
incorrectly addressed.

System Dual 500 Mhz Pentium III 256MB ram with Adaptec 2940 
UW scsi controller - WD disc and HP DAT tape.

I have been getting kernel panics when doing backups over the 
network. I have used both the eepro100 driver and Intel's e100 driver 
the general type of error is a panic - Aiee -- killing the interrupt 
driver.

I have tried the 2.4.0, 2.4.1 and lately the 2.2.2-pre2 kernels.

Panics below for 2.4.2-pre2 kernel.

The error I have got is spkput:over: d0826d4b put:1514 dev:eth0 
kernel BUG at skbuff.c:93 using the e100 driver

The NIC is an Intel Ether ExpressPro 100 set to 100Mbs full duplex 
connected to an HP2424M switch.

I switched to the eepro100 drive and got this panic with system 
"idle" and I was typing sudo -s.

Unable to handle kernel paging request at virtual address 1880 
Bad EIP value. Killing the interrupt handler.

Any ideas?

Stephen Carr


-
Computing Officer
Department of Civil and Environmental Engineering
University of Adelaide
Adelaide, South Australia,
Australia 5005
Phone +618 8303-4313
Fax   +618 8303-4359
Email [EMAIL PROTECTED]
---
This email message is intended only for the addressee(s)
and contains information which may be confidential and/or
copyright.  If you are not the intended recipient please
do not read, save, forward, disclose, or copy the contents
of this email. If this email has been sent to you in error,
please notify the sender by reply email and delete this
email and any copies or links to this email completely and
immediately from your system.  No representation is made
that this email is free of viruses.  Virus scanning is
recommended and is the responsibility of the recipient.

-
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/

paging question

[Daniel Stodden]

hi.

i desperately hope this is not too stupid.

i'm trying to write a driver which depends on giving pci devices
access to somewhat larger amounts of pysical memory. let's say, a
megabyte of contiguous ram.

is it possible to resize such an area later on? i mean: is there some
mechanism available in the kernel to enlarge such a region even if the
area beyond it is already in use?

i understand that this is pretty impossible if some entity depends on
correct physical locations of the pages in question. but couldn't for
example userland memory be copied elsewhere and its new location
simply remapped?

regards,
dns

-- 
___
 mailto:[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: DNS goofups galore...

[Michael H. Warfield]

On Fri, Feb 09, 2001 at 01:50:04AM +, Aaron Denney wrote:
> Michael H. Warfield <[EMAIL PROTECTED]> wrote:
> > But, wait a minute.  CNAME -> CNAME is a "must not".

> Cite the RFC please.  1034 says

> # Domain names in RRs which point at another name should always point at
> # the primary name and not the alias.
> and 
> # domain software should not fail when presented with CNAME
> # chains or loops; CNAME chains should be followed and CNAME loops
> # signalled as an error.
> and
> #- The answer to the query, possibly preface by one or more CNAME
> #  RRs that specify aliases encountered on the way to an answer.
> and
> # Multiple levels of
> # aliases should be avoided due to their lack of efficiency, but should
> # not be signalled as an error.

> It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal.

Hmmm...  Looks like I have had that just about backwards (par for
the course).  RFC 1912 (Common DNS Errors) makes it pretty clear that
other RRs should not point at CNAMEs and that would include CNAMEs
pointing at CNAMEs.  It quotes your same section, 3.6.2, of rfc 1034
for justifying that.

]   Don't use CNAMEs in combination with RRs which point to other names
]   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
]   implement classless in-addr delegation.)  For example, this is
]   strongly discouraged:
]
]   podunk.xx.  IN  MX  mailhost
]   mailhostIN  CNAME   mary
]   maryIN  A   1.2.3.4
]
]   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
]   974] explicitly states that MX records shall not point to an alias
]   defined by a CNAME.  This results in unnecessary indirection in
]   accessing the data, and DNS resolvers and servers need to work more
]   to get the answer.  If you really want to do this, you can accomplish
]   the same thing by using a preprocessor such as m4 on your host files.

That pretty explicity states that MX records should not (and,
according to RFC 974, must not) point to CNAMES.

]   Also, having chained records such as CNAMEs pointing to CNAMEs may
]   make administration issues easier, but is known to tickle bugs in
]   some resolvers that fail to check loops correctly.  As a result some
]   hosts may not be able to resolve such names.

That's a pretty strong recommendation to NOT point CNAMEs to
CNAMEs.  It's not a "must not", but it points out a seeming ambiguity in
RFC 1034.  The very passage you quote:

> # Domain names in RRs which point at another name should always point at
> # the primary name and not the alias.

Doesn't that say that a domain name in a RR should always point
at the primary name.  Doesn't that imply (and thus semi contradict the
rest of that section about loops) that CNAMEs should not point to CNAMEs?

That would appear to make rfc 1034 look ambiguous.  Section
3.6.2 says that RRs should always point to primary names but then
goes on to discuss CNAME loops and states that multiple levels of
aliases should not be signaled as an error.

But then we are down to semantics and the semantics of the RFCs
are defined.  Should and should not are recommendations, not requirements.
Must and must not are requirements.  On that point, I must cede the field
and admit that both CNAME -> MX and CNAME -> CNAME would appear to fall
under the former and not the later.  But MX -> CNAME would appear to be
explicitly prohibited under RFC 974.

> -- 
> Aaron Denney
> -><-
> -
> 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/

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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] maestro3 still oopses?

[dilinger]

The maestro3 driver, included in 2.4.2-pre2 (which I assume is the
same as maestro3-2.4-20010204.tar.gz, I haven't bothered to try it;
I'm perfectly happy w/ my patch), oopses upon shutdown.

I'm submitting my patch again, both to the maestro3 maintainer,
and to lk this time; please see fit to assimilate it into the official
driver release.

It's diff'd against an older maestro3 release (jan 30); it appears
as though the only changes in the new maestro3 release (feb 04) is
to fix this shutdown oops.

Both the patch (maestro3.c.diff) and Zach's original release
(maestro3-2.4-20010130.tar.gz) can be found at:

http://incandescent.mp3revolution.net/kernel/maestro3/.

There is a slight change between my originally submitted patch
and the patch attached was to increment the DRIVER_VERSION, which
I forgot to do initially.


-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [EMAIL PROTECTED]


--- maestro3.c.old  Tue Jan 30 14:39:44 2001
+++ maestro3.c  Thu Feb  8 22:17:00 2001
@@ -28,6 +28,11 @@
  * Shouts go out to Mike "DJ XPCom" Ang.
  *
  * History
+ *  v1.22 - Jan 31 2001 - Andres Salomon <[EMAIL PROTECTED]>
+ *   changed m3_notifier() to shut down device manually, instead
+ *   of calling m3_suspend().. the state saving stuff caused
+ *   oopses on machines w/ pm disabled.
+ *   use pci_module_init() instead of pci_register_driver().
  *  v1.20 - Jan 30 2001 - Zach Brown <[EMAIL PROTECTED]>
  *   get rid of pm callback and use pci_dev suspend/resume instead
  *   m3_probe cleanups, including pm oops think-o
@@ -147,7 +152,7 @@
 
 #define M_DEBUG 1
 
-#define DRIVER_VERSION  "1.20"
+#define DRIVER_VERSION  "1.22"
 #define M3_MODULE_NAME  "maestro3"
 #define PFX M3_MODULE_NAME ": "
 
@@ -277,6 +282,11 @@
 wait_queue_head_t suspend_queue;
 };
 
+
+static int m3_notifier(struct notifier_block *nb, unsigned long event, void *buf);
+static void m3_suspend(struct pci_dev *pci_dev);
+static void check_suspend(struct m3_card *card);
+
 /*
  * an arbitrary volume we set the internal
  * volume settings to so that the ac97 volume
@@ -353,17 +363,11 @@
 return r;
 }
 
-static struct m3_card *devs = NULL;
-
-/*
- * I'm not very good at laying out functions in a file :)
- */
-static int m3_notifier(struct notifier_block *nb, unsigned long event, void *buf);
-static void m3_suspend(struct pci_dev *pci_dev);
-static void check_suspend(struct m3_card *card);
 
+static struct m3_card *devs = NULL;
 struct notifier_block m3_reboot_nb = {m3_notifier, NULL, 0};
 
+
 static void m3_outw(struct m3_card *card,
 u16 value, unsigned long reg)
 {
@@ -2750,12 +2754,32 @@
 static int m3_notifier(struct notifier_block *nb, unsigned long event, void *buf)
 {
 struct m3_card *card;
+int i;
 
 DPRINTK(DPMOD, "notifier suspending all cards\n");
 
-for(card = devs; card != NULL; card = card->next) {
-if(!card->in_suspend)
-m3_suspend(card->pcidev); /* XXX legal? */
+for (card = devs; card != NULL; card = card->next) {
+if (!card->in_suspend) {
+for (i=0;ichannels[i];
+
+if (s->dev_audio == -1)
+continue;
+
+DPRINTK(DPMOD, "stop_adc/dac() device %d\n",i);
+stop_dac(s);
+stop_adc(s);
+}
+
+mdelay(10); /* give the assp a chance to idle.. */
+
+m3_assp_halt(card);
+
+DPRINTK(DPMOD, "powering down apci regs\n");
+m3_outw(card, 0x, 0x54);
+m3_outw(card, 0x, 0x56);
+
+}
 }
 return 0;
 }
@@ -2906,21 +2930,15 @@
 
 static int __init m3_init_module(void)
 {
-if (!pci_present())   /* No PCI bus in this machine! */
-return -ENODEV;
-
+int status;
+   
 printk(KERN_INFO PFX "version " DRIVER_VERSION " built at " __TIME__ " " __DATE__ 
"\n");
 
-if (register_reboot_notifier(&m3_reboot_nb)) {
-printk(KERN_WARNING PFX "reboot notifier registration failed\n");
-return -ENODEV; /* ? */
-}
+status = pci_module_init(&m3_pci_driver);
+if (status == 0)
+register_reboot_notifier(&m3_reboot_nb); /* never fails */
 
-if (!pci_register_driver(&m3_pci_driver)) {
-pci_unregister_driver(&m3_pci_driver);
-return -ENODEV;
-}
-return 0;
+return status;
 }
 
 static void __exit m3_cleanup_module(void)

Re: [PATCH] Small kernel-hacking.tmpl update

[Ingo Oeser]

On Thu, Feb 08, 2001 at 01:50:00PM +, John Levon wrote:
> +   
> +   For more complicated module unload locking requirements, you can set the
> +   can_unload function pointer to your own routine,
> +   which should return 0 if the module is
> +   unloadable, or -EBUSY otherwise.
s/is unloadable/cannot be removed/

This makes it more explicit. You could read "is unloadable" as
"is not loadable", if you are not that familiar with English.

Rest ist correct AFAICS.

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
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] modify ver_linux to check e2fsprogs and more.

[Frédéric L. W. Meunier]

Jochen Striepe wrote:

> tolot:/root # hostname --version
> hostname (GNU sh-utils) 2.0.11
> Written by Jim Meyering.

AFAIK, all distributions use hostname from net-tools, not from
sh-utils.

% hostname -V
net-tools 1.57
hostname 1.99 (2000-02-13)

Why duplicate it (on Linux) ?

-- 
Frédéric L. W. Meunier - http://www.pervalidus.net/
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
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] modify ver_linux to check e2fsprogs and more.

[Steven Cole]

On Thursday 08 February 2001 14:31, Jochen Striepe wrote:
> > Hi,
>
> On 08 Feb 2001, Steven Cole <[EMAIL PROTECTED]> wrote:
> > I have modified the scripts/ver_linux script to provide the following:
>
> [...]
>
> > hostname -V 2>&1 | awk 'NR==1{print "Net-tools ", $NF}'
>
> *Please* consider modifying this. There might be a problem:
>
>
> tolot:/root # hostname -V
> tolot:/root # hostname
> -V
> tolot:/root # hostname --version
> hostname (GNU sh-utils) 2.0.11
> Written by Jim Meyering.

Hmm, I guess the newer verion of hostname broke the old behaviour:
[root@localhost scripts]# hostname -V   
net-tools 1.57
hostname 1.99 (2000-02-13)

But, there is an easy solution:
[root@localhost scripts]# ifconfig --version
net-tools 1.57
ifconfig 1.40 (2000-05-21)

I replaced the old code for Net-tools with this:

ifconfig --version 2>&1 | grep tools | awk \
'NR==1{print "Net-tools ", $NF}'

That should work.  I hope.  Try it please.

A new patch, still against 2.4.1-ac6 is attached.
It should work with 2.4.1-ac5,6,7.

Steven


--- linux/scripts/ver_linux.orig	Thu Feb  8 06:33:52 2001
+++ linux/scripts/ver_linux	Thu Feb  8 19:47:50 2001
@@ -5,32 +5,64 @@
 # differ on your system.
 #
 PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH
-echo '-- Versions installed: (if some fields are empty or look'
-echo '-- unusual then possibly you have very old versions)'
+echo 'If some fields are empty or look unusual you may have an old version.'
+echo 'Compare to the current minimal requirements in Documentation/Changes.'
+echo ' '
+
 uname -a
-insmod -V  2>&1 | awk 'NR==1 {print "Kernel modules",$NF}'
+echo ' '
+
 echo "Gnu C " `gcc --version`
+
 make --version 2>&1 | awk -F, '{print $1}' | awk \
-  '/GNU Make/{print "Gnu Make  ",$NF}'
+  '/GNU Make/{print "Gnu make  ",$NF}'
+
 ld -v 2>&1 | awk -F\) '{print $1}' | awk \
-  '/BFD/{print "Binutils  ",$NF}'
-ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | sed -e 's/\.so$//' \
-  | awk -F'[.-]'   '{print "Linux C Library" $(NF-2)"."$(NF-1)"."$NF}'
-echo -n "Dynamic linker "
-ldd -v > /dev/null 2>&1 && ldd -v || ldd --version |head -1
+  '/BFD/{print "binutils  ",$NF}'
+
+mount --version | awk -F\- '{print "util-linux", $NF}'
+
+insmod -V  2>&1 | awk 'NR==1 {print "modutils  ",$NF}'
+
+tune2fs 2>&1 | grep tune2fs | sed 's/,//' |  awk \
+'NR==1 {print "e2fsprogs ", $2}'
+
+reiserfsck 2>&1 | grep reiserfsprogs | awk \
+'NR==1{print "reiserfsprogs ", $NF}'
+
+cardmgr -V 2>&1| grep version | awk \
+'NR==1{print "pcmcia-cs ", $3}'
+
+pppd --version 2>&1| grep version | awk \
+'NR==1{print "PPP   ", $3}'
+
+isdnctrl 2>&1 | grep version | awk \
+'NR==1{print "isdn4k-utils  ", $NF}'
+
+ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | sed \
+-e 's/\.so$//' | awk -F'[.-]'   '{print "Linux C Library" \
+$(NF-2)"."$(NF-1)"."$NF}'
+
+ldd -v > /dev/null 2>&1 && ldd -v || ldd --version |head -1 | awk \
+'NR==1{print "Dynamic linker (ldd)  ", $NF}'
+
 ls -l /usr/lib/lib{g,stdc}++.so  2>/dev/null | awk -F. \
'{print "Linux C++ Library  " $4"."$5"."$6}'
+
 ps --version 2>&1 | awk 'NR==1{print "Procps", $NF}'
-mount --version | awk -F\- '{print "Mount ", $NF}'
-hostname -V 2>&1 | awk 'NR==1{print "Net-tools ", $NF}'
+
+ifconfig --version 2>&1 | grep tools | awk \
+'NR==1{print "Net-tools ", $NF}'
+
 # Kbd needs 'loadkeys -h',
 loadkeys -h 2>&1 | awk \
 '(NR==1 && ($3 !~ /option/)) {print "Kbd   ", $3}'
+
 # while console-tools needs 'loadkeys -V'.
 loadkeys -V 2>&1 | awk \
 '(NR==1 && ($2 ~ /console-tools/)) {print "Console-tools ", $3}'
-reiserfsck --bogusarg 2>&1 | grep reiserfsprogs | awk \
-'NR==1{print "Reiserfsprogs ", $NF}'
+
 expr --v 2>&1 | awk 'NR==1{print "Sh-utils  ", $NF}'
+
 X=`cat /proc/modules | sed -e "s/ .*$//"`
 echo "Modules Loaded "$X

Re: DNS goofups galore...

[Aaron Denney]

Michael H. Warfield <[EMAIL PROTECTED]> wrote:
>   But, wait a minute.  CNAME -> CNAME is a "must not".

Cite the RFC please.  1034 says
# Domain names in RRs which point at another name should always point at
# the primary name and not the alias.
and 
# domain software should not fail when presented with CNAME
# chains or loops; CNAME chains should be followed and CNAME loops
# signalled as an error.
and
#- The answer to the query, possibly preface by one or more CNAME
#  RRs that specify aliases encountered on the way to an answer.
and
# Multiple levels of
# aliases should be avoided due to their lack of efficiency, but should
# not be signalled as an error.

It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal.

-- 
Aaron Denney
-><-
-
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: Linux 2.4.1-ac7

[Kurt Roeckx]

On Thu, Feb 08, 2001 at 08:12:39PM -0200, Rik van Riel wrote:
> On Thu, 8 Feb 2001, Alan Cox wrote:
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> > 
> > 2.4.1-ac7
> > o   Rebalance the 2.4.1 VM  (Rik van Riel)
> > | This should make things feel a lot faster especially
> > | on small boxes .. feedback to Rik
> 
> I'd really like feedback from people when it comes to this
> change. The change /should/ fix most paging performance bugs
> because it makes kswapd do the right amount of work in order
> to solve the free memory shortage every time it is run.

I just tested ac8.

If I run this test, the system gets really slow.  It takes about
a second between the time I press a key, and the time it appears
on the screen.  The load goes way up.  Everything seems to block.

This is a box with 64 MB or RAM, and 32 MB of swap.  There isn't
much running on the box while doing this, only dnetc.

It starts to get slow from the time the process starts is about
70 MB.  Then you really hear the disk work.  It ended up at about
75 MB, where it got killed by the OOM killer. (For once it killed
the right thing!)

I ran a vmstat 1, while doing this, and have attached the output.

It ran for serval minutes.  The process itself took about 1
minutes of CPU time, and so did kswapd.  It took atleast 5
minutes real time.

I once did just the same with 2.4.0, it took more like 30 minutes
then, and I ended up killing the process myself.


Kurt



 procs  memoryswapiosystem cpu
 r b w  swpd  free  buff cache  si  so   bi   bo   in   cs  us  sy  id
 1 0 0 16580  1808  1200 43336   0   0   834  130   25  93   2   5
 1 0 0 16704  1804  1200 43460   0   000  1164 100   0   0
 1 0 0 16704  1804  1200 43460   0   000  1204 100   0   0
 1 0 0 16784  1808  1200 43540   0   000  1026  99   1   0
 1 0 0 16904  1808  1200 43660   0   000  1017  99   1   0
 1 0 0 16988  1808  1200 43744   0   000  130   32  99   1   0
 1 0 0 16988  1808  1200 43744   0   000  136   18 100   0   0
 1 0 0 17152  1808  1200 43908   0   000  110   14 100   0   0
 1 0 0 17152  1808  1200 43908   0   003  110   10 100   0   0
 2 0 0 17112  1428  1204 43960   0   0  3844  142   63  98   2   0
 2 0 0 17268  1428  1204 43016   0   0  1300  133   46 100   0   0
 2 0 0 17344  1428  1204 41980   0   0  1280  110   47  97   3   0
 2 0 0 17548  1428  1204 41104   0   0  1290  116   48  98   2   0
 2 0 0 17604  1428  1204 40056   0   0  1280  102   45  97   3   0
 2 0 0 17820  1428  1208 39188   0   0  1290  106   49  97   3   0
 2 0 0 17972  1428  1208 38288   0   0  1280  108   48  99   1   0
 2 0 0 18136  1428  1208 37352   0   0  1290  104   46  95   5   0
 2 0 0 18140  1428  1208 36296   0   0  1280  107   49  98   2   0
 2 0 0 18140  1428  1208 35212   0   0  1290  108   54  96   4   0
 2 0 0 18140  1428  1208 34108   0   0  1280  105   44  99   1   0
 2 0 0 18140  1428  1208 33208   0   000  126   47  96   4   0
 procs  memoryswapiosystem cpu
 r b w  swpd  free  buff cache  si  so   bi   bo   in   cs  us  sy  id
 2 0 0 18116  1456  1168 32144   0   0  1290  127   49  96   4   0
 2 0 0 18116  1368  1100 31236   0   0  1280  110   46  97   3   0
 2 0 0 18752  1304  1016 30944   0   0  1291  107   51  97   3   0
 2 0 0 18752  2020   908 29944   0   0  1280  109   49 100   0   0
 2 0 0 18752  1296   904 29596   0   0  1290  104   45  95   5   0
 2 0 0 18752  1300   880 28788   0 248  128   62  106   42  97   3   0
 2 1 0 18752  1236   880 27864   0 1896   73  531  162   52  95   5   0
 2 0 0 18752   948   880 27056   0   0  1840  128   43  96   4   0
 2 0 0 18752   948   856 26008   0   000  105   41  98   2   0
 2 0 0 19688   980   840 26024   0 1360  129  340  133   50  97   3   0
 2 0 0 19688   948   828 25028   0 624  128  156  114   46  98   2   0
 2 0 0 20628   948   812 25008   0 192  129   48  108   45  95   5   0
 2 0 0 23420   948   784 26956   0 1140  128  285  125   49  97   3   0
 2 0 0 23464   948   676 26604   0   0  1300  105   49  99   1   0
 2 0 0 23560   948   564 25780   0 820  128  214  132   43  95   5   0
 2 1 0 23840   948   560 25036   0 244   73   61  109   47  96   4   0
 2 0 0 23940   948   556 24184   0 1768   56  445  152   61  94   6   0
 2 0 0 23928   948   540 23144   0   0  1430  111   55  98   2   0
 2 0 0 24168   948   532 22352   0 164  129   41  106   48  96   4   0
 2 0 0 29044   948   504 26240   0 120  128   30  105   42  97   3   0
 2 0 0 31476   948   412 28256   0 316  129   79  126   48  96   4   0
 procs  memoryswapiosystem cpu
 r b w  swpd  free  buff cache  si  so   bi   bo   in   cs  us  sy  id
 3 0 0 31476   948   416 27300   0 1580  193  413  269   68  97   3   0
 2 0 0 32580   948 

Re: dentry cache order 7 is broken

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
dean gaudet  <[EMAIL PROTECTED]> wrote:
>
>if you've got 512Mb of RAM you end up with a dentry cache of order 7 --
>65536 entries.
>
>this results in a D_HASHBITS of 16.  if you look at d_hash it contains
>this code:
>
>   hash = hash ^ (hash >> D_HASHBITS) ^ (hash >> D_HASHBITS*2);

Cool.

Just remove the third part altogether.  The "hash" is only 32 bits
anyway (even on 64-bit platforms, as we don't want to blow up the dentry
size unnecessarily).  And with most machines with reasonable memory, you
already get fine distribution with just two terms (ie you don't lose any
bits), and it speeds it up and avoids the problem you see.

Thanks..

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/

Linux-2.4.2-pre2

[Linus Torvalds]

Ok, the patch is reasonably big, mainly due to a new architecture (cris)
and some updates to others (arm and mips).

But what's interesting here are actually three very small patches:

 - mm/memory.c (PageReserved() check): this could corrupt the shared zero
   page if you used direct IO, and thus make your system unusable
 - elevator fix (another missed re-initialization in __make_request(), and
   this time we made sure to check that everything else _is_ initialized)
 - IDE driver multi-mode write fix (ide_multwrite()).

The first would only hit you if you used raw IO (and had some unlucky
timing etc), and very few people do.

The second can cause disk corruption with pretty much any disk (seen at
least on SCSI under heavy load). Not necessarily easy to trigger, but
still..

The third can cause disk corruption on IDE disks if you are using PIO
writes with multi-mode and irq unmasking enabled.

All three are quite nasty, but not all that easy to trigger (and have been
around for ages in the 2.3.x series - which only goes to show you how
important it is to have gotten a lot of new testers). Special thanks go to
Russell King for debugging the IDE driver thing with some heroic tracing
stuff.

I'd like people to test it out a bit before I'll make a real 2.4.2
release, but the three bugs do make it clear that a 2.4.2 will have to
happen soonish. The rest of the patches are quite cosmetic in comparison
even if they are much bigger..

Linus

- ChangeLog -

-pre2:
 - driver sync up with Alan
 - Andrew Morton: wakeup cleanup and race fix
 - Paul Mackerras: macintosh driver updates.
 - don't trust "page_count()" on reserved pages!
 - Russell King: fix serious IDE multimode write bug!
 - me, Jens, others: fix elevator problem
 - ARM, MIPS and cris architecture updates
 - alpha updates: better page clear/copy, avoid kernel lock in execve
 - USB and firewire updates
 - ISDN updates
 - Irda updates

-pre1:
 - XMM: don't allow illegal mxcsr values
 - ACPI: handle non-existent battery strings gracefully
 - Compaq Smart Array driver update
 - Kanoj Sarcar: serial console hardware flow control support
 - ide-cs: revert toc-valid cache checking in 2.4.1
 - Vojtech Pavlik: update via82cxxx driver to handle the vt82c686
 - raid5 graceful failure handling fix
 - ne2k-pci: enable device before asking the irq number
 - sis900 driver update
 - riva FB driver update
 - fix silly inode hashing pessimization
 - add SO_ACCEPTCONN for SuS
 - remove modinfo hack workaround, all newer modutils do it correctly
 - datagram socket shutdown fix
 - mark process as running when it takes a page-fault

-
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/

Oops when loading airo.o, 2.4.1-ac7

[Ookhoi]

Hi!

root@tilde:~# lsmod
Module  Size  Used by
root@tilde:~# lsmod
Module  Size  Used by
root@tilde:~# insmod airo
Using /lib/modules/2.4.1-ac7/pcmcia/airo.o
root@tilde:~# lsmod
Module  Size  Used by
airo   25232   0  (unused)
root@tilde:~# cat /proc/driver/aironet/eth1/Config 
Segmentation fault
root@tilde:~# uname -a
Linux tilde 2.4.1-ac7 #1 Fri Feb 9 01:02:00 CET 2001 i586 unknown

airo is a module for the cisco aironet wireless network cards. I have a
pcmcia 342, and a pci 342 (which just looks like a pcmcia card mounted
on a pci board). The pcmcia cards in my notebook seemes to work ok
(can't test, but the /proc interface works fine and the card reacts on
that), but the pci in my pc gives the above problem. Also tried -ac5.

/var/log/syslog only says:
Feb  9 01:52:52 tilde kernel: airo:  Probing for PCI adapters
Feb  9 01:52:52 tilde kernel: airo: Doing fast bap_reads
Feb  9 01:52:52 tilde kernel: airo: MAC enabled eth1 0:40:96:45:be:e6
Feb  9 01:52:52 tilde kernel: airo:  Finished probing for PCI adapters
Feb  9 01:53:05 tilde kernel: Unable to handle kernel NULL pointer dereference at 
virtual address 0034
Feb  9 01:53:05 tilde kernel:  printing eip:
Feb  9 01:53:05 tilde kernel: c48ec688
Feb  9 01:53:05 tilde kernel: *pde = 
Feb  9 01:53:05 tilde kernel: Oops: 
Feb  9 01:53:05 tilde kernel: CPU:0

The system sometimes seemes to be fine after this, and sometimes it
freezes. The nic doesn't work. 

What can I do to provide more info?

Ookhoi
-
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] cosmetic: missing includes (net/sched)

[Werner Almesberger]

This patch for 2.4.2-pre1 adds a few includes I forgot in sch_atm.c and
sch_dsmark.c

Their absence didn't cause any kernel compilation problems, but it may
well in the future (or when compiling things in a different context,
that's why I, ehm ... finally, noticed the problem).

- Werner

 patch 

--- linux.orig/net/sched/sch_atm.c  Wed Mar 22 08:38:27 2000
+++ linux/net/sched/sch_atm.c   Fri Feb  9 01:56:07 2001
@@ -5,6 +5,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
--- linux.orig/net/sched/sch_dsmark.c   Mon Jan 22 22:30:21 2001
+++ linux/net/sched/sch_dsmark.cFri Feb  9 01:56:58 2001
@@ -6,6 +6,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include  /* for pkt_sched */
 #include 

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
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] starfire reads irq before pci_enable_device.

[Ion Badulescu]

On Thu, 8 Feb 2001, Donald Becker wrote:

> > Or we can just tell people, "hey, don't use this 64-bit PCI card on a real 
> > 64-bit system, it's broken by design"? I don't think that's a good 
> > solution either.
> 
> This is not a 64 bit PCI issue.  

I know. It was just an ironic comment: we have a card with a 64-bit PCI 
bus, we have a 64-bit system which very likely has some 64-bit PCI slots 
on its motherboard, perfect match, right? Well, au contraire, the 
performance is going to suck big-time, at least for Rx.

> It is an issue with the protocol
> stack.  The IP protocol handling code must expect that the header words
> will be misaligned in some circumstances.

I won't get into this...

> It's amusing that a full receive copy is added without any concern, in
> the same discussion where zero-copy transmit is treated as a holy grail!

Amusing? Maybe. Zerocopy will still help with Tx, and with Rx we're just 
trying to contain the damage, *with the existent stack*.

> This might be a transceiver preamble issue with the specific
> transceivers on the recent cards.  Debugging this type of problem
> sometimes requires a D-Oscope on the MII data pins.
> 
> Normally I would suspect a timing problem with a very fast machine, but
> the Starfire hardware generates its own preamble and clock signals, not
> the driver code.

See my previous mail. It turned out to be just a confused chipset.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
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: Mem detection problem

[Adam Schrotenboer]

Dunlap, Randy wrote:

>> From: Adam Schrotenboer [mailto:[EMAIL PROTECTED]]
>> 
>> This is actually a repost of a problem that received few 
>> serious replies (IMNSHO).
> 
> 
> Well, I claim not to have ignored it.
> I have gone thru the entire patch-2.4.1 file and can't see
> anything there that would cause what you are seeing.
> 
> You aren't using ACPI, right?  (not in your log files)
> [That just makes the patch file of interest smaller.]

Nope, result of grep ACPI .config
# CONFIG_ACPI is not set

> 
> 
>> Basically 2.4.0 detects 192 MB(maybe 191, but big whoop) of 
>> memory. This 
>> is correct. However, 2.4.1-ac6 (as did Linus-blessed 2.4.1) 
>> detects 64. 
>> The problem is simple. 2.4.1 and later for some reason uses bios-88, 
>> instead of e820.
>> 
>> Attached are the dmesgs from 2.4.0 and 2.4.1-ac6.
> 
> 
> Have you booted 2.4.0 again (lately)?  You log file is from
> Jan-08-2001.  It may also report only 64 MB now, based on
> some kind of BIOS change (or ESCD ...) since Jan-08.

Yes I have booted 2.4.0 much more recently than Jan 8.
Just checked, Jan 8 is the build date, not the boot date.

> 
> 
> Someone else with a similar "problem" actually had a fruit fly
> in one of their slots that caused a problem, so I would ask that
> you (a) boot 2.4.0 again to see if it works now and (b) remove
> adapters, clean slots, reseat adapters, boot 2.4.1 again.
> 
> ~Randy
> 
Weird, but might be worth the try, about as soon as I grab my 
screwdriver from my car (in parking lot ~1/5 mile away)

-
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] redundant call to vm_enough_memory

[Werner Almesberger]

This patch removes a redundant call to vm_enough_memory from
mm/mmap.c:sys_brk. Exactly the same test is made in mm/mmap.c:do_brk,
with the exception that the latter is done after calling do_munmap.

Note that do_munmap in do_brk has no effect when called from sys_brk,
because the check for find_vma_intersection only lets us pass if there
are no memory objects in the way.

The patch is for 2.4.2-pre1, with my /proc/sys/vm/max_map_count patch
applied. (The latter only changes some offsets, not the context of this
patch.)

- Werner

 patch 

--- linux.orig/mm/mmap.cMon Jan 29 17:10:41 2001
+++ linux/mm/mmap.c Fri Feb  9 01:12:55 2001
@@ -148,10 +149,6 @@
if (find_vma_intersection(mm, oldbrk, newbrk+PAGE_SIZE))
goto out;
 
-   /* Check if we have enough memory.. */
-   if (!vm_enough_memory((newbrk-oldbrk) >> PAGE_SHIFT))
-   goto out;
-
/* Ok, looks good - let it rip. */
if (do_brk(oldbrk, newbrk-oldbrk) != oldbrk)
goto out;
-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
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: DNS goofups galore...

[Johannes Erdfelt]

On Thu, Feb 08, 2001, Michael H. Warfield <[EMAIL PROTECTED]> wrote:
>   But, wait a minute.  CNAME -> CNAME is a "must not".  MX -> CNAME
> is a "should not".  The "should not" leaves it to be implimentation
> dependent and not an outright ban.  Sooo...

Actually, I had this conversation recently. I checked a variety of
places and I couldn't find an RFC that said CNAME -> CNAME is a "must
not". In fact I found this snippet in rfc1912 which seems to imply that
it is legal:

   Also, having chained records such as CNAMEs pointing to CNAMEs may
   make administration issues easier, but is known to tickle bugs in
   some resolvers that fail to check loops correctly.  As a result some
   hosts may not be able to resolve such names.

*shrug*

JE

-
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: dentry cache order 7 is broken

[dean gaudet]

that appears to do it :)

-dean

On Thu, 8 Feb 2001, David S. Miller wrote:

>
> dean gaudet writes:
>  > also, for order > 7, was the real intention to use a shift of
>  > (order*2)&31?
>
> No, the whole thing is buggered.  How stupid, my fault.
> It was the 64-bit platform fascist at work :-)
>
> How does this work for you (against 2.4.x)?
>
> --- fs/dcache.c.~1~   Tue Feb  6 23:00:58 2001
> +++ fs/dcache.c   Thu Feb  8 00:09:10 2001
> @@ -696,7 +696,8 @@
>  static inline struct list_head * d_hash(struct dentry * parent, unsigned long hash)
>  {
>   hash += (unsigned long) parent / L1_CACHE_BYTES;
> - hash = hash ^ (hash >> D_HASHBITS) ^ (hash >> D_HASHBITS*2);
> + hash = hash ^ (hash >> D_HASHBITS) ^
> + (hash >> (D_HASHBITS+(D_HASHBITS/2)));
>   return dentry_hashtable + (hash & D_HASHMASK);
>  }
>
> -
> 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: [PATCH] starfire reads irq before pci_enable_device.

[Donald Becker]

On Thu, 8 Feb 2001, Ion Badulescu wrote:

> On Thu, 8 Feb 2001, Donald Becker wrote:
> 
> > > > The align-copy should *never* be required because the alignment differs
> > > > between DIX and E-II encapsulated packets.  The machine shouldn't crash
> > > > because someone sends you a different encapsulation type!
> > 
> > This is true for a number of drivers -- triggering the copy-align code
> > might eliminate the misaligned traps on your local network, but it's not
> > a solution.
> 
> Ok, so what *is* a good solution then? I'm not arguing that unaligned 
> memory access traps should be avoided because they are deadly (they 
> shouldn't be), but because they are costly.
> 
> Or we can just tell people, "hey, don't use this 64-bit PCI card on a real 
> 64-bit system, it's broken by design"? I don't think that's a good 
> solution either.

This is not a 64 bit PCI issue.  It is an issue with the protocol
stack.  The IP protocol handling code must expect that the header words
will be misaligned in some circumstances.

It's amusing that a full receive copy is added without any concern, in
the same discussion where zero-copy transmit is treated as a holy grail!

> >The MII read code is no longer reliable.  I spent twenty minutes at
> >the show, but couldn't figure out the problem.  I haven't been able
> >reproduce the problem locally with my 2.2 code and somewhat older
> >hardware.
> 
> Yes, I've noticed this too, the PHY doesn't seem to get detected in all 
> cases, and it's pretty random at that. Other times the same PHY gets 
> detected multiple times at different addresses.

This might be a transceiver preamble issue with the specific
transceivers on the recent cards.  Debugging this type of problem
sometimes requires a D-Oscope on the MII data pins.

Normally I would suspect a timing problem with a very fast machine, but
the Starfire hardware generates its own preamble and clock signals, not
the driver code.

> The good news is that the same code behaves the same on 2.4 and 2.2, so 
> I think it's not a core kernel issue. I'll try to track it down; 

It's likely easier to use the starfire-diag program from
  http://www.scyld.com/diag/index.html

Donald Becker   [EMAIL PROTECTED]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210   Second Generation Beowulf Clusters
Annapolis MD 21403  410-990-9993

-
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/

One liner: compile failure with 2.2.19pre9 aic7xxx

[Shane Wegner]

Hi,

Seems aic7xxx.h got lost.

--- drivers/scsi/hosts.c.orig   Thu Feb  8 16:32:00 2001
+++ drivers/scsi/hosts.cThu Feb  8 16:29:48 2001
@@ -136,7 +136,7 @@
 #endif

 #ifdef CONFIG_SCSI_AIC7XXX
-#include "aic7xxx.h"
+#include "aic7xxx/aic7xxx.h"
 #endif

 #ifdef CONFIG_SCSI_IPS

-- 
Shane Wegner: [EMAIL PROTECTED]
  http://www.cm.nu/~shane/
PGP:  1024D/FFE3035D
  A0ED DAC4 77EC D674 5487
  5B5C 4F89 9A4E FFE3 035D
-
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: DNS goofups galore...

[Michael H. Warfield]

On Thu, Feb 08, 2001 at 04:11:39PM -0800, H. Peter Anvin wrote:
> "Michael H. Warfield" wrote:
> > 
> > > Please explain how there is any different between an CNAME or MX pointing
> > > to an A record in a different SOA versus an MX pointing to a CNAME
> > > pointing to an A record where at least one pair is local (same SOA).
> > 
> > Ah!  But now you are placing conditions on it (that at least one
> > pair is local).  That is the very fine distinction that makes up the
> > "not quite" in the "almost" above and the difference between the "should
> > not" vs the "must not" in the specifications.  You basically can't qualify
> > it by saying "you can do this, but only if one pair is in the same SOA".


> No.  My point is that potential for inefficiency is not a valid reason
> for banning something outright.  This should be an administrative
> decision, nothing more.

But, wait a minute.  CNAME -> CNAME is a "must not".  MX -> CNAME
is a "should not".  The "should not" leaves it to be implimentation
dependent and not an outright ban.  Sooo...

I personally have no problem with Bind 9.x prohibiting an
MX -> CNAME, but that's an implimentation issue.

In case people have tuned in late, there have been some rather
radical swings in Bind policy since Bind 4.x.

Bind 8.x decided to ENFORCE (with a vengence) the character set
policies dictated by RFC.  This was (so they claimed) to protect poorly
coded programs that were prone to blowing chunks and doing Chernobyl
imitations on getting illegal characters in host names.  Of course that
also caused zones with underscores in names (more common than what you
would think) to crap all over themselves when unsuspecting (i.e. failure
to read warnings) admins upgraded.

Bind 9.0 went back to the old 4.9 policy on characters (allow
what can be entered and poorly coded programs are on their own) but started
enforcing a requirement for a TTL directive and making the SOA TTL field
the true minimum TTL that it was defined as (instead of a default like
Bind 8 and 4 and previous used it as).  I figured I was all set, since I,
of course, had upgraded all MY zone files already.  Imagine my surprise
when 9.0 would not even load because OVER HALF of the 200+ zones I'm
responsible for or host did NOT have the $TTL directive!  It was assholes
and elbows for a not so brief but really intense time while I updated those
$@$%#@ zone files!

You don't like the Bind enforcement of the DNS policy, bitch to
the ISC bunch.  They can be swayed (all too often, it appears).  If enough
DNS administrators really want to go against the "should not", maybe
they will make it configurable (Actually, I didn't think it really outright
prohibited it in the first place, but...  Oh well...)  There are lots
of other things in the DNS that need to be killed DEAD with a stake
through the heart like CNAME with other data (what is THAT suppose to
mean).  I run into lookups on sites with CNAMES and A records for a host!
I suppose one can come up with a hierachial reason for doing such
byzantine things, but do you REALLY want to?  In applying the KISS
principle (admitedly an oxymoron when it comes to DNS) I can see some
people wanting to ban MX -> CNAME in general if, for no other reason,
than to insure that you will do it only if you have really STRONG
reasons for doing it.

>   -hpa

> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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] xirc2ps_cs.c SET_MODULE_OWNER(dev)

[Thomas Hood]

I presume that this change needs to be made.
(All of the drivers/net/pcmcia/*.c need the change.)
 // Thomas

jdthood@thanatos:/usr/src/kernel-source-2.4.1-ac3/drivers/net/pcmcia# diff -Naur 
xirc2ps_cs.c_ORIG xirc2ps_cs.c
--- xirc2ps_cs.c_ORIG   Thu Feb  8 19:11:54 2001
+++ xirc2ps_cs.cThu Feb  8 19:12:01 2001
@@ -637,6 +637,7 @@
 link->irq.Instance = dev;
 
 /* Fill in card specific entries */
+SET_MODULE_OWNER(dev);
 dev->hard_start_xmit = &do_start_xmit;
 dev->set_config = &do_config;
 dev->get_stats = &do_get_stats;
-
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: Mem detection problem

[Dunlap, Randy]

> From: Adam Schrotenboer [mailto:[EMAIL PROTECTED]]
> 
> This is actually a repost of a problem that received few 
> serious replies (IMNSHO).

Well, I claim not to have ignored it.
I have gone thru the entire patch-2.4.1 file and can't see
anything there that would cause what you are seeing.

You aren't using ACPI, right?  (not in your log files)
[That just makes the patch file of interest smaller.]

> Basically 2.4.0 detects 192 MB(maybe 191, but big whoop) of 
> memory. This 
> is correct. However, 2.4.1-ac6 (as did Linus-blessed 2.4.1) 
> detects 64. 
> The problem is simple. 2.4.1 and later for some reason uses bios-88, 
> instead of e820.
> 
> Attached are the dmesgs from 2.4.0 and 2.4.1-ac6.

Have you booted 2.4.0 again (lately)?  You log file is from
Jan-08-2001.  It may also report only 64 MB now, based on
some kind of BIOS change (or ESCD ...) since Jan-08.

Someone else with a similar "problem" actually had a fruit fly
in one of their slots that caused a problem, so I would ask that
you (a) boot 2.4.0 again to see if it works now and (b) remove
adapters, clean slots, reseat adapters, boot 2.4.1 again.

~Randy

-
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: DNS goofups galore...

[H. Peter Anvin]

"Michael H. Warfield" wrote:
> 
> > Please explain how there is any different between an CNAME or MX pointing
> > to an A record in a different SOA versus an MX pointing to a CNAME
> > pointing to an A record where at least one pair is local (same SOA).
> 
> Ah!  But now you are placing conditions on it (that at least one
> pair is local).  That is the very fine distinction that makes up the
> "not quite" in the "almost" above and the difference between the "should
> not" vs the "must not" in the specifications.  You basically can't qualify
> it by saying "you can do this, but only if one pair is in the same SOA".
> 

No.  My point is that potential for inefficiency is not a valid reason
for banning something outright.  This should be an administrative
decision, nothing more.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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] starfire reads irq before pci_enable_device.

[Ion Badulescu]

On Thu, 8 Feb 2001, Ion Badulescu wrote:

> >The MII read code is no longer reliable.  I spent twenty minutes at
> >the show, but couldn't figure out the problem.  I haven't been able
> >reproduce the problem locally with my 2.2 code and someone older
> >hardware.
> 
> Yes, I've noticed this too, the PHY doesn't seem to get detected in all 
> cases, and it's pretty random at that. Other times the same PHY gets 
> detected multiple times at different addresses.
> 
> The good news is that the same code behaves the same on 2.4 and 2.2, so 
> I think it's not a core kernel issue. I'll try to track it down; 
> fortunately it doesn't affect card functionality as long as the user 
> sticks with autonegotiation.

Kicking the chip *hard* when probing can do wonders. :-)

The attached patch fixes MII detection for me, reliably. It's the same
thing my BSDI driver does. The patch is against the previous version I
sent to the list; it applies almost cleanly to 2.4.1-vanilla and the
reject is easy to apply manually.

Full patch (for Jeff) will follow later.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
---
--- linux-2.4-boxter/drivers/net/starfire.c Thu Feb  8 16:03:05 2001
+++ linux-2.4-zc/drivers/net/starfire.c Thu Feb  8 16:02:26 2001
@@ -160,6 +160,7 @@
 #include 
 #include 
 #include 
+#include 
 #include  /* Processor type for cache alignment. */
 #include 
 #include 
@@ -519,6 +520,7 @@
static int printed_version = 0;
long ioaddr;
int drv_flags, io_size;
+   int boguscnt;
 
card_idx++;
option = card_idx < MAX_UNITS ? options[card_idx] : 0;
@@ -586,8 +588,23 @@
   i % 16 != 15 ? " " : "\n");
 #endif
 
+   /* Issue soft reset */
+   writel(0x8000, ioaddr + TxMode);
+   udelay(1000);
+   writel(0, ioaddr + TxMode);
+
/* Reset the chip to erase previous misconfiguration. */
writel(1, ioaddr + PCIDeviceConfig);
+   boguscnt = 1000;
+   while (--boguscnt > 0) {
+   udelay(10);
+   if ((readl(ioaddr + PCIDeviceConfig) & 1) == 0)
+   break;
+   }
+   if (boguscnt == 0)
+   printk("%s: chipset reset never completed!\n", dev->name);
+   /* wait a little longer */
+   udelay(1000);
 
dev->base_addr = ioaddr;
dev->irq = irq;
@@ -630,14 +647,27 @@
 
if (drv_flags & CanHaveMII) {
int phy, phy_idx = 0;
+   int mii_status;
for (phy = 0; phy < 32 && phy_idx < 4; phy++) {
-   int mii_status = mdio_read(dev, phy, 1);
-   if (mii_status != 0x  &&  mii_status != 0x) {
+   mdio_write(dev, phy, 0, 0x8000);
+   udelay(500);
+   boguscnt = 1000;
+   while (--boguscnt > 0)
+   if ((mdio_read(dev, phy, 0) & 0x8000) == 0)
+   break;
+   if (boguscnt == 0) {
+   printk("%s: PHY reset never completed!\n", dev->name);
+   continue;
+   }
+   mii_status = mdio_read(dev, phy, 1);
+   if (mii_status != 0x) {
np->phys[phy_idx++] = phy;
np->advertising = mdio_read(dev, phy, 4);
printk(KERN_INFO "%s: MII PHY found at address %d, 
status "
   "0x%4.4x advertising %4.4x.\n",
   dev->name, phy, mii_status, 
np->advertising);
+   /* there can be only one PHY on-board */
+   break;
}
}
np->mii_cnt = phy_idx;
@@ -663,7 +693,11 @@
/* ??? Should we add a busy-wait here? */
do
result = readl(mdio_addr);
-   while ((result & 0xC000) != 0x8000 && --boguscnt >= 0);
+   while ((result & 0xC000) != 0x8000 && --boguscnt > 0);
+   if (boguscnt == 0)
+   return 0;
+   if ((result & 0x) == 0x)
+   return 0;
return result & 0x;
 }
 


-
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: DNS goofups galore...

[Michael H. Warfield]

On Thu, Feb 08, 2001 at 04:01:30PM -0800, H. Peter Anvin wrote:

> > > Wouldn't that be true for any CNAME anyway?

> > That's the point...

> > In other words, you do a lookup, you start with a primary lookup
> > and then possibly a second lookup to resolve an MX or CNAME.  It's only
> > the MX that points to a CNAME that results in yet another lookup.  An
> > MX pointing to a CNAME is almost (almost, but not quite) as bad as a
> > CNAME pointing to a CNAME.


> There is no reducibility problem for MX -> CNAME, unlike the CNAME ->
> CNAME case.

> Please explain how there is any different between an CNAME or MX pointing
> to an A record in a different SOA versus an MX pointing to a CNAME
> pointing to an A record where at least one pair is local (same SOA).

Ah!  But now you are placing conditions on it (that at least one
pair is local).  That is the very fine distinction that makes up the
"not quite" in the "almost" above and the difference between the "should
not" vs the "must not" in the specifications.  You basically can't qualify
it by saying "you can do this, but only if one pair is in the same SOA".

>   -hpa

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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: nfs_refresh_inode: inode number mismatch

[Jun Sun]

Russell King wrote:
> 
> Neil Brown writes:
> > On Wednesday February 7, [EMAIL PROTECTED] wrote:
> > > This is a weird problem that I am looking at right.  It seems to indicate a
> > > bug in the nfs server.
> > >
> > > I have a MIPS machine that boots from a NFS root fs hosted on a redhat 6.2
> > > workstation.  Everything works fine except that after a few reboots I start to
> > > see the error messages like the following:
> >
> > What verison of Linux?  If it is less than 2.2.18, then an upgrade
> > will help you a lot.
> >
> > If it is >= 2.2.18, I will look some more.
> 
> Note that you need to upgrade the server, not the client.  Also, make sure
> you don't reboot the client more than once in a 2 minute time window.

My server was 2.2.14.  I upgraded it to 2.2.18.  It appears that the problem
is gone, although it will probably take a while to be sure.

I do find the "no more than once in 2 minutes" requirement amusing ... :-)

Jun
-
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: DNS goofups galore...

[H. Peter Anvin]

> 
> > Wouldn't that be true for any CNAME anyway?
> 
> That's the point...
> 
> In other words, you do a lookup, you start with a primary lookup
> and then possibly a second lookup to resolve an MX or CNAME.  It's only
> the MX that points to a CNAME that results in yet another lookup.  An
> MX pointing to a CNAME is almost (almost, but not quite) as bad as a
> CNAME pointing to a CNAME.
> 

There is no reducibility problem for MX -> CNAME, unlike the CNAME ->
CNAME case.

Please explain how there is any different between an CNAME or MX pointing
to an A record in a different SOA versus an MX pointing to a CNAME
pointing to an A record where at least one pair is local (same SOA).

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Mem detection problem

[Adam Schrotenboer]

This is a repost of a problem that received few serious replies (IMNSHO).

Basically 2.4.0 detects 192 MB(maybe 191, but big whoop) of memory. This 
is correct. However, 2.4.1-ac6 (as did Linus-blessed 2.4.1) detects 64.
The problem is simple. 2.4.1 and later for some reason (with my 
motherboard/BIOS combination) uses bios-88, instead of e820. I have a 
MS-6167 Athlon board (as evidenced in the dmesg).

I know this has not happened to everyone, or I would have seen it on lk, 
but it seems unlikely that I am the only one with this board/BIOS.

Attached are the dmesgs from 2.4.0 and 2.4.1-ac6.

Please cc all replies, as I am not subscribed (I do read the archives.)


Linux version 2.4.0 (root@tabriel) (gcc version pgcc-2.95.2 19991024 (release)) #2 Mon 
Jan 8 09:02:27 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 0bef @ 0010 (usable)
 BIOS-e820: d000 @ 0bff3000 (ACPI data)
 BIOS-e820: 3000 @ 0bff (ACPI NVS)
On node 0 totalpages: 49136
zone(0): 4096 pages.
zone(1): 45040 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=k240 ro root=341
Initializing CPU#0
Detected 598.850 MHz processor.
Console: colour VGA+ 132x43
Calibrating delay loop... 1196.03 BogoMIPS
Memory: 191308k/196544k available (863k kernel code, 4848k reserved, 278k data, 200k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0081f9ff c0c1f9ff , vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: After vendor init, caps: 0081f9ff c0c1f9ff  
CPU: After generic, caps: 0081f9ff c0c1f9ff  
CPU: Common caps: 0081f9ff c0c1f9ff  
CPU: AMD-K7(tm) Processor stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb470, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
DMI 2.2 present.
39 structures occupying 1001 bytes.
DMI table at 0x000F0800.
BIOS Vendor: Award Software International, Inc.
BIOS Version: 6.0 PG
BIOS Release: 11/23/99
Board Vendor: MICRO-STAR INTERNATIONAL CO., LTD.
Board Name: MS-6167 (AMD751).
Board Version: 1.X.
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD7409: IDE controller on PCI bus 00 dev 39
AMD7409: chipset revision 3
AMD7409: not 100% native mode: will probe irqs later
AMD7409: disabling single-word DMA support (revision < C4)
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
hda: WDC AC28400R, ATA DISK drive
hdb: IBM-DHEA-38451, ATA DISK drive
hdc: TOSHIBA DVD-ROM SD-M1202, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 16514064 sectors (8455 MB) w/512KiB Cache, CHS=1027/255/63, UDMA(33)
hdb: 16514064 sectors (8455 MB) w/472KiB Cache, CHS=1027/255/63, UDMA(33)
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1
 /dev/ide/host0/bus0/target1/lun0: p1 p2 < p5 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Real Time Clock Driver v1.10d
8139too Fast Ethernet driver 0.9.13 loaded
eth0: RealTek RTL8139 Fast Ethernet at 0xcc80, 00:e0:7d:50:3f:3d, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139A'
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 149M
agpgart: Detected AMD Irongate chipset
agpgart: AGP aperture is 32M @ 0xd800
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED])
devfs: devfs_debug: 0x0
devfs: boot_options: 0x0
VFS: Mounted root (ext2 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 200k freed
Adding Swap: 136512k swap-space (priority -1)



Linux version 2.4.1-ac6 (root@tabriel) (gcc version egcs-2.

Re: DNS goofups galore...

[Michael H. Warfield]

On Thu, Feb 08, 2001 at 03:47:17PM -0800, H. Peter Anvin wrote:
> "Michael H. Warfield" wrote:
> > 
> > On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> > > Followup to:  <[EMAIL PROTECTED]>
> > > By author:Gerhard Mack <[EMAIL PROTECTED]>
> > > In newsgroup: linux.dev.kernel
> > > >
> > > > Thanklfully bind 9 barfs if you even try this sort of thing.
> > > >
> > 
> > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it
> > > seems like a useful setup without the pitfalls that either NS -> CNAME
> > > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
> > > irreducible situations; CNAME -> CNAME would require a link maximum
> > > count which could result in obscure breakage.)
> > 
> > It generally forces another DNS lookup.  If you do a resolve on
> > a name of type=ANY it returns any MX records and A records.  If you then
> > do a resolve on the MX records, you then get a CNAME and then have to
> > add an additional lookup for the CNAME.  If you have a lot of MX records
> > and not all the servers are "up" that can add up to a significant
> > increase in DNS traffic.
> > 

> Wouldn't that be true for any CNAME anyway?

That's the point...

In other words, you do a lookup, you start with a primary lookup
and then possibly a second lookup to resolve an MX or CNAME.  It's only
the MX that points to a CNAME that results in yet another lookup.  An
MX pointing to a CNAME is almost (almost, but not quite) as bad as a
CNAME pointing to a CNAME.

>   -hpa

> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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: DNS goofups galore...

[H. Peter Anvin]

"Michael H. Warfield" wrote:
> 
> On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> > Followup to:  <[EMAIL PROTECTED]>
> > By author:Gerhard Mack <[EMAIL PROTECTED]>
> > In newsgroup: linux.dev.kernel
> > >
> > > Thanklfully bind 9 barfs if you even try this sort of thing.
> > >
> 
> > Personally I find it puzzling what's wrong with MX -> CNAME at all; it
> > seems like a useful setup without the pitfalls that either NS -> CNAME
> > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
> > irreducible situations; CNAME -> CNAME would require a link maximum
> > count which could result in obscure breakage.)
> 
> It generally forces another DNS lookup.  If you do a resolve on
> a name of type=ANY it returns any MX records and A records.  If you then
> do a resolve on the MX records, you then get a CNAME and then have to
> add an additional lookup for the CNAME.  If you have a lot of MX records
> and not all the servers are "up" that can add up to a significant
> increase in DNS traffic.
> 

Wouldn't that be true for any CNAME anyway?

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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] Re: UP APIC reenabling vs. cpu type detection o

[Petr Vandrovec]

On  9 Feb 01 at 0:06, Mikael Pettersson wrote:
> On Thu, 8 Feb 2001 12:32:01 MET-1, Petr Vandrovec wrote:
> 
> >I have another question for UP APIC NMI: As I reported some time ago,
> >if performance counters overflow when LVTPC has 'disabled' bit set,
> >NMI is lost forever. This causes problems with VMware - it has to
> >disable NMI deliveries during CR3 (memory mapping) switching, and if 
> >performance counter overflows at that time, you'll not receive another 
> >NMI for couple of days on K7 (4.1 * 65536 seconds on fully loaded 1GHz 
> >Athlon. And 410 * 65536 seconds on idle Athlon)...
> 
> How long do you need to keep NMIs blocked?

Under some circumstances until `real' (usually timer) interrupt happens :-(
It is up to 10ms (on ia32).
 
> The watchdog (re-)initialises the perfctr to a negative value, but
> after overflow the counter will read as positive. (You'll have to
> use rdpmc() and sign-extend the low bits of the high word.)
> So if, after your critical section, the counter reads as positive
> you know that you missed an NMI. In that case, just write the restart
> value to the counter.
> 
> Alternatively, if you block the NMI watchdog for a long time, say a
> couple of thousand cycles or more, you can unconditionally restart it.

Unfortunately both these ways needs intimate knowledge of how UP NMI
watchdog works in each kernel, and it is incompatible with other
perfctr uses. Probably I'll switch perfctr delivery to some real
maskable interrupt while VMware VM owns CPU - if it is possible.
Then interrupt should be still pending after VM does __sti().
Petr Vandrovec
[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: spelling of disc (disk) in /devfs

[Thomas Dodd]

Peter Samuelson wrote:
> 
> [Jeremy M. Dolan]
> > Disk is spelled 'disk' except for Compact Disc and Digital Versatile
> > Disc. If it wasn't 3:30 in the morning, a patch would be attached.
> 
> It wouldn't do any good.  Many months ago, Ted Ts'o pleaded with
> Richard Gooch (devfs author, from Australia) to switch to the American
> spelling of the word, for consistency with the rest of the kernel, and
> nothing came of it.  At this point you may as well consider
> '/dev/discs' an "interface set in stone".  (Come on, do *you* want to
> explain to thousands of people why their /etc/fstab suddenly broke?)

Better still, follow the lead from other Solaris and HP-UX.

/dev/dsk/* block access for hard drives
/dev/rdsk/* char access for hard drives
/dev/diskette block access for floppy drives
/dev/rdiskette char access for floppy drives
/dev/rscsi/* char access for raw scsi (replace /dev/sg* )

Since linux currently doesn't have char access to drives,
rdsk/rdiskette would be ignored untill it is implemented
and needed.

My $0.02

-Thomas
-
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: DNS goofups galore...

[Michael H. Warfield]

On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
> Followup to:  <[EMAIL PROTECTED]>
> By author:Gerhard Mack <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Thanklfully bind 9 barfs if you even try this sort of thing.
> > 

> Personally I find it puzzling what's wrong with MX -> CNAME at all; it
> seems like a useful setup without the pitfalls that either NS -> CNAME
> or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
> irreducible situations; CNAME -> CNAME would require a link maximum
> count which could result in obscure breakage.)

It generally forces another DNS lookup.  If you do a resolve on
a name of type=ANY it returns any MX records and A records.  If you then
do a resolve on the MX records, you then get a CNAME and then have to
add an additional lookup for the CNAME.  If you have a lot of MX records
and not all the servers are "up" that can add up to a significant
increase in DNS traffic.

>   -hpa
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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: bidirectional named pipe?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:"David L. Nicol" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> How hard would it be to add? The limitation on fifos that you get the same
> one every time you open it makes some things tricky -- the server has to
> move the fifo and mkfifo a new one to replace its data with something else,
> for instance, which is not atomic.
> 
> I don't understand, in the original problem, how the server opens
> the named bipipe differently from the servers, to be on one end rather than
> the other.
> 
> A way to map a file name to a socket pair would be nice, the first to open
> it could get one end of it and everyone else would get the other end, or there
> would be a switch.
> 
> You could patch the file system code, I wonder how deep the changes would have
> to be, if you did it in terms of lots of fifos.
> 

I would really like it if open() on a socket would be the same thing
to connect to a socket as a client.  I don't think it's a good idea to
do that for the server side, though, since it would have to know about
accept() anyway.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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] Re: UP APIC reenabling vs. cpu type detection o

[Mikael Pettersson]

On Thu, 8 Feb 2001 12:32:01 MET-1, Petr Vandrovec wrote:

>I have another question for UP APIC NMI: As I reported some time ago,
>if performance counters overflow when LVTPC has 'disabled' bit set,
>NMI is lost forever. This causes problems with VMware - it has to
>disable NMI deliveries during CR3 (memory mapping) switching, and if 
>performance counter overflows at that time, you'll not receive another 
>NMI for couple of days on K7 (4.1 * 65536 seconds on fully loaded 1GHz 
>Athlon. And 410 * 65536 seconds on idle Athlon)...

How long do you need to keep NMIs blocked?

The watchdog (re-)initialises the perfctr to a negative value, but
after overflow the counter will read as positive. (You'll have to
use rdpmc() and sign-extend the low bits of the high word.)
So if, after your critical section, the counter reads as positive
you know that you missed an NMI. In that case, just write the restart
value to the counter.

Alternatively, if you block the NMI watchdog for a long time, say a
couple of thousand cycles or more, you can unconditionally restart it.

(I had a theory about inspecting the APIC_LVTPC "Delivery Status"
field, but unfortunately it doesn't seem to get set if a counter
overflowed while LVTPC was masked. Perhaps it's because NMIs are
edge-triggered.)

>So it came to my mind - why (on K7 we easy can, as counter has 48 bits)
>we do not reload NMI watchdog in each timer interrupt with 5sec timeout,
>and if we receive even one NMI, we are locked up? It should increase
>performance, as we'll do same number of MSR writes anyway (100/s), but
>we will not receive any NMI during normal operation, so we save time
>spent in processing this. Or do I miss something?

The 100 NMI/s rate was just to match the original IO-APIC driven watchdog;
it's certainly not a design goal to have the rate this high. In fact,
we'll probably reduce it to 1Hz soon. (I'm running it in that mode now.)

/Mikael
-
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: Mem detection problem

[Michael Hobgood]

On Thu, Feb 08, 2001 at 11:52:54AM -0500, Adam Schrotenboer wrote:
> This is actually a repost of a problem that received few serious replies 
> (IMNSHO).
> 
> Basically 2.4.0 detects 192 MB(maybe 191, but big whoop) of memory. This 
> is correct. However, 2.4.1-ac6 (as did Linus-blessed 2.4.1) detects 64. 
> The problem is simple. 2.4.1 and later for some reason uses bios-88, 
> instead of e820.
> 
> Attached are the dmesgs from 2.4.0 and 2.4.1-ac6.

[snip]

Perhaps on your machine, but not on all.  Small amount of dmesg from mine.


Linux version 2.4.2-pre1 (root@BrightStar) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #1 Tue Feb 6 05:34:32 CST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009f800 @  (usable)
 BIOS-e820: 0800 @ 0009f800 (reserved)
 BIOS-e820: e800 @ 000f1800 (reserved)
 BIOS-e820: 11f0 @ 0010 (usable)
 BIOS-e820: e800 @ 1800 (reserved)
  

On node 0 totalpages: 73728
zone(0): 4096 pages.
zone(1): 69632 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=242 ro root=342 hdd=ide-scsi
ide_setup: hdd=ide-scsi
Initializing CPU#0
Detected 334.098 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 666.82 BogoMIPS
Memory: 287948k/294912k available (953k kernel code, 6576k reserved, 319k data, 172k 
init, 0k highmem)
^^ the 294912k is correct

Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)

Cordially,
Michael Hobgood

-
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: DNS goofups galore...

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Gerhard Mack <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Thanklfully bind 9 barfs if you even try this sort of thing.
> 

Personally I find it puzzling what's wrong with MX -> CNAME at all; it
seems like a useful setup without the pitfalls that either NS -> CNAME
or CNAME -> CNAME can cause (NS -> CNAME can trivially result in
irreducible situations; CNAME -> CNAME would require a link maximum
count which could result in obscure breakage.)

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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 for ymfpci and xmms

[Pete Zaitcev]

Courtesy of Manish Singh, little bit extended
(I hope I did not break it too badly).
Supposedly it fixes bad skipping with xmms.

-- Pete

diff -ur -X dontdiff linux-2.4.1/drivers/sound/ymfpci.c 
linux-2.4.1-p3/drivers/sound/ymfpci.c
--- linux-2.4.1/drivers/sound/ymfpci.c  Fri Jan 26 23:31:16 2001
+++ linux-2.4.1-p3/drivers/sound/ymfpci.c   Thu Feb  8 11:29:45 2001
@@ -370,16 +370,14 @@
 
/*
 * Create fake fragment sizes and numbers for OSS ioctls.
+* Import what Doom might have set with SNDCTL_DSP_SETFRAGMENT.
 */
bufsize = PAGE_SIZE << dmabuf->buforder;
-   if (dmabuf->ossfragshift) {
-   if ((1000 << dmabuf->ossfragshift) < bytepersec)
-   dmabuf->fragshift = ld2(bytepersec/1000);
-   else
-   dmabuf->fragshift = dmabuf->ossfragshift;
-   } else {
-   /* lets hand out reasonable big ass buffers by default */
-   dmabuf->fragshift = (dmabuf->buforder + PAGE_SHIFT -2);
+   /* lets hand out reasonable big ass buffers by default */
+   dmabuf->fragshift = (dmabuf->buforder + PAGE_SHIFT -2);
+   if (dmabuf->ossfragshift > 3 &&
+   dmabuf->ossfragshift < dmabuf->fragshift) {
+   dmabuf->fragshift = dmabuf->ossfragshift;
}
dmabuf->numfrag = bufsize >> dmabuf->fragshift;
while (dmabuf->numfrag < 4 && dmabuf->fragshift > 3) {
@@ -389,9 +387,6 @@
dmabuf->fragsize = 1 << dmabuf->fragshift;
dmabuf->dmasize = dmabuf->numfrag << dmabuf->fragshift;
 
-   /*
-* Import what Doom might have set with SNDCTL_DSD_SETFRAGMENT.
-*/
if (dmabuf->ossmaxfrags >= 2 && dmabuf->ossmaxfrags < dmabuf->numfrag) {   
 dmabuf->numfrag = dmabuf->ossmaxfrags;
dmabuf->dmasize = dmabuf->numfrag << dmabuf->fragshift;
@@ -1718,21 +1713,13 @@
case SNDCTL_DSP_SETFRAGMENT:
if (get_user(val, (int *)arg))
return -EFAULT;
-   /* P3: these frags are for Doom. Amasingly, it sets [2,2**11]. */
-   /* P3 */ // printk("ymfpci: ioctl SNDCTL_DSP_SETFRAGMENT 0x%x\n", val);
-
dmabuf = &state->wpcm.dmabuf;
dmabuf->ossfragshift = val & 0x;
dmabuf->ossmaxfrags = (val >> 16) & 0x;
-   switch (dmabuf->ossmaxfrags) {
-   case 1:
-   dmabuf->ossfragshift = 12;
-   return 0;
-   default:
-   /* Fragments must be 2K long */
-   dmabuf->ossfragshift = 11;
-   dmabuf->ossmaxfrags = 2;
-   }
+   if (dmabuf->ossfragshift < 4)
+   dmabuf->ossfragshift = 4;
+   if (dmabuf->ossfragshift > 15)
+   dmabuf->ossfragshift = 15;
return 0;
 
case SNDCTL_DSP_GETOSPACE:
-
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: Problems with 2.4.2-pre1 & reiser & vfs

[Alan Cox]

> > kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for 
> > [7906789 7906806 0xfff DIRECT]
> > .
> 
> These aren't good at all, and show a general corruption problem.  I know the ac 
>kernels have at least one small DAC960 bug fixes, are there other fixes pending?
> 

The dac960 changes relate to gcc 2.96 stuff and wouldnt account for real bugs.
DAC960 built with cvs gcc or 2.96 < 2.96-74 or so could do because of the ABI
thing but wouldnt boot that far. If its straight 2.4.1 suspect the elevator
corruption thing too

-
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: Linux 2.4.1-ac7

[Rik van Riel]

On Thu, 8 Feb 2001, Torben Mathiasen wrote:
> On Thu, Feb 08 2001, Rik van Riel wrote:
> > On Thu, 8 Feb 2001, Alan Cox wrote:
> > 
> > >   ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> > > 
> > > 2.4.1-ac7
> > > o Rebalance the 2.4.1 VM  (Rik van Riel)
> > >   | This should make things feel a lot faster especially
> > >   | on small boxes .. feedback to Rik

> Just installed ac7 and after some 30 minutes of unpacking
> kernel-sources and diffing patches, I left my computer unattended
> for about 1 hour. When I came back the system was unusable (like it 
> was frozen), and /var/log/messages just displayed messages of the
> type:
> 
> Feb  8 22:54:40 fry kernel: Out of Memory: Killed process 455 (xmms).
> ...
> 
> The OOM killer killed most of my apps, and finally X. I had to reboot
> in order to get the system back. I've been running ac1-ac6 since they
> came out with no problems, so I guess its the VM hack that is buggy.

Highly unlikely since the VM rebalancing patch doesn't change
any of the actual swapout mechanisms.

All it does is change how often the particular algorithms get
called by kswapd and by user programs.

As for trigerring the OOM killer, this strongly suggest a
memory leak since there's a bug in the code which makes it
very hard to trigger the OOM killer under normal situations
(I'm working on a fix for that now).

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

-
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: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[tytso]

On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
> > In serial.c, you seem to perform a check by writing to a possible
> > modem's interrupt enable register and reading the result.  This seems to
> > be one of the points at which the auto-configuration process occasionally
> > fails.  If I make the following change to this code my modem seems to
> > be auto-detected correctly all of the time:
> 
> >scratch = serial_inp(info, UART_IER);
> > serial_outp(info, UART_IER, 0);
> > #ifdef __i386__
> > outb(0xff, 0x080);
> > #endif
> > scratch2 = serial_inp(info, UART_IER);
> > serial_outp(info, UART_IER, 0x0F);
> > #ifdef __i386__
> > outb(0, 0x080);
> > #endif
> > - scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> > + scratch3 = 0x0f/* ADD */
> > serial_outp(info, UART_IER, scratch);

The problem is that if this doesn't work, there are some serious
questions about the correctness of the Lucent Microelectronic Venus
modem.  I've forwarded this to someone in the Lucent Modem group, who
can hopefully look at this (and maybe can ship me a sample hardware so
I can play with it, although I'd much rather that he tell me how to
work around the hardware bug, or tell me that all you need is a
firmware upgrade to fix the bug in the modem).

- 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: Linux 2.4.1-ac7

[Torben Mathiasen]

On Thu, Feb 08 2001, Rik van Riel wrote:
> On Thu, 8 Feb 2001, Alan Cox wrote:
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> > 
> > 2.4.1-ac7
> > o   Rebalance the 2.4.1 VM  (Rik van Riel)
> > | This should make things feel a lot faster especially
> > | on small boxes .. feedback to Rik
> 
> I'd really like feedback from people when it comes to this
> change. The change /should/ fix most paging performance bugs
> because it makes kswapd do the right amount of work in order
> to solve the free memory shortage every time it is run.
 
Rik,

Just installed ac7 and after some 30 minutes of unpacking
kernel-sources and diffing patches, I left my computer unattended
for about 1 hour. When I came back the system was unusable (like it 
was frozen), and /var/log/messages just displayed messages of the
type:

Feb  8 22:54:40 fry kernel: Out of Memory: Killed process 455 (xmms).
...

The OOM killer killed most of my apps, and finally X. I had to reboot
in order to get the system back. I've been running ac1-ac6 since they
came out with no problems, so I guess its the VM hack that is buggy.

This is on an AMD K7 1200Mhz, 512MB Ram, ATA100. Nothing big was
running at the time (xchat, xmms, mozilla, gnome, x, a few xterms).

I'll do some more testing tomorrow and provide any further information
you might need.



-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://opensource.compaq.com

-
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: Problems with 2.4.2-pre1 & reiser & vfs

[Chris Mason]

On Thursday, February 08, 2001 04:00:26 PM +0100 Andrius Adomaitis <[EMAIL PROTECTED]> 
wrote:

> 
> Hello,
> 
> I have  dual PIII 800 machine running as mail server on DAC 960 RAID & 
> reiserfs comming with 2.4.1kernel.
> 
> Under very high loads I get  following messages in my kernel log:
> 
> kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 
> 7906806 0x0 SD](nlink == 1) not found (pos 23)
> kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 
> 7906806 0x0 SD] (nlink == 1) not found (pos 23)
> kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for 
> [7906789 7906806 0xfff DIRECT]
> kernel: vs-13060: reiserfs_update_sd: stat data of object [7906789 
> 7906806 0x0 SD] (nlink == 1) not found (pos 23)
> kernel: PAP-5660: reiserfs_do_truncate: wrong result -1 of search for 
> [7906789 7906806 0xfff DIRECT]
> .

These aren't good at all, and show a general corruption problem.  I know the ac 
kernels have at least one small DAC960 bug fixes, are there other fixes pending?

> 
> and afterwards come these:
> 
> kernel: vs-3050: wait_buffer_until_released: nobody releases buffer 
> (dev 30:09, size 4096, blocknr 1661732, count 16,
> kernel: vs-3050: wait_buffer_until_released: nobody releases buffer 
> (dev 30:09, size 4096, blocknr 1661732, count 16,
> ...
> and so on.
> 

There is more info in this message, it would help if you could send the entire line.

> The interesting thing is that system is still operational, but load 
> jumps up to 260 or so, and any attempts to reboot system fail. ps aux 
> shows that there exists imortal (kill -9 $PID doesn't kill it) qmail 
> process that consumes 97% of one CPU's resources.  Also `vmstat` shows 
> tons of processes in uninterruptable sleep, but `free` reports that it 
> is still enough memory (no swap used) and huge buffers... Machine gets 
> slugish but works for a while (0.5-2h dependent on mail request rate).
> 

Once you get a vs-3050, any process that tries to change the FS ends up waiting on the 
journal, which is waiting on the process stuck in vs-3050.  There is no escape.

-chris



-
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: [OFF-TOPIC] sendmail (was: Re: someone knows a good sendmail mailing list ?)

[David S. Miller]

Henning P. Schmiedehausen writes:
 > "threads is salt" quote of davem.

Please attribute things correctly, even though I agree with it
these aren't my words, they are Larry McVoy's.

Later,
David S. Miller
[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: [PATCH] starfire reads irq before pci_enable_device.

[Ion Badulescu]

On Thu, 8 Feb 2001, Donald Becker wrote:

> > > The align-copy should *never* be required because the alignment differs
> > > between DIX and E-II encapsulated packets.  The machine shouldn't crash
> > > because someone sends you a different encapsulation type!
> 
> This is true for a number of drivers -- triggering the copy-align code
> might eliminate the misaligned traps on your local network, but it's not
> a solution.

Ok, so what *is* a good solution then? I'm not arguing that unaligned 
memory access traps should be avoided because they are deadly (they 
shouldn't be), but because they are costly.

Or we can just tell people, "hey, don't use this 64-bit PCI card on a real 
64-bit system, it's broken by design"? I don't think that's a good 
solution either.

The lack of a 64-bit frame descriptor isn't going to help either, if and 
when zerocopy makes into the official tree. Using buffer descriptors with 
fragmented sk_buffs is *not* fun (and yet that's what I do in 32-bit for 
my BSDI driver, but for unrelated reasons).

> I saw the Adaptec people last week at LinuxWorld.  The 2.4.0 starfire
> has a number of actual bugs that should be fixed RSN:
>The consistency check in the Rx code was broken.  Did anyone ever try
>the driver after the changes?  The test triggers with every received
>packet.  The easiest patch is to just get rid the consistency checks
>inside "#ifndef final_version".

Done.

>The region resource was not released, requiring a reboot between each
>driver test.  Trivial fix.

Done.

>The MII read code is no longer reliable.  I spent twenty minutes at
>the show, but couldn't figure out the problem.  I haven't been able
>reproduce the problem locally with my 2.2 code and someone older
>hardware.

Yes, I've noticed this too, the PHY doesn't seem to get detected in all 
cases, and it's pretty random at that. Other times the same PHY gets 
detected multiple times at different addresses.

The good news is that the same code behaves the same on 2.4 and 2.2, so 
I think it's not a core kernel issue. I'll try to track it down; 
fortunately it doesn't affect card functionality as long as the user 
sticks with autonegotiation.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
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: Linux 2.4.1-ac7

[Rik van Riel]

On Thu, 8 Feb 2001, Alan Cox wrote:

>   ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> 
> 2.4.1-ac7
> o Rebalance the 2.4.1 VM  (Rik van Riel)
>   | This should make things feel a lot faster especially
>   | on small boxes .. feedback to Rik

I'd really like feedback from people when it comes to this
change. The change /should/ fix most paging performance bugs
because it makes kswapd do the right amount of work in order
to solve the free memory shortage every time it is run.

This, in turn, should make it far less likely that user processes
will *ever* need to call try_to_free_pages() themselves, unless
the system really goes into overload mode.

It would be good to know if this change really fixes the bug or
if it only helps for certain workloads and not for others. I'd
really like to close the following bug but need confirmation
that it works first ;)

http://distro.conectiva.com/bugzilla/show_bug.cgi?id=1178

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

-
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] starfire reads irq before pci_enable_device.

[Ion Badulescu]

On Thu, 8 Feb 2001, Jeff Garzik wrote:

> Well at least let's do it the Linux Kernel Way(tm):  separate out the
> zerocopy stuff such that there are minimal ifdefs in the code...  For
> example:
> 
>   /* add these functions... */
>   #ifdef ZEROCOPY
>   static inline setup_txrx_rings(...) { /*...*/ }
>   #else
>   static inline setup_txrx_rings(...) { /*...*/ }
>   #endif
> 
> then in the code itself, where the TxRx ring setup occurs now (ie. where
> ifdefs exist in the code) simply call the new static inline functions.

Hmm. Ok. I'll think about it. Roughly 1/3 of the driver code will be 
duplicated if we go this route with the existing structure. I'll try to 
make use of a few helper inline functions which are smaller and can be 
ifdef'ed without much code duplication.

> The #ifdef ZEROCOPY code you added is a classic example of the kind of
> code I -remove- from the kernel tree.

It's an issue of maintainer convenience vs. esthetics. And (last but not 
least) it's also about other people's ability to easily make changes to 
the driver, changes they can understand and test. So while in principle I 
agree with you, I'm also beginning to understand Donald Becker's 
frustration when others remove backward compatibility from his code.

So let's try to find some middle ground, ok? Your first suggestion sounds 
reasonable, and hopefully the fate of the zerocopy stuff will be decided 
sooner than later.

Stay tuned, there should be another version coming your way sometime 
today...

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
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] 2.4.1-ac7: NTFS further cleanups + docs updates

[Anton Altaparmakov]

Alan,

Please apply attached patch for the next ac release (it is gzipped to
ensure integrity of white space and it's also smaller that way).

Have tested it to compile both as module and in kernel and tested
functionality when compiled in. - Tests are fine.

Note I consider this patch fully stable (only obvious bugfixes, and each
has been tested).

Detailed description of updates:

Documentation/filesystems/ntfs.txt and Documentation/Configure.help: 
update adding references to ntfsfix utility (me)

Remainders only touch fs/ntfs/ files:

Remove remaining userspace tools support #ifdefs; final offset fix for
layout_runs(); misc cleanups. (Yuri Per <[EMAIL PROTECTED]>)

Add return code + checking to ntfs_insert_mft_attributes(); small
cleanups. (Rob Radez <[EMAIL PROTECTED]>)

Check and return error if unsupported blocksize, rather than panic the
kernel; Correctly handle all index_clusters_per_record values; Add
docbook style documentation to a few ntfs functions and other comments
updates (docs are the preparation for the next patch I will submit which
contains most of the documented functions either cleaned up or rewritten); 
misc cleanups. (me)

Best regards,

Anton

-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/


 patch-ntfs-2.4.1-ac7.gz

Re: [PATCH] starfire reads irq before pci_enable_device.

[Donald Becker]

On Thu, 8 Feb 2001, Jeff Garzik wrote:

> > Well, I decided to bite the bullet and port my zerocopy starfire
> > changes to the official tree, properly ifdef'ed. So here it goes,
>
> I would prefer that the zerocopy changes stay in DaveM's external patch
> until they are ready to be merged.  Zerocopy is still changing and being

Good idea -- I expect that there will be significant interface changes
before the zero-copy code stabilizes.

> > + * The ia64 doesn't allow for unaligned loads even of integers being
> > + * misaligned on a 2 byte boundary. Thus always force copying of
> > + * packets as the starfire doesn't allow for misaligned DMAs ;-(
...
> Note that I have not yet sent this patch onto Linus for a reason... 
> Here is Don Becker's comment on the subject:

> > Oh, and this is completely bogus.
> > This isn't a fix, it's a hack that covers up the real problem.
> > 
> > The align-copy should *never* be required because the alignment differs
> > between DIX and E-II encapsulated packets.  The machine shouldn't crash
> > because someone sends you a different encapsulation type!

This is true for a number of drivers -- triggering the copy-align code
might eliminate the misaligned traps on your local network, but it's not
a solution.

I saw the Adaptec people last week at LinuxWorld.  The 2.4.0 starfire
has a number of actual bugs that should be fixed RSN:
   The consistency check in the Rx code was broken.  Did anyone ever try
   the driver after the changes?  The test triggers with every received
   packet.  The easiest patch is to just get rid the consistency checks
   inside "#ifndef final_version".

   The region resource was not released, requiring a reboot between each
   driver test.  Trivial fix.

   The MII read code is no longer reliable.  I spent twenty minutes at
   the show, but couldn't figure out the problem.  I haven't been able
   reproduce the problem locally with my 2.2 code and someone older
   hardware.

Donald Becker   [EMAIL PROTECTED]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210   Second Generation Beowulf Clusters
Annapolis MD 21403  410-990-9993

-
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] patch-2.4.1-irda4 (irlap speed)

[Dag Brattli]

Linus,

Here is a patch that fixes some IrDA problems with speed 
changes in the IrLAP layer, and also a missing kfree's in all
of the IrDA device drivers. This patch is also credited 
Jean Tourrilhes. It's been tested for a month or so by
the Linux-IrDA mailing-list, and found to be working OK.

Please apply to your latest 2.4 code.

-- Dag

diff -urpN linux-2.4.1-patch/net/irda/irlap.c linux-2.4.1-irda-patch/net/irda/irlap.c
--- linux-2.4.1-patch/net/irda/irlap.c  Sun Nov 12 03:11:23 2000
+++ linux-2.4.1-irda-patch/net/irda/irlap.c Thu Feb  8 22:34:14 2001
@@ -998,7 +998,7 @@ void irlap_init_qos_capabilities(struct 
 }
 
 /*
- * Function irlap_apply_default_connection_parameters (void)
+ * Function irlap_apply_default_connection_parameters (void, now)
  *
  *Use the default connection and transmission parameters
  * 
@@ -1010,14 +1010,16 @@ void irlap_apply_default_connection_para
ASSERT(self != NULL, return;);
ASSERT(self->magic == LAP_MAGIC, return;);
 
+   /* xbofs : Default value in NDM */
+   self->next_bofs   = 12;
+   self->bofs_count  = 12;
+
+   /* NDM Speed is 9600 */
irlap_change_speed(self, 9600, TRUE);
 
/* Set mbusy when going to NDM state */
irda_device_set_media_busy(self->netdev, TRUE);
 
-   /* Default value in NDM */
-   self->bofs_count = 12;
-
/* 
 * Generate random connection address for this session, which must
 * be 7 bits wide and different from 0x00 and 0xfe 
@@ -1056,23 +1058,31 @@ void irlap_apply_default_connection_para
 }
 
 /*
- * Function irlap_apply_connection_parameters (qos)
+ * Function irlap_apply_connection_parameters (qos, now)
  *
  *Initialize IrLAP with the negotiated QoS values
  *
+ * If 'now' is false, the speed and xbofs will be changed after the next
+ * frame is sent.
+ * If 'now' is true, the speed and xbofs is changed immediately
  */
-void irlap_apply_connection_parameters(struct irlap_cb *self) 
+void irlap_apply_connection_parameters(struct irlap_cb *self, int now) 
 {
IRDA_DEBUG(4, __FUNCTION__ "()\n");

ASSERT(self != NULL, return;);
ASSERT(self->magic == LAP_MAGIC, return;);
 
-   irlap_change_speed(self, self->qos_tx.baud_rate.value, FALSE);
+   /* Set the negociated xbofs value */
+   self->next_bofs   = self->qos_tx.additional_bofs.value;
+   if(now)
+   self->bofs_count = self->next_bofs;
+
+   /* Set the negociated link speed (may need the new xbofs value) */
+   irlap_change_speed(self, self->qos_tx.baud_rate.value, now);
 
self->window_size = self->qos_tx.window_size.value;
self->window  = self->qos_tx.window_size.value;
-   self->bofs_count  = self->qos_tx.additional_bofs.value;
 
/*
 *  Calculate how many bytes it is possible to transmit before the
diff -urpN linux-2.4.1-patch/net/irda/irlap_event.c 
linux-2.4.1-irda-patch/net/irda/irlap_event.c
--- linux-2.4.1-patch/net/irda/irlap_event.cTue Nov 28 03:07:31 2000
+++ linux-2.4.1-irda-patch/net/irda/irlap_event.c   Thu Feb  8 22:34:14 2001
@@ -684,25 +684,26 @@ static int irlap_state_conn(struct irlap
 
irlap_initiate_connection_state(self);
 
-#if 0
/* 
-* We are allowed to send two frames, but this may increase
-* the connect latency, so lets not do it for now.
+* Applying the parameters now will make sure we change speed
+* *after* we have sent the next frame
 */
-   irlap_send_ua_response_frame(self, &self->qos_rx);
-#endif
+   irlap_apply_connection_parameters(self, FALSE);
 
/* 
-* Applying the parameters now will make sure we change speed
-* after we have sent the next frame
+* Sending this frame will force a speed change after it has
+* been sent (i.e. the frame will be sent at 9600).
 */
-   irlap_apply_connection_parameters(self);
+   irlap_send_ua_response_frame(self, &self->qos_rx);
 
+#if 0
/* 
-* Sending this frame will force a speed change after it has
-* been sent
+* We are allowed to send two frames, but this may increase
+* the connect latency, so lets not do it for now.
 */
+   /* What the hell is this ? - Jean II */
irlap_send_ua_response_frame(self, &self->qos_rx);
+#endif
 
/*
 *  The WD-timer could be set to the duration of the P-timer 
@@ -794,8 +795,9 @@ static int irlap_state_setup(struct irla
 
irlap_qos_negotiate(self, skb);

+   /* Send UA frame and then change link settings */
+   irlap_apply_connection_parameters(self, FALSE);
irlap_s

Re: Linux 2.4.1-ac7

[Anton Altaparmakov]

On Thu, 8 Feb 2001, Doug Ledford wrote:
> Thanks, I hoped it would ;-)  It's amazing what happens when you have a bcopy
> in assembly that's missing the source address initialization :-(

Yes! The output from the description of my SCSI hds when the driver
initialised was highly amusing (containing extremely random garbage)...
(-;

Best regards,

Anton
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / 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/

Re: Linux 2.4.1-ac7

[Doug Ledford]

Tigran Aivazian wrote:
> 
> two mistakes:
> 
> a) [EMAIL PROTECTED], not veritas.com! (it was pine, not me -- default
> domain etc :)
> 
> b) it was ac6 which fixed it, not ac7 (but I am running ac7)
> 
> On Thu, 8 Feb 2001, Tigran Aivazian wrote:
> 
> > Doug,
> >
> > I confirm that ac7 fixed all the aic7xxx problems on my machine.

Thanks, I hoped it would ;-)  It's amazing what happens when you have a bcopy
in assembly that's missing the source address initialization :-(

-- 

 Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
  Please check my web site for aic7xxx updates/answers before
  e-mailing me about problems
-
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 on GA-7ZX (2.4.1-ac6, via audio)

[Martin Braun]

Jeff Garzik wrote:
> 
> Martin Braun wrote:
> > I can not get sound working on a computer with a Gigabyte
> > GA-7ZX mainboard (KT133 chipset). Is this a known problem?
> > I have attached some config info. Mail me for further details.
> 
> > $ cat /proc/driver/via/0/*
> > Vendor name  : SigmaTel STAC
> > Vendor id: 8384 7600
> 
> 1) Have you turned the master volume and PCM volume -way- up?

Yes.

There is some noise when I send an audio file directly to the device,
i. e. cat error.wav > /dev/dsp. However, all sound programs I have
tried fail to set the audio speed (RedHat 7, tried sox, xmms, mpg123).
Sample strace output (mpg123):
...
alarm(10)   = 0
pause() = ? ERESTARTNOHAND (To be
restarted)
--- SIGALRM (Alarm clock) ---
sigreturn() = ? (mask now [])
alarm(0)= 10
rt_sigaction(SIGUSR1, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
open("/dev/dsp", O_WRONLY|O_NONBLOCK)   = 4
fcntl64(4, F_GETFL) = 0x801 (flags
O_WRONLY|O_NONBLOCK)
fcntl64(4, F_SETFL, O_WRONLY)   = 0
ioctl(4, SNDCTL_DSP_SETFRAGMENT, 0xb7e0) = 0
ioctl(4, SNDCTL_DSP_SETFMT, 0xb7e0) = 0
ioctl(4, SNDCTL_DSP_GETFMTS, 0xb7e0) = 0
ioctl(4, SNDCTL_DSP_STEREO, 0xb7e0) = 0
ioctl(4, SNDCTL_DSP_SPEED, 0xb7e0)  = 0
write(2, "unsupported playback rate: 22050"..., 33) = 33
close(4)= 0
write(2, "audio: Interrupted system call\n", 31) = 31
_exit(1)= ?
(END)  
> 
> 2) Does 2.4.1-ac5 work for you?  (ie. did 2.4.1-ac6 break something?)
> 

I only tried 2.4.1 without patches on this machine which did not work
either. 

Martin Braun

> Jeff
> 
> --
> Jeff Garzik   | "You see, in this world there's two kinds of
> Building 1024 |  people, my friend: Those with loaded guns
> MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
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: DNS goofups galore...

[Gerhard Mack]

Thanklfully bind 9 barfs if you even try this sort of thing.

Gerhard

On Thu, 8 Feb 2001, Henning P. Schmiedehausen wrote:

> [EMAIL PROTECTED] (Matti Aarnio) writes:
> 
> >NSes and MXes must ALWAYS point to NAMEs with A//A6 records for
> >them, specifically those names MUST NOT be CNAMEs.   With NSes the
> 
> NS: must not
> MX: should not
> 
>   ...stickler for details. ;-)
>   Henning
> 
> -- 
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen   -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
> 
> Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [EMAIL PROTECTED]
> D-91054 Buckenhof Fax.: 09131 / 50654-20   
> -
> 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/
> 

--
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: [PATCH] starfire reads irq before pci_enable_device.

[Ion Badulescu]

On Thu, 8 Feb 2001, Manfred Spraul wrote:

> What about changing the default for rx_copybreak instead?
> Set it to 1536 on ia64 and Alpha, 0 for the rest.
> tulip and eepro100 use that aproach.

That makes a lot of sense, thanks for the suggestion. I'll do so in the 
next version.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
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] starfire reads irq before pci_enable_device.

[Jeff Garzik]

Ion Badulescu wrote:
> 
> On Thu, 8 Feb 2001, Jeff Garzik wrote:
> 
> > I would prefer that the zerocopy changes stay in DaveM's external patch
> > until they are ready to be merged.
> 
> I would actually prefer to have a single source for all the driver
> versions. The 2.2.x version I sent to Alan later on actually compiles on
> 2.2, 2.4 and 2.4+zerocopy. I just want to test it some more; the 2.4
> version I submitted was quite well tested.

Well at least let's do it the Linux Kernel Way(tm):  separate out the
zerocopy stuff such that there are minimal ifdefs in the code...  For
example:

/* add these functions... */
#ifdef ZEROCOPY
static inline setup_txrx_rings(...) { /*...*/ }
#else
static inline setup_txrx_rings(...) { /*...*/ }
#endif

then in the code itself, where the TxRx ring setup occurs now (ie. where
ifdefs exist in the code) simply call the new static inline functions.


> > Zerocopy is still changing and being
> > actively debugged, so it is possible that we might have to patch
> > starfire.c again with zerocopy updates, before the final patch makes it
> > to Linus.  Let's wait on zerocopy in the main tree..
> 
> It's true that zerocopy might change. But remember, zerocopy support in
> the driver is not mandatory, and nobody forces you to #define ZEROCOPY. If
> the zerocopy proves to be unacceptable for the official kernel, ripping
> out the stuff that's #ifdef ZEROCOPY will be a trivial exercise.

You totally missed my point.  It's unclean.  If you have some code that
will not work at all in the current tree, it should not be in the
current tree.  If Alan or Linus applies a starfire.c patch that includes
ZEROCOPY support while the tree as a whole does not include such
support, you are effectively including a developer-local change in the
global tree.  With your patch but without zercopy infrastructure,
defining ZEROCOPY is completely pointless without an additional,
experimental patch.

The #ifdef ZEROCOPY code you added is a classic example of the kind of
code I -remove- from the kernel tree.


> > > I've also added myself as the starfire maintainer -- I hope
> > > nobody objects.
> >
> > If you've got the hardware and time, I'm always happy to see someone
> > step up ..
> 
> .. the hardware, the docs, the time, and the day-to-day duty to maintain
> the starfire driver (and the eepro100 driver) for an older version of
> BSDI. It's the job that pays my salary...

excellent :)


> tx_timeout is completely bogus right now, to be honest. If it gets there,
> you might as well just down the interface. So I just applied this part
> from your patch, without really thinking about it.
> 
> What tx_timeout really needs to do is a full reset and re-initialization
> of the chip. Why? Because when the timeout happens, the chip is basically
> fubar'ed (usually due to driver bugs, but that's not the point).

agreed

Jeff



-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
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] starfire reads irq before pci_enable_device.

[Manfred Spraul]

Ion Badulescu wrote:
> 
> > > +#if defined(__ia64__) || defined(__alpha__)
> > > +#define PKT_SHOULD_COPY(pkt_len)   1
> > > +#else
> > > +#define PKT_SHOULD_COPY(pkt_len)   (pkt_len < rx_copybreak)
> > > +#endif
> >
> [snip]
> 
> It's not *required* per se, as far as I know both the Alpha and IA64 have
> handlers for unaligned access traps. *However*, copying each packet is
> definitely better than taking an exception for each packet!
>

What about changing the default for rx_copybreak instead?
Set it to 1536 on ia64 and Alpha, 0 for the rest.
tulip and eepro100 use that aproach.

--
Manfred
-
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] modify ver_linux to check e2fsprogs and more.

[Jochen Striepe]

Hi,

On 08 Feb 2001, Steven Cole <[EMAIL PROTECTED]> wrote:
> I have modified the scripts/ver_linux script to provide the following:
>
[...]
>
> hostname -V 2>&1 | awk 'NR==1{print "Net-tools ", $NF}'

*Please* consider modifying this. There might be a problem:


tolot:/root # hostname -V
tolot:/root # hostname
-V
tolot:/root # hostname --version
hostname (GNU sh-utils) 2.0.11
Written by Jim Meyering.

Copyright (C) 2000 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Greetings from Germany,

Jochen Striepe

-- 
The number of UNIX installations has grown to 10, with more expected.
 - Dennis Ritchie and Ken Thompson, June 1972


 PGP signature

Re: Linux 2.4.1-ac7

[Anton Altaparmakov]

At 19:33 08/02/01, Tigran Aivazian wrote:
>On Thu, 8 Feb 2001, Tigran Aivazian wrote:
> > I confirm that ac7 fixed all the aic7xxx problems on my machine.

me,too (-:

AHA2940UW dual channel adapter (on board a SMP Tyan Thunder Pro 100 GX440 
mobo).

-ac5 crashed on boot at SCSI init.
-ac6 untested
-ac7 all working fine again

Best regards,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / 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/

What values in /proc/cpuinfo can change?

[Douglas Rudoff]

Of all the fields in /proc/cpuinfo, which ones aren't fixed (as long as
you keep the same processor)?

According to the HOWTO I know bogomips can change.

What about flags/features? Can things be done to a CPU to change the
flags?

Is cpu MHz a real measurement of the speed the CPU is running, or is it
a fixed number that is dependent on the CPU type?

I'm not currently a subscriber to the mailing list; Please cc me any
response to the list.

Thanks!

Doug Rudoff
[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/

[patch] patch-2.4.1-irda3 (qos)

[Dag Brattli]

Linus,

Please apply this patch to your latest 2.4 code. It contains
cleanups to the irda QoS code by Jean Tourrilhes.

-- Dag

diff -u -p linux/include/net/irda/qos.d6.h linux/include/net/irda/qos.h
--- linux/include/net/irda/qos.d6.h Thu Jan 11 14:28:26 2001
+++ linux/include/net/irda/qos.hThu Jan 11 14:29:15 2001
@@ -100,10 +100,19 @@ void irda_qos_compute_intersection(struc
 
 __u32 irlap_max_line_capacity(__u32 speed, __u32 max_turn_time);
 __u32 irlap_requested_line_capacity(struct qos_info *qos);
-__u32 irlap_min_turn_time_in_bytes(__u32 speed, __u32 min_turn_time);
 
 int msb_index(__u16 byte);
 void irda_qos_bits_to_value(struct qos_info *qos);
+
+/* So simple, how could we not inline those two ?
+ * Note : one byte is 10 bits if you include start and stop bits
+ * Jean II */
+#define irlap_min_turn_time_in_bytes(speed, min_turn_time) (   \
+   speed * min_turn_time / 1000\
+)
+#define irlap_xbofs_in_usec(speed, xbofs) (\
+   xbofs * 1000 / speed\
+)
 
 #endif
 
diff -u -p linux/net/irda/qos.d6.c linux/net/irda/qos.c
--- linux/net/irda/qos.d6.c Thu Jan 11 14:28:40 2001
+++ linux/net/irda/qos.cThu Jan 11 14:29:15 2001
@@ -70,10 +70,6 @@ static int irlap_param_additional_bofs(v
   int get);
 static int irlap_param_min_turn_time(void *instance, irda_param_t *param, 
 int get);
-static int value_index(__u32 value, __u32 *array, int size);
-static __u32 byte_value(__u8 byte, __u32 *array);
-static __u32 index_value(int index, __u32 *array);
-static int value_lower_bits(__u32 value, __u32 *array, int size, __u16 *field);
 
 __u32 min_turn_times[]  = { 1, 5000, 1000, 500, 100, 50, 10, 0 }; /* us */
 __u32 baud_rates[]  = { 2400, 9600, 19200, 38400, 57600, 115200, 576000, 
@@ -130,6 +126,98 @@ static pi_major_info_t pi_major_call_tab
 
 static pi_param_info_t irlap_param_info = { pi_major_call_table, 2, 0x7f, 7 };
 
+/* -- LOCAL SUBROUTINES -- */
+/* Note : we start with a bunch of local subroutines.
+ * As the compiler is "one pass", this is the only way to get them to
+ * inline properly...
+ * Jean II
+ */
+/*
+ * Function value_index (value, array, size)
+ *
+ *Returns the index to the value in the specified array
+ */
+static inline int value_index(__u32 value, __u32 *array, int size)
+{
+   int i;
+   
+   for (i=0; i < size; i++)
+   if (array[i] == value)
+   break;
+   return i;
+}
+
+/*
+ * Function index_value (index, array)
+ *
+ *Returns value to index in array, easy!
+ *
+ */
+static inline __u32 index_value(int index, __u32 *array) 
+{
+   return array[index];
+}
+
+/*
+ * Function msb_index (word)
+ *
+ *Returns index to most significant bit (MSB) in word
+ *
+ */
+int msb_index (__u16 word) 
+{
+   __u16 msb = 0x8000;
+   int index = 15;   /* Current MSB */
+   
+   while (msb) {
+   if (word & msb)
+   break;   /* Found it! */
+   msb >>=1;
+   index--;
+   }
+   return index;
+}
+
+static inline __u32 byte_value(__u8 byte, __u32 *array) 
+{
+   int index;
+
+   ASSERT(array != NULL, return -1;);
+
+   index = msb_index(byte);
+
+   return index_value(index, array);
+}
+
+/*
+ * Function value_lower_bits (value, array)
+ *
+ *Returns a bit field marking all possibility lower than value.
+ *We may need a "value_higher_bits" in the future...
+ */
+static inline int value_lower_bits(__u32 value, __u32 *array, int size, __u16 *field)
+{
+   int i;
+   __u16   mask = 0x1;
+   __u16   result = 0x0;
+
+   for (i=0; i < size; i++) {
+   /* Add the current value to the bit field, shift mask */
+   result |= mask;
+   mask <<= 1;
+   /* Finished ? */
+   if (array[i] >= value)
+   break;
+   }
+   /* Send back a valid index */
+   if(i >= size)
+ i = size - 1; /* Last item */
+   *field = result;
+   return i;
+}
+
+/* -- MAIN CALLS -- */
+
 /*
  * Function irda_qos_compute_intersection (qos, new)
  *
@@ -594,99 +682,6 @@ __u32 irlap_requested_line_capacity(stru
   line_capacity);

return line_capacity; 
-}
-
-__u32 irlap_min_turn_time_in_bytes(__u32 speed, __u32 min_turn_time)
-{
-   __u32 bytes;
-   
-   bytes = speed * min_turn_time / 1000;
-   
-   return bytes;
-}
-
-static __u32 byte_value(__u8 byte, __u32 *array) 
-{
-   int index;
-
-   ASSERT(array != NULL, return -1;);
-
-   index = msb_index(byte);
-
-   return index_value(index, array);
-}
-
-/*
- * Function msb_index (word)
- *
- *Returns index to most si

Re: [PATCH] starfire reads irq before pci_enable_device.

[Ion Badulescu]

On Thu, 8 Feb 2001, Jeff Garzik wrote:

> I would prefer that the zerocopy changes stay in DaveM's external patch
> until they are ready to be merged.  

I would actually prefer to have a single source for all the driver 
versions. The 2.2.x version I sent to Alan later on actually compiles on 
2.2, 2.4 and 2.4+zerocopy. I just want to test it some more; the 2.4 
version I submitted was quite well tested.

> Zerocopy is still changing and being
> actively debugged, so it is possible that we might have to patch
> starfire.c again with zerocopy updates, before the final patch makes it
> to Linus.  Let's wait on zerocopy in the main tree..

It's true that zerocopy might change. But remember, zerocopy support in 
the driver is not mandatory, and nobody forces you to #define ZEROCOPY. If 
the zerocopy proves to be unacceptable for the official kernel, ripping 
out the stuff that's #ifdef ZEROCOPY will be a trivial exercise.

> > I've also added myself as the starfire maintainer -- I hope
> > nobody objects.
> 
> If you've got the hardware and time, I'm always happy to see someone
> step up ..  

.. the hardware, the docs, the time, and the day-to-day duty to maintain 
the starfire driver (and the eepro100 driver) for an older version of 
BSDI. It's the job that pays my salary...

> I must confess that I haven't seen much of your work to
> date, however.

Oh well, I thought the code would be enough proof. For what it's worth, 
I was the main developer for the Linux version of Erez Zadok's stackable 
filesystems work. I'm also co-maintainer (with Erez and two more people) 
of the am-utils automounter suite, taking care of the Linux port and 
currently implementing autofs support for Linux and Solaris.

But hey, if you want to continue maintaining the starfire driver yourself, 
I don't really mind.

> > +/*
> > + * The ia64 doesn't allow for unaligned loads even of integers being
> > + * misaligned on a 2 byte boundary. Thus always force copying of
> > + * packets as the starfire doesn't allow for misaligned DMAs ;-(
> > + * 23/10/2000 - Jes
> > + *
> > + * Neither does the Alpha. -Ion
> > + */
> > +#if defined(__ia64__) || defined(__alpha__)
> > +#define PKT_SHOULD_COPY(pkt_len)   1
> > +#else
> > +#define PKT_SHOULD_COPY(pkt_len)   (pkt_len < rx_copybreak)
> > +#endif
> 
> Note that I have not yet sent this patch onto Linus for a reason... 
> Here is Don Becker's comment on the subject:
> 
> Donald Becker wrote:
> > On Tue, 16 Jan 2001, Jeff Garzik wrote:
> > > * IA64 support (Jes)
> > Oh, and this is completely bogus.
> > This isn't a fix, it's a hack that covers up the real problem.
> > 
> > The align-copy should *never* be required because the alignment differs
> > between DIX and E-II encapsulated packets.  The machine shouldn't crash
> > because someone sends you a different encapsulation type!

It's not *required* per se, as far as I know both the Alpha and IA64 have 
handlers for unaligned access traps. *However*, copying each packet is 
definitely better than taking an exception for each packet!

So the box won't crash. But it should behave better with this patch, in 
regular operation.

Jes can probably comment some more, it's his change after all. I have 
neither alphas nor itaniums, so my comment is based on second-hand 
knowledge and on reading the arch code.

> > @@ -757,14 +931,14 @@
> > 
> > dev->trans_start = jiffies;
> > np->stats.tx_errors++;
> > -   return;
> > +   netif_wake_queue(dev);
> >  }
> 
> this has not been sent on to linus/alan because, if you do not empty the
> Tx ring on tx_timeout, you should check to see if there is space on the
> ring before waking the queue.  Otherwise corruption/problems occur...

tx_timeout is completely bogus right now, to be honest. If it gets there,
you might as well just down the interface. So I just applied this part
from your patch, without really thinking about it.

What tx_timeout really needs to do is a full reset and re-initialization
of the chip. Why? Because when the timeout happens, the chip is basically
fubar'ed (usually due to driver bugs, but that's not the point).

It's in the TODO list..

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
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/

No sound on SB line2 anymore?

[torben fjerdingstad]

Since 2.4.0-test5, line2 on my Soundblaster 128 soundcard, which is
connected to on my hauppauge winTV/pci TV card has been silent.
I sure have turned line2 on with a mixer program.
The external line connector sounds OK.

lspci says:
00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
00:0b.0 Multimedia video controller: Brooktree Corporation Bt848 TV with DMA push (rev 
11)

Since linux-2.4.0-test5 (which worked), I have tried the following
kernel versions:
linux-2.4.0-prerelease
linux-2.4.0-ac12
linux-2.4.1-ac6

dmesg says:
i2c-core.o: i2c core module
i2c-algo-bit.o: i2c bit algorithm module
Linux video capture interface: v1.00
bttv: driver version 0.7.50 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
bttv: Bt8xx card found (0).
bttv0: Bt848 (rev 17) at 00:0b.0, irq: 10, latency: 32, memory: 0xdd00
bttv0: model: BT848( *** UNKNOWN *** ) [autodetected]
i2c-core.o: adapter bt848 #0 registered as adapter 0.
bttv0: i2c: checking for MSP34xx @ 0x80... not found
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
i2c-core.o: driver i2c TV tuner driver registered.
tuner: chip found @ 0x61
bttv0: i2c attach [Temic PAL]
i2c-core.o: client [Temic PAL] registered to adapter [bt848 #0](pos. 0).
es1370: version v0.34 time 21:31:10 Feb  8 2001
es1370: found adapter at io 0xa800 irq 5
es1370: features: joystick off, line in, mic impedance 0

Currently I'm using xawtv:
This is xawtv-3.30, running on Linux/i686 (2.4.1-ac6)

In .xawtv I have:
mixer   = line2

It seems to both aumix and xawtv that there is a mixer there,
but no sound comes out, even when line2 is on, and volume=100%.
Otherwise the sound card works fine.

What's up?

-- 
Med venlig hilsen / Regards 
Netdriftgruppen / Network Management Group
UNI-C  

Tlf./Phone   +45 35 87 89 41Mail:  UNI-C
Fax. +45 35 87 89 90   Bygning 304
E-mail: [EMAIL PROTECTED]   DK-2800 Lyngby

-
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] patch-2.4.1-irda2 (irlan)

[Dag Brattli]

Linus,

Here is a patch that fixes the problem of attaching to IrLAN
devices in Linux-2.4.1. 

The problem was that the IrLAN driver forgot to memorize the
hardware address of the remote device and instead used the
broadcast address, which sometimes did work, but not always
(since doing so is actually a bug)

Have also added the dynalloc flag to irlan, since it does 
allocate it's network devices dynamically.

-- Dag

diff -urpN linux-2.4.1/net/irda/irlan/irlan_client.c 
linux/net/irda/irlan/irlan_client.c
--- linux-2.4.1/net/irda/irlan/irlan_client.c   Sun Nov 12 03:11:23 2000
+++ linux/net/irda/irlan/irlan_client.c Thu Feb  8 09:08:41 2001
@@ -120,8 +120,9 @@ void irlan_client_wakeup(struct irlan_cb
return;
}
 
-   /* Address may have changed! */
+   /* Addresses may have changed! */
self->saddr = saddr;
+   self->daddr = daddr;
 
if (self->disconnect_reason == LM_USER_REQUEST) {
IRDA_DEBUG(0, __FUNCTION__ "(), still stopped by user\n");
diff -urpN linux-2.4.1/net/irda/irlan/irlan_eth.c linux/net/irda/irlan/irlan_eth.c
--- linux-2.4.1/net/irda/irlan/irlan_eth.c  Sun Nov 12 03:11:23 2000
+++ linux/net/irda/irlan/irlan_eth.cThu Feb  8 09:08:41 2001
@@ -61,6 +61,7 @@ int irlan_eth_init(struct net_device *de
dev->hard_start_xmit= irlan_eth_xmit; 
dev->get_stats  = irlan_eth_get_stats;
dev->set_multicast_list = irlan_eth_set_multicast_list;
+   dev->features  |= NETIF_F_DYNALLOC;
 
ether_setup(dev);


-
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] modify ver_linux to check e2fsprogs and more.

[Steven Cole]

I have modified the scripts/ver_linux script to provide the following:

1) The order of version checks is now the same as the list in the
   Current Minimal Requirements section of Documentation/Changes
   for easier comparison.
2) Made capitalization  consistent with the list in Changes.
3) Added version check for ext2 utils (e2fsprogs).
4) Added version check for pcmcia utils (pcmcia-cs).
5) Added version check for pppd (PPP).
6) Added version check for isdn utils (isdn4k-utils).
7) Added whitespace for better readability.

Due to the extensive rewriting, the patch against 2.4.1-ac6 is
larger than the ver_linux script itself.  I will include the proposed
new version of ver_linux here inline, and I will attach the patch itself,
which isn't as readable. This patch should apply against -ac5 and -ac7 also.

Here is the output of the current ver_linux for my system:

[root@localhost scripts]# ./ver_linux.orig
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux localhost.localdomain 2.4.1-ac6 #1 Thu Feb 8 06:30:46 MST 2001 i686 unknown
Kernel modules 2.4.2
Gnu C  2.95.3
Gnu Make   3.79.1
Binutils   2.10.0.24
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.7
Mount  2.10o
Net-tools  1.57
Console-tools  0.2.3
Reiserfsprogs  3.x.0b
Sh-utils   2.0
Modules Loaded

Here is the output of the new ver_linux:

[root@localhost scripts]# ./ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux localhost.localdomain 2.4.1-ac6 #1 Thu Feb 8 06:30:46 MST 2001 i686 unknown

Gnu C  2.95.3
Gnu make   3.79.1
binutils   2.10.0.24
util-linux 2.10o
modutils   2.4.2
e2fsprogs  1.19
reiserfsprogs  3.x.0b
pcmcia-cs  3.1.24
PPP2.4.0
isdn4k-utils   3.1beta7
Linux C Library2.1.3
Dynamic linker (ldd)   2.1.3
Procps 2.0.7
Net-tools  1.57
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded

This output can be compared with the list in Documentation/Changes:

o  Gnu C  2.91.66 # gcc --version
o  Gnu make   3.77# make --version
o  binutils   2.9.1.0.25  # ld -v
o  util-linux 2.10o   # fdformat --version
o  modutils   2.4.2   # insmod -V
o  e2fsprogs  1.19# tune2fs
o  reiserfsprogs  3.x.0b  # reiserfsck 2>&1|grep reiserfsprogs
o  pcmcia-cs  3.1.21  # cardmgr -V
o  PPP2.4.0   # pppd --version
o  isdn4k-utils   3.1pre1 # isdnctrl 2>&1|grep version

Here is the proposed new version of ver_linux, patch against 2.4.1-ac6 attached.

#!/bin/sh
# Before running this script please ensure that your PATH is
# typical as you use for compilation/istallation. I use
# /bin /sbin /usr/bin /usr/sbin /usr/local/bin, but it may
# differ on your system.
#
PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH
echo 'If some fields are empty or look unusual you may have an old version.'
echo 'Compare to the current minimal requirements in Documentation/Changes.'
echo ' '

uname -a
echo ' '

echo "Gnu C " `gcc --version`

make --version 2>&1 | awk -F, '{print $1}' | awk \
  '/GNU Make/{print "Gnu make  ",$NF}'

ld -v 2>&1 | awk -F\) '{print $1}' | awk \
  '/BFD/{print "binutils  ",$NF}'

mount --version | awk -F\- '{print "util-linux", $NF}'

insmod -V  2>&1 | awk 'NR==1 {print "modutils  ",$NF}'

tune2fs 2>&1 | grep tune2fs | sed 's/,//' |  awk \
'NR==1 {print "e2fsprogs ", $2}'

reiserfsck 2>&1 | grep reiserfsprogs | awk \
'NR==1{print "reiserfsprogs ", $NF}'

cardmgr -V 2>&1| grep version | awk \
'NR==1{print "pcmcia-cs ", $3}'

pppd --version 2>&1| grep version | awk \
'NR==1{print "PPP   ", $3}'

isdnctrl 2>&1 | grep version | awk \
'NR==1{print "isdn4k-utils  ", $NF}'

ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | sed \
-e 's/\.so$//' | awk -F'[.-]'   '{print "Linux C Library" \
$(NF-2)"."$(NF-1)"."$NF}'

ldd -v > /dev/null 2>&1 && ldd -v || ldd --version |head -1 | awk \
'NR==1{print "Dynamic linker (ldd)  ", $NF}'

ls -l /usr/lib/lib{g,stdc}++.so  2>/dev/null | awk -F. \
   '{print "Linux C++ Library  " $4"."$5"."$6}'

ps --version 2>&1 | awk 'NR==1{print "Procps", $NF}'

hostname -V 2>&1 | awk 'NR==1{print "Net-tools ", $NF}'

# Kbd needs 'loadkeys -h',
loadkeys -h 2>&1 | awk \
'(NR==1 && ($3 !~ /option/)) {print "Kbd   

[patch] patch-2.4.1-irda1 (irtty)

[Dag Brattli]

Linus,

Here is a patch that fixes a kernel crash people have 
experiended when using IrDA dongles with Linux-2.4.

The problem was that the netdev was deallocated a bit
to early at close time.

Please apply to your latest 2.4 code.

-- Dag

--- linux/drivers/net/irda/irtty.c.orig Sun Jan 21 23:35:44 2001
+++ linux/drivers/net/irda/irtty.c  Sun Jan 21 23:36:30 2001
@@ -279,6 +279,11 @@ static void irtty_close(struct tty_struc
tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP);
tty->disc_data = 0;

+   /* We are not using any dongle anymore! */
+   if (self->dongle)
+   irda_device_dongle_cleanup(self->dongle);
+   self->dongle = NULL;
+
/* Remove netdevice */
if (self->netdev) {
rtnl_lock();
@@ -286,11 +291,6 @@ static void irtty_close(struct tty_struc
rtnl_unlock();
}

-   /* We are not using any dongle anymore! */
-   if (self->dongle)
-   irda_device_dongle_cleanup(self->dongle);
-   self->dongle = NULL;
-
/* Remove speed changing task if any */
if (self->task)
irda_task_delete(self->task);

-
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] starfire reads irq before pci_enable_device.

[Jeff Garzik]

Ion Badulescu wrote:
> 
> Hi Jeff,
> 
> On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> 
> > Here's the patch I have, against vanilla 2.4.2-pre1, with the
> > pci_enable_device preferred changes included...
> 
> Well, I decided to bite the bullet and port my zerocopy starfire
> changes to the official tree, properly ifdef'ed. So here it goes,
> the patch was made against 2.4.1 vanilla and includes all the
> fixes from Jeff and myself that were sent to the list so far.

I would prefer that the zerocopy changes stay in DaveM's external patch
until they are ready to be merged.  Zerocopy is still changing and being
actively debugged, so it is possible that we might have to patch
starfire.c again with zerocopy updates, before the final patch makes it
to Linus.  Let's wait on zerocopy in the main tree..


> I've also added myself as the starfire maintainer -- I hope
> nobody objects.

If you've got the hardware and time, I'm always happy to see someone
step up ..   I must confess that I haven't seen much of your work to
date, however.


> +/*
> + * The ia64 doesn't allow for unaligned loads even of integers being
> + * misaligned on a 2 byte boundary. Thus always force copying of
> + * packets as the starfire doesn't allow for misaligned DMAs ;-(
> + * 23/10/2000 - Jes
> + *
> + * Neither does the Alpha. -Ion
> + */
> +#if defined(__ia64__) || defined(__alpha__)
> +#define PKT_SHOULD_COPY(pkt_len)   1
> +#else
> +#define PKT_SHOULD_COPY(pkt_len)   (pkt_len < rx_copybreak)
> +#endif

Note that I have not yet sent this patch onto Linus for a reason... 
Here is Don Becker's comment on the subject:

Donald Becker wrote:
> On Tue, 16 Jan 2001, Jeff Garzik wrote:
> > * IA64 support (Jes)
> Oh, and this is completely bogus.
> This isn't a fix, it's a hack that covers up the real problem.
> 
> The align-copy should *never* be required because the alignment differs
> between DIX and E-II encapsulated packets.  The machine shouldn't crash
> because someone sends you a different encapsulation type!

> @@ -757,14 +931,14 @@
> 
> dev->trans_start = jiffies;
> np->stats.tx_errors++;
> -   return;
> +   netif_wake_queue(dev);
>  }

this has not been sent on to linus/alan because, if you do not empty the
Tx ring on tx_timeout, you should check to see if there is space on the
ring before waking the queue.  Otherwise corruption/problems occur...

Jeff


-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
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: nvidia fb 0.9.0 (0.9.2?)

[Louis Garcia]

Bakonyi Ferenc wrote:

> /me wrote:
> 
>> Louis Garcia <[EMAIL PROTECTED]> wrote:
>> 
>>> I'm using XFree86-4.0.1 with the nv driver. You are right, it's ver 
>>> 0.9.2 for the fb.
>>> 
>>> Where can I get the patch? Should I upgrade to XFree86-4.0.2?
>> 
>> Not yet, we have to write that patch first... :) I'll grab an XFree 
>> source soon.
>> Please test other color depths too: 15bpp and 32bpp.
> 
> 
>   Hi!
> 
> I've tried to reproduce your problem, but I failed. Rivafb 0.9.2 on 
> Asus V3000 (Riva 128) with nv driver (from XFree-4.0.1g, Debian 
> Woody) works fine for me. Would you like to try out some other XFree 
> versions too?
> 
> Regards:
>   Ferenc Bakonyi
> 
> 
> 
> 
On a nvidia riva 128 and a stock rh7 with kernel-2.4.1ac4 and above 
which has rivafb-0.9.2 when I startx the desktop is dark. This is in 
16bit and 24bit modes.
I have been told the Riva hardware can be programmed to expect 8 bit or 
6 bit color registers. Rivafb < 0.7.2 used 6 bit color registers, but 
the hw was programmed to 8 bit registers on TNT/TNT2. That was causing 
the so called 'dark console' bug. Rivafb 0.9.2 begins to utilize 8 bits 
on Riva 128, but the XFree86-4.0.1 server uses only 6 bits of them so 
your desktop's brightness is 1/4.

Louis Garcia

-
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/

Oops in 2.4.1-ac6 (and all older than 2.2.x)

[Jean-luc Coulon]

Hi !

I experienced a Oops with all versions  of the kernel newer than 2.2.x :

Here is the Oops processed by ksymoops. In this case, it was with
2.4.1-ac6.
This oops seems related to ax25 (hamradio) use. I can have access to
magic keys
(but the reboot one, but I _never_ managed to have this one to work,
maybe a
configuration problem with my French keyboard ?).
After trying a remount, I got :
SysReq : Emergency Remount R/O
Remounting device 03:02... Scheduling in interrupt
Kernel BUG at sched.c:714!
incalid operand:  ... etc. etc.

ksymoops 2.3.7 on i586 2.4.1-ac6.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.1-ac6/ (default)
 -m /boot/System.map-2.4.1-ac6 (specified)

Warning (compare_maps): ksyms_base symbol
__VERSIONED_SYMBOL(shmem_file_setup) not found in System.map.  Ignoring
ksyms_base entry
Unable to handle kernel paging request at virtual address fffc
c0112c38
*pde = 1063
Oops: 
CPU: 0
EIP: 0010 : []
Using defaults from ksymoops -t elf32-i386 -a i386
eax: c5c3aec4 eb:  ecx: 0001 edx: c5c3aec8
esi: c3dc8680 edi: fff8 ebp: c5219f54 esp: c5219f38
ds: 0018 es: 0018 ss:0018
Process make (pid: 1565, stackpage=c5219000)
stack: c5c3aec4 c3dc8680 c02336fc c5c3aec8 0282 0001 0001
c5219fbc
   c018c72f c3dc8680 c4d66140 c018c03f c3dc8680  c018cba2
c4d66140
    c02336fc c018e6d3 c4d66140 0001 c02335c8 000d
c0118470
Call Trace: [] [] [] []
[] [] []
Code : 8b 4f 04 8b 1b 8b 01 85 45 fc 74 4c 9c 5e fa c7 01 00 00 00

>>EIP; c0112c38 <__wake_up+28/98>   <=
Trace; c018c72f 
Trace; c018c03f 
Trace; c018cba2 <__kfree_skb+7e/f4>
Trace; c018e6d3 
Trace; c0118470 
Trace; c010a132 
Trace; c0108e00 
Code;  c0112c38 <__wake_up+28/98>
 <_EIP>:
Code;  c0112c38 <__wake_up+28/98>   <=
   0:   8b 4f 04  mov0x4(%edi),%ecx   <=
Code;  c0112c3b <__wake_up+2b/98>
   3:   8b 1b mov(%ebx),%ebx
Code;  c0112c3d <__wake_up+2d/98>
   5:   8b 01 mov(%ecx),%eax
Code;  c0112c3f <__wake_up+2f/98>
   7:   85 45 fc  test   %eax,0xfffc(%ebp)
Code;  c0112c42 <__wake_up+32/98>
   a:   74 4c je 58 <_EIP+0x58> c0112c90
<__wake_up+80/98>
Code;  c0112c44 <__wake_up+34/98>
   c:   9cpushf
Code;  c0112c45 <__wake_up+35/98>
   d:   5epop%esi
Code;  c0112c46 <__wake_up+36/98>
   e:   facli
Code;  c0112c47 <__wake_up+37/98>
   f:   c7 01 00 00 00 00 movl   $0x0,(%ecx)

Kernel panic: Aiee, killing the interrupt handler!

1 warning issued.  Results may not be reliable.

--

Best regards

  Jean-Luc


-
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: [NEW][PATCH] updates for KLSI

[Eric Sandeen]

Greg KH wrote:

> Silently changing descriptor ids while connected is just asking for
> trouble :)

Ok, fair enough - here's a patch against 2.4.1-ac6 which causes the
device to disconnect/reconnect after firmware load (and a couple other
minor kernel logging & formatting cleanups, plus one more device ID).

-Eric

--- linux/drivers/usb/kaweth.c.ac6  Thu Feb  8 10:47:40 2001
+++ linux/drivers/usb/kaweth.c  Thu Feb  8 11:08:16 2001
@@ -131,6 +131,7 @@
{ USB_DEVICE(0x066b, 0x2202) }, /* Linksys USB10T */ 
{ USB_DEVICE(0x1645, 0x0005) }, /* Entrega E45 */ 
{ USB_DEVICE(0x2001, 0x4000) }, /* D-link DSB-650C */
+   { USB_DEVICE(0x07b8, 0x4000) }, /* D-Link DU-E10 */
{} /* Null terminator */
 };
 
@@ -647,9 +648,10 @@
if (net->flags & IFF_PROMISC) {
packet_filter_bitmap |= KAWETH_PACKET_FILTER_PROMISCUOUS;
} 
-   else if ((net->mc_count) ||  (net->flags & IFF_ALLMULTI)) {
+   else if ((net->mc_count) || (net->flags & IFF_ALLMULTI)) {
packet_filter_bitmap |= KAWETH_PACKET_FILTER_ALL_MULTICAST;
}
+
kaweth->packet_filter_bitmap = packet_filter_bitmap;
netif_wake_queue(net);
 }
@@ -721,11 +723,7 @@
const eth_addr_t bcast_addr = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
int result = 0;
 
-   result = usb_get_device_descriptor(dev);
-   if (result < 0)
-   kaweth_err("Error re-loading device descriptor");
-   
-   kaweth_dbg("Kawasaki Device Probe (Device number:%d): 0x%4.4x:0x%4.4x revision 
0x%4.4x",
+   kaweth_dbg("Kawasaki Device Probe (Device number:%d): 0x%4.4x:0x%4.4x:0x%4.4x",
 dev->devnum, 
 (int)dev->descriptor.idVendor, 
 (int)dev->descriptor.idProduct,
@@ -754,52 +752,65 @@
kaweth_reset(kaweth);
 
/*
-* If we got bcdDevice 0x0202, firmware is already present,
-* don't try to download again.
+* If high byte of bcdDevice is nonzero, firmware is already
+* downloaded. Don't try to do it again, or we'll hang the device.
 */
 
-   if ((int)dev->descriptor.bcdDevice != 0x0202) {
-
-   if((result = kaweth_download_firmware(kaweth, 
+   if (dev->descriptor.bcdDevice >> 8) {
+   kaweth_info("Firmware present in device.");
+   } else {
+   /* Download the firmware */
+   kaweth_info("Downloading firmware...");
+   if ((result = kaweth_download_firmware(kaweth, 
  kaweth_new_code, 
  len_kaweth_new_code, 
  100, 
- 2)) < 0){
-   kaweth_err("Error downloading firmware (%d), no net device 
created", result);
+ 2)) < 0) {
+   kaweth_err("Error downloading firmware (%d)", result);
kfree(kaweth);
return NULL;
}
 
-   if((result = kaweth_download_firmware(kaweth, 
+   if ((result = kaweth_download_firmware(kaweth, 
  kaweth_new_code_fix, 
  len_kaweth_new_code_fix, 
  100, 
  3)) < 0) {
-   kaweth_err("Error downloading firmware fix (%d), no net device 
created", result);
+   kaweth_err("Error downloading firmware fix (%d)", result);
kfree(kaweth);
return NULL;
}
 
-   if((result = kaweth_trigger_firmware(kaweth, 100)) < 0){
-   kaweth_err("Error triggering firmware (%d), no net device 
created\n", result);
+   if ((result = kaweth_download_firmware(kaweth,
+ kaweth_trigger_code,
+ len_kaweth_trigger_code,
+ 126,
+ 2)) < 0) {
+   kaweth_err("Error downloading trigger code (%d)", result);
kfree(kaweth);
return NULL;
}
 
-   udelay(1000);
+   if ((result = kaweth_download_firmware(kaweth,
+ kaweth_trigger_code_fix,
+ len_kaweth_trigger_code_fix,
+ 126,
+ 3)) < 0) {
+   kaweth_err("Error downloading trigger code fix (%d)", res

Re: nfs_refresh_inode: inode number mismatch

[Russell King]

Neil Brown writes:
> On Wednesday February 7, [EMAIL PROTECTED] wrote:
> > This is a weird problem that I am looking at right.  It seems to indicate a
> > bug in the nfs server.
> > 
> > I have a MIPS machine that boots from a NFS root fs hosted on a redhat 6.2
> > workstation.  Everything works fine except that after a few reboots I start to
> > see the error messages like the following:
> 
> What verison of Linux?  If it is less than 2.2.18, then an upgrade 
> will help you a lot.
> 
> If it is >= 2.2.18, I will look some more.

Note that you need to upgrade the server, not the client.  Also, make sure
you don't reboot the client more than once in a 2 minute time window.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

-
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 on GA-7ZX (2.4.1-ac6, via audio)

[Jeff Garzik]

Martin Braun wrote:
> I can not get sound working on a computer with a Gigabyte
> GA-7ZX mainboard (KT133 chipset). Is this a known problem?
> I have attached some config info. Mail me for further details.

> $ cat /proc/driver/via/0/*
> Vendor name  : SigmaTel STAC
> Vendor id: 8384 7600

1) Have you turned the master volume and PCM volume -way- up?

2) Does 2.4.1-ac5 work for you?  (ie. did 2.4.1-ac6 break something?)

Jeff



-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Stephen C. Tweedie]

Hi,

On Thu, Feb 08, 2001 at 03:52:35PM +0100, Mikulas Patocka wrote:
> 
> > How do you write high-performance ftp server without threads if select
> > on regular file always returns "ready"?
> 
> No, it's not really possible on Linux. Use SYS$QIO call on VMS :-)

Ahh, but even VMS SYS$QIO is synchronous at doing opens, allocation of
the IO request packets, and mapping file location to disk blocks.
Only the data IO is ever async (and Ben's async IO stuff for Linux
provides that too).

--Stephen
-
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: TCP_NOPUSH on FreeBSD, TCP_CORK on Linux (was: Is sendfile all that

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Tony Finch  <[EMAIL PROTECTED]> wrote:
>Dan Kegel <[EMAIL PROTECTED]> wrote:
>>
>>Tony, are people using the TCP_NOPUSH define as a way to detect
>>the presence of T/TCP support?
>
>No, MSG_EOF is the right way to do that.

However, I think ank is at least partially correct: TCP_NOPUSH has some
magic behaviour for sockets in listen state, and turns on at least some
T/TCP semantics, if I remember correctly. Tony?

If I remember correctly, may I suggest something: make a new BSD option
called (ehh, just random name ;) TCP_CORK, and make the old BSD
TCP_NOPUSH option be a superset of TCP_CORK that also turns on T/TCP on
listen sockets.

Linux TCP_CORK doesn't have anything to do with T/TCP (not surprisingly,
as T/TCP is considered a broken protocol in Linux and other circles).

And Linux TCP_CORK _is_ used on listen sockets: it makes sockets that
are accepted from the listen socket have the corking semantics. In
contrast, BSD TCP_NOPUSH, I think, has this overloading issue..

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: [Patch] ServerWorks peer bus fix for 2.4.x

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Martin Mares  <[EMAIL PROTECTED]> wrote:
>
>What leads you to your belief it's correct? The lspci dump Adam has sent
>to the list shows that there's something utterly wrong with our understanding
>of the ServerWorks config registers -- they seem to say that the primary
>bus numbers are 00 and 01, but in reality they are 00 and 02.

Is there any reason to not just change the default pcibios_last_bus to
255, and just always default to scanning all PCI bus numbers?

Alternatively, how about just changing the fixups to be saner. Right now
they are obviously bogus, and don't even match with their comments.
Somehting like this..

Linus


--- old-linux/arch/i386/kernel/pci-pc.c Thu Jun 22 07:17:16 2000
+++ linux/arch/i386/kernel/pci-pc.c Thu Feb  8 11:36:58 2001
@@ -843,30 +843,40 @@
pcibios_last_bus = -1;
 }
 
+/*
+ * ServerWorks host bridges -- Find and scan all secondary buses.
+ * Register 0x44 contains first, 0x45 last bus number routed there.
+ */
 static void __init pci_fixup_serverworks(struct pci_dev *d)
 {
-   /*
-* ServerWorks host bridges -- Find and scan all secondary buses.
-* Register 0x44 contains first, 0x45 last bus number routed there.
-*/
-   u8 busno;
-   pci_read_config_byte(d, 0x44, &busno);
-   printk("PCI: ServerWorks host bridge: secondary bus %02x\n", busno);
-   pci_scan_bus(busno, pci_root_ops, NULL);
-   pcibios_last_bus = -1;
+   u8 busno1, busno2;
+
+   pci_read_config_byte(d, 0x44, &busno1);
+   pci_read_config_byte(d, 0x45, &busno2);
+   if (busno2 < busno1)
+   busno2 = busno1;
+   if (busno2 > pcibios_last_bus) {
+   pcibios_last_bus = busno2;
+   printk("PCI: ServerWorks host bridge: last bus %02x\n", 
+pcibios_last_bus);
+   }
 }
 
+/* 
+ * Compaq host bridges -- Find and scan all secondary buses.
+ * This time registers 0xc8 and 0xc9.
+ */
 static void __init pci_fixup_compaq(struct pci_dev *d)
 {
-   /*  
-* Compaq host bridges -- Find and scan all secondary buses.
-* This time registers 0xc8 and 0xc9.
-*/
-   u8 busno;
-   pci_read_config_byte(d, 0xc8, &busno);
-   printk("PCI: Compaq host bridge: secondary bus %02x\n", busno);
-   pci_scan_bus(busno, pci_root_ops, NULL);
-   pcibios_last_bus = -1;
+   u8 busno1, busno2;
+
+   pci_read_config_byte(d, 0xc8, &busno1);
+   pci_read_config_byte(d, 0xc9, &busno2);
+   if (busno2 < busno1)
+   busno2 = busno1;
+   if (busno2 > pcibios_last_bus) {
+   pcibios_last_bus = busno2;
+   printk("PCI: Compaq host bridge: last bus %02x\n", busno2);
+   }
 }
 
 static void __init pci_fixup_umc_ide(struct pci_dev *d)

-
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: Linux 2.4.1-ac7

[Tigran Aivazian]

Doug,

I confirm that ac7 fixed all the aic7xxx problems on my machine.

Thanks,
Tigran

-
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: Linux 2.4.1-ac7

[Tigran Aivazian]

two mistakes:

a) [EMAIL PROTECTED], not veritas.com! (it was pine, not me -- default
domain etc :)

b) it was ac6 which fixed it, not ac7 (but I am running ac7)

On Thu, 8 Feb 2001, Tigran Aivazian wrote:

> Doug,
> 
> I confirm that ac7 fixed all the aic7xxx problems on my machine.
> 
> Thanks,
> Tigran
> 
> 

-
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] to deal with bad dev->refcnt in unregister_netdevice()

[kuznet]

Hello!

> Here is a patch which may not solve the underlying

This does not. refcnt cannot be <1 at this point.


> assuming that the latter messages aren't serious?

They are fatal. Machine must be rebooted after them.


> I hope the networking gurus can find the real bugs here.

Well, someone forgets to grab refcnt or makes redundant dev_put.
Try to catch this, f.e. adding BUG() to the places where fatal
messages are generated to get backtraces.

Alexey
-
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] micro-opt DEBUG_ADD_PAGE

[Richard B. Johnson]

On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:

> "Richard B. Johnson" wrote:
> > 
> > On Thu, 8 Feb 2001, Stephen Wille Padnos wrote:
> > 
> > > "Richard B. Johnson" wrote:
> > > [snip]
> > > > Another problem with 'volatile' has to do with pointers. When
> > > > it's possible for some object to be modified by some external
> > > > influence, we see:
> > > >
> > > > volatile struct whatever *ptr;
> > > >
> > > > Now, it's unclear if gcc knows that we don't give a damn about
> > > > the address contained in 'ptr'. We know that it's not going to
> > > > change. What we are concerned with are the items within the
> > > > 'struct whatever'. From what I've seen, gcc just reloads the
> > > > pointer.
> > > >
> [snip]
> 
> > Yes. My point is that a lot of authors have declared just about everything
> > 'volatile' `grep volatile /usr/src/linux/drivers/net/*.c`, just to
> > be "safe". It's likely that there are many hundreds of thousands of
> > unneeded register-reloads because of this.
> > 
> > It might be useful for somebody who has a lot of time on his/her
> > hands to go through some of these drivers.
> 
> I would be willing to do this (on the slow boat - I don't have THAT much
> spare time :), but only if we can be sure that the gcc optimizer will
> correctly handle a normal pointer to volatile data.  Your experiences
> would seem to indicate that the optimizer needs fixing before much
> effort should be spent on this.
> 

Well the question for that is; "What compiler?". I'm currently
using egcs-2.91.66, one of the "approved" versions for compiling
the kernel. It treats all volatiles about the same:


volatile int i;
volatile int *p;
int volatile *q;
volatile int * volatile r;

void foo()
{
   while(*p == i) 
   ;
   while(*q == i) 
   ;
   while(*r == i) 
   ;
}
...makes :


.file   "main.c"
.version"01.01"
gcc2_compiled.:
.text
.align 4
.globl foo
.typefoo,@function
foo:
pushl %ebp
movl %esp,%ebp
nop
.align 4
.L2:
movl p,%eax
movl (%eax),%edx
movl i,%eax
cmpl %eax,%edx
je .L4
jmp .L3
.align 4
.L4:
jmp .L2
.align 4
.L3:
nop
.align 4
.L5:
movl q,%eax
movl (%eax),%edx
movl i,%eax
cmpl %eax,%edx
je .L7
jmp .L6
.align 4
.L7:
jmp .L5
.align 4
.L6:
nop
.align 4
.L8:
movl r,%eax
movl (%eax),%edx
movl i,%eax
cmpl %eax,%edx
je .L10
jmp .L9
.align 4
.L10:
jmp .L8
.align 4
.L9:
.L1:
movl %ebp,%esp
popl %ebp
ret
.Lfe1:
.sizefoo,.Lfe1-foo
.comm   i,4,4
.comm   p,4,4
.comm   q,4,4
.comm   r,4,4
.ident  "GCC: (GNU) egcs-2.91.66 19990314 (egcs-1.1.2 release)"


Since there seems to be a rather big difference between what is
expected to be done, and what happens to be the result, this
certainly contributes to the possible over-use of 'volatile' in
some kernel code. 

It's certainly better to be safe than sorry, but in some cases "safe"
is just a bit "strange". FYI, ../linux/drivers/net/atp.c doesn't use
'volatile' at all. However, ../linux/drivers/net/bmac.c uses it 40
times. I'll bet a buck that both of the drivers work and the one
without 'volatile' keywords does the work with fewer instructions.

These are just two drivers chosen at random. The driver I've been
working on to make  'bullet proof', pcnet32.c uses 'volatile' twice.
And, at least in one occasion, the wrong thing is declared volatile
(the value in a pointer to a structure ), however gcc doesn't seem
to care because it reloads the values of the structure members every time,
anyway. So, in this case, the address-value in the pointer will never
change, but gcc reloads all the pointed-to members anyway, so the
'volatile' keyword not useful.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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/

No sound on GA-7ZX (2.4.1-ac6, via audio)

[Martin Braun]

Hello all

I can not get sound working on a computer with a Gigabyte
GA-7ZX mainboard (KT133 chipset). Is this a known problem?
I have attached some config info. Mail me for further details.

Thanks in advance,

Martin Braun
-- 
+-+--+
| Martin Braun (Dipl.-Phys.)  | EMail: [EMAIL PROTECTED] |
| Fraunhofer Institut für Techno- |  |
| und Wirtschaftsmathematik   | Tel.: ++49(0)631/36681-19|
| Gottlieb-Daimler-Straße | Fax : ++49(0)631/36681-66|
| D-67663 Kaiserslautern  | Geb.: PRE-Park 209   |
+-+--+

Script started on Thu Feb  8 20:15:30 2001
$ lsmod
Module  Size  Used by
nfs77632   4  (autoclean)
lockd  49872   1  (autoclean) [nfs]
sunrpc 59584   1  (autoclean) [nfs lockd]
eepro100   17536   1  (autoclean)
via82cxxx_audio27680   0 
ac97_codec  8720   0  [via82cxxx_audio]
soundcore   4240   2  [via82cxxx_audio]
usb-uhci   22128   0  (unused)
usbcore48656   1  [usb-uhci]
$ play /usr/share/sounds/KDE_Startup.wav
sox: Unable to set audio speed to 22050 (set to 0)
sox: Sampling rate for /dev/dsp file was not given

$ cat /proc/driver/via/0/*
Vendor name  : SigmaTel STAC
Vendor id: 8384 7600
AC97 Version : 1.0
Capabilities :
DAC resolutions  : -16-bit- -18-bit-
ADC resolutions  : -16-bit- -18-bit-
3D enhancement   : SigmaTel 3D Enhancement
POP path : pre 3D
Sim. stereo  : off
3D enhancement   : off
Loudness : off
Mono output  : MIX
MIC select   : MIC1
ADC/DAC loopback : off
Ext Capabilities :
VIA 82Cxxx Audio driver 1.1.14a

Via 82Cxxx PCI registers:

40  Codec Ready: yes
Codec Low-power: no
Secondary Codec Ready: no

41  Interface Enable: enable
De-Assert Reset: yes
Force SYNC high: no
Force SDO high: no
Variable Sample Rate On-Demand Mode: enable
SGD Read Channel PCM Data Out: enable
FM Channel PCM Data Out: disable
SB PCM Data Out: disable

42  Game port enabled: yes
SoundBlaster enabled: no
FM enabled: no
MIDI enabled: no

44  AC-Link Interface Access: no
Secondary Codec Support: no

$ lspci -vx
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
Flags: bus master, medium devsel, latency 8
Memory at e000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00: 06 11 05 03 06 00 10 22 02 00 00 06 00 08 00 00
10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00

00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal 
decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 9000-9fff
Memory behind bridge: dda0-dfaf
Prefetchable memory behind bridge: cd80-dd8f
Capabilities: [80] Power Management version 2
00: 06 11 05 83 07 00 30 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 90 90 00 00
20: a0 dd a0 df 80 cd 80 dd 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Flags: bus master, stepping, medium devsel, latency 0
00: 06 11 86 06 87 00 10 02 22 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 86 06
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 
8a [Master SecP PriP])
Flags: bus master, medium devsel, latency 32
I/O ports at ffa0 [size=16]
Capabilities: [c0] Power Management version 2
00: 06 11 71 05 07 00 90 02 10 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: a1 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 00 00

00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 
[UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 64, IRQ 9
I/O ports at c000 [size=32]
Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 01 10 02 10 00 03 0c 08 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 c0 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 09 04 00 00

00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 
[UHCI])

Linux 2.4.1-ac7

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

2.4.1-ac7
o   Rebalance the 2.4.1 VM  (Rik van Riel)
| This should make things feel a lot faster especially
| on small boxes .. feedback to Rik
o   Silence osf syscall error printk(Ivan Kokshaysky)
o   Don't trust ARC irq routing on ruffian  (Ivan Kokshaysky)
o   Report the right module on 3c59x for pcmcia (Arjan van de Ven)
o   Update i82365 driver to add locks, delays, and  (Arjan van de Ven)
'bouncing' on the card detect
o   Get the name right on ide-cs (v ide_cs) and do  (Arjan van de Ven)
resource claims
o   Merge parport_cs(David Hinds)
o   Merge sedlbauer_cs  (Marcus Niemann)
o   Fix a bug in the Cyrix pirq routing (me)

2.4.1-ac6
o   Fix eepro100 reporting on lockup fix(Ion Badulescu)
o   Clean up i810 error message (me)
o   Fix S390 build bug  (me)
o   Update version id on cpqarray driver(Charles White)
o   Further aic7xxx fixes   (Doug Ledford)
| again please report aic7xxx stuff to Doug
o   Further maxiradio cleanups  (Dimitromanolakis Apostolos)
o   Change ide to use mdelay cleanly(Petr Vandrovec)
| Still broken for PROMISE if no IDE_CS
o   Fix duplicated ncpfs fix(Petr Vandrovec)
o   Improve inode hash function (Dave Miller)
o   Correct 62 misspellings of transferred  (Andre Dahlqvist)
o   Update AC97 codec setup and tables  (Jeff Garzik)

2.4.1-ac5
o   Fix zero page corruption(Ben La Haise)
o   Elevator corruption fixes   (Jens Axboe, Linus)
o   Fix fdatasync possible corruption problem   (Arjan van de Ven)
o   Further KSLI ethernet fixes (Eric Sandeen)
o   Merge the correct version of the pm fixes   (me)
| noted by Mikael Pettersson
o   Account for inode/dcache in free memory (Rik van Riel)
o   Add info on how to check reiserfsprogs versions (Steven Cole)
o   Disable write combining on serverworks LE chips (Mark Rusk)
o   Fix via audio crashes   (Jeff Garzik)
o   Fix ip accounting rules bug (Rusty Russell)
o   Handle USB printers that use device not (Johannes Erdfelt)
interface descriptors
o   Fix wheel on graphire usb tablet(Peter Hofmann)
o   Clean up maxiradio driver   (Francois Romieu)
o   Fix visor USB size reporting on buffers (Greg Kroah-Hartmann)
o   Update USB serial documentation (Greg Kroah-Hartmann)
o   Fix locking on etherworks3 ethernet (Jeff Garzik)
o   Fix empeg USB driver problems   (Gary Brubaker)
o   Generic USB serial driver fixes (Greg Kroah-Hartmann)
o   Update USB serial configure.help(Greg Kroah-Hartmann)
o   Add more device support to mct_u232 USB (Cornel Ciocirlan)
o   Fix typo in asm-ppc/semaphore.h (Andre Dahlqvist)
o   Report reiserfs tools in ver_linux  (Steven Cole)
o   Fix resource leaks in NCR_53c406, atari_scsi(Rasmus Andersen)
and qlogicisp
o   Move pci_enable_device earlier for hamachi  (Dave Jones)
o   Type 6 drives are apparently floppy 2.88M   (Dave Jones)
o   Remove duplicate pci_enable_device in ne2kpci   (Dave Jones)

2.4.1-ac4
o   Fix sk_in use counting in svcsock.c (Neil Brown)
| Not yet a complete and final agreed solution
o   Add support for KLSI USB ethernet   (Brad Hards,
 Stephane Alnet, 'the Zapman', and co)
o   Update aic7xxx driver   (Doug Ledford)
| Please test this carefully and cc reports to Doug
o   Add help for CONFIG_INPUT   (Steven Cole)
o   3c523 driver update (Tom Sightler)
o   Fix reiserfs Changes entry further  (Steven Cole)
o   Limit ide scatter gather to 128 blocks  (Jens Axboe)
o   Merge hppa config.in changes(Matthew Wilcox)
o   Fix tx timeout recovery on via rhine(Manfred Spraul)
o   Fix stale comments in fs/block_dev.c(Tigran Aivazian)
o   Further defxx driver work   (Maciej Rozycki)
o   winbond 840 reported wrong setting value(Maciej Rozycki)
o   Guillemot Maxi radio support(Dimitromanolakis Apostolos)
o   Allow sleeping in pm callbacks but with locking (me)
working

2.4.1-ac3
o   Remove ancient d

question regarding OOPS in 2.2.16

[Carlo Pagano]

Hi,

I was trying out a modem on RedHat 7 running kernel 2.2.16 and when trying
to upload a file via ftp I get an OOPS. 
I am using pppd version 2.4.0 on a Pentium III 450 with 128MB of RAM.

Here is the output of kysymoops:

[root@cpagano_redhat7 cpagano]# ksymoops oops.feb8.txt -m /boot/System.map
ksymoops 2.3.4 on i686 2.2.16-22.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.16-22/ (default)
 -m /boot/System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 0018   ebx: c0234000   ecx: 03fd   edx: c76ee000
esi:    edi: 0d95   ebp: c0235ce4   esp: c0235cd0
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=c0235000)
Stack: c7ff62ad 0d95 c883c20a c622b780 c7ff6000 c7235900 c8867ac3
c7ff6000
   00d9 0001 c7ff6000 0075 c883be97 c6522000 
c7ff62ad
   0064 c7ff6000 c6754800 c622b780 c883bdb4 c7ff6000 0021
c883e023
Call Trace: [] [] [] [] []
[] []
   [] [] [] [] []
[] [] [] [] []
[] [] [] [] []
[] []
Code: c7 05 00 00 00 00 00 00 00 00 8d 65 e8 5b 5e 5f 89 ec 5d c3

>>EIP; c01114d2<=
Trace; c883c20a <[ppp]ppp_async_encode+2c2/304>
Trace; c8867ac3 <[nls_cp437].data.end+1c6c/6e1a9>
Trace; c883be97 <[ppp]ppp_tty_push+d3/184>
Trace; c883bdb4 <[ppp]ppp_async_send+70/80>
Trace; c883e023 <[ppp]ppp_send_frame+257/280>
Code;  c01114d2 
 <_EIP>:
Code;  c01114d2<=
   0:   c7 05 00 00 00 00 00  movl   $0x0,0x0   <=
Code;  c01114d9 
   7:   00 00 00 
Code;  c01114dc 
   a:   8d 65 e8  lea0xffe8(%ebp),%esp
Code;  c01114df 
   d:   5bpop%ebx
Code;  c01114e0 
   e:   5epop%esi
Code;  c01114e1 
   f:   5fpop%edi
Code;  c01114e2 
  10:   89 ec mov%ebp,%esp
Code;  c01114e4 
  12:   5dpop%ebp
Code;  c01114e5 
  13:   c3ret

Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
In swapper task - not syncing


Thanks in advance,

Carlo Pagano
-
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] Re: 2.4.x, drm, g400 and pci_set_master

[Alan Olsen]

On Thu, 8 Feb 2001, Petr Vandrovec wrote:

> On  8 Feb 01 at 13:14, Alex Deucher wrote:
> > Jeff Hartmann wrote:
> > > Petr Vandrovec wrote:
> 
> > > It does not use dynamic DMA mapping, because it doesn't do PCI DMA at
> > > all.  It uses AGP DMA.  Actually, it shouldn't be too hard to get it to
> > > work on the Alpha (just a few 32/64 bit issues probably.)  Someone just
> > > needs to get agpgart working on the Alpha, thats the big step.
> > 
> > That shouldn't be too hard since many (all?) AGP alpha boards (UP1000's
> > anyway) are based on the AMD 751 Northbridge? And there is already
> > support for that in the kernel for x86. 
> 
> My AlphaPC 164LX does not have AGP at all - and I want to get G200/G400 PCI 
> working on it with dri, using 21174 features.

After looking into this a little more I have found it is uglier than that.
The answers I have are not very good.

I assume you are wanting to use this with X.  There is a rather odd driver
issue involved.

There are two X drivers available for the G400. One from Matrox and one in
the version of X that you are using.

The Matrox driver will not work under the 2.4.x kernel for DRM due to a
version conflict.  (It wants version 1.0 and 2.4.x uses version 2.0.)  It
will also not compile with 4.0.2 and above at the present time.

The XFree86 version has some odd problems in Xinerama, but at least it
works.  (Ugly artifact borders on the second screen.)

BUT...

Both drivers want Matrox's HALlib. (Which is x86 binary only.) Matrox will
not release the info on that interface to the chipset.  (Using the
standard corporate excuse whenever they don't want to do something
"Intelectual Property concerns".)

Good luck on getting them to make an Alpha version of the library or get
them to release the underlying library interface specs. 

[EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply
Alan Olsen| to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."

-
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/