Re: re. too long mac address for --mac-source netfilter option

[Darren Tucker]

[EMAIL PROTECTED] wrote:
> Jack  Bowling wrote - 
> >> iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
> >>
> >> to the respective iptable line:
> >>
> >> $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source 
>xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT
> >>
> >> The idea here is to allow VNC access to my home box with the access filtered by 
>both IP and mac address.> 
> Stefan Hanse writes -
> 
> >Umm..  An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6 groups, not 
>14. Is this really an ethernet
> >interface? (If it really has 14 groups).
 
> All hits on my firewall from cable modem servers other than my own provider also 
>have the 14 group "MAC" address so it looks like this may be a feature of these units.

It looks like it's the entire MAC-level header that is logged:
destination, source and protocol type.

I did a quick test with the PPPoE link down and the upstream cable
unplugged. I telnetted into the modem and generated a single UDP packet
to the echo port on the linux box (using the command "ip sendto
addr=10.0.0.1 count=1 size=10 dstport=7").

The kernel logged:
IN=eth1 OUT= MAC=08:00:2b:e2:a6:a3:00:90:d0:1b:4d:1c:08:00
SRC=10.0.0.138 DST=10.0.0.1 LEN=38 TOS=0x00 PREC=0x00 TTL=64 ID=2693
PROTO=UDP SPT=1032 DPT=7 LEN=18

The tcpdump output from this exchange:
[root@gate dtucker]# tcpdump -i eth1 -vv -x -e -p ! port telnet
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth1
13:07:04.105231 < 0:90:d0:1b:4d:1c 0:0:0:0:0:1 ip 60: 10.0.0.138.1041 >
10.0.0.1.echo: udp 10 (ttl 64, id 3335)
 4500 0026 0d07  4011 5936 0a00 008a
 0a00 0001 0411 0007 0012 8cc8 4142 4344
 4546 4748 494a    
13:07:04.105900 > 0:0:0:0:0:0 8:0:2b:e2:a6:a3 ip 80: 10.0.0.1 >
10.0.0.138: icmp: 10.0.0.1 udp port echo unreachable Offending pkt:
10.0.0.138.1041 > 10.0.0.1.echo: udp 10 (ttl 64, id 3335) (DF) [tos
0xc0]  (ttl 255, id 0)
 45c0 0042  4000 ff01 6670 0a00 0001
 0a00 008a 0303 11ab   4500 0026
 0d07  4011 5936 0a00 008a 0a00 0001
 0411 0007 0012 8cc8 4142 4344 4546 4748
 494a

Environment:
Kernel 2.4.2-pre3 running on an AMD K6-3.
eth1 is a DE435 using the de4x5 driver. MAC address 08:00:2B:E2:A6:A3
Alcatel "Speed Touch Home" ADSL modem connected to eth1. MAC address
00:90:D0:1B:4D:1C
The (relevant parts of the) iptables:
iptables -N droplog
iptables -A droplog -j LOG
iptables -A droplog -j REJECT
iptables -A INPUT -i eth1 -m state --state NEW,INVALID -j droplog
iptables -A FORWARD -i eth1 -m state --state NEW,INVALID -j droplog

Further comments:
1) I know that some of the the MAC addresses given by tcpdump are
invalid. Is this a bug? In what?
2) I've also repeated this test with the tulip driver, with the same
results.

-Daz.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this the ultimate stack-smash fix?

[Eric W. Biederman]

Peter Samuelson <[EMAIL PROTECTED]> writes:

>   [Manfred Spraul]
> > > Unless you modify the ABI and pass the array bounds around you won't
> > > catch such problems, 
> 
> [Eric W. Biederman]
> > Of course.  But this is linux and you have the source.  And I did
> > mention you needed to recompile the libraries your trusted
> > applications depended on.
> 
> So by what ABI do you propose to pass array bounds to a called
> function?  It sounds pretty ugly.  

Not especially.  In cases you can't optimize pointers become tuples
of .

> It also sounds like you will be
> breaking the extremely useful C postulate that, at the ABI level at
> least, arrays and pointers are equivalent.  I can't see *how* you plan
> to work around that one.

Huh?  Pointers and arrays are clearly different at the ABI level.

A pointer is a word that contains an address of something.
An array is an array.

There is an implicit promotion from one to the other at the source level,
but that has little to do with the application binary interface.

> > Yep bounds checking is not an easy fix.
> 
> Understatement of the year, if you really want to catch all cases.

No, it's more of a large mechanical job than truly hard problem.
The real challenge lies in optimizing out the checks so you don't penalize
the inner loops of code.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Boot fails in Avanti AS 400 4/233, include boot log and sysrq dump

[Rafael E. Herrera]

Hello,

I compiled both kernel versions 2.4.2-pre4 and 2.4.1-ac18 on my Alpha
Station 400 4/233 and both stop when they are start init. I include the
boot log and sysrq dumps for 2.4.1-ac18, I passed init=/bin/bash as
kernel parameter. I'd appreciate any help.

Thanks.
-- 
 Rafael

Linux version 2.4.1-ac18 (root@alfa) (gcc version 2.95.2 19991024 (release)) #1 Sat 
Feb 17 19:19:561
Booting GENERIC on Avanti using machine vector Avanti from MILO
Command line: bootdevice=sda1 bootfile=2.4 root=/dev/sda3 debug init=/bin/bash 
console=ttyS0,19200n 
memcluster 0, usage 2, start0, end2
memcluster 1, usage 0, start2, end  256
memcluster 2, usage 2, start  256, end  328
memcluster 3, usage 0, start  328, end 2065
memcluster 4, usage 2, start 2065, end 2066
memcluster 5, usage 0, start 2066, end 2068
memcluster 6, usage 2, start 2068, end 2069
memcluster 7, usage 0, start 2069, end16384
freeing pages 2:256
freeing pages 328:384
freeing pages 776:2065
freeing pages 2066:2068
freeing pages 2069:16384
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: bootdevice=sda1 bootfile=2.4 root=/dev/sda3 debug init=/bin/bash 
console=ttyS0 
Using epoch = 1980
Console: colour VGA+ 80x25
Calibrating delay loop... 460.92 BogoMIPS
Memory: 125112k/131072k available (1764k kernel code, 5352k reserved, 524k data, 368k 
init)
Dentry-cache hash table entries: 16384 (order: 5, 262144 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 65536 bytes)
Page-cache hash table entries: 16384 (order: 4, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 131072 bytes)
POSIX conformance testing by UNIFIX
  got res[8000:80ff] for resource 0 of Symbios Logic Inc. (formerly NCR) 53c810
  got res[8400:84ff] for resource 0 of Realtek Semiconductor Co., Ltd. RTL-8139
  got res[280:2ff] for resource 1 of Matrox Graphics, Inc. MGA 2064W 
[Millennium]
  got res[220:220] for resource 6 of Matrox Graphics, Inc. MGA 2064W 
[Millennium]
  got res[221:2213fff] for resource 0 of Matrox Graphics, Inc. MGA 2064W 
[Millennium]
  got res[2214000:22140ff] for resource 1 of Symbios Logic Inc. (formerly NCR) 53c810
  got res[2215000:22150ff] for resource 1 of Realtek Semiconductor Co., Ltd. RTL-8139
PCI enable device: (Symbios Logic Inc. (formerly NCR) 53c810)
  cmd reg 0x47
PCI enable device: (Intel Corporation 82378IB [SIO ISA Bridge])
  cmd reg 0x7
PCI enable device: (Matrox Graphics, Inc. MGA 2064W [Millennium])
  cmd reg 0x87
PCI enable device: (Realtek Semiconductor Co., Ltd. RTL-8139)
  cmd reg 0x147
isapnp: Scanning for Pnp cards...
isapnp: Card 'ESS ES1869 Plug and Play AudioDrive'
isapnp: 1 Plug & Play card detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 82858kB/27619kB, 256 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Floppy drive(s): fd0 is 2.88M
FDC 0 is a National Semiconductor PC87306
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP 
enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
rtc: ARC console epoch (1980) detected
Real Time Clock Driver v1.10d
SCSI subsystem driver Revision: 1.00
ncr53c8xx: at PCI bus 0, device 6, function 0
ncr53c8xx: 53c810 detected 
ncr53c810-0: rev 0x1 on pci bus 0 device 6 function 0 irq 11
ncr53c810-0: ID 7, Fast-10, Parity Checking
ncr53c810-0: restart (scsi reset).
scsi0 : ncr53c8xx - version 3.3b
ncr53c810-0-<0,0>: wide msgin: 1-2-3-1.
ncr53c810-0-<0,0>: wide: wide=0 chg=1.
ncr53c810-0-<0,0>: wide msgout: 8.
ncr53c810-0-<0,0>: sync msgin: 1-3-1-19-1e.
ncr53c810-0-<0,0>: sync: per=25 scntl3=0x10 ofs=8 fak=0 chg=1.
ncr53c810-0-<0,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 8)
ncr53c810-0-<0,0>: sync msgout: 1-3-1-19-8.
  Vendor: TANDEMModel: 4255-1Rev: 1011
  Type:   Direct-Access  ANSI SCSI revision: 02
  Vendor: NEC   Model: CD-ROM DRIVE:461  Rev: 2.3d
  Type:   CD-ROM ANSI SCSI revision: 02
ncr53c810-0-<0,0>: tagged command queue depth set to 8
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 4404489 512-byte hdwr sectors (2255 MB)
Partition check:
 sda: sda1 sda2 sda3
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0
ncr53c810-0-<4,0>: sync_msgout: 1-3-1-19-8.
ncr53c810-0-<4,0>: sync msgin: 1-3-1-1f-8.
ncr53c810-0-<4,0>: sync: per=31 scntl3=0x10 ofs=8 fak=1 chg=0.
ncr53c810-0-<4,*>: FAST-10 SCSI 8.0 MB/s (125 ns, offset 8)
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 16Kbytes
TCP: Hash tables configured (established 8192 bind 8192)

Re: 2.4.1 crashing every other day

[Mordechai Ovits]

On Sun, Feb 18, 2001 at 02:46:30AM +0100, Andre Tomt wrote:
> Very recently I installed a new mailserver for my company, based around
> qmail, linux 2.4.1, and software raid 1.
> It works very nicely untill it spews out oops's after a few days, leaving
> hundreds of qmail-popup processes hanging, unkillable. THe server is very
> lightly loaded for now, doing only a few hundreds smtp + pop's a day.
> 
> It's a Pentium III 733 based system, with 256MB RAM (one stick, we have
> already tried another stick), and every partition except swap on software
> RAID 1. Both IDE disks (IBM-DTLA-307030, 30GB each) are connected to a HPT
> ATA100 IDE controller (see the lscpi-output). I've attached some info, and
> one decoded oops. Longer down you'll find info from lspci and the like.
> 
> As a side note, we have one other _identical_ hardware setup, running the
> same kernel, same base software, same partitioning, same RAID setup, just as
> a webserver. And it works geat, no hickups whatsoever. Also, the oops's
> seems to happen only with qmail-popup, at least thats how the few crashes I
> had the chance to investigate did.
> 

Looks like you were bitten by either the RAID 1 bugs or the elevator bugs.
Try a 2.4.2-pre4 or an 2.4.1-ac18 kernel.  Should solve it.

Mordy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.1ac17 hang on mounting loopback fs

[Pete Toscano]

Excellent!  Thanks, that worked.

pete

On Sat, 17 Feb 2001, Thomas Molina wrote:

> On Sat, 17 Feb 2001, Pete Toscano wrote:
> 
> > reading this, I see now why mkbootdisk was locking in the D state with
> > the loop mounted... Would this also explain not being able to seek
> > forward while writing a floppy?
> >
> > I was trying to make the GRUB boot disk by writing the stage 1 and 2
> > loaders to the floppy (as per the GRUB docs) with dd:
> >
> > [root@bubba grub]# dd of=/dev/fd0 if=stage1 bs=512 count=1
> > 1+0 records in
> > 1+0 records out
> > [root@bubba grub]# dd of=/dev/fd0 if=stage2 bs=512 seek=1
> > dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied
> 
> Different problem.  Add conv=notrunc to the dd command to make it work.
> 

 PGP signature

Re: Linux stifles innovation...

[Ben Ford]

> 
> On the other hand, they make excellent mice.  The mouse wheel and
> the new optical mice are truly innovative and Microsoft should be
> commended for them. 
> 
The wheel was a nifty idea, but I've seen workstations 15 years old with 
optical mice.  It wasn't MS's idea.

-b

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Asus CUV4X-D mobo

[David D.W. Downey]

On Sat, 17 Feb 2001, Mark Hahn wrote:

> the 0-4 drives attached to the primary controller are fundamentally
> different in behavior than any other controller's drives.
>

Wait, when I first started in computers I found that by using the CHS
count on the drive made the drives work correctly due to the fact that
those day BIOSes didn't understand how to do LBA or any enhianced modes.
You HAD to specify the CHS count. Then, hard drives and mobo BIOSes
improved to the point that the motherboards would check a chip on the
drive telling it what the geometry was for that drive. this allowed the
BIOS to configure the system. All *I*'ve been doing is simply stating the
straight CHS counts manually in the BIOS. I've also played with toggling
the LBA mode on and off.

The problem is that the 686B controller reads the chip as reading
1024x16x63+LBA to equal 30GB for the drive. This is clearly not the right
count. So, I booted to a rescue disk and ran hdparm against the drive to
see what the drive itself is saying the setting is.

This is my first clue that the mobo is not reading the drive correctly, since the 
drive shows
RawCHS as being 16383x16x63+LBA. (RawCHS being the field in hdparm's
output I understand to be what the drive is truly reporting)  So, I then
ran fdisk to see what IT was seeing for the cylinder count which I believe it
gets by taking the reported CHS, does the LBA magic itself then displays what
it came up with for it's translation. fdisk reported 58168x16x63.
Obviously 2 of the translations are incorrect. 16383x16x63 is obviously
not the right one. Booting with that geometry fails to find the
partition.

