date:20100420

Re: Source Overview

2010-04-20 Thread Bret S. Lambert

On Mon, Apr 19, 2010 at 04:15:02PM +, Thordur Bjornsson wrote:
  And if you value your sanity, stay out of anything resembling filesystems.
 This is a lie.
 
 Hacking on filesystems, and the VFS layer in general is a very rewarding
 experince, just ask Bob.
 
 NFS for example, has been a source of joy for OpenBSD developers for
 years!

Yes, if by joy you mean anal hemmoraging.

 
  2) ?Is there something like an openbsd janitors project where newbies can
  start contributing small patches? similar to the Linux janitors project?
 
  Not at all. The philosophy behind not having one is that it's considered 
  dangerous
  to farm out work to the inexperienced (and this exact topic has been 
  brought up
  before, usually by people whining that we didn't make them feel special 
  enough
  by not having one).
 Also it leads to people doing KNF style diffs, just to do KNF style
 diffs. Noone
 learns anything. Most KNF style diffs you see coming from developers is due 
 to
 them having to read some code, and they cleaned up a little while doing so.
 
 While KNF is great, doing KNF just for the sake of doing KNF is hardly
 ever worth it
 IMHO.

Re: Source Overview

2010-04-20 Thread Bret S. Lambert

 Or, in short, we need to not deter people straight away, and accept that
 perhaps sometimes decent programmers start from ones that make lots
 of mistakes.
 
 Perhaps a ports TODO similar to the NetBSD ports TODO might help; it
 doesn't require quite the same level of kernel or userspace hacking and
 provides very visible feedback and thanks once completed.

But you're also missing a big point: if someone can't figure out what
needs to be fixed, or is incapable of mustering enough motivation to
do the work, then they're not as useful to us as someone who can do
one or the other (or hopefully both).

tedu@ once said that there's an entrance exam to get an account; this
happens to be part of it, IMO.

PS - put this back on tech@ where it was originally, misc@ has enough noise
without this going there as well

Re: Source Overview

2010-04-20 Thread Peter Kay (Syllopsium)


From: Bret S. Lambert blamb...@openbsd.org

Or, in short, we need to not deter people straight away, and accept that
perhaps sometimes decent programmers start from ones that make lots
of mistakes.

Perhaps a ports TODO similar to the NetBSD ports TODO might help; it
doesn't require quite the same level of kernel or userspace hacking and
provides very visible feedback and thanks once completed.


But you're also missing a big point: if someone can't figure out what
needs to be fixed, or is incapable of mustering enough motivation to
do the work, then they're not as useful to us as someone who can do
one or the other (or hopefully both).

tedu@ once said that there's an entrance exam to get an account; this
happens to be part of it, IMO.

Sure, and I understand that viewpoint. It's a valid one provided we want the
OpenBSD community to stay as it is.

I tend to think there's an in-between option. If I think back to some of my
earlier coding days, say on OS/2, and omit the coding I did as part of work,
most of it never saw the light of day. Some of it was just me playing around
with code and often I found other ways of achieving the aim that rendered 
the

code useless.

I never did (and probably never would at the time) get around to coding
anything serious, but I did port a number of apps - at the time it was 
pretty

easy.

Surely people can move on from the low hanging fruit of a port that needs
a ./configure  make install, to minor code or makefile changes, to specific
new functionality to from the scratch coding. Certainly, if at the time 
someone

with zero coding knowledge had asked for a port and it was trivial, I would
certainly have done it.

PK

usb attach lines; print vendor/product id

2010-04-20 Thread Stuart Henderson

after reading the N hundredth misc@ post with some USB device
where device/vendor IDs haven't been shown, it seems that printing
them in the device attach line might save some trouble.

any comments/suggestions?


Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.73
diff -u -p -r1.73 usb_subr.c
--- usb_subr.c  14 Jan 2009 21:02:57 -  1.73
+++ usb_subr.c  20 Apr 2010 13:08:53 -
@@ -1281,7 +1281,9 @@ usbd_print(void *aux, const char *pnp)
printf( interface %d, uaa-ifaceno);
 
if (!pnp)
-   printf( %s\n, devinfop);
+   printf( %s (0x%04x:0x%04x)\n, devinfop,
+   UGETW(uaa-device-ddesc.idVendor),
+   UGETW(uaa-device-ddesc.idProduct));
usbd_devinfo_free(devinfop);
return (UNCONF);
 }


