RE: For comment: draft BIOS use document for the kernel

[Dunlap, Randy]

Looks somewhat familiar.  8;)
(compare http://rddunlap.home.att.net/linit/lin240_init_x86.html) (blatant
plug)

Some comments below.


> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]]

> Linux 2.4 BIOS usage reference
> 
> 
> Boot Sequence
> -
> 
...
> 
> int 0x10 service 3 is used during the boot loading sequence 
> to obtain the
> cursor position. int 0x10 service 13 is used to display 
s/13/0x13/ 0x13

> loading messages
> as the loading procedure continues. int 0x10 AH=0xE is used 
> to display a
> progress bar of '=' characters during the bootstrap
s/=/./'.'


> Memory Sizing
> -
> 
> Firstly a call is made to BIOS INT 15  AX=0xE820 in order to read the
s/15/0x15/

> E820 map. A maximum of 32 blocks are supported by current kernels. The
> 'SMAP' signature is required and tested. In addition the SMAP 
> signature
> is restored each call, although not required by the 
> specification in order to handle some know BIOS bugs.
> 
> If the E820 call fails then the INT 15 AX=0xE801 service is 
s/15/0x15/

> called and the
> results are sanity checked. In particular the code zeroes the 
> CX/DX return 
> values in order to detect BIOS implementations that do not set them 
> usable memory data. It also handles older BIOSes that return 
> AX/BX but not AX/BX data.
??? CX/DX instead?


> Peripherals
> ---
> 
...
> 
> Having completed video set up the hard disk data for hda and 
> hdb is copied
> from the low memory BIOS area into the kernel tables. INT 
> 0x13 AH-0x15 is
s/-/=/


> 32bit Bootstrap
> ---
> 
...
> 
> In the majority of systems the kernel will directly invoke 
> type 1 or type 2
> configuration. In this situation the kernel will search for a $PIR PCI
> IRQ routing table in the BIOS area (0xF->0xF) with a 
> revision of 0x100 (1.0). 

