膜工程造价◆
SP---5X-9z--#(Fa##Piao#)?IMb?* #,WIQ/#:137 171387 03#, QQ#: aaZ KDE6~ R;NeR;
Re: ZTE MF112 HSUPA - report and patch for usbdevs, umsm.c, umsm.4
s...@spacehopper.org (Stuart Henderson), 2010.12.01 (Wed) 23:45 (CET):
On 2010/12/01 22:55, MERIGHI Marcus wrote:
Without the patches below the thingy attaches as umsm for a second,
detaches and re-attaches as umass.
After patching it attaches as umsm0, umsm1, umsm2, umsm3 and ucom0,
ucom1, ucom2.
does it come back as the same id? the other ZTE devices apparently
come back differently.
since I'm not sure what your question is aiming at I did the attach
and patch dance once more and saved usbdevs -v:
on a snapshot of today, ergo before patching:
first:
umsm0 attach
port 2 addr 2: full speed, power 500 mA, config 1,
ZTE WCDMA Technologies MSM(0x2000), ZTE,Incorporated(0x19d2),
rev 0.00, iSerialNumber P671A2ZTED01
that's alright then, the ID used for the initial attach is listed in
usbdevs.
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.528
diff -u -r1.528 usbdevs
--- sys/dev/usb/usbdevs 30 Nov 2010 00:52:07 - 1.528
+++ sys/dev/usb/usbdevs 1 Dec 2010 21:47:03 -
@@ -3080,6 +3080,7 @@
product ZTE CDMA_MSM 0x0001 CDMA Technologies MSM modem
product ZTE MF633 0x0016 ZTE MF633 USUPA USB modem
product ZTE MF637 0x0031 ZTE MF637 HSUPA USB modem
+product ZTE MF112 0x0117 ZTE MF112 HSUPA USB modem
product ZTE K3565Z 0x0063 ZTE K3565-Z USB MSM modem
productZTE UMASS_INSTALLER20x0103 ZTE USB MSM installer
product ZTE UMASS_INSTALLER0x2000 ZTE USB MSM installer
within each vendor section, usbdevs is sorted by product ID,
please keep it that way. otherwise ok with me.
Only usbdevs changed, modified ordering and modified/added comments.
Index: share/man/man4/umsm.4
===
RCS file: /cvs/src/share/man/man4/umsm.4,v
retrieving revision 1.64
diff -u -r1.64 umsm.4
--- share/man/man4/umsm.4 12 Oct 2010 21:08:08 - 1.64
+++ share/man/man4/umsm.4 1 Dec 2010 21:46:18 -
@@ -92,6 +92,7 @@
.It Li Vodafone Mobile Broadband K3765 Ta Ta USB
.It Li ZTE MF633 Ta Ta USB
.It Li ZTE MF637 Ta Ta USB
+.It Li ZTE MF112 Ta Ta USB
.El
.Pp
Devices suspected of being compatible are:
Index: sys/dev/usb/umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.68
diff -u -r1.68 umsm.c
--- sys/dev/usb/umsm.c 12 Oct 2010 21:08:08 - 1.68
+++ sys/dev/usb/umsm.c 1 Dec 2010 21:46:59 -
@@ -159,6 +159,7 @@
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_K3565Z }, 0},
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF633 }, 0},
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF637 }, 0},
+ {{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF112 }, DEV_UMASS4},
{{ USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_EXPRESSCARD }, 0},
{{ USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_MERLINV620 }, 0},
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.528
diff -u -r1.528 usbdevs
--- sys/dev/usb/usbdevs 30 Nov 2010 00:52:07 - 1.528
+++ sys/dev/usb/usbdevs 2 Dec 2010 10:59:09 -
@@ -32,7 +32,7 @@
*/
/*
- * List of known USB vendors
+ * List of known USB vendors and their product IDs.
*
* Please note that these IDs do not do anything. Adding an ID here and
* regenerating the usbdevs.h and usbdevs_data.h only makes a symbolic name
@@ -48,6 +48,8 @@
*
* You may have to add these defines to the respective probe routines to
* make the device recognised by the appropriate device driver.
+ *
+ * Within each vendor section, this is sorted by product ID.
*/
vendor UNKNOWN10x0053 Unknown vendor
@@ -3082,6 +3084,7 @@
product ZTE MF637 0x0031 ZTE MF637 HSUPA USB modem
product ZTE K3565Z 0x0063 ZTE K3565-Z USB MSM modem
productZTE UMASS_INSTALLER20x0103 ZTE USB MSM installer
+product ZTE MF112 0x0117 ZTE MF112 HSUPA USB modem
product ZTE UMASS_INSTALLER0x2000 ZTE USB MSM installer
product ZTE AC8700 0xfffe AC8700 CDMA USB modem
JVC HD500 - Mejor precio del Mercado
Filmadora JVC-HD500 USD 460 Mejor precio del mercado Sensor CCD (en piacute;xeles) 1 370 000 / Soporte Disco duro de 80 GB / tarjetas MicroSD/ MicroSDHC / Pantalla LCD 2,7 (6,9 cm) / Zoom oacute;ptico 20X, Digital 200X / Salida HDMI VeaMas artiacute;culos de este vendedor
Re: better matching of boot devices on amd64
On Thu, Dec 02, 2010 at 03:17:53PM +1000, David Gwynne wrote:
the boot loader passes a variable that identifies the disk its
booting off made up of a bunch of fields like adapter, controller,
disk, and partition offsets, plus a table of all the disks it can
see which includes this id and a checksum.
the kernel goes through and checksums the disks and then maps that
back to the id associated with that disk, and then compares some
of the fields in those ids against the boot disks id to figure out
which disk its on.
the problem is we overflow one of those fields (the disk id one).
since the other fields are set to 0 by the boot loader, this doesnt
really matter that much. however, since those fields are now
significant because of the overflow, we should compare them too.
this prevents sd16 being matched as the boot disk after sd0 on my
system with 25 disks attached.
sorry if this explanation sucks.
ok?
If this works then ok k...@. Certainly comparing all the fields is
better as far as I am concerned.
My only twinge is relying on the overflow of the unit field. Some
clever dick (intern?) may look at MAKEBOOTDEV() some day and apply
the masks as the word is being constructed. Perhaps a cautionary
note in sys/sys/reboot.h saying we rely on unit overflowing would
not go amiss.
Ken
Index: dkcsum.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/dkcsum.c,v
retrieving revision 1.15
diff -u -p -r1.15 dkcsum.c
--- dkcsum.c 10 Dec 2008 23:41:19 - 1.15
+++ dkcsum.c 2 Dec 2010 05:08:25 -
@@ -71,10 +71,13 @@ dkcsumattach(void)
#ifdef DEBUG
printf(dkcsum: bootdev=%#x\n, bootdev);
- for (bdi = bios_diskinfo; bdi-bios_number != -1; bdi++)
- if (bdi-bios_number 0x80)
- printf(dkcsum: BIOS drive %#x checksum is %#x\n,
- bdi-bios_number, bdi-checksum);
+ for (bdi = bios_diskinfo; bdi-bios_number != -1; bdi++) {
+ if (bdi-bios_number 0x80) {
+ printf(dkcsum: BIOS drive %#x bsd_dev=%#x
+ checksum=%#x\n, bdi-bios_number, bdi-bsd_dev,
+ bdi-checksum);
+ }
+ }
#endif
pribootdev = altbootdev = 0;
@@ -180,7 +183,9 @@ dkcsumattach(void)
*/
/* B_TYPE dependent hd unit counting bootblocks */
- if ((B_TYPE(bootdev) == B_TYPE(hit-bsd_dev))
+ if ((B_ADAPTOR(bootdev) == B_ADAPTOR(hit-bsd_dev))
+ (B_CONTROLLER(bootdev) == B_CONTROLLER(hit-bsd_dev))
+ (B_TYPE(bootdev) == B_TYPE(hit-bsd_dev))
(B_UNIT(bootdev) == B_UNIT(hit-bsd_dev))) {
int type, ctrl, adap, part, unit;
biomask netmask ttymask
Hi, could someone please shed some light on why do we have this printf on some of the architectures but not on the others? what purpose did it serve before? does anyone use it? me is just curious :)
Re: maxdsiz tweaking (fwd)
Date: Wed, 1 Dec 2010 23:05:41 -0500 (EST) From: Ted Unangst ted.unan...@gmail.com reminder that i tested this and it works responses are more helpful than yo this is awesome responses. :) Unless Theo withdraws hos objection to decoupling MAXDSIZ and BRKSIZ, there isn't much point in testing this :(. Also, Index: arch/i386/include/vmparam.h === RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v retrieving revision 1.43 diff -u -r1.43 vmparam.h --- arch/i386/include/vmparam.h 16 Jun 2009 16:42:41 - 1.43 +++ arch/i386/include/vmparam.h 30 Jun 2010 02:17:34 - @@ -63,7 +63,10 @@ #define DFLDSIZ (64*1024*1024) /* initial data size limit */ #endif #ifndef MAXDSIZ -#define MAXDSIZ (1024*1024*1024)/* max data size */ +#define MAXDSIZ (2U*1024*1024*1024 - 4096) /* max data size */ what's the reason for the - 4096 here?
TV LCD - Varios Modelos
TV LCD LED Sharp Aquos 40 USD 1800 TV LCD LED Toshiba 40 USD 2300 TV LCD + DVD Sharp 32 USD 980 TV LCD Sharp Aquos 37 USD 1220
Close-Out Sale
[demime 1.01d removed an attachment of type image/gif which had a name of Close-out Header.jpg] [demime 1.01d removed an attachment of type image/gif which had a name of Polo Shirts.jpg] [demime 1.01d removed an attachment of type image/gif which had a name of Outerwear.jpg] [demime 1.01d removed an attachment of type image/gif which had a name of Dress Shirts.jpg] [demime 1.01d removed an attachment of type image/gif which had a name of Housekeeping.jpg] [demime 1.01d removed an attachment of type image/gif which had a name of Sweaters.jpg] [demime 1.01d removed an attachment of type image/gif which had a name of Nike.jpg] [demime 1.01d removed an attachment of type image/gif which had a name of Close-out Footer.jpg]
Re: maxdsiz tweaking (fwd)
On Thu, Dec 2, 2010 at 8:37 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Wed, 1 Dec 2010 23:05:41 -0500 (EST) From: Ted Unangst ted.unan...@gmail.com reminder that i tested this and it works responses are more helpful than yo this is awesome responses. :) Unless Theo withdraws hos objection to decoupling MAXDSIZ and BRKSIZ, there isn't much point in testing this :(. I'm not aware of any objection other than this needs testing on more than i386. Index: arch/i386/include/vmparam.h === RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v retrieving revision 1.43 diff -u -r1.43 vmparam.h --- arch/i386/include/vmparam.h 16 Jun 2009 16:42:41 - 1.43 +++ arch/i386/include/vmparam.h 30 Jun 2010 02:17:34 - @@ -63,7 +63,10 @@ #define DFLDSIZ (64*1024*1024) /* initial data size limit */ #endif #ifndef MAXDSIZ -#define MAXDSIZ (1024*1024*1024)/* max data size */ +#define MAXDSIZ (2U*1024*1024*1024 - 4096) /* max data size */ what's the reason for the - 4096 here? I am worried about signed bugs. I didn't find any, but I do not want the the maxdsiz to end up in a signed int and turn negative (possibly in some crappy app code). it's more paranoia than any justified reason.
Re: biomask netmask ttymask
could someone please shed some light on why do we have this printf on some of the architectures but not on the others? what purpose did it serve before? does anyone use it? Decades ago, the printf was added because it was important to check the masks; in particular, for the splnet/spltty cross-|'ing hack to support ppp/slip. When apic support came in it gathered a new purpose -- allowing us to easily spot the pic-only machines (especially the almost-all-interrupts-on-one pin machines such as the X40) easily in dmesg, and thus not get confused and chase the wrong bugs. Nowadays, the message has no value since the pic handling must be perfect (enough), so you can go and clean this up.
Re: apmd action scripts
On Wed, Dec 01, 2010 at 11:05:03PM +0100, Holger Mikolon wrote: Hi tech@ ! A couple of times now I didn't notice when my laptop battery reached the 0% remaining capacity. I am not aware of any tool in base that could issue a beep or nice sound in case of critical battery. Currently, apmd reports battery and power events to syslog. Below is a patch to let apmd report battery state, battery life and power state as parameters to an action script (/etc/apm/powerchange). This makes the powerup and powerdown scripts obsolete. I also included my powerchange script as an example. For your information and that of people reading the archives: the current way to do this is sensorsd. Still, this may be more obvious. Joachim
Re: maxdsiz tweaking
What follows is a somewhat older mail I had forgotten about. It's
suddenly become more interesting to be because I was playing around with
jruby which requires a big heap size. It pisses me off to own a 3GB
laptop and only be able to use 1GB of that memory.
This does 2.5 things.
1. If uvm_mmap fails to find memory in the normal mmap area, go back
again and look for memory somewhere else (brk). We only do this after
failure, to preserve the brk space as long as possible.
This is something I have wanted to do for a long time.
Index: uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.127
diff -u -r1.127 uvm_map.c
--- uvm/uvm_map.c 17 Jun 2010 16:11:20 - 1.127
+++ uvm/uvm_map.c 30 Jun 2010 02:17:35 -
@@ -1226,7 +1226,7 @@
* creating a new mapping with prot protection.
*/
vaddr_t
-uvm_map_hint(struct proc *p, vm_prot_t prot)
+uvm_map_hint(struct proc *p, vm_prot_t prot, int invadeheap)
{
vaddr_t addr;
@@ -1242,9 +1242,11 @@
return (round_page(addr));
}
#endif
- addr = (vaddr_t)p-p_vmspace-vm_daddr + MAXDSIZ;
+ addr = (vaddr_t)p-p_vmspace-vm_daddr;
+ if (!invadeheap)
+ addr += BRKSIZ;
#if !defined(__vax__)
- addr += arc4random() (MIN((256 * 1024 * 1024), MAXDSIZ) - 1);
+ addr += arc4random() (MIN((256 * 1024 * 1024), BRKSIZ) - 1);
#else
/* start malloc/mmap after the brk */
addr = (vaddr_t)p-p_vmspace-vm_daddr + BRKSIZ;
The way this is written, invadeheap will never have any effect on vax.
Shouldn't this become something like:
addr = ...
if (!invadeheap)
addr +=
#if !defined(__vax__)
addr += randomness
#endif
Miod
How much will you sell before the end of the year?
Hello , Do you have an accurate forecast of what sales are going to close by the end of the year? Many small businesses don't, and I think December is probably the time of year when it becomes most painful. If you've ever thought of doing a sales forecast before, but just couldn't get in the habit of keeping it up-to-date, I want to share a short (2 minute) video with just two simple rules for making a do-able forecast -- one that's not time-consuming or over-complicated. Just click here http://www.ne16.com/t/14522331/645243910/54259105/0/ to watch it and tell me if you could see yourself doing this or not. http://www.ne16.com/t/14522331/645243910/54259105/0/ It's not rocket-science, so don't expect to be too overwhelmed, but like so many things: it may be simple, but not always easy. Hope you find it helpful. Nick Carter President CEO AddressTwo 8653 Bash Street Indianapolis, IN 46256 p. 317.594.9550 www.addresstwo.com This email was sent to t...@openbsd.org. To stop receiving emails from this user, Powered By: 'http://www.ne16.com/u?id=645243910.e106bd26ed5c7b838114b1b3c3083897n=Tl=a2-ncarter-m51y2008m8-m51y2008m8o=14522331'unsubscribe.
Re: better matching of boot devices on amd64
On 02/12/2010, at 10:35 PM, Kenneth R Westerback wrote: If this works then ok k...@. Certainly comparing all the fields is better as far as I am concerned. My only twinge is relying on the overflow of the unit field. Some clever dick (intern?) may look at MAKEBOOTDEV() some day and apply the masks as the word is being constructed. Perhaps a cautionary note in sys/sys/reboot.h saying we rely on unit overflowing would not go amiss. we'll fix the bootloader eventually. i just dont think that is a great idea at this point in the cycle. dlg
22文件接收☆
SPfa---piao-- ?* #,WIQ/#:r...@h}axF#,6~6~R;H}#,FKB0M!#Q#:r...@6~f_ **H}AxAx**6~0M6~Ax!# Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Najoriginalniji novogodišnji pokloni za Vaše muškarce
Najbolji novogodišnji paketiD za Njega... Top Shop PrazniD ni šoping bez guEve i stresa! Ne znate šta da mu poklonite za Novu Godinu? Ne lupajte više glavu - imamo rešenje! Ponovite se za Novu Pogledajte izbor najkreativnijih i najpraktiD nijh novogodišnjih poklona za Njega koji su bili HIT 2010. ili proizvode uz popuste i do 50%! Obradujte ga najoriginalnijim novogodišnjim poklonom! Ponovite se za Novu Naši muškarci zasluEuju najbolje poklone Paint Zoom - kompresor 2XSweet Dream anatomski jastuk Kosmodisk Classic protiv bolova Water Jet kompresor za vodu Paint Zoom 2 x Sweet Dream Kosmodisk Classic Water Jet 7.490 rsd 2.990 rsd 6.290 rsd 1.290 rsd U korpu U korpu U korpu U korpu Micro Force vodootporni brijaD Smart Pen protiv ogrebotina Heavy Weight set tegova Slime Smart za krpljenje guma Micro Force Smart Pen Heavy Weight Set Slime Smart 2.290 rsd 3.990 rsd 5.490 rsd 2.290 rsd U korpu U korpu U korpu U korpu NOVO: Go 4 Slim - anticelulit steznik i sprej! Ovu elektronsku poštu primate, ukoliko ste svojevoljno ostavili svoju e-mail adresu na nekom od sajtova Top Shop-a, uD estvovali u našoj poklon igri ili nagradnom kvizu ili se prijavili za e-D asopis Top Shop-a ili nekog od nasih brendova. Ponude date u ovom e-mailu vaEe iskljuD ivo za porudEbine upuDene putem Interneta ili broja telefona 021 489 26 60. Ukoliko ne Eelite više da primate naše elektronske poruke, za odjavljivanje sa naše e-mailing liste, kliknite ovde. Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021 489 26 60, Fax: 021 489 29 08, E-mail: i...@news.top-shop.rs [IMAGE]If you would no longer like to receive our emails please unsubscribe by clicking here.