OpenBSD 4.7-current (GENERIC.MP) #34: Tue Apr 20 14:03:40 BST 2010
st...@symphytum.spacehopper.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
RTC BIOS diagnostic error 80clock_battery
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
real mem  = 1597034496 (1523MB)
avail mem = 1538363392 (1467MB)
RTC BIOS diagnostic error 80clock_battery
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/06/08, SMBIOS rev. 2.4 @ 0xe8e70 (32 
entries)
bios0: vendor Acer version v0.3309 date 10/06/2008
bios0: Acer AOA150
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT HPET APIC MCFG ASF! SLIC BOOT
acpi0: wakeup devices P32_(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) ECHI(S3) 
EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) AZAL(S0) MODM(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (P32_)
acpiprt2 at acpi0: bus 1 (EXP1)
acpiprt3 at acpi0: bus 2 (EXP2)
acpiprt4 at acpi0: bus 3 (EXP3)
acpiprt5 at acpi0: bus 4 (EXP4)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpibtn2 at acpi0: SLPB
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpivideo0 at acpi0: OVGA
acpivout0 at acpivideo0: CRT1
acpivout1 at acpivideo0: DTV1
acpivout2 at acpivideo0: DFP1
acpivout3 at acpivideo0: LCD_
acpivout4 at acpivideo0: DTV2
acpivout5 at acpivideo0: DFP2
bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000
cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1333, 1066, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945GME Host rev 0x03
vga1 at pci0 dev 2 function 0 Intel 82945GME Video rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0x6000, size 0x1000
inteldrm0 at vga1: apic 4 int 16 (irq 11)
drm0 at inteldrm0
Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: apic 4 int 
16 (irq 11)
azalia0: codecs: Realtek ALC268
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4 int 16 
(irq 255)
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4 int 17 
(irq 255)
pci2 at ppb1 bus 2
re0 at pci2 dev 0 function 0 Realtek 8101E rev 0x02: RTL8102EL (0x2480), apic 
4 int 17 (irq 11), address 00:23:8b:43:96:e6
rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 4 int 18 
(irq 255)
pci3 at ppb2 bus 3
ral0 at pci3 dev 0 function 0 Ralink RT2790 rev 0x00: apic 4 int 18 (irq 11), 
address 00:22:43:14:9b:35
ral0: MAC/BBP RT2872 (rev 0x0200), RF RT2720 (MIMO 1T2R)
ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 4 int 19 
(irq 255)
pci4 at ppb3 bus 4
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 4 int 16 
(irq 11)
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 4 int 17 
(irq 11)
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 4 int 18 
(irq 11)
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 4 int 19 
(irq 11)
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 4 int 16 
(irq 11)
usb0 at ehci0: USB

Re: usb attach lines; print vendor/product id

2010-04-20 Thread Stuart Henderson

On 2010/04/20 14:23, Stuart Henderson wrote:
 after reading the N hundredth misc@ post with some USB device
 where device/vendor IDs haven't been shown, it seems that printing
 them in the device attach line might save some trouble.
 
 any comments/suggestions?

note that with PCI, we print canonical strings from pcidevs which
we can map back to the IDs, or if we don't know the device, we print
IDs, so we can identify the device fairly well from the output.
with USB, we can't do this, because the strings come from the
device itself.


 
 Index: usb_subr.c
 ===
 RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
 retrieving revision 1.73
 diff -u -p -r1.73 usb_subr.c
 --- usb_subr.c14 Jan 2009 21:02:57 -  1.73
 +++ usb_subr.c20 Apr 2010 13:08:53 -
 @@ -1281,7 +1281,9 @@ usbd_print(void *aux, const char *pnp)
   printf( interface %d, uaa-ifaceno);
  
   if (!pnp)
 - printf( %s\n, devinfop);
 + printf( %s (0x%04x:0x%04x)\n, devinfop,
 + UGETW(uaa-device-ddesc.idVendor),
 + UGETW(uaa-device-ddesc.idProduct));
   usbd_devinfo_free(devinfop);
   return (UNCONF);
  }
 
 
 OpenBSD 4.7-current (GENERIC.MP) #34: Tue Apr 20 14:03:40 BST 2010
 st...@symphytum.spacehopper.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 RTC BIOS diagnostic error 80clock_battery
 cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz
 cpu0: 
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
 real mem  = 1597034496 (1523MB)
 avail mem = 1538363392 (1467MB)
 RTC BIOS diagnostic error 80clock_battery
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 10/06/08, SMBIOS rev. 2.4 @ 0xe8e70 (32 
 entries)
 bios0: vendor Acer version v0.3309 date 10/06/2008
 bios0: Acer AOA150
 acpi0 at bios0: rev 2
 acpi0: tables DSDT FACP SSDT HPET APIC MCFG ASF! SLIC BOOT
 acpi0: wakeup devices P32_(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) ECHI(S3) 
 EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) AZAL(S0) MODM(S0)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpihpet0 at acpi0: 14318179 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: apic clock running at 133MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz
 cpu1: 
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 0, remapped to apid 4
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 5 (P32_)
 acpiprt2 at acpi0: bus 1 (EXP1)
 acpiprt3 at acpi0: bus 2 (EXP2)
 acpiprt4 at acpi0: bus 3 (EXP3)
 acpiprt5 at acpi0: bus 4 (EXP4)
 acpiec0 at acpi0
 acpicpu0 at acpi0: C3, C2, C1, PSS
 acpicpu1 at acpi0: C3, C2, C1, PSS
 acpibtn0 at acpi0: PWRB
 acpibtn1 at acpi0: LID0
 acpibtn2 at acpi0: SLPB
 acpibat0 at acpi0: BAT1 not present
 acpiac0 at acpi0: AC unit offline
 acpivideo0 at acpi0: OVGA
 acpivout0 at acpivideo0: CRT1
 acpivout1 at acpivideo0: DTV1
 acpivout2 at acpivideo0: DFP1
 acpivout3 at acpivideo0: LCD_
 acpivout4 at acpivideo0: DTV2
 acpivout5 at acpivideo0: DFP2
 bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000
 cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1333, 1066, 800 MHz
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 pchb0 at pci0 dev 0 function 0 Intel 82945GME Host rev 0x03
 vga1 at pci0 dev 2 function 0 Intel 82945GME Video rev 0x03
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 intagp0 at vga1
 agp0 at intagp0: aperture at 0x6000, size 0x1000
 inteldrm0 at vga1: apic 4 int 16 (irq 11)
 drm0 at inteldrm0
 Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured
 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: apic 4 
 int 16 (irq 11)
 azalia0: codecs: Realtek ALC268
 audio0 at azalia0
 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4 int 16 
 (irq 255)
 pci1 at ppb0 bus 1
 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4 int 17 
 (irq 255)
 pci2 at ppb1 bus 2
 re0 at pci2 dev 0 function 0 Realtek 8101E rev 0x02: RTL8102EL (0x2480), 
 apic 4 int 17 (irq 11), address 00:23:8b:43:96:e6
 rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
 ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 4 int 18 
 (irq 255)
 pci3 at ppb2 bus 3
 ral0 at pci3 dev 0 function 0 Ralink RT2790 rev 0x00: apic 4 int 18 (irq 
 11), address 00:22:43:14:9b:35
 ral0: MAC/BBP RT2872 (rev 0x0200), RF RT2720 (MIMO 1T2R)
 ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 4 int 19 
 (irq 255)
 pci4 at ppb3 bus 4
 uhci0 at

