Re: time in the future during make for 2.4.0

[Thomas Molina]

On Sun, 28 Jan 2001 [EMAIL PROTECTED] wrote:

>
> I had this problem when I was upgrading my kernel, and happened to do
> it during the daylight savings time roll-back.  Confused the heck out
> of me for a while.  Anyways, you can try 'touching' all your files,
> and do a 'make clean' then try again.  If it doesn't complain about a
> long arg list, you can try 'touch `find . -type f`'.

Several people emailed me with similar comments.  It seems I
occasionally have this habit of making myself look foolish.  The
explanation is this:  Yesterday I put a new processor and motherboard
into the system.  When I set up the BIOS I put in a date one day into
the future.  This morning's cron job called a remote time server which
corrected the date.  When I compiled the kernel this morning, confusion
reigned.  Sorry for bothering everyone.  Touching the files did fix the
problem.  I'll probably find a few more floating around causing problems
until 0302 tomorrow morning when I'm past all the future dates.

The motherboard change was instructive as was going from a K6-2 to an
Athlon.  Linux booted up without a problem while Windows crashed and
burned.  The best part was that I knew what was going to happen and I
had an audience.

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

PCI IRQ routing problem in 2.4.0

[Robert Siemer]

Hi Martin!

While moving from 2.4.0-test9 to 2.4.0 I got the following problem:
Linux thinks my usb controller is on IRQ 12 instead of IRQ 9.
The 'BIOS box' (on boot) still states that usb is on IRQ 9.

Under test9 pci-irq-behaviour was okay for me, but with 2.4.0 I cant
load the usb-modules (the kernel panics and reboots).

I attached the kernel output (with #define DEBUG) and 'lspci -vvx'.

I hope you can help me; otherwise I need a good pointer to pci
configuration specs...


Thanks,
Robert


00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (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- 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 
Region 4: I/O ports at d000 [size=16]
00: 39 10 13 55 01 00 00 00 d0 8a 01 01 00 20 80 00
10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00
20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 00 00

00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 10) (prog-if 10 
[OHCI])
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: 33 53 f0 88 83 00 00 02 00 00 00 03 00 00 00 00
10: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0e 01 00 00

00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
Subsystem: Tekram Technology Co.,Ltd. DC390F Ultra Wide SCSI Controller
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]
00: 00 10 0f 00 57 00 00 02 03 00 00 01 08 20 00 00
10: 01 b4 00 00 00 00 80 e1 00 00 00 e1 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 e1 1d 04 39
30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 11 40

00:13.0 VGA compatible controller: Silicon Integrated Systems [SiS] 5597/5598 VGA (rev 
65) (prog-if 00 [VGA])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (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- 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 
Region 4: I/O ports at d000 [size=16]
00: 39 10 13 55 01 00 00 00 d0 8f 01 01 00 20 80 00
10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00
20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 00 00

00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 10) (prog-if 10 
[OHCI])
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: 33 53 f0 88 83 00 00 02 00 00 00 03 00 00 00 00
10: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0e 01 00 00

00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
Subsystem: Tekram Technology Co.,Ltd. DC390F Ultra Wide SCSI Controller
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]
00: 00 10 0f 00 57 00 00 02 03 00 00 01 08 20 00 00
10: 01 b4 00 00 00 00 80 e1 00 00 00 e1 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 e1 1d 04 39
30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 11 40

00:13.0 VGA compatible controller: Silicon Integrated Systems [SiS] 5597/5598 VGA (rev 
65) (prog-if 00 [VGA])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 

Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #4 Sun Jan 28 19:03:05 CET 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 

Re: dos-partition mount bug

[mirabilos]