That leaves 1024x16x63 which just doesn't add up to the max of the
drive. Looking on the drive you see a sector count that matches what fdisk
reads the drive to be. No CHS count just the total sector count of the
drive and LBA. (Most hard drives usually have the CHS written
on them so it's easy to throw them back in. This drive doesn't have a CHS count
on it. That's what made this difficult.)

Now the controller can see the drive correctly and all partitions are
accessible. BUT ONLY if i boot from a CD. Not because of the kernel, but
because no matter what, LILO will NOT load correctly to reboot back into linux.
I consistently get LI (stage 2 loader) problems. Now, dig this, switch
these drives just as they are to the Promise controller (which reads the
drives the same way as fdisk does AND the LI problems completely
disappear.

Now, you COULD make the argument that since my motherboard has the option
to match translations to the partition table that THAT should have worked
and allowed access to the drive. (It's a feature of this particular
board and is an actual menu options.) This of course is NOT the case.
Setting it this way did not fix the problem. At this point, I've manually
stated the drive is 58383x16x63 in the BIOS, toggled LBA both on and off,
told it to match the translation to that reported by the partition table,
and nothing got it to boot from LILO.

I decided to wipe the drive leaving NO partitions and see what happened
when I torched the drives.

So i cold booted with no partition table on the drive, ran fdisk /MBR
from windows against the MBR to make sure LILO was compeltely gone,
rebooted the system with the drives unplugged from the mobo and the bios
set to NONE for drives.

Then I reattached the drives, booted up, manualy specied the CHS+LBA only,
saved bios, rebooted, and ran through a Linux install. (Completely
different distrib as well.) Once again I got the LI errors again. It would
always blow right at the point that it looks at the drive for the raw
starting sector for the kernel. (2nd stage loader)

Now, enter back in the Promise PDC20267 controller. I went back into the
BIOS, disabled the onboard controllers, rebooted again and ran the install
from the Promise. I ran all the way through the entire steps again with
the Promise. First I tried it leaving the partiton table just the way it
was on the other controller, rebooted back from the install CD to the
drive and reran LILO just as it was on the drive. Rebooted the system and
this time around I get a working LILO prompt.

I decided to do the 2nd half of the test by removing the partitions,
rebooting, removing the drives from the controller, rebooting so it
doesn't have a memory of the drives, re-attaching the drives,
repartitioning the now-blank drives and reinstalling linux. Again LILO
works flawlessly the first time.

To me, this says the mobo's controller or it's chipset are bad. Since I've
had numerous problems with the VIA chipset in the past, even from years
ago, I'm more willing to believe that the 686B is a screwy chip.


BTW, marking a drive and cables is nothing more than marking them 1/2 for
primary master/slave and 3/4 for 2ndary master/slave. I also record the
geometry of the drive somwhere on the side or a peice of paper within the
machine itself so I don't have to mess with yankin drives and such. I

Re: [LONG RANT] Re: Linux stifles innovation...

[Ben Ford]

Jacob Luna Lundberg wrote:

>> Speaking as a Linux _USER_, if this happens, can I get said print
>> engine working on my ARM machines with these closed source drivers?
>> Can Alpha users get this print system working?  Can Sparc uses
>> get it working?  What?  I can't?  They can't?  Well, its no good to
>> me nor them.  You've just made the system x86 specific.  Well done,
>> thats a step backwards, not forwards.
> 
> 
> Just out of curiosity, why can't the specification be along the lines of a
> vendor data file saying ``if you want the printer to do x then say y'' and
> ``if the printer says x then it means y''.  That ought to add a lot of
> functionality right there.  Sure there are evil winprinters that this
> wouldn't be enough for but it would be hardware independant, yes?

isn't that what windows *.INF files do?
(don't flame me  I'm not sure about it)

-b

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Linux stifles innovation...

[Torrey Hoffman]

Dennis wrote:
>At 07:01 PM 02/16/2001, Alan Olsen wrote:
>>On Fri, 16 Feb 2001, Dennis wrote:
>>
>> > There is much truth to the concept, although Microsoft should not be
ones
>> > to comment on it as such.
>>
>>What truth?  I have seen more "innovation" in the Open Source movement
>>than I ever have in my 18+ years of being a professional programmer.
>You are confusing "progress" with "innovation". If there is only 1 choice, 
>thats not innovation. Expanding on a bad idea, or even a good one, is not 
>innovation.
>
>Designing something differently to make it better is innovation.  I suppose

>you could argue that redesigning linux every few  years is innovation, but 
>unfortunately its the same cast of characters doing it, so its not very 
>innovative.

Reality check:

1.  The Open Source / Free Software communities have produced 
more innovative software in the last 4 years than Microsoft 
has in the same time, despite Microsoft's _vast_ advantages 
in money, manpower, and hardware manufacturer relationships.

2.  Where Microsoft is "innovating", those changes are usually
intended to lock the customer in to Microsoft's products,
and are not in the best interests of their own customers.

3.  Far from Open Source being a threat to innovation, it is 
actually Microsoft that stifles innovation.  Also, Free 
software helps the developers who use it to do innovative
things, while Microsoft has endless restrictions.

What has Microsoft done since 1996?  Good and bad?
What has Free Software done in the same time?  

Most of Microsoft's best ideas were more than 5 years ago, and
since then they've mostly been integrating and marketing.  
They have done a few interesting things, but not nearly as much 
as they could have.

Some things to consider, in no particular order:

- Innovative new hardware devices are more likely to be based on
Linux than any Microsoft OS. For example, the TiVO, the coolest 
improvement to television since the VCR.

- ECN, IPv6, other RFC-standard improvements standard protocols
- File systems: cramfs, reiserfs, Tux2, ext3, etc.
- MS' new C# language. Java. Kaffe. Perl. Ruby. Python.
- Cross platform support from System 390 to iPaq
- Ogg Vorbis
- Beowulf vs. that pathetic Microsoft beowulf-wanna-be.
- Microsoft's "innovative" extensions to Kerebos.
- Software for building community web sites, like Slashdot, 
Freshmeat, SourceForge, etc.
- Mozilla
- Integrating Internet Explorer into Windows.
- RTLinux (does Microsoft have a hard real-time OS? Why not?)
- Embedded Linux vs. Windows CE
- Gnome and KDE user interfaces - works in progress, but lots
of innovation there.
- Gimp. Apache.
- PHP, ModPerl, etc. vs ASP.
- Jabber XML messaging platform
- Handwriting recognition.  MS has an edge here.
- Scanner software APIs: TWAIN vs. SANE. 
- Direct3D vs OpenGL
- XML-based, open file formats vs. proprietary file formats
- Windows Update vs. apt-get, rpmfind, etc.
- OpenSSH vs.  ummm... BackOrfice?
- IP over Firewire and other crazy, cool ideas
- OpenBSD and line-by-line code audits.
- .NET
- Innovative new ways to spread viral documents and mail
- In-kernel web server/accelerator, fastest in the world

Don't forget Microsoft's latest innovation: integrating copy 
protection for music into the upcoming Windows XP OS, preventing 
people from fully controlling their own computer hardware. Feh.

On the other hand, they make excellent mice.  The mouse wheel and
the new optical mice are truly innovative and Microsoft should be
commended for them. 

Yours truly,

Torrey Hoffman 
- a relative nobody in the world of free software. But I use it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.1ac17 hang on mounting loopback fs

[Thomas Molina]

On Sat, 17 Feb 2001, Pete Toscano wrote:

> reading this, I see now why mkbootdisk was locking in the D state with
> the loop mounted... Would this also explain not being able to seek
> forward while writing a floppy?
>
> I was trying to make the GRUB boot disk by writing the stage 1 and 2
> loaders to the floppy (as per the GRUB docs) with dd:
>
> [root@bubba grub]# dd of=/dev/fd0 if=stage1 bs=512 count=1
> 1+0 records in
> 1+0 records out
> [root@bubba grub]# dd of=/dev/fd0 if=stage2 bs=512 seek=1
> dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied

Different problem.  Add conv=notrunc to the dd command to make it work.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile

[David]

> Well, I run glibc-2.2.1 as well, so that might be one of the factors
> contributing to this. Then again, glibc-2.2.1 with ext2 does not cause any
> problems whatsoever with mozilla. So it could be that reiserfs + glibc-2.2.1 is
> a bad combination, question remains which of these two is the culprit (if not
> both). Since glibc-2.2.2 is out, I will give that a try as well. Not tonight
> though...
> 
> And no, I'm not running RedHat 7.x for those who might think so (and
> automatically blame everything on it).
> 
> When did you switch to glibc-2.2.1? Were you running reiserfs before that?
> 
> Cheers//Frank


Yes I was running reiserfs before 2.2.1 and I switched to 2.2.1 a couple 
months ago.  Since then I've been dealing with issues.  I've had to 
recompile half a dozen things similar to sendmail, apache etc.  They 
segfaulted.  It wasn't as purely backward compatible as expected.

I typically compile everything on one machine and distribute it.  Thus 
far everything has been ok save a few issues I haven't been able to pin 
down.  One of these issues is the inability to compile mozilla.  Also 
related, I can't recompile gcc 2.95.2.

All of these things I was able to do just fine before the changeover.  
To note, I used to cvs up mozilla and recompile it every few days.  I 
suppose I'll build an ext2 system and try things out.

Oh btw, I don't run That distribution either.

-d

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Serverworks HE quad Xeon: strange network lockups

[Emil Briggs]

We just got a SuperMicro S2QE6 which is a quad
Xeon motherboard using the Serverworks HE chipset.
It has onboard ethernet (Intel 82559). After installing
Redhat 6.2 the Ethernet stopped working with the
message "eth0: card reports no resources"

>From what I have seen there is nothing that unusual
with this and the 82559. What is strange is that the
network starts working again if you type something on
the keyboard. This is 100% repeatable -- don't type
on the keyboard and the ethernet freezes up with the no
resources message in a few minutes. Touch the keyboard
and it starts working again immediately.

I'm going to update the kernel and see if that fixes the
issue but it struck me as a rather unusual problem.

Regards
Emil Briggs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Linux stifles innovation...

[Torrey Hoffman]

Henning P. Schmiedehausen wrote:

> ... If you
> write for Windows, you have an ugly and complicated API with lots of
> bugs

Yes, that is true.

> , but the API itself is stable since six (!) years.  You can write
> programs that run on 95/98/ME/NT/2000 unchanged. 

That is not always true, as I learned by painful, repeated experience.

My previous job, and some contract work I have done, involved writing 
software for Windows.  My WORST problems were incompatibilities between 
Windows NT and Windows 95.  The APIs do NOT, I repeat NOT! NOT! NOT! 
work the same on the various Windows flavors, as soon as you start 
doing non-trivial applications.  Three times at least, portability
problems from NT to Win95 cost me sleepless nights.  Debugging stuff
like that is hell when you don't have the source.

And when things break on Win95 where they ran on NT, what do you do,
run a debugger on Win95, where a crash can (and will) bring down the 
whole system?  Ugh, the horror.

Linux is not perfect yet, and there may be incompatibilities between 
library versions. But with the source, I have always been able to 
debug and fix the problems I've run into with much less pain than 
I ever had on Windows.  I'm never going back.

Yours, 

Torrey Hoffman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile

[Frank de Lange]

On Sat, Feb 17, 2001 at 05:47:49PM -0800, David wrote:
> I can say "me too" for this.  I thought it was perhaps glibc or binutils 
> tho.  I only have reiserfs systems now so I don't have a basis for 
> comparison.
> 
> However I -can- say that I didn't experience this until I put glibc 
> 2.2.1 on my systems.  I do use an "approved" gcc, stock 2.95.2.
> 
> I wouldn't be so quick to pin it on reiserfs.

Well, I run glibc-2.2.1 as well, so that might be one of the factors
contributing to this. Then again, glibc-2.2.1 with ext2 does not cause any
problems whatsoever with mozilla. So it could be that reiserfs + glibc-2.2.1 is
a bad combination, question remains which of these two is the culprit (if not
both). Since glibc-2.2.2 is out, I will give that a try as well. Not tonight
though...

And no, I'm not running RedHat 7.x for those who might think so (and
automatically blame everything on it).

When did you switch to glibc-2.2.1? Were you running reiserfs before that?

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: XOR [ was: Linux stifles innovation... ]

[Dan Hollis]

On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote:
> In 1984 I received a demand letter for $10,000 from the above
> referenced company as a unlimited license for use of a that
> patent and another patent.
> At the time I ran a company that made graphics cards for IBM PCs.

Did you ignore it or did you pay up?

FWIW I recall there was prior art dating back to 1974 at the very least...

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Oops in 2.4.1 with apache nfs and netapp

[Krzysztof Adamski]

Here is the setup:
Compaq proliant dual PIII 800 with 1G of memory. Debian potato system with
the 2.4.1 kernel compiled from source (from ftp.kernel.org) SMP enabled.
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 2220 (Debian GNU/Linux)
Server version: Apache/1.3.9 (Unix) Debian/GNU
The NFSv3 client is compiled in the kernel

The /usr and /var are mounted on a Network Appliance F740
website root and apache log files are on a local disk, when they are on
the netapp, the lockup happens much faster.

When doing stress testing of apache (with ab -n 1000 -c 300 -k website/ )
I get lockups, before it lockup here is what gets written to syslog:

Feb 17 19:42:27 clientweb2 kernel: Unable to handle kernel paging request at virtual 
address 68a8
Feb 17 19:42:27 clientweb2 kernel: Unable to handle kernel paging request at virtual 
address 68a8
Feb 17 19:42:27 clientweb2 kernel:  printing eip:
Feb 17 19:42:27 clientweb2 kernel: c0178b18
Feb 17 19:42:27 clientweb2 kernel: *pde = 
Feb 17 19:42:27 clientweb2 kernel: Oops: 
Feb 17 19:42:27 clientweb2 kernel: CPU:1
Feb 17 19:42:27 clientweb2 kernel: EIP:0010:[nlmclnt_block+120/212]
Feb 17 19:42:27 clientweb2 kernel: EFLAGS: 00010203
Feb 17 19:42:27 clientweb2 kernel: eax: 68a8   ebx: e34d7ce0   ecx: e34d7ce0   
edx: 68a8
Feb 17 19:42:27 clientweb2 kernel: esi: e5a7e460   edi:    ebp: e2eaab88   
esp: e34d7cd0
Feb 17 19:42:27 clientweb2 kernel: ds: 0018   es: 0018   ss: 0018
Feb 17 19:42:27 clientweb2 kernel: Process apache (pid: 690, stackpage=e34d7000)
Feb 17 19:42:27 clientweb2 kernel: Stack: e34d7e24 e5a7e460 e2eaab88 e34d7d4c  
<4>0001  printing eip:
Feb 17 19:42:27 clientweb2 kernel: e34d7ce8 e34d7ce8 
Feb 17 19:42:27 clientweb2 kernel:c0178b18
Feb 17 19:42:27 clientweb2 kernel: e5a7e460 <1>*pde = 
Feb 17 19:42:27 clientweb2 kernel: e2eaab88 e34d7d54 0003 c01796b0 e5a7e460 
e2eaab88 e34d7e30 
Feb 17 19:42:27 clientweb2 kernel:e34d7d60 e4f76b76 e34d7da6 e34d7d4c c01790f6 
e34d7d4c e2eaab88 e4f76a20 
Feb 17 19:42:27 clientweb2 kernel: Call Trace: [nlmclnt_lock+100/164] 
[nlmclnt_proc+674/856] [] [nfs_lock+253/368] [fcntl_setlk+275/444] 
[do_fcntl+434/712] [sys_fcntl+42/60] 
Feb 17 19:42:27 clientweb2 kernel:[system_call+51/56] [startup_32+43/203] 
Feb 17 19:42:27 clientweb2 kernel: 
Feb 17 19:42:27 clientweb2 kernel: Code: 8b 02 85 c0 74 0a 39 c8 75 f4 8b 44 24 10 89 
02 b8 00 e0 ff 
Feb 17 19:42:27 clientweb2 kernel: Oops: 
Feb 17 19:42:27 clientweb2 kernel: CPU:0
Feb 17 19:42:27 clientweb2 kernel: EIP:0010:[nlmclnt_block+120/212]
Feb 17 19:42:27 clientweb2 kernel: EFLAGS: 00010203
Feb 17 19:42:27 clientweb2 kernel: eax: 68a8   ebx: e1923ce0   ecx: e1923ce0   
edx: 68a8
Feb 17 19:42:27 clientweb2 kernel: esi: e5a7e460   edi:    ebp: e4b824b4   
esp: e1923cd0
Feb 17 19:42:27 clientweb2 kernel: ds: 0018   es: 0018   ss: 0018
Feb 17 19:42:27 clientweb2 kernel: Process apache (pid: 568, stackpage=e1923000)
Feb 17 19:42:27 clientweb2 kernel: Stack: e1923e24 e5a7e460 e4b824b4 e1923d4c e34d7ce0 
0001 e1923ce8 e1923ce8 
Feb 17 19:42:27 clientweb2 kernel:e5a7e460 e4b824b4 e1923d54 0003 c01796b0 
e5a7e460 e4b824b4 e1923e30 
Feb 17 19:42:27 clientweb2 kernel:e1923d60 e4f76b76 e1923da6 e1923d4c c01790f6 
e1923d4c e4b824b4 e4f76a20 
Feb 17 19:42:27 clientweb2 kernel: Call Trace: [nlmclnt_lock+100/164] 
[nlmclnt_proc+674/856] [] [nfs_lock+253/368] [fcntl_setlk+275/444] 
[do_fcntl+434/712] [sys_fcntl+42/60] 
Feb 17 19:42:27 clientweb2 kernel:[system_call+51/56] [startup_32+43/203] 
Feb 17 19:42:27 clientweb2 kernel: 
Feb 17 19:42:27 clientweb2 kernel: Code: 8b 02 85 c0 74 0a 39 c8 75 f4 8b 44 24 10 89 
02 b8 00 e0 ff 
Feb 17 19:44:57 clientweb2 kernel: Unable to handle kernel paging request at virtual 
address 68ce
Feb 17 19:44:57 clientweb2 kernel:  printing eip:
Feb 17 19:44:57 clientweb2 kernel: c0178b18
Feb 17 19:44:57 clientweb2 kernel: *pde = 
Feb 17 19:44:57 clientweb2 kernel: Oops: 
Feb 17 19:44:57 clientweb2 kernel: CPU:0
Feb 17 19:44:57 clientweb2 kernel: EIP:0010:[nlmclnt_block+120/212]
Feb 17 19:44:57 clientweb2 kernel: EFLAGS: 00010207
Feb 17 19:44:57 clientweb2 kernel: eax: 68ce   ebx: e1cbbce0   ecx: e1cbbce0   
edx: 68ce
Feb 17 19:44:57 clientweb2 kernel: esi: e5a7e460   edi:    ebp: e4b820c0   
esp: e1cbbcd0
Feb 17 19:44:57 clientweb2 kernel: ds: 0018   es: 0018   ss: 0018
Feb 17 19:44:57 clientweb2 kernel: Process apache (pid: 662, stackpage=e1cbb000)
Feb 17 19:44:57 clientweb2 kernel: Stack: e1cbbe24 e5a7e460 e4b820c0 e1cbbd4c e3d01ce0 
0001 e1cbbce8 e1cbbce8 
Feb 17 19:44:57 clientweb2 kernel:e5a7e460 e4b820c0 e1cbbd54 0003 c01796b0 
e5a7e460 e4b820c0 e1cbbe30 
Feb 17 19:44:57 clientweb2 kernel:e1cbbd60 e4f76b76 e1cbbda6 e1cbbd4c c01790f6 
e1cbbd4c e4b820c0 e4f76a20 
Feb 17 19:44:57 clientweb2 kernel: Call Trace: 

Re: [LK] Re: lkml subject line

[Chipzz]

> > If the above procmail filter doesn't work (untested) let me know
> > and I will MAKE it work.  Windows users - tough luck - procmail
> > is open source - hire someone to port it...

This procmail rule has caught all the mail, never slipped even one in the
last year:

:0
* ^Sender: linux-kernel-owner@.*\.kernel\.org
linux-kernel

Chipzz AKA
Jan Van Buggenhout
-- 

--
  UNIX isn't dead - It just smells funny
[EMAIL PROTECTED]
--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SO_SNDTIMEO: 2.4 kernel bugs

[Chris Evans]

Hi,

By the way - I tested SO_RCVLOWAT, another 2.4 addition. Good news this
time - seems to work fine.

Cheers
Chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile

[David]

I can say "me too" for this.  I thought it was perhaps glibc or binutils 
tho.  I only have reiserfs systems now so I don't have a basis for 
comparison.

However I -can- say that I didn't experience this until I put glibc 
2.2.1 on my systems.  I do use an "approved" gcc, stock 2.95.2.

I wouldn't be so quick to pin it on reiserfs.

-d


Chris Mason wrote:

> 
> On Saturday, February 17, 2001 05:21:18 PM +0100 Frank de Lange
> <[EMAIL PROTECTED]> wrote:
> 
>> Hi'all,
>> 
>> Well, subject says it all... When I try to compile mozilla (CVS version)
>> with the '--enable-elf-dynstr-gc' option, the compile fails with a
>> segfault:
>> 
>> ../../dist/bin/elf-dynstr-gc ../../dist/lib/components/libsample.so
>> make[2]: *** [install] Segmentation fault (core dumped)
>> 
> 
> That's not good.  Which compiler did you use to compile the kernel?  This
> sounds lame, but reiserfs exercises the cpu/mem more than ext2, so we hit
> bad ram more often.  If we run out of other things to try, please run a
> memory tester.
> 
>> compiling the same codebase on an ext2 filesystem does not produce this
>> segfault. When I compare the produced library (libsample.so), there is a
>> consistent difference between the one compile on the reiserfs and the ext2
>> filesystem. Running objdump on the reiserfs-compiled library also produces
>> errors (some assertion failures, a lot of 'invalid string offset' errors,
>> and finally a 'Memory exhausted' error), while objdump happily
>> disassebles the ext-produced binary.
>> 
> 
> Where in the libsample.so file are the differences (what byte offset?).
> Are they restricted to a given range, or do they vary randomly?
> 
>> These problems occur on:
>> 
>>  2.4.1
>>  2.4.2-pre4
>>  2.4.2-pre4 with Chris Mason's 'reiserfs fix for null bytes in small
>>  files'
>> 
> At least the patch didn't make it worse.  Would anyone care to comment on
> how the elf-dynstr-gc option changes the file access patterns for the
> compile?
> 
> thanks,
> Chris
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] a more efficient BUG() macro

[Keith Owens]