Re: usb attach lines; print vendor/product id

2010-04-20 Thread Mark Kettenis

 Date: Tue, 20 Apr 2010 14:23:46 +0100
 From: Stuart Henderson s...@spacehopper.org

 after reading the N hundredth misc@ post with some USB device
 where device/vendor IDs haven't been shown, it seems that printing
 them in the device attach line might save some trouble.

 any comments/suggestions?

I think this makes dmesg uglier.  The information is easily available
from usbdevs(8).

Perhaps the uglification is acceptable for devices that attach as
ugen(4) though.

Re: Source Overview

2010-04-20 Thread Bret S. Lambert

 Surely people can move on from the low hanging fruit of a port that needs
 a ./configure  make install, to minor code or makefile changes, to specific
 new functionality to from the scratch coding.

Not to sound like a dick, but this illustrates some of what I'm saying:

If I hold up one corner and a student cannot come back to me
with the other three, I do not go on with the lesson.

- Confucius, the Analects

Re: usb attach lines; print vendor/product id

2010-04-20 Thread Jens Teglhus Møller

I like this, but i was also too stupid to run usbdevs to find
vendor/product id for my device (and i'm too embarrassed to tell how
actually found it).

/jtm

On Tue, April 20, 2010 15:23, Stuart Henderson wrote:
 after reading the N hundredth misc@ post with some USB device
 where device/vendor IDs haven't been shown, it seems that printing
 them in the device attach line might save some trouble.

 any comments/suggestions?


 Index: usb_subr.c
 ===
 RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
 retrieving revision 1.73
 diff -u -p -r1.73 usb_subr.c
 --- usb_subr.c14 Jan 2009 21:02:57 -  1.73
 +++ usb_subr.c20 Apr 2010 13:08:53 -
 @@ -1281,7 +1281,9 @@ usbd_print(void *aux, const char *pnp)
   printf( interface %d, uaa-ifaceno);

   if (!pnp)
 - printf( %s\n, devinfop);
 + printf( %s (0x%04x:0x%04x)\n, devinfop,
 + UGETW(uaa-device-ddesc.idVendor),
 + UGETW(uaa-device-ddesc.idProduct));
   usbd_devinfo_free(devinfop);
   return (UNCONF);
  }


 OpenBSD 4.7-current (GENERIC.MP) #34: Tue Apr 20 14:03:40 BST 2010
 st...@symphytum.spacehopper.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 RTC BIOS diagnostic error 80clock_battery
 cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60
 GHz
 cpu0:
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
 real mem  = 1597034496 (1523MB)
 avail mem = 1538363392 (1467MB)
 RTC BIOS diagnostic error 80clock_battery
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 10/06/08, SMBIOS rev. 2.4 @ 0xe8e70
 (32 entries)
 bios0: vendor Acer version v0.3309 date 10/06/2008
 bios0: Acer AOA150
 acpi0 at bios0: rev 2
 acpi0: tables DSDT FACP SSDT HPET APIC MCFG ASF! SLIC BOOT
 acpi0: wakeup devices P32_(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3)
 ECHI(S3) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) AZAL(S0) MODM(S0)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpihpet0 at acpi0: 14318179 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: apic clock running at 133MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60
 GHz
 cpu1:
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 0, remapped to apid 4
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 5 (P32_)
 acpiprt2 at acpi0: bus 1 (EXP1)
 acpiprt3 at acpi0: bus 2 (EXP2)
 acpiprt4 at acpi0: bus 3 (EXP3)
 acpiprt5 at acpi0: bus 4 (EXP4)
 acpiec0 at acpi0
 acpicpu0 at acpi0: C3, C2, C1, PSS
 acpicpu1 at acpi0: C3, C2, C1, PSS
 acpibtn0 at acpi0: PWRB
 acpibtn1 at acpi0: LID0
 acpibtn2 at acpi0: SLPB
 acpibat0 at acpi0: BAT1 not present
 acpiac0 at acpi0: AC unit offline
 acpivideo0 at acpi0: OVGA
 acpivout0 at acpivideo0: CRT1
 acpivout1 at acpivideo0: DTV1
 acpivout2 at acpivideo0: DFP1
 acpivout3 at acpivideo0: LCD_
 acpivout4 at acpivideo0: DTV2
 acpivout5 at acpivideo0: DFP2
 bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000
 cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1333, 1066, 800 MHz
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 pchb0 at pci0 dev 0 function 0 Intel 82945GME Host rev 0x03
 vga1 at pci0 dev 2 function 0 Intel 82945GME Video rev 0x03
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 intagp0 at vga1
 agp0 at intagp0: aperture at 0x6000, size 0x1000
 inteldrm0 at vga1: apic 4 int 16 (irq 11)
 drm0 at inteldrm0
 Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured
 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: apic
 4 int 16 (irq 11)
 azalia0: codecs: Realtek ALC268
 audio0 at azalia0
 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4 int
 16 (irq 255)
 pci1 at ppb0 bus 1
 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4 int
 17 (irq 255)
 pci2 at ppb1 bus 2
 re0 at pci2 dev 0 function 0 Realtek 8101E rev 0x02: RTL8102EL (0x2480),
 apic 4 int 17 (irq 11), address 00:23:8b:43:96:e6
 rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
 ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 4 int
 18 (irq 255)
 pci3 at ppb2 bus 3
 ral0 at pci3 dev 0 function 0 Ralink RT2790 rev 0x00: apic 4 int 18 (irq
 11), address 00:22:43:14:9b:35
 ral0: MAC/BBP RT2872 (rev 0x0200), RF RT2720 (MIMO 1T2R)
 ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 4 int
 19 (irq 255)
 pci4 at ppb3 bus 4
 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 4 int
 16 (irq 11)
 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB

Re: usb attach lines; print vendor/product id

2010-04-20 Thread Stuart Henderson

On 2010/04/20 15:46, Mark Kettenis wrote:
  Date: Tue, 20 Apr 2010 14:23:46 +0100
  From: Stuart Henderson s...@spacehopper.org

  after reading the N hundredth misc@ post with some USB device
  where device/vendor IDs haven't been shown, it seems that printing
  them in the device attach line might save some trouble.

  any comments/suggestions?

 I think this makes dmesg uglier.  The information is easily available
 from usbdevs(8).

 Perhaps the uglification is acceptable for devices that attach as
 ugen(4) though.

I agree that it makes dmesg uglier, and the information is easily
available. But on the other hand, problem reports are consistently
sent without this information (but they do often have dmesg in the
first mail), and it would add information to dmesglog.

I think there would be relatively small benefit from just doing
this for ugen(4); most of the problem reports that this would
improve involve devices attaching as umsm(4) or uhid(4).

Atheros AR5424 rev 0x01 hal error

2010-04-20 Thread Adam M. Dutko

When I attempt to use my wireless card (AR5424) I get the following:

ath0: unable to reset hardware; hal status 3520208968

The number at the end changes when I try again.

I believe I've traced where the error message is thrown to a section of code
in src/sys/dev/ic/ath.c:


if (!ath_hal_reset(ah, ic-ic_opmode, hchan, AH_TRUE, status)) {
printf(%s: unable to reset hardware; hal status %u\n,
ifp-if_xname, status);
error = EIO;
goto done;
}


I'm going to recompile with ATH_DEBUG=10 and see if I can get more
information.  I'm also trying to trace down the ath_hal_reset function
to see if I can't find something in that area.

Does anyone that's worked on a similar error have any pointers?  Thanks.

Re: Add support to AR5424

2010-04-20 Thread Adam M. Dutko

I have a card to test with and am trying to solve the problem on my eeepc
laptop.  Luis, are you still around and interested in working on this?

Re: Atheros AR5424 rev 0x01 hal error

2010-04-20 Thread Bret S. Lambert

On Tue, Apr 20, 2010 at 10:55:18AM -0400, Adam M. Dutko wrote:
 When I attempt to use my wireless card (AR5424) I get the following:
 
 ath0: unable to reset hardware; hal status 3520208968
 
 The number at the end changes when I try again.

That smells like an uninitialized value for status, to me;
try setting it to something known to be stupid and incorrect at the
top of the function.

 
 I believe I've traced where the error message is thrown to a section of code
 in src/sys/dev/ic/ath.c:
 
 
 if (!ath_hal_reset(ah, ic-ic_opmode, hchan, AH_TRUE, status)) {
   printf(%s: unable to reset hardware; hal status %u\n,
   ifp-if_xname, status);
   error = EIO;
   goto done;
   }
 
 
 I'm going to recompile with ATH_DEBUG=10 and see if I can get more
 information.  I'm also trying to trace down the ath_hal_reset function
 to see if I can't find something in that area.
 
 Does anyone that's worked on a similar error have any pointers?  Thanks.

Re: usb attach lines; print vendor/product id

2010-04-20 Thread Miod Vallat

 I think this makes dmesg uglier.  The information is easily available
 from usbdevs(8).