I suggest type # fdisk -l /dev/hdb
Maybe it's FAT32 where the others are FAT16?
Try SCANDISK(tm)...
If you're familiar with FAT, you also could use DEBUG, the Norton
Utilities etc. to look for a failure in the filesystem. For FAT16 it's easy.
Bootsector, 2xFAT, root dir, data blocks
Send us a hexdump of the first block. (If it's FAT16)

PS: I'm going to bed now, so could be some time to respond

mirabilos

- Original Message - 
From: "Andreas Huppert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 28, 2001 8:49 PM
Subject: dos-partition mount bug


> > Hi,
> The following bug-report concerns all linux-versions (inclusive 2.2.18) I have
> had to do with!
> 
> > I have been trying to mount the dos-partition /dev/hdb1 on /dos/d for
> > three years and it fails:
> > My /etc/fstab is:
> > /dev/hda3 / ext2 defaults 0 1
> > /dev/hdb2 /downloads ext2 defaults 0 1
> > /proc /proc proc defaults 0 0
> > /dev/cdrom /cdrom iso9660 ro,noauto,user,exec 0 0
> > /dev/hda4 /usr ext2 defaults 0 2
> > /dev/hda1 /dos/c vfat user,noexec,nosuid,nodev 0 2
> > /dev/hda5 /dos/e vfat user,noexec,nosuid,nodev 0 2
> > /dev/hdb1 /dos/d vfat user,noexec,nosuid,nodev 0 2
> > 
> > and "mount /dos/d" sais:
> > mount: wrong fs type, bad option, bad superblock on /dev/hdb1,
> >or too many mounted file systems
> > 
> > strace sais:
> > mount("/dev/hdb1", "/dos/d", "vfat",
> > MS_NOSUID|MS_NODEV|MS_NOEXEC|0xc0ed, 0x8056fc8) = -1 EINVAL (Invalid
> > argument)
> > 
> > I don´t need to say, that mounting /dos/c and /dos/e works without any
> > problem. On the other hand win'98 works with all dos-partitions normally.
> > Thanks
> > Andreas Huppert


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

dos-partition mount bug

[Andreas Huppert]

> Hi,
The following bug-report concerns all linux-versions (inclusive 2.2.18) I have
had to do with!

> I have been trying to mount the dos-partition /dev/hdb1 on /dos/d for
> three years and it fails:
> My /etc/fstab is:
> /dev/hda3 / ext2 defaults 0 1
> /dev/hdb2 /downloads ext2 defaults 0 1
> /proc /proc proc defaults 0 0
> /dev/cdrom /cdrom iso9660 ro,noauto,user,exec 0 0
> /dev/hda4 /usr ext2 defaults 0 2
> /dev/hda1 /dos/c vfat user,noexec,nosuid,nodev 0 2
> /dev/hda5 /dos/e vfat user,noexec,nosuid,nodev 0 2
> /dev/hdb1 /dos/d vfat user,noexec,nosuid,nodev 0 2
> 
> and "mount /dos/d" sais:
> mount: wrong fs type, bad option, bad superblock on /dev/hdb1,
>or too many mounted file systems
> 
> strace sais:
> mount("/dev/hdb1", "/dos/d", "vfat",
> MS_NOSUID|MS_NODEV|MS_NOEXEC|0xc0ed, 0x8056fc8) = -1 EINVAL (Invalid
> argument)
> 
> I don´t need to say, that mounting /dos/c and /dos/e works without any
> problem. On the other hand win'98 works with all dos-partitions normally.
> Thanks
> Andreas Huppert

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

tulip autonegotiation patch

[Stephen Degler]

Hi,

This one-liner fixes a subtle 21143 autonegotiation problem for me on a Zynx
quad card.  The driver would claim to negotiate 100-FD, but would report late
collisions and bad transmit throughput.

The driver still allows packets to be transmitted during autonegotiation,
but that only drops a few packets.

skd

--- 21142.c.bad Sun Jan 28 15:26:25 2001
+++ 21142.c Sun Jan 28 11:51:59 2001
@@ -171,7 +171,7 @@
for (i = 0; i < tp->mtable->leafcount; i++)
if (tp->mtable->mleaf[i].media == dev->if_port) {
tp->cur_index = i;
-   tulip_select_media(dev, 0);
+   tulip_select_media(dev, 1);
setup_done = 1;
break;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ECN: Clearing the air (fwd)

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 01:08:40PM -0500, jamal wrote:
> On Sun, 28 Jan 2001, Rogier Wolff wrote:
> 
> > A sufficiently paranoid firewall should block requests that he doesn't
> > fully understand. ECN was in this category, so old firewalls are
> > "right" to block these. (Sending an 'RST' is not elegant. So be it.)
> >
> > However, ECN is now "understood", and operators are now in a position
> > to configure their firewall to "do the right thing". This is
> 
> This would have been easier. The firewall operators were not provided with
> this option. This is hard-coded. I agree with the rest of your message.

They chose their vendor. 

In the case of Cisco, they aparently chose OK as cisco fixed their product
right away.

In the case of Raptor they made a bad decision as the vendor still has not
fixed the problem...

They could have chose Linux where if there had been an issue they could have
gotten it fixed without respect to the vendors idea of how important the
problem is...

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

linux-kernel´Ô¾È³çÇϼ¼¿ä?

[OnLine Korea]

Title: 



¢Ä ¿À´ÃÀÇ À¯¸Ó ÇѸ¶µð ¢Å
  "Dad, I don't want to go to school today.," said 
the boy.  "Why not, son?"  "Well, one of the chickens on the 
school farm died last week and    we had chicken soup for lunch 
the next day. And three days ago    one of the pigs died and we 
had roast pork the next day,,,."  "But why don't you want to go 
today?"  "Because the English teacher died yesterday!"  
"."
  "¾Æºü, ³ª ¿À´Ã Çб³ °¡±â ½È¾î." ÇÏ°í ¼Ò³âÀÌ ¸»Çß´Ù.  "¿Ö °¡±â 
½È¾î?"  "Áö³­ ÁÖ¿¡ Çб³ ³óÀå¿¡¼­ ´ß ÇÑ ¸¶¸®°¡ Á×¾ú´Âµ¥ ´ÙÀ½³¯ Á¡½ÉÀ¸·Î    ´ß ½ºÇÁ¸¦ ¸Ô¾ú¾î. 
±×¸®°í 3ÀÏ Àü¿¡´Â µÅÁö ÇÑ ¸¶¸®°¡ Á×¾ú´Âµ¥    ±× ´ÙÀ½ ³¯¿¡´Â µÅÁö ºÒ°í±â¸¦ ¸Ô¾ú°í"  
"±×·±µ¥ ¿À´ÃÀº ¿Ö Çб³¿¡ °¡±â ½È¾î?"  "¾îÁ¦ ¿µ¾î ¼±»ý´ÔÀÌ µ¹¾Æ°¡¼Ì´Ü ¸»¾ß!"  
"."
¢Ä ¿À´ÃÀÇ ¿µ¾î ÇѸ¶µð ¢Å    
¢Â I felt on top of the 
world 

»ç¶÷Àº ´©±¸³ª ¼º°øÇÏ¸é ±âºÐÀÌ ÁÁÀº °ÍÀº ´ç¿¬ÇÏÁö¿ä. ¹°·Ð, ¾î¶² »ç¶÷µéÀº ¼º°øÇßÀ» ¶§¿¡ ´õ 
°â¼ÕÇØÁöÁö¸¸ ´ëºÎºÐÀÇ »ç¶÷µéÀº [³ª¸¦ ºÁ! ³»°¡ ÃÖ°í¾ß]¶ó°í »ý°¢ÇÕ´Ï´Ù. ÀÌ¿Í °°Àº ±âºÐÀ» ³ªÅ¸³»´Â Ç¥ÇöÀÌ 'on top of 
the world'¶ø´Ï´Ù.
A: I heard you were engaged to Marian.
B: Actually, I was.
A: Oh, really? So, how did you feel on the night of 
your engagement?
B: I felt like I was on top of the world.
¡á'on top of the world'¸¦ Á÷¿ªÇϸé [¼¼»ó ²À´ë±â¿¡]¶ó´Â ÀǹÌÀ̸ç 
  'I felt on top of the world.'´Â "¼¼»ó ²À´ë±â¿¡ ÀÖ´Â ´À³¦À̾ú´Ù."  Áï, (±²ÀåÈ÷ 
±âºÐÀÌ ÁÁ¾Ò´Ù)¸¦ ¶æÇÕ´Ï´Ù.  ÈçÈ÷ [±âºÐÀÌ ÁÁ¾Ò¾î]¶ó´Â Àǹ̷Π'I felt good.'¸¸À» »ý°¢Çϱ⠽¬¿ì³ª 
  ÀÌ Ç¥Çöµµ ¾Ë°í ÀÖÀ¸¸é °¨Á¤ÀÇ Ç¥ÇöÀ» ´õ Àß ÇÒ ¼ö ÀÖÀ» °Å¿¡¿ä.
¢Á 'on top of the world'´Â ¼¼»ó ²À´ë±â¿¡ ÀÖ´Â ´À³¦!. ±×·¸´Ù¸é 
   'out of this world'´Â? ÀÌ ¼¼»óÀÇ ÀÏ °°Áö ¾Ê°Ô ±Ù»çÇÑ[wonderful],   
  ȤÀº ȯ»óÀûÀÎ[fantastic]À̶õ ¶æÀÌ¿¡¿ä.
A: ¸Þ¸®¾È°ú ¾àÈ¥ÇÑ´Ù°í µé¾ú´Âµ¥.B: »ç½Ç ÀÌ¹Ì Çß¾î.A: ¾î, 
Á¤¸»À̾ß?  ±×·¡,¾àÈ¥½ÄÇÑ ±×³¯ ¹ã¿¡ ±âºÐÀÌ ¾î¶®¾î?B: ¼¼»óÀ» ¾òÀº ±âºÐÀ̾úÁö.
¢Ä ¿À´ÃÀÇ ÀÏ¾î  ÇѸ¶µð ¢Å
   ¡ØÀϾ ¿µ¾î¿Í °°Àº ÇüÅ·Π±¸¼º µÇ¾î 
ÀÖ½À´Ï´Ù.linux-kernel´Ô 
¾È³çÇϼ¼¿ä? 
ÀúÈñ´Â ÀüÈ­¸¦ ÀÌ¿ëÇؼ­ °­»ç¿Í 1:1·Î ¿Ü±¹¾î ÇнÀÀ» ÇÒ ¼ö ÀÖ´Â ¢Ä Online Korea 
[ www.olk.co.kr ] ¢Å ¶ó°í ÇÕ´Ï´Ù.
¸ÕÀú, Çã¶ô¾øÀÌ ÆíÁö µå·Á Á˼ÛÇÕ´Ï´Ù. ºÎµð ³Ê±×·¯¿î ¿ë¼­¸¦..
ÀúÈñ ȸ»ç¿¡¼­´Â ¿µ¾î À¯¸Ó¿Í »ýÈ° ȸȭ¿¡ °ü½É ÀÖ´Â ºÐµé²² ¸ÅÀÏ(¿ù-±Ý), ¿µ¾î À¯¸Ó¿Í ½Ç 
»ýÈ°¿¡ ÇÊ¿äÇÑ »ýȰȸȭ ÇÑ ¹®À徿À» ¹«·á·Î º¸³» µå¸®°í ÀÖ¾î¿ä.
À§¿Í°°Àº ³»¿ëÀÇ ¼­ºñ½º¸¦ ¹Þ¾Æº¸±â ¿øÇÏ½Ã¸é ¡ì [EMAIL PROTECTED] ¡í·Î "yes"¶ó´Â ³»¿ëÀÇ ´äÀåÀ» Áֽñâ 
¹Ù¶ø´Ï´Ù.
±×¸®°í, ÀúÈñ ÀüÈ­ ¿Ü±¹¾î °­ÀÇ°¡ ±Ã±ÝÇϽŠºÐµéÀ» À§ÇØ  ¢Â ½Ã¹ü°­ÀÇ ¢Â µµ 1ȸ¿¡ ÇÑÇؼ­ ¹«·á·Î ½Ç½ÃÇÏ°í 
ÀÖÀ¸´Ï Çѹø µé¾îº¸°í ½ÍÀ¸½Ã¸é Áö±Ý ½ÅûÇØ ÁÖ¼¼¿ä.
¹«·á ½Ã¹ü°­ÀÇ ½Åû ¹æ¹ýÀº ¢º ¿©±â ¢¸ ¸¦ Ŭ¸¯ÇϽŠÈÄ °­ÀÇ ½Åû¶õ¿¡ 
Àִ½ùü°­ÀǸ¦ ½ÅûÇϽøé ÀúÈñ°¡ ÀüÈ­¸¦ µå·Á ½Ã¹ü°­ÀǸ¦ ÇØ µå¸°´ä´Ï´Ù.
¹°·Ð, ÀüÈ­ 02-588-0510 À¸·Îµµ ½ÅûÇÏ½Ç ¼ö ÀÖ±¸¿ä.
¾Æ¹«ÂÉ·Ï ÀÌ ÇнÀ¹ýÀÌ linux-kernel´ÔÀÇ È¸È­ ½Ç·Â Çâ»ó¿¡ ÀÛÀº º¸ÅÆÀÌ 
µÇ¾úÀ¸¸éÇÕ´Ï´Ù.
°¨»çÇÕ´Ï´Ù.
linux-kernel´Ô²²´Â http://icat.snu.ac.kr/news.html¿¡ ÀÖ´Â ÁÖ¼Ò¸¦ º¸°í ¸ÞÀÏ µå¸®°Ô 
µÇ¾ú½À´Ï´Ù.
ºÒÇÊ¿äÇÑ Á¤º¸¿´´Ù¸é Á¤¸» Á˼ÛÇÕ´Ï´Ù.


èº{.nÇ+‰·Ÿ®‰­†+%ŠËlzwm…ébë§²æìr¸›zX§»®w¥Š{ayºʇڙë,j­¢f£¢·hš‹àz¹®w¥¢¸•æ¬z·švØ^¶m§ÿðÃnƊàþY&—

Re: ECN: Clearing the air (fwd)

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 05:11:20PM +, James Sutherland wrote:
[snip]
> > The simplest thing in this chaos is to fix the firewall because it is in
> > violation to begin with.
> 
> It is not in violation, and you can't fix it: it's not yours.
[snip]
 > > It's too bad we end up defining protocols using English. We should use
> > mathematical equations to remove any ambiguity ;->
> 
> No, just use English properly. "Must be zero" doesn't actually mean "must
> be set to zero when sending, and ignored when receiving/processing", which
> is probably what the standard SHOULD have said.

I see your problem now... You can't read!
The standard don't just say "Must be zero" it also says that it is reserved.
Reserved is very explicitly defined elseware... In the language of RFCs (and
most of engineering) it means 'you must always set it as specified' when
generating, and you must never behave differently because of it. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Poor SCSI drive performance on SMP machine, 2.2.16

[paradox3]

Sorry, forget this last email. Here is hdparm output.


 hdparm

Re: Poor SCSI drive performance on SMP machine, 2.2.16

[paradox3]

I did this:

date
dd if=/dev/zero of=TESTFILE bs=1024 count=102400
date
sync
date


and I gave the time differences from the first to the last timestamp.

Regards, Para-dox ([EMAIL PROTECTED])



- Original Message -
From: "Bruce Harada" <[EMAIL PROTECTED]>
To: "paradox3" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 28, 2001 2:31 PM
Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16


>
> Hm. As a point of comparison, I use a similar system to yours (full SCSI,
> though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the
> same disk, in around 13 seconds. Where are you copying to the SCSI drive
> from - the same drive, an IDE disk, CDROM? If IDE, what are its
> particulars? (Check with hdparm -iI /dev/hd?)
>
> --
> Bruce Harada
> [EMAIL PROTECTED]
>
>
>
> On Sun, 28 Jan 2001 12:44:29 -0500
> "paradox3" <[EMAIL PROTECTED]> wrote:
> >
> > I don't get any messages relating to the drives in any syslog output.
> >
> > >
> > > Do you get messages like the ones below in /var/log/messages?
> > >
> > >   sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs
> > >   sym53c875-0-<0,0>: tagged command queue depth set to 7
> > >
> > > In fact, do you get any messages in your log files that look like they
> > > might be related?
> > >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>

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

Re: time in the future during make for 2.4.0

[phil]

I had this problem when I was upgrading my kernel, and happened to do
it during the daylight savings time roll-back.  Confused the heck out
of me for a while.  Anyways, you can try 'touching' all your files,
and do a 'make clean' then try again.  If it doesn't complain about a
long arg list, you can try 'touch `find . -type f`'.


Phil

On Sun, Jan 28, 2001 at 08:49:38PM +0100, Mikael Pettersson wrote:
> On Sun, 28 Jan 2001 12:27:46 -0600 (CST), Thomas Molina wrote:
> 
> >I seem to recall a discussion on faster processors causing timing
> >problems during a kernel make, but I'm unable to find it in the kernel
> >archives.  I've now upgraded to an Athlon 900 MHz processor and an ASUS
> >A7V motherboard and have started seeing this.  It shows up as the
> >following messages during a make bzImage:
> >
> >make[3]: *** Warning:  Clock skew detected.  Your build may be
> >incomplete.
> >make[3]: *** Warning: File
> >`/mnt/hd/local/kernel/linux.24.new/include/linux/sched.h' has
> >modification time in the future (2001-01-28 17:41:05 > 2001-01-28
> >10:07:02)
> 
> No, this doesn't look like the "fast CPU" problem you are alluding to
> (look for subject MODVERSIONS in the archives). We fixed that one.
> 
> Your problem is that your kernel source dir (unpacked tarball?)
> contains files with time stamps several hours in the future;
> 'make' doesn't take kindly to this.
> 
> I've seen this happen once: during an upgrade (RH-style, i.e. not
> fresh install) from RH6.2 to RH7.0, my /etc/localtime had become
> overwritten and my machine in an instant moved from CET to some US
> time zone 6 or 8 hrs back. Then when I unpacked my kernel tarball to
> build a real kernel, I got exactly the problems you listed above.
> 
> Check your clock & time zone settings.
> 
> /Mikael

-- 
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
   [EMAIL PROTECTED] -- http://www.netroedge.com/~phil
 PGP F16: 01 D2 FD 01 B5 46 F4 F0  3A 8B 9D 7E 14 7F FB 7A
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ECN: Clearing the air (fwd)

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 02:09:19PM +, James Sutherland wrote:
> On Sun, 28 Jan 2001, Ben Ford wrote:
> > Do keep in mind, we aren't breaking connectivity, they are.
> 
> Let me guess: you're a lawyer? :-)
> 
> This is a very strange definition: if someone makes a change such that
> their machine can no longer communicate with existing systems, I would say
> the person making the incompatible change is the one who broke it.

No. If one day your city decides to make the rode into and out of your
neighorbhood only 1 meter wide, sooner or later someone will expects to drive
a car or truck into the area (rather then a motorcycle), the person city is
at fault for building a non-standard road.

The person who chose to operate a perfectly standard car/truck is not in the
wrong.
 
> Maybe my mains sockets should be waterproof: it's still my fault when
> pouring water over them causes problems, even if the standards say the
> socket should be waterproof!

No it's not. If you had a waterproof socket, it would certantly be the
makers fault if it wasn't actually waterproof. 

I suppose you think I should be tried for murder because my sneeze was an
element that contributed to a weather pattern which caused a monsoon on the
other side of the world and killed people?

It's perfectly reasonable for Linux to impliment an IETF standard.
It's not reasonable for networks to make expectations/decisions about reserved
bits in headers. If you want to break your networks, great, do things like
that. But it's your problem to fix it when it becomes an issue.

They expended effort to willfully break their networks, they can now expend
the effort to fix them. This type of thing is part of the
total-cost-of-ownership of a firewall, it isn't Linux's fault if they were
too foolish to understand they would have ongoing costs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: time in the future during make for 2.4.0

[Mikael Pettersson]

On Sun, 28 Jan 2001 12:27:46 -0600 (CST), Thomas Molina wrote:

>I seem to recall a discussion on faster processors causing timing
>problems during a kernel make, but I'm unable to find it in the kernel
>archives.  I've now upgraded to an Athlon 900 MHz processor and an ASUS
>A7V motherboard and have started seeing this.  It shows up as the
>following messages during a make bzImage:
>
>make[3]: *** Warning:  Clock skew detected.  Your build may be
>incomplete.
>make[3]: *** Warning: File
>`/mnt/hd/local/kernel/linux.24.new/include/linux/sched.h' has
>modification time in the future (2001-01-28 17:41:05 > 2001-01-28
>10:07:02)

No, this doesn't look like the "fast CPU" problem you are alluding to
(look for subject MODVERSIONS in the archives). We fixed that one.

Your problem is that your kernel source dir (unpacked tarball?)
contains files with time stamps several hours in the future;
'make' doesn't take kindly to this.

I've seen this happen once: during an upgrade (RH-style, i.e. not
fresh install) from RH6.2 to RH7.0, my /etc/localtime had become
overwritten and my machine in an instant moved from CET to some US
time zone 6 or 8 hrs back. Then when I unpacked my kernel tarball to
build a real kernel, I got exactly the problems you listed above.

Check your clock & time zone settings.

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

Choosing Linux NICs (was: Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN))

[Felix von Leitner]

Thus spake Felix von Leitner ([EMAIL PROTECTED]):
> What is missing here is a good authoritative web ressource that tells
> people which NIC to buy.

I started one now.

It's at http://www.fefe.de/linuxeth/, but there is not much content yet.
Please contribute!

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

Re: ECN: Clearing the air (fwd)

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 06:04:17AM -0800, Ben Ford wrote:
> James Sutherland wrote:
[snip] 
> > those firewalls should be updated to allow ECN-enabled packets
> > through. However, to break connectivity to such sites deliberately just
> > because they are not supporting an *experimental* extension to the current
> > protocols is rather silly.
> 
> Do keep in mind, we aren't breaking connectivity, they are.

Thats the crux of the argument. No one made them run a firewall, they chose
one that blocks undefined behavior. The Internet is a dynamic system, they
broke the end-to-end model with their firewall, the onus is on them to keep
up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote:
> Thus spake Andrew Morton ([EMAIL PROTECTED]):
> > Conclusions:
> 
> >   For a NIC which cannot do scatter/gather/checksums, the zerocopy
> >   patch makes no change in throughput in all case.
> 
> >   For a NIC which can do scatter/gather/checksums, sendfile()
> >   efficiency is improved by 40% and send() efficiency is decreased by
> >   10%.  The increase and decrease caused by the zerocopy patch will in
> >   fact be significantly larger than these two figures, because the
> >   measurements here include a constant base load caused by the device
> >   driver.
> 
> What is missing here is a good authoritative web ressource that tells
> people which NIC to buy.
> 
> I have a tulip NIC because a few years ago that apparently was the NIC
> of choice.  It has good multicast (which is important to me), but AFAIK
> it has neither scatter-gather nor hardware checksumming.
> 
> Is there such a web page already?
> If not, I volunteer to create amd maintain one.

Additionally, it would be useful to have some boot messages comment on the
abilities of cards. I am sick and tired of dealing with people telling me
that 'Linux performance sucks' when they keep putting Linux on systems with
pci 8139 adaptors. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.4.0 loop device still hangs

[Jens Axboe]

On Sun, Jan 28 2001, Andreas Franck wrote:
> Hi Jens,
> 
> I've tested your patch quite as heavy as it gets: I created 5 files of each 
> 100 MB, set up 5 loop devices and made a RAID5 array out of them, putting 
> ext2 on it and running a bonnie loop with 350 MB test size over it for the 
> night.
> 
> Everything survived, worked flawlessly and I'm happy my disk did too :-)
> Many thanks for the fine work!

Thanks for the testing, it does indeed look promising if it survives
a beating like that :-)

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ECN: Clearing the air (fwd)

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
> > There is nothing silly with the decision, davem is simply a modern day
> > internet hero.
> 
> No. If it were something essential, perhaps, but it's just a minor
> performance tweak to cut packet loss over congested links. It's not
> IPv6. It's not PMTU. It's not even very useful right now!

No. ECN is essential to the continued stability of the Internet. Without
probabilistic queuing (i.e. RED) and ECN the Internet will continue to have
retransmit synchronization and once congested stay congested until people get
frustrated and give it up for a little bit.

It's a real issue, and it's actually important to have it implemented. It's
not just a performance hack.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Q: Release of 2.4.1

[Jens Axboe]

On Sun, Jan 28 2001, mirabilos wrote:
> Does 2.4.1 when released, include e.g. Jens' loop patch?

No, I haven't submitted it yet due to the massive restructering. Plus,
it also touches other parts than loop itself.

> Because it seems stable and loop else were buggy.
> So for others if there are.

It needs a bit more testing, and crypto hasn't been verified either.

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Re: hotmail not dealing with ECN

[Gregory Maxwell]

On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
> ...
> > An attack against an Xray system is much more likely to come from inside the
> > companies network.
> ...
> 
> We are not talking about attacks here, we are talking about undefined
> behaviour when (perhaps poorly designed) systems encounter network
> packages that use new or experimental features: I have seen MRI scanners
> panic when they received SNMP queries and SNMP has been around for ages!

The discussion was over centralized firewalls. Putting a firewall right on
top of a system is the same as putting it on the system. Putting a firewall
on your Internet connection would be insufficient to protect such a system.

It's not a question of how long something has been around. You should be
able to send line noise into the Ethernet port of any IP host and not have
it behave adversly. Anything less and you *WILL* have problems.

I would hope that you have enough sense to NOT connect any such broken
systems in any way to a public network. 

Yet, another point against firewalls: Apparently they encourage computer
professionals to behave criminally negligent by making it acceptable to
implement broken life critical services. 

Firewalling your hospital's Internet connection to prevent your tomographic
equipment from producing bad results due to a port scan rather then
correctly repairing the system is computer equivalent of placing the fuel tank
on the outside of the frame on a car (Pinto): Since it's protected by it's
own wall and the outer body, casual impacts won't make the defect noticeable.

Less people would have died in the pinto if the fuel tank was made of
sugar-glass and placed prominently on the hood. Not because it's safer that
way, but because out of both of the defective configurations the
tank-on-the-hood is obviously broken and would get fixed or not used.

Firewalls only actually improve security when there is only a single domain
of trust behind them. Often we have multiple domains of trust even within a
single system. Internet filtering firewalls provide nothing more then a
false sense of security, and some opportunistic script kiddie protection.

The continued profiteering by security 'experts' and acceptance of
magic-boxes by systems administrators ensures that better solutions are not
implemented.


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

Re: Poor SCSI drive performance on SMP machine, 2.2.16

[Bruce Harada]

Hm. As a point of comparison, I use a similar system to yours (full SCSI,
though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the
same disk, in around 13 seconds. Where are you copying to the SCSI drive
from - the same drive, an IDE disk, CDROM? If IDE, what are its
particulars? (Check with hdparm -iI /dev/hd?)

--
Bruce Harada
[EMAIL PROTECTED]



On Sun, 28 Jan 2001 12:44:29 -0500
"paradox3" <[EMAIL PROTECTED]> wrote:
>
> I don't get any messages relating to the drives in any syslog output.
> 
> >
> > Do you get messages like the ones below in /var/log/messages?
> >
> >   sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs
> >   sym53c875-0-<0,0>: tagged command queue depth set to 7
> >
> > In fact, do you get any messages in your log files that look like they
> > might be related?
> >
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Q: Release of 2.4.1

[mirabilos]

Does 2.4.1 when released, include e.g. Jens' loop patch?
Because it seems stable and loop else were buggy.
So for others if there are.

mirabilos

-BEGIN GEEK CODE BLOCK-
Version: 3.12+custom(^=href;C-style-comments)
GO/S dx@ s--: a---> C++ UL P--- L++$(-^lang) E/joe W+(++)
N? o K? w-(+$) O+>+++ M-- V- PS+++@ PE(--) Y+ PGP t+ 5? X+ R+ !tv!
b* DI- D+ G(>++) e(^age) h! r(-) y--(!y+) /* lang=NASM, GW-BASIC, C */
--END GEEK CODE BLOCK--


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

Re: Linux-2.4.1-pre11

[Dieter Nützel]

> I just uploaded it to kernel.org, and I expect that I'll do the final
> 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
> pre-kernel works for you..

Hello Linus,

can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release 
updated: 1-25-2001)  in 2.4.1 final?
ftp://download.intel.com/technology/iapc/acpi/downloads/acpica-linux-20010125.tar.gz)

Thanks, 
Dieter

BTW Have a nice trip.
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

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

Re: Renaming lost+found

[Chris Mason]

On Friday, January 26, 2001 01:19:49 PM -0500 James Lewis Nance
<[EMAIL PROTECTED]> wrote:

> FWIW IBM's JFS file system does not have a lost+found directory.  I dont
> remember if reiserfs does or not.
> 

reiserfsck creates it.

-chris

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

Re: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.xkernels?

[Chris Mason]

On Sunday, January 28, 2001 02:29:09 PM +1100 Andrew Morton
<[EMAIL PROTECTED]> wrote:

> Shawn Starr wrote:
>> 
>> Andrew, the patch HAS made a difference. For example, while untaring
>> glibc-2.2.1.tar.gz the system was not sluggish (mouse movements in X)
>> etc.
>> 
>> Seems to be a go for latency improvements on this system.
> 
> hmm..  OK, thanks.
> 
> Chris, this seems to be a worthwhile improvement to mainstream
> reiserfs, independent of the low-latency thing.   You can
> probably achieve 10 milliseconds with just a few lines of
> code - a subset of the patch which Shawn tested. (Unless you
> were planning on magical algorithmic improvements...).
> 
> I'm all set up to generate those few lines of code, so
> I'll propose a patch later this week.

Perfect, I was thinking exactly the same thing.  We have to be careful here
though, since the extra schedules will increase the chance the searching
has to be redone from scratch, which can have big performance ramifications.

I think your change to search_by_key will be the safest for performance
considerations, along with the change to prepare_for_delete_or_cut.  If
those won't be enough, we can attack reiserfs_get_block (who is probably
the biggest single offender without your patch).

-chris

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Roman Zippel]