On Sun, 18 Feb 2001 12:33:35 +1100, 
Andrew Morton <[EMAIL PROTECTED]> wrote:
>__BASE_FILE__ does this.  It expands to the thing which you
>typed on the `gcc' command line.
>
>bix:/home/morton> ./a.out
>3 at a.c
>3 at a.c

But __LINE__ is wrong.  Forget what I said about __C_FILE__ and
__C_LINE__, __C_LINE__ would not work for inline functions.  Looks like
the best option is a combination of __BASE_FILE__ and function name.

a.h
#define BUG() \
  printf("kernel BUG in func %s, file %s\n",__FUNCTION__,__BASE_FILE__);

static inline void hello(void)
{
  BUG();
}

a.c
#include 
#include 

int main()
{
hello();
hello();
return 0;
}

# gcc -I`pwd` `pwd`/a.c -o a
# ./a
kernel BUG in func hello, file /home/kaos/a.c
kernel BUG in func hello, file /home/kaos/a.c

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.1 crashing every other day

[Andre Tomt]

Very recently I installed a new mailserver for my company, based around
qmail, linux 2.4.1, and software raid 1.
It works very nicely untill it spews out oops's after a few days, leaving
hundreds of qmail-popup processes hanging, unkillable. THe server is very
lightly loaded for now, doing only a few hundreds smtp + pop's a day.

It's a Pentium III 733 based system, with 256MB RAM (one stick, we have
already tried another stick), and every partition except swap on software
RAID 1. Both IDE disks (IBM-DTLA-307030, 30GB each) are connected to a HPT
ATA100 IDE controller (see the lscpi-output). I've attached some info, and
one decoded oops. Longer down you'll find info from lspci and the like.

As a side note, we have one other _identical_ hardware setup, running the
same kernel, same base software, same partitioning, same RAID setup, just as
a webserver. And it works geat, no hickups whatsoever. Also, the oops's
seems to happen only with qmail-popup, at least thats how the few crashes I
had the chance to investigate did.


Output from ksymops (yes, it's ksymops-2.4.0):

root@mail:~/ksymoops-2.4.0# ./ksymoops -m /boot/System.map < input
ksymoops 2.3.7 on i686 2.4.1.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.1/ (default)
 -m /boot/System.map (specified)

kernel BUG at page_alloc.c:203!
invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010292
eax: 0020   ebx: c1419da8   ecx: cf343f00   edx: 0008
esi: 0002   edi: c0201558   ebp: 0001   esp: c1863ef8
ds: 0018   es: 0018   ss: 0018
Process qmail-popup (pid: 6795, stackpage=c1863000)
Stack: c01d4145 c01d42d3 00cb c0201558 c0201758 0007 c1863fbc
c020158c
   e706 e706 0286 0001 c0201558 c012a8bb c1862000
c1863f94
   c1862000 c1863fbc 0001 c1963840 0007  c0201754
c012aad4
Call Trace: [] [] [] [] []
Code: 0f 0b 83 c4 0c 90 89 d8 eb 14 45 83 c6 0c 83 fd 09 0f 86 db

>>EIP; c012a6f2<=
Trace; c012a8bb <__alloc_pages+eb/2f0>
Trace; c012aad4 <__get_free_pages+14/20>
Trace; c0114480 
Trace; c01077dc 
Trace; c0108dc3 
Code;  c012a6f2 
 <_EIP>:
Code;  c012a6f2<=
   0:   0f 0b ud2a  <=
Code;  c012a6f4 
   2:   83 c4 0c  addl   $0xc,%esp
Code;  c012a6f7 
   5:   90nop
Code;  c012a6f8 
   6:   89 d8 movl   %ebx,%eax
Code;  c012a6fa 
   8:   eb 14 jmp1e <_EIP+0x1e> c012a710

Code;  c012a6fc 
   a:   45incl   %ebp
Code;  c012a6fd 
   b:   83 c6 0c  addl   $0xc,%esi
Code;  c012a700 
   e:   83 fd 09  cmpl   $0x9,%ebp
Code;  c012a703 
  11:   0f 86 db 00 00 00 jbef2 <_EIP+0xf2> c012a7e4
<__alloc_pages+14/2f0>


lspci:
--
root@mail:~/ksymoops-2.4.0# lspci -vvv
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- 

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- Reset- FastB2B+

00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR-  [disabled] [size=64K]

00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 03)
Subsystem: Triones Technologies, Inc.: Unknown device 0001
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR-  [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 15)
(prog-if 00 [VGA])
Subsystem: CardExpert Technology: Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-  [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Re: [PATCH] a more efficient BUG() macro

[Andrew Morton]

"J . A . Magallon" wrote:
> 
> On 02.18 Andrew Morton wrote:
> >
> > __BASE_FILE__ does this.  It expands to the thing which you
> > typed on the `gcc' command line.
> >
> ..
> > 3 at a.c
> > 3 at a.c
> 
> I also thought that, but look at the line numbers...wrong and repeated.

Sure.  There's no __BASE_LINE__.

I don't think providing file-n-line in BUG() provides much utility. Just
remove it.  Replace it with "please feed the following into ksymoops".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] a more efficient BUG() macro

[J . A . Magallon]

On 02.18 Andrew Morton wrote:
> 
> __BASE_FILE__ does this.  It expands to the thing which you
> typed on the `gcc' command line.
> 
..
> 3 at a.c
> 3 at a.c

I also thought that, but look at the line numbers...wrong and repeated.

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac17 #1 SMP Sat Feb 17 01:47:56 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] a more efficient BUG() macro

[Andrew Morton]

Keith Owens wrote:
> 
> But 
> 
> a.h
> static inline void hello(void) { printf("%d at %s\n",__LINE__,__FILE__); }
> 
> a.c
> #include 
> #include "a.h"
> 
> int main()
> {
> hello();
> hello();
> return 0;
> }
> 
> # ./a
> 1 at a.h
> 1 at a.h
> 

__BASE_FILE__ does this.  It expands to the thing which you
typed on the `gcc' command line.

bix:/home/morton> cat a.h
static inline void hello(void)
{
printf("%d at %s\n",__LINE__,__BASE_FILE__);
}
bix:/home/morton> cat a.c
#include 
#include "a.h"

int main()
{
hello();
hello();
return 0;
}

bix:/home/morton> gcc -O a.c
bix:/home/morton> ./a.out
3 at a.c
3 at a.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile

[Frank de Lange]

On Sun, Feb 18, 2001 at 01:57:15AM +0100, Frank de Lange wrote:
> I will retry this with 'all warnings and bells and whistles' turned on in
> reiserfs (on 2.4.1-ac18), and see if anything out of the ordinary is logged. I
> somehow doubt it, since repeated forced reiserfsck's have turned up nothing at
> all...

I just ran the compile again on the described build, same results, no warnings
of any kind, nothing in the debug log facility, nothing on the console...

Reiserfs seems to believe it did the right thing. I'm here to tell you that it
didn't...

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile

[Frank de Lange]

>  At least the patch didn't make it worse. Would anyone care to comment on
>  how the elf-dynstr-gc option changes the file access patterns for the
>  compile?

It does not change the file access patterns, it adds an extra step. A separate
binary (dist/bin/elf-dynstr-gc, a convoluted version of strip) is run over the
final (linked) library/executable to remove some symbol info. The elf-dynstr-gc
program is compiled as part of the mozilla build. There's nothing wrong with
elf-dynstr-gc on the reiserfs filesystem, it is identical to the one on the
ext2 partition. Running the 'reiserfs' version on the ext2 tree works as it
should, running the ext2 version on the reiserfs tree crashes (seems the
program is not very robust, as it does not detect garbled input files). As
said, running objdump on the corrupted (reiserfs compiled) library also
produces errors.

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LONG RANT] Re: Linux stifles innovation...

[Peter Samuelson]

[Jacob Luna Lundberg]
> Just out of curiosity, why can't the specification be along the lines
> of a vendor data file saying ``if you want the printer to do x then
> say y'' and ``if the printer says x then it means y''.  That ought to
> add a lot of functionality right there.

Think about it.  A spec based on what you say would be quite easy to
reverse-compile, no?  In which case, obviously the company's IP, such
as it is, is not protected.  In which case, why not just do an open
source driver and be done with it?

The concept of architecture-independent device drivers goes back to
Open Firmware.  But in that case, there is a practical consideration:
the drivers couldn't be compiled down to machine language since they
had to be accessible as-is at boot time.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile

[Frank de Lange]

> That's not good. Which compiler did you use to compile the kernel? This
> sounds lame, but reiserfs exercises the cpu/mem more than ext2, so we hit
> bad ram more often. If we run out of other things to try, please run a
> memory tester.

I use 'good old' gcc 2.95.2:

gcc -v: gcc version 2.95.2 19991024 (release)

I just tried 2.4.1-ac18, which also gave me the same segfault. When I compare
the corrupted binary (the one compile on reiserfs) to the working one (compiled
on ext2), I notice that at position 0x1000 in the file, a block of data from
position 0x0e60 is duplicated. It seems to be inserted into the data stream, as
it is followed by data which (in the working version of libsample.so) starts at
0x1000:

(bsdiff (binary sdiff) between both files)

(actually the differences between both files start much earlier, but that seems
to be just all kinds of changed relocation information as a result of the error)

(hope my careful ASCII-formatting makes it through the list and the archives)

THE BAD THE GOOD



e60  c4 20 83 c4 f4 8b 06   e60  c4 20 83 c4 f4 8b 06 
e68  8b 40 10 ff d0 eb 06   e68  8b 40 10 ff d0 eb 06 
e70  bf 0e 00 07 80 89 f8   e70  bf 0e 00 07 80 89 f8 
e78  65 e8 5b 5e 5f 89 ec   e78  65 e8 5b 5e 5f 89 ec 
e80  c3 8d 76 00 55 89 e5   e80  c3 8d 76 00 55 89 e5 
e88  c0 89 ec 5d c3 8d 76   e88  c0 89 ec 5d c3 8d 76 
e90  55 89 e5 31 c0 89 ec   e90  55 89 e5 31 c0 89 ec 



fd8  00 00 00 00 c0 00 00   fd8  00 00 00 00 c0 00 00 
fe0  00 00 00 46 80 a0 c0   fe0  00 00 00 46 80 a0 c0 
fe8  68 08 d3 11 91 5f d9   fe8  68 08 d3 11 91 5f d9 
ff0  89 d4 8e 3c 40 92 89   ff0  89 d4 8e 3c 40 92 89 
ff8  d2 f9 d2 11 bd d6 00   ff8  d2 f9 d2 11 bd d6 00 

LOOK HERE: IDENTICAL TO THE AND THIS IS WHAT IT SHOULD
DATA AT e60 LOOK LIKE...

0001000  c4 20 83 c4 f4 8b 06 | 0001000  64 65 73 74 86 52 38 
0001008  8b 40 10 ff d0 eb 06 | 0001008  c4 cb d2 11 8c ca 00 
0001010  bf 0e 00 07 80 89 f8 | 0001010  b0 fc 14 a3 a0 58 f1 
0001018  65 e8 5b 5e 5f 89 ec | 0001018  dd ca d2 11 8c ca 00 



0001190  89 d4 8e 3c 40 92 89 <
0001198  d2 f9 d2 11 bd d6 00 <

AND HERE THE 'GOOD' DATA STARTS
AGAIN, THIS BLOCK IS IDENTICAL TO
THE ONE AT 0x1000 IN THE 'GOOD' FILE

00011a0  64 65 73 74 86 52 38 <
00011a8  c4 cb d2 11 8c ca 00 <
00011b0  b0 fc 14 a3 a0 58 f1 <
00011b8  dd ca d2 11 8c ca 00 <
00011c0  b0 fc 14 a3 40 a7 58 <
00011c8  dc d5 d2 11 92 fb 00 <



So, it seems a wrong block of data was inserted into the stream at position
0x1000, wreaking havoc on the file structure. Now 0x1000 is kind of a magic
number, isn't it? Alsmost to good to be true...

I will retry this with 'all warnings and bells and whistles' turned on in
reiserfs (on 2.4.1-ac18), and see if anything out of the ordinary is logged. I
somehow doubt it, since repeated forced reiserfsck's have turned up nothing at
all...

Oh, and both my own and my computer's memory is OK, so this is not a hardware
fault... :-)

By the way, /tmp (where most action is taking place when compiling) is hosted
on a good ext2 filesystem. Just in case you wondered...

And, also of interest, I'm using an SMP box (BP6, 2 non overclocked Celeron
466s)

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SMP: bind process to cpu

[Andrew Morton]

Thomas Widmann wrote:
> ...
> * Andrew Morton wrote:
> 
> >   http://www.uow.edu.au/~andrewm/linux/#cpus_allowed
> >
> > You just write a bitmask into it.
> 
> Thanks for this information. I patched my the kernel with it.
> After rebooting with the new kernel i can see the bitmask
> for every process running on my server.
> 
> #cat /proc/1310/cpus_allowed
> 
> 
> Now, if i want to run this process on only one cpu, i which way
> do i have to set the bitmask ?
> Let's say, i want to run it on cpu0. how look's the bitmask ?

Each bit corresponds to a logical CPU on which the task
is permitted to run.  So 1->CPU0, 2->CPU1, 5->CPU0+CPU2, etc.

But it does seem there are problems with the scheduler
which occur when cpus_allowed it not all-ones.  I didn't
observe any problems in the 1-2 hours testing which I
needed that patch for, so it should be OK for experimentation
purposes..

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Peter Samuelson]

[Dennis]
> For example, if there were six different companies that marketed
> ethernet drivers for the eepro100, you'd have a choice of which one
> to buy..perhaps with different "features" that were of value to
> you. Instead, you have crappy GPL code that locks up under load, and
> its not worth spending corporate dollars to fix it because you have
> to give away your work for free under GPL. And since there is a
> "free" driver that most people can use, its not worth building a
> better mousetrap either because the market is too small. So, the
> handful of users with problems get to "fit it themselves", most of
> whom cant of course.

You may have a point but device drivers are a piss-poor example.  Say
Linux does take over the world, and eepro100 continues to lock up under
load.  Who loses?  Intel.  People will quit buying their motherboards
and PCI cards.  So for whom is it worth spending corporate dollars
fixing eepro100?  Again, Intel.  If word were to get out "avoid Intel
network cards, the driver is crap", you can bet they will fix it.

If this hasn't happened yet, it's because Intel doesn't see enough
market in Linux to bother.  And if so, so what?  There are plenty of
motherboards with pcnet32 and 3c9xx chips.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] a more efficient BUG() macro

[Keith Owens]

On Sun, 18 Feb 2001 01:33:53 +0100, 
"J . A . Magallon" <[EMAIL PROTECTED]> wrote:
>Try this:
>a.h:
>#define hello printf("%d at %s\n",__LINE__,__FILE__)
>
>a.c:
>#include 
>#include "a.h"
>
>int main()
>{
>hello;
>hello;
>return 0;
>}
>
>werewolf:~/ko> gcc a.c -o a
>werewolf:~/ko> a
>6 at a.c
>7 at a.c


But 

a.h
static inline void hello(void) { printf("%d at %s\n",__LINE__,__FILE__); }

a.c
#include 
#include "a.h"

int main()
{
hello();
hello();
return 0;
}

# ./a
1 at a.h
1 at a.h

Most uses of BUG() in headers use inline functions instead of #define.
48 occurrences of BUG() in include/{linux,asm-i386}, only 2 are in
#define.

>As I said before, my choose would be the __func__ + __LINE__ predefined macros.
>I would prefer to see 'bug in my_buggy_device_init(), line 42'. And you can
>even drop the __LINE__ part.

Function names are not unique, especially when you get into modules.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] a more efficient BUG() macro

[J . A . Magallon]

On 02.18 Keith Owens wrote:
> 
> __C_FILE__ and __C_LINE__ refer to the .c or .s file that included the
> header, so you get the exact location of the failing code instead of
> the name and line number of a common header which is used all over the
> place.  __C_FILE__ would be replaced with the minimum string required

Are you sure about that ?
Try this:
a.h:
#define hello printf("%d at %s\n",__LINE__,__FILE__)

a.c:
#include 
#include "a.h"

int main()
{
hello;
hello;
return 0;
}

werewolf:~/ko> gcc a.c -o a
werewolf:~/ko> a
6 at a.c
7 at a.c

(line changes, and name is .c)
because __FILE__ and __LINE__ are expanded with respect to the current
SOURCE file (see info cpp), not header file.

As I said before, my choose would be the __func__ + __LINE__ predefined macros.
I would prefer to see 'bug in my_buggy_device_init(), line 42'. And you can
even drop the __LINE__ part.

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac17 #1 SMP Sat Feb 17 01:47:56 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.1ac17 hang on mounting loopback fs

[Pete Toscano]

hmmm... I've been trying to play with GRUB on my 2.4.2-pre4 system.  For
safety's sake, I wanted to make a bookdisk with mkbootdisk.  After
reading this, I see now why mkbootdisk was locking in the D state with
the loop mounted... Would this also explain not being able to seek
forward while writing a floppy?  

I was trying to make the GRUB boot disk by writing the stage 1 and 2
loaders to the floppy (as per the GRUB docs) with dd:

[root@bubba grub]# dd of=/dev/fd0 if=stage1 bs=512 count=1
1+0 records in
1+0 records out
[root@bubba grub]# dd of=/dev/fd0 if=stage2 bs=512 seek=1
dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied

With 2.4.1, I get a different error message, but, AFAICT, the same
result.

pete


Alan Cox writes:
> > # mount -t ext2 -o loop /spare/i486-linuxaout.img /spare/mnt
> > loop: enabling 8 loop devices
> 
> Loop does not currently work in 2.4. It might partly work by luck
> but thats it.  This will change as and when the new loop patches go
> in. Until then if you need loop use 2.2

 PGP signature

Re: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaksmozilla compile

[Chris Mason]

On Saturday, February 17, 2001 05:21:18 PM +0100 Frank de Lange
<[EMAIL PROTECTED]> wrote:

> Hi'all,
> 
> Well, subject says it all... When I try to compile mozilla (CVS version)
> with the '--enable-elf-dynstr-gc' option, the compile fails with a
> segfault:
> 
> ../../dist/bin/elf-dynstr-gc ../../dist/lib/components/libsample.so
> make[2]: *** [install] Segmentation fault (core dumped)
> 

That's not good.  Which compiler did you use to compile the kernel?  This
sounds lame, but reiserfs exercises the cpu/mem more than ext2, so we hit
bad ram more often.  If we run out of other things to try, please run a
memory tester.

> compiling the same codebase on an ext2 filesystem does not produce this
> segfault. When I compare the produced library (libsample.so), there is a
> consistent difference between the one compile on the reiserfs and the ext2
> filesystem. Running objdump on the reiserfs-compiled library also produces
> errors (some assertion failures, a lot of 'invalid string offset' errors,
> and finally a 'Memory exhausted' error), while objdump happily
> disassebles the ext-produced binary.
> 

Where in the libsample.so file are the differences (what byte offset?).
Are they restricted to a given range, or do they vary randomly?

> These problems occur on:
> 
>  2.4.1
>  2.4.2-pre4
>  2.4.2-pre4 with Chris Mason's 'reiserfs fix for null bytes in small
>  files'
> 
At least the patch didn't make it worse.  Would anyone care to comment on
how the elf-dynstr-gc option changes the file access patterns for the
compile?

thanks,
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Re: System V msg queue bugs in latest kernels

[Andries . Brouwer]

From [EMAIL PROTECTED] Sat Feb 17 22:45:36 2001

I'm sending this to you with the hope that lines like this (in ipcs.c)
can be modified to report proper values:

 printf ("%-10o%-12ld%-12ld\n",
ipcp->mode & 0777,
/*
 * glibc-2.1.3 and earlier has unsigned short;
 * glibc-2.1.91 has variation between
 * unsigned short, unsigned long
 * Austin has msgqnum_t
 */
(long) msgque.msg_cbytes,
(long) msgque.msg_qnum);  

msg_cbytes and msg_qnum should be handled differently (as per Manfred's
email).

Hmm. In 2.2.18 these fields are short in the kernel, so there is
no more information, and ipcs cannot print it.
In 2.4.1 these fields are long in the kernel, and are copied back
to user space using copy_msqid_to_user() which will give the longs
in case IPC_64 was set, and the shorts otherwise.

(By the way, "IPC_64" is rather a misnomer - it is more like IPC_32.
I could well imagine that we'll need something for 64-bits sooner or
later (and call it IPC_128 then?).)

Manfred's email does

#define msg_lqbytes__rwait

that is, his program stores information in, and retrieves information
from some field that maybe is unused. In fact the kernel also uses it,
so I don't think that would be very successful.

No, we must just use IPC_64 when it is available, and that is glibc's job.
Looking at the libc source I see that glibc-2.1.95 does this, but
glibc-2.1.3 doesn't. So, maybe, if you upgrade your glibc all will be well.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation... [way O.T.]

[Gerhard Mack]

On Sat, 17 Feb 2001, Dennis wrote:

> BSDI is distributing FreeBSD now. They havent done anything useful to 
> support it. They are just cashing in on it.

That's BS last I heard they were merging their SMP support.

Btw have you submitted bug reports for your networking card? If not you
have no one to blame but yourself for the fact that it's not working on
your system.

Gerhard


--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: aic7xxx (and sym53c8xx) plans