This argues for sendbug(1) adding the output of `usbdevs -v'.

Miod

Re: Add support to AR5424

2010-04-20 Thread Luis Henriques

On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko dutko.a...@gmail.com wrote:
 I have a card to test with and am trying to solve the problem on my eeepc
 laptop.  Luis, are you still around and interested in working on this?

Yep, still around. But not sure how I can help without the actual HW.

Sometime ago I submited a patch that is working for my card:

ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 (irq
11)
ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address XX:XX:XX:XX:XX:XX

I'm using a CVS head kernel with this patch on my laptop, but some
other guys tried
the same patch with different revs of the card without success:

http://marc.info/?l=openbsd-techm=126437914024661w=2

Try the patch to see what happens. Ah, and send the dmesg (at least the
lines identifing the card.

--
Luis

Re: usb attach lines; print vendor/product id

2010-04-20 Thread Yojiro UO

I agree to kettenis's opinion.

Almost all users will not care the VID/PID information even though it is
contained in dmesg. You (and potential bug report user) can get this
information
(with more detail) by usbdevs. isn't it enough?

-- Yojiro UO

On 2010/04/20, at 23:14, Stuart Henderson wrote:

 On 2010/04/20 15:46, Mark Kettenis wrote:
 Date: Tue, 20 Apr 2010 14:23:46 +0100
 From: Stuart Henderson s...@spacehopper.org

 after reading the N hundredth misc@ post with some USB device
 where device/vendor IDs haven't been shown, it seems that printing
 them in the device attach line might save some trouble.

 any comments/suggestions?

 I think this makes dmesg uglier.  The information is easily available
 from usbdevs(8).

 Perhaps the uglification is acceptable for devices that attach as
 ugen(4) though.

 I agree that it makes dmesg uglier, and the information is easily
 available. But on the other hand, problem reports are consistently
 sent without this information (but they do often have dmesg in the
 first mail), and it would add information to dmesglog.

 I think there would be relatively small benefit from just doing
 this for ugen(4); most of the problem reports that this would
 improve involve devices attaching as umsm(4) or uhid(4).

Re: Add support to AR5424

2010-04-20 Thread Adam M. Dutko

Lines identifying the card:

ath0 at pci2 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 17 (irq
10)
ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:XX:XX:XX:XX:XX

I have the version the other folks had that had issues with your patch.  I
can still attempt to use the patch if you'd like...

On Tue, Apr 20, 2010 at 11:31 AM, Luis Henriques luis.hen...@gmail.comwrote:

 On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko dutko.a...@gmail.com
 wrote:
  I have a card to test with and am trying to solve the problem on my eeepc
  laptop.  Luis, are you still around and interested in working on this?

 Yep, still around. But not sure how I can help without the actual HW.

 Sometime ago I submited a patch that is working for my card:

 ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 (irq
 11)
 ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address XX:XX:XX:XX:XX:XX

 I'm using a CVS head kernel with this patch on my laptop, but some
 other guys tried
 the same patch with different revs of the card without success:

 http://marc.info/?l=openbsd-techm=126437914024661w=2

 Try the patch to see what happens. Ah, and send the dmesg (at least the
 lines identifing the card.

 --
 Luis

Re: Add support to AR5424

2010-04-20 Thread Luis Henriques

On Tue, Apr 20, 2010 at 12:14:51PM -0400, Adam M. Dutko wrote:
 Lines identifying the card:
 
 ath0 at pci2 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 17 (irq
 10)
 ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:XX:XX:XX:XX:XX
 
 I have the version the other folks had that had issues with your patch.  I
 can still attempt to use the patch if you'd like...

Well, I guess there's no point trying it since this version has been tested
already.  I can take a look again at the linux and netbsd code to try to figure
out what is missing to have your card working.  But it will be trial  error:
I send you a patch and you test it :-)

I'll try to get some time today or tomorrow to dive into the driver again.

--
Luis
 
 On Tue, Apr 20, 2010 at 11:31 AM, Luis Henriques luis.hen...@gmail.comwrote:
 
  On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko dutko.a...@gmail.com
  wrote:
   I have a card to test with and am trying to solve the problem on my eeepc
   laptop.  Luis, are you still around and interested in working on this?
 
  Yep, still around. But not sure how I can help without the actual HW.
 
  Sometime ago I submited a patch that is working for my card:
 
  ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 (irq
  11)
  ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address XX:XX:XX:XX:XX:XX
 
  I'm using a CVS head kernel with this patch on my laptop, but some
  other guys tried
  the same patch with different revs of the card without success:
 
  http://marc.info/?l=openbsd-techm=126437914024661w=2
 
  Try the patch to see what happens. Ah, and send the dmesg (at least the
  lines identifing the card.
 
  --
  Luis

Re: usb attach lines; print vendor/product id

2010-04-20 Thread Stuart Henderson

On 2010/04/20 15:31, Miod Vallat wrote:
  I think this makes dmesg uglier.  The information is easily available
  from usbdevs(8).
 
 This argues for sendbug(1) adding the output of `usbdevs -v'.

That makes sense to me. Tested on simh-vax and amd64.

Index: sendbug.1
===
RCS file: /cvs/src/usr.bin/sendbug/sendbug.1,v
retrieving revision 1.19
diff -u -p -r1.19 sendbug.1
--- sendbug.1   10 Jun 2009 06:46:53 -  1.19
+++ sendbug.1   20 Apr 2010 16:58:48 -
@@ -22,6 +22,7 @@ A template PR is opened in a text editor
 with some system information already filled in,
 such as machine architecture,
 .Xr dmesg 8 ,
+.Xr usbdevs 8 ,
 .Xr pcidump 8 ,
 and
 .Xr acpidump 8 .
@@ -63,6 +64,7 @@ The options are as follows:
 .It Fl D
 Do not attach
 .Xr dmesg 8 ,
+.Xr usbdevs 8 ,
 .Xr pcidump 8 ,
 and
 .Xr acpidump 8
Index: sendbug.c
===
RCS file: /cvs/src/usr.bin/sendbug/sendbug.c,v
retrieving revision 1.64
diff -u -p -r1.64 sendbug.c
--- sendbug.c   23 Mar 2010 19:19:53 -  1.64
+++ sendbug.c   20 Apr 2010 16:58:48 -
@@ -42,6 +42,7 @@ int   prompt(void);
 intsend_file(const char *, int);
 intsendmail(const char *);
 void   template(FILE *);
+void   usbdevs(FILE *);
 
 const char *categories = system user library documentation kernel 
 alpha amd64 arm hppa i386 m68k m88k mips64 powerpc sh sparc sparc64 vax;
@@ -230,6 +231,26 @@ dmesg(FILE *fp)
fclose(dfp);
 }
 