Hi,

On Sun, 28 Jan 2001, Manfred Spraul wrote:

> And one more point for the Janitor's list:
> Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
> either spin_lock_irq() or spin_lock() is sufficient. That's both faster
> and better readable.
> 
> spin_lock_irq(): you know that the function is called with enabled
> interrupts.
> spin_lock(): can be used in hardware interrupt handlers when only one
> hardware interrupt uses that spinlocks (most hardware drivers), or when
> all hardware interrupt handler set the SA_INTERRUPT flag (e.g. rtc and
> timer interrupt)

This is not a bug and only helps to make drivers nonportable. Please,
don't do this.

bye, Roman

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

time in the future during make for 2.4.0

[Thomas Molina]

I seem to recall a discussion on faster processors causing timing
problems during a kernel make, but I'm unable to find it in the kernel
archives.  I've now upgraded to an Athlon 900 MHz processor and an ASUS
A7V motherboard and have started seeing this.  It shows up as the
following messages during a make bzImage:

make[3]: *** Warning:  Clock skew detected.  Your build may be
incomplete.
make[3]: *** Warning: File
`/mnt/hd/local/kernel/linux.24.new/include/linux/sched.h' has
modification time in the future (2001-01-28 17:41:05 > 2001-01-28
10:07:02)

I would appreciate any pointers to the discussion archive or solutions.

It doesn't seem to have a major problem with kernel compiles, but it
appears to send compiles of lm-sensors 2.5.5 into endless loops.  Each
loop begins with the following:

make: *** Warning: File `/usr/local/kernel/linux/include/linux/types.h'
has modification time in the future (2001-01-28 17:41:05 > 2001-01-28
12:21:28)
gcc -M -MG -I. -Ikernel/include -I/usr/local/include
-I/usr/local/kernel/linux/include -O2  prog/detect/i2cdetect.c | \
sed -e 's@^\(.*\)\.o:@prog/detect/i2cdetect.rd
prog/detect/i2cdetect.ro: Makefile '`dirname
prog/detect/i2cdetect.rd`/Module.mk' @' > prog/detect/i2cdetect.rd

and ends with the following before starting over again:

gcc -M -MG -I. -Ikernel/include -I/usr/local/include
-I/usr/local/kernel/linux/include -O2  -D__KERNEL__ -DMODULE
-fomit-frame-pointer  -DEXPORT_SYMTAB -DMODVERSIONS -include
/usr/local/kernel/linux/include/linux/modversions.h kernel/sensors.c | \
sed -e 's@^\(.*\)\.o:@kernel/sensors.d kernel/sensors.o:
Makefile '`dirname kernel/sensors.d`/Module.mk' @' > kernel/sensors.d


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

Re: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)

[Jens Axboe]

On Sun, Jan 28 2001, Linus Torvalds wrote:
> On Sun, 28 Jan 2001, Jens Axboe wrote:
> > 
> > How about this instead?
> 
> I really don't like this one. It will basically re-introduce the old
> behaviour of waking people up in a trickle, as far as I can tell. The
> reason we want the batching is to make people have more requests to sort
> in the elevator, and as far as I can tell this will just hurt that.
> 
> Are there any downsides to just _always_ batching, regardless of whether
> the request freelist is empty or not? Sure, it will make the "effective"
> size of the freelist a bit smaller, but that's probably not actually
> noticeable under any load except for the one that empties the freelist (in
> which case the old code would have triggered the batching anyway).

The problem with removing the !list_empty test like you suggested
is that batching is no longer controlled anymore. If we start
batching once the lists are empty and start wakeups once batch_requests
has been reached, we know we'll give the elevator enough to work
with to be effective. With !list_empty removed, batch_requests is no
longer a measure of how many requests we want to batch. Always
batching is not a in problem in itself, the effective smaller freelist
effect should be neglible.

The sent patch will only trickle wakeups in case of batching already
in effect, but batch_request wakeups were not enough to deplete
the freelist again. At least that was the intended effect :-)

> Performance numbers?

Don't have any right now, will test a bit later.

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ECN: Clearing the air (fwd)

[jamal]

On Sun, 28 Jan 2001, Rogier Wolff wrote:

> > This would have been easier. The firewall operators were not
> > provided with this option. This is hard-coded. I agree with the rest
> > of your message.
>
> Take "configure" with a bit of liberty. Because the firewall vendor
> chose to hard-code this into the firmware. "configuring" in this case
> means reconfiguring new software on the firewall. Blame the vendor.

Perhaps the most famous writting on protocol design was by Jon Postel.
Interestingly in RFC 793 (Section 2.10)
" be conservative in what you do, be liberal in what you accept from
  others."

That should be the mantra.
There is no librety when you hard-code.

cheers,
jamal

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

Linux-2.4.1-pre11

[Linus Torvalds]

I just uploaded it to kernel.org, and I expect that I'll do the final
2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
pre-kernel works for you..

The main noticeable things in pre11 are fixing some bugs that crept in
after 2.4.0 - the block device queuing improvements could lose wakeups
under extreme load by multiple clients, and the vmscanning "get rid of
special return codes for shared memory" thing had missed a bit.

This should also fix the VIA IDE driver issues (if you want safe, do NOT
enable auto-dma), and the reported problems with hpt366 controllers and
IBM drives. Hopefully these were the last major IDE issues for a while.

Also, can people who have had unhappy relationships with their eepro100
please try to cuddle and make up again? The eepro100 changes should fix
the problem of having posted writes that basically made some of the timing
not work out.

Linus

-
pre11:
 - Trond Myklebust: NFS/RPC client SMP fixes
 - rth: alpha pyxis and cabriolet fixes
 - remove broken sys_wait4() declarations
 - disable radeon debugging code
 - VIA IDE driver should not enable autodma unless asked for
 - Andrey Savochkin: eepro100 update. Should fix the resource timing problems.
 - Jeff Garzik: via82cxxx_audio update
 - YMF7xx PCI audio update: get rid of old broken driver, make new
   driver handle legacy control too. 
 - fix missed wakeup on block device request list
 - hpt366 controller doesn't play nice with some IBM harddisks
 - remove inode pages from the page cache only after having removed them
   from the page tables.
 - shared memory out-of-swap writepage() fixup (no more magic return)

pre10:
 - got a few too-new R128 #defines in the Radeon merge. Fix.
 - tulip driver update from Jeff Garzik
 - more cpq and DAC elevator fixes from Jens. Looks good.
 - Petr Vandrovec: nicer ncpfs behaviour
 - Andy Grover: APCI update
 - Cort Dougan: PPC update
 - David Miller: sparc updates
 - David Miller: networking updates
 - Neil Brown: RAID5 fixes

pre9:
 - cpq array driver elevator fixes 
 - merge radeon driver from X CVS tree
 - ispnp cleanups
 - emu10k unlock on error fixes
 - hpfs doesn't allow truncate to larger

pre8:
 - Don't drop a megabyte off the old-style memory size detection
 - remember to UnlockPage() in ramfs_writepage()
 - 3c59x driver update from Andrew Morton
 - egcs-1.1.2 miscompiles depca: workaround by Andrew Morton
 - dmfe.c module init fix: Andrew Morton
 - dynamic XMM support. Andrea Arkangeli.
 - ReiserFS merge
 - USB hotplug updates/fixes
 - boots on real i386 machines
 - blk-14 from Jens Axboe
 - fix DRM R128/AGP dependency
 - fix n_tty "canon" mode SMP race
 - ISDN fixes
 - ppp UP deadlock attack fix
 - FAT fat_cache SMP race fix
 - VM balancing tuning
 - Locked SHM segment deadlock fix
 - fork() page table copy race fix

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

Re: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)

[Linus Torvalds]

On Sun, 28 Jan 2001, Jens Axboe wrote:
> 
> How about this instead?

I really don't like this one. It will basically re-introduce the old
behaviour of waking people up in a trickle, as far as I can tell. The
reason we want the batching is to make people have more requests to sort
in the elevator, and as far as I can tell this will just hurt that.

Are there any downsides to just _always_ batching, regardless of whether
the request freelist is empty or not? Sure, it will make the "effective"
size of the freelist a bit smaller, but that's probably not actually
noticeable under any load except for the one that empties the freelist (in
which case the old code would have triggered the batching anyway).

Performance numbers?

Linus

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

[PATCH] ide config order

[Pavel Rabel]

Please reorder config to group DMA options together. In 2.4.0

Pavel Rabel


--- drivers/ide/Config.in.old   Tue Nov 28 22:22:49 2000
+++ drivers/ide/Config.in   Tue Nov 28 22:24:19 2000
@@ -42,8 +42,8 @@
 bool '  Generic PCI IDE chipset support' CONFIG_BLK_DEV_IDEPCI
 if [ "$CONFIG_BLK_DEV_IDEPCI" = "y" ]; then
bool 'Sharing PCI IDE interrupts support' CONFIG_IDEPCI_SHARE_IRQ
-   bool 'Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA_PCI
bool 'Boot off-board chipsets first support' CONFIG_BLK_DEV_OFFBOARD
+   bool 'Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA_PCI
dep_bool '  Use PCI DMA by default when available' 
CONFIG_IDEDMA_PCI_AUTO $CONFIG_BLK_DEV_IDEDMA_PCI
define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_PCI
dep_bool '  ATA Work(s) In Progress (EXPERIMENTAL)' 
CONFIG_IDEDMA_PCI_WIP $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_EXPERIMENTAL


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

Re: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)

[Jens Axboe]

On Sun, Jan 28 2001, Lorenzo Allegrucci wrote:
> >Ho humm. Jens: imagine that you have more people waiting for requests than
> >"batchcount". Further, imagine that you have multiple requests finishing
> >at the same time. Not unlikely. Now, imagine that one request finishes,
> >and causes "batchcount" users to wake up, and immediately another request
> >finishes but THAT one doesn't wake anybody up because it notices that the
> >freelist isn't empty - so it thinks that it doesn't need to wake anybody.
> >
> >Lorenzo, does the problem go away for you if you remove the
> >
> > if (!list_empty(>request_freelist[rw])) {
> > ...
> > }
> >
> >code from blkdev_release_request() in drivers/block/ll_rw_block.c?
> 
> Yes, it does.

How about this instead?

--- /opt/kernel/linux-2.4.1-pre10/drivers/block/ll_rw_blk.c Thu Jan 25 19:15:12 
2001
+++ drivers/block/ll_rw_blk.c   Sun Jan 28 19:22:20 2001
@@ -633,6 +634,8 @@
if (!list_empty(>request_freelist[rw])) {
blk_refill_freelist(q, rw);
list_add(>table, >request_freelist[rw]);
+   if (waitqueue_active(>wait_for_request))
+   wake_up_nr(>wait_for_request, 2);
return;
}
 

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ECN: Clearing the air (fwd)

[Rogier Wolff]

jamal wrote:
> 
> 
> On Sun, 28 Jan 2001, Rogier Wolff wrote:
> 
> > jamal wrote:
> > > > Yes,
> > > > those firewalls should be updated to allow ECN-enabled packets
> > > > through. However, to break connectivity to such sites deliberately just
> > > > because they are not supporting an *experimental* extension to the current
> > > > protocols is rather silly.
> > > >
> > >
> > > This is the way it's done with all protocols. or i should say the way it
> > > used to be done. How do you expect ECN to be deployed otherwise?
> >
> > Thinking about this a bit more:
> >
> > A sufficiently paranoid firewall should block requests that he doesn't
> > fully understand. ECN was in this category, so old firewalls are
> > "right" to block these. (Sending an 'RST' is not elegant. So be it.)
> >
> > However, ECN is now "understood", and operators are now in a position
> > to configure their firewall to "do the right thing". This is

> This would have been easier. The firewall operators were not
> provided with this option. This is hard-coded. I agree with the rest
> of your message.

Take "configure" with a bit of liberty. Because the firewall vendor
chose to hard-code this into the firmware. "configuring" in this case
means reconfiguring new software on the firewall. Blame the vendor. 

Roger. 




-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

problem exporting symbols from a lkm

[c]

Hello,

I'm kinda new to this kernel hacking thing. So excuse me for any stupid 
questions/remarks.
The problem I have occurs because I'm trying to install the rshaper software on my 
linux system.
I'm running:
Distribution: red hat 6.2
Kernel ver.: 2.2.14-5.0
System: i386
compiler: gcc
compiler ver.: gcc version egcs-2.91.66 19990314/linux (egcs-1.1.2 release)

The rshaper software requires you to modify the 8390 driver kernel module.
I had no problems modifying the 8390.c source to accomodate rshaper.
The problem is that the ne2k-pci.o uses symbols from the 8390.o driver.
these symbols are exported with the EXPORT_SYMBOL macro.
When I load the modified 8390.o (insmod 8390.o)
my /proc/ksyms shows that the exported symbols from 8390.o are different
from the other symbols because they have  "_R__ver_" in front of them.
And when I load the ne2k-pci.o it complains that it can't find those symbols
that were supposed to be exported by 8390.o

I have looked around on the net and this problem seems related to the
CONFIG_MODVERSIONS bug. since I have no clue as to getting
these symbols to be exported correctly maybe someone can tell me
how to get around this problem.

the compile command I used to compile 8390.c was:
gcc -D__KERNEL__ -DEXPORT_SYMTAB -DMODULE -I/usr/src/linux/net/inet -Wall 
-Wstrict-prototypes -O6 -m486 -c 8390.c

greetings,
Willem van Doesburg





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

Re: ECN: Clearing the air (fwd)

[jamal]

On Sun, 28 Jan 2001, Rogier Wolff wrote:

> jamal wrote:
> > > Yes,
> > > those firewalls should be updated to allow ECN-enabled packets
> > > through. However, to break connectivity to such sites deliberately just
> > > because they are not supporting an *experimental* extension to the current
> > > protocols is rather silly.
> > >
> >
> > This is the way it's done with all protocols. or i should say the way it
> > used to be done. How do you expect ECN to be deployed otherwise?
>
> Thinking about this a bit more:
>
> A sufficiently paranoid firewall should block requests that he doesn't
> fully understand. ECN was in this category, so old firewalls are
> "right" to block these. (Sending an 'RST' is not elegant. So be it.)
>
> However, ECN is now "understood", and operators are now in a position
> to configure their firewall to "do the right thing". This is


This would have been easier. The firewall operators were not provided with
this option. This is hard-coded. I agree with the rest of your message.

cheers,
jamal



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

Re: ECN: Clearing the air (fwd)

[jamal]

On Sun, 28 Jan 2001, James Sutherland wrote:

> On Sun, 28 Jan 2001, jamal wrote:
> > We are allowing two rules to be broken, one is RFC 793 which
> > clearly and unambigously defines what a RST means. the second is
>
> This is NOT being violated: the RST is honoured as normal.

You are interpreting RST to mean "it says RST but maybe it was not RST;
let me try again"
I dont think thats honoring it ;->
[Just like the anti-harassment campaign goes: What part of NO dont
you understand, is it the N or the O?]

>
> > the firewall or IDS box which clearly is in violation.
>
> Disagreed: it is complying with firewall RFCs, rejecting suspect
> packets. Sending an RST isn't a very bright way to do it, but that's
> irrelevant: it happens. Deal with it.

It is what some idiot designer thought it meant.
If the administrator configured it, that is complying with RFCs.

> > I see that we mostly have philosphical differences. You'd rather adapt
> > to the criminal and most people would rather have the criminal adjust to
> > society.
>
> There is no "criminal": no rules are being broken. Since it is
> "society" (or a tiny minority thereof) which has changed the rules, it is
> "society" which must adapt to be compatible with existing rules.
>

;-> We are on different extremes for sure. It is "society" which clearly
says now that if you misunderstood the rule and didnt pay attention to
the definition of "reserved", here's the definition. You understand it
better? good, please conform.
You are saying that "society" should now say ok, since you misunderstood
we'll make our lives a lot more miserable and just live with your
ignorance.

>
> I'd have said that's still true - only "hackers" are qualified. The
> problem is just that the staff doing (or attempting) the job aren't
> necessarily qualified to do it properly...

The internet is growing so fast and the shortage of people is affecting
it. Look at what happened to MS ;-> ;->

>
> > If you think the CISCOs were bad sending RSTs, i am sure you havent heard
> > about the Raptor firewalls. They dont even bother to send you anything if
> > you have ECN enabled ;-> Simply swallow your SYNs.
>
> That's regarded as a better response, actually: just drop suspect packets.
>

But then how do you "degrade" nicely from it? If you want Linux to be
able to degrade nicely, what do you do in this case?


> > So tell me, what do you propose we deal with these? Do we further
> > disambiguate or assume the packet was lost?
> > I actually bothered calling Raptor, they chose to ignore me.
>
> You mean they are still shipping a firewall which drops ECN
> packets? Hrm...
>

Yeah, as far as i know

> No, just use English properly. "Must be zero" doesn't actually mean "must
> be set to zero when sending, and ignored when receiving/processing", which
> is probably what the standard SHOULD have said.
>
> However, it's too late now: ECN-disabled routes exist. ECN implementations
> should degrade as well as possible when handling these circumstances.


I think this is the right moment for this to be fixed. Way before it is
too late.

cheers,
jamal

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

Re: ECN: Clearing the air (fwd)

[Graham Murray]

[EMAIL PROTECTED] (Rogier Wolff) writes:

> If the firewall operator is sufficiently paranoid, they can say: "We
> don't trust the ECN implementation on our hosts behind the firewall,
> so we want to disable it.".

In which case would the "correct" action not be to zero the ECN bits
of packets passing through the firewall? This would have the effect of
informing the ECN aware hosts (both within and outside the firewall)
that ECN is not available for that connection. This would not prevent
ECN aware systems from connecting.

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

Re: Poor SCSI drive performance on SMP machine, 2.2.16

[paradox3]

I don't get any messages relating to the drives in any syslog output.



- Original Message -
From: "Bruce Harada" <[EMAIL PROTECTED]>
To: "paradox3" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, January 28, 2001 3:40 AM
Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16


>
> Hi.
>
> Do you get messages like the ones below in /var/log/messages?
>
>   sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs
>   sym53c875-0-<0,0>: tagged command queue depth set to 7
>
> In fact, do you get any messages in your log files that look like they
> might be related?
>
> --
> Bruce Harada
> [EMAIL PROTECTED]
>
>
> On Sun, 28 Jan 2001 02:26:32 -0500
> "paradox3" <[EMAIL PROTECTED]> wrote:
>
> > I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM
> > IBM
> > 10 GB SCSI drive
> > (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives.
> > The
> > SCSI drive
> > performs the worst. In tests of writing 100 MB and sync'ing, one of my
> > IDE
> > drives takes 31 seconds. The SCSI drive (while doing nothing else) took
> > 2 minutes, 10 seconds. This is extremely noticable in file transfers
> > that
> > completely
> > monopolize the SCSI drive, and are much slower than when involving the
> > IDE
> > drives.
> > After a large data operation on the SCSI drive, the system will hang for
> > several minutes.
> > Anyone know what could be causing this? Thanks.
> >
> > Attached are some data to help.
> >
> >
> > Thanks,
> > Para-dox ([EMAIL PROTECTED])
> >
> >
>

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Manfred Spraul]

David Woodhouse wrote:
> 
> TIOCMIWAIT does restore_flags() before interruptible_sleep_on(). It's
> broken too.
>
Yes, and I found a second bug: it doesn't sti() immediately after
interruptible_sleep_on(), thus cli() doesn't reacquire the global irq
lock --> the atomic copy won't be atomic on SMP.


And one more point for the Janitor's list:
Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
either spin_lock_irq() or spin_lock() is sufficient. That's both faster
and better readable.

spin_lock_irq(): you know that the function is called with enabled
interrupts.
spin_lock(): can be used in hardware interrupt handlers when only one
hardware interrupt uses that spinlocks (most hardware drivers), or when
all hardware interrupt handler set the SA_INTERRUPT flag (e.g. rtc and
timer interrupt)

There is one more rule when you can use spin_lock_irq():
if you know that the function might sleep. E.g. compare make_request
from 2.2.18 and __make_request() from 2.4.
Since __get_request_wait() can sleep, the callers of make_request()
cannot rely on disabled interrupts, thus spin_lock_irq instead of
spin_lock_irqsave().

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

Re: ECN: Clearing the air (fwd)

[Rogier Wolff]

jamal wrote:
> > Yes,
> > those firewalls should be updated to allow ECN-enabled packets
> > through. However, to break connectivity to such sites deliberately just
> > because they are not supporting an *experimental* extension to the current
> > protocols is rather silly.
> >
> 
> This is the way it's done with all protocols. or i should say the way it
> used to be done. How do you expect ECN to be deployed otherwise?

Thinking about this a bit more:

A sufficiently paranoid firewall should block requests that he doesn't
fully understand. ECN was in this category, so old firewalls are
"right" to block these. (Sending an 'RST' is not elegant. So be it.)

However, ECN is now "understood", and operators are now in a position
to configure their firewall to "do the right thing". This is
subjective.  If the firewall operator is sufficiently paranoid, they
can say: "We don't trust the ECN implementation on our hosts behind
the firewall, so we want to disable it.". Firewall operators make
"lose connectivity to certain hosts/ports" decisions all the time.
That's what a firewall is about.

So... I think that the hotmail operators (or was it somewhere else
that started this debate?) simply get to chose. Lose connectivity to
part of the world because they block ECN or not.

But let it be known that it is THEIR decision. 


- If you implement a standard badly, you can get to be inoperable if
the standard gets expanded. That's what's happening here. Happens all
the time. 

- Note that Dave politely waited with announcing the impending
"cutoff" until he verified for sure that they did have a CHOICE.  

- The users (/customers) have gotten two weeks to bother the operators
into action, and the operators then have two weeks left to schedule
the upgrade. That seems pretty fair and resonable to me. 


Roger.

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: patch for 2.4.0 disable printk

[Jamie Lokier]

Stefani Seibold wrote:
> The inline function is the best choice, because it it full compatible to old 
> old printk. No side effects are expeted.

What is the difference?
I can't think of any difference between:

  #define printk(format, args...) ((int) 0)

and:

  static inline int printk_inline (void) { return 0; }
  #define printk(format, args...) (printk_inline ())

If you wanted to be fully compatible in the sense of evaluating the
printk arguments, in case those have side effects, there would be:

  #define printk(format, args...) ((0 , ## args), (int) 0)

By the way, CONFIG_NO_PRINTK or CONFIG_DISABLE_PRINTK would be better
names.  CONFIG_PRINTK suggests that enabling that option enabled printk.

enjoy,
-- Jamie

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

[patch] new, scalable timer implementation, smptimers-2.4.0-B1

[Ingo Molnar]

a new, 'ultra SMP scalable' implementation of Linux kernel timers is now
available for download:

http://www.redhat.com/~mingo/scalable-timers/smptimers-2.4.0-B1

the patch is against 2.4.1-pre10 or ac12. The timer design in this
implementation is a work of David Miller, Alexey Kuznetsov and myself.

Internals: the current 2.4 timer implementation uses a global spinlock for
synchronizing access to the global timer lists. This causes excessive
cacheline ping-pongs and visible performance degradation under very high
TCP networking load (and other, timer-intensive operations).

The new implementation introduces per-CPU timer lists and per-CPU
spinlocks that protect them. All timer operations, add_timer(),
del_timer() and mod_timer() are still O(1) and cause no cacheline
contention at all (because all data structures are separated). All
existing semantics of Linux timers are preserved, so the patch is
'transparent' to all other subsystems.

In addition, the role of TIMER_BH has been redefined, and run_local_timers
is used directly from APIC timer interrupts to run timers (not from
TIMER_BH). This means that timer expiry is per-CPU as well - it is global
in vanilla 2.4. Every timer is started and expired on the CPU where it has
been added. Timers get migrated between CPUs if mod_timer() is done on
another CPU (because eg. a process using them migrates to another CPU.).
In the typical case timer handling is completely localized to one CPU.

The new timers still maintain 'semantical compatibility' with older
concepts such as the IRQ lock and manipulation of TIMER_BH state. These
constructs are quite rare already, in 2.5 they can be removed completely.

the patch has been sanity tested on UP-pure, UP-APIC, UP-IOAPIC and SMP
systems. Reports/comments/questions/suggestions welcome!

Ingo

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

Re: Linux Post codes during runtime, possibly OT

[Jamie Lokier]

H. Peter Anvin wrote:
> It is; you'd have to specify "eax" as a clobber value, and that is
> undesirable.

For outb_p, EAX is used, usually for the last time, in the preceding
"out" instruction so clobbering it is not a big deal.

For inb_p, you first have to copy EAX to another register before
outputting the post_byte.  That's a small penalty.  Are in[bwl]_p used
anywhere time critical?  (Richard Johnson's explanation for outb_p
implies that inb_p is not required, but perhaps that explanation doesn't
tell the whole story).

> And you're still overwriting the POST value written by the BIOS.

Can the BIOS-written value be read from port 0x80?

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

Re: ps hang in 241-pre10

[Linus Torvalds]

On Sun, 28 Jan 2001, Marcelo Tosatti wrote:
> 
> Why dont you just put set_page_dirty() back in page_launder() in case
> writepage() fails?

Because a EIO or similar should _not_ be re-tried or kept dirty.

Imagine a bad user that goes over his quota on purpose, and then every
single write will always return an error. What should we do? Let him eat
all physical memory? I don't think so. 

write-out errors will be ignored. We _might_ send a signal or something,
but considering the fact that we don't even know who caused the dirty page
in the first place, even that is kind of hard.

Shared memory and out-of-swap is special - the shared memory code is
supposed to check that we have enough memory before it even allocates
anything.

Linus

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

troubles with devfs ?

[Pierfrancesco Caci]

This happens on a freshly booted 2.4.0 macine, with devfs and devfsd
running.

I got the oops by doing
# cd /dev
# ls -las
(segmentation fault)

The first oops causes the death of devfsd.


I still can do 
# ls -als /dev/sc*
   0 lr-xr-xr-x1 root root3 Jan 28 18:10 /dev/scd0-> sr0
   0 lr-xr-xr-x1 root root3 Jan 28 18:10 /dev/scd1-> sr1
   0 lr-xr-xr-x1 root root3 Jan 28 18:10 /dev/scd2-> sr2
   0 lr-xr-xr-x1 root root3 Jan 28 18:10 /dev/scd3-> sr3
   0 lr-xr-xr-x1 root root3 Jan 28 18:10 /dev/scd4-> sr4
   0 lr-xr-xr-x1 root root3 Jan 28 18:10 /dev/scd5-> sr5
   0 lr-xr-xr-x1 root root3 Jan 28 18:10 /dev/scd6-> sr6
   0 lr-xr-xr-x1 root root3 Jan 28 18:10 /dev/scd7-> sr7

/dev/scsi:
total 0
   0 drwxr-xr-x1 root root0 Jan  1  1970 .
   0 drwxr-xr-x1 root root0 Jan  1  1970 ..
   0 drwxr-xr-x1 root root0 Jan  1  1970 host0

or whatever else... Just "ls /dev" doesn't work any more.

It worked until ... er...  a few days ago, I suppose. I've updated a bunch
of libraries in the meantime, including libc.



ksymoops complains about System.map not matching the kernel, but I'm
sure it comes from the same compilation.




ksymoops 2.3.7 on i686 2.4.0.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0/ (default)
 -m /boot/System.map-2.4.0 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Warning (compare_maps): ksyms_base symbol acpi_clear_event_R__ver_acpi_clear_event not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_cm_memcpy_R__ver_acpi_cm_memcpy not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_cm_memset_R__ver_acpi_cm_memset not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_cm_strncmp_R__ver_acpi_cm_strncmp not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_dbg_layer_R__ver_acpi_dbg_layer not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_dbg_level_R__ver_acpi_dbg_level not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_disable_event_R__ver_acpi_disable_event 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_enable_event_R__ver_acpi_enable_event 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_evaluate_object_R__ver_acpi_evaluate_object not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_current_resources_R__ver_acpi_get_current_resources not found in System.map.  
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_get_handle_R__ver_acpi_get_handle not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_get_name_R__ver_acpi_get_name not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_next_object_R__ver_acpi_get_next_object not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_object_info_R__ver_acpi_get_object_info not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_get_parent_R__ver_acpi_get_parent not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_possible_resources_R__ver_acpi_get_possible_resources not found in 
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_processor_cx_info_R__ver_acpi_get_processor_cx_info not found in System.map.  
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_processor_throttling_info_R__ver_acpi_get_processor_throttling_info not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_processor_throttling_state_R__ver_acpi_get_processor_throttling_state not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_get_type_R__ver_acpi_get_type not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 

Re: ECN: Clearing the air (fwd)

[James Sutherland]

On Sun, 28 Jan 2001, jamal wrote:
> On Sun, 28 Jan 2001, James Sutherland wrote:
> > On Sun, 28 Jan 2001, jamal wrote:
> > > There were people who made the suggestion that TCP should retry after a
> > > RST because it "might be an anti-ECN path"
> >
> > That depends what you mean by "retry"; I wanted the ability to attempt a
> > non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of
> > Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be
> > able to retry with ECN disabled for that connection.
> 
> We are allowing two rules to be broken, one is RFC 793 which
> clearly and unambigously defines what a RST means. the second is

This is NOT being violated: the RST is honoured as normal.

> the firewall or IDS box which clearly is in violation.

Disagreed: it is complying with firewall RFCs, rejecting suspect
packets. Sending an RST isn't a very bright way to do it, but that's
irrelevant: it happens. Deal with it.

> The simplest thing in this chaos is to fix the firewall because it is in
> violation to begin with.

It is not in violation, and you can't fix it: it's not yours.

> I think it is silly to try to be "robust against RSTs" because of ECN.
> What if the RST was genuine?

It is genuine, and is treated as such. There is no "robust against
RSTs" or anything else: just graceful handling of non-ECN routes.

> I see that we mostly have philosphical differences. You'd rather adapt
> to the criminal and most people would rather have the criminal adjust to
> society.

There is no "criminal": no rules are being broken. Since it is
"society" (or a tiny minority thereof) which has changed the rules, it is
"society" which must adapt to be compatible with existing rules.

> I think CISCO have been very good in responding fast. I blame the site
> owners who dont want to go beyond their 9-5 job and upgrade their boxes.
> In the old internet where only hackers were qualified for such jobs, the
> upgrade would have happened by now at hotmail. I suppose it's part of
> growing pains.

I'd have said that's still true - only "hackers" are qualified. The
problem is just that the staff doing (or attempting) the job aren't
necessarily qualified to do it properly...

> If you think the CISCOs were bad sending RSTs, i am sure you havent heard
> about the Raptor firewalls. They dont even bother to send you anything if
> you have ECN enabled ;-> Simply swallow your SYNs.

That's regarded as a better response, actually: just drop suspect packets.

> So tell me, what do you propose we deal with these? Do we further
> disambiguate or assume the packet was lost?
> I actually bothered calling Raptor, they chose to ignore me.

You mean they are still shipping a firewall which drops ECN
packets? Hrm...

> You should never ASSume anything about something that is "reserved".
> I posted the definition from the collegiate dictionary, but i am sure most
> dictionaries would give the same definition.

It isn't just reserved, though, it's stated "must be zero". Very poor
wording, but it's too late now.

> It's too bad we end up defining protocols using English. We should use
> mathematical equations to remove any ambiguity ;->

No, just use English properly. "Must be zero" doesn't actually mean "must
be set to zero when sending, and ignored when receiving/processing", which
is probably what the standard SHOULD have said.

However, it's too late now: ECN-disabled routes exist. ECN implementations
should degrade as well as possible when handling these circumstances.


James.

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[David Woodhouse]

On Sun, 28 Jan 2001, Manfred Spraul wrote:

> It isn't wrong to call schedule() with disabled interrupts - it's a
> feature ;-)
> Those 10% sleep_on() users that aren't broken use it:
> 
>  for(;;) {
>   cli();
>   if(condition)
>   break;
>   sleep_on(_wait_queue);
>   sti();
>  }

That's valid iff the wake_up() can only happen from an ISR.

> E.g. TIOCMIWAIT in drivers/char/serial.c - a nearly correct sleep_on()
> user.

TIOCMIWAIT does restore_flags() before interruptible_sleep_on(). It's 
broken too.

Anyway, if you're feeling pedantic, consider what happens if shutdown() is
called from rs_close() just before sleep_on() is called. Regardless of 
whether interrupts are disabled.

> But I doubt that 10% of the sleep_on() users are non-broken...

There are cases where you don't care if you miss a wakeup because you have
a timeout. So it's only suboptimal rather than broken. I did produce a 
patch to BUG() in sleep_on if the BKL isn't held, at one point. It was 
quite interesting.

> If you remove sleep_on(), then you can disallow calling schedule() with
> disabled local interrupts.

The remaining valid users of sleep_on are mainly filesystems - much fs
code gets called with the BKL held. I expect that to change during 2.5, at 
which point sleep_on can be terminated with extreme prejudice. 

-- 
dwmw2


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

Re: doesn't boot.

[John Kacur]

mike wrote:
> 
> Hi,  im not sure if im emailing the right place but its  a start. I just
> setup kernel 2.4.0 and well it doesnt boot.
> 
> it says " ok booting the kernel" then nothing happens on the screen, and
> I hear no activity from the computer. I tried it several times following
> the
> instructions, I did make mrproper, etc, tired putting the source in a
> different dir, etc. I remember to reinstall lilo, all the good stuff. Im
> not sure whats wrong.
> 
> My system is 2 466 celerons, abtit bp6 , 128ram, voodoo 3 3000,  maxtor
> hd, all custom built. Anyone have any ideas? thanks in advance.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

When you configured the kernel, did you remember to change the processor
type to "Pentium Pro/Celeron/Pentium II"?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: hotmail not dealing with ECN

[Jamie Lokier]

Dax Kelson wrote:
> Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
> 
> > Does ECN provide perceived benefits to the node using it?
> 
> Why are you even making suggestions when you haven't even read the RFC?
> 
> It seems that knowing what ECN is would be prerequisite to engaging in
> discussion about it.

I do know what ECN is thanks.  Whether it provides _actual_ perceived
benefits depends on how widely deployed ECN routers and servers are.

-- Jamie

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

compile error in 2.4.0

[Alan Chandler]

I'm probably doing something silly, but I have just tried to rebuild
the 2.4.0 kernel.  I changed a few config things and did

make dep clean bzlilo modules modules_install

and the following appeared.  I did a brief look around for the
declaration of skb_datarefp but couldn't find it. 


make[3]: Entering directory `/usr/src/linux/net/core'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -
fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686
-malign-functions=4 -c
-o sock.o sock.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -
fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686
-malign-functions=4 -c
-o skbuff.o skbuff.c
skbuff.c: In function `alloc_skb':
skbuff.c:208: warning: implicit declaration of function `skb_datarefp'
skbuff.c:208: invalid type argument of `->'
skbuff.c: In function `kfree_skbmem':
skbuff.c:257: warning: passing arg 1 of `atomic_dec_and_test' makes
pointer from integer witho
ut a cast
skbuff.c: In function `skb_clone':
skbuff.c:321: warning: passing arg 1 of `atomic_inc' makes pointer
from integer without a cast
make[3]: *** [skbuff.o] Error 1
make[3]: Leaving directory `/usr/src/linux/net/core'
Alan