[Peter Samuelson]

[Nathan Black]
> This really improved the performance of my dual PIII-866 w/512MB Ram
> and AIC7899 scsi.
[...]
> I would suggest, if at all possible, putting this in the 2.4.2
> kernel.

Have you any idea the breadth of cards and chips that aic7xxx supports?
Sure, Justin's driver does great with your shiny new 7899, but can you
verify that it also drives the 8-year-old EISA AHA-2740 I still have
sitting around (actually retired to the parts pile, but that's beside
the point, I'm sure some still exist in the wild)?  How about the VLB
card I have in my 486 at home?

IMHO there is no way Linus should consider replacing aic7xxx with 6.1
in a stable kernel.  Not until it has gotten as much testing on as much
obscure hardware as the old driver, which is not going to happen soon.
Breaking existing working setups in 2.4.x is not an option.  Possible
solution: let the two drivers coexist, like ncr53c8xx vs sym53c8xx or
tulip vs old_tulip.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] a more efficient BUG() macro

[Keith Owens]

On Sat, 17 Feb 2001 13:15:42 + (GMT), 
Hugh Dickins <[EMAIL PROTECTED]> wrote:
>On Sat, 17 Feb 2001, Paul Gortmaker wrote:
>> Anyway this small patch makes sure there is only one "kernel BUG..." string,
>> and dumps __FILE__ in favour of an address value since System.map data is 
>> needed to make full use of the BUG() dump anyways.  The memory stats of two 
>> otherwise identical kernels:
>substitute INLINE_BUG() in inline functions, but use your macro
>(with 0x%p address) for it instead of mine.  What do others think?
>Keith, does the address format need adjusting to suit ksymoops?

I would prefer to see

  extern const char *kernel_bug;
  printk(kernel_bug, __C_FILE__, __C_LINE__)

init/main.c contains
  const char *kernel_bug = "kernel BUG at %s:%d!\n";
kernel_bug is also exported.

__C_FILE__ and __C_LINE__ refer to the .c or .s file that included the
header, so you get the exact location of the failing code instead of
the name and line number of a common header which is used all over the
place.  __C_FILE__ would be replaced with the minimum string required
to uniquely identify the file, e.g. isdn_audio.c (unique at one level)
or romfs/inode.c (unique at two levels).

Standard gcc will not do this.  But as part of my makefile rewrite I am
reading the pre-processed output as it is generated by cpp and before
it is read by cc1, to extract data for module symbol versions.  It is
trivial for my code to look for __C_FILE__ and __C_LINE__ (cpp will
have left them alone) and replace them with the relevant string and
number.

Would people prefer the C/ASM filename in BUG() messages instead of the
include header?  If so I will add it to my todo list for the makefile
rewrite.  Of course you can still use __FILE__ and __LINE_ if you
really want to report the error against the include file.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.1ac17 hang on mounting loopback fs

[Ville Herva]

On Sat, Feb 17, 2001 at 12:42:42PM -0800, you [Nate Eldredge] claimed:
> Alan Cox writes:
>  > > # mount -t ext2 -o loop /spare/i486-linuxaout.img /spare/mnt
>  > > loop: enabling 8 loop devices
>  > 
>  > Loop does not currently work in 2.4. It might partly work by luck
>  > but thats it.  This will change as and when the new loop patches go
>  > in. Until then if you need loop use 2.2
> 
> I see.  Thank you.  I can live without it until then.
> 
> Btw, I applied Jens Axboe's loop-3 patch as suggested by Ville Herva.
> It applied with some fuzz and offset.  However, when I booted it, the
> kernel oopsed when I tried to mount the first ordinary ext2 partition
> (no loopback involved).  I can post the oops if anyone cares, but I
> presume that loop-3 and 2.4.1ac17 are just incompatible.

I'm not sure if it'll apply any more cleanly (and work), but the newest is
loop-4 at

ftp://ftp.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.2-pre1

(It should work with 2.4.1pre1, at least).


-- v --

[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: System V msg queue bugs in latest kernels

[Christopher Allen Wing]

Manfred:

> If you want to access values > 65535 from your app you have 2 options:
> 
> 1) use the new msqid64_ds structure. You must pass IPC_64 to the msgctl
> call. This is the only option if you need correct 32-bit uids.

glibc 2.2 will support this natively without needing any changes to your
application (besides a recompile). struct msqid_ds in the glibc 2.2
headers corresponds to struct msqid64_ds in the kernel.

It would be a bad thing to require people to change their source code in
order to build against the improved sysvipc interface :)

(glibc 2.2 also handles the case of a non 2.4 kernel properly, by
detecting the lack of IPC_64 support and emulating it in software-- Jakub
Jelinek wrote this compatibility code because I was too lazy/didn't need
it myself)

-Chris Wing
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

usb audio

[Landsberger Brian J]

Has anyone been able to get the Apple Pro (the round clear) speakers to
work in Linux? I've read the howto's and followed the various steps to
no avail. The various usb modules print the following to syslog:


Feb 17 14:05:50 fux0r kernel: usb.c: registered new driver audio
Feb 17 14:05:51 fux0r kernel: usbaudio: device 4 audiocontrol interface
0 has 0 input and 1 output AudioStreaming interfaces
Feb 17 14:05:51 fux0r kernel: usbaudio: device 4 interface 1 altsetting
0 does not have an endpoint
Feb 17 14:05:51 fux0r kernel: usbaudio: device 4 interface 1 altsetting
1: format 0x0010 sratelo 5000 sratehi 5 attributes 0x00
Feb 17 14:05:51 fux0r kernel: usbaudio: device 4 interface 1 altsetting
2: format 0x8010 sratelo 5000 sratehi 5 attributes 0x00
Feb 17 14:05:51 fux0r kernel: usbaudio: device 4 interface 1 altsetting
3 unsupported channels 2 framesize 3
Feb 17 14:05:51 fux0r kernel: usbaudio: constructing mixer for Terminal
3 type 0x0301

Some info out of usbdevfs on the speakers...

Speakers
Manufacturer: Apple Computer, Inc.
Serial Number: p4000
Speed: 12Mb/s (full)
USB Version:  1.10
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 8
Number of Configurations: 1
Vendor Id: 05ac
Product Id: 1101
Revision Number:  0.01

Config Number: 1
Number of Interfaces: 3
Attributes: 80
MaxPower Needed: 500mA

Interface Number: 0
Name: audio
Alternate Number: 0
Class: 01(audio) 
Sub Class: 1
Protocol: 0
Number of Endpoints: 0

Interface Number: 1
Name: audio
Alternate Number: 0
Class: 01(audio) 
Sub Class: 2
Protocol: 0
Number of Endpoints: 0

Interface Number: 1
Name: audio
Alternate Number: 1
Class: 01(audio) 
Sub Class: 2
Protocol: 0
Number of Endpoints: 1

Endpoint Address: 01
Direction: out
Attribute: 9
Type: Isoc
Max Packet Size: 112
Interval:   1ms

Interface Number: 1
Name: audio
Alternate Number: 2
Class: 01(audio) 
Sub Class: 2
Protocol: 0
Number of Endpoints: 1

Endpoint Address: 01
Direction: out
Attribute: 9
Type: Isoc
Max Packet Size: 224
Interval:   1ms

Interface Number: 1
Name: audio
Alternate Number: 3
Class: 01(audio) 
Sub Class: 2
Protocol: 0
Number of Endpoints: 1

Endpoint Address: 01
Direction: out
Attribute: 9
Type: Isoc
Max Packet Size: 336
Interval:   1ms

Interface Number: 2
Name: hid
Alternate Number: 0
Class: 03(HID  ) 
Sub Class: 0
Protocol: 0
Number of Endpoints: 1

Endpoint Address: 83
Direction: in
Attribute: 3
Type: Int.
Max Packet Size: 2
Interval:   8ms

Thanks,
Brian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.1ac18

[Alan Cox]

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

2.4.1-ac18
o   Fix SO_SNDTIMEO bugs(Alexey Kuznetsov)
o   Fix tmpfs fsync (Lennert Buytenhek)
o   PPC now uses generic pci bus setup  (Paul Mackerras)
o   Remove PPC boot argument printing   (Paul Mackerras)
o   Jeff Tranter has moved  (Jeff Tranter)
o   ymf_pci driver cleanups (Pete Zaitcev)
o   Fix USB 2.0 compliance in hub.c (Brad Hards)
o   Fix usb hub device claim race   (Paul Mackerras)
o   Fix some bugs in mac_hid driver (Paul Mackerras)
o   Fix more typos  (Dag Wieers)
o   PPC compile warnings/symbol export fixes(Paul Mackerras)

2.4.1-ac17
o   Fix pegasus for bigendian   (Roman Weissgaerber)
o   Further smbfs fixes (Urban Widmark)
o   Update ISDN version tags(Kai Germaschewski)
o   Finish ISDN move to new style module_init   (Kai Germaschewski)
o   Small Eicon driver updates/fix license bug  (Armin Schindler)
o   Fix reiserfs tail packing problem   (Alexander Zarochentcev
 Chris Mason)
o   Export aci symbols from drivers/sound/aci.c (Alexandr Kanevskiy)
o   Merge Linus 2.4.2pre4
o   Starfire update (Ionu Badulescu)
o   Fix 3270 merge  (Richard Hitt)

2.4.1-ac16
o   Fix the exception table/unload race (me)
o   Further tulip fixup (Manfred Spraul)
o   Fix USB oops on traverse/delete race(Randy Dunlap)
o   Set max_sectors to 255 for hd/xd drivers(Paul Gortmaker)
| This should make them work again
o   Fix typo in USB makefile(Arjan van de Ven)
o   Fix accidental change to scsi_scan  (Steve Ralston)
o   Hid rollover/endian fixes   (Paul Mackerras)
o   Drop via pci fixup  (me)
o   Further hp5300 fixups   (Arjan van de Ven)
o   PCnet 32 init changes for non SEPROM cards  (Eli Carter)
o   Fix acpi idle reporting on SMP  (Philipp Hahn)
o   Add non PCI pci device list walk macro  (me)
| pointed out by Mikael Pettersson
o   IBM S/390 3270 drivers  (Richard Hitt)

2.4.1-ac15
o   Fix the non booting winchip/cyrix problem   (me)
| Nasty interaction with the vmalloc fix 
| wants a cleaner solution. This one is a hack
| to get people up and running again
o   Fix typo in vfat changes(OGAWA Hirofumi)
o   Update scsi blacklist table (Karsten Hopp)
o   dscc4 wan driver update (Francois Romieu)
o   Fix clgenfb warning (Bryan Headley)

2.4.1-ac14
o   Fix tulip problems introduced by in ac13(Manfred Spraul)
o   S/390x build fixes  (Ulrich Weigand)
o   Fix off by one error in octagon driver  (David Woodhouse)
o   Fix dasd driver for new queues  (Holger Smolinksi)
o   Networking standards compliance fixes
o   Fix binary layout assumptions in sym53c416  (Arjan van de Ven)
o   tmpfs timestamps(Christoph Rohland)
o   Further mkdep changes   (Keith Owens)
o   Fix 16bit vfat handling (OGAWA Hirofumi)
o   JIS nls fixes   (OGAWA Hirofumi)
o   Handle more than 8 luns (Eric Youngdale,
 Doug Gilbert)
o   Minor scsi clean ups(Eric Youngdale)

2.4.1-ac13
o   Fix pnic tulip problems (Manfred Spraul)
o   Fix USB printer read and poll problems  (Johannes Erdfelt)
o   Fix parport pci list corrupt bug(Tim Waugh)
o   Fix sbpcd driver crashes(Paul Gortmaker)
o   Clarify the locking doc (Rusty Russell)
o   i810 audio doesnt need OSS  (Jeff Garzik)
o   Fix vmalloc fault race  (Mark Hemment)
o   Makedep fixes   (Keith Owens)
o   Fix missing unlock_kernel on usb hub(Paul Mundt)
o   Fix smbfs+bigmem, buffer and listing bugs   (Urban Widmark)
o   Merge tms380 isa token ring support (Jochen Friedrich)
o   Sigmatel change didnt help, removed (Jeff Garzik)

Re: Linux stifles innovation...

[Michael H. Warfield]

On Sat, Feb 17, 2001 at 02:38:19PM -0800, Andre Hedrick wrote:
> On Sat, 17 Feb 2001, Dennis wrote:
> > good commercial drivers dont need fixing. another point. You are arguing 
> > that having source is required to fix crappy code, which i agree with.

> > You "guys" like to have source, and there is nothing wrong with that. But 
> > requiring that all code be distributed as source DOES stifle innovation. 
> > Its as simple as that.

> And when your customer gets screw because you refuse to update your binary
> driver because you do not know or have had the chance to follow any
> evolving API, you are going to blame us in OPEN source, right.

At our office, we actually had a sysadmin suggest that the reason
we had problems with viruses propagating was because they couldn't put
everyone on Exchange (some of us use Unix/Linux) and that was causing the
problems.  Of course...  Operating systems which are immune to these things
are to blame for the epidemics on the ones that are suceptible.  That
makes sense.  G  Of course the availablity of quality drivers with
sources are the reason for crappy closed source drivers...  I can see his
reasoning (isn't that scary).  <;-/=/

Actually, it does make a perverted sort of sense.  If we didn't
have systems that didn't have these problems, nobody would think that
there was anything wrong.  They would just think that "of course, this
is what you expect from suppliers".  They would have no yardstick to
measure against, so rebooting a computer once a day or having a blue
screen would just be part of the normal experience.  So we DO contribute
to his problems!  We provide a standard which he can not live up to or
even pursue given the manpower and talent he may have (or not have).
How is he suppose to innovate when the Open Source community is setting
such a high standard for him?  :->=>

> Meanwhile the API changes may have boosted the performance factor and you
> have screw yourself and customer base because you are to lame to see the
> value of open source.
> 
> Some time ago I proposed CLAPI, and you are one of the venders that would 
> benefit from such a beast.  This model would have required you to LGPL a
> kernel library that would have all the functional IP (that is not IP) that
> is to lame to be placed into the hardware.  If your hardware is so flakey
> that you have to pump/prime it for operationswellyou get the
> point.
> 
> If I recall you and your company on one of the worst offenders of taking
> code (GPL or not) and changing it and putting it out as binaries.  I am
> surprized that you have not been taken down yet.  Then if someone asks for
> the return of the code base and changes because they can under the terms
> of the license that you removed from that code, you charge them a fee and
> suggest actionable terms if any disclosure into the public form from
> where it came.

Well...  Yeah...  Of course, Andre.  Can you see how that stiffles
his innovation.

> Regards,

Later!

> Andre Hedrick
> Linux ATA Development

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SO_SNDTIMEO: 2.4 kernel bugs

[Chris Evans]

Hi Alexey,

This patch fixes my simple read()/write() tests, nice one. The behaviour
also now matches BSD (someone kindly donated me a FreeBSD shell for
testing).

Unfortunately, I discovered a bug with SO_SNDTIMEO/sendfile():

- Connect an AF_INET, SOCK_STREAM socket to a local listening socket.
- Set 5 seconds SO_SNDTIMEO on the connected socket
- Do a sendfile() from a big file down the connected socket. Make sure the
size is big (e.g. 1Mb) so the call blocks.
--> BUG!! The call blocks indefinitely rather than being interrupted after
5 seconds.

Cheers
Chris

On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote:

> Hello!
>
> > Unfortunately, it seems to be very buggy. Here are two buggy scenarios.
>
>
> --- ../vger3-010210/linux/net/ipv4/tcp.c  Sat Feb 10 23:16:51 2001
> +++ linux/net/ipv4/tcp.c  Sat Feb 17 23:27:43 2001
> @@ -691,6 +691,8 @@
>
>   set_current_state(TASK_INTERRUPTIBLE);
>
> + if (!timeo)
> + break;
>   if (signal_pending(current))
>   break;
>   if (tcp_memory_free(sk) && !vm_wait)
> --- ../vger3-010210/linux/net/core/sock.c Tue Jan 30 21:20:16 2001
> +++ linux/net/core/sock.c Sat Feb 17 23:27:44 2001
> @@ -727,6 +727,8 @@
>   clear_bit(SOCK_ASYNC_NOSPACE, >socket->flags);
>   add_wait_queue(sk->sleep, );
>   for (;;) {
> + if (!timeo)
> + break;
>   if (signal_pending(current))
>   break;
>   set_bit(SOCK_NOSPACE, >socket->flags);
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Andre Hedrick]

On Sat, 17 Feb 2001, Dennis wrote:

> good commercial drivers dont need fixing. another point. You are arguing 
> that having source is required to fix crappy code, which i agree with.
> 
> You "guys" like to have source, and there is nothing wrong with that. But 
> requiring that all code be distributed as source DOES stifle innovation. 
> Its as simple as that.

And when your customer gets screw because you refuse to update your binary
driver because you do not know or have had the chance to follow any
evolving API, you are going to blame us in OPEN source, right.

Meanwhile the API changes may have boosted the performance factor and you
have screw yourself and customer base because you are to lame to see the
value of open source.

Some time ago I proposed CLAPI, and you are one of the venders that would 
benefit from such a beast.  This model would have required you to LGPL a
kernel library that would have all the functional IP (that is not IP) that
is to lame to be placed into the hardware.  If your hardware is so flakey
that you have to pump/prime it for operationswellyou get the
point.

If I recall you and your company on one of the worst offenders of taking
code (GPL or not) and changing it and putting it out as binaries.  I am
surprized that you have not been taken down yet.  Then if someone asks for
the return of the code base and changes because they can under the terms
of the license that you removed from that code, you charge them a fee and
suggest actionable terms if any disclosure into the public form from
where it came.

Regards,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Comparing buffer cache algorithms on 2.2.17. Suggestions?

[Fireball Freddy]

Howdy,

  Trying to implement some different buffer caching
algorithms in Linux.  This is just for comparison
purposes for a thesis, not suggesting any problem with
the current scheme.  Here is what I'm attempting:

  o Eliminate BUF_CLEAN, BUF_DIRTY, and BUF_LOCKED
lists in favor of a single BUF_LRU list.  This because
I don't see the point of maintaining three lists...
the only time I need to find all the dirty blocks is
on a sync of some sort.  I don't mind if the sync
takes a while longer if the normal operating condition
is faster.

  Once I have the cache working on a single list
(assuming I can!) I plan on using an I/O generator to
get some repeatable traces so I can compare the
following:

  o LRU vs SLRU with static region percentages vs SLRU
with dynamic region percentages
  o Periodic flushing of dirty blocks enabled vs
disabled
  o Write-through caching vs write-back caching vs
adaptive (switching between wt and wb based on recent
activity) vs my own method (write to disk on first
write, only to buffer after that, write to disk again
when block is flushed, if dirty)
  o Of course, I'll also do a run with the default
Linux 2.2.17 to see how it compares with the others

  It looks like the ext2 fs is going to complicate
this somewhat, as it sets blocks dirty and/or writes
them itself sometimes.  Not sure how I'm going to get
around this... will probably ignore it for now.

  I'd appreciate any advice on this undertaking. 
Specifically, how many things (tools, etc) is this
going to break, warnings about common pitfalls, and
other suggestions.  I would like to have started this
on 2.4, but I wanted to work on a release that had
been out for a bit, so I'd know that any problems were
caused by *me* and not just kernel bugs.  :)

  Also, are there any specific people to whom I should