+void
+usbdevs(FILE *ofp)
+{
+   char buf[BUFSIZ];
+   FILE *ifp;
+   size_t len;
+
+   if ((ifp = popen(usbdevs -v, r)) != NULL) {
+   while (!feof(ifp)) {
+   len = fread(buf, 1, sizeof buf, ifp);
+   if (len == 0)
+   break;
+   if (fwrite(buf, 1, len, ofp) != len)
+   break;
+   }
+   pclose(ofp);
+   }
+   pclose(ifp);
+}
+
 /*
  * Execute an editor on the specified pathname, which is interpreted
  * from the shell.  This means flags may be included.
@@ -555,12 +576,14 @@ template(FILE *fp)
if (!root)
fprintf(fp, SENDBUG: Run sendbug as root 
if this is an ACPI report!\n);
-   fprintf(fp, SENDBUG: dmesg%s attached.\n
-   SENDBUG: Feel free to delete or use the -D flag if it 
-   contains sensitive information.\n,
-   root ? , pcidump, and acpidump are :  is);
+   fprintf(fp, SENDBUG: dmesg%s and usbdevs are attached.\n
+   SENDBUG: Feel free to delete or use the -D flag if they 
+   contain sensitive information.\n,
+   root ? , pcidump, acpidump : );
fputs(\ndmesg:\n, fp);
dmesg(fp);
+   fputs(\nusbdevs:\n, fp);
+   usbdevs(fp);
if (root)
hwdump(fp);
}

sendbug pclose()

2010-04-20 Thread Stuart Henderson

as pointed out by Peter Philipp, there are some problems with
pclose() in sendbug, this code from hwdump() which I borrowed for
usbdevs()..

 1  if ((ifp = popen(cmd, r)) != NULL) {
 2  while (!feof(ifp)) {
 3  len = fread(buf, 1, sizeof buf, ifp);
 4  if (len == 0)
 5  break;
 6  if (fwrite(buf, 1, len, ofp) != len)
 7  break;
 8  }
 9  pclose(ofp);
10  }
11  pclose(ifp);

- if the popen() fails, it's still trying to pclose(ifp).

- ofp is either stdout or a file descriptor from mkstemp(),
neither of which should be pclose()'d; main() exits if it uses
stdout, or takes care of closing the fd itself.

ok?

Index: sendbug.c
===
RCS file: /cvs/src/usr.bin/sendbug/sendbug.c,v
retrieving revision 1.65
diff -u -p -u -8 -r1.65 sendbug.c
--- sendbug.c   20 Apr 2010 19:05:03 -  1.65
+++ sendbug.c   20 Apr 2010 20:31:08 -
@@ -241,19 +241,18 @@ usbdevs(FILE *ofp)
if ((ifp = popen(usbdevs -v, r)) != NULL) {
while (!feof(ifp)) {
len = fread(buf, 1, sizeof buf, ifp);
if (len == 0)
break;
if (fwrite(buf, 1, len, ofp) != len)
break;
}
-   pclose(ofp);
+   pclose(ifp);
}
-   pclose(ifp);
 }
 
 /*
  * Execute an editor on the specified pathname, which is interpreted
  * from the shell.  This means flags may be included.
  *
  * Returns -1 on error, or the exit value on success.
  */