However, the $PIR table is a Windows 98 requirement.  Hence it
is not required for newer versions of Windows and also does not
apply to MP systems (unless the MP BIOS table is not being used).
(http://www.microsoft.com/HWDEV/busbios/PCIIRQ.htm)

$PIR *is* still used in Windows 2000 if available:
http://www.microsoft.com/HWDEV/cardbus/Spir.htm


> Power Management and BIOS Bugs
> --
> 
...

> Finally the battery status querying can be disabled to work 
> around a small
> number of BIOSes which crash when this function is used from 
> 32bit space.
> These options can be keyed from the DMI table scanner, so 
> that, if we are
> made aware of BIOSes requiring options set specific ways we can
> automatically set the options correctly for that BIOS without user
> intervention.

Didn't you disable DMI scan recently, in favor of userspace
DMI tools?


> Future Paths
> 
> 
> Intel are currently working on ACPI support for Linux. While 
> much of this is
> functional it is not yet stable enough that vendors enable 
> it. Linux does
> not require APM services to do minimal power management, nor 
> does it require
> PnPBIOS services to function happily. It does however need to 
> know about 
> interrupt routing. For minimal Linux compatibility a 'legacy 
> free' BIOS
> should probably provide the $PIR table, even if it does not 
> provide non ACPI versions of other services.

Sorry, legacy-free => ACPI, certainly not a $PIR table IMO.

Personally I'd like to explore adding support to Linux for
the Simple Boot Flag spec.
(http://www.microsoft.com/HWDEV/desinit/simp_bios.htm

~Randy
(not speaking for Intel)

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

RE: For comment: draft BIOS use document for the kernel

[Dunlap, Randy]

Looks somewhat familiar.  8;)
(compare http://rddunlap.home.att.net/linit/lin240_init_x86.html) (blatant
plug)

Some comments below.


 -Original Message-
 From: Alan Cox [mailto:[EMAIL PROTECTED]]

 Linux 2.4 BIOS usage reference
 
 
 Boot Sequence
 -
 
...
 
 int 0x10 service 3 is used during the boot loading sequence 
 to obtain the
 cursor position. int 0x10 service 13 is used to display 
s/13/0x13/ 0x13

 loading messages
 as the loading procedure continues. int 0x10 AH=0xE is used 
 to display a
 progress bar of '=' characters during the bootstrap
s/=/./'.'


 Memory Sizing
 -
 
 Firstly a call is made to BIOS INT 15  AX=0xE820 in order to read the
s/15/0x15/

 E820 map. A maximum of 32 blocks are supported by current kernels. The
 'SMAP' signature is required and tested. In addition the SMAP 
 signature
 is restored each call, although not required by the 
 specification in order to handle some know BIOS bugs.
 
 If the E820 call fails then the INT 15 AX=0xE801 service is 
s/15/0x15/

 called and the
 results are sanity checked. In particular the code zeroes the 
 CX/DX return 
 values in order to detect BIOS implementations that do not set them 
 usable memory data. It also handles older BIOSes that return 
 AX/BX but not AX/BX data.
??? CX/DX instead?


 Peripherals
 ---
 
...
 
 Having completed video set up the hard disk data for hda and 
 hdb is copied
 from the low memory BIOS area into the kernel tables. INT 
 0x13 AH-0x15 is
s/-/=/


 32bit Bootstrap
 ---
 
...
 
 In the majority of systems the kernel will directly invoke 
 type 1 or type 2
 configuration. In this situation the kernel will search for a $PIR PCI
 IRQ routing table in the BIOS area (0xF-0xF) with a 
 revision of 0x100 (1.0). 

However, the $PIR table is a Windows 98 requirement.  Hence it
is not required for newer versions of Windows and also does not
apply to MP systems (unless the MP BIOS table is not being used).
(http://www.microsoft.com/HWDEV/busbios/PCIIRQ.htm)

$PIR *is* still used in Windows 2000 if available:
http://www.microsoft.com/HWDEV/cardbus/Spir.htm


 Power Management and BIOS Bugs
 --
 
...

 Finally the battery status querying can be disabled to work 
 around a small
 number of BIOSes which crash when this function is used from 
 32bit space.
 These options can be keyed from the DMI table scanner, so 
 that, if we are
 made aware of BIOSes requiring options set specific ways we can
 automatically set the options correctly for that BIOS without user
 intervention.

Didn't you disable DMI scan recently, in favor of userspace
DMI tools?


 Future Paths
 
 
 Intel are currently working on ACPI support for Linux. While 
 much of this is
 functional it is not yet stable enough that vendors enable 
 it. Linux does
 not require APM services to do minimal power management, nor 
 does it require
 PnPBIOS services to function happily. It does however need to 
 know about 
 interrupt routing. For minimal Linux compatibility a 'legacy 
 free' BIOS
 should probably provide the $PIR table, even if it does not 
 provide non ACPI versions of other services.

Sorry, legacy-free = ACPI, certainly not a $PIR table IMO.

Personally I'd like to explore adding support to Linux for
the Simple Boot Flag spec.
(http://www.microsoft.com/HWDEV/desinit/simp_bios.htm

~Randy
(not speaking for Intel)

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

RE: Undocumented configuration symbols in 2.4.6pre2

[Dunlap, Randy]

Hi,

Could you make these 5 instances of "Not unsure" be more
palatable and less confusing?

E.g., "Not sure" or "If not sure".
But not the double negative...

As is, it basically says:  "Sure ? say M."

~Randy

> -Original Message-
> From: Maksim Krasnyanskiy [mailto:[EMAIL PROTECTED]]
> 
> >CONFIG_BLUEZ
> >CONFIG_BLUEZ_HCIEMU
> >CONFIG_BLUEZ_HCIUART
> >CONFIG_BLUEZ_HCIUSB
> >CONFIG_BLUEZ_L2CAP
> 
> Here we go:
> 
> CONFIG_BLUEZ
...
> 
>Say Y here to enable Linux Bluetooth support and to build HCI Core 
>layer.
> 
...
> 
>Not unsure ? say N.
> 
> CONFIG_BLUEZ_L2CAP
...
> 
>Say Y here to compile L2CAP support into the kernel or say 
> M to compile it 
>as module (l2cap.o).
> 
>Not unsure ? say M.
> 
> CONFIG_BLUEZ_HCIUART
...
> 
>Say Y here to compile support for Bluetooth UART devices 
> into the kernel 
>or say M to compile it as module (hci_uart.o).
> 
>Not unsure ? say M.
> 
> 
> CONFIG_BLUEZ_HCIUSB
...
> 
>Say Y here to compile support for Bluetooth USB devices 
> into the kernel 
>or say M to compile it as module (hci_usb.o).
> 
>Not unsure ? say M.
> 
> CONFIG_BLUEZ_HCIEMU
...
> 
>Not unsure ? say M.

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

RE: Undocumented configuration symbols in 2.4.6pre2

[Dunlap, Randy]

Hi,

Could you make these 5 instances of Not unsure be more
palatable and less confusing?

E.g., Not sure or If not sure.
But not the double negative...

As is, it basically says:  Sure ? say M.

~Randy

 -Original Message-
 From: Maksim Krasnyanskiy [mailto:[EMAIL PROTECTED]]
 
 CONFIG_BLUEZ
 CONFIG_BLUEZ_HCIEMU
 CONFIG_BLUEZ_HCIUART
 CONFIG_BLUEZ_HCIUSB
 CONFIG_BLUEZ_L2CAP
 
 Here we go:
 
 CONFIG_BLUEZ
...
 
Say Y here to enable Linux Bluetooth support and to build HCI Core 
layer.
 
...
 
Not unsure ? say N.
 
 CONFIG_BLUEZ_L2CAP
...
 
Say Y here to compile L2CAP support into the kernel or say 
 M to compile it 
as module (l2cap.o).
 
Not unsure ? say M.
 
 CONFIG_BLUEZ_HCIUART
...
 
Say Y here to compile support for Bluetooth UART devices 
 into the kernel 
or say M to compile it as module (hci_uart.o).
 
Not unsure ? say M.
 
 
 CONFIG_BLUEZ_HCIUSB
...
 
Say Y here to compile support for Bluetooth USB devices 
 into the kernel 
or say M to compile it as module (hci_usb.o).
 
Not unsure ? say M.
 
 CONFIG_BLUEZ_HCIEMU
...
 
Not unsure ? say M.

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

RE: Kernel 2.4.x TODO

[Dunlap, Randy]

> From: Sasi Peter [mailto:[EMAIL PROTECTED]]
> 
> > Check out the kernel janitor project at
> > http://bazar.conectiva.com.br/~acme/TODO (original)
> 
> Is this information up2date? If it is, sad to see we have 
> this many bugs... 

"Last updated in: Mon Feb 26 21:19:49 EST 2001"

The other link that I sent (the kernel janitor project) replaced this list
and should be more up-to-date...although I can't really find a TODO list
there:
http://sourceforge.net/projects/kernel-janitor

Jeff?

~Randy

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

RE: Kernel 2.4.x TODO

[Dunlap, Randy]

 From: Sasi Peter [mailto:[EMAIL PROTECTED]]
 
  Check out the kernel janitor project at
  http://bazar.conectiva.com.br/~acme/TODO (original)
 
 Is this information up2date? If it is, sad to see we have 
 this many bugs... 

"Last updated in: Mon Feb 26 21:19:49 EST 2001"

The other link that I sent (the kernel janitor project) replaced this list
and should be more up-to-date...although I can't really find a TODO list
there:
http://sourceforge.net/projects/kernel-janitor

Jeff?

~Randy

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

RE: ac15 and 2.4.5-pre6, pwc format conversion

[Dunlap, Randy]

> From: Erik Mouw [mailto:[EMAIL PROTECTED]]
> 
> On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
> > On 25-May-01 Norbert Preining wrote:
> > > According to ac ChangeLog:
> > > o   Rip format conversion out of the pwc driver (me)
> > > | It belongs in user space..
> > > 
> > > This change is included in 2.4.5-pre6, but
> > >   drivers/usb/pwc-uncompress.c
> > > pwc-uncompress.c:185: warning: implicit declaration of function
> > > `vcvt_420i_420p'
> > 
> > That´s what you get for ripping out the guts of a driver. 
> Have a nice day.
> 
> The format conversion shouldn't be there in the first place. Format
> conversion is policy, so it doesn't belong in kernel. Note for example
> that none of the sound drivers does sample rate conversion although
> some sound chips are locked at 48kHz only.

Once upon a time there was an agreement (understanding ?) that this
was to be a major 2.5 change (moving video conversion from kernel
drivers to user space) and that lots of apps would need to be
changed for this to be successful.

~Randy

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

RE: changes betwwen 2.2 | 2.4

[Dunlap, Randy]

See http://www.firstfloor.org/~andi/softnet/

~Randy
---

> From: sebastien person [mailto:[EMAIL PROTECTED]]
> 
> Is there any documents that explain how upgrade network 
> driver from 2.2. to 2.4.? that gives details on changes ...
> 
> Or maybe best way is to compare same driver in the twice 
> kernel version ?

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

RE: changes betwwen 2.2 | 2.4

[Dunlap, Randy]

See http://www.firstfloor.org/~andi/softnet/

~Randy
---

 From: sebastien person [mailto:[EMAIL PROTECTED]]
 
 Is there any documents that explain how upgrade network 
 driver from 2.2. to 2.4.? that gives details on changes ...
 
 Or maybe best way is to compare same driver in the twice 
 kernel version ?

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

RE: ac15 and 2.4.5-pre6, pwc format conversion

[Dunlap, Randy]

 From: Erik Mouw [mailto:[EMAIL PROTECTED]]
 
 On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
  On 25-May-01 Norbert Preining wrote:
   According to ac ChangeLog:
   o   Rip format conversion out of the pwc driver (me)
   | It belongs in user space..
   
   This change is included in 2.4.5-pre6, but
 drivers/usb/pwc-uncompress.c
   pwc-uncompress.c:185: warning: implicit declaration of function
   `vcvt_420i_420p'
  
  That´s what you get for ripping out the guts of a driver. 
 Have a nice day.
 
 The format conversion shouldn't be there in the first place. Format
 conversion is policy, so it doesn't belong in kernel. Note for example
 that none of the sound drivers does sample rate conversion although
 some sound chips are locked at 48kHz only.

Once upon a time there was an agreement (understanding ?) that this
was to be a major 2.5 change (moving video conversion from kernel
drivers to user space) and that lots of apps would need to be
changed for this to be successful.

~Randy

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

RE: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Dunlap, Randy]

> From: Andrew Morton [mailto:[EMAIL PROTECTED]]
> 
> Andreas Dilger wrote:
> > 
> > On a side note, does anyone know if the kernel does checking if the
> > stack overflowed at any time?
> 
> There's a little bit of code in show_task() which calculates
> how close this task ever got to overrunning its kernel stack:
> 
> {
> unsigned long * n = (unsigned long *) (p+1);
> while (!*n)
> n++;
> free = (unsigned long) n - (unsigned long)(p+1);
> }
> printk("%5lu %5d %6d ", free, p->pid, p->p_pptr->pid);
> 
> SYSRQ-T will trigger this.
> 
> However it doesn't work, because do_fork() doesn't zero
> out the stack pages when they're created.

If do_fork() performance is an issue, at least clearing the stack
pages as a build option would be nice for some of us.

~Randy

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

RE: Kernel 2.4.x TODO

[Dunlap, Randy]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
> Was the TODO list at http://linux24.sourceforge.net just 
> meant to be useful before 2.4.0 was released?

I believe that is the case.

> It seems to me that it would still be useful for (amongst 
> other things)
> potential kernel hackers looking for something to have a stab 
> at but it
> doesn't seem to up to date. Is it still supposed to be being 
> maintained by anyone?

Check out the kernel janitor project at
http://bazar.conectiva.com.br/~acme/TODO (original)
and
http://sourceforge.net/projects/kernel-janitor (later)

~Randy

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

RE: Kernel 2.4.x TODO

[Dunlap, Randy]

 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 
 Was the TODO list at http://linux24.sourceforge.net just 
 meant to be useful before 2.4.0 was released?

I believe that is the case.

 It seems to me that it would still be useful for (amongst 
 other things)
 potential kernel hackers looking for something to have a stab 
 at but it
 doesn't seem to up to date. Is it still supposed to be being 
 maintained by anyone?

Check out the kernel janitor project at
http://bazar.conectiva.com.br/~acme/TODO (original)
and
http://sourceforge.net/projects/kernel-janitor (later)

~Randy

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

RE: [CHECKER] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8

[Dunlap, Randy]

 From: Andrew Morton [mailto:[EMAIL PROTECTED]]
 
 Andreas Dilger wrote:
  
  On a side note, does anyone know if the kernel does checking if the
  stack overflowed at any time?
 
 There's a little bit of code in show_task() which calculates
 how close this task ever got to overrunning its kernel stack:
 
 {
 unsigned long * n = (unsigned long *) (p+1);
 while (!*n)
 n++;
 free = (unsigned long) n - (unsigned long)(p+1);
 }
 printk(%5lu %5d %6d , free, p-pid, p-p_pptr-pid);
 
 SYSRQ-T will trigger this.
 
 However it doesn't work, because do_fork() doesn't zero
 out the stack pages when they're created.

If do_fork() performance is an issue, at least clearing the stack
pages as a build option would be nice for some of us.

~Randy

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

RE: kernel2.2.x to kernel2.4.x

[Dunlap, Randy]

see http://www.firstfloor.org/~andi/softnet/

~Randy


> -Original Message-
> From: jalaja devi [mailto:[EMAIL PROTECTED]]
> 
> How can I handle this from kernel2.2 to kernel2.4
> 
> Can I replace like this??
> 
> if (test_and_set_bit (0, (void *)>tbusy)){ return
> EBUSY;} == with  netif_stop_queue (dev);
> 
> clear_bit ((void *)>tbusy); = with
> netif_start_queue(dev);
> 
> Thanks
> Jalaja
> 
> --- Alan Cox <[EMAIL PROTECTED]> wrote:
> > > I tried porting a network driver from kernel2.2.x
> > to
> > > 2.4. When i tried loading the driver, it shows the
> > > unresolved symbols for
> > > copy_to_user_ret
> > 
> > if(copy_to_user(...))
> > return -EFAULT
> > 
> > > outs
> > 
> > Has not gone away, your includes are wrong
> > 
> > > __bad_udelay
> > 
> > You are using too large a udelay use mdelay
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at 
> > http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> __
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

RE: kernel2.2.x to kernel2.4.x

[Dunlap, Randy]

see http://www.firstfloor.org/~andi/softnet/

~Randy


 -Original Message-
 From: jalaja devi [mailto:[EMAIL PROTECTED]]
 
 How can I handle this from kernel2.2 to kernel2.4
 
 Can I replace like this??
 
 if (test_and_set_bit (0, (void *)dev-tbusy)){ return
 EBUSY;} == with  netif_stop_queue (dev);
 
 clear_bit ((void *)dev-tbusy); = with
 netif_start_queue(dev);
 
 Thanks
 Jalaja
 
 --- Alan Cox [EMAIL PROTECTED] wrote:
   I tried porting a network driver from kernel2.2.x
  to
   2.4. When i tried loading the driver, it shows the
   unresolved symbols for
   copy_to_user_ret
  
  if(copy_to_user(...))
  return -EFAULT
  
   outs
  
  Has not gone away, your includes are wrong
  
   __bad_udelay
  
  You are using too large a udelay use mdelay
  -
  To unsubscribe from this list: send the line
  unsubscribe linux-kernel in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at 
  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
 
 
 __
 Do You Yahoo!?
 Yahoo! Auctions - buy the things you want at great prices
 http://auctions.yahoo.com/
 -
 To unsubscribe from this list: send the line unsubscribe 
 linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

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

RE: LANANA: To Pending Device Number Registrants

[Dunlap, Randy]

hpa wrote:
> 
> Alan Cox wrote:
> > 
> > > Are FireWire (and USB) disks always detected in the same 
> > > order? Or does it
> > > behave like ADB, where you never know which 
> > > mouse/keyboard is which mouse/keyboard?
> > 
> > USB disks are required (haha etc) to have serial numbers. 
> > Firewire similarly has unique disk identifiers.

Bulk-only USB storage is required to have serial numbers.
E.g., Zip drives, probably USB hard drives and CDs.
Drives that use CBI (control/bulk/interrupt) transport (mostly
floppies) are not required to have serial numbers.
(Cost thing, of course.)

> How about for other device classes?

Mice?  no way.  Keyboards?  nope.
Webcams?  nope.
Printers?  optional.
Audio?  no.
Communication?  not mentioned in the spec.
Hub?  not mentioned in the spec.

~Randy

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

RE: LANANA: To Pending Device Number Registrants

[Dunlap, Randy]

hpa wrote:
 
 Alan Cox wrote:
  
   Are FireWire (and USB) disks always detected in the same 
   order? Or does it
   behave like ADB, where you never know which 
   mouse/keyboard is which mouse/keyboard?
  
  USB disks are required (haha etc) to have serial numbers. 
  Firewire similarly has unique disk identifiers.

Bulk-only USB storage is required to have serial numbers.
E.g., Zip drives, probably USB hard drives and CDs.
Drives that use CBI (control/bulk/interrupt) transport (mostly
floppies) are not required to have serial numbers.
(Cost thing, of course.)

 How about for other device classes?

Mice?  no way.  Keyboards?  nope.
Webcams?  nope.
Printers?  optional.
Audio?  no.
Communication?  not mentioned in the spec.
Hub?  not mentioned in the spec.

~Randy

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

RE: kernel2.2.x to kernel2.4.x

[Dunlap, Randy]

> From: jalaja devi [mailto:[EMAIL PROTECTED]]
> 
> I tried porting a network driver from kernel2.2.x to
> 2.4. When i tried loading the driver, it shows the
> unresolved symbols for
> copy_to_user_ret
> outs
> __bad_udelay
> 
> Could anyone please tell me the corresponding fxns in 2.4.

You need to "unroll" copy_to_user_ret().  There is no
corresponding macro.  Just test the condition and return
-EFAULT (?; not looking at the source code) if it's invalid.

Don't know about "outs".

__bad_udelay means that some module used a too-large-parameter-value
to udelay().  Linker should be telling you which module.

~Randy

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

RE: kernel2.2.x to kernel2.4.x

[Dunlap, Randy]

 From: jalaja devi [mailto:[EMAIL PROTECTED]]
 
 I tried porting a network driver from kernel2.2.x to
 2.4. When i tried loading the driver, it shows the
 unresolved symbols for
 copy_to_user_ret
 outs
 __bad_udelay
 
 Could anyone please tell me the corresponding fxns in 2.4.

You need to unroll copy_to_user_ret().  There is no
corresponding macro.  Just test the condition and return
-EFAULT (?; not looking at the source code) if it's invalid.

Don't know about outs.

__bad_udelay means that some module used a too-large-parameter-value
to udelay().  Linker should be telling you which module.

~Randy

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

RE: [PATCH] x86 page fault handler not interrupt safe

[Dunlap, Randy]

> From: David Woodhouse [mailto:[EMAIL PROTECTED]]
> 
> [EMAIL PROTECTED] said:
> >  If anybody has such a beast, please try this kernel patch _and_
> > running the F0 0F bug-producing program (search for it on the 'net -
> > it must be out there somewhere) to verify that the code still
> > correctly handles that case. 
> 
> Something along the lines of:
> 
> echo "unsigned long main=0xf00fc7c8;" > f00fbug.c ; make f00fbug

Yes, that's what the (SGI) program uses:
http://lwn.net/2001/0329/a/ltp-f00f.php3

~Randy

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

RE: [PATCH] x86 page fault handler not interrupt safe

[Dunlap, Randy]

 From: David Woodhouse [mailto:[EMAIL PROTECTED]]
 
 [EMAIL PROTECTED] said:
   If anybody has such a beast, please try this kernel patch _and_
  running the F0 0F bug-producing program (search for it on the 'net -
  it must be out there somewhere) to verify that the code still
  correctly handles that case. 
 
 Something along the lines of:
 
 echo unsigned long main=0xf00fc7c8;  f00fbug.c ; make f00fbug

Yes, that's what the (SGI) program uses:
http://lwn.net/2001/0329/a/ltp-f00f.php3

~Randy

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

RE: inserting a Forth-like language into the Linux kernel

[Dunlap, Randy]

> > > If someone knows of another example of interpreter-like behavior 
> > > directly in a unix in-kernel thread I'd like to know about it.  
> > 
> > kdb
> > 
> 
> That runs in trap handlers doesn't it? I don't think it's a 
> kernel daemon.

and there's the hangman-in-kernel patch...
interpreter or daemon or app-in-system-space ???

~Randy

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

RE: inserting a Forth-like language into the Linux kernel

[Dunlap, Randy]

   If someone knows of another example of interpreter-like behavior 
   directly in a unix in-kernel thread I'd like to know about it.  
  
  kdb
  
 
 That runs in trap handlers doesn't it? I don't think it's a 
 kernel daemon.

and there's the hangman-in-kernel patch...
interpreter or daemon or app-in-system-space ???

~Randy

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

RE: input core pointers, someone?

[Dunlap, Randy]

http://www.suse.cz/development/input/

and Vojtech Pavlik ([EMAIL PROTECTED])


~Randy503-677-5408_
--- 

> -Original Message-
> From: Magnus Bodin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2001 7:18 AM
> To: [EMAIL PROTECTED]
> Subject: input core pointers, someone?
> 
> 
> 
> I'm about to write a (IR) KEYBOARD device driver. I guess I'm 
> better off
> using the existing work on the USB-path with input core etc 
> that appeared sometimes around 2.2?
> 
> Is there ANY documentation/schematics on how this works or is 
> it 'Read The
> Fantastic Source' and/or e-mail Pavel Machek that is my way to go?
> 
> _Any_ pointers is of interest.
> 
> /magnus

> 


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

RE: input core pointers, someone?

[Dunlap, Randy]

http://www.suse.cz/development/input/

and Vojtech Pavlik ([EMAIL PROTECTED])


~Randy503-677-5408_
--- 

 -Original Message-
 From: Magnus Bodin [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, May 02, 2001 7:18 AM
 To: [EMAIL PROTECTED]
 Subject: input core pointers, someone?
 
 
 
 I'm about to write a (IR) KEYBOARD device driver. I guess I'm 
 better off
 using the existing work on the USB-path with input core etc 
 that appeared sometimes around 2.2?
 
 Is there ANY documentation/schematics on how this works or is 
 it 'Read The
 Fantastic Source' and/or e-mail Pavel Machek that is my way to go?
 
 _Any_ pointers is of interest.
 
 /magnus

 


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

RE: Dyanmics Thread at Kernel Level

[Dunlap, Randy]

> On 26-Apr-2001 Rajeev Nigam wrote:
> > Can anybody  tell me, How can I create dynamic threads at 
> Kernel level??
> > 
> > If u have any sample code in which Semaphore, threads, events are
> > implemented, Pls send.
> > 
> > Waiting for ur response.
> 
> http://www.linux-mag.com/depts/gear.html

or http://www.scs.ch/~frey/linux/kernelthreads.html

~Randy

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

RE: Dyanmics Thread at Kernel Level

[Dunlap, Randy]

 On 26-Apr-2001 Rajeev Nigam wrote:
  Can anybody  tell me, How can I create dynamic threads at 
 Kernel level??
  
  If u have any sample code in which Semaphore, threads, events are
  implemented, Pls send.
  
  Waiting for ur response.
 
 http://www.linux-mag.com/depts/gear.html

or http://www.scs.ch/~frey/linux/kernelthreads.html

~Randy

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

RE: [kbuild-devel] CML2 1.0.0 release announcement

[Dunlap, Randy]

> After 11 months of painstaking work and testing, CML2 1.0.0 
> is ready for use,
> and ready to replace the current kernel-configuration system.  You'll
> find it at <http://www.tuxedo.org/~esr/cml2/>.  I've made a transition
> guide available at <http://www.tuxedo.org/~esr/cml2/transition.html>.

> From: Eric S. Raymond [mailto:[EMAIL PROTECTED]]
> 
> Dunlap, Randy <[EMAIL PROTECTED]>:
> > I'd like to see one of the prominent web pages inform
> > people that Python version x.yy(?) is required to use CML2.
> 
> It's in the README.  Is that good enough?
> -- 

Then the README should be listed (linked) on one of the 2 web pages
above.  I can't find it without downloading "CML2 prototype
and documentation," right?  I think that it should be
more visible that Python version x.yy(?) is needed, without
having to download the tarball.  Or did I miss the README
somewhere?

Thanks,
~Randy

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

RE: [kbuild-devel] CML2 1.0.0 release announcement

[Dunlap, Randy]

Hi Eric,

> After 11 months of painstaking work and testing, CML2 1.0.0 
> is ready for use,
> and ready to replace the current kernel-configuration system.  You'll
> find it at .  I've made a transition
> guide available at .

Congratulations on taking it this far.

> (For those of you who grumbled about adding Python to the 
> build-tools set,
> Linus has uttered a ukase: CML2's reliance on Python is not 
> an issue.

I'd like to see one of the prominent web pages inform
people that Python version x.yy(?) is required to use CML2.
(I had Python version problems during testing/use of it...)

~Randy_

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

RE: [kbuild-devel] CML2 1.0.0 release announcement

[Dunlap, Randy]

Hi Eric,

 After 11 months of painstaking work and testing, CML2 1.0.0 
 is ready for use,
 and ready to replace the current kernel-configuration system.  You'll
 find it at http://www.tuxedo.org/~esr/cml2/.  I've made a transition
 guide available at http://www.tuxedo.org/~esr/cml2/transition.html.

Congratulations on taking it this far.

 (For those of you who grumbled about adding Python to the 
 build-tools set,
 Linus has uttered a ukase: CML2's reliance on Python is not 
 an issue.

I'd like to see one of the prominent web pages inform
people that Python version x.yy(?) is required to use CML2.
(I had Python version problems during testing/use of it...)

~Randy_

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

RE: [kbuild-devel] CML2 1.0.0 release announcement

[Dunlap, Randy]

 After 11 months of painstaking work and testing, CML2 1.0.0 
 is ready for use,
 and ready to replace the current kernel-configuration system.  You'll
 find it at http://www.tuxedo.org/~esr/cml2/.  I've made a transition
 guide available at http://www.tuxedo.org/~esr/cml2/transition.html.

 From: Eric S. Raymond [mailto:[EMAIL PROTECTED]]
 
 Dunlap, Randy [EMAIL PROTECTED]:
  I'd like to see one of the prominent web pages inform
  people that Python version x.yy(?) is required to use CML2.
 
 It's in the README.  Is that good enough?
 -- 

Then the README should be listed (linked) on one of the 2 web pages
above.  I can't find it without downloading "CML2 prototype
and documentation," right?  I think that it should be
more visible that Python version x.yy(?) is needed, without
having to download the tarball.  Or did I miss the README
somewhere?

Thanks,
~Randy

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

using ioctls (was: RE: Larger dev_t)

[Dunlap, Randy]

Hi-

Tangential question (I think).  Not for an IOCTL request  8;)
[as the JFS request last week].

[When] is it OK to use (new) IOCTLs vs. using procfs read/write?

And are there some alternative methods besides these two?

Thanks,
~Randy


> -Original Message-
> From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
> 
...
> We should encourage people to not need major numbers. It's easy. The
> driver exports a /proc entry in /proc/driver/xxx or similar . Or the
> driver writer says "if you want to use this device, use devfs", and
> exports the name there.

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

using ioctls (was: RE: Larger dev_t)

[Dunlap, Randy]

Hi-

Tangential question (I think).  Not for an IOCTL request  8;)
[as the JFS request last week].

[When] is it OK to use (new) IOCTLs vs. using procfs read/write?

And are there some alternative methods besides these two?

Thanks,
~Randy


 -Original Message-
 From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
 
...
 We should encourage people to not need major numbers. It's easy. The
 driver exports a /proc entry in /proc/driver/xxx or similar . Or the
 driver writer says "if you want to use this device, use devfs", and
 exports the name there.

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

RE: HP Vectra XU 5/90 interrupt problems

[Dunlap, Randy]

> -Original Message-
> From: John William [mailto:[EMAIL PROTECTED]]
> 
> I'm having a problem with kernel 2.4.2-SMP on my HP Vectra XU 
> 5/90. This is an old dual-pentium (Neptune chipset) machine.
> 
...
> 
> OR
> 
> If PCI interrupts are shared, force them to be level 
> triggered? Can shared 
> PCI interrupts be edge triggered? If not, then wouldn't this 
> be the correct 
> solution? This isn't specific to the Vectra, but could 
> possibly prevent problems on any machine with a broken BIOS?

PCI interrupts are defined as "level sensitive" and must
be shareable.

~Randy

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

RE: [patch] patch-2.4.2-irda1 (irda-usb)

[Dunlap, Randy]

> From: Jean Tourrilhes [mailto:[EMAIL PROTECTED]]
> 
>   First thanks for Dag for bringing me into the conversation. I
> may add my little bit of spice, especially that I was the one pushing
> for having the driver in .../drivers/net/irda.
>   By the way, Greg, sorry if I hurt your feeling, I don't want
> to put down any of the great work that has been done on the USB stack.
> 
>   My feeling is that devices are mostly defined by their higher
> level interface, because this is what is closer to the user.
>   If I look at a Pcmcia Ethernet card, I will tend to associate
> more with a PCI Ethernet card rather than a Pcmcia SCSI card. Both
> card have the same high level interface (TCP/IP) even if their low
> level interface is different (Pcmcia, PCI).
>   People tend to agree with that, and that's why you have
> directories called drivers/net, drivers/scsi and driver/sound, rather
> that drivers/pci, drivers/isa, drivers/mca and drivers/pcmcia.
> 
>   If I get an IrDA-USB dongle, the feature that matter the most
> is that it does IrDA, the fact that it connect to my PC via USB is
> rather secondary.
>   That's it. I hope it explain some of the rationale and why we
> departed from the usual drivers/usb arrangement. Actually, I think
> that stuffing all USB drivers in drivers/usb is not that great, but
> that's not my call...

That has been discussed & Linus like[ds] it that way.

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

RE: [patch] patch-2.4.2-irda1 (irda-usb)

[Dunlap, Randy]

 From: Jean Tourrilhes [mailto:[EMAIL PROTECTED]]
 
   First thanks for Dag for bringing me into the conversation. I
 may add my little bit of spice, especially that I was the one pushing
 for having the driver in .../drivers/net/irda.
   By the way, Greg, sorry if I hurt your feeling, I don't want
 to put down any of the great work that has been done on the USB stack.
 
   My feeling is that devices are mostly defined by their higher
 level interface, because this is what is closer to the user.
   If I look at a Pcmcia Ethernet card, I will tend to associate
 more with a PCI Ethernet card rather than a Pcmcia SCSI card. Both
 card have the same high level interface (TCP/IP) even if their low
 level interface is different (Pcmcia, PCI).
   People tend to agree with that, and that's why you have
 directories called drivers/net, drivers/scsi and driver/sound, rather
 that drivers/pci, drivers/isa, drivers/mca and drivers/pcmcia.
 
   If I get an IrDA-USB dongle, the feature that matter the most
 is that it does IrDA, the fact that it connect to my PC via USB is
 rather secondary.
   That's it. I hope it explain some of the rationale and why we
 departed from the usual drivers/usb arrangement. Actually, I think
 that stuffing all USB drivers in drivers/usb is not that great, but
 that's not my call...

That has been discussed  Linus like[ds] it that way.

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

RE: USB mouse jumping

[Dunlap, Randy]

> From: Elmer Joandi [mailto:[EMAIL PROTECTED]]
> 
> On Tue, 13 Feb 2001, Dunlap, Randy wrote:
> 
> > If USB mice had serial numbers (like some USB storage devices
> > do), then we could tell that it's the same mouse on the
> > same connector and not change from mouse0 to mouse1.
> > Currently it looks like a new device attachment.
> > 
> > One possible solution is for you to use /dev/usb/mice,
> > which is all USB mice merged into one input stream.
> 
> 
> Please, if it is possible, make it simple and sensible.
> 
> if to have true multihead, with 5 keyboards and mice, I would 
> really wish
> that the device numbers are connected to physical holes for plugs,
> otherwise anyone (of schoolchildren for example) can do simple nasty
> stupid things.

It's currently not designed for multihead usage.
I haven't looked at it much, but I believe that the
linux-console project is working on that.  (?)
(http://sourceforge.net/projects/linuxconsole/)

I agree; your suggestion (same physical device on same connector =>
same logical device) makes sense to me, at least for some
devices, like mice and keyboards.  For some devices it could
lead to misuse of the device.

> And also it is the dream for true dumbuser with one mouse, 
> because it then just works out of box.

Use /dev/input/mice for this case, not /dev/input/mouse0 .

(Ah, I said /dev/usb/mice earlier; should be /dev/input/mice .)

> Or you tell that with USB internal design you can not know physical
> connector unique number ?

Yes, we can/do know what physical connector a device is attached
on.

~Randy

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

RE: USB mouse jumping

[Dunlap, Randy]

> From: Elmer Joandi [mailto:[EMAIL PROTECTED]]
> 
> I dont know, if it is bug or feature, but, 
> 
>  USB mouse jumps around (between) /dev/input/mouse0 and mouse1
>  when taken out and put back in(to same connector), 2.4.0 kernel.
> 
> Annoys, should not be the default behaviour, IMHO.

If USB mice had serial numbers (like some USB storage devices
do), then we could tell that it's the same mouse on the
same connector and not change from mouse0 to mouse1.
Currently it looks like a new device attachment.

One possible solution is for you to use /dev/usb/mice,
which is all USB mice merged into one input stream.


~Randy_
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

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

RE: USB mouse jumping

[Dunlap, Randy]

 From: Elmer Joandi [mailto:[EMAIL PROTECTED]]
 
 I dont know, if it is bug or feature, but, 
 
  USB mouse jumps around (between) /dev/input/mouse0 and mouse1
  when taken out and put back in(to same connector), 2.4.0 kernel.
 
 Annoys, should not be the default behaviour, IMHO.

If USB mice had serial numbers (like some USB storage devices
do), then we could tell that it's the same mouse on the
same connector and not change from mouse0 to mouse1.
Currently it looks like a new device attachment.

One possible solution is for you to use /dev/usb/mice,
which is all USB mice merged into one input stream.


~Randy_
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

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

RE: USB mouse jumping

[Dunlap, Randy]

 From: Elmer Joandi [mailto:[EMAIL PROTECTED]]
 
 On Tue, 13 Feb 2001, Dunlap, Randy wrote:
 
  If USB mice had serial numbers (like some USB storage devices
  do), then we could tell that it's the same mouse on the
  same connector and not change from mouse0 to mouse1.
  Currently it looks like a new device attachment.
  
  One possible solution is for you to use /dev/usb/mice,
  which is all USB mice merged into one input stream.
 
 
 Please, if it is possible, make it simple and sensible.
 
 if to have true multihead, with 5 keyboards and mice, I would 
 really wish
 that the device numbers are connected to physical holes for plugs,
 otherwise anyone (of schoolchildren for example) can do simple nasty
 stupid things.

It's currently not designed for multihead usage.
I haven't looked at it much, but I believe that the
linux-console project is working on that.  (?)
(http://sourceforge.net/projects/linuxconsole/)

I agree; your suggestion (same physical device on same connector =
same logical device) makes sense to me, at least for some
devices, like mice and keyboards.  For some devices it could
lead to misuse of the device.

 And also it is the dream for true dumbuser with one mouse, 
 because it then just works out of box.

Use /dev/input/mice for this case, not /dev/input/mouse0 .

(Ah, I said /dev/usb/mice earlier; should be /dev/input/mice .)

 Or you tell that with USB internal design you can not know physical
 connector unique number ?

Yes, we can/do know what physical connector a device is attached
on.

~Randy

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

RE: Unresolved Symbol error

[Dunlap, Randy]

> I am trying to create a catcher module that will provide a 
> distributed layer over the file system. To do this I am using 
> a kernel module to intercept and pre process the open system 
> call. However I need to use some functions such as strlen() 
> and memcpy() etc. When I try to compile the module it 
> compiles fine. Without any errors. However when I insert the 
> module using insmod  I get an error:
> catcher.o: unresolved symbol strlen
> 
> I am compiling the module using -D__KERNEL__ -DMODULE -DLINUX 
> options. Is there some thing else that I have to do to use 
> the strlen function. 

Also use -O2 .

~Randy

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

RE: Unresolved Symbol error

[Dunlap, Randy]

 I am trying to create a catcher module that will provide a 
 distributed layer over the file system. To do this I am using 
 a kernel module to intercept and pre process the open system 
 call. However I need to use some functions such as strlen() 
 and memcpy() etc. When I try to compile the module it 
 compiles fine. Without any errors. However when I insert the 
 module using insmod module name I get an error:
 catcher.o: unresolved symbol strlen
 
 I am compiling the module using -D__KERNEL__ -DMODULE -DLINUX 
 options. Is there some thing else that I have to do to use 
 the strlen function. 

Also use -O2 .

~Randy

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

RE: Mem detection problem

[Dunlap, Randy]

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

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

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

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

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

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

~Randy

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

RE: Mem detection problem

[Dunlap, Randy]

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

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

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

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

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

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

~Randy

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

RE: different IRQ settings for different MPS settings?

[Dunlap, Randy]

Hi,

> From: John R Lenton [mailto:[EMAIL PROTECTED]]
> 
> With a MPS setting of 1.4 USB doesn't work on me; it timeouts,
> constantly.  With MPS setting of 1.1 everything is OK.
> 
...
> 
> My question(s) is(are) is this a known bug, is this correct
> behaviour, am I missing something, and why is USB the only
> subsystem affected.

It is known that several systems have problems with USB if
MPS is set to 1.4, and some systems work OK with that
setting.  Problem cause is still unknown.

I'd be interested to see you boot logs (kernel messages,
specifically MP table info) from Linux boots with
MPS = 1.1 and 1.4, to see if there are any differences
in them.  The big difference should be the addition
of some address space mappings, which Linux ignores
(doesn't parse, doesn't use) -- but I've never seen
a BIOS that implements address space mappings in the
MP table [and if one did, it looks like Linux would
just loop forever in smp_read_mpc(), so that's probably
not the issue here].

~Randy

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

RE: different IRQ settings for different MPS settings?

[Dunlap, Randy]

Hi,

 From: John R Lenton [mailto:[EMAIL PROTECTED]]
 
 With a MPS setting of 1.4 USB doesn't work on me; it timeouts,
 constantly.  With MPS setting of 1.1 everything is OK.
 
...
 
 My question(s) is(are) is this a known bug, is this correct
 behaviour, am I missing something, and why is USB the only
 subsystem affected.

It is known that several systems have problems with USB if
MPS is set to 1.4, and some systems work OK with that
setting.  Problem cause is still unknown.

I'd be interested to see you boot logs (kernel messages,
specifically MP table info) from Linux boots with
MPS = 1.1 and 1.4, to see if there are any differences
in them.  The big difference should be the addition
of some address space mappings, which Linux ignores
(doesn't parse, doesn't use) -- but I've never seen
a BIOS that implements address space mappings in the
MP table [and if one did, it looks like Linux would
just loop forever in smp_read_mpc(), so that's probably
not the issue here].

~Randy

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

kernel param. Q's

[Dunlap, Randy]

(Linux 2.4.0)

1.  Are the PARIDE options that are listed in
linux/Documentation/kernel-parameters.txt still valid?
I couldn't find them in drivers/block/paride anywhere.

2.  kernel-parameters.txt says (or implies to me) that
ide?=nodma
is a valid kernel option.  However, I can't see this
parsed in drivers/block anywhere.  Anybody know if this
is (still) valid?

Thanks,
~Randy_

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

Q. on marking __initdata

[Dunlap, Randy]

Hi,

Just a question (not a patch proposal):

Could
+/* # of MP IRQ source entries */
+struct mpc_config_intsrc mp_irqs[MAX_IRQ_SOURCES];

in arch/i386/kernel/mpparse.c (in 2.4.1-ac3; or in
arch/i386/kernel/io_apic.c in 2.4.1) be marked as
__initdata ?  If not, why not?  Or is __initdata
not needed on it for some reason (and if so, what
reason)?

Thanks,
~Randy_

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

Q. on marking __initdata

[Dunlap, Randy]

Hi,

Just a question (not a patch proposal):

Could
+/* # of MP IRQ source entries */
+struct mpc_config_intsrc mp_irqs[MAX_IRQ_SOURCES];

in arch/i386/kernel/mpparse.c (in 2.4.1-ac3; or in
arch/i386/kernel/io_apic.c in 2.4.1) be marked as
__initdata ?  If not, why not?  Or is __initdata
not needed on it for some reason (and if so, what
reason)?

Thanks,
~Randy_

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

RE: "kaweth" usb ethernet driver in 2.4?

[Dunlap, Randy]

It was posted on linux-usb-devel on 28-jan-2001.
Find some email archive for it, or I can forward it
to you...

~Randy

> -Original Message-
> From: Michael Rothwell [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, February 04, 2001 6:17 PM
> To: Eric Sandeen
> Cc: [EMAIL PROTECTED]
> Subject: Re: "kaweth" usb ethernet driver in 2.4?
> 
> 
> Thanks. Has Brad Hards made his version available somewhere?
> -M
> 
> - Original Message -
> From: "Eric Sandeen" <[EMAIL PROTECTED]>
> To: "Michael Rothwell" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Sunday, February 04, 2001 9:30 AM
> Subject: Re: "kaweth" usb ethernet driver in 2.4?
> 
> 
> > Michael Rothwell wrote:
> >
> > > > It also doesn't seem to work in 2.2.  :)  The original 
> development of
> > > > this driver was going on at 
> http://drivers.rd.ilan.net/kaweth/ but
> there
> > > > have been no updates for quite some time.
> > >
> > > Well, it doesn't work you _you_ on 2.2, obviously. But it 
> works for us
> > > and other people. Can you provide any information to diagnose the
> > > problem you're having?
> >
> > I'm sorry, I should have provided that info.  I searched 
> the 'net, and
> > saw many people with problems on several mailing lists, and saw no
> > solutions, or reports of success, so I assumed that it was 
> a widespread,
> > possibly even known, problem with the driver.
> >
> > I'll preface this by saying that Brad Hards sent me an 
> updated version
> > that works much better, at least as long as the module is 
> loaded before
> > the device is plugged in.
> >
> > But here's what I get with a 2.2 kernel and the stock driver:
> >
> > Kawasaki USB->Ethernet Driver loading...
> > usb.c: registered new driver kaweth
> > usb.c: USB new device connect, assigned device number 2
> > Kawasaki Device Probe (Device number:2): 0x0846:0x1001
> > Device at c2192600
> > Descriptor length: 12 type: 1
> > NetGear EA-101 connected...
> > Reading kaweth configuration
> > Request type: c0  Request: 0  Value: 0 Index: 0 Length: 12
> > usb-uhci.c: interrupt, status 2, frame# 1929
> > kaweth control message failed (urb addr: c2c05ca0)
> > usb_control/bulk_msg: timeout
> > usb-uhci.c: interrupt, status 2, frame# 851
> > Actual length: 0, length 18
> > Resetting...
> > usb-uhci.c: interrupt, status 2, frame# 854
> > Downloading firmware at c48abb6c to kaweth device at c31be000...
> > Firmware length: 3838
> > Request type: 40  Request: ff  Value: 0 Index: 0 Length: efe
> > usb-uhci.c: interrupt, status 2, frame# 871
> > kaweth control message failed (urb addr: c213ab60)
> > usb-uhci.c: interrupt, status 2, frame# 877
> > usb-uhci.c: interrupt, status 2, frame# 882
> > Actual length: 0, length 3838
> > Error downloading firmware (-110), no net device created
> >
> 
> -
> 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: IDE timeouts 2.4.1

[Dunlap, Randy]

I'm also getting a ton of these, along with lots of
file corruption.  I could handle the timeouts and
rebooting every once in awhile if I didn't also have
the corruption.

Do I have some incorrect IDE parameters?

(using 2.4.0, not 2.4.1)
dual Pentium III 933 MHz (STL2 board)
SAMSUNG 20 GB IDE hard drive
ServerWorks chipset

details--

Feb  2 19:34:51 localhost kernel: Linux version 2.4.0
([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease))
#34 SMP Tue Jan 30 17:49:24 PST 2001 
Feb  2 19:35:00 localhost kernel: DMI table at 0x000EF5C0. 
Feb  2 19:35:00 localhost kernel: BIOS Vendor: Intel Corporation 
Feb  2 19:35:01 localhost kernel: BIOS Version:
STL20.86B.0016.P01.001008 
Feb  2 19:35:01 localhost kernel: BIOS Release: 10/11/2000 
Feb  2 19:35:01 localhost kernel: System Vendor: Intel. 
Feb  2 19:35:01 localhost kernel: Product Name: STL2. 
Feb  2 19:35:01 localhost kernel: Version  . 
Feb  2 19:35:01 localhost kernel: Serial Number  . 
Feb  2 19:35:01 localhost kernel: Board Vendor: Intel. 
Feb  2 19:35:01 localhost kernel: Board Name: STL2. 
Feb  2 19:35:01 localhost kernel: Board Version: 133-639718. 
Feb  2 19:35:01 localhost kernel: Asset Tag: . 
Feb  2 19:35:01 localhost kernel: Uniform Multi-Platform E-IDE driver
Revision: 6.31 
Feb  2 19:35:02 localhost kernel: ide: Assuming 33MHz system bus speed for
PIO modes; override with idebus=xx 
Feb  2 19:35:02 localhost kernel: ServerWorks OSB4: IDE controller on PCI
bus 00 dev 79 
Feb  2 19:35:02 localhost kernel: ServerWorks OSB4: chipset revision 0 
Feb  2 19:35:02 localhost kernel: ServerWorks OSB4: not 100% native mode:
will probe irqs later 
Feb  2 19:35:02 localhost kernel: hda: SAMSUNG SV2006D fc2_17, ATA DISK
drive 
Feb  2 19:35:02 localhost kernel: hdb: TOSHIBA CD-ROM XM-6402B, ATAPI CDROM
drive 
Feb  2 19:35:02 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 
Feb  2 19:35:02 localhost kernel: hda: 40142592 sectors (20553 MB) w/480KiB
Cache, CHS=2498/255/63 
Feb  2 19:35:02 localhost kernel: hdb: ATAPI 32X CD-ROM drive, 256kB Cache 
Feb  2 19:35:02 localhost kernel: Uniform CD-ROM driver Revision: 3.12 
Feb  2 19:35:02 localhost kernel: Partition check: 
Feb  2 19:35:02 localhost kernel:  hda: hda1 hda2 hda3 < hda5 hda6 hda7 > 

/dev/hda:
 Model=SAMSUNG SV2006D fc2_17, FwRev=LS100, SerialNo=V7**BT0521
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
 BuffType=DualPortCache, BuffSize=480kB, MaxMultSect=16, MultSect=off
 CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=40142592
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: sdma0 sdma1 sdma2 *mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3
udma4 

/dev/hda:
 I/O support  =  0 (default 16-bit)

   CPU0   CPU1   
  0:  15519   9063IO-APIC-edge  timer
  1:404289IO-APIC-edge  keyboard
  2:  0  0  XT-PIC  cascade
 12:  0  0IO-APIC-edge  PS/2 Mouse
 14:  21517  20366IO-APIC-edge  ide0
 18:138121   IO-APIC-level  eth0
NMI:  24511  24512 
LOC:  24491  24492 
ERR:  0

00:0f.1 IDE interface: Relience Computer: Unknown device 0211 (prog-if 8a
[Master SecP PriP])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- http://www.tux.org/lkml/

RE: More on the VIA KT133 chipset misbehaving in Linux

[Dunlap, Randy]

> From: Rogerio Brito [mailto:[EMAIL PROTECTED]]
> 
>   While I don't have problems with the Duron above, I do have a
>   486 here with 8MB of memory that I intend to use as a router
>   for my local LAN, but 2.4.0 only recognizes 7MB, while 2.2.18
>   recognizes all 8MB. Under 2.4.0 (I haven't tried 2.4.1 yet), I
>   used a mem=8M option and it worked fine, but I don't know if
>   this is indeed safe or not (I'd guess that it would be, since
>   the 2.2 kernels use all memory, but you never know).

Fixed in 2.4.1 and its pre-patches.

~Randy

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

RE: More on the VIA KT133 chipset misbehaving in Linux

[Dunlap, Randy]

 From: Rogerio Brito [mailto:[EMAIL PROTECTED]]
 
   While I don't have problems with the Duron above, I do have a
   486 here with 8MB of memory that I intend to use as a router
   for my local LAN, but 2.4.0 only recognizes 7MB, while 2.2.18
   recognizes all 8MB. Under 2.4.0 (I haven't tried 2.4.1 yet), I
   used a mem=8M option and it worked fine, but I don't know if
   this is indeed safe or not (I'd guess that it would be, since
   the 2.2 kernels use all memory, but you never know).

Fixed in 2.4.1 and its pre-patches.

~Randy

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

RE: IDE timeouts 2.4.1

[Dunlap, Randy]

I'm also getting a ton of these, along with lots of
file corruption.  I could handle the timeouts and
rebooting every once in awhile if I didn't also have
the corruption.

Do I have some incorrect IDE parameters?

(using 2.4.0, not 2.4.1)
dual Pentium III 933 MHz (STL2 board)
SAMSUNG 20 GB IDE hard drive
ServerWorks chipset

details--

Feb  2 19:34:51 localhost kernel: Linux version 2.4.0
([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease))
#34 SMP Tue Jan 30 17:49:24 PST 2001 
Feb  2 19:35:00 localhost kernel: DMI table at 0x000EF5C0. 
Feb  2 19:35:00 localhost kernel: BIOS Vendor: Intel Corporation 
Feb  2 19:35:01 localhost kernel: BIOS Version:
STL20.86B.0016.P01.001008 
Feb  2 19:35:01 localhost kernel: BIOS Release: 10/11/2000 
Feb  2 19:35:01 localhost kernel: System Vendor: Intel. 
Feb  2 19:35:01 localhost kernel: Product Name: STL2. 
Feb  2 19:35:01 localhost kernel: Version  . 
Feb  2 19:35:01 localhost kernel: Serial Number  . 
Feb  2 19:35:01 localhost kernel: Board Vendor: Intel. 
Feb  2 19:35:01 localhost kernel: Board Name: STL2. 
Feb  2 19:35:01 localhost kernel: Board Version: 133-639718. 
Feb  2 19:35:01 localhost kernel: Asset Tag: . 
Feb  2 19:35:01 localhost kernel: Uniform Multi-Platform E-IDE driver
Revision: 6.31 
Feb  2 19:35:02 localhost kernel: ide: Assuming 33MHz system bus speed for
PIO modes; override with idebus=xx 
Feb  2 19:35:02 localhost kernel: ServerWorks OSB4: IDE controller on PCI
bus 00 dev 79 
Feb  2 19:35:02 localhost kernel: ServerWorks OSB4: chipset revision 0 
Feb  2 19:35:02 localhost kernel: ServerWorks OSB4: not 100% native mode:
will probe irqs later 
Feb  2 19:35:02 localhost kernel: hda: SAMSUNG SV2006D fc2_17, ATA DISK
drive 
Feb  2 19:35:02 localhost kernel: hdb: TOSHIBA CD-ROM XM-6402B, ATAPI CDROM
drive 
Feb  2 19:35:02 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 
Feb  2 19:35:02 localhost kernel: hda: 40142592 sectors (20553 MB) w/480KiB
Cache, CHS=2498/255/63 
Feb  2 19:35:02 localhost kernel: hdb: ATAPI 32X CD-ROM drive, 256kB Cache 
Feb  2 19:35:02 localhost kernel: Uniform CD-ROM driver Revision: 3.12 
Feb  2 19:35:02 localhost kernel: Partition check: 
Feb  2 19:35:02 localhost kernel:  hda: hda1 hda2 hda3  hda5 hda6 hda7  

/dev/hda:
 Model=SAMSUNG SV2006D fc2_17, FwRev=LS100, SerialNo=V7**BT0521
 Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
 RawCHS=16383/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
 BuffType=DualPortCache, BuffSize=480kB, MaxMultSect=16, MultSect=off
 CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=40142592
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: sdma0 sdma1 sdma2 *mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3
udma4 

/dev/hda:
 I/O support  =  0 (default 16-bit)

   CPU0   CPU1   
  0:  15519   9063IO-APIC-edge  timer
  1:404289IO-APIC-edge  keyboard
  2:  0  0  XT-PIC  cascade
 12:  0  0IO-APIC-edge  PS/2 Mouse
 14:  21517  20366IO-APIC-edge  ide0
 18:138121   IO-APIC-level  eth0
NMI:  24511  24512 
LOC:  24491  24492 
ERR:  0

00:0f.1 IDE interface: Relience Computer: Unknown device 0211 (prog-if 8a
[Master SecP PriP])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 64 set
Region 4: I/O ports at 5440 [size=16]


~Randy_
 
Michael D. Black wrote:
Happens every night on both hda and hdc -- no sure yet what triggers it but 
it is repeatable. Has happened since I've installed this machine with all 
the 2.4.x series. 
Jan 31 00:34:16 kernel: hdc: timeout waiting for DMA 
Jan 31 00:34:16 kernel: ide_dmaproc: chipset supported ide_dma_timeout func 
only: 14 
Jan 31 00:34:16 kernel: hdc: irq timeout: status=0x58 { DriveReady 
SeekComplete DataRequest } 
Jan 31 00:34:26 kernel: hdc: timeout waiting for DMA 
Jan 31 00:34:26 kernel: ide_dmaproc: chipset supported ide_dma_timeout func 
only: 14 
Jan 31 00:34:26 kernel: hdc: irq timeout: status=0x58 { DriveReady 
SeekComplete DataRequest } 
Jan 31 00:34:36 kernel: hdc: timeout waiting for DMA 
Jan 31 00:34:36 kernel: ide_dmaproc: chipset supported ide_dma_timeout func 
only: 14 
Jan 31 00:34:36 kernel: hdc: irq timeout: status=0x58 { DriveReady 
SeekComplete DataRequest } 
Jan 31 00:34:46 kernel: hdc: timeout waiting for DMA 
Jan 31 00:34:46 kernel: ide_dmaproc: chipset supported ide_dma_timeout func 
only: 14 
Jan 31 00:34:46 kernel: hdc: irq timeout: status=0x58 { DriveReady 
SeekComplete DataRequest } 
Jan 31 00:34:46 kernel: hdc: DMA disabled 
Jan 31 00:34:46 i kernel: ide1: reset: success 

-
To unsubscribe from this list: 

RE: [BUG] 2.4.1 Detects 64 MB RAM, actual 192MB

[Dunlap, Randy]

> From: Adam Schrotenboer [mailto:[EMAIL PROTECTED]]
> 
> > On Wed, 31 Jan 2001 10:01:08 -0500, Adam Schrotenboer wrote:
> > 
> >>> On Tue, 30 Jan 2001 23:25:22 -0500, Adam Schrotenboer wrote:
> >>> 
>  ...
>  Linux version 2.4.1 (root@tabriel) (gcc version egcs-2.91.66 
> >>> 
> >> 19990314/Linux (egcs-1.1.2 release)) #9 Tue Jan 30 
> 15:35:21 EST 2001
> >> 
>  BIOS-provided physical RAM map:
>  BIOS-88: 0009f000 @  (usable)
>  BIOS-88: 03ff @ 0010 (usable)
>  On node 0 totalpages: 16624
> >>> 
> >> ...
> >> Linux version 2.4.0 (root@tabriel) (gcc version 
> pgcc-2.95.2 19991024 (release)) #2 Mon Jan 8 09:02:27 EST 2001
> >> BIOS-provided physical RAM map:
> >> BIOS-e820: 0009fc00 @  (usable)
> >> BIOS-e820: 0400 @ 0009fc00 (reserved)
> >> BIOS-e820: 0001 @ 000f (reserved)
> >> BIOS-e820: 0001 @  (reserved)
> >> BIOS-e820: 0bef @ 0010 (usable)
> >> BIOS-e820: d000 @ 0bff3000 (ACPI data)
> >> BIOS-e820: 3000 @ 0bff (ACPI NVS)
> >> On node 0 totalpages: 49136
> 
> It did it again. fresh tree, egcs 1.1.2, etc
~~~
Different versions of gcc were used on 2.4.0 vs. 2.4.1.
Were different versions of as also used?  (hint?)

Or somehow in linux/arch/i386/boot/setup.S, your source
file has
#define STANDARD_MEMORY_BIOS_CALL
?

~Randy  /  503-677-5408
___
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

-
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: PCI IRQ routing problem in 2.4.0 (updated patch)

[Dunlap, Randy]

> From: Martin Diehl [mailto:[EMAIL PROTECTED]]
...
> Linus' patch helps you, because it makes us trusting the 
> device's config
> space over the routing table. Probably a good idea as long as BIOS'es
> wouldn't start to set wrong values in config space too...
...
> in fact vanilla 2.4.0 did believe what the bios states, 
> namely the broken
> routing table. It didn't believe however what the devices config space
> reports - which turned out to be correct.

The PIRQ (PCI IRQ Routing table) is a Windows 95/98 convention
(requirement).  It isn't used by NT or Windows 2000.
IOW, Linux needs to be well-prepared for handling interrupt
routing in the absence of the PIRQ table.
[http://www.microsoft.com/HWDEV/busbios/PCIIRQ.htm]

~Randy

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

RE: PCI IRQ routing problem in 2.4.0 (updated patch)

[Dunlap, Randy]

 From: Martin Diehl [mailto:[EMAIL PROTECTED]]
...
 Linus' patch helps you, because it makes us trusting the 
 device's config
 space over the routing table. Probably a good idea as long as BIOS'es
 wouldn't start to set wrong values in config space too...
...
 in fact vanilla 2.4.0 did believe what the bios states, 
 namely the broken
 routing table. It didn't believe however what the devices config space
 reports - which turned out to be correct.

The PIRQ (PCI IRQ Routing table) is a Windows 95/98 convention
(requirement).  It isn't used by NT or Windows 2000.
IOW, Linux needs to be well-prepared for handling interrupt
routing in the absence of the PIRQ table.
[http://www.microsoft.com/HWDEV/busbios/PCIIRQ.htm]

~Randy

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

RE: [BUG] 2.4.1 Detects 64 MB RAM, actual 192MB

[Dunlap, Randy]

 From: Adam Schrotenboer [mailto:[EMAIL PROTECTED]]
 
  On Wed, 31 Jan 2001 10:01:08 -0500, Adam Schrotenboer wrote:
  
  On Tue, 30 Jan 2001 23:25:22 -0500, Adam Schrotenboer wrote:
  
  ...
  Linux version 2.4.1 (root@tabriel) (gcc version egcs-2.91.66 
  
  19990314/Linux (egcs-1.1.2 release)) #9 Tue Jan 30 
 15:35:21 EST 2001
  
  BIOS-provided physical RAM map:
  BIOS-88: 0009f000 @  (usable)
  BIOS-88: 03ff @ 0010 (usable)
  On node 0 totalpages: 16624
  
  ...
  Linux version 2.4.0 (root@tabriel) (gcc version 
 pgcc-2.95.2 19991024 (release)) #2 Mon Jan 8 09:02:27 EST 2001
  BIOS-provided physical RAM map:
  BIOS-e820: 0009fc00 @  (usable)
  BIOS-e820: 0400 @ 0009fc00 (reserved)
  BIOS-e820: 0001 @ 000f (reserved)
  BIOS-e820: 0001 @  (reserved)
  BIOS-e820: 0bef @ 0010 (usable)
  BIOS-e820: d000 @ 0bff3000 (ACPI data)
  BIOS-e820: 3000 @ 0bff (ACPI NVS)
  On node 0 totalpages: 49136
 
 It did it again. fresh tree, egcs 1.1.2, etc
~~~
Different versions of gcc were used on 2.4.0 vs. 2.4.1.
Were different versions of as also used?  (hint?)

Or somehow in linux/arch/i386/boot/setup.S, your source
file has
#define STANDARD_MEMORY_BIOS_CALL
?

~Randy  /  503-677-5408
___
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

-
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: Multiplexing mouse input

[Dunlap, Randy]

The "USB Guide" section on HID devices could also be
helpful to you.
http://www.linux-usb.org/USB-guide/x194.html

~Randy  /  503-677-5408
___

> From: Ben Ford [mailto:[EMAIL PROTECTED]]
> 
> You are probably talking about an Xfree issue.  And yes it 
> can be done.  I
> know several people that do that.  Refer to the XFree86 website.
> 
> -b
> 
> 
> Dax Kelson wrote:
> 
> > My laptop has a touchpad builtin with two buttons, I also 
> have an external
> > PS2 and/or USB mouse (3 buttons with scroll wheel).
> >
> > I would like to be able to use the touchpad, and then plug 
> in the mouse
> > (with either PS2 or USB connector) and use it without reconfiguring
> > anything.
> >
> > In fact, it would be cool if I could use both at the same time.
> >
> > Is this possible with the new "Input Drivers" in the 2.4 
> kernel?  Is it
> > possible with Linux at all?
> >
> > As a comparison, at least two other OSes, Windows 2000 and 
> NetBSD 1.5
> > multiplex mouse input and allow use of two (or more!) mice 
> at the same
> > time.
> >
> > Dax Kelson
> >
> > NetBSD "wscons console driver" info:
> >
> > http://www.netbsd.org/Documentation/wscons/

-
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: Multiplexing mouse input

[Dunlap, Randy]

The "USB Guide" section on HID devices could also be
helpful to you.
http://www.linux-usb.org/USB-guide/x194.html

~Randy  /  503-677-5408
___

 From: Ben Ford [mailto:[EMAIL PROTECTED]]
 
 You are probably talking about an Xfree issue.  And yes it 
 can be done.  I
 know several people that do that.  Refer to the XFree86 website.
 
 -b
 
 
 Dax Kelson wrote:
 
  My laptop has a touchpad builtin with two buttons, I also 
 have an external
  PS2 and/or USB mouse (3 buttons with scroll wheel).
 
  I would like to be able to use the touchpad, and then plug 
 in the mouse
  (with either PS2 or USB connector) and use it without reconfiguring
  anything.
 
  In fact, it would be cool if I could use both at the same time.
 
  Is this possible with the new "Input Drivers" in the 2.4 
 kernel?  Is it
  possible with Linux at all?
 
  As a comparison, at least two other OSes, Windows 2000 and 
 NetBSD 1.5
  multiplex mouse input and allow use of two (or more!) mice 
 at the same
  time.
 
  Dax Kelson
 
  NetBSD "wscons console driver" info:
 
  http://www.netbsd.org/Documentation/wscons/

-
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: [uPATCH][Probably fucked up] arch/i386/kernel/io_apic.c: missing extern? (241p10)

[Dunlap, Randy]

Rasmus,

Yep, I noticed this during some recent ServerWorks chipset
APIC work I have been doing.

nr_ioapics is also used in arch/i386/kernel/apic.c
(#ifdef CONFIG_X86_IO_APIC), so that should have an
  extern int nr_ioapics;
also.

I'd prefer to see nr_ioapics live near the mp_ioapics[] array,
in io_apic.c, and add an
  extern int nr_ioapics;
in mpparse.c also.

And while your patch will compile without syntax errors,
it has linker errors on undefined references to 'nr_ioapics'.


> In arch/i386/kernel we declare nr_ioapics in both io_apic.c 
> and mpparse.c.

Where is it declared in mpparse.c ?
I don't see it.

> I guess that one of them should be an 'extern' declaration? 
> In the patch
> below I have guessed that it is io_apic.c that is missing it 
> since (AFAICS)
> never assign to nr_ioapic in this file. 

It's only _read_ in io_apic.c and written in mpparse.c.

> But I am in way over my head here so please be gentle when you point
> out my mistake.
> 
> The patch (against 241p10 and ac11):
> 
> 
> --- linux-ac11-clean/arch/i386/kernel/io_apic.c   Thu Jan 
> 25 20:48:51 2001
> +++ linux-ac11/arch/i386/kernel/io_apic.c Fri Jan 26 21:59:16 2001
> @@ -38,7 +38,7 @@
>  /*
>   * # of IRQ routing registers
>   */
> -int nr_ioapics;
> +extern int nr_ioapics;
>  int nr_ioapic_registers[MAX_IO_APICS];
>  
>  #if CONFIG_SMP
> 
> -- 
> Regards,
> Rasmus([EMAIL PROTECTED])


~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

-
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: [uPATCH][Probably fucked up] arch/i386/kernel/io_apic.c: missing extern? (241p10)

[Dunlap, Randy]

Rasmus,

Yep, I noticed this during some recent ServerWorks chipset
APIC work I have been doing.

nr_ioapics is also used in arch/i386/kernel/apic.c
(#ifdef CONFIG_X86_IO_APIC), so that should have an
  extern int nr_ioapics;
also.

I'd prefer to see nr_ioapics live near the mp_ioapics[] array,
in io_apic.c, and add an
  extern int nr_ioapics;
in mpparse.c also.

And while your patch will compile without syntax errors,
it has linker errors on undefined references to 'nr_ioapics'.


 In arch/i386/kernel we declare nr_ioapics in both io_apic.c 
 and mpparse.c.

Where is it declared in mpparse.c ?
I don't see it.

 I guess that one of them should be an 'extern' declaration? 
 In the patch
 below I have guessed that it is io_apic.c that is missing it 
 since (AFAICS)
 never assign to nr_ioapic in this file. 

It's only _read_ in io_apic.c and written in mpparse.c.

 But I am in way over my head here so please be gentle when you point
 out my mistake.
 
 The patch (against 241p10 and ac11):
 
 
 --- linux-ac11-clean/arch/i386/kernel/io_apic.c   Thu Jan 
 25 20:48:51 2001
 +++ linux-ac11/arch/i386/kernel/io_apic.c Fri Jan 26 21:59:16 2001
 @@ -38,7 +38,7 @@
  /*
   * # of IRQ routing registers
   */
 -int nr_ioapics;
 +extern int nr_ioapics;
  int nr_ioapic_registers[MAX_IO_APICS];
  
  #if CONFIG_SMP
 
 -- 
 Regards,
 Rasmus([EMAIL PROTECTED])


~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

-
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: Teledat USB 2 a/b

[Dunlap, Randy]

Some USB ISDN TAs work with Linux-USB.
See http://www.qbik.ch/usb/devices/ + Device Overview + Comm.
Several are listed there.
The Teledat is not listed, so it may or may not work.

You could try attaching the device with the "acm" driver
loaded to see if the acm driver claims the device.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> From: Thunder from the hill [mailto:[EMAIL PROTECTED]]
> 
> Is there support for external USB ISDN boxes like the Teledat 
> USB 2 a/b?
> I don't really know this box, but there's someone asking for 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: Teledat USB 2 a/b

[Dunlap, Randy]

Some USB ISDN TAs work with Linux-USB.
See http://www.qbik.ch/usb/devices/ + Device Overview + Comm.
Several are listed there.
The Teledat is not listed, so it may or may not work.

You could try attaching the device with the "acm" driver
loaded to see if the acm driver claims the device.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

 From: Thunder from the hill [mailto:[EMAIL PROTECTED]]
 
 Is there support for external USB ISDN boxes like the Teledat 
 USB 2 a/b?
 I don't really know this box, but there's someone asking for 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: 2.2.19pre6aa1 USB - Why do I get these?

[Dunlap, Randy]

> Previously unseen. What could be the cause of these messages?
> (Abit BH6 (Intel BX), Logitech Mouseman+ USB)
> 
> Jan 24 21:39:15 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0
> requesters
> Jan 24 21:39:16 iq kernel: usb.c: bw_alloc increased by 118 
> to 118 for 1 requesters
..

These messages have been there all along.  In recent 2.4
kernels, they are #ifdef-ed out.  Same needs to be done
for 2.2.x.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

-
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.2.19pre6aa1 USB - Why do I get these?

[Dunlap, Randy]

 Previously unseen. What could be the cause of these messages?
 (Abit BH6 (Intel BX), Logitech Mouseman+ USB)
 
 Jan 24 21:39:15 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0
 requesters
 Jan 24 21:39:16 iq kernel: usb.c: bw_alloc increased by 118 
 to 118 for 1 requesters
..

These messages have been there all along.  In recent 2.4
kernels, they are #ifdef-ed out.  Same needs to be done
for 2.2.x.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

-
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: int. assignment on SMP + ServerWorks chipset

[Dunlap, Randy]

> From: Duncan Laurie [mailto:[EMAIL PROTECTED]]
> 
> On Mon, 22 Jan 2001, Randy.Dunlap wrote:
> 
> Hi Randy,
> 
> Oops, I knew it was an STL2, but somehow couldn't get it right in the
> message..  It looks like they both use ServerWorks LE chipsets, do you
> know if the SBT2 has the same problem?

I don't have an SBT2 to test, but it's likely that they share
this problem.  The only difference in them is supposed to be
SBT2 using bigger/faster processors.

> I did see that your BIOS is build 16 (STL20.86B.0016.P01.001008)
> while Petr has build 17 (STL20.86B.0017.P01.0011291152) which also
> appears to be the latest release.  Not that it has any affect on this
> particular problem, but it might explain why the patch worked for you
> and not him.
> 
> I looked at the Technical Product Specification,
> (ftp://download.intel.com/support/motherboards/server/stl2/stl
2_tps.pdf)
> and it appears that they have released BIOS updates to fix Errata 
> regarding Linux boot problems, so chances are good that it may be fixed
> by a future update.  Until then, the 'mpint' parameter patch seems
> pretty harmless, yet flexible enough to handle subtle differences
> in hardware and configuration.

Yes, I tested that one as well and it works for me, using
"mpint=5,0,4,9".
But now I need to upgrade the BIOS and I can't run phlash.exe!!!

...

| Here's my output from dump_pirq.  Is the PCI router info unique
| enough so that you'll need to debug it instead of me doing so?
| ~
| [root@localhost src]# ./dump_pirq
|  
| Interrupt routing table found at address 0xfdf10
|   Version 1.0, 0 bytes
|   Interrupt router is device ff:1f.7
|   PCI exclusive interrupt mask: 0x []
|  
| Interrupt router at ff:1f.7:
| Could not read router info from /proc/bus/pci/ff/1f.7.
| [root@localhost src]#
| ~~~
|

> Hrm, this certainly doesn't look right.  You mentioned in a previous
> message that changing the OS type from PnP-aware did not have any
> effect, but if disabled the BIOS might not be creating the PIRQ
> tables.  Hopefully it will still take care of the IRQ routing, which
> means you should be able to read the value directly.  (it better or
> USB shouldn't work in UP!)  Try the following program:

USB works in UP mode (smp kernel, with "nosmp noapic").

dump_pirq in UP mode, PNP OS = Yes or No, gives the same
output as above.  I'd still like to get dump_pirq
working if you have something else that I could try.

---
USB Interrupt: 9
---

Yes, the BIOS assigns interrupt 9 to USB.  9 is the correct
value as far as the BIOS is concerned.

BTW, where is the  structure defined, in what
spec?

~Randy

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

RE: int. assignment on SMP + ServerWorks chipset

[Dunlap, Randy]

Hi Duncan,

> From: Duncan Laurie [mailto:[EMAIL PROTECTED]]
> 
> Hi Petr,
> 
> I didn't consider that your hardware would have subtle differences
> than Mr. Dunlap's Intel SBT2 board, but these could have made the
> hard-coded values in the patch invalid.  So instead try the attached
> patch, and this time you'll need to plug in some values into a boot
> parameter to override the mptable entry.

Petr's listing of /proc/interrupts also did not use IRQ 9
(from Jan. 11, 2001 email).

I expect that our STL2 boards are very much alike, with possible
differences in processor speed and RAM size.  I also have
disabled SCSI in BIOS SETUP while Petr has not, since he is using
SCSI disks and I am using IDE.

> This "mpint=" parameter allows you to alter a specific (IO)INT mptable
> entry destination APIC and INT.  It takes four arguments, the first
> two for looking up the entry to change in the current mptable by APIC
> and INT, and the second two are for the new APIC and INT 
> values to use.
> (I also have an expanded version that allows more detailed
> modifications but the number of arguments gets out of hand very fast)
> 
> The values to use depend on what your system is configured to use
> for the USB interrupt.  This can be obtained by using the dump_pirq
> utility from the recent pcmcia utilities.  (I made some modifications
> to recognize the ServerWorks IRQ router which is available from
> ftp://virtualwire.org/dump_pirq)

Thanks for that.

> The output you are looking for should look something like this:
> 
> Device 00:0f.0 (slot 0): ISA bridge
> INTA: link 0x01, irq mask 0x0400 [10]
> 
> The USB device is actually function 2, but uses INTA#.  The irq
> mask value should give you the new INT value to put in the
> mptable.  The old INT value can be read from the dmesg output
> or by compiling and running mptable, which I also made available
> at ftp://virtualwire.org/mptable.c.  (it appears to be '0' on your
> hardware as well as Mr. Dunlap's)  The destination APIC should just
> be the ID of the first IO-APIC in the system, in this case 4.

I had also ported that program a few months ago, but was
advised against it since the BIOS can build the MP table
dynamically, and it could be from a skeleton table in EEPROM,
so the mptable program could find and print the wrong version
of the table.  Just a small warning.

> So based on the example above, you would add "mpint=5,0,4,10" to
> the boot parameters.  One caveat, this doesn't actually change the
> mptable as it is stored in memory so if you use the mptable program
> to view it you will still see the original values.

Duncan, do you still think that there might be a BIOS MP table
error?  Also, what would you propose as a long-term solution to
this problem?  This patch or something else?

Thanks,
~Randy


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

RE: int. assignment on SMP + ServerWorks chipset

[Dunlap, Randy]

Hi Duncan,

 From: Duncan Laurie [mailto:[EMAIL PROTECTED]]
 
 Hi Petr,
 
 I didn't consider that your hardware would have subtle differences
 than Mr. Dunlap's Intel SBT2 board, but these could have made the
 hard-coded values in the patch invalid.  So instead try the attached
 patch, and this time you'll need to plug in some values into a boot
 parameter to override the mptable entry.

Petr's listing of /proc/interrupts also did not use IRQ 9
(from Jan. 11, 2001 email).

I expect that our STL2 boards are very much alike, with possible
differences in processor speed and RAM size.  I also have
disabled SCSI in BIOS SETUP while Petr has not, since he is using
SCSI disks and I am using IDE.

 This "mpint=" parameter allows you to alter a specific (IO)INT mptable
 entry destination APIC and INT.  It takes four arguments, the first
 two for looking up the entry to change in the current mptable by APIC
 and INT, and the second two are for the new APIC and INT 
 values to use.
 (I also have an expanded version that allows more detailed
 modifications but the number of arguments gets out of hand very fast)
 
 The values to use depend on what your system is configured to use
 for the USB interrupt.  This can be obtained by using the dump_pirq
 utility from the recent pcmcia utilities.  (I made some modifications
 to recognize the ServerWorks IRQ router which is available from
 ftp://virtualwire.org/dump_pirq)

Thanks for that.

 The output you are looking for should look something like this:
 
 Device 00:0f.0 (slot 0): ISA bridge
 INTA: link 0x01, irq mask 0x0400 [10]
 
 The USB device is actually function 2, but uses INTA#.  The irq
 mask value should give you the new INT value to put in the
 mptable.  The old INT value can be read from the dmesg output
 or by compiling and running mptable, which I also made available
 at ftp://virtualwire.org/mptable.c.  (it appears to be '0' on your
 hardware as well as Mr. Dunlap's)  The destination APIC should just
 be the ID of the first IO-APIC in the system, in this case 4.

I had also ported that program a few months ago, but was
advised against it since the BIOS can build the MP table
dynamically, and it could be from a skeleton table in EEPROM,
so the mptable program could find and print the wrong version
of the table.  Just a small warning.

 So based on the example above, you would add "mpint=5,0,4,10" to
 the boot parameters.  One caveat, this doesn't actually change the
 mptable as it is stored in memory so if you use the mptable program
 to view it you will still see the original values.

Duncan, do you still think that there might be a BIOS MP table
error?  Also, what would you propose as a long-term solution to
this problem?  This patch or something else?

Thanks,
~Randy


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

RE: int. assignment on SMP + ServerWorks chipset

[Dunlap, Randy]

Hi Duncan,

Your temporary patch enables my USB host controller and USB devices
(mouse, hub, and keyboard) to work on an STL2 system.


> From: Duncan Laurie [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 16, 2001 5:40 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: int. assignment on SMP + ServerWorks chipset
> 
...
> This may actually be an MP BIOS bug...

Yes, I was also thinking this.  I'll check with some other
people on it tomorrow.

Thanks,
~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> According to the boot log, the MP table I/O Interrupt entry for the
> USB controller (PCI device 00:0f:02) is:
> 
>Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 5, APIC INT 00
> 
> Which specifies the destination APIC ID 5 (corresponding to the 2nd
> IO-APIC, used solely to distribute PCI interrupts) and destination INT
> pin 0.  So when the IO-APICs are programmed this IRQ is remapped to:
> 
>PCI->APIC IRQ transform: (B0,I15,P0) -> 16
> 
> The problem is the USB Interrupt is internally routed and should use
> the ISA IO-APIC for the destination APIC, and a valid ISA IRQ for the
> destination INT.  The MP table entry and corresponding IRQ transform
> should look something like this:
> 
>[I used INT 09 simply because it wasn't already assigned...]
> 
>Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 4, APIC INT 09
>PCI->APIC IRQ transform: (B0,I15,P0) -> 9
> 
> Here's a patch to find & correct this entry on boot.  Its not pretty,
> and should ONLY be used to verify this particular fix--any 
> real solution
> will have to be done in the BIOS.  (there doesn't seem to be 
> an easy way
> to alter specific MP table entries outside of the BIOS, especially if
> they happen to exist in write-protected memory regions...)
> 
> There may be bogus data in the PIRQ table as well, which is why this
> explicitly routes the interrupt & sets the ELCR.  If you enable DEBUG
> in pci-i386.h and re-send the dmesg output I will look it over.
> 
> -duncan
> 
> 
> --- linux/arch/i386/kernel/mpparse.c  Tue Nov 14 22:25:34 2000
> +++ linux~/arch/i386/kernel/mpparse.c Tue Jan 16 17:11:07 2001
> @@ -237,6 +237,37 @@
>
>   m->mpc_irqtype, m->mpc_irqflag & 3,
>
>   (m->mpc_irqflag >> 2) & 3, m->mpc_srcbus,
>
>   m->mpc_srcbusirq, m->mpc_dstapic, m->mpc_dstirq);
> +
> + 
> if ((m->mpc_irqtype == 0) && ((m->mpc_irqflag & 3) == 3) &&
> + 
>  ((m->mpc_irqflag >> 2) == 3) && (m->mpc_srcbus == 0) &&
> + 
>  (m->mpc_dstapic == 5) && (m->mpc_srcbusirq == 0x3c))
> + 
> {
> + 
>   struct mpc_config_intsrc usbint = { MP_INTSRC,
> + 
>   0x00, 0x000f, 0x00,
> + 
>   0x3c, 0x04, 0x09 };
> + 
>   unsigned char mask = 1 << (usbint.mpc_dstirq & 7);
> + 
>   unsigned int port = 0x4d0 + (usbint.mpc_dstirq >> 3);
> + 
>   unsigned char val = inb(port);
> +
> + 
>   Dprintk("MP BIOS bug, USB INT should use ISA IO-APIC!\n");
> +
> + 
>   /* fix PIRQ routing entry: index 1 -> dstirq */
> + 
>   outb_p(1, 0xc00);
> + 
>   outb_p(usbint.mpc_dstirq, 0xc01);
> + 
>   if (!(val & mask))
> + 
>   outb(val|mask, port);
> +
> + 
>   /* use modified intsrc struct */
> + 
>   mp_irqs[mp_irq_entries] = usbint;
> +
> + 
>   Dprintk("Int: type %d, pol %d, trig %d, bus %d,"
> + 
>   " IRQ %02x, APIC ID %x, APIC INT %02x\n",
> + 
>   usbint.mpc_irqtype, usbint.mpc_irqflag & 3,
> + 
>   (usbint.mpc_irqflag >> 2) & 3,
> + 
>   usbint.mpc_srcbus,  usbint.mpc_srcbusirq,
> + 
>   usbint.mpc_dstapic, usbint.mpc_dstirq);
> + 
> }
> +
>   if (++mp_irq_entries == MAX_IRQ_SOURCES)
>   panic("Max # of irq sources exceeded!!\n");
>   }

-
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: int. assignment on SMP + ServerWorks chipset

[Dunlap, Randy]

Hi Duncan,

Your temporary patch enables my USB host controller and USB devices
(mouse, hub, and keyboard) to work on an STL2 system.


 From: Duncan Laurie [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, January 16, 2001 5:40 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
 [EMAIL PROTECTED]
 Subject: RE: int. assignment on SMP + ServerWorks chipset
 
...
 This may actually be an MP BIOS bug...

Yes, I was also thinking this.  I'll check with some other
people on it tomorrow.

Thanks,
~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

 According to the boot log, the MP table I/O Interrupt entry for the
 USB controller (PCI device 00:0f:02) is:
 
Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 5, APIC INT 00
 
 Which specifies the destination APIC ID 5 (corresponding to the 2nd
 IO-APIC, used solely to distribute PCI interrupts) and destination INT
 pin 0.  So when the IO-APICs are programmed this IRQ is remapped to:
 
PCI-APIC IRQ transform: (B0,I15,P0) - 16
 
 The problem is the USB Interrupt is internally routed and should use
 the ISA IO-APIC for the destination APIC, and a valid ISA IRQ for the
 destination INT.  The MP table entry and corresponding IRQ transform
 should look something like this:
 
[I used INT 09 simply because it wasn't already assigned...]
 
Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 4, APIC INT 09
PCI-APIC IRQ transform: (B0,I15,P0) - 9
 
 Here's a patch to find  correct this entry on boot.  Its not pretty,
 and should ONLY be used to verify this particular fix--any 
 real solution
 will have to be done in the BIOS.  (there doesn't seem to be 
 an easy way
 to alter specific MP table entries outside of the BIOS, especially if
 they happen to exist in write-protected memory regions...)
 
 There may be bogus data in the PIRQ table as well, which is why this
 explicitly routes the interrupt  sets the ELCR.  If you enable DEBUG
 in pci-i386.h and re-send the dmesg output I will look it over.
 
 -duncan
 
 
 --- linux/arch/i386/kernel/mpparse.c  Tue Nov 14 22:25:34 2000
 +++ linux~/arch/i386/kernel/mpparse.c Tue Jan 16 17:11:07 2001
 @@ -237,6 +237,37 @@

   m-mpc_irqtype, m-mpc_irqflag  3,

   (m-mpc_irqflag  2)  3, m-mpc_srcbus,

   m-mpc_srcbusirq, m-mpc_dstapic, m-mpc_dstirq);
 +
 + 
 if ((m-mpc_irqtype == 0)  ((m-mpc_irqflag  3) == 3) 
 + 
  ((m-mpc_irqflag  2) == 3)  (m-mpc_srcbus == 0) 
 + 
  (m-mpc_dstapic == 5)  (m-mpc_srcbusirq == 0x3c))
 + 
 {
 + 
   struct mpc_config_intsrc usbint = { MP_INTSRC,
 + 
   0x00, 0x000f, 0x00,
 + 
   0x3c, 0x04, 0x09 };
 + 
   unsigned char mask = 1  (usbint.mpc_dstirq  7);
 + 
   unsigned int port = 0x4d0 + (usbint.mpc_dstirq  3);
 + 
   unsigned char val = inb(port);
 +
 + 
   Dprintk("MP BIOS bug, USB INT should use ISA IO-APIC!\n");
 +
 + 
   /* fix PIRQ routing entry: index 1 - dstirq */
 + 
   outb_p(1, 0xc00);
 + 
   outb_p(usbint.mpc_dstirq, 0xc01);
 + 
   if (!(val  mask))
 + 
   outb(val|mask, port);
 +
 + 
   /* use modified intsrc struct */
 + 
   mp_irqs[mp_irq_entries] = usbint;
 +
 + 
   Dprintk("Int: type %d, pol %d, trig %d, bus %d,"
 + 
   " IRQ %02x, APIC ID %x, APIC INT %02x\n",
 + 
   usbint.mpc_irqtype, usbint.mpc_irqflag  3,
 + 
   (usbint.mpc_irqflag  2)  3,
 + 
   usbint.mpc_srcbus,  usbint.mpc_srcbusirq,
 + 
   usbint.mpc_dstapic, usbint.mpc_dstirq);
 + 
 }
 +
   if (++mp_irq_entries == MAX_IRQ_SOURCES)
   panic("Max # of irq sources exceeded!!\n");
   }

-
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] memparse should return long long

[Dunlap, Randy]

Why not (?):

> diff -uNr 2.4.0-ac/lib/cmdline.c 2.4.0-ac-memparse/lib/cmdline.c
> --- 2.4.0-ac/lib/cmdline.cMon Aug 28 11:42:45 2000
> +++ 2.4.0-ac-memparse/lib/cmdline.c   Mon Jan 15 09:06:14 2001
> @@ -93,9 +93,9 @@
>   *   megabyte, or one gigabyte, respectively.
>   */
>  
> -unsigned long memparse (char *ptr, char **retptr)
> +unsigned long long memparse (char *ptr, char **retptr)
>  {
> - unsigned long ret = simple_strtoul (ptr, retptr, 0);
> + unsigned long long ret = simple_strtoul (ptr, retptr, 0);
! + unsigned long long ret = simple_strtoull (ptr, retptr, 0);

~Randy

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

RE: [Patch] memparse should return long long

[Dunlap, Randy]

Why not (?):

 diff -uNr 2.4.0-ac/lib/cmdline.c 2.4.0-ac-memparse/lib/cmdline.c
 --- 2.4.0-ac/lib/cmdline.cMon Aug 28 11:42:45 2000
 +++ 2.4.0-ac-memparse/lib/cmdline.c   Mon Jan 15 09:06:14 2001
 @@ -93,9 +93,9 @@
   *   megabyte, or one gigabyte, respectively.
   */
  
 -unsigned long memparse (char *ptr, char **retptr)
 +unsigned long long memparse (char *ptr, char **retptr)
  {
 - unsigned long ret = simple_strtoul (ptr, retptr, 0);
 + unsigned long long ret = simple_strtoul (ptr, retptr, 0);
! + unsigned long long ret = simple_strtoull (ptr, retptr, 0);

~Randy

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

RE: The latest instance in the A20 farce

[Dunlap, Randy]

> From: H. Peter Anvin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 10, 2001 4:10 PM
> 
> "Dunlap, Randy" wrote:
> > 
> > a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
> >but that is handled by your patch.
> 
> Idiots.  This should be required and be a null function; likewise
> AH=0x2400.  The only thing that the current spec means is that 
> 
> > b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
> >(Ye Olde Traditional memory-size function).
> 
> Incorrect; see page 226.

Right.  Somehow I looked at that and didn't see it.

> >Hopefully the other memory-size methods will always have
> >priority.
> > c. A20M# is always de-asserted at the processor [Ch. 3, 
> item SYS-0047]
> > 
> > I bring these up because they may have some impact on SYSLINUX,
> > LILO, etc., and the data structures that they use (like the
> > memory_size item) and because some of these systems don't
> > have a "real mode," so loaders can't reliably assume that
> > they do (unless it's transparent to the loaders)...
> > and because you know something about SYSLINUX etc.
> > 
> 
> URRRK.  I get a feeling these specs are either there to make 
> life extra difficult for programmers,
> because the people that design them are too
> stupid to tie their own shoes, or because they want nothing but M$
> factory-installed to work.
> 
> A20M# always deasserted: this is all fine and good if we had 
> nothing else
> to worry about, but they really have managed to fuck up when 
> it comes to
> getting something to work *ACROSS THE BOARD*.  THEY DON'T 
> GIVE ME A WAY
> TO DETECT THE FACT THAT A20M# IS FIXED!  This is 
> particularly nasty
> when going back to real mode, since I don't have a way to 
> figure out that I can't turn A20M# back to its old state.  

I'm not sure about this, but I'm wondering if the
Fixed (as in Static) ACPI Description Table (FADT)
can indicate that the platform is a legacy-free system.

According to the ACPI 2.0 spec, FADT field "Boot Architecture
Flags", bit 0 (LEGACY_DEVICES) indicates whether there are
legacy devices (user-visible) on the system.  I'm not sure
that this is adequate/equivalent.  I'll continue to check into it.
Even if it is adequate/equiv, it's not pretty.

> I also really, really, *REALLY* hate them for killing serial 
> ports.  It's a Bad Idea[TM].

Got the Message.

> Worse, they define that port 92h, bit 1, is no longer 
> A20M#... but they
> don't forbid the system from using it for other things.

I don't quite see it that way.  Where do you see that?
Maybe it just needs to be more explicit.

Ch. 3 (SYS-0047) says that port 92h:bit 1 doesn't toggle/affect A20M#.
Appendix A says that port 92h is (still?) "System Control Port A"
(not defined here AFAIK).
(I haven't checked all of the other chapters/appendices.)

>   -hpa
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

-
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: The latest instance in the A20 farce

[Dunlap, Randy]

hpa-

I tested this patch on a Pentium dual-proc system (440GX)
and on a Celeron system[1] (810) that lacks floppy, keyboard
controller, maybe some other things.

Linux 2.4.0 boots fine on each of these systems with this
patch applied.  I couldn't tell which method of
enabling A20 was actually successful.
Have you had any other reports on the patch?


[1] I'm not sure if this system qualifies as "legacy free"
or "legacy reduced."  However, for future (how far?)
reference, on legacy-free systems:
[from PDF file at http://www.pcdesguide.org/pc2001/default.htm]

a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
   but that is handled by your patch.
b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
   (Ye Olde Traditional memory-size function).
   Hopefully the other memory-size methods will always have
   priority.
c. A20M# is always de-asserted at the processor [Ch. 3, item SYS-0047]

I bring these up because they may have some impact on SYSLINUX,
LILO, etc., and the data structures that they use (like the
memory_size item) and because some of these systems don't
have a "real mode," so loaders can't reliably assume that
they do (unless it's transparent to the loaders)...
and because you know something about SYSLINUX etc.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> From: H. Peter Anvin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 06, 2000 3:55 PM
> 
> Okay, here is yet another A20 patch (against test12-pre6) this time
> for people to try out.  This patch uses the following algorithm for
> enabling A20:
> 
> 1. Try the BIOS call.  If it works, we're cool.
> 2. Try the KBC (using Linus' lowered timeouts.)
> 3. If the KBC doesn't work, or is very slow, flip port 92.
> 
> After 3 it sits into the same infinite loop waiting for A20 to become
> enabled (necessary on for example some Toshiba notebooks which have an
> extremely slow response to A20.)
> 
> The main differences between this patch and test12-pre6:
> 
> - Trying the BIOS first of all.  This should reduce the risk of the
>   BIOS getting confused while doing a suspend.  This also gives even
>   less of an excuse for any nonstandard arrangement -- if you didn't
>   implement the standard KBC *and* you didn't provide the BIOS call,
>   you have a seriously broken piece of hardware.
> 
> - If the KBC responds quickly enough (within about 1 cycles), we
>   don't ever touch the fast A20 gate.  This is a difference from
>   previous code, where the fast A20 gate was toggled immediately after
>   the KBC, even if the KBC responded instantly.
> 
> - I had to move the A20 code somewhat earlier in setup.S in order for
>   the BIOS to still be available.
> 
> Please try it out and let me know as soon as possible...
> 
>   -hpa
> 
> 
> --- arch/i386/boot/setup.S.12p6   Wed Dec  6 12:49:07 2000
> +++ arch/i386/boot/setup.SWed Dec  6 15:25:01 2000
...
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!

-
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: The latest instance in the A20 farce

[Dunlap, Randy]

hpa-

I tested this patch on a Pentium dual-proc system (440GX)
and on a Celeron system[1] (810) that lacks floppy, keyboard
controller, maybe some other things.

Linux 2.4.0 boots fine on each of these systems with this
patch applied.  I couldn't tell which method of
enabling A20 was actually successful.
Have you had any other reports on the patch?


[1] I'm not sure if this system qualifies as "legacy free"
or "legacy reduced."  However, for future (how far?)
reference, on legacy-free systems:
[from PDF file at http://www.pcdesguide.org/pc2001/default.htm]

a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
   but that is handled by your patch.
b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
   (Ye Olde Traditional memory-size function).
   Hopefully the other memory-size methods will always have
   priority.
c. A20M# is always de-asserted at the processor [Ch. 3, item SYS-0047]

I bring these up because they may have some impact on SYSLINUX,
LILO, etc., and the data structures that they use (like the
memory_size item) and because some of these systems don't
have a "real mode," so loaders can't reliably assume that
they do (unless it's transparent to the loaders)...
and because you know something about SYSLINUX etc.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

 From: H. Peter Anvin [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, December 06, 2000 3:55 PM
 
 Okay, here is yet another A20 patch (against test12-pre6) this time
 for people to try out.  This patch uses the following algorithm for
 enabling A20:
 
 1. Try the BIOS call.  If it works, we're cool.
 2. Try the KBC (using Linus' lowered timeouts.)
 3. If the KBC doesn't work, or is very slow, flip port 92.
 
 After 3 it sits into the same infinite loop waiting for A20 to become
 enabled (necessary on for example some Toshiba notebooks which have an
 extremely slow response to A20.)
 
 The main differences between this patch and test12-pre6:
 
 - Trying the BIOS first of all.  This should reduce the risk of the
   BIOS getting confused while doing a suspend.  This also gives even
   less of an excuse for any nonstandard arrangement -- if you didn't
   implement the standard KBC *and* you didn't provide the BIOS call,
   you have a seriously broken piece of hardware.
 
 - If the KBC responds quickly enough (within about 1 cycles), we
   don't ever touch the fast A20 gate.  This is a difference from
   previous code, where the fast A20 gate was toggled immediately after
   the KBC, even if the KBC responded instantly.
 
 - I had to move the A20 code somewhat earlier in setup.S in order for
   the BIOS to still be available.
 
 Please try it out and let me know as soon as possible...
 
   -hpa
 
 
 --- arch/i386/boot/setup.S.12p6   Wed Dec  6 12:49:07 2000
 +++ arch/i386/boot/setup.SWed Dec  6 15:25:01 2000
...
 -- 
 [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!

-
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: The latest instance in the A20 farce

[Dunlap, Randy]

 From: H. Peter Anvin [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, January 10, 2001 4:10 PM
 
 "Dunlap, Randy" wrote:
  
  a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
 but that is handled by your patch.
 
 Idiots.  This should be required and be a null function; likewise
 AH=0x2400.  The only thing that the current spec means is that 
 
  b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
 (Ye Olde Traditional memory-size function).
 
 Incorrect; see page 226.

Right.  Somehow I looked at that and didn't see it.

 Hopefully the other memory-size methods will always have
 priority.
  c. A20M# is always de-asserted at the processor [Ch. 3, 
 item SYS-0047]
  
  I bring these up because they may have some impact on SYSLINUX,
  LILO, etc., and the data structures that they use (like the
  memory_size item) and because some of these systems don't
  have a "real mode," so loaders can't reliably assume that
  they do (unless it's transparent to the loaders)...
  and because you know something about SYSLINUX etc.
  
 
 URRRK.  I get a feeling these specs are either there to make 
 life extra difficult for programmers,
 because the people that design them are too
 stupid to tie their own shoes, or because they want nothing but M$
 factory-installed to work.
 
 A20M# always deasserted: this is all fine and good if we had 
 nothing else
 to worry about, but they really have managed to fuck up when 
 it comes to
 getting something to work *ACROSS THE BOARD*.  THEY DON'T 
 GIVE ME A WAY
 TO DETECT THE FACT THAT A20M# IS FIXED!  This is 
 particularly nasty
 when going back to real mode, since I don't have a way to 
 figure out that I can't turn A20M# back to its old state.  

I'm not sure about this, but I'm wondering if the
Fixed (as in Static) ACPI Description Table (FADT)
can indicate that the platform is a legacy-free system.

According to the ACPI 2.0 spec, FADT field "Boot Architecture
Flags", bit 0 (LEGACY_DEVICES) indicates whether there are
legacy devices (user-visible) on the system.  I'm not sure
that this is adequate/equivalent.  I'll continue to check into it.
Even if it is adequate/equiv, it's not pretty.

 I also really, really, *REALLY* hate them for killing serial 
 ports.  It's a Bad Idea[TM].

Got the Message.

 Worse, they define that port 92h, bit 1, is no longer 
 A20M#... but they
 don't forbid the system from using it for other things.

I don't quite see it that way.  Where do you see that?
Maybe it just needs to be more explicit.

Ch. 3 (SYS-0047) says that port 92h:bit 1 doesn't toggle/affect A20M#.
Appendix A says that port 92h is (still?) "System Control Port A"
(not defined here AFAIK).
(I haven't checked all of the other chapters/appendices.)

   -hpa
 -- 
 [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

-
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: USB problems with 2.4.0

[Dunlap, Randy]

What kind of USB host controller is it?
Maybe there are some issues with it.

Maybe 'lspci -vv'...

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
---

> From: Adam Huffman [mailto:[EMAIL PROTECTED]]
> 
> System is a KA7-100, sole USB peripheral is a Logitech MouseMan Wheel.
> 
> If I use the uhci driver, it doesn't initialise properly (there is a
> message along the lines of "something bad happened".  If I use the
> usb-uhci driver, I frequently get an oops if I move the mouse during
> bootup.
> 
> If anyone is interested I will try to obtain a decoded oops report.
> 
> I've had this problem for a while and have reported it here before, as
> well as to one of the USB maintainers, but with no result so far.
> 
> 
> Adam
> -

-
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: USB problems with 2.4.0

[Dunlap, Randy]

What kind of USB host controller is it?
Maybe there are some issues with it.

Maybe 'lspci -vv'...

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
---

 From: Adam Huffman [mailto:[EMAIL PROTECTED]]
 
 System is a KA7-100, sole USB peripheral is a Logitech MouseMan Wheel.
 
 If I use the uhci driver, it doesn't initialise properly (there is a
 message along the lines of "something bad happened".  If I use the
 usb-uhci driver, I frequently get an oops if I move the mouse during
 bootup.
 
 If anyone is interested I will try to obtain a decoded oops report.
 
 I've had this problem for a while and have reported it here before, as
 well as to one of the USB maintainers, but with no result so far.
 
 
 Adam
 -

-
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: USB broken in 2.4.0

[Dunlap, Randy]

This rings a small bell with me.
There was a change by Dan Streetman IIRC to limit
usbdevfs bulk transfers to PAGE_SIZE (4 KB for x86,
or 0x1000).  Anything larger than that returns
an error (-EINVAL).

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: antirez [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 05, 2001 6:40 PM
> To: antirez
> Cc: Greg KH; Heitzso; '[EMAIL PROTECTED]'; 
> 'Johannes Erdfelt'
> Subject: Re: USB broken in 2.4.0
> 
> 
> On Sat, Jan 06, 2001 at 12:04:29AM +0100, antirez wrote:
> > I'll do some test with the new 2.4 kernel to find if there 
> is a problem
> > in s10sh itself. A good test can be to try if the equivalent driver
> > of gphoto works without problems using the 2.4 kernel 
> (however it also
> > uses the libusb). The s10sh bug may be not necessarly 
> related to the USB
> > subsystem.
> 
> Ok, the problem is the same that I ecountered developing the file
> upload for the powershot USB driver performing a bulk write with
> a big data size, but this time it is present even reading.
> 
> s10sh reads 0x1400 bytes at once downloading jpges from the
> digicam, but the ioctl() that performs the bulk read fails with 2.4
> using this size. If I resize it (for example to 0x300) it 
> works without
> problems (with high performace penality, of course, 60% of slow-down).
> I don't know why. I checked at the time of the file upload the kernel
> code finding nothing.
> 
> Anyway with the old releases of the USB subsystem libusb failed to
> initialize the camera some time, now it seems fixed.
> 
> For the users: just edit usb.c and check the function USB_get_data(),
> substituting all the occurrence of 0x1400 to 0x300 as a work-around.
> 
> Please CC: me since I'm not subscribed to the list.
> 
> regards,
> antirez
> 
> -- 
> Salvatore Sanfilippo  |  
> <[EMAIL PROTECTED]>
> http://www.kyuzz.org/antirez  |  PGP: finger 
> [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/
> 

-
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: Adding devices to dc2xx.c

[Dunlap, Randy]

> Hello, and thank you to those who responded to my query about 
> adding my
> Agfa ePhoto to the USB mass storage device database. I had no success
> with this (the machine locked hard on connecting the device), 
> so I have decided to try it with the dc2xx driver.
> 
> I have added it to /usr/src/linux/drivers/usb/dc2xx.c as follows:
> ..
> { idVendor: 0x040a, idProduct: 0x0112 },  // Kodak DC-290
> { idVendor: 0xf003, idProduct: 0x6002 },  // HP 
> PhotoSmart C500
> { idVendor: 0x06bd, idProduct: 0x0403 },  // Agfa ePhoto CL18
> ..
> 
> However, after I recompile and reboot with the new boot 
> image, I receive the following:
> ..
> Jan  5 19:37:33 localhost kernel: usb.c: registered new driver dc2xx 
> ..
> Jan  5 19:37:33 localhost kernel: hub.c: USB new device 
> connect on bus1/2, assigned device number 2 
> Jan  5 19:37:33 localhost kernel: usb.c: USB device 2 (vend/prod
> 0x6bd/0x403) is not claimed by any active driver. 
> ..
> 
> Why is dc2xx not being associated with the camera? I note 
> that the vendor
> and product names of the camera omit the leading '0', but I have tried
> adding them to the driver file as both '0x06bd' and '0x6bd' and 
> neither works. I'm
> using 2.4.0-prerelease, in case that helps.
> 
> So, does this sound like a bug with the above driver, or is 
> there something that I've missed?

Either you don't have dc2xx compiled into the kernel, or
if it's a module, you don't have it loaded yet.  You should
load it manually or add hotplug support
and the proper support files for it.
See http://www.linux-usb.org/policy.html.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

-
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: Adding devices to dc2xx.c

[Dunlap, Randy]

 Hello, and thank you to those who responded to my query about 
 adding my
 Agfa ePhoto to the USB mass storage device database. I had no success
 with this (the machine locked hard on connecting the device), 
 so I have decided to try it with the dc2xx driver.
 
 I have added it to /usr/src/linux/drivers/usb/dc2xx.c as follows:
 ..
 { idVendor: 0x040a, idProduct: 0x0112 },  // Kodak DC-290
 { idVendor: 0xf003, idProduct: 0x6002 },  // HP 
 PhotoSmart C500
 { idVendor: 0x06bd, idProduct: 0x0403 },  // Agfa ePhoto CL18
 ..
 
 However, after I recompile and reboot with the new boot 
 image, I receive the following:
 ..
 Jan  5 19:37:33 localhost kernel: usb.c: registered new driver dc2xx 
 ..
 Jan  5 19:37:33 localhost kernel: hub.c: USB new device 
 connect on bus1/2, assigned device number 2 
 Jan  5 19:37:33 localhost kernel: usb.c: USB device 2 (vend/prod
 0x6bd/0x403) is not claimed by any active driver. 
 ..
 
 Why is dc2xx not being associated with the camera? I note 
 that the vendor
 and product names of the camera omit the leading '0', but I have tried
 adding them to the driver file as both '0x06bd' and '0x6bd' and 
 neither works. I'm
 using 2.4.0-prerelease, in case that helps.
 
 So, does this sound like a bug with the above driver, or is 
 there something that I've missed?

Either you don't have dc2xx compiled into the kernel, or
if it's a module, you don't have it loaded yet.  You should
load it manually or add hotplug support
and the proper support files for it.
See http://www.linux-usb.org/policy.html.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

-
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: USB broken in 2.4.0

[Dunlap, Randy]

This rings a small bell with me.
There was a change by Dan Streetman IIRC to limit
usbdevfs bulk transfers to PAGE_SIZE (4 KB for x86,
or 0x1000).  Anything larger than that returns
an error (-EINVAL).

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

 -Original Message-
 From: antirez [mailto:[EMAIL PROTECTED]]
 Sent: Friday, January 05, 2001 6:40 PM
 To: antirez
 Cc: Greg KH; Heitzso; '[EMAIL PROTECTED]'; 
 'Johannes Erdfelt'
 Subject: Re: USB broken in 2.4.0
 
 
 On Sat, Jan 06, 2001 at 12:04:29AM +0100, antirez wrote:
  I'll do some test with the new 2.4 kernel to find if there 
 is a problem
  in s10sh itself. A good test can be to try if the equivalent driver
  of gphoto works without problems using the 2.4 kernel 
 (however it also
  uses the libusb). The s10sh bug may be not necessarly 
 related to the USB
  subsystem.
 
 Ok, the problem is the same that I ecountered developing the file
 upload for the powershot USB driver performing a bulk write with
 a big data size, but this time it is present even reading.
 
 s10sh reads 0x1400 bytes at once downloading jpges from the
 digicam, but the ioctl() that performs the bulk read fails with 2.4
 using this size. If I resize it (for example to 0x300) it 
 works without
 problems (with high performace penality, of course, 60% of slow-down).
 I don't know why. I checked at the time of the file upload the kernel
 code finding nothing.
 
 Anyway with the old releases of the USB subsystem libusb failed to
 initialize the camera some time, now it seems fixed.
 
 For the users: just edit usb.c and check the function USB_get_data(),
 substituting all the occurrence of 0x1400 to 0x300 as a work-around.
 
 Please CC: me since I'm not subscribed to the list.
 
 regards,
 antirez
 
 -- 
 Salvatore Sanfilippo  |  
 [EMAIL PROTECTED]
 http://www.kyuzz.org/antirez  |  PGP: finger 
 [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/
 

-
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: usb dc2xx quirk

[Dunlap, Randy]

> From: David Brownell [mailto:[EMAIL PROTECTED]]
> 
> If this makes it go away, then by all means apply this patch;
> though I don't quite see what the failure mode would be.

Josh didn't have HOTPLUG defined and he has
confirmed to me that this patch fixes the oops.
I'll forward it again.

> The proximate cause of that Oops looked to be in one of the
> UHCI drivers, but of course it's also possible that it was
> triggered by driver misbehavior.

You didn't look hard enough.  8;)
hub_thread got a disconnect event, called usb_disconnect,
which tried to call driver->disconnect, which wasn't there
due to using __devexit without CONFIG_HOTPLUG defined.

> Have we identified anything that actually does anything with
> code labeled __dev{in,ex}it (or data), beyond putting it into
> a different section?  If so, what's it doing?

That's a great question.  I'd like to know the answer also.
Then we can see what the correct fixes should be.
This patch could just be a short-lived 2.4.0-prerel
fix-the-oops patch.

> I just tried plug/unplug of a dc-240, albeit on a kernel
> with HOTPLUG defined (and using OHCI) and it worked without
> any Oops.

Yes, HOTPLUG (and #define of __devexit) is the key.

~Randy


> - Dave
> 
> 
> - Original Message -
> From: Randy Dunlap <[EMAIL PROTECTED]>
> To: josh <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; l-u-d
> <[EMAIL PROTECTED]>
> Sent: Wednesday, January 03, 2001 11:23 AM
> Subject: Re: usb dc2xx quirk
> 
> 
> > Hi,
> >
> > Looks like dc2xx.c shouldn't use __devinit/__devexit
> > [patch attached]
> > or you should enable CONFIG_HOTPLUG under General Setup.
> >
> > David?
> >
> > The ov511 (usb) driver is the only other USB device driver
> > that uses __devinit/__devexit.
> >
> > ~Randy
> >
> > josh wrote:
> > >
> > > Kernel Version: 2.4.0-test11 - 2.4.0-prerelease
> > > Platform: ix86 (PIII)
> > > Problem Hardware: Kodac DC280, firmware 1.01
> > >
> > > Ever since test10 or after, removing my dc280 from the usb
> > > bus causes khubd to crash.  I have tried both UHCI drivers
> > > and they produce the same effect.
> > >
> > > dmesg, syslog, messages, and .config can be found at:
> > > http://mammoth.org/~skulcap/usb-problem
> > >
> > > I have looked throug the archives and havent found anything
> > > like this, so I'm sorry if it has been covered already.
> > >
> > > Thanks in advance!
> > --
> > ___
> > |randy.dunlap_at_intel.com503-677-5408|
> > |NOTE: Any views presented here are mine alone|
> > |& may not represent the views of my employer.|
> > ---
> 
> 
> --
> --
> 
> 
> > --- linux/drivers/usb/dc2xx.c.org Sun Nov 12 20:40:42 2000
> > +++ linux/drivers/usb/dc2xx.c Wed Jan  3 11:15:11 2001
> > @@ -353,7 +353,7 @@
> >
> >
> >
> > -static void * __devinit
> > +static void *
> >  camera_probe (struct usb_device *dev, unsigned int ifnum, 
> const struct usb_device_id
> *camera_info)
> >  {
> >   int i;
> > @@ -451,7 +451,7 @@
> >   return camera;
> >  }
> >
> > -static void __devexit camera_disconnect(struct usb_device 
> *dev, void *ptr)
> > +static void camera_disconnect(struct usb_device *dev, void *ptr)
> >  {
> >   struct camera_state *camera = (struct camera_state *) ptr;
> >   int subminor = camera->subminor;

-
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: usb dc2xx quirk

[Dunlap, Randy]

 From: David Brownell [mailto:[EMAIL PROTECTED]]
 
 If this makes it go away, then by all means apply this patch;
 though I don't quite see what the failure mode would be.

Josh didn't have HOTPLUG defined and he has
confirmed to me that this patch fixes the oops.
I'll forward it again.

 The proximate cause of that Oops looked to be in one of the
 UHCI drivers, but of course it's also possible that it was
 triggered by driver misbehavior.

You didn't look hard enough.  8;)
hub_thread got a disconnect event, called usb_disconnect,
which tried to call driver-disconnect, which wasn't there
due to using __devexit without CONFIG_HOTPLUG defined.

 Have we identified anything that actually does anything with
 code labeled __dev{in,ex}it (or data), beyond putting it into
 a different section?  If so, what's it doing?

That's a great question.  I'd like to know the answer also.
Then we can see what the correct fixes should be.
This patch could just be a short-lived 2.4.0-prerel
fix-the-oops patch.

 I just tried plug/unplug of a dc-240, albeit on a kernel
 with HOTPLUG defined (and using OHCI) and it worked without
 any Oops.

Yes, HOTPLUG (and #define of __devexit) is the key.

~Randy


 - Dave
 
 
 - Original Message -
 From: Randy Dunlap [EMAIL PROTECTED]
 To: josh [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; l-u-d
 [EMAIL PROTECTED]
 Sent: Wednesday, January 03, 2001 11:23 AM
 Subject: Re: usb dc2xx quirk
 
 
  Hi,
 
  Looks like dc2xx.c shouldn't use __devinit/__devexit
  [patch attached]
  or you should enable CONFIG_HOTPLUG under General Setup.
 
  David?
 
  The ov511 (usb) driver is the only other USB device driver
  that uses __devinit/__devexit.
 
  ~Randy
 
  josh wrote:
  
   Kernel Version: 2.4.0-test11 - 2.4.0-prerelease
   Platform: ix86 (PIII)
   Problem Hardware: Kodac DC280, firmware 1.01
  
   Ever since test10 or after, removing my dc280 from the usb
   bus causes khubd to crash.  I have tried both UHCI drivers
   and they produce the same effect.
  
   dmesg, syslog, messages, and .config can be found at:
   http://mammoth.org/~skulcap/usb-problem
  
   I have looked throug the archives and havent found anything
   like this, so I'm sorry if it has been covered already.
  
   Thanks in advance!
  --
  ___
  |randy.dunlap_at_intel.com503-677-5408|
  |NOTE: Any views presented here are mine alone|
  | may not represent the views of my employer.|
  ---
 
 
 --
 --
 
 
  --- linux/drivers/usb/dc2xx.c.org Sun Nov 12 20:40:42 2000
  +++ linux/drivers/usb/dc2xx.c Wed Jan  3 11:15:11 2001
  @@ -353,7 +353,7 @@
 
 
 
  -static void * __devinit
  +static void *
   camera_probe (struct usb_device *dev, unsigned int ifnum, 
 const struct usb_device_id
 *camera_info)
   {
int i;
  @@ -451,7 +451,7 @@
return camera;
   }
 
  -static void __devexit camera_disconnect(struct usb_device 
 *dev, void *ptr)
  +static void camera_disconnect(struct usb_device *dev, void *ptr)
   {
struct camera_state *camera = (struct camera_state *) ptr;
int subminor = camera-subminor;

-
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: recommended build environment

[Dunlap, Randy]

> From: Borislav Deianov [mailto:[EMAIL PROTECTED]]
> 
> In article <[EMAIL PROTECTED]> you wrote:
> >> > oWe tell vendors to build RPMv3 , glibc 2.1.x
> >> Curious HOW do you tell vendors??
> 
> > When they ask. More usefully Dan Quinlann and most vendors 
> put together a
> > recommended set of things to build with and use. It warns 
> about library
> > pitfalls, kernel changes and what packaging is supported. 
> It is far from
> > perfect and nothing like the LSB goals but its a start and 
> following it does
> > give you applications that with a bit of care run on everything.
> 
> Is that recommendation available online anywhere? What about RedHat's?
> If not, who do I email for a copy in each case?

The Quinlan et al recommendations are at
http://www.freestandards.org/ldps/ .

~Randy

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

RE: recommended build environment

[Dunlap, Randy]

 From: Borislav Deianov [mailto:[EMAIL PROTECTED]]
 
 In article [EMAIL PROTECTED] you wrote:
   oWe tell vendors to build RPMv3 , glibc 2.1.x
  Curious HOW do you tell vendors??
 
  When they ask. More usefully Dan Quinlann and most vendors 
 put together a
  recommended set of things to build with and use. It warns 
 about library
  pitfalls, kernel changes and what packaging is supported. 
 It is far from
  perfect and nothing like the LSB goals but its a start and 
 following it does
  give you applications that with a bit of care run on everything.
 
 Is that recommendation available online anywhere? What about RedHat's?
 If not, who do I email for a copy in each case?

The Quinlan et al recommendations are at
http://www.freestandards.org/ldps/ .

~Randy

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

RE: test12-pre6

[Dunlap, Randy]

> From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
> 
...
> Now, this is with a bog-standard PIIX irq router, so we 
> definitely know
> that we have the pirq table parsing right. I even have unofficial
> confirmation from intel engineers on this.
> 
> But I see something obviously wrong there: you have busmaster 
> disabled.
> 
> Looking into the UHCI controller code, I notice that neither 
> UHCI driver actually does the (required)
> 
>   pci_set_master(dev);
> 
> Please add that to just after a successful 
> "pci_enable_device(dev)", and I
> just bet your USB will start working.
> 
> Johannes, Georg, the above is a fairly embarrassing bug, and 
> is likely to
> explain a _lot_ of USB failures (the OHCI driver does do this, btw).
> 
>   Linus

Gawd, I'm embarrassed even if they aren't.
You probably just wiped out a significant portion of the
USB bug list.

Thanks,
~Randy

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

RE: test12-pre6

[Dunlap, Randy]

 From: Linus Torvalds [mailto:[EMAIL PROTECTED]]
 
...
 Now, this is with a bog-standard PIIX irq router, so we 
 definitely know
 that we have the pirq table parsing right. I even have unofficial
 confirmation from intel engineers on this.
 
 But I see something obviously wrong there: you have busmaster 
 disabled.
 
 Looking into the UHCI controller code, I notice that neither 
 UHCI driver actually does the (required)
 
   pci_set_master(dev);
 
 Please add that to just after a successful 
 "pci_enable_device(dev)", and I
 just bet your USB will start working.
 
 Johannes, Georg, the above is a fairly embarrassing bug, and 
 is likely to
 explain a _lot_ of USB failures (the OHCI driver does do this, btw).
 
   Linus

Gawd, I'm embarrassed even if they aren't.
You probably just wiped out a significant portion of the
USB bug list.

Thanks,
~Randy

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

RE: [bug] vfsmount->count accounting broken again?

[Dunlap, Randy]

> > Andries wrote Monday 4-dec-2000 about a umount patch
> > for this:
> 
> Randy, presumably you mean the userspace side, yes? I.e. not 
> the kernel
> bug I reported. I should have put a subject [two bugs] 
> instead of [bug].

Right.  Sorry I wasn't more clear about that.

~Randy

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

RE: [bug] vfsmount->count accounting broken again?

[Dunlap, Randy]

Andries wrote Monday 4-dec-2000 about a umount patch
for this:

Now that there was some discussion about umount,
I released a version of mount/umount that perhaps
has a slightly better behaviour. Since the change
was largish (and is untested), don't put it blindly
into your distribution.
Another change was one intended to make things behave
a bit better for Japanese (with variable width characters).
Since I changed the patch a bit, it is quite possible
I broke things both for Japanese and English.

Andries - [EMAIL PROTECTED]

ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/
-

I haven't tried it yet.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: Tigran Aivazian [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 05, 2000 1:07 PM
> To: [EMAIL PROTECTED]
> Subject: [bug] vfsmount->count accounting broken again?
> 
> 
> Hi,
> 
> Imagine two ext2 filesystems
> 
> /dev/hda1 mounted rw on /boot
> /dev/hda3 mounted rw on /usr/src
> 
> now mount /dev/hda3 also on /boot
> 
> mount -t ext2 /dev/hda3 /boot
> 
> this succeeds, which is expected. Now umount it.
> 
> umount /boot
> 
> this also succeeds, which is expected. Now do df(1) and notice that
> /etc/mtab is corrupted and no longer shows the old /boot 
> filesystem even
> though we know (from /proc/mounts) that it is mounted. This 
> is a bug but a
> userspace one (should mail Andries later, probably 
> util-linux). Now, the
> interesting bit, i.e. the kernel bug:
> 
> umount /boot
> 
> this fails with EBUSY. So, I think the reference count has gone wrong
> somewhere -- I will put debugging code in do_umount() and see, but
> everyone is welcome to fix it before I do so...
> 
> Regards,
> Tigran
> 
> -

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

RE: [bug] vfsmount-count accounting broken again?

[Dunlap, Randy]

Andries wrote Monday 4-dec-2000 about a umount patch
for this:

Now that there was some discussion about umount,
I released a version of mount/umount that perhaps
has a slightly better behaviour. Since the change
was largish (and is untested), don't put it blindly
into your distribution.
Another change was one intended to make things behave
a bit better for Japanese (with variable width characters).
Since I changed the patch a bit, it is quite possible
I broke things both for Japanese and English.

Andries - [EMAIL PROTECTED]

ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/
-

I haven't tried it yet.

~Randy
___
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

 -Original Message-
 From: Tigran Aivazian [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, December 05, 2000 1:07 PM
 To: [EMAIL PROTECTED]
 Subject: [bug] vfsmount-count accounting broken again?
 
 
 Hi,
 
 Imagine two ext2 filesystems
 
 /dev/hda1 mounted rw on /boot
 /dev/hda3 mounted rw on /usr/src
 
 now mount /dev/hda3 also on /boot
 
 mount -t ext2 /dev/hda3 /boot
 
 this succeeds, which is expected. Now umount it.
 
 umount /boot
 
 this also succeeds, which is expected. Now do df(1) and notice that
 /etc/mtab is corrupted and no longer shows the old /boot 
 filesystem even
 though we know (from /proc/mounts) that it is mounted. This 
 is a bug but a
 userspace one (should mail Andries later, probably 
 util-linux). Now, the
 interesting bit, i.e. the kernel bug:
 
 umount /boot
 
 this fails with EBUSY. So, I think the reference count has gone wrong
 somewhere -- I will put debugging code in do_umount() and see, but
 everyone is welcome to fix it before I do so...
 
 Regards,
 Tigran
 
 -

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

RE: [bug] vfsmount-count accounting broken again?

[Dunlap, Randy]

  Andries wrote Monday 4-dec-2000 about a umount patch
  for this:
 
 Randy, presumably you mean the userspace side, yes? I.e. not 
 the kernel
 bug I reported. I should have put a subject [two bugs] 
 instead of [bug].

Right.  Sorry I wasn't more clear about that.

~Randy

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

RE: Nightly usb oops

[Dunlap, Randy]

Hi,

What kernel (test10)?
>  -m /boot/System.map-2.4.0-test10 (specified)

What compiler/version?

Please post a list of your USB devices from
/proc/bus/usb/devices .

Are you inserting or unplugging a USB device when this happens?
If not, are you doing anything with USB when this happens?

Thanks,
~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> -Original Message-
> From: J. Nick Koston [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 04, 2000 7:13 AM
> To: [EMAIL PROTECTED]
> Subject: Nightly usb oops
> 
> 
> My machine crashes almost every night with this oops.  I've finally
> managed to catch it before it was totally gone.
> 
> 
> ksymoops 2.3.4 on i686 2.4.0-test10.  Options used
>  -V (default)
>  -k /proc/ksyms (default)
>  -l /proc/modules (default)
>  -o /lib/modules/2.4.0-test10 (specified)
>  -m /boot/System.map-2.4.0-test10 (specified)
> 
> Warning (compare_maps): snd symbol pm_register not found in 
> /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
> /lib/modules/2.4.0-test10/misc/snd.o entry
> Warning (compare_maps): snd symbol pm_send not found in 
> /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
> /lib/modules/2.4.0-test10/misc/snd.o entry
> Warning (compare_maps): snd symbol pm_unregister not found in 
> /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
> /lib/modules/2.4.0-test10/misc/snd.o entry
>   0fef3340 e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 
> EndPt=0 Dev=1b, PID=2d(SETUP) (buf=0bd41580)
... (many STALL/CRC/Timeouts for Dev=1b, 22, 25) ...
> Unable to handle kernel NULL pointer dereference at virtual 
> address 0014
> c01faed6
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010282
> eax: 0008   ebx: cbd41385   ecx: cbd41380   edx: 0008
> esi:    edi: cfe12400   ebp: 0001   esp: c14fdf0c
> ds: 0018   es: 0018   ss: 0018
> Process khubd (pid: 7, stackpage=c14fd000)
> Stack: cbd41385  cfe12400 0001 0008  
> 0009  
>0001   c01fb1f3 cfe12400  
> cfe12400 c5985802 
>cfe12400  cbd41380 cbd41380 c01fb7f1 cfe12400 
> 0001  
> Call Trace: [] [] [] 
> [] [] [] [] 
>[] [] 
> Code: 8b 42 0c c7 44 24 24 00 00 00 00 0f b6 72 04 39 74 24 24 0f 
> 
> >>EIP; c01faed6<=
> Trace; c01fb1f3 
> Trace; c01fb7f1 
> Trace; c01fcc60 
> Trace; c01fce32 
> Trace; c0293580 
> Trace; c0293647 
> Trace; c01fcfa5 
> Trace; c0105000 
> Trace; c0108c03 
> Code;  c01faed6 
>  <_EIP>:
> Code;  c01faed6<=
>0:   8b 42 0c  mov0xc(%edx),%eax   <=
> Code;  c01faed9 
>3:   c7 44 24 24 00 00 00  movl   $0x0,0x24(%esp,1)
> Code;  c01faee0 
>a:   00 
> Code;  c01faee1 
>b:   0f b6 72 04   movzbl 0x4(%edx),%esi
> Code;  c01faee5 
>f:   39 74 24 24   cmp%esi,0x24(%esp,1)
> Code;  c01faee9 
>   13:   0f 00 00  sldt   (%eax)
> 
> Unable to handle kernel NULL pointer dereference at virtual 
> address 0008
> c013ed99
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> EFLAGS: 00010246
> eax: 0008   ebx:    ecx: 000c   edx: 0002
> esi:    edi:    ebp: 0008   esp: c36f3f08
> ds: 0018   es: 0018   ss: 0018
> Process initlog (pid: 532, stackpage=c36f3000)
> Stack: c36f2000  0002  000c 000e 
> c013eec3 0002 
>0008 c36f3f48 c36f3f4c c36f2000 0002 0002 
>  c36f2000 
>  c013f133 0002  0002 
> cbd41140 c36f3fb8 
> Call Trace: [] [] [] [] 
> Code: 8b 45 00 85 c0 7c 59 e8 6b 1f ff ff 89 c6 bb 20 00 00 00 85 
> 
> >>EIP; c013ed99<=
> Trace; c013eec3 
> Trace; c013f133 
> Trace; c01203ed 
> Trace; c010a637 
> Code;  c013ed99 
>  <_EIP>:
> Code;  c013ed99<=
>0:   8b 45 00  mov0x0(%ebp),%eax   <=
> Code;  c013ed9c 
>3:   85 c0 test   %eax,%eax
> Code;  c013ed9e 
>5:   7c 59 jl 60 <_EIP+0x60> 
> c013edf9 
> Code;  c013eda0 
>7:   e8 6b 1f ff ffcall   1f77 
> <_EIP+0x1f77> c0130d10 
> Code;  c013eda5 
>c:   89 c6 mov%eax,%esi
> Code;  c013eda7 
>e:   bb 20 00 00 00mov$0x20,%ebx
> Code;  c013edac 
>   13:   85 00 test   %eax,(%eax)
> 
> Unable to handle kernel NULL pointer dereference at virtual 
> address 0040
> c013ed99
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> EFLAGS: 00210246
> eax: 0040   ebx:    ecx: 0044   edx: 0006
> esi:    edi:    ebp: 0040   esp: c09a7f08
> ds: 0018   es: 

RE: Nightly usb oops

[Dunlap, Randy]

Hi,

What kernel (test10)?
  -m /boot/System.map-2.4.0-test10 (specified)

What compiler/version?

Please post a list of your USB devices from
/proc/bus/usb/devices .

Are you inserting or unplugging a USB device when this happens?
If not, are you doing anything with USB when this happens?

Thanks,
~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
| may not represent the views of my employer.|
---

 -Original Message-
 From: J. Nick Koston [mailto:[EMAIL PROTECTED]]
 Sent: Monday, December 04, 2000 7:13 AM
 To: [EMAIL PROTECTED]
 Subject: Nightly usb oops
 
 
 My machine crashes almost every night with this oops.  I've finally
 managed to catch it before it was totally gone.
 
 
 ksymoops 2.3.4 on i686 2.4.0-test10.  Options used
  -V (default)
  -k /proc/ksyms (default)
  -l /proc/modules (default)
  -o /lib/modules/2.4.0-test10 (specified)
  -m /boot/System.map-2.4.0-test10 (specified)
 
 Warning (compare_maps): snd symbol pm_register not found in 
 /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
 /lib/modules/2.4.0-test10/misc/snd.o entry
 Warning (compare_maps): snd symbol pm_send not found in 
 /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
 /lib/modules/2.4.0-test10/misc/snd.o entry
 Warning (compare_maps): snd symbol pm_unregister not found in 
 /lib/modules/2.4.0-test10/misc/snd.o.  Ignoring 
 /lib/modules/2.4.0-test10/misc/snd.o entry
   0fef3340 e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 
 EndPt=0 Dev=1b, PID=2d(SETUP) (buf=0bd41580)
... (many STALL/CRC/Timeouts for Dev=1b, 22, 25) ...
 Unable to handle kernel NULL pointer dereference at virtual 
 address 0014
 c01faed6
 *pde = 
 Oops: 
 CPU:0
 EIP:0010:[c01faed6]
 Using defaults from ksymoops -t elf32-i386 -a i386
 EFLAGS: 00010282
 eax: 0008   ebx: cbd41385   ecx: cbd41380   edx: 0008
 esi:    edi: cfe12400   ebp: 0001   esp: c14fdf0c
 ds: 0018   es: 0018   ss: 0018
 Process khubd (pid: 7, stackpage=c14fd000)
 Stack: cbd41385  cfe12400 0001 0008  
 0009  
0001   c01fb1f3 cfe12400  
 cfe12400 c5985802 
cfe12400  cbd41380 cbd41380 c01fb7f1 cfe12400 
 0001  
 Call Trace: [c01fb1f3] [c01fb7f1] [c01fcc60] 
 [c01fce32] [c0293580] [c0293647] [c01fcfa5] 
[c0105000] [c0108c03] 
 Code: 8b 42 0c c7 44 24 24 00 00 00 00 0f b6 72 04 39 74 24 24 0f 
 
 EIP; c01faed6 usb_set_maxpacket+46/120   =
 Trace; c01fb1f3 usb_set_configuration+e3/f0
 Trace; c01fb7f1 usb_new_device+171/1d0
 Trace; c01fcc60 usb_hub_port_connect_change+270/300
 Trace; c01fce32 usb_hub_events+142/270
 Trace; c0293580 usb_bandwidth_option+1bf8/28ec
 Trace; c0293647 usb_bandwidth_option+1cbf/28ec
 Trace; c01fcfa5 usb_hub_thread+45/70
 Trace; c0105000 empty_bad_page+0/1000
 Trace; c0108c03 kernel_thread+23/30
 Code;  c01faed6 usb_set_maxpacket+46/120
  _EIP:
 Code;  c01faed6 usb_set_maxpacket+46/120   =
0:   8b 42 0c  mov0xc(%edx),%eax   =
 Code;  c01faed9 usb_set_maxpacket+49/120
3:   c7 44 24 24 00 00 00  movl   $0x0,0x24(%esp,1)
 Code;  c01faee0 usb_set_maxpacket+50/120
a:   00 
 Code;  c01faee1 usb_set_maxpacket+51/120
b:   0f b6 72 04   movzbl 0x4(%edx),%esi
 Code;  c01faee5 usb_set_maxpacket+55/120
f:   39 74 24 24   cmp%esi,0x24(%esp,1)
 Code;  c01faee9 usb_set_maxpacket+59/120
   13:   0f 00 00  sldt   (%eax)
 
 Unable to handle kernel NULL pointer dereference at virtual 
 address 0008
 c013ed99
 *pde = 
 Oops: 
 CPU:0
 EIP:0010:[c013ed99]
 EFLAGS: 00010246
 eax: 0008   ebx:    ecx: 000c   edx: 0002
 esi:    edi:    ebp: 0008   esp: c36f3f08
 ds: 0018   es: 0018   ss: 0018
 Process initlog (pid: 532, stackpage=c36f3000)
 Stack: c36f2000  0002  000c 000e 
 c013eec3 0002 
0008 c36f3f48 c36f3f4c c36f2000 0002 0002 
  c36f2000 
  c013f133 0002  0002 
 cbd41140 c36f3fb8 
 Call Trace: [c013eec3] [c013f133] [c01203ed] [c010a637] 
 Code: 8b 45 00 85 c0 7c 59 e8 6b 1f ff ff 89 c6 bb 20 00 00 00 85 
 
 EIP; c013ed99 do_pollfd+29/b0   =
 Trace; c013eec3 do_poll+a3/e0
 Trace; c013f133 sys_poll+233/350
 Trace; c01203ed sys_nanosleep+10d/190
 Trace; c010a637 system_call+33/38
 Code;  c013ed99 do_pollfd+29/b0
  _EIP:
 Code;  c013ed99 do_pollfd+29/b0   =
0:   8b 45 00  mov0x0(%ebp),%eax   =
 Code;  c013ed9c do_pollfd+2c/b0
3:   85 c0 test   %eax,%eax
 Code;  c013ed9e do_pollfd+2e/b0
5:   7c 59 jl 60 _EIP+0x60 
 c013edf9 do_pollfd+89/b0
 Code;  c013eda0 do_pollfd+30/b0
7:   e8 6b 1f ff ffcall   

RE: usbdevfs mount 2x, umount 1x

[Dunlap, Randy]

> From: Jan-Benedict Glaw [mailto:[EMAIL PROTECTED]]
> 
> On Wed, Nov 29, 2000 at 04:47:27PM -0800, Randy Dunlap wrote:
> > 
> > Summary:  After I mount usbdevfs 2 times, and umount it
> > 1 time, the usbcore module use count prevents it from
> > being rmmod-ed.
> 
> > [root@dragon rdunlap]# lsmod
> > usbcore50656   2  [uhci]
> 
> > and 'mount' shows no usb or usbdevfs entries listed.
> 
> Are there usbdevfs entries in /proc/mount? Maybe 'umount' removes
> too many entries from /etc/mtab...

Yes, that's how it looks to me also, so maybe it's not a kernel
problem.  Thanks for the tip.

Here's more info, including the strace that Al Viro asked for.
I also made sure that I'm using mount & umount version 2.10o.
Please let me know if you need anything else.

~Randy


1.  Start with empty slate: no modules, no usb mounts:

[root@localhost rdunlap]# lsmod
Module  Size  Used by

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0

2.  insmod usbcore and mount 'usb':

[root@localhost rdunlap]# insmod usbcore
Using /lib/modules/2.4.0-test11/kernel/drivers/usb/usbcore.o

[root@localhost rdunlap]# cat /etc/fstab
/dev/hdc5 / ext2 defaults 1 1
/dev/hdc1 /boot ext2 defaults 1 2
none /dev/pts devpts mode=0620 0 0
/dev/hdc7 /home ext2 defaults 1 2
/dev/cdrom /mnt/cdrom auto user,noauto,nosuid,exec,nodev,ro 0 0
/dev/fd0 /mnt/floppy auto sync,user,noauto,nosuid,nodev 0 0
none /proc proc defaults 0 0
usb /proc/bus/usb usbdevfs defaults,user 0 0
/dev/hdc6 /usr ext2 defaults 1 2
/dev/hdc2 swap swap defaults 0 0

[root@localhost rdunlap]# mount usb

3.  This gives us:

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   1 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0

4.  A second mount (slightly different 'device' name = "usbfs") gives:

[root@localhost rdunlap]# mount -t usbdevfs usbfs /proc/bus/usb

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   2 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbdevfs (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0
usbfs /proc/bus/usb usbdevfs rw 0 0

5.  [root@localhost rdunlap]# strace -xv -o umount.st2 umount usb

gives (strace output at end):

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   1 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
< no usb here >>

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0 <-

6.  Trying to umount the remaining usb mount:

[root@localhost rdunlap]# umount usb
umount: usb: not found

[root@localhost rdunlap]# umount /proc/bus/usb

[root@localhost rdunlap]#  mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0

~~ strace of umount usb ~~

execve("/bin/umount", ["umount", "usb"], [/* 

RE: usbdevfs mount 2x, umount 1x

[Dunlap, Randy]

 From: Jan-Benedict Glaw [mailto:[EMAIL PROTECTED]]
 
 On Wed, Nov 29, 2000 at 04:47:27PM -0800, Randy Dunlap wrote:
  
  Summary:  After I mount usbdevfs 2 times, and umount it
  1 time, the usbcore module use count prevents it from
  being rmmod-ed.
 
  [root@dragon rdunlap]# lsmod
  usbcore50656   2  [uhci]
 
  and 'mount' shows no usb or usbdevfs entries listed.
 
 Are there usbdevfs entries in /proc/mount? Maybe 'umount' removes
 too many entries from /etc/mtab...

Yes, that's how it looks to me also, so maybe it's not a kernel
problem.  Thanks for the tip.

Here's more info, including the strace that Al Viro asked for.
I also made sure that I'm using mount  umount version 2.10o.
Please let me know if you need anything else.

~Randy


1.  Start with empty slate: no modules, no usb mounts:

[root@localhost rdunlap]# lsmod
Module  Size  Used by

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0

2.  insmod usbcore and mount 'usb':

[root@localhost rdunlap]# insmod usbcore
Using /lib/modules/2.4.0-test11/kernel/drivers/usb/usbcore.o

[root@localhost rdunlap]# cat /etc/fstab
/dev/hdc5 / ext2 defaults 1 1
/dev/hdc1 /boot ext2 defaults 1 2
none /dev/pts devpts mode=0620 0 0
/dev/hdc7 /home ext2 defaults 1 2
/dev/cdrom /mnt/cdrom auto user,noauto,nosuid,exec,nodev,ro 0 0
/dev/fd0 /mnt/floppy auto sync,user,noauto,nosuid,nodev 0 0
none /proc proc defaults 0 0
usb /proc/bus/usb usbdevfs defaults,user 0 0
/dev/hdc6 /usr ext2 defaults 1 2
/dev/hdc2 swap swap defaults 0 0

[root@localhost rdunlap]# mount usb

3.  This gives us:

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   1 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0

4.  A second mount (slightly different 'device' name = "usbfs") gives:

[root@localhost rdunlap]# mount -t usbdevfs usbfs /proc/bus/usb

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   2 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbdevfs (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0
usbfs /proc/bus/usb usbdevfs rw 0 0

5.  [root@localhost rdunlap]# strace -xv -o umount.st2 umount usb

gives (strace output at end):

[root@localhost rdunlap]# lsmod
Module  Size  Used by
usbcore52224   1 

[root@localhost rdunlap]# mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)
 no usb here 

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0
usb /proc/bus/usb usbdevfs rw,noexec,nosuid,nodev 0 0 -

6.  Trying to umount the remaining usb mount:

[root@localhost rdunlap]# umount usb
umount: usb: not found

[root@localhost rdunlap]# umount /proc/bus/usb

[root@localhost rdunlap]#  mount
/dev/hdc5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hdc1 on /boot type ext2 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hdc7 on /home type ext2 (rw)
/dev/hdc6 on /usr type ext2 (rw)

[root@localhost rdunlap]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/hdc1 /boot ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/hdc7 /home ext2 rw 0 0
/dev/hdc6 /usr ext2 rw 0 0

~~ strace of umount usb ~~

execve("/bin/umount", ["umount", "usb"], [/* 40 vars */]) = 0
brk(0)  = 

RE: usbdevfs mount 2x, umount 1x

[Dunlap, Randy]

> > > So umount it twice.
> > I don't see a way to umount it twice or I would have done that.
> > Is there a way?
> 
> Erm... Say umount one more time? If _that_ doesn't work - we've got a
> bug, either in umount(2) or in umount(8). Strace would be welcome.

Or I'm using an old version of umount (from RH 5.2) ?
I'll check on that and the strace.

~Randy

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

RE: usbdevfs mount 2x, umount 1x

[Dunlap, Randy]

> From: Alexander Viro [mailto:[EMAIL PROTECTED]]
> 
> On Wed, 29 Nov 2000, Randy Dunlap wrote:
> 
> > [I reported this a couple of months back.  Got no
> > feedback on it.  If it's just a DDT (don't do that)
> > or a user error, please say so.]
> > 
> > Summary:  After I mount usbdevfs 2 times, and umount it
> > 1 time, the usbcore module use count prevents it from
> > being rmmod-ed.
> 
> So umount it twice.
I don't see a way to umount it twice or I would have done that.
Is there a way?

> And yes, it's "don't do it, then".
OK.

> Every mount() increments the use count.
Got that.

> Every umount() decrements it. You want it
> to become 0. Draw your conclusions...
Looks to me like umount unmounted it 2 times and decremented
the use count by 1.

I don't see a way for me to rmmod usbcore.  As it is,
I have to reboot the system (or just DDT).

Thanks,
~Randy

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