[EMAIL PROTECTED]
http://www.chandler.u-net.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Manfred Spraul]

Arnaldo Carvalho de Melo wrote:
> 
> Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu:
> > >
> > > Anything which uses sleep_on() has a 90% chance of being broken. Fix
> > > them all, because we want to remove sleep_on() and friends in 2.5.
> > >
> >
> > Then you can add 'calling schedule() with disabled local interrupts()'
> > to your list.
> 
> any example of code doing this now? That way we can at least point it to
> interested people and say "look at driver foobar in kernel x.y.z and see
> how its wrong"
>

It isn't wrong to call schedule() with disabled interrupts - it's a
feature ;-)
Those 10% sleep_on() users that aren't broken use it:

 for(;;) {
cli();
if(condition)
break;
sleep_on(_wait_queue);
sti();
 }

E.g. TIOCMIWAIT in drivers/char/serial.c - a nearly correct sleep_on()
user.

But I doubt that 10% of the sleep_on() users are non-broken...

If you remove sleep_on(), then you can disallow calling schedule() with
disabled local interrupts.

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

Re: ECN: Clearing the air (fwd)

[James Sutherland]

On Sun, 28 Jan 2001, Miquel van Smoorenburg wrote:

> In article <[EMAIL PROTECTED]>,
> James Sutherland  <[EMAIL PROTECTED]> wrote:
> >On Sun, 28 Jan 2001, jamal wrote:
> >> The internet is a form of organized chaos, sometimes you gotta make
> >> these type of decisions to get things done. Imagine the joy _most_
> >> people would get flogging all firewall admins who block all ICMP.
> >
> >Blocking out ICMP doesn't bother me particularly. I know they should be
> >selective, but it doesn't break anything essential.
> 
> It breaks Path MTU Discovery. If you have a link somewhere in your
> network (not at an endpoint, or TCP MSS will take care of it) that
> has an MTU < 1500, you cannot reach hotmail and a lot of other sites
> either currently. It _does_ break essential things. Daily. I would
> get a lot of joy from flogging all firewall admins who block all ICMP.