@@ -616,19 +615,18 @@ hwdump(FILE *ofp)
if ((ifp = popen(cmd, r)) != NULL) {
while (!feof(ifp)) {
len = fread(buf, 1, sizeof buf, ifp);
if (len == 0)
break;
if (fwrite(buf, 1, len, ofp) != len)
break;
}
-   pclose(ofp);
+   pclose(ifp);
}
-   pclose(ifp);
free(cmd);
free(acpidir);
 }
 
 void
 debase(void)
 {
char buf[BUFSIZ];

Для Главного бухгалтера.

2010-04-20 Thread Людмила Грядунова

**
*
*  PP PPPPP'PP!PPP  PPPPPP+  PP.PPPPPP PPPPPP/  P
P#PP PPPPPP'PP!PPPP  P#P'PPP.
*
**

PP0 QP5PP8P=P0Q P?QP8P3P;P0QP0QQQQ: QQP:PP2PP4P8QP5P;P8
P:PPP?P0P=P8P9, QP8P=P0P=QPP2QP5 P4P8QP5P:QPQP0 P8
QPQQQP4P=P8P:P8 QP8P=P0P=QPP2P-Q
P:PP=PPP8QP5QP:P8Q QP;QP6P1.

PP0QQ P?QPP2P5P4P5P=P8Q: 26-27 P0P?QP5P;Q
P P5P3P8QQQP0QP8Q P8 P8P=QPQPP0QP8Q: 8(495)411-94-31

**

P PP PPP PPPP:

1. PP0P: P?QP0P2P8P;QP=P QQP8QP0QQ P4P5P=QP3P8. PP0P:
PQP3P0P=P8P7PP2P0QQ QQP5Q P2 P:PPP?P0P=P8P8
   - PQPQP5QQ QPQPP8QPP2P0P=P8Q QP?QP0P2P;P5P=QP5QP:PP9
P8P=QPQPP0QP8P8.
   - P-P;P5PP5P=QQ B+P:PP=QQQQP:QPQP0B;
QP?QP0P2P;P5P=QP5QP:PP9 PQQP5QP=PQQP8.
   - PP8QP0PP8P4P0 P:PP=QQPP;Q.
   - PP7P0P8PPQP2QP7Q PP5P6P4Q QP?QP0P2P;P5P=QP5QP:PP9 P8
P1QQP3P0P;QP5QQP:PP9 PQQP5QP=PQQQQ.

2. PQP=PP2P=QP5 QP8P=P0P=QPP2QP5 P4PP:QPP5P=QQ.
P#P?QP0P2P;P5P=QP5QP:P8P5 QPQPQ PQQP5QPP2
   - PQQP5Q P P?QP8P1QP;P8. PP0P;P0P=Q.
   - PQQP5Q P P4P2P8P6P5P=P8P8 P4P5P=P5P6P=QQ QQP5P4QQP2.
   - PP4P0P?QP0QP8Q P4P;Q QP5QP5P=P8Q QP?QP0P2P;P5P=QP5QP:P8Q
P7P0P4P0Q.
   - PQP8PP5QQ QP0P1PQP8Q QPQP PQQP5QP=PQQP8
QPQQP8P9QP:P8Q P:PPP?P0P=P8P9.

3. B+PP4P5 P4P5P=QP3P8?B;. PQP2P5Q P=P0 P3P;P0P2P=QP9 P2PP?QPQ
QQP:PP2PP4P8QP5P;Q
   - PQP8P1QP;Q P5QQQ, P0 P4P5P=P5P3 P=P5Q. PP4P5 PP=P8?
   - PP0P3P;QP4P=QP5 QPQPQ P4P;Q P?PP=P8PP0P=P8Q
P8QQPQP=P8P:PP2 P4P5P=P5P6P=QQ QQP5P4QQP2 P8 P=P0P?QP0P2P;P5P=P8Q
P8Q P8QP?PP;QP7PP2P0P=P8Q.
   - PQQP;P5P6P8P2P0P=P8P5 QP8P=P0P=QPP2QQ P?PQPP:PP2
PP5P6P4Q QP0P7P=QPP8 P2P8P4P0PP8 P4P5QQP5P;QP=PQQP8.

4. P#QP5Q P8 QP?QP0P2P;P5P=P8P5 PQP4P5P;QP=QPP8 QQP0QQQPP8
PP1PQPQP=PP3P P:P0P?P8QP0P;P0
   - P!PQQP0P2P;QQQP8P5 PP1PQPQP=PP3P P:P0P?P8QP0P;P0.
   - PPP3P8P:P0 P:5QQP5QP:PP3P QP8P:P;P0.
   - P#QP5Q P8 QP?QP0P2P;P5P=P8P5 QQP0QQQPP8
PP1PQPQP=PP3P P:P0P?P8QP0P;P0.
   - P#P4PP1P=QP5 QPQPQ P4P;Q QQP5QP0 P8 P0P=P0P;P8P7P0.
   - PPP=QQPP;QP=QP5 QPQP:P8 P?QPP2P5QP:P8
PQQP5QP=PQQP8.

5. P P5P=QP0P1P5P;QP=PQQQ, PP1PQP0QP8P2P0P5PPQQQ,
P?QPP8P7P2PP4P8QP5P;QP=PQQQ, P;P8P:P2P8P4P=PQQQ, QP3QPP7P0
P1P0P=P:QPQQQP2P0. PP0 QP5P QP;P5P4P8QQ P8 P:P0P: P2 Q
QPP P=P5
P?PQP5QQQQQQ
   - PQP=PP2P=QP5 P3QQP?P?Q P:PQ
QQP8QP8P5P=QPP2
(QP5P=QP0P1P5P;QP=PQQQ, PP1PQP0QP8P2P0P5PPQQQ,
P;P8P:P2P8P4P=PQQQ, QP3QPP7P0 P1P0P=P:QPQQQP2P0). PPP3P8P:P0
P8Q P?PQQQPP5P=P8Q.
   - B+PQP0P2P8P;QP=QP5B; QPQPQP;Q. P! QP5P
QQP0P2P=P8P2P0QQ P?PP:P0P7P0QP5P;P8.
   - PPQPP8QPP2P0P=P8P5 P?PP:P0P7P0QP5P;P5P9.

6. PP=P0P;P8P7 P2QP3PP4P=PQQP8 P0QQPQQP8PP5P=QP0 P8 P2P8P4PP2
P4P5QQP5P;QP=PQQP8
   - PP0QP6P8P=P0P;QP=QP9 P0P=P0P;P8P7 P0QQPQQP8PP5P=QP0 P8
P2P8P4PP2 P4P5QQP5P;QP=PQQP8.
   - PQP5P=P:P0 QP5P0P;QP=PP9 Q
P:PP=PPP8QP5QP:PP9
Q
QQP5P:QP8P2P=PQQP8.
   - PP4P5 PQ P7P0QP0P1P0QQP2P0P5P, P0 P3P4P5 QP5QQP5P.
   - PP0P:QQP2P0QQ P8P;P8 P=P5 P7P0P:QQP2P0QQ
P=P0P?QP0P2P;P5P=P8P5 P2 QP;QQP0P5 PQQP8QP0QP5P;QP=PP3P
QP5P7QP;QQP0QP0.

7. PPP=QQPP;Q P=P0P4 P7P0QQP0QP0PP8. PPQP:P0
P1P5P7QP1QQPQP=PQQP8. PP5QQ P?P QP=P8P6P5P=P8Q P7P0QQP0Q
   - PP=P0P;P8P7 P8 P?QP8P=QP8P?Q QP0P7P4P5P;P5P=P8Q P7P0QQP0Q.
   - PQP5P=P:P0 QPQP:P8 P1P5P7QP1QQPQP=PQQP8.
   - PQP3P0P=P8P7P0QP8Q P:PP=QQPP;Q P=P0P4 P7P0QQP0QP0PP8.
   - PQP8PP5QQ P?QPP3QP0PP P?P QP=P8P6P5P=P8Q P7P0QQP0Q.

8. P!P8QQP5PP0 QP8P=P0P=QPP2PP3P P?P;P0P=P8QPP2P0P=P8Q -
P1QP4P6P5QP8QPP2P0P=P8Q
   - PP0P4P0QP8 P8 P=P0P7P=P0QP5P=P8P5 QP8QQP5PQ
QP8P=P0P=QPP2PP3P P?P;P0P=P8QPP2P0P=P8Q.
   - PPQP8P7PP=QQ P?P;P0P=P8QPP2P0P=P8Q.
   - PQP=PP2P=QP5 Q
QP0P?Q QP8P:P;P0 P?P;P0P=P8QPP2P0P=P8Q.
   - P#QP;PP2P8Q P2QP?PP;P=P8PPQQP8 P?P;P0P=P0 P8 PP5QQ P?P
QQQQP0P=P5P=P8Q P4P5QP8QP8QP0 P1QP4P6P5QP0.
   - PQP8PP5QQ QP5P0P;P8P7P0QP8P8.

9. PP?P5QP0QP8P2P=PP5 P?P;P0P=P8QPP2P0P=P8P5 P4P5P=P5P6P=QQ
QQP5P4QQP2
   - PQP0P:QP8QP5QP:P0Q QP5QP=PP;PP3P8Q P?PQQP0P=PP2P:P8
QP8QQP5PQ P?P;P0P=P8QPP2P0P=P8Q P4P2P8P6P5P=P8Q P4P5P=P5P6P=QQ
QQP5P4QQP2.
   - PQP3P0P=P8P7P0QP8PP=P=QP5 5P=QQ.
   - P$PQPP8QPP2P0P=P8P5 P=P0P1PQP0 P1QP4P6P5QPP2 P8
PQP2P5QQQP2P5P=P=QQ P7P0 P2QP?PP;P=P5P=P8P5.
   - PQP4P6P5QP=QP9 QP5P3P;P0PP5P=Q, QP0QP?QP5P4P5P;P5P=P8P5
QQP=P:QP8P9, P?PQQP4PP: P2P7P0P8PPP4P5P9QQP2P8Q.
   - PQP3P0P=P8P7P0QP8Q QP?QP0P2P;P5P=P8Q P1QP4P6P5QP0PP8.

10. PPPP?P;P5P:QP=PP5

Re: Atheros AR5424 rev 0x01 hal error

2010-04-20 Thread Peter Hessler

this is a known unsupported chip.  I believe the ISC atheros driver is
compatible, so you may be able to borrow code from linux/freebsd/netbsd
to fix it.

(think of it as a TODO item ;) )