direct memory management questions?  I've had some in
the past few months but haven't been able to get
answers.  Or should I post them to this list (I assume
not).  Finally, I have noticed references to a
kernelnewbies chat room.  I prefer newsgroups to
chat... is there a good mailing list devoted to kernel
newbies?

  Thanks to everyone for your hard work, and apologies
for adding one more e-mail to the pile.

Andy Cottrell

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: re. too long mac address for --mac-source netfilter option

[jpinpg]

James L. wrote -
> Hello All,
> 
> On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote:
> > Stefan Hanse writes -
> > >Umm..  An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6
> >groups, not 14. Is this really an ethernet
> > >interface? (If it really has 14 groups).
> >
> >> Good question. I have determined by scanning my firewall logs that the
> >"invalid" mac addresses are all coming from cable modem routers. And my
> >linux kernel is recognizing them as being MAC addresses. Would it be
> >better to write another module looking for these long "MAC"  rather than
> >tamper with the mac module?
> >
> >> To illustrate, here is a cut from my system log showing a portscan from
> >my cable modem provider (a routine part of their service contract since
> >you are not allowed to run client-side servers). SRC and DST have been
> >x'ed out:
> >
> >> Feb 17 08:49:42 nonesuch kernel: IN=eth0 OUT=
> >MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx
>  ^
>   This appears to be an ATM NSAP address .  Hth ,  JimL

OK, thanks Jim. The question then becomes: could a netfilter module for recognizing 
ATM addresses be developed? Are all ATM addresses 14 groups?

Jack Bowling
mailto: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Felix von Leitner]

Thus spake Dennis ([EMAIL PROTECTED]):
> You are confusing "progress" with "innovation". If there is only 1 choice, 
> thats not innovation. Expanding on a bad idea, or even a good one, is not 
> innovation.

This is bizarre.

Please name one innovation in the history of mankind that could not be
seen as expanding on a different idea or even cloning an idea from
someone else (for example, nature).

Dennis, do you have a single argument or are you going to post bizarre
statements like this forever?  Please just say so, so people cann
killfile you now.

Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LONG RANT] Re: Linux stifles innovation...

[Felix von Leitner]

Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
> "If a company does not write a driver which works on all hardware
>  platforms in all cases and gives us the source, then it is better,
>  that the company writes no drivers at all."

> "If I can't force a company to write a driver for everyone, then I
>  don't want to write them any driver at all."

> IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

Henning, what is the matter with you?

I bought the hardware.  Why should I pay for the driver?
Not even on Windows you pay extra for a driver!

Please state your intentions.  Why would you want to split the Linux
user base into people who pay companies to screw them (I get a driver
for hardware I already paid for, but the driver will work with exactly
one kernel version on one hardware) and people who think they deserve
support when they buy hardware?

Why do we even have to discuss drivers?
A company that actively hinders developing a good driver with patents,
NDAs or other legal crap does not deserve my money.  If you throw your
money at such people, you deserve everything you get.

Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Changes to ide-cd for 2.4.1 are broken?

[John Fremlin]

Specifically, this part:

@@ -2324,11 +2309,17 @@
sense.ascq == 0x04)
return CDS_DISC_OK;
 
+
+   /*
+* If not using Mt Fuji extended media tray reports,
+* just return TRAY_OPEN since ATAPI doesn't provide
+* any other way to detect this...
+*/
if (sense.sense_key == NOT_READY) {
-   /* ATAPI doesn't have anything that can help
-  us decide whether the drive is really
-  emtpy or the tray is just open. irk. */
-   return CDS_TRAY_OPEN;
+   if (sense.asc == 0x3a && (!sense.ascq||sense.ascq == 1))
+   return CDS_NO_DISC;
+   else
+   return CDS_TRAY_OPEN;
}

My tray is open as I type, and it is misreported as CDS_NO_DISC. In
2.4.0 it worked fine.

# strace cdd
execve("/trusted/bin/cdd", ["cdd"], [/* 35 vars */]) = 0
open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = 5
ioctl(5, CDROM_DRIVE_STATUS, 0) = 1
write(1, "No disc in drive\n", 17No disc in drive
)  = 17
_exit(0)= ?

>From linux/include/linux/cdrom.h:

#define CDS_NO_INFO 0   /* if not implemented */
#define CDS_NO_DISC 1
#define CDS_TRAY_OPEN   2
#define CDS_DRIVE_NOT_READY 3
#define CDS_DISC_OK 4

(The usual plug: download my beautifully minimalistic but featureful
hand coded assembly cd player from
http://john.snoop.dk/programs/linux/asm-toys).

Some miscellaneous hardware details from dmesg:

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 78
PCI: Hardcoded IRQ 14 for device 00:0f.0
ALI15X3: chipset revision 32
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: SAMSUNG VG36483A (6.48GB), ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: IBM-DTLA-305020, ATA DISK drive
hdd: TOSHIBA DVD-ROM SD-M1102, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 12685680 sectors (6495 MB) w/494KiB Cache, CHS=789/255/63, (U)DMA
hdc: 40188960 sectors (20577 MB) w/380KiB Cache, CHS=39870/16/63, (U)DMA
hdd: ATAPI 24X DVD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.12

-- 

http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SO_SNDTIMEO: 2.4 kernel bugs

[Chris Evans]

Alexey,

Damn you are quick! :) Testing immediately

Cheers
Chris

On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote:

> Hello!
>
> > Unfortunately, it seems to be very buggy. Here are two buggy scenarios.
>
>
> --- ../vger3-010210/linux/net/ipv4/tcp.c  Sat Feb 10 23:16:51 2001
> +++ linux/net/ipv4/tcp.c  Sat Feb 17 23:27:43 2001
> @@ -691,6 +691,8 @@
>
>   set_current_state(TASK_INTERRUPTIBLE);
>
> + if (!timeo)
> + break;
>   if (signal_pending(current))
>   break;
>   if (tcp_memory_free(sk) && !vm_wait)
> --- ../vger3-010210/linux/net/core/sock.c Tue Jan 30 21:20:16 2001
> +++ linux/net/core/sock.c Sat Feb 17 23:27:44 2001
> @@ -727,6 +727,8 @@
>   clear_bit(SOCK_ASYNC_NOSPACE, >socket->flags);
>   add_wait_queue(sk->sleep, );
>   for (;;) {
> + if (!timeo)
> + break;
>   if (signal_pending(current))
>   break;
>   set_bit(SOCK_NOSPACE, >socket->flags);
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] clean up inconsistent formatting in MAINTAINERS

[john slee]

against 2.4.1:

this may seem rather frivolous, but...

patch below makes all data lines start with the appropriate letter, a
colon, then a tab.  previously some entries used (varying amounts of)
space characters instead of tabs.

--- MAINTAINERS.origSun Feb 18 01:48:03 2001
+++ MAINTAINERS Sun Feb 18 02:04:44 2001
@@ -230,11 +230,11 @@
 S: Maintained
 
 COMPAQ FIBRE CHANNEL 64-bit/66MHz PCI non-intelligent HBA
-P:  Amy Vanzant-Hodge 
-M:  Amy Vanzant-Hodge ([EMAIL PROTECTED])
+P: Amy Vanzant-Hodge 
+M: Amy Vanzant-Hodge ([EMAIL PROTECTED])
 L: [EMAIL PROTECTED]
 W: ftp.compaq.com/pub/products/drivers/linux
-S:  Supported
+S: Supported
 
 COMPAQ SMART2 RAID DRIVER
 P: Charles White   
@@ -251,14 +251,14 @@
 S: Supported 
 
 COMPUTONE INTELLIPORT MULTIPORT CARD
-P: Doug McNash
-P: Michael H. Warfield
-M: Doug McNash <[EMAIL PROTECTED]>
-M: Michael H. Warfield <[EMAIL PROTECTED]>
-W: http://www.computone.com/
-W: http://www.wittsend.com/computone.html
-L: [EMAIL PROTECTED]
-S: Supported
+P: Doug McNash
+P: Michael H. Warfield
+M: Doug McNash <[EMAIL PROTECTED]>
+M: Michael H. Warfield <[EMAIL PROTECTED]>
+W: http://www.computone.com/
+W: http://www.wittsend.com/computone.html
+L: [EMAIL PROTECTED]
+S: Supported
 
 COMX/MULTIGATE SYNC SERIAL DRIVERS
 P: Gergely Madarasz
@@ -347,10 +347,10 @@
 
 DIGI INTL. EPCA DRIVER
 P: Chad Schwartz
-M:  [EMAIL PROTECTED]
-M:  [EMAIL PROTECTED]
-L:  [EMAIL PROTECTED]
-S:  Maintained
+M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
+S: Maintained
 
 DIGI RIGHTSWITCH NETWORK DRIVER
 P: Rick Richardson
@@ -373,12 +373,12 @@
 S: Supported
 
 DISK GEOMETRY AND PARTITION HANDLING
-P: Andries Brouwer
-M: [EMAIL PROTECTED]
-W: http://www.win.tue.nl/~aeb/linux/Large-Disk.html
-W: http://www.win.tue.nl/~aeb/linux/zip/zip-1.html
-W: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
-S: Maintained
+P: Andries Brouwer
+M: [EMAIL PROTECTED]
+W: http://www.win.tue.nl/~aeb/linux/Large-Disk.html
+W: http://www.win.tue.nl/~aeb/linux/zip/zip-1.html
+W: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
+S: Maintained
 
 DISKQUOTA:
 P: Marco van Wieringen
@@ -442,9 +442,9 @@
 S: Maintained
 
 ETHERTEAM 16I DRIVER
-P:  Mika Kuoppala
-M:  [EMAIL PROTECTED]
-S:  Maintained
+P: Mika Kuoppala
+M: [EMAIL PROTECTED]
+S: Maintained
 
 EXT2 FILE SYSTEM
 P: Remy Card
@@ -498,10 +498,10 @@
 S: Maintained
 
 HFS FILESYSTEM
-P:  Adrian Sun
-M:  [EMAIL PROTECTED]
-L:  [EMAIL PROTECTED]
-S:  Maintained
+P: Adrian Sun
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
+S: Maintained
 
 HGA FRAMEBUFFER DRIVER
 P: Ferenc Bakonyi
@@ -527,11 +527,11 @@
 S: Maintained 
 
 LOGICAL VOLUME MANAGER
-P: Heinz Mauelshagen
-M: [EMAIL PROTECTED]
-L: [EMAIL PROTECTED]
-W: http://linux.msede.com/lvm
-S: Maintained 
+P: Heinz Mauelshagen
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
+W: http://linux.msede.com/lvm
+S: Maintained 
 
 HIPPI
 P: Jes Sorensen
@@ -578,10 +578,10 @@
 S: Maintained
 
 IBM ServeRAID RAID DRIVER
-P:  Keith Mitchell
-M:  [EMAIL PROTECTED]
-W:  http://www.developer.ibm.com/welcome/netfinity/serveraid.html
-S:  Supported 
+P: Keith Mitchell
+M: [EMAIL PROTECTED]
+W: http://www.developer.ibm.com/welcome/netfinity/serveraid.html
+S: Supported 
 
 IDE DRIVER [GENERAL]
 P: Andre Hedrick
@@ -663,11 +663,11 @@
 S: Maintained
 
 IRDA SUBSYSTEM
-P:  Dag Brattli
-M:  Dag Brattli <[EMAIL PROTECTED]>
-L:  [EMAIL PROTECTED]
-W:  http://irda.sourceforge.net/
-S:  Maintained
+P: Dag Brattli
+M: Dag Brattli <[EMAIL PROTECTED]>
+L: [EMAIL PROTECTED]
+W: http://irda.sourceforge.net/
+S: Maintained
 
 ISAPNP
 P: Jaroslav Kysela
@@ -731,10 +731,10 @@
 S: Maintained
 
 LANMEDIA WAN CARD DRIVER
-P:  Andrew Stanley-Jones
-M:  [EMAIL PROTECTED]
-W:  http://www.lanmedia.com/
-S:  Supported
+P: Andrew Stanley-Jones
+M: [EMAIL PROTECTED]
+W: http://www.lanmedia.com/
+S: Supported
  
 LAPB module
 P: Henner Eisen
@@ -875,17 +875,17 @@
 S: Maintained
 
 NFS CLIENT
-P:  Trond Myklebust
-M:  [EMAIL PROTECTED]
-L:  [EMAIL PROTECTED]
-S:  Maintained
+P: Trond Myklebust
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
+S: Maintained
 
 NI5010 NETWORK DRIVER
-P: Jan-Pascal van Best and Andreas Mohr
-M: Jan-Pascal van Best <[EMAIL PROTECTED]>
-M: Andreas Mohr <[EMAIL PROTECTED]>
-L: [EMAIL PROTECTED]
-S: Maintained
+P: Jan-Pascal van Best and Andreas Mohr
+M: Jan-Pascal van Best <[EMAIL PROTECTED]>
+M: Andreas Mohr <[EMAIL PROTECTED]>
+L: [EMAIL PROTECTED]
+S: Maintained
 
 

Re: [PATCH] starfire reads irq before pci_enable_device.

[David S. Miller]

Jeff Garzik writes:
 > And in another message, On Mon, 12 Feb 2001, David S. Miller wrote:
 > > 3) The acenic/gbit performance anomalies have been cured
 > >by reverting the PCI mem_inval tweaks.
 > 
 > 
 > Just to be clear, acenic should or should not use MWI?
 > 
 > And can a general rule be applied here?  Newer Tulip hardware also
 > has the ability to enable/disable MWI usage, IIRC.

I think this is an Acenic specific issue.  The second processor on the
Acenic board is only there to work around bugs in their DMA
controller.

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Multi-sized MMU page support

[Jeremy Jackson]

Greetings,

I have been staying up late thinking about this, so I'm writing to clear
my head.
(and get some sleep in the future)

Background:

Under ia32 Pentium and higher, 3 different MMU page sizes are
available in hardware: 4kB, 4MB & 2MB.  Under Alpha (21064), sizes
include 8kB, 4MB for code, 8kB, 64kB, 512kB, and 4MB.  Under ia64,
sizes range (in powers of two) from 4kB to 256MB.

Significance:  a number of important architectures support multi-sized
pages.  For applications with large contiguous code and/or data objects,

this enhanced hardware allows a performance increase.  A prerequisite
for using these features is kernel support.

I am unaware of what order of improvement this will allow, but I can
immagine
the pipeline stalls caused on TLB misses: examples: gimp lightens an
entire 64MB image;
a linear scan read-modify-write.  This access pattern isn't *so* bad.
The X server mmaps a 32MB area (3dfx) or larger of the video card for
linear frame
buffer/mmio and accesses it in a slightly less that random fashion.
 This could benefit much more from
larger pages.  Note that this is completely different that MTRR
support.  Also consider
that the TLB cache must be flushed and reloaded frequently durring
context switches
under an OS with separate memory areas for each process.  The larger the
pages, the
fewer entries which must be reloaded.

Also, not completely unrelated are comments in the kernel 2.3.? slab
allocator
regarding the inabliity of the zoned-buddy allocator to provide more
than
single (or trivially larger) pages for slab-cache.  The code which would

request larger pages when it would be more optimal to do so is commented

with 1's hardcoded instead.

Proposed implementation:

Short term:  allow a special (temporary) mmap argument or syscall and
support
in fault handlers/page table routines, to allow mmap or non-ram areas
with larger
sized pages.  the X server could uses this immediately by adding the
call alongside
the MTRR setting.  This avoids swap / mmaped file issues.

Long term: extend the zoned-buddy allocator to include buddy-lists
up to the largest hardware page size;  page table and fault handlers,
swap code, etc; massive work just for UP.  user-space code
could mmap ANON and get an aligned 4MB area using a single hardware
page...

Egad man! or "stop the madness"?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree864.0.2)

[Ingo Buescher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 14 Feb 2001, David Wood wrote:

> Everything actually works rather well, with the exception that when I've
> started XFree86 a few times, coupled with switching virtual consoles, I
> get irretrievably "corrupted" text virtual consoles. The screen becomes
> garbled, sometimes quite colorful, cursor goes to the wrong place, text
> appears in odd locations or is not visible at all. Interestingly, the
> scrollback buffer allows me to scroll through the garble perfectly.
>
> The problem can only be fixed by rebooting.
>

You don't need to reboot. Just try:
echo  CTRL-V ESC-C RETURN

This should reset your console.

IB
- -- 

Ingo Buescher <[EMAIL PROTECTED]>
Fingerprint: A8D9 610F 175E 4B8D FDB7  6077 0878 5ADF DF00 C939
M$ Outlook, the software which made the "Good Times" email hoax a reality.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Made with pgp4pine 1.75

iD8DBQE6jZoeCHha398AyTkRAkP0AJ9a9+x0yhzQIi6BNAQWqrTwJQlxrgCcCQGJ
MGzgb5u9gI9dv+Jys/zPR24=
=iO+o
-END PGP SIGNATURE-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Alan Cox]

> both lock up under load. You dont run a busy ISP i guess. The fact that 
> they come out with a new release every few minutes is clear evidence that 
> it is problematic.

I've been technical director of an ISP. I help manage sites that have not
insignificant loads and no eepro100 driver problems. For that matter there
are porn sites using eepro100 drivers.

> Intel doesnt sell the e100.o driver, so they couldnt give a rats ass if it 

Your information is wrong. But then it usually is. If you are large corporation
and would care to talk to Intel they will be happy to discuss it further.

Of course the single biggest problem with the eepro100 is closedness, and people
in Intel with attitudes like yours who refuse to release full documentation.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Alan Cox]

> When is that specification for 2.4 drivers going to be available? Talk 
> about "stifling the marketplace"!!! Vendors cant even write reliable 
> drivers if they want to.

Its called the source code, which includes example driver skeletons. WHere
is the documentation for writing your own etinc drivers



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.1ac17 hang on mounting loopback fs

[Nate Eldredge]

Alan Cox writes:
 > > # mount -t ext2 -o loop /spare/i486-linuxaout.img /spare/mnt
 > > loop: enabling 8 loop devices
 > 
 > Loop does not currently work in 2.4. It might partly work by luck
 > but thats it.  This will change as and when the new loop patches go
 > in. Until then if you need loop use 2.2

I see.  Thank you.  I can live without it until then.

Btw, I applied Jens Axboe's loop-3 patch as suggested by Ville Herva.
It applied with some fuzz and offset.  However, when I booted it, the
kernel oopsed when I tried to mount the first ordinary ext2 partition
(no loopback involved).  I can post the oops if anyone cares, but I
presume that loop-3 and 2.4.1ac17 are just incompatible.

-- 

Nate Eldredge
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Gregory Maxwell]

On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote:
> good commercial drivers dont need fixing. another point. You are arguing 
> that having source is required to fix crappy code, which i agree with.

Too bad we havn't seen much (any?) good closed-source (what you ment to say
when you said commercial above) drivers for Linux, including the steaming
pile of garbage your company ships.
 
> You "guys" like to have source, and there is nothing wrong with that. But 
> requiring that all code be distributed as source DOES stifle innovation. 
> Its as simple as that.

Like Microsoft you seem to confuse 'innovation' with 'being able to dictate
the terms of how I will extort money from others'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation... [way O.T.]

[Michael H. Warfield]