Except you can detect and deal with these "PMTU black holes". Just as you
should detect and deal with ECN black holes. Maybe an ideal Internet
wouldn't have them, but this one does. If you can find an ideal Internet,
go code for it: until then, stick with the real one. It's all we've got.


James.

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

doesn't boot.

[mike]

Hi,  im not sure if im emailing the right place but its  a start. I just
setup kernel 2.4.0 and well it doesnt boot.

it says " ok booting the kernel" then nothing happens on the screen, and
I hear no activity from the computer. I tried it several times following
the
instructions, I did make mrproper, etc, tired putting the source in a
different dir, etc. I remember to reinstall lilo, all the good stuff. Im
not sure whats wrong.


My system is 2 466 celerons, abtit bp6 , 128ram, voodoo 3 3000,  maxtor
hd, all custom built. Anyone have any ideas? thanks in advance.


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

Re: 2.4.1-pre8 losing pages

[Andre Hedrick]

On Sun, 28 Jan 2001, Peter Horton wrote:

> Okay, scratch that. It does still happen when there's no swap, but for
> some reason it happens a lot less often. Looks like it's timing related,
> it only fails when using 7200rpm drives, not older 5400rpm ones (even
> though they too are using UDMA33). I've ruled out the filing system, the
> IDE controller, the drives and the RAM, so that leaves the kernel or the
> CPU - I'll try and beg/borrow/steal another CPU and try that. I can
> compile kernels / run X whilst the test is running without a problem so it
> looks like it's the bulk write that's the problem.

Peter, did the scratch-test series pass or fail?
Did it report any bit failures on the check?

Cheers,

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]
Please read the FAQ at http://www.tux.org/lkml/

flush_scheduled_tasks() question

[Manfred Spraul]

Is is intentional that tummy_task is not initialized?
Ok, it won't crash because the current __run_task_queue() implementation
doesn't call tq->routine if it's NULL, but IMHO it's ugly.

Additionally I don't like the loop in flush_scheduled_tasks(), what
about replacing it with a locked semaphore (same idea as vfork)?

I've attched an untested patch.

--
Manfred

--- context.c.orig  Sun Jan 28 17:02:35 2001
+++ context.c   Sun Jan 28 17:09:24 2001
@@ -22,7 +22,6 @@
 
 static DECLARE_TASK_QUEUE(tq_context);
 static DECLARE_WAIT_QUEUE_HEAD(context_task_wq);
-static DECLARE_WAIT_QUEUE_HEAD(context_task_done);
 static int keventd_running;
 static struct task_struct *keventd_task;
 
@@ -97,7 +96,6 @@
schedule();
remove_wait_queue(_task_wq, );
run_task_queue(_context);
-   wake_up(_task_done);
if (signal_pending(curtask)) {
while (waitpid(-1, (unsigned int *)0, __WALL|WNOHANG) > 0)
;
@@ -119,31 +117,24 @@
  * The caller should hold no spinlocks and should hold no semaphores which could
  * cause the scheduled tasks to block.
  */
-static struct tq_struct dummy_task;
 
-void flush_scheduled_tasks(void)
+static void up_semaphore(void* sem)
 {
-   int count;
-   DECLARE_WAITQUEUE(wait, current);
+   up((struct semaphore*)sem);
+}
 
-   /*
-* Do it twice. It's possible, albeit highly unlikely, that
-* the caller queued a task immediately before calling us,
-* and that the eventd thread was already past the run_task_queue()
-* but not yet into wake_up(), so it woke us up before completing
-* the caller's queued task or our new dummy task.
-*/
-   add_wait_queue(_task_done, );
-   for (count = 0; count < 2; count++) {
-   set_current_state(TASK_UNINTERRUPTIBLE);
+void flush_scheduled_tasks(void)
+{
+   DECLARE_MUTEX_LOCKED(sem);
+   struct tq_struct wakeup_task;
 
-   /* Queue a dummy task to make sure we get kicked */
-   schedule_task(_task);
+   wakeup_task.routine = up_semaphore;
+   wakeup_task.data = 
+   /* Queue a dummy task to make sure we get kicked */
+   schedule_task(_task);
 
-   /* Wait for it to complete */
-   schedule();
-   }
-   remove_wait_queue(_task_done, );
+   /* Wait for it to complete */
+   down();
 }

 int start_context_thread(void)

[patch] smbfs cache rewrite - 2nd try

[Urban Widmark]

Hello again

This patch is more complete than the version posted earlier. It implements
support for OS/2 (and possibly things even older than that :) and have
been more tested. This borrows a lot from the ncpfs dircache code.

Smbfs testers wanted, with or without highmem boxes.


Bugs (believed) fixed vs 2.4.1-pre10:
+ cache code would oops/lockup on highmem machines (too many kmap'ed pages
  and possibly a few other things)
+ readpage/writepage could oops on highmem machines (missing kmap)
+ listing long directories would fail on some dirs on some types of servers
  (from 2.2.18, has nothing to do with the cache code)

Improvements:
+ new cache code creates dentries and inodes from the "findfirst" data,
  reducing the number of smb requests needed to list a directory (ls -l)
  from n/x + n to n/x (where x is the number of entries that fit in one
  request).
+ new mount option, ttl, allows control over how long the cache is
  considered valid, default ttl=1000 (1 second).

Bugs introduced:
- date conversion may need to do timezone conversion in smbfs
- 'd; touch dd; d; rm DD; d', where d is an alias for ls -alF, will crash
  on the rm if the server is "old", tested vs a samba server configured to
  talk "LANMAN1". Does not crash when using "NT1".
  Don't know if this is a new or old bug yet.
- more?
  (this is where you come in ...)


Download ~57k from:
http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.1-pre10-cache-2.patch
(Apply using 'patch -p1' from the linux directory.)

/Urban

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Arnaldo Carvalho de Melo]

Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu:
> > 
> > Anything which uses sleep_on() has a 90% chance of being broken. Fix 
> > them all, because we want to remove sleep_on() and friends in 2.5. 
> >
> 
> Then you can add 'calling schedule() with disabled local interrupts()'
> to your list.

any example of code doing this now? That way we can at least point it to
interested people and say "look at driver foobar in kernel x.y.z and see
how its wrong"

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Arnaldo Carvalho de Melo]

Em Sun, Jan 28, 2001 at 12:28:50PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Jan 29, 2001 at 03:13:19AM +1100, Andrew Morton escreveu:
> > Arnaldo Carvalho de Melo wrote:
> > > 
> > > Please send additions and corrections to me and I'll try
> > > to keep it updated.
> > 
> > Here - have about 300 bugs:
> > 
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
> > 
> > A lot of the timer deletion races are hard to fix because of
> > the deadlock problem.
> 
> added, please keep sending, and as somebody pointed out: it is good to have
> explanations about what have to be done, so interested people can
> contribute, specially people that are looking to start helping and don't
> know where to start, now we can say "hey, pick one of these 300 bugs and
> start doing something!" ;)

I forgot to add: "Like Andrew did in the above URL" 8)

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

Re: ECN: Clearing the air (fwd)

[jamal]

On Sun, 28 Jan 2001, James Sutherland wrote:

> On Sun, 28 Jan 2001, jamal wrote:
> > There were people who made the suggestion that TCP should retry after a
> > RST because it "might be an anti-ECN path"
>
> That depends what you mean by "retry"; I wanted the ability to attempt a
> non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of
> Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be
> able to retry with ECN disabled for that connection.
>

We are allowing two rules to be broken, one is RFC 793 which
clearly and unambigously defines what a RST means. the second is
the firewall or IDS box which clearly is in violation.
The simplest thing in this chaos is to fix the firewall because it is in
violation to begin with.
I think it is silly to try to be "robust against RSTs" because of ECN.
What if the RST was genuine?

I see that we mostly have philosphical differences. You'd rather adapt
to the criminal and most people would rather have the criminal adjust to
society.

I think CISCO have been very good in responding fast. I blame the site
owners who dont want to go beyond their 9-5 job and upgrade their boxes.
In the old internet where only hackers were qualified for such jobs, the
upgrade would have happened by now at hotmail. I suppose it's part of
growing pains.
If you think the CISCOs were bad sending RSTs, i am sure you havent heard
about the Raptor firewalls. They dont even bother to send you anything if
you have ECN enabled ;-> Simply swallow your SYNs.
So tell me, what do you propose we deal with these? Do we further
disambiguate or assume the packet was lost?
I actually bothered calling Raptor, they chose to ignore me.

You should never ASSume anything about something that is "reserved".
I posted the definition from the collegiate dictionary, but i am sure most
dictionaries would give the same definition.

It's too bad we end up defining protocols using English. We should use
mathematical equations to remove any ambiguity ;->

cheers,
jamal

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

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Joe deBlaquiere]

Andrew Morton wrote:

> There has been surprisingly little discussion here about the
> desirability of a preemptible kernel.
> 

And I think that is a very intersting topic... (certainly more 
interesting than hotmail's firewalling policy ;o)

Alright, so suppose I dream up an application which I think really 
really needs preemption (linux heart pacemaker project? ;o) I'm just not 
convinced that linux would ever be the correct codebase to start with. 
The fundamental design of every driver in the system presumes that there 
is no preemption.

A recent example I came across is in the MTD code which invokes the 
erase algorithm for CFI memory. This algorithm spews a command sequence 
to the flash chips followed by a list of sectors to erase. Following 
each sector adress, the chip will wait for 50usec for another address, 
after which timeout it begins the erase cycle. With a RTLinux-style 
approach the driver is eventually going to fail to issue the command in 
time. There isn't any logic to detect and correct the preemption case, 
so it just gets confused and thinks the erase failed. Ergo, RTLinux and 
MTD are mutually exclusive. (I should probably note that I do not intend 
this as an indictment of RTLinux or MTD, but just an example of why 
preemption breaks the Linux driver model).

So what is the solution in the preemption case? Should we re-write every 
driver to handle the preemption? Do we need a cli_yes_i_mean_it() for 
the cases where disabling interrupts is _absolutely_ required? Do we 
push drivers like MTD down into preemptable-Linux? Do we push all 
drivers down?
In the meantime, fixing the few places where the kernel spends an 
extended period of time performing a task makes sense to me. If you're 
going to be busy for a while it is 'courteous' to allow the scheduler a 
chance to give some time to other threads. Of course it's hard to know 
when to draw the line.

So now I am starting to wonder about what needs to be profiled. Is there 
a mechanism in place now to measure the time spent with interrupts off, 
for instance? I know this has to have been quantified to some extent, right?

-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Manfred Spraul]

> 
> Anything which uses sleep_on() has a 90% chance of being broken. Fix 
> them all, because we want to remove sleep_on() and friends in 2.5. 
>

Then you can add 'calling schedule() with disabled local interrupts()'
to your list.

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Arnaldo Carvalho de Melo]

Em Mon, Jan 29, 2001 at 03:13:19AM +1100, Andrew Morton escreveu:
> Arnaldo Carvalho de Melo wrote:
> > 
> > Please send additions and corrections to me and I'll try
> > to keep it updated.
> 
> Here - have about 300 bugs:
> 
>   http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
> 
> A lot of the timer deletion races are hard to fix because of
> the deadlock problem.

added, please keep sending, and as somebody pointed out: it is good to have
explanations about what have to be done, so interested people can
contribute, specially people that are looking to start helping and don't
know where to start, now we can say "hey, pick one of these 300 bugs and
start doing something!" ;)

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Andrew Morton]

Arnaldo Carvalho de Melo wrote:
> 
> Please send additions and corrections to me and I'll try
> to keep it updated.

Here - have about 300 bugs:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html

A lot of the timer deletion races are hard to fix because of
the deadlock problem.

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

Re: [PATCH] devfsd, compiling on glibc22x

[Douglas Gilbert]

While on the subject of devfs:
  - it doesn't seem to have any entries for raw devices:
/dev/rawctl, /dev/raw/raw1, etc
  - when I upgraded to glibc 2.2 (via a rpm) in RH 7.0
this line in /etc/devfsd.conf caused devfsd to 
seg fault:
"LOOKUP  ^cdrom$  CFUNCTION  GLOBAL 
 symlink ${mntpnt}/cdroms/cdrom0 $devpath"
Rebuilding devfsd didn't help.

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

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

[Andrew Morton]

jamal wrote:
> 
> PS:- can you try it out with the ttcp testcode i posted?

Yup.  See below.  The numbers are almost the same as
with `zcs' and `zcc'.

The CPU utilisation code which was in `zcc' has been
broken out into a standalone tool, so the new `cyclesoak'
app is a general-purpose system load measurement tool.
It's fascinating to play with, if you're into that sort
of thing.

`cyclesoak' was used to measure ttcp-sf and NFS/UDP client
and server throughput.  The times()-based instrumentation
inside ttcp-sf doesn't (can't) give correct numbers.  2-4% CPU
at 100 mbps?  We wish :)

The zerocopy patch doesn't seem to affect NFS efficiency at
all.  Confused.

Excerpt from the rapidly swelling README:



NFS/UDP client results
==

Reading a 100 meg file across 100baseT.  The file is fully cached on
the server.  The client is the above machine.  You need to unmount the
server between runs to avoid client-side caching.

The server is mounted with various rsize and wsize options.

  Kernel   rsize wsize   mbyte/sec CPU

  2.4.1-pre10+zc   1024  1024 2.4 10.3%
  2.4.1-pre10+zc   2048  2048 3.7 11.4%
  2.4.1-pre10+zc   4096  4096 10.129.0%
  2.4.1-pre10+zc   8199  8192 11.928.2%
  2.4.1-pre10+zc  16384 16384 11.928.2%

  2.4.1-pre10  1024  1024  2.4 9.7%
  2.4.1-pre10  2048  2048  3.711.8%
  2.4.1-pre10  4096  4096 10.733.6%
  2.4.1-pre10  8199  8192 11.929.5%
  2.4.1-pre10 16384 16384 11.929.2%

Small diff at 8192.


NFS/UDP server results
==

Reading a 100 meg file across 100baseT.  The file is fully cached on
the server.  The server is the above machine.

  Kernel   rsize wsize   mbyte/sec CPU

  2.4.1-pre10+zc   1024  1024  2.619.1%
  2.4.1-pre10+zc   2048  2048  3.918.8%
  2.4.1-pre10+zc   4096  4096 10.034.5%
  2.4.1-pre10+zc   8199  8192 11.828.9%
  2.4.1-pre10+zc  16384 16384 11.829.0%

  2.4.1-pre10  1024  1024  2.618.5%
  2.4.1-pre10  2048  2048  3.918.6%
  2.4.1-pre10  4096  4096 10.933.8%
  2.4.1-pre10  8199  8192 11.829.0%
  2.4.1-pre10 16384 16384 11.829.0%

No diff.


ttcp-sf Results
===

Jamal Hadi Salim has taught ttcp to use sendfile.  See
http://www.cyberus.ca/~hadi/ttcp-sf.tar.gz

Using the same machine as above, and the following commands:

Sender:./ttcp-sf -t -c -l 32768 -v receiver_host
Receiver:  ./ttcp-sf -c -r -l 32768 -v sender_host

CPU

2.4.1-pre10-zerocopy, sending with ttcp-sf:10.5%
2.4.1-pre10-zerocopy, receiving with ttcp-sf:  16.1%

2.4.1-pre10-vanilla, sending with ttcp-sf: 18.5%
2.4.1-pre10-vanilla, receiving with ttcp-sf:   16.0%

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Michael H. Warfield]

On Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse wrote:

> [EMAIL PROTECTED] said:
> >  Please send additions and corrections to me and I'll try to keep it
> > updated.

> Anything which uses sleep_on() has a 90% chance of being broken. Fix
> them all, because we want to remove sleep_on() and friends in 2.5.

And friends meaning "interruptible_sleep_on"?  Great...  I've
got a driver with about a half a dozen of them.  Point me at the Doco
to fix please?

> --
> dwmw2

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

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[Arnaldo Carvalho de Melo]

Em Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse escreveu:
> 
> [EMAIL PROTECTED] said:
> >  Please send additions and corrections to me and I'll try to keep it
> > updated.
> 
> Anything which uses sleep_on() has a 90% chance of being broken. Fix
> them all, because we want to remove sleep_on() and friends in 2.5.

TODO updated, availabe at http://bazar.conectiva.com.br/~acme/TODO

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

Re: [OT] Re: hotmail not dealing with ECN

[Michael H. Warfield]

On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
> ...
> > An attack against an Xray system is much more likely to come from inside the
> > companies network.
> ...

> We are not talking about attacks here, we are talking about undefined
> behaviour when (perhaps poorly designed) systems encounter network
> packages that use new or experimental features: I have seen MRI scanners
> panic when they received SNMP queries and SNMP has been around for ages!

Couple of years ago I did a security advisory on OS/9 (the
Microware OS that was originally designed for 6809 processors).  It
had become quite popular for embedded controllers.  I think at the time
it was ranked one of the top three embedded controller operating systems
and was used in a large number of Allen Bradley controllers.  Read that
last statement as saying that it was in a GOD AWFULL number of HVAC
controllers and factory automation controllers around the entire world.

We stumbled onto a flaw in the protocol stacks in OS/9 and it
couldn't handle being hit with an ICMP redirect.  The incoming stack
didn't properly recognize it and created some weird state in the outgoing
stack.  The next time the controller tried to transmit something, the
controller hung leaving whatever it was controlling in what ever position
it was in, no matter what the consequences.  This was "discovered" the
hard way at a site where the network people had not even realized that
all of these controllers were connected to the main corporate network.
Envision hundreds of controllers suddenly freezing and an entire plant
rapidly grinding to a complete halt.

My contact at Microware told me that they never anticipated having
those controllers hooked up to a general purpose network and OS/9 was
designed for such a small footprint (Hey, I had a multitasking, multiuser,
dial-in system running on a RadioShack CoCo with 64K of memory running OS/9)
that they had no room for handling ICMP redirects so they hadn't coded
it into the stack.  Multiple mistakes and assumptions resulted in a
security advisory warning about potential threats to human health and
safety.  They were having a bad day...  Especially when CNN called them.  :-/
(They had been notified over 6 months prior to the publication of the
advisory, BTW...)

That advisory concluded to isolate all embedded controllers to
insulated subnets and configure all routers to refuse to pass ICMP
redirect packets.  Anyone want to take bets if it's been done to
any great extent?  It will take some factory being knocked on it's
ass and making CNN, and even then most people won't take action because
most of the admins don't know what's on their networks in those
environments.

Upgrading a lot of these old controllers also meant physically
removing and replacing EPROMS. (One claim to fame for OS/9 is that it
was totally PIC and could be copied straight into EPROM and run
equally well from EPROM or RAM at arbitrary addresses.)  That's even
assuming you knew where all your controllers were and how to get to them!

So...  Yeah...  I can understand what can happen when unknown
packets reach devices that were not designed to handle them.  Bad Juju...
And embedded controllers are a hell of a lot more plentyful than X-Ray
machines.

> Yours,
>   Dominik Kubla
> -- 
>   A lovely thing to see:   Kobayashi Issa
>  through the paper window's holes   (1763-1828)
> the galaxy.   [taken from: David Brin - Sundiver]

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

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

Re: ECN: Clearing the air (fwd)

[Ben Ford]

James Sutherland wrote:

> On Sun, 28 Jan 2001, Ben Ford wrote:
>
> > James Sutherland wrote:
> >
> > > I'm sure we all know what the IETF is, and where ECN came from. I haven't
> > > seen anyone suggesting ignoring RST, either: DM just imagined that,
> > > AFAICS.
> > >
> > > The one point I would like to make, though, is that firewalls are NOT
> > > "brain-damaged" for blocking ECN: according to the RFCs governing
> > > firewalls, and the logic behind their design, blocking packets in an
> > > unknown format (i.e. with reserved bits set) is perfectly legitimate. Yes,
> > > those firewalls should be updated to allow ECN-enabled packets
> > > through. However, to break connectivity to such sites deliberately just
> > > because they are not supporting an *experimental* extension to the current
> > > protocols is rather silly.
> >
> > Do keep in mind, we aren't breaking connectivity, they are.
>
> Let me guess: you're a lawyer? :-)
>
> This is a very strange definition: if someone makes a change such that
> their machine can no longer communicate with existing systems, I would say
> the person making the incompatible change is the one who broke it.
>
> Maybe my mains sockets should be waterproof: it's still my fault when
> pouring water over them causes problems, even if the standards say the
> socket should be waterproof!
>

Bad analogy.  Try this.  Jim-Bob down at your local Post Office starts rejecting
all your mail that has the 4 digit zip code extension (Not in wide use, but a
"proposed standard") because he's old school and doesn't know what it is -- maybe
its secret spy communications!!!

(Although this would have the side benefit of really reducing the amount of junk
mail received . . . . . . )

And no, I'm not a lawyer.

-b


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

Re: "no such 386 instruction" with gcc 2.95.2

[Matti Aarnio]

> > I think I must need to upgrade my assembler, but:
> > 2.4.0/Documentation/Changes does not list an assembler version.

It does, the "binutils" package contain the assembler and linker,
et.al. of that kind utilities.  The errors quoted below are
definitely due to "too old" assembler.

> > {standard input}: Assembler messages:
> > {standard input}:996: Error: no such 386 instruction: `movups'
> > {standard input}:1001: Error: no such 386 instruction: `prefetcht0'
> > {standard input}:1005: Error: no such 386 instruction: `movaps'

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

Re: [ANNOUNCE] Kernel Janitor's TODO list

[David Woodhouse]

[EMAIL PROTECTED] said:
>  Please send additions and corrections to me and I'll try to keep it
> updated.

Anything which uses sleep_on() has a 90% chance of being broken. Fix
them all, because we want to remove sleep_on() and friends in 2.5.

--
dwmw2


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

Re: patch for 2.4.0 disable printk and panic messages, third try

[Dmitry A. Fedorov]

On Sun, 28 Jan 2001, Stefani Seibold wrote:

> this is now the third try to release my patch for disabling all kernel 
> messages. It is usefull on deep embedded systems with no human interactions 

> --- linux/arch/s390/config.in Thu Nov 16 21:51:28 2000
> +++ linux.noprintk/arch/s390/config.inSun Jan 28 10:56:15 2001

> +bool 'Disable kernel messages' CONFIG_NOPRINTK


S/390 on embedded systems? :)

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

Re: patch for 2.4.0 disable printk and panic messages, third try

[Abramo Bagnara]

Stefani Seibold wrote:
> 
> Hi guys,
> 
> this is now the third try to release my patch for disabling all kernel
> messages. It is usefull on deep embedded systems with no human interactions
> and for rescue discs where the diskspace is always to less.
> 
> This patch has now the following features:
> 
> The macro printk throws away all parameters and calls now a funciton "inline
> int printk_inline(void)" which always return 0 integer. So it should be now
> compatibel to the original printk funciton.
> 

Then I suppose that you've checked that never in kernel printk arguments
have side effects, don't you ;-)

printk("%d", p());
printk("%d", a++);
etc.

You're changing semantics of a well known function and also if you don't
broke anything now, what grants this for the future?

You need also a big warning in printk documentation: "Note that
arguments may to be not evaluated" and hope everybody note it.

I'd prefer to rely on modern compiler smartness.

-- 
Abramo Bagnara   mailto:[EMAIL PROTECTED]

Opera Unica  Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project ishttp://www.alsa-project.org
sponsored by SuSE Linuxhttp://www.suse.com

It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ECN: Clearing the air (fwd)

[Andi Kleen]

On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
> > The internet is a form of organized chaos, sometimes you gotta make
> > these type of decisions to get things done. Imagine the joy _most_
> > people would get flogging all firewall admins who block all ICMP.
> 
> Blocking out ICMP doesn't bother me particularly. I know they should be
> selective, but it doesn't break anything essential.

Ever heard of path mtu discovery? For example you essentially blocked out 
most people behind IP tunnels from your site (at least those who do not
do MSS hacks) 

In addition to breaking pmtu disc (which is a real showstopper for many setups),
it also have some negative effects on your servers. For example when your
mail server is for some reason trying to contact an unreachable host to
deliver a mail it'll not notice except after having wasted lots of bandwidth
and resources trying to contact the host again and again, even when the ICMP
clearly tells that it won't work. 

-Andi (who would join into Miquel's flogging) 

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

patch for 2.4.0 disable printk and panic messages, third try

[Stefani Seibold]

Hi guys,

this is now the third try to release my patch for disabling all kernel 
messages. It is usefull on deep embedded systems with no human interactions 
and for rescue discs where the diskspace is always to less.

This patch has now the following features:

The macro printk throws away all parameters and calls now a funciton "inline 
int printk_inline(void)" which always return 0 integer. So it should be now 
compatibel to the original printk funciton.

The macro panic also throws away all parameter and calls a function 
"NORET_TYPE void panic_nomsg(void) ATTRIB_NORET", which is still the same as 
the old panic function, but without display an oops and reboot immidiately.
 
All parameters of printk and panic will be automatically removed by the 
compiler optimizions.

The old functions printk and panic will be also implemented and exported as 
silent functions for backward compatibility.

The name of the config variable is now CONFIG_NOPRINTK.

The option for disabling the printk and panic messages in in menu kernel 
hacking.

It is a normal behaviour, that you get now some compiler warnings like 
"variable not used", because some of the them are only used for output by 
printk or panic, which will be now removed by optimizing.

Greetings,
Stefani

-patch for 2.4.0 disable printk and panic -

diff -u --recursive --new-file linux/CREDITS linux.noprintk/CREDITS
--- linux/CREDITS   Sun Dec 31 18:27:57 2000
+++ linux.noprintk/CREDITS  Fri Jan 26 10:51:19 2001
@@ -2395,6 +2395,14 @@
 S: Oldenburg
 S: Germany
 
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Possibility to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for embedded systems
+D: and rescue disks)
+S: Munich
+S: Germany
+
 N: Darren Senn
 E: [EMAIL PROTECTED]
 D: Whatever I notice needs doing (so far: itimers, /proc)
diff -u --recursive --new-file linux/Documentation/Configure.help 
linux.noprintk/Documentation/Configure.help
--- linux/Documentation/Configure.help  Thu Jan  4 22:00:55 2001
+++ linux.noprintk/Documentation/Configure.help Sun Jan 28 10:57:29 2001
@@ -12139,6 +12179,14 @@
 
   If unsure, say Y, or else you won't be able to do much with your new
   shiny Linux system :-)
+
+Disable kernel messages
+CONFIG_NOPRINTK
+  This option allows you to disable all kernel messages by overriding
+  the printk function with an empty macro.
+  On small embedded systems, this save a lot of rom and ram space. On
+  server or desktop systems you want human readable outputs, so it is
+  normally the best choice to say N to this option.
 
 Support for console on virtual terminal
 CONFIG_VT_CONSOLE
diff -u --recursive --new-file linux/arch/alpha/config.in 
linux.noprintk/arch/alpha/config.in
--- linux/arch/alpha/config.in  Fri Dec 29 23:07:19 2000
+++ linux.noprintk/arch/alpha/config.in Sun Jan 28 10:56:21 2001
@@ -359,6 +359,7 @@
 fi
 
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 
 bool 'Legacy kernel start address' CONFIG_ALPHA_LEGACY_START_ADDRESS
 
diff -u --recursive --new-file linux/arch/arm/config.in 
linux.noprintk/arch/arm/config.in
--- linux/arch/arm/config.inThu Nov 16 21:51:28 2000
+++ linux.noprintk/arch/arm/config.in   Sun Jan 28 10:55:58 2001
@@ -414,6 +414,7 @@
 bool 'Verbose user fault messages' CONFIG_DEBUG_USER
 bool 'Include debugging information in kernel binary' CONFIG_DEBUG_INFO
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 if [ "$CONFIG_CPU_26" = "y" ]; then
bool 'Disable pgtable cache' CONFIG_NO_PGT_CACHE
 fi
diff -u --recursive --new-file linux/arch/i386/config.in 
linux.noprintk/arch/i386/config.in
--- linux/arch/i386/config.in   Fri Dec 29 23:35:47 2000
+++ linux.noprintk/arch/i386/config.in  Sun Jan 28 10:56:04 2001
@@ -374,4 +374,5 @@
 
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 endmenu
diff -u --recursive --new-file linux/arch/ia64/config.in 
linux.noprintk/arch/ia64/config.in
--- linux/arch/ia64/config.in   Thu Jan  4 21:50:17 2001
+++ linux.noprintk/arch/ia64/config.in  Sun Jan 28 10:56:07 2001
@@ -249,6 +249,7 @@
 fi
 
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 bool 'Early printk support (requires VGA!)' CONFIG_IA64_EARLY_PRINTK
 bool 'Turn on compare-and-exchange bug checking (slow!)' 