On 2010 Apr 20 (Tue) at 10:55:18 -0400 (-0400), Adam M. Dutko wrote:
:When I attempt to use my wireless card (AR5424) I get the following:
:
:ath0: unable to reset hardware; hal status 3520208968
:
:The number at the end changes when I try again.
:
:I believe I've traced where the error message is thrown to a section of code
:in src/sys/dev/ic/ath.c:
:
:
:if (!ath_hal_reset(ah, ic-ic_opmode, hchan, AH_TRUE, status)) {
:   printf(%s: unable to reset hardware; hal status %u\n,
:   ifp-if_xname, status);
:   error = EIO;
:   goto done;
:   }
:
:
:I'm going to recompile with ATH_DEBUG=10 and see if I can get more
:information.  I'm also trying to trace down the ath_hal_reset function
:to see if I can't find something in that area.
:
:Does anyone that's worked on a similar error have any pointers?  Thanks.
:

-- 
Christ:
A man who was born at least 5,000 years ahead of his time.

diff to fix/clean up ep(4) ioctl handler.

2010-04-20 Thread Brad

A diff for the ep(4) 3Com EtherLink III driver to clean up the ioctl handler
code a bit and eliminate unnecessary resets when reconfiguring IP addresses.

Please test and provide a dmesg.


Index: elink3.c
===
RCS file: /cvs/src/sys/dev/ic/elink3.c,v
retrieving revision 1.76
diff -u -p -r1.76 elink3.c
--- elink3.c24 Nov 2009 18:12:39 -  1.76
+++ elink3.c23 Dec 2009 22:57:06 -
@@ -1462,48 +1462,32 @@ epioctl(ifp, cmd, data)
switch (cmd) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
+   if (!(ifp-if_flags  IFF_RUNNING))
+   epinit(sc);
 
-   switch (ifa-ifa_addr-sa_family) {
 #ifdef INET
-   case AF_INET:
-   epinit(sc);
+   if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-sc_arpcom, ifa);
-   break;
 #endif
-   default:
-   epinit(sc);
-   break;
+   break;
+
+   case SIOCSIFFLAGS:
+   if (ifp-if_flags  IFF_UP) {
+   if (ifp-if_flags  IFF_RUNNING)
+   error = ENETRESET;
+   else
+   epinit(sc);
+   } else {
+   if (ifp-if_flags  IFF_RUNNING) {
+   epstop(sc);
+   ifp-if_flags = ~IFF_RUNNING;
+   }
}
break;
 
case SIOCSIFMEDIA:
case SIOCGIFMEDIA:
error = ifmedia_ioctl(ifp, ifr, sc-sc_mii.mii_media, cmd);
-   break;
-
-   case SIOCSIFFLAGS:
-   if ((ifp-if_flags  IFF_UP) == 0 
-   (ifp-if_flags  IFF_RUNNING) != 0) {
-   /*
-* If interface is marked down and it is running, then
-* stop it.
-*/
-   epstop(sc);
-   ifp-if_flags = ~IFF_RUNNING;
-   } else if ((ifp-if_flags  IFF_UP) != 0 
-  (ifp-if_flags  IFF_RUNNING) == 0) {
-   /*
-* If interface is marked up and it is stopped, then
-* start it.
-*/
-   epinit(sc);
-   } else if ((ifp-if_flags  IFF_UP) != 0) {
-   /*
-* Reset the interface to pick up changes in any other
-* flags that affect hardware registers.
-*/
-   epinit(sc);
-   }
break;
 
default:

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Source Overview

Re: Source Overview

Re: Source Overview

usb attach lines; print vendor/product id

Re: usb attach lines; print vendor/product id

Re: usb attach lines; print vendor/product id

Re: Source Overview

Re: usb attach lines; print vendor/product id

Re: usb attach lines; print vendor/product id

Atheros AR5424 rev 0x01 hal error

Re: Add support to AR5424

Re: Atheros AR5424 rev 0x01 hal error

Re: usb attach lines; print vendor/product id

Re: Add support to AR5424

Re: usb attach lines; print vendor/product id

Re: Add support to AR5424

Re: Add support to AR5424

Re: usb attach lines; print vendor/product id

sendbug pclose()

Для Главного бухгалтера.

Re: Atheros AR5424 rev 0x01 hal error

diff to fix/clean up ep(4) ioctl handler.

22 matches

Site Navigation

Mail list logo

Footer information