On Sat, Feb 17, 2001 at 02:56:15PM -0500, Dennis wrote:
> At 05:59 PM 02/16/2001, John Cavan wrote:
> >Dennis wrote:
> > > objective, arent we?
> >
> >You might ask yourself the same question...

> > > For example, if there were six different companies that marketed ethernet
> > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > > with different "features" that were of value to you. Instead, you have
> > > crappy GPL code that locks up under load, and its not worth spending
> > > corporate dollars to fix it because you have to give away your work for
> > > free under GPL. And since there is a "free" driver that most people can
> > > use, its not worth building a better mousetrap either because the market is
> > > too small. So, the handful of users with problems get to "fit it
> > > themselves", most of whom cant of course.

> >A large bulk of the investment in Linux is starting to come in from
> >hardware manufacturers, notably IBM. These companies see Linux as a
> >means to sell more hardware, not as a means to sell software. This is
> >critical, because it means that it IS worth the money to make the driver
> >perform correctly, GPL or not, because a bad driver means no sales.


> Thats wrong. The eepro100 is a great example. It works for most people, so 
> the market for an improved one is very limited. Your market is not the 
> whole community, only the community that needs something better. IBM will 
> simply blame linux if it cant handle a situation. They arent supporting 
> linux, they are only taking advantage of the fact that people want it.

Excuse me?  A 1 billion dolar investment in Linux is not supporting
it?  Setting up tier 1 and tier 2 support services for a half a dozen
distributions is not supporting it?  Porting their AIX file systems and
applications is not supporting it?  Porting it to the 390 is not supporting
it?  You bet'cha they are taking advantage of the fact that people want it.
They would be damn fools in business if they didn't take advantage of that.
And that means supporting it.  It's to their advantage to support it and
they see it.  You must have a really bizzare idea of what support means...

> BSDI is distributing FreeBSD now. They havent done anything useful to 
> support it. They are just cashing in on it.

And your point is???

> DB

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this the ultimate stack-smash fix?

[Alan Cox]

> need fat pointers, which would make sizeof (long) /= sizeof (void *),
> which would break quite some software, I think.

There are plenty of architectures where sizeof long != sizeof (void *). If your
code makes bad assumptions and a bounds checking cc breaks it then its progress.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.1ac17 hang on mounting loopback fs

[Alan Cox]

> # mount -t ext2 -o loop /spare/i486-linuxaout.img /spare/mnt
> loop: enabling 8 loop devices

Loop does not currently work in 2.4. It might partly work by luck but thats it.
This will change as and when the new loop patches go in. Until then if you need
loop use 2.2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SO_SNDTIMEO: 2.4 kernel bugs

[kuznet]

Hello!

> Unfortunately, it seems to be very buggy. Here are two buggy scenarios.


--- ../vger3-010210/linux/net/ipv4/tcp.cSat Feb 10 23:16:51 2001
+++ linux/net/ipv4/tcp.cSat Feb 17 23:27:43 2001
@@ -691,6 +691,8 @@
 
set_current_state(TASK_INTERRUPTIBLE);
 
+   if (!timeo)
+   break;
if (signal_pending(current))
break;
if (tcp_memory_free(sk) && !vm_wait)
--- ../vger3-010210/linux/net/core/sock.c   Tue Jan 30 21:20:16 2001
+++ linux/net/core/sock.c   Sat Feb 17 23:27:44 2001
@@ -727,6 +727,8 @@
clear_bit(SOCK_ASYNC_NOSPACE, >socket->flags);
add_wait_queue(sk->sleep, );
for (;;) {
+   if (!timeo)
+   break;
if (signal_pending(current))
break;
set_bit(SOCK_NOSPACE, >socket->flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Michael H. Warfield]

On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote:
> At 07:10 PM 02/16/2001, [EMAIL PROTECTED] wrote:
> >Dennis wrote:
> >...
> > > objective, arent we?
> >Nope. Are you claiming to be?
> >
> > > For example, if there were six different companies that marketed ethernet
> > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> >... Rant deleted
> >
> >I had a problem with eepro100.
> >It was fixed same night cause I had the source.
> >Don't even try to compare with MickyS**t.


> good commercial drivers dont need fixing. another point. You are arguing 
> that having source is required to fix crappy code, which i agree with.

Then good commercial drivers == blivit.

Ain't no such critter.  They are always late and buggy and then
take forever to get fixed.  Nature of the close source development cycle
with deadlines and project managers that say "we can afford to wait any
longer, we have to ship it now and fix the bugs after release".

> You "guys" like to have source, and there is nothing wrong with that. But 
> requiring that all code be distributed as source DOES stifle innovation. 
> Its as simple as that.

Sorry but it's time to pull it out, smell the air, and buy a clue.
There are people out there right now delivering binary modules and binary
pieces for device drivers in the kernel.  I'm working with one right now.
They are providing partial sources with a binary library (this is the
Lucent WaveLan wvlan2_cs drivers).  Nothing is required.  But binary drivers
don't get the support from the open source people that the open source
drivers get.  Sounds reasonable to me.  There are other binary only drivers
(to say nothing of applications) both freeware and payware out there.  I've
got people working on some myself.  So your arguement that "requiring that
all code be distributed as source DOES stifle innovation" fails on it's
premise because it's NOT REQUIRED.  Just don't expect us to kiss your merry
ass and fall over backwards meeting your demands when you DO deliver a
binary only driver.  If people like it, fine.  If they don't, whose problem
is that?  The idea that nobody will pay for OpenSource software is a myth.
I buy software for Linux all the time.  I buy closed source software and
I buy open source software.  The only difference is the presence of the
sources.  So what.  Tell me how that makes those products less innovative?

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Michael H. Warfield]

On Sat, Feb 17, 2001 at 03:05:36PM -0500, Dennis wrote:
> At 07:01 PM 02/16/2001, Alan Olsen wrote:
> >On Fri, 16 Feb 2001, Dennis wrote:

> > > There is much truth to the concept, although Microsoft should not be ones
> > > to comment on it as such.

> >What truth?  I have seen more "innovation" in the Open Source movement
> >than I ever have in my 18+ years of being a professional programmer.

> You are confusing "progress" with "innovation". If there is only 1 choice, 
> thats not innovation. Expanding on a bad idea, or even a good one, is not 
> innovation.

I think you are obviously the one who is confused.  You are right.
If there is only 1 choice, that's not innovation.  And that's what closed
source is.  Open source is typically castigated because it HAS SO MANY
choices.  We are often overwhelmed by choices.  Sometimes, those choices
narrow through natural selection and evolution, and that's a good thing too.
Close source is the mono-choice.  You take what the vendor gives you and
that's it.  If it doesn't work, tough, wait for the next release cycle
and pay us again to fix our bugs.  That's real innovative.

> Designing something differently to make it better is innovation.  I suppose 
> you could argue that redesigning linux every few  years is innovation, but 
> unfortunately its the same cast of characters doing it, so its not very 
> innovative.

I think I agree with the comment that I've seen more innovation in
the open source movement than anything that has come out of closed source.
One could very safely argue that the entire Internet grew out of a form
of Open Source movement.  Closed source gave us things like EDI and SNA
and SDLC and a host of other proprietary ideas and networks that have been
buried by the Internet.  "Profs" (IBM's idea of E-Mail) was swamped by SMTP.
The Web originated in Open Source.  Entire markets have sprung up where
there was none before out of Open Source.

No...  Close Source and proprietary protocols are then anthema to
BOTH progress and innovation.  When innovation is done in a close arena, it
gets done for closed limited ideas and tightly restricted to what profits
the inventors and nothing more.  It's when it becomes more open that the
real innovation occurs and things are created that the original inventors
never envisioned.

Without Open Source and it's predecessors, we would not have the
Internet as we know it today.  Companies back then (and I worked for
some of them) could not envision a network as we know it now.  Several
of them saw no future what so ever in the "Internet".  One of them even
went so far as to proclaim that Novell was the be all and end all of
networking and nothing would ever amount to anything on this petty worthless
Internet thing.

History has proved them wrong and history has proved that Open
Source is the provider of choices not the limiter of choices.

> DB

> >I don't see how having the source open removes "intelectual property",
> >except by showing that huge portions of the concept are flawed.
> >
> > > For example, if there were six different companies that marketed ethernet
> > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > > with different "features" that were of value to you. Instead, you have
> > > crappy GPL code that locks up under load, and its not worth spending
> > > corporate dollars to fix it because you have to give away your work for
> > > free under GPL. And since there is a "free" driver that most people can
> > > use, its not worth building a better mousetrap either because the 
> > market is
> > > too small. So, the handful of users with problems get to "fit it
> > > themselves", most of whom cant of course.
> >
> >Strange.  I have not heard of any problems with that driver, except for
> >issues where the original hardware vendor kept implimentation details from
> >the open source community.  (Citeing "IP issues".)
> >
> > > Theres also the propensity for mediocre stuff to get into the kernel
> > > because some half-baked programmer was willing to contribute some code. 
> > The
> > > 50% of the kernel that remains "experimental" ad infinitum is evidence 
> > of that.
> >
> >You must be looking at a different kernel.
> >
> >I have seen little in the kernel that was "half baked".  There have been
> >some things put in to test if they were good ideas.  That is far different
> >than half-baked.  Most of the bad ideas never get to the kernel.  Linus or
> >Alan kick them out before they ever get that far.
> >
> > > The biggest thing that the linux community does to stifle innovation is to
> > > bash commercial vendors trying to make a profit by whining endlessly about
> > > "sourceless" distributions and recommending "open-source" solutions even
> > > when they are wholly inferior. You're only hurting yourselves in the long
> > > run. In that respect MS is correct, because those with the dollars to
> > > innovate will stay away.
> >
> 

Re: Linux stifles innovation...

[Alan Olsen]

On Sat, 17 Feb 2001, Dennis wrote:

> At 07:01 PM 02/16/2001, Alan Olsen wrote:
> >On Fri, 16 Feb 2001, Dennis wrote:
> >
> > > There is much truth to the concept, although Microsoft should not be ones
> > > to comment on it as such.
> >
> >What truth?  I have seen more "innovation" in the Open Source movement
> >than I ever have in my 18+ years of being a professional programmer.
> 
> You are confusing "progress" with "innovation". If there is only 1 choice, 
> thats not innovation. Expanding on a bad idea, or even a good one, is not 
> innovation.

"You keep using that word. i don't think it means what you think it
means."

[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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: re. too long mac address for --mac-source netfilter option

[Mr. James W. Laferriere]

Hello All,

On Sat, 17 Feb 2001 [EMAIL PROTECTED] wrote:
> Stefan Hanse writes -
> >Umm..  An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6
>groups, not 14. Is this really an ethernet
> >interface? (If it really has 14 groups).
>
>> Good question. I have determined by scanning my firewall logs that the
>"invalid" mac addresses are all coming from cable modem routers. And my
>linux kernel is recognizing them as being MAC addresses. Would it be
>better to write another module looking for these long "MAC"  rather than
>tamper with the mac module?
>
>> To illustrate, here is a cut from my system log showing a portscan from
>my cable modem provider (a routine part of their service contract since
>you are not allowed to run client-side servers). SRC and DST have been
>x'ed out:
>
>> Feb 17 08:49:42 nonesuch kernel: IN=eth0 OUT=
>MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx
 ^
This appears to be an ATM NSAP address .  Hth ,  JimL

>DST=xx.xx.xx.xx LEN=44 TOS=0x00 PREC=0x00 TTL=246 ID=21419 PROTO=TCP
>SPT=45435 DPT=119 WINDOW=8760 RES=0x00 SYN URGP=0
>> All hits on my firewall from cable modem servers other than my own
>provider also have the 14 group "MAC" address so it looks like this may
>be a feature of these units.

   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[James A. Sutherland]

On Sat, 17 Feb 2001, Michael Bacarella wrote:

> On Sat, Feb 17, 2001 at 02:38:29PM -0500, Dennis wrote:
> > >It's not about facts, it's not about the truth, it's not about Jim
> > >Allchin being an idiot or deluded. It's about propaganda,
> > >misinformation, and marketing. It's about business. Nothing new, nor
> > >unexpected. And to the comment "It is not American to steal", well,
> > >it may not be "American", but it's for sure been part of the way of
> > >doing business in this country for years. It's not right, it's not
> > >ideal, but it IS the way it's done in too many cases.
>
> > Its not a "stealing" issue. Its about whether its worthwhile, dollar-wise,
> > to finance innovation. With free source, its not, because you have to give
> > away  your investment and then anyone can use it equally.
>
> Untrue.
>
> Ogg Vorbis is a perfect example of free software innovation. It is one
> of the most advanced audio codecs available to date. The libraries are
> LGPL'd and the specifications are now and forever public. An audio
> codec is only the beginning.

Yes, Ogg Vorbis is an excellent example.

> The fact that it's freely available and patent unencumbered can only
> be good for it's investors, who happen to be hardware vendors and
> content providers (among others).

It's a shame those investors didn't invest in a WWW site for it: it was
being run on someone's DSL line at home. Their ISP has now folded, leaving
them offline without a site to host www.vorbis.com on...

> Funding free software innovation is only a bad idea if the principle way you
> plan to make money with it is by controlling it's use (such as MP3).

Yes. The people who "developed" CSS had to keep it proprietary because
that was all they had: if they were able and willing to make money by
selling real products for a reasonable price, they wouldn't need
"security" through obscurity and court cases.

> > Secondly, the
> > "open-source" community openly shuns binary distributions (A. Cox never
> > misses an opportunity), so there is no avenue for commercial innovation
> > that is "worthwhile".
>
> As they should. Binary distributions are always inferior.

Not really. Souce availability does not automatically make a piece of
software good, nor does a lack of source make it bad. Having the source
code is a good thing, but it doesn't affect the quality of the software
itself.

> I'm glad to have a binary instead of nothing, but I really should've
> had the foresight to buy better supported hardware.

Yes. I just wish it were a bit easier to determine which hardware that
is...


James.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: System V msg queue bugs in latest kernels

[Manfred Spraul]

Manfred Spraul wrote:
> 
> Mark Swanson wrote:
> >
> > Hello,
> >
> > ipcs (msg) gives incorrect results if used-bytes is above 65536. It
> > stays at 65536 even though messages are being read and removed from the
> > msg queue.
> >

Ok, does the value stay at 65536 or 65535?
It should stay at 65535 if you use a too old version of util-linux.

Please upgrade (see linux/Documentation/Changes)

The proc interface at /proc/sysvipc/msg should report the correct
numbers.

If you want to access values > 65535 from your app you have 2 options:

1) use the new msqid64_ds structure. You must pass IPC_64 to the msgctl
call. This is the only option if you need correct 32-bit uids.
Check the util-linux source, I don't have sample code.
msqid64_ds is only supported by the 2.4 kernel.

2) the old msqid_ds structure also support 32-bit queue length, an
unused field was reused. No support for 32-bit uids.

#define msg_lqbytes __rwait;

I've attached my old sample code.
--
Manfred

/*
 * This code is public domain sample code.
 * Written by Manfred Spraul, 1999
 *
 * The application must be started by root or
 * setuid(root).
 *
 * $Header: /pub/cvs/ms/ipcmsg/longqueue.c,v 1.2 1999/10/09 23:27:54 manfreds Exp $
 */

#include 
#include 
#include 
#include 

/* result codes:
 * 0: success
 * 1: partial success, queue len now USHORT_MAX
 * 100: invalid parameters.
 * 101: other error
 * 256: fatal error, please delete the queue: queue len now 0.
 */

#define USHORT_MAX  0xFFff
struct queuelen {
int llen;
unsigned short slen;
};

struct msqid_ds g_q;

#define msg_lqbytes __rwait
void failure(char* msg)
{
printf(" unexpected error in %s.\n",msg);
exit(101);
}

int init_ipc(int id)
{
int res;

res = msgget(id,0);
if(res == -1)
failure("findkey()");
id = res;
res = msgctl(id,IPC_STAT,_q);
if(res == -1)
failure("init_ipc()");
return id;
}

void get_queuelen(int id,
struct queuelen *out)
{
int res;
struct msqid_ds q;

res = msgctl(id,IPC_STAT,);
if(res == -1)
failure("get_queuelen()");
out->llen = q.msg_lqbytes;
out->slen = q.msg_qbytes;
}

int set_queuelen(int id, int len)
{
struct msqid_ds q;

memcpy(,_q,sizeof(q));
if(len > USHORT_MAX) {
q.msg_qbytes = 0;
q.msg_lqbytes = len;
} else
{
q.msg_qbytes = len;
}
return msgctl(id,IPC_SET,);
}

int main(int argc,char** argv)
{
int id;
int len;
struct queuelen prev;
struct queuelen new;

printf("longqueue  \n");
if(argc != 3) {
printf("Invalid parameters.\n");
return 100;
}
id = atoi(argv[1]);
len = atoi(argv[2]);
if(len <= 0) {
printf("Invalid parameters.\n");
return 100;
}
id = init_ipc(id);
get_queuelen(id,);
if(set_queuelen(id,len) == -1)
failure("set_queuelen()");
if(len <= USHORT_MAX) {
out_success:
get_queuelen(id,);
printf(" new queuelen: (%d,%d).\n",prev.slen,prev.llen);
return 0;
}
/* the old Linux ipcmsg code doesn't support
 * long queues. It interprets this as "queue len 0".
 * Check for this, and try USHORT_MAX, then the original
 * value.
 */
get_queuelen(id,);
if(new.slen != 0)
goto out_success;

if(set_queuelen(id,USHORT_MAX) == -1) {
if(set_queuelen(id,prev.slen) == -1) {
printf(" fatal error. queue len now 0.\n");
return 256;
};
failure("set_queuelen()");
}
get_queuelen(id,);
printf(" new queuelen: (%d,%d).\n",prev.slen,prev.llen);
return 1;
}

Re: SMP: bind process to cpu

[Tim Hockin]

> Is it possible to bind a process to a specific
> cpu on this SMP machine (process affinity) ?
> 
> I there something like pset ?

http://isunix.it.ilstu.edu/~thockin/pset  - pset for linux-2.2 (not ported
to 2.4 yet)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[James A. Sutherland]

On Sat, 17 Feb 2001, Dennis wrote:

> At 07:01 PM 02/16/2001, Alan Olsen wrote:
> >On Fri, 16 Feb 2001, Dennis wrote:
> >
> > > There is much truth to the concept, although Microsoft should not be ones
> > > to comment on it as such.
> >
> >What truth?  I have seen more "innovation" in the Open Source movement
> >than I ever have in my 18+ years of being a professional programmer.
>
> You are confusing "progress" with "innovation".

Not necessarily: both exist in open source projects.

> If there is only 1 choice, thats not innovation.

You are confusing "innovation" with "competition".

> Expanding on a bad idea, or even a good one, is not innovation.

Correct. Having the idea in the first place is innovation.

> Designing something differently to make it better is innovation.  I suppose
> you could argue that redesigning linux every few  years is innovation, but

Not really. Changing Linux to take advantage of some new concept would be
innovation. Adding a new feature would be innovation.

> unfortunately its the same cast of characters doing it, so its not very
> innovative.

There is no need for innovation to involve different/new PEOPLE, just new
IDEAS.


James.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation... [way O.T.]

[Dennis]