CONFIG_IA64_DEBUG_CMPXCHG
 bool 'Turn on irq debug checks (slow!)' CONFIG_IA64_DEBUG_IRQ
diff -u --recursive --new-file linux/arch/m68k/config.in 
linux.noprintk/arch/m68k/config.in
--- linux/arch/m68k/config.in   Thu Jan  4 22:00:55 2001
+++ linux.noprintk/arch/m68k/config.in  Sun Jan 28 10:56:09 2001
@@ -538,4 +538,5 @@
 
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 endmenu
diff -u --recursive --new-file 

[PATCH] udf writepage UnlockPage

[Hugh Dickins]

Although fs/udf's args to writepage() were updated in 2.4.0-test12,
its page unlocking was overlooked.  udf_adinicb_writepage() should
now UnlockPage, udf_expand_file_adinicb() should not now UnlockPage
after udf_writepage i.e. block_write_full_page.  Al Viro posted a
patch for the latter, still lurking in Alan's -ac12; the former seems
to have gone unnoticed.  Warning: from source inspection: untested.

(Originally sent ten days ago against 2.4.1-pre8, no comments
received: today seems topical to resend against 2.4.1-pre10.)

Hugh

--- linux-2.4.1-pre10/fs/udf/file.c Fri Dec 29 22:07:57 2000
+++ linux/fs/udf/file.c Thu Jan 18 15:42:11 2001
@@ -86,6 +86,7 @@
brelse(bh);
SetPageUptodate(page);
kunmap(page);
+   UnlockPage(page);
return 0;
 }
 
--- linux-2.4.1-pre10/fs/udf/inode.cTue Dec  5 17:41:51 2000
+++ linux/fs/udf/inode.cThu Jan 18 15:43:50 2001
@@ -203,7 +203,6 @@
udf_release_data(bh);
 
inode->i_data.a_ops->writepage(page);
-   UnlockPage(page);
page_cache_release(page);
 
mark_inode_dirty(inode);

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

setitimer() and fork()

[Kurt Roeckx]

I'm having a problem when I try to profile a program that
fork()'s. The problem is that it does count how many times I'm in
a function, but nothing seems to use any cpu time at all.

If I call setitmer(ITIMER_PROF, ...) again after the
fork, it works as expected.  fork() doesn't seem to copy the
timer(s). On other OS's, I don't seem to have to do this.

I'm having this problem with both 2.2, and 2.4.  I think it used
to work in older versions.

Is this a bug, or is this intentional?


Kurt

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

Re: ECN: Clearing the air (fwd)

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
James Sutherland  <[EMAIL PROTECTED]> wrote:
>On Sun, 28 Jan 2001, jamal wrote:
>> The internet is a form of organized chaos, sometimes you gotta make
>> these type of decisions to get things done. Imagine the joy _most_
>> people would get flogging all firewall admins who block all ICMP.
>
>Blocking out ICMP doesn't bother me particularly. I know they should be
>selective, but it doesn't break anything essential.

It breaks Path MTU Discovery. If you have a link somewhere in your
network (not at an endpoint, or TCP MSS will take care of it) that
has an MTU < 1500, you cannot reach hotmail and a lot of other sites
either currently. It _does_ break essential things. Daily. I would
get a lot of joy from flogging all firewall admins who block all ICMP.

Mike.

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

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

[Andi Kleen]

On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote:
> What is missing here is a good authoritative web ressource that tells
> people which NIC to buy.
> 
> I have a tulip NIC because a few years ago that apparently was the NIC
> of choice.  It has good multicast (which is important to me), but AFAIK
> it has neither scatter-gather nor hardware checksumming.
> 
> Is there such a web page already?
> If not, I volunteer to create amd maintain one.

Here a try for FastEthernet. Corrections/additions welcome.

Currently the 3c9xx cards look like the best commonly affordable ones,
at least when you care about zero copy networking. The newer ones have
all the necessary toys for it. 
Don't use them with the 3com vendor driver though, their driver is crap. 

eepro100 seems to have mostly the same facilities, but Intel doesn't 
document it fully so it is not usable in the standard Linux driver. They have
an own driver available (e100.c) which does more, but it of course lags in
progress to the normal stack.

I don't know about starfire, but it seems to be hard to even buy them anyways.

Sun HME seems to be on similar level as 3c9xx, but near impossible to buy or
very expensive.

Realtek is ok for low cost and being relatively hazzle free, but they
miss lots of useful facilities and basically require a copy for RX.

SMC epic/100 is handicapped by not being able to receive to unaligned addresses,
requiring in linux a driver level copy (that may change in 2.5 though, zero
copy has the necessary infrastructure to only copy the header in this case,
not the whole packet) 

AMD pcnet afaik doesn't do hardware checksums.

Tulip doesn't do hardware checksum and is a bit constrained by the 
required long word alignment in RX (causing problems with misaligned IP 
headers, see above on epic100) 

Advantage of Tulip and AMD is that they perform much better in my experience
on half duplex Ethernet than other cards because they a modified 
patented backoff scheme. Without it Linux 2.1+ tends to suffer badly from
ethernet congestion by colliding with the own acks, probably because it 
sends too fast.

-Andi


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

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Andrew Morton]

Bill Huey wrote:
> 
> Andrew Morton's patch uses < 10 rescheduling points (maybe less from memory)

err... It grew.  More like 50 now reiserfs is in there.  That's counting
real instances - it's not counting ones which are expanded multiple times
as "1".

It could be brought down to 20-25 with good results.  It seems to have
a 1/x distribution - double the reschedule count, halve the latency.
We're currently doing 300-400 usecs.

I think a 1.5-millisecond @ 500MHz kernel would be a good, maintainable
solution and a sensible compromise.

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

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Andrew Morton]

[EMAIL PROTECTED] wrote:
> 
> ...
> 
> I suggest that you get your hearing checked. I'm fully in favor of sensible
> low latency Linux. I believe however that low latency  in Linux will
> A. be "soft realtime", close to deadline most of the time.
> B. millisecond level on present hardware
> C. Best implemented by careful algorithm design instead of
> "stuff the kernel with resched points" and hope for the best.

Point C would be nice, but I don't believe it will happen because of

a) The sheer number of problem areas
b) The complexity of fixing them this way and
c) The low level of motivation to make Linux perform well in
   this area.

Main problem areas are the icache, dcache, pagecache, buffer cache,
slab manager, filemap and filesystems.  That's a lot of cantankerous
cats to herd.

In many cases it just doesn't make sense.  If we need to unmap 10,000
pages, well, we need to unmap 10,000 pages.  The only algorithmic
redesign we can do here is to free them in 500 page blobs.  That's
silly because we're unbatching work which can be usefully batched.
You're much better off unbatching the work *on demand* rather than
by prior decision.  And the best way of doing that is, yup, by
peeking at current->need_resched, or by preempting the kernel.

There has been surprisingly little discussion here about the
desirability of a preemptible kernel.

> 
> Nice marketing line, but it is not working code.
> 

Guys, please don't.

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

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

[Dan Hollis]

On Sun, 28 Jan 2001, Felix von Leitner wrote:
> What is missing here is a good authoritative web ressource that tells
> people which NIC to buy.
> I have a tulip NIC because a few years ago that apparently was the NIC
> of choice.  It has good multicast (which is important to me), but AFAIK
> it has neither scatter-gather nor hardware checksumming.
> Is there such a web page already?

http://www.anime.net/~goemon/cardz/

Based on discussions I've had with Donald Becker about chipsets.

For 100bt, 3c905C is the most efficient card at the moment.
I've no idea about gigglebit ethernet.

-Dan

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

Re: ECN: Clearing the air (fwd)

[James Sutherland]

On Sun, 28 Jan 2001, Ben Ford wrote:

> James Sutherland wrote:
> 
> > I'm sure we all know what the IETF is, and where ECN came from. I haven't
> > seen anyone suggesting ignoring RST, either: DM just imagined that,
> > AFAICS.
> >
> > The one point I would like to make, though, is that firewalls are NOT
> > "brain-damaged" for blocking ECN: according to the RFCs governing
> > firewalls, and the logic behind their design, blocking packets in an
> > unknown format (i.e. with reserved bits set) is perfectly legitimate. Yes,
> > those firewalls should be updated to allow ECN-enabled packets
> > through. However, to break connectivity to such sites deliberately just
> > because they are not supporting an *experimental* extension to the current
> > protocols is rather silly.
> 
> Do keep in mind, we aren't breaking connectivity, they are.

Let me guess: you're a lawyer? :-)

This is a very strange definition: if someone makes a change such that
their machine can no longer communicate with existing systems, I would say
the person making the incompatible change is the one who broke it.

Maybe my mains sockets should be waterproof: it's still my fault when
pouring water over them causes problems, even if the standards say the
socket should be waterproof!


James.

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

Re: 2.4 Cpu usuage (display oddities more than anything)

[safemode]

Linda Walsh wrote:

> Some oddities w/kapmd(2.4.0)...  If I sit in X and do nothing other than run top or
> "vmstat 5", I get down to as low as 60% idle and 40% in system -- with kapmd getting
> 'charged' for the 40%.
>
> Then I go and run 'freeamp' and the CPU usage goes to 100% idle, presumably because
> kapmd never gets called because it's never in the idle loop for longer than 333ms.
>
> It's just weird and unnatural.
>
> Also forgive my ignorance but is it really possible playing VBR MP3's takes 0 
>measurable
> CPU?  I've run the program for hours and a ps of 'freeamp' show either no measured 
>cpu
> time or maybe 1 second...the kernel runs at at 100% idle for most of the time.
> I thought mp3 decompression was a cpu intensive operationweird...
>
> I guess I'm thinking -- maybe time in kapmd should be counted as 'idle'?
>

  freeamp is just that good.  I've seen 0% cpu usage with it on 2.4 and 2.2.   if you
notice closely, it does use  a percentage of cpu but it's so small that over the 
course of
time that the cpu usage of each process is averaged, it is closer to 0 than 1.  It is 
hands
down the best mp3 player i've seen out.

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

sandisk sddr31 or scsi problems, double occurence

[Norbert Preining]

Hi!

I have a problem with my sandisk sddr31 occuring 2 times while only
one is installed. My configuration:

linux-2.4.1-pre10
hotplug-scripts (newest)
ohci

I attach the output of cat /proc/bus/usb/devices, here only one
sddr is occuring, and various cat's from my /proc/scsi dir

Please, tell me how I can try to debug this problem.

-- 
ciao
norb

+---+
| Norbert Preining  http://www.logic.at/people/preining |
| University of Technology Vienna, Austria[EMAIL PROTECTED] |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+---+


T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=129/900 us (14%), #Int=  2, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor= ProdID= Rev= 0.00
S:  Product=USB OHCI Root Hub
S:  SerialNumber=c8e7a000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=1.5 MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c002 Rev= 1.20
S:  Manufacturer=Logitech
S:  Product=USB-PS/2 Mouse M-BA47
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 50mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl= 10ms
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 4
D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=03eb ProdID=3301 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=255ms
T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#=  4 Spd=1.5 MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c207 Rev= 1.04
S:  Manufacturer=Logitech Inc.
S:  Product=WingMan Extreme Digital 3D
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 20mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl= 10ms
T:  Bus=01 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0781 ProdID=0002 Rev= 0.09
S:  Manufacturer=SanDisk Corporation
S:  Product=ImageMate CompactFlash USB
S:  SerialNumber=0005
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=  0ms
T:  Bus=01 Lev=02 Prnt=03 Port=02 Cnt=03 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0471 ProdID=0308 Rev= 0.06
S:  SerialNumber=02130211A0101AB1
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS=   0 Ivl=  1ms
I:  If#= 0 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 196 Ivl=  1ms
I:  If#= 0 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 292 Ivl=  1ms
I:  If#= 0 Alt= 3 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 448 Ivl=  1ms
I:  If#= 0 Alt= 4 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 592 Ivl=  1ms
I:  If#= 0 Alt= 5 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 704 Ivl=  1ms
I:  If#= 0 Alt= 6 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 776 Ivl=  1ms
I:  If#= 0 Alt= 7 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 840 Ivl=  1ms
I:  If#= 0 Alt= 8 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 896 Ivl=  1ms
I:  If#= 0 Alt= 9 #EPs= 2 Cls=0a(data ) Sub=ff Prot=00 Driver=Philips webcam
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=100ms
E:  Ad=84(I) Atr=01(Isoc) MxPS= 960 Ivl=  1ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=(none)
E:  Ad=85(I) Atr=05(Isoc) MxPS=   0 Ivl=  1ms
I:  If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=(none)
E:  Ad=85(I) Atr=05(Isoc) MxPS=  90 Ivl=  1ms
I:  If#= 2 Alt= 2 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=(none)
E:  Ad=85(I) 

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Bill Huey]

On Sun, Jan 28, 2001 at 06:14:28AM -0700, [EMAIL PROTECTED] wrote:
> > Yes, I most emphatically do disagree with Victor!  IRIX is used for
> > mission-critical audio applications - recording as well playback - and
> And it has bloat, it's famously buggy, it is impossible to maintain, ...

However, that doesn't fault its concepts and its original goals. This
kind stuff is often more of an implementation and bad abstraction issue than
about faulty design and end goals.

> > used.  I will be very happy when Linux is as good in all these areas,
> > and I'm working hard to achieve this goal with negligible impact on the
> > current Linux "sweet-spot" applications such as web serving.
> As stated previously: I think this is a proven improbability and I have
> not seen any code or designs from you to show otherwise.

Andrew Morton's patch uses < 10 rescheduling points (maybe less from memory)
and in controlled, focused and logical places. It's certainly not a unmaintainable
mammoth unlike previous attempts, since Riel (many thanks) has massively
cleaned up the VM layer by using more reasonable algorithms, etc...

> I suggest that you get your hearing checked. I'm fully in favor of sensible
> low latency Linux. I believe however that low latency  in Linux will
>   A. be "soft realtime", close to deadline most of the time.

Which is very good and maintainable with Andrew's patches.

>   B. millisecond level on present hardware

Also very good an useable for many applications short of writting dedicated
code on specialized DSP cards.

>   C. Best implemented by careful algorithm design instead of 
>   "stuff the kernel with resched points" and hope for the best.

Algorithms ? which ones ? VM layer, scheduler ?  It seems there's enough
there in the Linux kernel to start doing interesting stuff, assuming that
there's a large enough media crowd willing to do the userspace programming.

> > for low-latency tasks.  RTLinux is not Linux, it is a separate
> > environment with a separate, limited set of APIs.  You can't run XMMS,
> > or any other existing Linux audio app in RTLinux.  I want a low-latency
> > Linux, not just another RTOS living parasitically alongside Linux.
 
> Nice marketing line, but it is not working code.

Mean what ? How does that response answer his criticism ?

bill

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

Re: ECN: Clearing the air (fwd)

[Ben Ford]

James Sutherland wrote:

> I'm sure we all know what the IETF is, and where ECN came from. I haven't
> seen anyone suggesting ignoring RST, either: DM just imagined that,
> AFAICS.
>
> The one point I would like to make, though, is that firewalls are NOT
> "brain-damaged" for blocking ECN: according to the RFCs governing
> firewalls, and the logic behind their design, blocking packets in an
> unknown format (i.e. with reserved bits set) is perfectly legitimate. Yes,
> those firewalls should be updated to allow ECN-enabled packets
> through. However, to break connectivity to such sites deliberately just
> because they are not supporting an *experimental* extension to the current
> protocols is rather silly.

Do keep in mind, we aren't breaking connectivity, they are.

-b


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

Re: Oops accessing file on 2048 bytes/sector vfat MO in 2.4.0

[Stefan Meyknecht]

In article  you wrote:
> ... and on a fair number < 2.4.0. The patch below will give you (dog slow)
> read access to your FAT MOs. Apply in fs/fat/. And don't even think about
> write() and mmap().

Thanks for the patch! The oops is gone, but now after reading a file from the MO-disk
I receive an I/O error even though the file is successfully copied. Writing to the 
MO-disk freezes the system!

Regards

Stefan

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

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

[Felix von Leitner]

Thus spake Andrew Morton ([EMAIL PROTECTED]):
> Conclusions:

>   For a NIC which cannot do scatter/gather/checksums, the zerocopy
>   patch makes no change in throughput in all case.

>   For a NIC which can do scatter/gather/checksums, sendfile()
>   efficiency is improved by 40% and send() efficiency is decreased by
>   10%.  The increase and decrease caused by the zerocopy patch will in
>   fact be significantly larger than these two figures, because the
>   measurements here include a constant base load caused by the device
>   driver.

What is missing here is a good authoritative web ressource that tells
people which NIC to buy.

I have a tulip NIC because a few years ago that apparently was the NIC
of choice.  It has good multicast (which is important to me), but AFAIK
it has neither scatter-gather nor hardware checksumming.

Is there such a web page already?
If not, I volunteer to create amd maintain one.

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

Re: ECN: Clearing the air (fwd)

[James Sutherland]

On Sun, 28 Jan 2001, jamal wrote:
> On Sun, 28 Jan 2001, James Sutherland wrote:
> 
> > I'm sure we all know what the IETF is, and where ECN came from. I haven't
> > seen anyone suggesting ignoring RST, either: DM just imagined that,
> > AFAICS.
> 
> The email was not necessarily intended for you. You just pulled the pin.
> There were people who made the suggestion that TCP should retry after a
> RST because it "might be an anti-ECN path"

That depends what you mean by "retry"; I wanted the ability to attempt a
non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of
Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be
able to retry with ECN disabled for that connection.

> > The one point I would like to make, though, is that firewalls are NOT
> > "brain-damaged" for blocking ECN: according to the RFCs governing
> > firewalls, and the logic behind their design, blocking packets in an
> > unknown format (i.e. with reserved bits set) is perfectly legitimate.
> 
> I dont agree that unknown format == reserved. I think it is bad design to
> assume that. You may be forgiven if you provide the operator
> opportunities to reset your assumptions via a config option.
> It has nothing to do with a paranoia setting, just a bad design. Nothing
> legit about that.

On the contrary: rejecting weird-looking traffic is perfectly legit. I
agree RST is the wrong response, but it's too late to tell Cisco that
now...

> > Yes,
> > those firewalls should be updated to allow ECN-enabled packets
> > through. However, to break connectivity to such sites deliberately just
> > because they are not supporting an *experimental* extension to the current
> > protocols is rather silly.
> 
> This is the way it's done with all protocols. or i should say the way it
> used to be done. How do you expect ECN to be deployed otherwise?

The current versions of these firewalls handle ECN OK. I just want Linux
to degrade gracefully when unable to use ECN: it will be a while before
all these firewalls have gone.

> The internet is a form of organized chaos, sometimes you gotta make
> these type of decisions to get things done. Imagine the joy _most_
> people would get flogging all firewall admins who block all ICMP.

Blocking out ICMP doesn't bother me particularly. I know they should be
selective, but it doesn't break anything essential.

> There is nothing silly with the decision, davem is simply a modern day
> internet hero.

No. If it were something essential, perhaps, but it's just a minor
performance tweak to cut packet loss over congested links. It's not
IPv6. It's not PMTU. It's not even very useful right now!


James.

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

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[yodaiken]

On Sun, Jan 21, 2001 at 06:21:05PM -0800, Nigel Gamble wrote:
> Yes, I most emphatically do disagree with Victor!  IRIX is used for
> mission-critical audio applications - recording as well playback - and
> other low-latency applications.  The same OS scales to large numbers of
> CPUs.  And it has the best desktop interactive response of any OS I've

And it has bloat, it's famously buggy, it is impossible to maintain, ...


> used.  I will be very happy when Linux is as good in all these areas,
> and I'm working hard to achieve this goal with negligible impact on the
> current Linux "sweet-spot" applications such as web serving.

As stated previously: I think this is a proven improbability and I have
not seen any code or designs from you to show otherwise.

> I agree.  I'm not wedded to any particular design - I just want a
> low-latency Linux by whatever is the best way of achieving that.
> However, I am hearing Victor say that we shouldn't try to make Linux
> itself low-latency, we should just use his so-called "RTLinux" environment

I suggest that you get your hearing checked. I'm fully in favor of sensible
low latency Linux. I believe however that low latency  in Linux will
A. be "soft realtime", close to deadline most of the time.
B. millisecond level on present hardware
C. Best implemented by careful algorithm design instead of 
"stuff the kernel with resched points" and hope for the best.

RTLinux main focus is hard realtime: a few microseconds here and there
are critical for us and for the applications we target. For consumer
audio, this is overkill and vanilla Linux should be able to provide
services reasonably well. But ...

> for low-latency tasks.  RTLinux is not Linux, it is a separate
> environment with a separate, limited set of APIs.  You can't run XMMS,
> or any other existing Linux audio app in RTLinux.  I want a low-latency
> Linux, not just another RTOS living parasitically alongside Linux.

Nice marketing line, but it is not working code.


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

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

Re: Kernel 2.4.0 loop device still hangs

[Andreas Franck]

Hi Jens,

I've tested your patch quite as heavy as it gets: I created 5 files of each 
100 MB, set up 5 loop devices and made a RAID5 array out of them, putting 
ext2 on it and running a bonnie loop with 350 MB test size over it for the 
night.

Everything survived, worked flawlessly and I'm happy my disk did too :-)
Many thanks for the fine work!

Greetings,
Andreas

-- 
->>>--- Andreas Franck <<<-
---<<< [EMAIL PROTECTED] --->>>---
->>> Keep smiling! <<<-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] make drivers/scsi/sym53c8xx.c check request_region'sreturn code (241p9)]

[Gérard Roudier]

On Thu, 25 Jan 2001, Rasmus Andersen wrote:

> Hi.
> 
> I apparently forgot to cc the lists on this one. Replies should be cc'ed
> to [EMAIL PROTECTED] also.
> 
> Thanks.

The change should not harm, but request_region() is very unlikely to fail
here. Reason is that the drivers previously perform a check_region() in
order to synchronyze with any other driver that may have attached the same
device (candidates are : sym53c8xx, ncr53c8xx, 53c7,8xx)

By the way, as PCI only device drivers, the [sym|ncr]53c8xx drivers want
to use MMIO and not normal IO. The 'normal IO' path is here for archs that
donnot want to accept MMIO. Note that there are a couple of strangenesses
here:

1) The FreeBSD sym driver (derived from sym53c8xx) works with MMIO on
   FreeBSD/Alpha, but the sym53c8xx fails MMIO under Linux/Alpha.
2) Power/PC port wants drivers to use normal IOs even on machines that
   only have MMIO.

(2) looks rather a weirdness than a strangeness. :-)

Gérard.

> - Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -
> 
> Date: Tue, 23 Jan 2001 23:37:14 +0100
> From: Rasmus Andersen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PATCH] make drivers/scsi/sym53c8xx.c check request_region's return code 
>(241p9)
> User-Agent: Mutt/1.2.4i
> 
> Hi.
> 
> The following patch makes drivers/scsi/sym53c8xx.c check the return
> code of request_region. It applies cleanly against ac10 and 241p9.
> 
> Please comment.
> 
> 
> 
> --- linux-ac10-clean/drivers/scsi/sym53c8xx.c Mon Jan  1 19:23:21 2001
> +++ linux-ac10/drivers/scsi/sym53c8xx.c   Sun Jan 21 21:40:54 2001
> @@ -5817,7 +5817,11 @@
>   */
>  
>   if (device->slot.io_port) {
> - request_region(device->slot.io_port, np->base_ws, NAME53C8XX);
> + if (!request_region(device->slot.io_port, np->base_ws, 
> + NAME53C8XX)) {
> + printk(KERN_ERR "Cannot mmap IO range.\n");
> + goto attach_error;
> + }
>   np->base_io = device->slot.io_port;
>   }
> 
> --- linux-ac10-clean/drivers/scsi/sym53c8xx_comm.hMon Oct 16 21:56:50 2000
> +++ linux-ac10/drivers/scsi/sym53c8xx_comm.h  Mon Jan 22 21:56:46 2001
> @@ -1799,7 +1799,8 @@
>   **Get access to chip IO registers
>   */
>  #ifdef NCR_IOMAPPED
> - request_region(devp->slot.io_port, 128, NAME53C8XX);
> + if (!request_region(devp->slot.io_port, 128, NAME53C8XX))
> + return;
>   devp->slot.base_io = devp->slot.io_port;
>  #else
>   devp->slot.reg = (struct ncr_reg *) remap_pci_mem(devp->slot.base, 128);
> 
> 
> -- 
> Regards,
> Rasmus([EMAIL PROTECTED])
> 
> It isn't pollution that's harming the environment. It's the impurities in
> our air and water that are doing it.  -Former U.S. Vice-President Dan
> Quayle
> 
> - End forwarded message -
> 
> -- 
> Regards,
> Rasmus([EMAIL PROTECTED])
> 
> Freedom of the press is limited to those who own one.
>  - A.J. Liebling 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

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

Re: ECN: Clearing the air (fwd)

[jamal]

On Sun, 28 Jan 2001, James Sutherland wrote:

> I'm sure we all know what the IETF is, and where ECN came from. I haven't
> seen anyone suggesting ignoring RST, either: DM just imagined that,
> AFAICS.

The email was not necessarily intended for you. You just pulled the pin.
There were people who made the suggestion that TCP should retry after a
RST because it "might be an anti-ECN path"

>
> The one point I would like to make, though, is that firewalls are NOT
> "brain-damaged" for blocking ECN: according to the RFCs governing
> firewalls, and the logic behind their design, blocking packets in an
> unknown format (i.e. with reserved bits set) is perfectly legitimate.

I dont agree that unknown format == reserved. I think it is bad design to
assume that. You may be forgiven if you provide the operator
opportunities to reset your assumptions via a config option.
It has nothing to do with a paranoia setting, just a bad design. Nothing
legit about that.

> Yes,
> those firewalls should be updated to allow ECN-enabled packets
> through. However, to break connectivity to such sites deliberately just
> because they are not supporting an *experimental* extension to the current
> protocols is rather silly.
>

This is the way it's done with all protocols. or i should say the way it
used to be done. How do you expect ECN to be deployed otherwise?
The internet is a form of organized chaos, sometimes you gotta make
these type of decisions to get things done. Imagine the joy _most_
people would get flogging all firewall admins who block all ICMP.
There is nothing silly with the decision, davem is simply a modern day
internet hero.

cheers,
jamal

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

Re: Knowing what options a kernel was compiled with

[Andreas Ehliar]

On Sun, Jan 28, 2001 at 04:29:06PM +1100, Keith Owens wrote:
> On Sun, 28 Jan 2001 00:13:48 -0500, 
> "Matthew Pitts" <[EMAIL PROTECTED]> wrote:
> >Some distributions DO include the config. It may be located
> >in the /boot dir with a name CONFIG-2.2.10 or similar. I
> >know that Caldera 2.3 shiped that way(2.4 may also). If you
> >have the install CDROM, the kernel source install may have
> >it (e.g. Linux-Mandrake 7.x).
> 
> I know that some distributions ship .config but not all do.  A long way
> down on my TODO list is "submit a requirement to FHS that .config,
> System.map and other kernel related text files must be shipped in
> directory ".  I would like  to be /lib/modules/`uname -r`
> since that directory is already kernel specific, but we have to handle
> kernels without modules and disks with restricted size in /lib.
> However that discussion is best held on the FHS/LSB lists, not l-k.

Speaking of .config, wouldn't it make sense to add some comments to the
beginning of that file detailing at least the kernel version this config
file was generated for?
Other information like the time the file was generated could be useful as well.

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

Re: 2.4.1-pre8 losing pages

[Peter Horton]

On Fri, Jan 26, 2001 at 07:48:05PM +, Russell King wrote:
> Peter Horton writes:
> > The corruption is dependent on having a swapped on swap partition. If I
> > "swapoff" the corruption goes away, but it comes back when I "swapon"
> > again. I feel this a kernel bug, but as I'm the only person out here who's
> > seeing it I'm at a loss ...
> 
> The reason I ask is that on an ARM box running plain 2.4.0 with swap
> enabled I get rather a lot of SEGVs.  Turn swap off, and I don't see
> any.
> 
> It sounds like it may be related.
> 

Okay, scratch that. It does still happen when there's no swap, but for
some reason it happens a lot less often. Looks like it's timing related,
it only fails when using 7200rpm drives, not older 5400rpm ones (even
though they too are using UDMA33). I've ruled out the filing system, the
IDE controller, the drives and the RAM, so that leaves the kernel or the
CPU - I'll try and beg/borrow/steal another CPU and try that. I can
compile kernels / run X whilst the test is running without a problem so it
looks like it's the bulk write that's the problem.

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

Re: Poor SCSI drive performance on SMP machine, 2.2.16

[Gérard Roudier]

On Sun, 28 Jan 2001, paradox3 wrote:

> I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM
> 10 GB SCSI drive
> (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The
> SCSI drive
> performs the worst. In tests of writing 100 MB and sync'ing, one of my IDE
> drives takes 31 seconds. The SCSI drive (while doing nothing else) took
> 2 minutes, 10 seconds. This is extremely noticable in file transfers that
> completely
> monopolize the SCSI drive, and are much slower than when involving the IDE
> drives.
> After a large data operation on the SCSI drive, the system will hang for
> several minutes.
> Anyone know what could be causing this? Thanks.
> 
> Attached are some data to help.

You didn't provide enough information for anybody to have a single idea
about the cause of the problem you report, in my opinion.

Just any not too old 10,000 RPM disk is able to sustain more that 25 MB/s
sequential data transfer, but cannot do better than 5 milli-seconds
latency with random IO patterns. So, result for 100 MB transfer can be
less than 4 seconds in the best case but greater than (25000*5)/1000=125
seconds for random 4K IO pattern, for example.

What you want to do, in my opinion, could be:

- Check in the syslog the actual transfer speed that has been negotiated
  for your SCSI disk.
- Also check if error messages related to disk IOs have been reported by 
  the kernel.
- Run some benchmark to check, at least, sequential IO performance (iozone
  for example will fit)

Gérard.

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

Re: Kernel 2.4.0 loop device still hangs

[Mircea Damian]

On Sun, Jan 28, 2001 at 03:43:00AM +0100, Jens Axboe wrote:
> 
> It should be safe. Thanks for the feedback.


The patch works fine here too, but I have not tested it very hard ... just
normal read/write small/big files into it.

It looks fine here.

Any thoughts to integrate it into 2.4.1? What's Linus opinion?

-- 
Mircea Damian
E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED]
WebPage: http://taz.mania.k.ro/~dmircea/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.xkernels?

[Andrew Morton]

Shawn Starr wrote:
> 
> Andrew, the patch HAS made a difference. For example, while untaring 
>glibc-2.2.1.tar.gz the
> system was not sluggish (mouse movements in X) etc.
> 
> Seems to be a go for latency improvements on this system.

Shawn,

could you please try this patch in a pristine 2.4.1-pre10? It
gets reiserfs down to 4 milliseconds worst case.  If the
system's interactivity is still sluggish with this then
reiserfs isn't the cause.


Thanks.

--- linux-2.4.1-pre10/include/linux/reiserfs_fs.h   Tue Jan 23 19:28:16 2001
+++ linux-akpm/include/linux/reiserfs_fs.h  Sun Jan 28 22:37:11 2001
@@ -1161,7 +1161,8 @@
 #define fs_generation(s) ((s)->u.reiserfs_sb.s_generation_counter)
 #define get_generation(s) atomic_read (_generation(s))
 #define FILESYSTEM_CHANGED_TB(tb)  (get_generation((tb)->tb_sb) != (tb)->fs_gen)
-#define fs_changed(gen,s) (gen != get_generation (s))
+#define __fs_changed(gen,s) (gen != get_generation (s))
+#define fs_changed(gen,s) ({if (current->need_resched) schedule(); 
+__fs_changed(gen,s);})
 
 
 /***/
--- linux-2.4.1-pre10/fs/reiserfs/journal.c Tue Jan 23 19:28:15 2001
+++ linux-akpm/fs/reiserfs/journal.cSun Jan 28 22:31:12 2001
@@ -2649,6 +2649,8 @@
   }
 #endif
   wait_on_buffer(bh) ;
+  if (current->need_resched)
+   schedule();
 }
 retry_count++ ;
   }
@@ -3085,6 +3087,8 @@
 /* copy all the real blocks into log area.  dirty log blocks */
 if (test_bit(BH_JDirty, >bh->b_state)) {
   struct buffer_head *tmp_bh ;
+  if (current->need_resched)
+schedule();
   tmp_bh = getblk(p_s_sb->s_dev, reiserfs_get_journal_block(p_s_sb) + 
 ((cur_write_start + jindex) % JOURNAL_BLOCK_COUNT), 
   p_s_sb->s_blocksize) ;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/