At 05:59 PM 02/16/2001, John Cavan wrote:
>Dennis wrote:
> > objective, arent we?
>
>You might ask yourself the same question...
>
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > with different "features" that were of value to you. Instead, you have
> > crappy GPL code that locks up under load, and its not worth spending
> > corporate dollars to fix it because you have to give away your work for
> > free under GPL. And since there is a "free" driver that most people can
> > use, its not worth building a better mousetrap either because the market is
> > too small. So, the handful of users with problems get to "fit it
> > themselves", most of whom cant of course.
>
>A large bulk of the investment in Linux is starting to come in from
>hardware manufacturers, notably IBM. These companies see Linux as a
>means to sell more hardware, not as a means to sell software. This is
>critical, because it means that it IS worth the money to make the driver
>perform correctly, GPL or not, because a bad driver means no sales.


Thats wrong. The eepro100 is a great example. It works for most people, so 
the market for an improved one is very limited. Your market is not the 
whole community, only the community that needs something better. IBM will 
simply blame linux if it cant handle a situation. They arent supporting 
linux, they are only taking advantage of the fact that people want it.

BSDI is distributing FreeBSD now. They havent done anything useful to 
support it. They are just cashing in on it.

DB


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Dennis]

At 07:01 PM 02/16/2001, Alan Olsen wrote:
>On Fri, 16 Feb 2001, Dennis wrote:
>
> > There is much truth to the concept, although Microsoft should not be ones
> > to comment on it as such.
>
>What truth?  I have seen more "innovation" in the Open Source movement
>than I ever have in my 18+ years of being a professional programmer.

You are confusing "progress" with "innovation". If there is only 1 choice, 
thats not innovation. Expanding on a bad idea, or even a good one, is not 
innovation.

Designing something differently to make it better is innovation.  I suppose 
you could argue that redesigning linux every few  years is innovation, but 
unfortunately its the same cast of characters doing it, so its not very 
innovative.

DB




>I don't see how having the source open removes "intelectual property",
>except by showing that huge portions of the concept are flawed.
>
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > with different "features" that were of value to you. Instead, you have
> > crappy GPL code that locks up under load, and its not worth spending
> > corporate dollars to fix it because you have to give away your work for
> > free under GPL. And since there is a "free" driver that most people can
> > use, its not worth building a better mousetrap either because the 
> market is
> > too small. So, the handful of users with problems get to "fit it
> > themselves", most of whom cant of course.
>
>Strange.  I have not heard of any problems with that driver, except for
>issues where the original hardware vendor kept implimentation details from
>the open source community.  (Citeing "IP issues".)
>
> > Theres also the propensity for mediocre stuff to get into the kernel
> > because some half-baked programmer was willing to contribute some code. 
> The
> > 50% of the kernel that remains "experimental" ad infinitum is evidence 
> of that.
>
>You must be looking at a different kernel.
>
>I have seen little in the kernel that was "half baked".  There have been
>some things put in to test if they were good ideas.  That is far different
>than half-baked.  Most of the bad ideas never get to the kernel.  Linus or
>Alan kick them out before they ever get that far.
>
> > The biggest thing that the linux community does to stifle innovation is to
> > bash commercial vendors trying to make a profit by whining endlessly about
> > "sourceless" distributions and recommending "open-source" solutions even
> > when they are wholly inferior. You're only hurting yourselves in the long
> > run. In that respect MS is correct, because those with the dollars to
> > innovate will stay away.
>
>You claim that "open source solutions are wholely inferior to closed
>source solutions".
>
>H...
>
>Then why does everyone run with Apache instead of IIS?  Could it be that
>IIS is a piece of crap?
>
>Feature for feature I would rather use PHP 4 over ColdFusion any day.
>
>Sendmail is MUCH more stable than Exchange.  (Even if it has config files
>that look like they were designed by Carlos Castanada on a bad day.) If
>not Sendmail, there are a couple of other Open Source mail programs that
>are much superior in quality than the closed source counterparts.
>
>As for the Linux kernel being "shoddy"...
>
>Since when?
>
>I can leave my Linux box running over night and actually have it do
>things!  I cannot say the same for Windows.  I leave that running (same
>hardware, different OS) and it is usually dead by dawn.
>
>But your argument is even more bogus than that.
>
>It seems that you argument boils down to a couple of thing...
>
>"Closed source is better because you pay money for it."
>
>"Closed source is superior because we have a company name and you don't."
>
>Sorry, but most of the people who develop Open Source are profesional
>programmers.  They just have a different motivation.
>
>Open Source is motivated by pride in what you can do and a desire to help
>others by sharing that. They don't hide behind a wall of lawyers to keep
>people from finding out what they did wrong.
>
>I found out a long time ago that most "Trade Secret" claims were bogus.
>It was either a common technique that had been adapted to a particular
>purpose or it was being used as an excuse to hide how bad the code really
>was.
>
>But my experiences with Open Source, as well as the others I know who use
>it are quite telling.
>
>If I have a problem with an Open Source program I can look at the code and
>fix it.  Or I can report the bug and it will get fixed soon after. The
>programmers involved put the effort into it because their name is
>attached.
>
>My experiences with closed source companies are not as good.
>
>In many cases, I was ignored because I did not represent a fortune 500
>company.  If the problem got fixed at all, it would be months before I saw
>it and usually in a later release that I would have to pay for.  (Usually
>having features 

Re: Linux stifles innovation...

[Dennis]

At 07:10 PM 02/16/2001, [EMAIL PROTECTED] wrote:
>Dennis wrote:
>...
> > objective, arent we?
>Nope. Are you claiming to be?
>
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
>... Rant deleted
>
>I had a problem with eepro100.
>It was fixed same night cause I had the source.
>Don't even try to compare with MickyS**t.


good commercial drivers dont need fixing. another point. You are arguing 
that having source is required to fix crappy code, which i agree with.

You "guys" like to have source, and there is nothing wrong with that. But 
requiring that all code be distributed as source DOES stifle innovation. 
Its as simple as that.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Michael Bacarella]

On Sat, Feb 17, 2001 at 02:38:29PM -0500, Dennis wrote:
> >It's not about facts, it's not about the truth, it's not about Jim
> >Allchin being an idiot or deluded. It's about propaganda,
> >misinformation, and marketing. It's about business. Nothing new, nor
> >unexpected. And to the comment "It is not American to steal", well,
> >it may not be "American", but it's for sure been part of the way of
> >doing business in this country for years. It's not right, it's not
> >ideal, but it IS the way it's done in too many cases.
 
> Its not a "stealing" issue. Its about whether its worthwhile, dollar-wise, 
> to finance innovation. With free source, its not, because you have to give 
> away  your investment and then anyone can use it equally.

Untrue.

Ogg Vorbis is a perfect example of free software innovation. It is one
of the most advanced audio codecs available to date. The libraries are
LGPL'd and the specifications are now and forever public. An audio
codec is only the beginning.

The fact that it's freely available and patent unencumbered can only
be good for it's investors, who happen to be hardware vendors and
content providers (among others).

Funding free software innovation is only a bad idea if the principle way you
plan to make money with it is by controlling it's use (such as MP3).

> Secondly, the 
> "open-source" community openly shuns binary distributions (A. Cox never 
> misses an opportunity), so there is no avenue for commercial innovation 
> that is "worthwhile".

As they should. Binary distributions are always inferior. I'm glad to
have a binary instead of nothing, but I really should've had the
foresight to buy better supported hardware. 


-- 
Michael Bacarella <[EMAIL PROTECTED]>
Technical Staff / System Development,
New York Connect.Net, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SMP: bind process to cpu

[Francis Galiegue]

On Sat, 17 Feb 2001, Thomas Widmann wrote:

> 
> #cat /proc/1310/cpus_allowed
> 
> 
> Now, if i want to run this process on only one cpu, i which way
> do i have to set the bitmask ?
> Let's say, i want to run it on cpu0. how look's the bitmask ?
> 

Wild guess: as this is a bitmask, you must "or" the bitmask with (1 <<
cpu_number). 1 for CPU 0 only, 5 for CPU 0 and 2, etc, etc.

-- 
Francis Galiegue, [EMAIL PROTECTED] - Normand et fier de l'être
"Programming is a race between programmers, who try and make more and more
idiot-proof software, and universe, which produces more and more remarkable
idiots. Until now, universe leads the race"  -- R. Cook

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[help] _syscall2 fails with -fPIC

[Mark Swanson]

Hello,

I am building a -fPIC shared object that will define and access a Linux
kernel system call, but _syscall2 fails with -fPIC .so compilation.
What can I do?
 
F.E. the statement:
 
_syscall2 (int, tux, unsigned int, action, user_req_t *, req)
 
Gives the following gcc error when compiled with -fPIC:
 
tst.c: In function `tux':
tst.c:62: Invalid `asm' statement:
tst.c:62: fixed or forbidden register 3 (bx) was spilled for class
BREG.

If the -fPIC isn't there it compiles fine. Unfortunately I need to find
another way as I have to use -fPIC.

Thanks in advance for any suggestions.


=
A camel is ugly but useful; it may stink, and it may spit, but it'll get you where 
you're going. - Larry Wall -

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

re. too long mac address for --mac-source netfilter option

[jbinpg]

Jack  Bowling wrote -

>> I am trying to use the --mac-source option in the netfilter code to better refine 
>access to my linux box. However, I > have run up against something. The router 
>through which my private subnet work box passes sends a 14-group "invalid" > mac 
>address, presumably as an attempt to conceal the real hextile mac address. However, 
>the code for the > --mac-source netfilter option is looking for a valid hextile mac 
>address and complains loudly as such (numerals converted to x's):
>> 
>> iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
>> 
>> to the respective iptable line:
>> 
>> $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source 
>xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT
>> 
>> The idea here is to allow VNC access to my home box with the access filtered by 
>both IP and mac address.
>> 
>> Is there a resolution to this other than a rewrite and recompile of the relevant 
>sections of the iptable code? Or am I stuck? I know this option is tagged by Rusty as 
>experimental still so I would assume that the code is open for feedback ;) The 
>question could be rephrased as: is there any chance of allowing "invalid" mac 
>addresses to be recognized by the --mac-source option of the netfilter code? Running 
>Redhat v7/kernel 2.4.1-ac15.

Stefan Hanse writes -

>Umm..  An ethernet MAC address is 48bit long, ie AA:BB:CC:DD:EE:FF, 6 groups, not 14. 
>Is this really an ethernet
>interface? (If it really has 14 groups).

Good question. I have determined by scanning my firewall logs that the "invalid" mac 
addresses are all coming from cable modem routers. And my linux kernel is recognizing 
them as being MAC addresses. Would it be better to write another module looking for 
these long "MAC"  rather than tamper with the mac module? 

To illustrate, here is a cut from my system log showing a portscan from my cable modem 
provider (a routine part of their service contract since you are not allowed to run 
client-side servers). SRC and DST have been x'ed out:

Feb 17 08:49:42 nonesuch kernel: IN=eth0 OUT= 
MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=44 
TOS=0x00 PREC=0x00 TTL=246 ID=21419 PROTO=TCP SPT=45435 DPT=119 WINDOW=8760 RES=0x00 
SYN URGP=0 
Feb 17 08:49:43 nonesuch kernel: IN=eth0 OUT= 
MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=40 
TOS=0x00 PREC=0x00 TTL=246 ID=21420 PROTO=TCP SPT=45435 DPT=119 WINDOW=8760 RES=0x00 
RST URGP=0 
Feb 17 08:49:43 nonesuch kernel: IN=eth0 OUT= 
MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=44 
TOS=0x00 PREC=0x00 TTL=246 ID=21421 PROTO=TCP SPT=45806 DPT=119 WINDOW=8760 RES=0x00 
SYN URGP=0 
Feb 17 08:49:43 nonesuch kernel: IN=eth0 OUT= 
MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=40 
TOS=0x00 PREC=0x00 TTL=246 ID=21422 PROTO=TCP SPT=45806 DPT=119 WINDOW=8760 RES=0x00 
RST URGP=0 
Feb 17 08:49:43 nonesuch kernel: IN=eth0 OUT= 
MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=44 
TOS=0x00 PREC=0x00 TTL=246 ID=21423 PROTO=TCP SPT=46248 DPT=119 WINDOW=8760 RES=0x00 
SYN URGP=0 
Feb 17 08:49:44 nonesuch kernel: IN=eth0 OUT= 
MAC=00:01:02:69:49:4f:00:00:77:93:83:d2:08:00 SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=40 
TOS=0x00 PREC=0x00 TTL=246 ID=21424 PROTO=TCP SPT=46248 DPT=119 WINDOW=8760 RES=0x00 
RST URGP=0 

All hits on my firewall from cable modem servers other than my own provider also have 
the 14 group "MAC" address so it looks like this may be a feature of these units.

Jack

P.S. - I have moved this to another of my email accounts



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: System V msg queue bugs in latest kernels

[Mark Swanson]

The exact error is in /usr/include/linux/msg.h

The three unsigned shorts should be unsigned int instead.
Would too many things break if this was changed?
Should user-space tools like ipcs be rewritten to use /proc/sysvipc
instead? (I notice that my old 2.2.14 kernel doesn't have
/proc/sysvipc...)

Thanks.

/* one msqid structure for each queue on the system */
struct msqid_ds {
struct ipc_perm msg_perm;
struct msg *msg_first;  /* first message on queue */
struct msg *msg_last;   /* last message in queue */
__kernel_time_t msg_stime;  /* last msgsnd time */
__kernel_time_t msg_rtime;  /* last msgrcv time */
__kernel_time_t msg_ctime;  /* last change time */
struct wait_queue *wwait;
struct wait_queue *rwait;
unsigned short msg_cbytes;  /* current number of bytes on queue */
unsigned short msg_qnum;/* number of messages in queue */
unsigned short msg_qbytes;  /* max number of bytes on queue */
__kernel_ipc_pid_t msg_lspid;   /* pid of last msgsnd */
__kernel_ipc_pid_t msg_lrpid;   /* last receive pid */
}; 




=
A camel is ugly but useful; it may stink, and it may spit, but it'll get you where 
you're going. - Larry Wall -

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Francois Romieu]

Dennis <[EMAIL PROTECTED]> écrit :
[...]
> When is that specification for 2.4 drivers going to be available? Talk 
> about "stifling the marketplace"!!! Vendors cant even write reliable 
> drivers if they want to.

May be said vendors should give a look at l-k between 2.2 and 2.4 instead
of spending their time ranting at low quality of source code on l-k, 
FreeBSD-hackers and elsewhere, shouldn't they ?

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Linux stifles innovation...

[Dennis]

At 08:34 PM 02/16/2001, Neal Dias wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>It's not about facts, it's not about the truth, it's not about Jim
>Allchin being an idiot or deluded. It's about propaganda,
>misinformation, and marketing. It's about business. Nothing new, nor
>unexpected. And to the comment "It is not American to steal", well,
>it may not be "American", but it's for sure been part of the way of
>doing business in this country for years. It's not right, it's not
>ideal, but it IS the way it's done in too many cases.


Its not a "stealing" issue. Its about whether its worthwhile, dollar-wise, 
to finance innovation. With free source, its not, because you have to give 
away  your investment and then anyone can use it equally. Secondly, the 
"open-source" community openly shuns binary distributions (A. Cox never 
misses an opportunity), so there is no avenue for commercial innovation 
that is "worthwhile".

Dennis


>Neal Dias
>UNIX Systems Administrator, Sunglass Hut International, MIS Dept.
>office: (305) 648-6479  wk. email:[EMAIL PROTECTED]
>mobile: (786) 368-5742  pvt. email:[EMAIL PROTECTED]
>**
>Whoever fights monsters should see to it that in the process he does
>not become a monster. And when you look into an abyss, the abyss also
>looks into you. -Nietzsche
>
>Any opinions expressed above or below are entirely my own and may not
>reflect those of my employers. The information contained in this
>e-mail message is confidential, intended only for the receipt and use
>of the individual(s) or entity(s) named above. If the reader of this
>email message is not the intended recipient, or the employee or agent
>responsible for its delivery to the intended and or addressed
>recipient, you are hereby notified that any review, dissemination,
>distribution or copying of this communication is strictly prohibited
>except at the express consent of its author.
>
>-BEGIN PGP SIGNATURE-
>Version: PGPfreeware 6.5.8 for non-commercial use 
>
>iQA/AwUBOo3VDsUVRGLQ1PaaEQKnWwCcCb+J3BbV/AQLCB20mzLn/1e8HmkAoK+u
>zXoDl5pPc5Z1uihfhOMrQy+I
>=wE+Z
>-END PGP SIGNATURE-
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ingo's RAID patch for 2.2.18 final?

[Andrea Arcangeli]

On Fri, Feb 16, 2001 at 10:53:51AM -0500, David Mansfield wrote:
> This may be a bit OT, but when you say O_DIRECT, that implies that you
> can pass that flag to open(2) and it will bypass the page cache, and

yes.

> read directly into user-space buffers (zero-copy IO)?  Does this also

yes.

> bypass the read-ahead mechanisms in the kernel?  Does it imply O_SYNC?

yes.

It's rawio through the fs. It's not included into 2.4-latest yet.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: System V msg queue bugs in latest kernels

[Mark Swanson]

You are right.
/proc/sysvipc/msg is correct. It shows:
cbytes: 1048575
qnum: 95325

ipcs shows:
used-bytes: 65535
messages: 65535

It's a 16-bit number issue.

--- Manfred Spraul <[EMAIL PROTECTED]> wrote:
> Mark Swanson wrote:
> > 
> > Hello,
> > 
> > ipcs (msg) gives incorrect results if used-bytes is above 65536. It
> > stays at 65536 even though messages are being read and removed from
> the
> > msg queue.
> >
> I'm testing it.
> 
> Could you check /proc/sysvipc/msg?
> 
> I know that several API's have 16-bit numbers, perhaps wrong values
> are
> returned to user space.
> 
> --
>   Manfred


=
A camel is ugly but useful; it may stink, and it may spit, but it'll get you where 
you're going. - Larry Wall -

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LONG RANT] Re: Linux stifles innovation...

[Jacob Luna Lundberg]

> Speaking as a Linux _USER_, if this happens, can I get said print
> engine working on my ARM machines with these closed source drivers?
> Can Alpha users get this print system working?  Can Sparc uses
> get it working?  What?  I can't?  They can't?  Well, its no good to
> me nor them.  You've just made the system x86 specific.  Well done,
> thats a step backwards, not forwards.

Just out of curiosity, why can't the specification be along the lines of a
vendor data file saying ``if you want the printer to do x then say y'' and
``if the printer says x then it means y''.  That ought to add a lot of
functionality right there.  Sure there are evil winprinters that this
wouldn't be enough for but it would be hardware independant, yes?

Or alternatively what about getting vendors to release their source to a
middleman as a trade secret?  The middleman could then release binaries
for the various arches...  Distasteful, but I'd love to be able to use
*all* the features of my Lexmark OptraColor 45...  ;)

-Jacob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P . Schmiedehausen]

On Sat, Feb 17, 2001 at 01:37:58PM +, Russell King wrote:

> Henning P. Schmiedehausen writes:
> > But at least I would be happy if there would be a printing
> > engine that is entirely open source and all the printer vendors can
> > write a small, closed source stub that drives their printer over
> > parallel port, ethernet or USB and give us all the features, that the
> > Linux _USERS_ (and these are the people that count) want.
> 
> Speaking as a Linux _USER_, if this happens, can I get said print
> engine working on my ARM machines with these closed source drivers?
>
> Can Alpha users get this print system working?  Can Sparc uses
> get it working?  What?  I can't?  They can't?  Well, its no good to
> me nor them.  

Maybe not. But you can use this print engine API to pay anyone to
write a driver for you. What you just said, is exactly my point. You
said:

"If a company does not write a driver which works on all hardware
 platforms in all cases and gives us the source, then it is better,
 that the company writes no drivers at all."

"If I can't force a company to write a driver for everyone, then I
 don't want to write them any driver at all."

IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

> You've just made the system x86 specific.  Well done, thats a step
> backwards, not forwards.

No. Some Linux users got a driver that works as well as the drivers
for another OS. This is good for Linux. And all Linux users and
developers got an open, stable API, which is supported by big printer
vendors and enables everyone to write good drivers.

If you need a printer driver for the ARM, you're able to approach the
company XXX and either pay for an ARM specific driver (and they will
listen to you because they already have made a driver for another
Linux platform, learned that they can make money with Linux software
and have experience with driver(s) for Linux. And it will be just a
recompile most of the time).

> Ah, golly, I'll just have to throw my ARM machines away because
> we have some critical parts of the system which are closed source.

We're talking about a driver. If Company XX won't sell it to you for
your architecture, it's their right to do so. There is software that
I've written that you might want to have, too. If I chose not to sell
it to you, what do you do? You can say "company XX sucks" and buy an
equal product with an ARM driver from YY which listens to you. _THAT_
is IMHO open. Not forcing everyone to comply with your ideology.

> > But even if there is such an engine written for Gnome or KDE, some
> > really ingenious "free software advocate" will slap a "must not be
> > used with any kind of non-GPL driver" on it...
> 
> Good.  I build the stuff to work on my ARM machines.

Can you get a Legato Networker Client for Linux-ARM? Can you get one for
Linux-MIPS? Why? Because someone payed for the port.

> They don't work on ARM though, do they?  Gee, I guess ARM Ltd ought to
> stop my contract because what use is an ARM kernel without everything
> else to go with it?
> 
> For me, closed source is _REALLY_ bad news.  _EXTREMELY_ bad news.
> It 100% prevents me from doing stuff.

No. It means, that for some programs, in order to have them, you have
to pay. That is fine. There ain't no such thing as a free lunch. You
may, of course, chose not to pay, but then you may not be able to use
a certain program.

Look, I'm willing to pay money for the whole M$ Office Suite on
Linux. Yes.  I would give billg gladly a big chunk of my money to get
this application suite on Linux. Not a copy or a "just almost like M$
Office". But the real thing. The real "M$ Office 2k" suite for Linux.

Can I?  No. Because M$ chose not to offer its product for Linux. Bad
for me. It means, that I can not get parts of my work done on Linux.
Can I buy AutoCAD? Photoshop? Quicken? Outlook? Visio? Not look alikes
or clones or "almost as good as". But the real thing with the same
support as on Windows. I can for the Mac. Why can't I for Linux?

Because IMHO some companies shy away from the aggressive and sometime
openly hostile behaviour of the Open Source community ("If you don't
support your application on Linux/SPARC with an B/W framebuffer, you
suck. Go away") towards commercial companies.  ("If you don't support
Gnome 1.0 but just KDE 2.1, you suck. Go away"). And billg laughs and
just points the confused companies towards the "stable" and "easy to
use" M$ OS.

And the volatile APIs which are immature in some points (Font handling. 
Printer support. Color handling. Same things all the time. But displaying 
the results of your work and printing them onto paper is for many
people the most important thing. And frankly, Linux sucks here).

In your opinion, it is better, that I can't get some programs at all
than paying money for them.

In my opinion, I prefer to get it at least for i386/Linux than not to
get them at all. Because if I can't get them for i386/Linux, I must
get them for 

Re: Linux stifles innovation...

[Dennis]

At 05:31 PM 02/16/2001, Dan Hollis wrote:
>On Fri, 16 Feb 2001, Dennis wrote:
> > The biggest thing that the linux community does to stifle innovation is to
> > bash commercial vendors trying to make a profit by whining endlessly about
> > "sourceless" distributions and recommending "open-source" solutions even
> > when they are wholly inferior. You're only hurting yourselves in the long
> > run. In that respect MS is correct, because those with the dollars to
> > innovate will stay away.
>
>So I take it you support M$ on the legislation bit also...


No. You conveniently snipped the part where I said that Microsoft is not 
one to talk. They "stifle the market" in other ways, like not completely 
documenting the OS for their own advantage.

DB


>-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Mohammad A. Haque]

I'm using these drivers just fine on a couple of streaming servers that
get hit pretty hard.

Dennis wrote:
> both lock up under load. You dont run a busy ISP i guess. The fact that
> they come out with a new release every few minutes is clear evidence that
> it is problematic.

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SMP: bind process to cpu

[Thomas Widmann]

Hi,

* Andrew Morton wrote:

> > Hi,
> > 
> > I run an 3*XEON 550MHz Primergy with 2GB of RAM.
> > On this machine, i have compiled kernel 2.4.0SMP.
> > 
> > Is it possible to bind a process to a specific
> > cpu on this SMP machine (process affinity) ?
> > 
> > I there something like pset ?
> 
> A patch which creates /proc//cpus_allowed is at
> 
>   http://www.uow.edu.au/~andrewm/linux/#cpus_allowed
> 
> You just write a bitmask into it.

Thanks for this information. I patched my the kernel with it.
After rebooting with the new kernel i can see the bitmask
for every process running on my server.

#cat /proc/1310/cpus_allowed


Now, if i want to run this process on only one cpu, i which way
do i have to set the bitmask ?
Let's say, i want to run it on cpu0. how look's the bitmask ?

Thanks 

Regards
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] APMD on Linux 2.2.18 and include/linux/mc146818rtc.h

[Marc Esipovich]

I've noticed this when attempting to build APMD, mc146818rtc.h has
a reference to a spinlock_t while asm/spinlock.h is not included.

Patch follows:

--- linux-2.2.18.orig/include/linux/mc146818rtc.hFri Jan 12 19:15:00 2001
+++ linux-2.2.18/include/linux/mc146818rtc.h   Tue Feb 20 01:17:09 2001
@@ -11,6 +11,7 @@
 #ifndef _MC146818RTC_H
 #define _MC146818RTC_H
 #include 
+#include 

 #ifndef RTC_PORT
 #define RTC_PORT(x)(0x70 + (x))


bye,
Marc.

--
marc @ corky.net

fingerprint = D1F0 5689 967F B87A 98EB  C64D 256A D6BF 80DE 6D3C

  /"\
  \ / ASCII Ribbon Campaign
   X  Against HTML Mail
  / \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: System V msg queue bugs in latest kernels

[Manfred Spraul]

Mark Swanson wrote:
> 
> Hello,
> 
> ipcs (msg) gives incorrect results if used-bytes is above 65536. It
> stays at 65536 even though messages are being read and removed from the
> msg queue.
>
I'm testing it.

Could you check /proc/sysvipc/msg?

I know that several API's have 16-bit numbers, perhaps wrong values are
returned to user space.

--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Dennis]

>
>Fortunately despite your best efforts there is now a choice in 2.4

When is that specification for 2.4 drivers going to be available? Talk 
about "stifling the marketplace"!!! Vendors cant even write reliable 
drivers if they want to.

db

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Dennis]

At 05:20 PM 02/16/2001, Alan Cox wrote:
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > with different "features" that were of value to you. Instead, you have
> > crappy GPL code that locks up under load, and its not worth spending
>
>Umm I find the driver very reliable. And actually I have choice of two
>eepro100 drivers eepro100.c and e100.c so you cant even pick an example.

both lock up under load. You dont run a busy ISP i guess. The fact that 
they come out with a new release every few minutes is clear evidence that 
it is problematic.

Intel doesnt sell the e100.o driver, so they couldnt give a rats ass if it 
doesnt perform. Note that the DO sell the drivers for other platforms, and 
they support them, a win for the other platforms.

DB

Emerging Technologies, Inc.
-


http://www.etinc.com
ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX
Multiport T1 and HSSI/T3 UNIX-based Routers
Bandwidth Management Standalone Systems
Bandwidth Management software for LINUX and FreeBSD

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LONG RANT] Re: Linux stifles innovation...

[Jonathan Morton]

>Henning P. Schmiedehausen writes:
>> But at least I would be happy if there would be a printing
>> engine that is entirely open source and all the printer vendors can
>> write a small, closed source stub that drives their printer over
>> parallel port, ethernet or USB and give us all the features, that the
>> Linux _USERS_ (and these are the people that count) want.
>
>Speaking as a Linux _USER_, if this happens, can I get said print
>engine working on my ARM machines with these closed source drivers?
>Can Alpha users get this print system working?  Can Sparc uses
>get it working?  What?  I can't?  They can't?  Well, its no good to
>me nor them.  You've just made the system x86 specific.  Well done,
>thats a step backwards, not forwards.
>
>Oh please nice big corporation, can you please build said closed
>source stub for ARM?  No?  Why?  You don't see the point?
>
>Ah, golly, I'll just have to throw my ARM machines away because
>we have some critical parts of the system which are closed source.



I have similar, though less acute, problems with PowerPC.  Because it's
seen as a "smaller market", less work is done on it and less closed-source
software makes it's way onto it.  Try to download a PowerPC version of
Netscape (4.x, not 6) - all you'll find are the MacOS versions, nothing for
Linux.  Fortunately, distro makers manage to have extracted one for
themselves.

As for 680x0...  well I'd love to have been able to use my old Quadra 840av
as a router/firewall/server, but nobody knows how the *hardware* works well
enough to get either Linux or NetBSD working properly on it.  So I wind up
using it as an IRC bot and scanner station, using the old, now unsupported
MacOS 8.1, which will never have it's bugs fixed because Apple considers
ancient hardware not worth it's while.  Fortunately it works well enough
for the job, and I don't have to complain too loudly about it, which is
more than I could say about any (especially recent) Micro$oft product.

Even on x86 I have problems.  I just bought ATI's flashiest new graphics
card - the All-in-Wonder Radeon - and installed it into my "workstation"
PC, which just happens to also have a Win95 partition.  With a little
fiddling, I get the 2D and 3D output features running smoothly, if not yet
optimally, under the latest version of XFree86 and the Linux kernel.  Much
the same goes for the Windows drivers.

Then I start looking for the software to drive the "extra" features, such
as the TV/video input/capture stuff, which is what distinguishes the
All-in-Wonder from the regular Radeon (and which makes it cost 2x as much).
I'll probably eventually find the right drivers for Linux - I know they
exist, if in uncompleted form - but so far I have not found them on the ATI
CDs bundled with the card!  There's a video-editing package bundled, but it
can't do anything without the right driver.

Then I try to run the Video CDs - supposedly in DVD format - and I get
errors about "wrong region code" with no way of changing the region code or
working out which region code I even need, and then the "DVD Player"
crashes Windows solid.  So much for the RIAA and closed source...

So, I have 9 computers in my bedroom.  The Macs (mostly) run MacOS.  The
PCs (mostly) run Linux.  Strange that one of the Linux machines (the most
underpowered and overworked one) has an uptime exceeding 100 days, whereas
I've never had even 4 weeks out of any of the Macs despite the "higher
quality hardware" argument.

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-END GEEK CODE BLOCK-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Henning P . Schmiedehausen]

On Sat, Feb 17, 2001 at 02:58:45PM +0100, Jean Francois Micouleau wrote:
> 
> On Sat, 17 Feb 2001, Henning P. Schmiedehausen wrote:
> 
> > If IBM, Intel, Compaq, HP, Dell, SGI and other companies would
> > wholeheartedly drop their Windows support in favour of Linux, that I
> > would call "a move". If HP would spent only 5% of their driver writing
> > buget for Windows into Linux driver development, that I would call "a
> > move". 
> 
> I'm wondering if the $600 000 HP gave to VA linux and myself last year is
> only 5% of their driver budget.

> Henning, HP is supporting linux and the open source movement. They are
> paying people to port linux to the ia64 platform and the hp-pa risc.

Yes. They want to sell the IA64 and the HP-PA hardware. So it is
logically for them to fund people and companies that port the kernel
or build OS software for their hardware.

> They are supporting the open source movement by paying people like me to
> improve Samba.

Yes. They want to sell products which use this special piece of software.

I don't see HP supporting software authors to write CD-ROM burning
software for all CDROM writers just to be able to bundle Linux
software with their CDROM writers [just watching an HP commercial on
TV].

IMHO, this is no "basic change in company policy". HP and many other
companies understood that they have two ways to conduct their business
in the future: Being dependent on a company that dictates how to write
software, being forced to live with the way that company wants future
products to be and the fact that this company will always have an edge
over their competitors. Or the will support open _protocols_ like
CORBA, TCP/IP, XML and the like to keep their closed source products
working on many (especially their own) platforms and avoid the
strangle hold of a single company.

Linux is ideal for them because no company has "a grip" on the OS. 
This is good!

But is it "commitment to open source"? Or just "keeping all options
open"? Because these companies still support their products on M$. 

Most of the programs are in newer, larger and more mature versions for
Windows. Why? Did you ever try to write a non-web based GUI program
for Linux? For which Linux? Which desktop (besides using statically
linked motif applications or bare metal X11)? Which version of the
desktop? What tools do you get? How mature are the tools, especially
GUI builders and IDEs? Most developers in bigger companies are not
kernel wizards but just average run-of-the-mill-have-a-grip-on-c++
developers who code after specs.

Most companies simply use Java and leave the details to the VM. If you
write for Windows, you have an ugly and complicated API with lots of
bugs, but the API itself is stable since six (!) years.  You can write
programs that run on 95/98/ME/NT/2000 unchanged. Writing them sucks
but it is possible. For Linux to do so, you must use almost bare X11.

Don't get me wrong. I am _happy_ that there are big companies
recognizing, funding and supporting Linux. But then it is for Linux to
grow mature and recognize that these companies don't do it because
they think "Linux is cool". They do it because they think "Linux is
business. Linux is profit. Linux helps us to avoid the strangle hold
of M$" No news here. No basic direction change here. They do Windows
and anything else for exactly the same reasons.

And they don't do desktop applications besides java applications and
Web stuff.

Regards
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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

System V msg queue bugs in latest kernels

[Mark Swanson]

Hello,

ipcs (msg) gives incorrect results if used-bytes is above 65536. It
stays at 65536 even though messages are being read and removed from the
msg queue.

The sysv msg queue either ignores the /proc/sys/kernel/msgmnb value if
it is above 65536 or simply gets it wrong. Proof: I can place more than
msgmnb bytes in a queue. The behavior is not consistent, but 100%
reproducable. It's not consistent because if I use messages of about
1000-2000 bytes the msgmnb never gets bigger than 65536 (even if
/proc/sys/kernel/msgmnb is set to 1048576 - bug). However, if I use
small messages like 13 bytes I can get bizarre (wrong) ipcs results
like this:

used-bytesmessages
65536  65536


Why does Linux ignore the /proc/sys/kernel/msgmnb value - or seem to
partly ignore it if it is above 65536? I *really* need this to be
around a MB. Is there an undocumented limit here or is this a bug?

Thanks.





=
A camel is ugly but useful; it may stink, and it may spit, but it'll get you where 
you're going. - Larry Wall -

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Flushing buffer and page cache

[Douglas Gilbert]

James Bottomley wrote:

> > Is it possible to flush all entries in the buffer cache corresponding
> > to a single block device (i.e. simply drop them if they aren't dirty,
> > or write them to disk and drop them after this if they are dirty)?
> 
> Yes, just send the BLKFLSBUF ioctl to the device this syncs the device then 
> removes all the buffers from the cache.  We use it as a tool to move a SAN 
> device around a cluster, which is similar to what you want to do.

Last time this question was raised, someone mentioned
a little utility called flushb . Here is its source:

/*
 * flushb.c --- This routine flushes the disk buffers for a disk
 */

/*
 * modified August 2000 by Juri Haberland
 * [EMAIL PROTECTED]
 */

#include 
#include 
#include 

#define NOARGS void

const char *progname;

static void usage(NOARGS)
{
fprintf(stderr, "Usage: %s disk\n", progname);
exit(1);
}  

int main(int argc, char **argv)
{
int fd;

progname = argv[0];
if (argc != 2)
usage();

fd = open(argv[1], O_RDONLY, 0);
if (fd < 0) {
perror("open");
exit(1);
}
/*
 * Note: to reread the partition table, use the ioctl
 * BLKRRPART instead of BLKFSLBUF.
 */
if (ioctl(fd, BLKFLSBUF, 0) < 0) {
perror("ioctl BLKFLSBUF");
exit(1);
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SMP: bind process to cpu

[Christoph Hellwig]

[Nick, I've added you to the Cc list so you can look at
 it for future versions of your patch]


On Sat, Feb 17, 2001 at 03:13:45PM +0100, Manfred Spraul wrote:
> You must also update wake_process_synchroneous(), otherwise you can get
> lost wakeups with pipes.
> 
> Something like
> 
> > if (!(p->cpus_allowed & (1 << smp_processor_id()))
> > reschedule_idle(p);
> 
> must be added after add_to_runqueue().

Ok.

> Ingo Molnar did some testing with tux2, and under high load wakeups were
> lost without such a patch.

(s/tux2/tux/ I suppose)

Yepp - but tux is again not userspace...

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: XOR [ was: Linux stifles innovation... ]

[brian]

>  > On Fri, 16 Feb 2001, Michael H. Warfield wrote:
>  > > > You know XOR is patented (yes, the logical bit operation XOR).
>  > >  But wasn't that Xerox that had that?

>  > US Patent #4,197,590 held by NuGraphics, Inc.

On Fri, Feb 16, 2001 at 09:20:34PM -0500, David Relson wrote:
> The patent was for using the technique of using XOR for dragging/moving 
> parts of a graphics image without erasing other parts.  Also, since the 
> patent was granted in 1980, the inventors have had their 17 years of patent 
> protection, and we're all free to use the technique - legally!

In 1984 I received a demand letter for $10,000 from the above
referenced company as a unlimited license for use of a that
patent and another patent.

At the time I ran a company that made graphics cards for IBM PCs.

-- 
Brian Litzinger <[EMAIL PROTECTED]>

Copyright (c) 2000 By Brian Litzinger, All Rights Reserved
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux stifles innovation...

[Robert Read]

On Sat, Feb 17, 2001 at 12:41:57PM +, Henning P. Schmiedehausen wrote:
> 
> If HP would spent only 5% of their driver writing
> buget for Windows into Linux driver development, that I would call "a
> move". 

Have you seen this: http://hp.sourceforge.net/ 

I certainly don't know what the percentage is (or care), but I'd call
that "a move."

robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LILO and serial speeds over 9600

[James Sutherland]

On Sat, 17 Feb 2001, Patrick Michael Kane wrote:

> * Pavel Machek ([EMAIL PROTECTED]) [010217 05:40]:
> > Being able to remotely resed machine with crashed userland would be
> > *very* nice, too...
> 
> If it provides a true remote console, enable SYSRQ and youi should get this
> for free.

Yes, it should work fine. Of course, there's always the risk you'll
connect to the crashed box from your machine, then hit Alt+SysRq+B, and
say rude things as YOUR machine reboots... :-)


James.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/