Re: copying /dev/da0 with dd(1) to file: output differs
El día Friday, November 19, 2010 a las 05:42:57PM -0700, Warren Block escribió: > On Fri, 19 Nov 2010, Matthias Apitz wrote: > > El d?a Friday, November 19, 2010 a las 12:39:13PM -0700, Warren Block > > escribi?: > > > >>> Should I overwrite the full USB key from /dev/zero? > >> > >> Possibly there would still be differences. Filesystem metadata like > >> date last mounted, for example. If you want a block-by-block duplicate, > >> the brute-force method is to just dd the whole drive. Use bs=64k or > >> bs=1m to help reduce overhead. > > > > Warren, perhaps you missed my point. I have a prepared boot-able key and > > I want to give away a copy of it as a file on DVD. So I dd(1)'ed the key > > to disk and did this twice to ensure that the copy was fine, but the two > > files differ. How can I make sure that the file on disk (or DVD) is a > > exact copy of the key? > > Okay, that makes more sense. Did you mount the key in between the two > times it was dd-ed? No. I just fired up the dd(1) a 2nd time to another file to check if it would produce two times the same result. And, surprise, they differ, they differ each time and in laptops differentes as well. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 23:24, Pyun YongHyeon wrote: > On Fri, Nov 19, 2010 at 11:20:25PM -0200, Nenhum_de_Nos wrote: >> >> On Fri, November 19, 2010 22:52, Pyun YongHyeon wrote: >> > On Fri, Nov 19, 2010 at 08:30:54PM -0200, Nenhum_de_Nos wrote: >> >> >> >> On Fri, November 19, 2010 20:07, Nenhum_de_Nos wrote: >> >> > >> >> > On Fri, November 19, 2010 20:02, Pyun YongHyeon wrote: >> >> >> On Fri, Nov 19, 2010 at 07:49:57PM -0200, Nenhum_de_Nos wrote: >> >> >>> >> >> >>> On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote: >> >> >>> > On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote: >> >> >>> > >> >> >>> > [...] >> >> >>> > >> >> >>> >> > Ok, try again after downloading new if_axe.c and let me know >> >> >>> >> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on >> your >> >> >>> >> > console. >> >> >>> >> >> >> >>> >> never got to see that message. I saw the diff to previous >> >> version, >> >> >>> and >> >> >>> >> did >> >> >>> >> boot into verbose mode (dmesg attached). there were just the >> >> belkin >> >> >>> >> gigabit nic on boot. after, the linksys USB200M: >> >> >>> >> >> >> >>> >> axe1: on >> >> >>> usbus2 >> >> >>> >> axe1: PHYADDR 0xe0:0x10 >> >> >>> >> miibus2: on axe1 >> >> >>> >> ukphy1: PHY 16 on >> miibus2 >> >> >>> >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 >> >> >>> >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> >> >>> >> ue1: on axe1 >> >> >>> >> ue1: bpf attached >> >> >>> >> invalid media SR 0x700 >> >> >>> >> invalid media SR 0x700 >> >> >>> >> >> >> >>> > >> >> >>> > This is normal, the message I said will show up when you use >> >> >>> > gigabit controller, AX88178. This controller is fast ethernet >> >> >>> > controller, AX88772A. >> >> >>> >> >> >>> yes, I just tried to show that message with other nic. >> >> >>> >> >> >>> >> >> >> >>> >> and the other gigabit: >> >> >>> >> >> >> >>> >> ugen2.4: at usbus2 >> >> >>> >> axe2: on >> >> >>> usbus2 >> >> >>> >> axe2: PHYADDR 0xe0:0x01 >> >> >>> >> miibus3: on axe2 >> >> >>> >> truephy1: PHY 1 on miibus3 >> >> >>> >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> >> >>> >> 1000baseT-FDX, >> >> >>> >> auto >> >> >>> >> ue2: on axe2 >> >> >>> >> ue2: bpf attached >> >> >>> >> ue2: Ethernet address: my mac here >> >> >>> >> ue2: link state changed to DOWN >> >> >>> >> >> >> >>> >> and never got to see the EEPROM message. >> >> >>> >> >> >> >>> > >> >> >>> > Two odd things here. This controller looks like Belkin F5D5055 >> and >> >> >>> >> >> >>> yes, it's this one. >> >> >>> >> >> >>> > it is gigabit controller. So it should print the message I >> >> >>> > mentioned in previous mail. Are you sure you rebuild/reboot >> your >> >> >>> > kernel? >> >> >>> >> >> >>> as usual, just rebuilt the axe module ... so I'm going to rebuild >> >> now. >> >> >>> this is a slow box, and might take a couple of hours. Will try to >> do >> >> it >> >> >>> also in a notebook running stable to speedup the process. >> >> >>> >> >> >>> > The second odd thing is now truephy(4) PHY driver is attached >> to >> >> >>> > your controller. Previously it was ukphy(4) generic PHY driver. >> >> >>> > This means accessing GMII is not reliable such that reading OUI >> of >> >> >>> > PHY changed its value. Maybe this could the reason why you see >> >> lots >> >> >>> > of link UP/DOWN messages since mii(4) periodically polls a >> >> register >> >> >>> > through GMII. If the register value read through GMII >> constantly >> >> >>> > changes it will cause all sorts of problems. >> >> >>> > I'm not sure whether this is axe(4) issue or USB stack issue. I >> >> >>> > also have Belkin F5D5055 controller and has no such problems so >> I >> >> >>> > guess it could be related with other parts of USB stack. >> >> >>> > >> >> >>> > To easily identify issues for a controller, it would be better >> to >> >> >>> > remove all other axe(4) controllers except one you want to >> test. >> >> >>> >> >> >>> ok, I was also testing that other issue. Will separate things >> from >> >> now >> >> >>> on. >> >> >>> no problem using stable from October 7, right ? >> >> >>> >> >> >> >> >> >> Hmm, that depends on your environments. To test USB issues it >> would >> >> >> be better to use stable/8. >> >> > >> >> > both are 8-stable from the beginning of October. As the faster is >> >> already >> >> > compiling things, and it takes 1h max, I'll try this way and can >> after >> >> > update to today 8-stable. >> >> > >> >> > if anything, just say :) >> >> > >> >> > thanks, >> >> > >> >> > matheus >> >> > >> >> >>> thanks, >> >> >>> >> >> >>> matheus >> >> >> >> here: >> >> >> >> ugen0.2: at usbus0 >> >> wlan0: Ethernet address: a mac here >> >> fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 >> >> ugen1.3: at usbus1 >> >> axe0: on usbus1 >> >> axe0: EEPROM data : 0x0a82, phymode : 02 >> >> axe0: MII without any PHY >> >> wlan0: link state changed to UP >> >> wlan0: link state changed to DOWN >> >> wlan0: link state changed to UP >> >>
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, Nov 19, 2010 at 11:20:25PM -0200, Nenhum_de_Nos wrote: > > On Fri, November 19, 2010 22:52, Pyun YongHyeon wrote: > > On Fri, Nov 19, 2010 at 08:30:54PM -0200, Nenhum_de_Nos wrote: > >> > >> On Fri, November 19, 2010 20:07, Nenhum_de_Nos wrote: > >> > > >> > On Fri, November 19, 2010 20:02, Pyun YongHyeon wrote: > >> >> On Fri, Nov 19, 2010 at 07:49:57PM -0200, Nenhum_de_Nos wrote: > >> >>> > >> >>> On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote: > >> >>> > On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote: > >> >>> > > >> >>> > [...] > >> >>> > > >> >>> >> > Ok, try again after downloading new if_axe.c and let me know > >> >>> >> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your > >> >>> >> > console. > >> >>> >> > >> >>> >> never got to see that message. I saw the diff to previous > >> version, > >> >>> and > >> >>> >> did > >> >>> >> boot into verbose mode (dmesg attached). there were just the > >> belkin > >> >>> >> gigabit nic on boot. after, the linksys USB200M: > >> >>> >> > >> >>> >> axe1: on > >> >>> usbus2 > >> >>> >> axe1: PHYADDR 0xe0:0x10 > >> >>> >> miibus2: on axe1 > >> >>> >> ukphy1: PHY 16 on miibus2 > >> >>> >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 > >> >>> >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >> >>> >> ue1: on axe1 > >> >>> >> ue1: bpf attached > >> >>> >> invalid media SR 0x700 > >> >>> >> invalid media SR 0x700 > >> >>> >> > >> >>> > > >> >>> > This is normal, the message I said will show up when you use > >> >>> > gigabit controller, AX88178. This controller is fast ethernet > >> >>> > controller, AX88772A. > >> >>> > >> >>> yes, I just tried to show that message with other nic. > >> >>> > >> >>> >> > >> >>> >> and the other gigabit: > >> >>> >> > >> >>> >> ugen2.4: at usbus2 > >> >>> >> axe2: on > >> >>> usbus2 > >> >>> >> axe2: PHYADDR 0xe0:0x01 > >> >>> >> miibus3: on axe2 > >> >>> >> truephy1: PHY 1 on miibus3 > >> >>> >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >> >>> >> 1000baseT-FDX, > >> >>> >> auto > >> >>> >> ue2: on axe2 > >> >>> >> ue2: bpf attached > >> >>> >> ue2: Ethernet address: my mac here > >> >>> >> ue2: link state changed to DOWN > >> >>> >> > >> >>> >> and never got to see the EEPROM message. > >> >>> >> > >> >>> > > >> >>> > Two odd things here. This controller looks like Belkin F5D5055 and > >> >>> > >> >>> yes, it's this one. > >> >>> > >> >>> > it is gigabit controller. So it should print the message I > >> >>> > mentioned in previous mail. Are you sure you rebuild/reboot your > >> >>> > kernel? > >> >>> > >> >>> as usual, just rebuilt the axe module ... so I'm going to rebuild > >> now. > >> >>> this is a slow box, and might take a couple of hours. Will try to do > >> it > >> >>> also in a notebook running stable to speedup the process. > >> >>> > >> >>> > The second odd thing is now truephy(4) PHY driver is attached to > >> >>> > your controller. Previously it was ukphy(4) generic PHY driver. > >> >>> > This means accessing GMII is not reliable such that reading OUI of > >> >>> > PHY changed its value. Maybe this could the reason why you see > >> lots > >> >>> > of link UP/DOWN messages since mii(4) periodically polls a > >> register > >> >>> > through GMII. If the register value read through GMII constantly > >> >>> > changes it will cause all sorts of problems. > >> >>> > I'm not sure whether this is axe(4) issue or USB stack issue. I > >> >>> > also have Belkin F5D5055 controller and has no such problems so I > >> >>> > guess it could be related with other parts of USB stack. > >> >>> > > >> >>> > To easily identify issues for a controller, it would be better to > >> >>> > remove all other axe(4) controllers except one you want to test. > >> >>> > >> >>> ok, I was also testing that other issue. Will separate things from > >> now > >> >>> on. > >> >>> no problem using stable from October 7, right ? > >> >>> > >> >> > >> >> Hmm, that depends on your environments. To test USB issues it would > >> >> be better to use stable/8. > >> > > >> > both are 8-stable from the beginning of October. As the faster is > >> already > >> > compiling things, and it takes 1h max, I'll try this way and can after > >> > update to today 8-stable. > >> > > >> > if anything, just say :) > >> > > >> > thanks, > >> > > >> > matheus > >> > > >> >>> thanks, > >> >>> > >> >>> matheus > >> > >> here: > >> > >> ugen0.2: at usbus0 > >> wlan0: Ethernet address: a mac here > >> fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > >> ugen1.3: at usbus1 > >> axe0: on usbus1 > >> axe0: EEPROM data : 0x0a82, phymode : 02 > >> axe0: MII without any PHY > >> wlan0: link state changed to UP > >> wlan0: link state changed to DOWN > >> wlan0: link state changed to UP > >> ugen1.3: at usbus1 (disconnected) > >> axe0: at uhub1, port 3, addr 3 (disconnected) > >> ugen1.3: at usbus1 > >> axe0: on usbus1 > >> axe0: EEPROM data : 0x0a82, phymode : 02 > > ^^^ > > Th
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 22:52, Pyun YongHyeon wrote: > On Fri, Nov 19, 2010 at 08:30:54PM -0200, Nenhum_de_Nos wrote: >> >> On Fri, November 19, 2010 20:07, Nenhum_de_Nos wrote: >> > >> > On Fri, November 19, 2010 20:02, Pyun YongHyeon wrote: >> >> On Fri, Nov 19, 2010 at 07:49:57PM -0200, Nenhum_de_Nos wrote: >> >>> >> >>> On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote: >> >>> > On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote: >> >>> > >> >>> > [...] >> >>> > >> >>> >> > Ok, try again after downloading new if_axe.c and let me know >> >>> >> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your >> >>> >> > console. >> >>> >> >> >>> >> never got to see that message. I saw the diff to previous >> version, >> >>> and >> >>> >> did >> >>> >> boot into verbose mode (dmesg attached). there were just the >> belkin >> >>> >> gigabit nic on boot. after, the linksys USB200M: >> >>> >> >> >>> >> axe1: on >> >>> usbus2 >> >>> >> axe1: PHYADDR 0xe0:0x10 >> >>> >> miibus2: on axe1 >> >>> >> ukphy1: PHY 16 on miibus2 >> >>> >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 >> >>> >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> >>> >> ue1: on axe1 >> >>> >> ue1: bpf attached >> >>> >> invalid media SR 0x700 >> >>> >> invalid media SR 0x700 >> >>> >> >> >>> > >> >>> > This is normal, the message I said will show up when you use >> >>> > gigabit controller, AX88178. This controller is fast ethernet >> >>> > controller, AX88772A. >> >>> >> >>> yes, I just tried to show that message with other nic. >> >>> >> >>> >> >> >>> >> and the other gigabit: >> >>> >> >> >>> >> ugen2.4: at usbus2 >> >>> >> axe2: on >> >>> usbus2 >> >>> >> axe2: PHYADDR 0xe0:0x01 >> >>> >> miibus3: on axe2 >> >>> >> truephy1: PHY 1 on miibus3 >> >>> >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> >>> >> 1000baseT-FDX, >> >>> >> auto >> >>> >> ue2: on axe2 >> >>> >> ue2: bpf attached >> >>> >> ue2: Ethernet address: my mac here >> >>> >> ue2: link state changed to DOWN >> >>> >> >> >>> >> and never got to see the EEPROM message. >> >>> >> >> >>> > >> >>> > Two odd things here. This controller looks like Belkin F5D5055 and >> >>> >> >>> yes, it's this one. >> >>> >> >>> > it is gigabit controller. So it should print the message I >> >>> > mentioned in previous mail. Are you sure you rebuild/reboot your >> >>> > kernel? >> >>> >> >>> as usual, just rebuilt the axe module ... so I'm going to rebuild >> now. >> >>> this is a slow box, and might take a couple of hours. Will try to do >> it >> >>> also in a notebook running stable to speedup the process. >> >>> >> >>> > The second odd thing is now truephy(4) PHY driver is attached to >> >>> > your controller. Previously it was ukphy(4) generic PHY driver. >> >>> > This means accessing GMII is not reliable such that reading OUI of >> >>> > PHY changed its value. Maybe this could the reason why you see >> lots >> >>> > of link UP/DOWN messages since mii(4) periodically polls a >> register >> >>> > through GMII. If the register value read through GMII constantly >> >>> > changes it will cause all sorts of problems. >> >>> > I'm not sure whether this is axe(4) issue or USB stack issue. I >> >>> > also have Belkin F5D5055 controller and has no such problems so I >> >>> > guess it could be related with other parts of USB stack. >> >>> > >> >>> > To easily identify issues for a controller, it would be better to >> >>> > remove all other axe(4) controllers except one you want to test. >> >>> >> >>> ok, I was also testing that other issue. Will separate things from >> now >> >>> on. >> >>> no problem using stable from October 7, right ? >> >>> >> >> >> >> Hmm, that depends on your environments. To test USB issues it would >> >> be better to use stable/8. >> > >> > both are 8-stable from the beginning of October. As the faster is >> already >> > compiling things, and it takes 1h max, I'll try this way and can after >> > update to today 8-stable. >> > >> > if anything, just say :) >> > >> > thanks, >> > >> > matheus >> > >> >>> thanks, >> >>> >> >>> matheus >> >> here: >> >> ugen0.2: at usbus0 >> wlan0: Ethernet address: a mac here >> fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 >> ugen1.3: at usbus1 >> axe0: on usbus1 >> axe0: EEPROM data : 0x0a82, phymode : 02 >> axe0: MII without any PHY >> wlan0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> ugen1.3: at usbus1 (disconnected) >> axe0: at uhub1, port 3, addr 3 (disconnected) >> ugen1.3: at usbus1 >> axe0: on usbus1 >> axe0: EEPROM data : 0x0a82, phymode : 02 > ^^^ > Thanks. It's big hint. I uploaded updated if_axe.c > Let me know it makes any difference. need to recompile kernel, or just if_axe ? will do this asap. matheus >> miibus1: on axe0 >> ukphy0: PHY 1 on miibus1 >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> ue0: on axe0 >> ue0: Ethernet
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, Nov 19, 2010 at 08:30:54PM -0200, Nenhum_de_Nos wrote:
>
> On Fri, November 19, 2010 20:07, Nenhum_de_Nos wrote:
> >
> > On Fri, November 19, 2010 20:02, Pyun YongHyeon wrote:
> >> On Fri, Nov 19, 2010 at 07:49:57PM -0200, Nenhum_de_Nos wrote:
> >>>
> >>> On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote:
> >>> > On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote:
> >>> >
> >>> > [...]
> >>> >
> >>> >> > Ok, try again after downloading new if_axe.c and let me know
> >>> >> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your
> >>> >> > console.
> >>> >>
> >>> >> never got to see that message. I saw the diff to previous version,
> >>> and
> >>> >> did
> >>> >> boot into verbose mode (dmesg attached). there were just the belkin
> >>> >> gigabit nic on boot. after, the linksys USB200M:
> >>> >>
> >>> >> axe1: on
> >>> usbus2
> >>> >> axe1: PHYADDR 0xe0:0x10
> >>> >> miibus2: on axe1
> >>> >> ukphy1: PHY 16 on miibus2
> >>> >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1
> >>> >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> >>> >> ue1: on axe1
> >>> >> ue1: bpf attached
> >>> >> invalid media SR 0x700
> >>> >> invalid media SR 0x700
> >>> >>
> >>> >
> >>> > This is normal, the message I said will show up when you use
> >>> > gigabit controller, AX88178. This controller is fast ethernet
> >>> > controller, AX88772A.
> >>>
> >>> yes, I just tried to show that message with other nic.
> >>>
> >>> >>
> >>> >> and the other gigabit:
> >>> >>
> >>> >> ugen2.4: at usbus2
> >>> >> axe2: on
> >>> usbus2
> >>> >> axe2: PHYADDR 0xe0:0x01
> >>> >> miibus3: on axe2
> >>> >> truephy1: PHY 1 on miibus3
> >>> >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> >>> >> 1000baseT-FDX,
> >>> >> auto
> >>> >> ue2: on axe2
> >>> >> ue2: bpf attached
> >>> >> ue2: Ethernet address: my mac here
> >>> >> ue2: link state changed to DOWN
> >>> >>
> >>> >> and never got to see the EEPROM message.
> >>> >>
> >>> >
> >>> > Two odd things here. This controller looks like Belkin F5D5055 and
> >>>
> >>> yes, it's this one.
> >>>
> >>> > it is gigabit controller. So it should print the message I
> >>> > mentioned in previous mail. Are you sure you rebuild/reboot your
> >>> > kernel?
> >>>
> >>> as usual, just rebuilt the axe module ... so I'm going to rebuild now.
> >>> this is a slow box, and might take a couple of hours. Will try to do it
> >>> also in a notebook running stable to speedup the process.
> >>>
> >>> > The second odd thing is now truephy(4) PHY driver is attached to
> >>> > your controller. Previously it was ukphy(4) generic PHY driver.
> >>> > This means accessing GMII is not reliable such that reading OUI of
> >>> > PHY changed its value. Maybe this could the reason why you see lots
> >>> > of link UP/DOWN messages since mii(4) periodically polls a register
> >>> > through GMII. If the register value read through GMII constantly
> >>> > changes it will cause all sorts of problems.
> >>> > I'm not sure whether this is axe(4) issue or USB stack issue. I
> >>> > also have Belkin F5D5055 controller and has no such problems so I
> >>> > guess it could be related with other parts of USB stack.
> >>> >
> >>> > To easily identify issues for a controller, it would be better to
> >>> > remove all other axe(4) controllers except one you want to test.
> >>>
> >>> ok, I was also testing that other issue. Will separate things from now
> >>> on.
> >>> no problem using stable from October 7, right ?
> >>>
> >>
> >> Hmm, that depends on your environments. To test USB issues it would
> >> be better to use stable/8.
> >
> > both are 8-stable from the beginning of October. As the faster is already
> > compiling things, and it takes 1h max, I'll try this way and can after
> > update to today 8-stable.
> >
> > if anything, just say :)
> >
> > thanks,
> >
> > matheus
> >
> >>> thanks,
> >>>
> >>> matheus
>
> here:
>
> ugen0.2: at usbus0
> wlan0: Ethernet address: a mac here
> fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8
> ugen1.3: at usbus1
> axe0: on usbus1
> axe0: EEPROM data : 0x0a82, phymode : 02
> axe0: MII without any PHY
> wlan0: link state changed to UP
> wlan0: link state changed to DOWN
> wlan0: link state changed to UP
> ugen1.3: at usbus1 (disconnected)
> axe0: at uhub1, port 3, addr 3 (disconnected)
> ugen1.3: at usbus1
> axe0: on usbus1
> axe0: EEPROM data : 0x0a82, phymode : 02
^^^
Thanks. It's big hint. I uploaded updated if_axe.c
Let me know it makes any difference.
> miibus1: on axe0
> ukphy0: PHY 1 on miibus1
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> ue0: on axe0
> ue0: Ethernet address: a mac here
> ue0: link state changed to DOWN
>
> both belkin, each one at a time.
>
> will sync world and kernel and make {kernel,world}
>
> thanks,
>
> matheus
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mail
Re: copying /dev/da0 with dd(1) to file: output differs
On Fri, 19 Nov 2010, Matthias Apitz wrote: El d?a Friday, November 19, 2010 a las 12:39:13PM -0700, Warren Block escribi?: Should I overwrite the full USB key from /dev/zero? Possibly there would still be differences. Filesystem metadata like date last mounted, for example. If you want a block-by-block duplicate, the brute-force method is to just dd the whole drive. Use bs=64k or bs=1m to help reduce overhead. Warren, perhaps you missed my point. I have a prepared boot-able key and I want to give away a copy of it as a file on DVD. So I dd(1)'ed the key to disk and did this twice to ensure that the copy was fine, but the two files differ. How can I make sure that the file on disk (or DVD) is a exact copy of the key? Okay, that makes more sense. Did you mount the key in between the two times it was dd-ed? ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: copying /dev/da0 with dd(1) to file: output differs
On Fri, Nov 19, 2010 at 06:35:19PM +0100, Matthias Apitz wrote: > El día Friday, November 19, 2010 a las 06:21:09PM +0100, Hans Petter Selasky > escribió: > > > > > Can you dump the data into hex using hexdump -C and show us the > > > > difference. > > > > > > Note: the output of the dd(1) is around 3.8 GByte. I compared the 1st > > > 2.000.000 lines of the hexdump: no diff; any better tool to show the 1st > > > block which differs? > > > > > > > Usually you would use bs=65536 (Does that change anything)? > > > > > > Same result: they differ :-( > > > > > > matthias > > > > bsdiff ? > > This will not work with such big files (requires 8x memory of the file): > > I was thinking in a tool just reading each file block by block, > comparing the blocks and noting the 1st diff with block offset number. > (some 10 lines of C code :-)) E... are you thinking of cmp(1), maybe with the -l option? :) G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 When you are not looking at it, this sentence is in Spanish. signature.asc Description: Digital signature
FreeBSD + pilot-link + USB
Does anybody here know how to use pilot-link on FreeBSD with a Zire 21 over USB? It appears that usb_scan_devices never finds my device. Thanks for any guidance you can give me.-- George Mitchell ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 20:07, Nenhum_de_Nos wrote:
>
> On Fri, November 19, 2010 20:02, Pyun YongHyeon wrote:
>> On Fri, Nov 19, 2010 at 07:49:57PM -0200, Nenhum_de_Nos wrote:
>>>
>>> On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote:
>>> > On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote:
>>> >
>>> > [...]
>>> >
>>> >> > Ok, try again after downloading new if_axe.c and let me know
>>> >> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your
>>> >> > console.
>>> >>
>>> >> never got to see that message. I saw the diff to previous version,
>>> and
>>> >> did
>>> >> boot into verbose mode (dmesg attached). there were just the belkin
>>> >> gigabit nic on boot. after, the linksys USB200M:
>>> >>
>>> >> axe1: on
>>> usbus2
>>> >> axe1: PHYADDR 0xe0:0x10
>>> >> miibus2: on axe1
>>> >> ukphy1: PHY 16 on miibus2
>>> >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1
>>> >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>>> >> ue1: on axe1
>>> >> ue1: bpf attached
>>> >> invalid media SR 0x700
>>> >> invalid media SR 0x700
>>> >>
>>> >
>>> > This is normal, the message I said will show up when you use
>>> > gigabit controller, AX88178. This controller is fast ethernet
>>> > controller, AX88772A.
>>>
>>> yes, I just tried to show that message with other nic.
>>>
>>> >>
>>> >> and the other gigabit:
>>> >>
>>> >> ugen2.4: at usbus2
>>> >> axe2: on
>>> usbus2
>>> >> axe2: PHYADDR 0xe0:0x01
>>> >> miibus3: on axe2
>>> >> truephy1: PHY 1 on miibus3
>>> >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
>>> >> 1000baseT-FDX,
>>> >> auto
>>> >> ue2: on axe2
>>> >> ue2: bpf attached
>>> >> ue2: Ethernet address: my mac here
>>> >> ue2: link state changed to DOWN
>>> >>
>>> >> and never got to see the EEPROM message.
>>> >>
>>> >
>>> > Two odd things here. This controller looks like Belkin F5D5055 and
>>>
>>> yes, it's this one.
>>>
>>> > it is gigabit controller. So it should print the message I
>>> > mentioned in previous mail. Are you sure you rebuild/reboot your
>>> > kernel?
>>>
>>> as usual, just rebuilt the axe module ... so I'm going to rebuild now.
>>> this is a slow box, and might take a couple of hours. Will try to do it
>>> also in a notebook running stable to speedup the process.
>>>
>>> > The second odd thing is now truephy(4) PHY driver is attached to
>>> > your controller. Previously it was ukphy(4) generic PHY driver.
>>> > This means accessing GMII is not reliable such that reading OUI of
>>> > PHY changed its value. Maybe this could the reason why you see lots
>>> > of link UP/DOWN messages since mii(4) periodically polls a register
>>> > through GMII. If the register value read through GMII constantly
>>> > changes it will cause all sorts of problems.
>>> > I'm not sure whether this is axe(4) issue or USB stack issue. I
>>> > also have Belkin F5D5055 controller and has no such problems so I
>>> > guess it could be related with other parts of USB stack.
>>> >
>>> > To easily identify issues for a controller, it would be better to
>>> > remove all other axe(4) controllers except one you want to test.
>>>
>>> ok, I was also testing that other issue. Will separate things from now
>>> on.
>>> no problem using stable from October 7, right ?
>>>
>>
>> Hmm, that depends on your environments. To test USB issues it would
>> be better to use stable/8.
>
> both are 8-stable from the beginning of October. As the faster is already
> compiling things, and it takes 1h max, I'll try this way and can after
> update to today 8-stable.
>
> if anything, just say :)
>
> thanks,
>
> matheus
>
>>> thanks,
>>>
>>> matheus
here:
ugen0.2: at usbus0
wlan0: Ethernet address: a mac here
fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8
ugen1.3: at usbus1
axe0: on usbus1
axe0: EEPROM data : 0x0a82, phymode : 02
axe0: MII without any PHY
wlan0: link state changed to UP
wlan0: link state changed to DOWN
wlan0: link state changed to UP
ugen1.3: at usbus1 (disconnected)
axe0: at uhub1, port 3, addr 3 (disconnected)
ugen1.3: at usbus1
axe0: on usbus1
axe0: EEPROM data : 0x0a82, phymode : 02
miibus1: on axe0
ukphy0: PHY 1 on miibus1
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
ue0: on axe0
ue0: Ethernet address: a mac here
ue0: link state changed to DOWN
both belkin, each one at a time.
will sync world and kernel and make {kernel,world}
thanks,
matheus
--
We will call you cygnus,
The God of balance you shall be
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
http://en.wikipedia.org/wiki/Posting_style
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 20:02, Pyun YongHyeon wrote: > On Fri, Nov 19, 2010 at 07:49:57PM -0200, Nenhum_de_Nos wrote: >> >> On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote: >> > On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote: >> > >> > [...] >> > >> >> > Ok, try again after downloading new if_axe.c and let me know >> >> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your >> >> > console. >> >> >> >> never got to see that message. I saw the diff to previous version, >> and >> >> did >> >> boot into verbose mode (dmesg attached). there were just the belkin >> >> gigabit nic on boot. after, the linksys USB200M: >> >> >> >> axe1: on usbus2 >> >> axe1: PHYADDR 0xe0:0x10 >> >> miibus2: on axe1 >> >> ukphy1: PHY 16 on miibus2 >> >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 >> >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> >> ue1: on axe1 >> >> ue1: bpf attached >> >> invalid media SR 0x700 >> >> invalid media SR 0x700 >> >> >> > >> > This is normal, the message I said will show up when you use >> > gigabit controller, AX88178. This controller is fast ethernet >> > controller, AX88772A. >> >> yes, I just tried to show that message with other nic. >> >> >> >> >> and the other gigabit: >> >> >> >> ugen2.4: at usbus2 >> >> axe2: on usbus2 >> >> axe2: PHYADDR 0xe0:0x01 >> >> miibus3: on axe2 >> >> truephy1: PHY 1 on miibus3 >> >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> >> 1000baseT-FDX, >> >> auto >> >> ue2: on axe2 >> >> ue2: bpf attached >> >> ue2: Ethernet address: my mac here >> >> ue2: link state changed to DOWN >> >> >> >> and never got to see the EEPROM message. >> >> >> > >> > Two odd things here. This controller looks like Belkin F5D5055 and >> >> yes, it's this one. >> >> > it is gigabit controller. So it should print the message I >> > mentioned in previous mail. Are you sure you rebuild/reboot your >> > kernel? >> >> as usual, just rebuilt the axe module ... so I'm going to rebuild now. >> this is a slow box, and might take a couple of hours. Will try to do it >> also in a notebook running stable to speedup the process. >> >> > The second odd thing is now truephy(4) PHY driver is attached to >> > your controller. Previously it was ukphy(4) generic PHY driver. >> > This means accessing GMII is not reliable such that reading OUI of >> > PHY changed its value. Maybe this could the reason why you see lots >> > of link UP/DOWN messages since mii(4) periodically polls a register >> > through GMII. If the register value read through GMII constantly >> > changes it will cause all sorts of problems. >> > I'm not sure whether this is axe(4) issue or USB stack issue. I >> > also have Belkin F5D5055 controller and has no such problems so I >> > guess it could be related with other parts of USB stack. >> > >> > To easily identify issues for a controller, it would be better to >> > remove all other axe(4) controllers except one you want to test. >> >> ok, I was also testing that other issue. Will separate things from now >> on. >> no problem using stable from October 7, right ? >> > > Hmm, that depends on your environments. To test USB issues it would > be better to use stable/8. both are 8-stable from the beginning of October. As the faster is already compiling things, and it takes 1h max, I'll try this way and can after update to today 8-stable. if anything, just say :) thanks, matheus >> thanks, >> >> matheus > -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, Nov 19, 2010 at 07:49:57PM -0200, Nenhum_de_Nos wrote: > > On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote: > > On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote: > > > > [...] > > > >> > Ok, try again after downloading new if_axe.c and let me know > >> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your > >> > console. > >> > >> never got to see that message. I saw the diff to previous version, and > >> did > >> boot into verbose mode (dmesg attached). there were just the belkin > >> gigabit nic on boot. after, the linksys USB200M: > >> > >> axe1: on usbus2 > >> axe1: PHYADDR 0xe0:0x10 > >> miibus2: on axe1 > >> ukphy1: PHY 16 on miibus2 > >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 > >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >> ue1: on axe1 > >> ue1: bpf attached > >> invalid media SR 0x700 > >> invalid media SR 0x700 > >> > > > > This is normal, the message I said will show up when you use > > gigabit controller, AX88178. This controller is fast ethernet > > controller, AX88772A. > > yes, I just tried to show that message with other nic. > > >> > >> and the other gigabit: > >> > >> ugen2.4: at usbus2 > >> axe2: on usbus2 > >> axe2: PHYADDR 0xe0:0x01 > >> miibus3: on axe2 > >> truephy1: PHY 1 on miibus3 > >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >> 1000baseT-FDX, > >> auto > >> ue2: on axe2 > >> ue2: bpf attached > >> ue2: Ethernet address: my mac here > >> ue2: link state changed to DOWN > >> > >> and never got to see the EEPROM message. > >> > > > > Two odd things here. This controller looks like Belkin F5D5055 and > > yes, it's this one. > > > it is gigabit controller. So it should print the message I > > mentioned in previous mail. Are you sure you rebuild/reboot your > > kernel? > > as usual, just rebuilt the axe module ... so I'm going to rebuild now. > this is a slow box, and might take a couple of hours. Will try to do it > also in a notebook running stable to speedup the process. > > > The second odd thing is now truephy(4) PHY driver is attached to > > your controller. Previously it was ukphy(4) generic PHY driver. > > This means accessing GMII is not reliable such that reading OUI of > > PHY changed its value. Maybe this could the reason why you see lots > > of link UP/DOWN messages since mii(4) periodically polls a register > > through GMII. If the register value read through GMII constantly > > changes it will cause all sorts of problems. > > I'm not sure whether this is axe(4) issue or USB stack issue. I > > also have Belkin F5D5055 controller and has no such problems so I > > guess it could be related with other parts of USB stack. > > > > To easily identify issues for a controller, it would be better to > > remove all other axe(4) controllers except one you want to test. > > ok, I was also testing that other issue. Will separate things from now on. > no problem using stable from October 7, right ? > Hmm, that depends on your environments. To test USB issues it would be better to use stable/8. > thanks, > > matheus ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 19:23, Pyun YongHyeon wrote: > On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote: > > [...] > >> > Ok, try again after downloading new if_axe.c and let me know >> > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your >> > console. >> >> never got to see that message. I saw the diff to previous version, and >> did >> boot into verbose mode (dmesg attached). there were just the belkin >> gigabit nic on boot. after, the linksys USB200M: >> >> axe1: on usbus2 >> axe1: PHYADDR 0xe0:0x10 >> miibus2: on axe1 >> ukphy1: PHY 16 on miibus2 >> ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ue1: on axe1 >> ue1: bpf attached >> invalid media SR 0x700 >> invalid media SR 0x700 >> > > This is normal, the message I said will show up when you use > gigabit controller, AX88178. This controller is fast ethernet > controller, AX88772A. yes, I just tried to show that message with other nic. >> >> and the other gigabit: >> >> ugen2.4: at usbus2 >> axe2: on usbus2 >> axe2: PHYADDR 0xe0:0x01 >> miibus3: on axe2 >> truephy1: PHY 1 on miibus3 >> truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT-FDX, >> auto >> ue2: on axe2 >> ue2: bpf attached >> ue2: Ethernet address: my mac here >> ue2: link state changed to DOWN >> >> and never got to see the EEPROM message. >> > > Two odd things here. This controller looks like Belkin F5D5055 and yes, it's this one. > it is gigabit controller. So it should print the message I > mentioned in previous mail. Are you sure you rebuild/reboot your > kernel? as usual, just rebuilt the axe module ... so I'm going to rebuild now. this is a slow box, and might take a couple of hours. Will try to do it also in a notebook running stable to speedup the process. > The second odd thing is now truephy(4) PHY driver is attached to > your controller. Previously it was ukphy(4) generic PHY driver. > This means accessing GMII is not reliable such that reading OUI of > PHY changed its value. Maybe this could the reason why you see lots > of link UP/DOWN messages since mii(4) periodically polls a register > through GMII. If the register value read through GMII constantly > changes it will cause all sorts of problems. > I'm not sure whether this is axe(4) issue or USB stack issue. I > also have Belkin F5D5055 controller and has no such problems so I > guess it could be related with other parts of USB stack. > > To easily identify issues for a controller, it would be better to > remove all other axe(4) controllers except one you want to test. ok, I was also testing that other issue. Will separate things from now on. no problem using stable from October 7, right ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, Nov 19, 2010 at 06:23:50PM -0200, Nenhum_de_Nos wrote: [...] > > Ok, try again after downloading new if_axe.c and let me know > > the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your > > console. > > never got to see that message. I saw the diff to previous version, and did > boot into verbose mode (dmesg attached). there were just the belkin > gigabit nic on boot. after, the linksys USB200M: > > axe1: on usbus2 > axe1: PHYADDR 0xe0:0x10 > miibus2: on axe1 > ukphy1: PHY 16 on miibus2 > ukphy1: OUI 0x000ec6, model 0x0001, rev. 1 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue1: on axe1 > ue1: bpf attached > invalid media SR 0x700 > invalid media SR 0x700 > This is normal, the message I said will show up when you use gigabit controller, AX88178. This controller is fast ethernet controller, AX88772A. > > and the other gigabit: > > ugen2.4: at usbus2 > axe2: on usbus2 > axe2: PHYADDR 0xe0:0x01 > miibus3: on axe2 > truephy1: PHY 1 on miibus3 > truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, > auto > ue2: on axe2 > ue2: bpf attached > ue2: Ethernet address: my mac here > ue2: link state changed to DOWN > > and never got to see the EEPROM message. > Two odd things here. This controller looks like Belkin F5D5055 and it is gigabit controller. So it should print the message I mentioned in previous mail. Are you sure you rebuild/reboot your kernel? The second odd thing is now truephy(4) PHY driver is attached to your controller. Previously it was ukphy(4) generic PHY driver. This means accessing GMII is not reliable such that reading OUI of PHY changed its value. Maybe this could the reason why you see lots of link UP/DOWN messages since mii(4) periodically polls a register through GMII. If the register value read through GMII constantly changes it will cause all sorts of problems. I'm not sure whether this is axe(4) issue or USB stack issue. I also have Belkin F5D5055 controller and has no such problems so I guess it could be related with other parts of USB stack. To easily identify issues for a controller, it would be better to remove all other axe(4) controllers except one you want to test. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/150546: commit references a PR
The following reply was made to PR usb/150546; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/150546: commit references a PR
Date: Fri, 19 Nov 2010 21:04:24 + (UTC)
Author: thompsa
Date: Fri Nov 19 21:04:18 2010
New Revision: 215546
URL: http://svn.freebsd.org/changeset/base/215546
Log:
MFC r213853
- Add missing LibUSB API functions:
* libusb_strerror()
* libusb_get_driver[_np]()
* libusb_detach_kernel_driver[_np]()
- Factor out setting of non-blocking flag inside libusb.
- Add missing NULL check after libusb_get_device() call.
- Correct some wrong error codes due to copy and paste error.
PR: usb/150546
Submitted by: Robert Jenssen, Alexander Leidinger
Modified:
stable/8/lib/libusb/libusb.3
stable/8/lib/libusb/libusb.h
stable/8/lib/libusb/libusb10.c
stable/8/lib/libusb/libusb20.3
Directory Properties:
stable/8/lib/libusb/ (props changed)
stable/8/lib/libusb/usb.h (props changed)
Modified: stable/8/lib/libusb/libusb.3
==
--- stable/8/lib/libusb/libusb.3 Fri Nov 19 20:23:01 2010
(r215545)
+++ stable/8/lib/libusb/libusb.3 Fri Nov 19 21:04:18 2010
(r215546)
@@ -26,7 +26,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd June 22, 2009
+.Dd October 14, 2010
.Dt LIBUSB 3
.Os
.Sh NAME
@@ -72,6 +72,15 @@ Deinitialise libusb. Must be called at t
.
.Pp
.
+.Ft const char *
+.Fn libusb_strerror "int code"
+Get ASCII representation of the error given by the
+.Fa code
+argument.
+.
+.
+.Pp
+.
.Ft void
.Fn libusb_set_debug "libusb_context *ctx" "int level"
Set debug to the
@@ -239,12 +248,37 @@ if the device has been disconnected and
.Pp
.
.Ft int
+.Fn libusb_get_driver "libusb_device_handle *devh" "int interface" "char
*name" "int namelen"
+or
+.Ft int
+.Fn libusb_get_driver_np "libusb_device_handle *devh" "int interface" "char
*name" "int namelen"
+Gets the name of the driver attached to the given
+.Fa device
+and
+.Fa interface
+into the buffer given by
+.Fa name
+and
+.Fa namelen .
+Returns 0 on success, LIBUSB_ERROR_NOT_FOUND if no kernel driver is attached
+to the given interface and LIBUSB_ERROR_INVALID_PARAM if the interface does
+not exist.
+This function is non-portable.
+The buffer pointed to by
+.Fa name
+is only zero terminated on success.
+.
+.Pp
+.
+.Ft int
.Fn libusb_detach_kernel_driver "libusb_device_handle *devh" "int interface"
-Detach a kernel driver from an interface. This is needed to claim an interface
-required by a kernel driver. Returns 0 on success, LIBUSB_ERROR_NOT_FOUND if
-no kernel driver was active, LIBUSB_ERROR_INVALID_PARAM if the interface does
not
-exist, LIBUSB_ERROR_NO_DEVICE if the device has been disconnected and a
-LIBUSB_ERROR code on failure.
+or
+.Ft int
+.Fn libusb_detach_kernel_driver_np "libusb_device_handle *devh" "int
interface"
+Detach a kernel driver from an interface.
+This is needed to claim an interface required by a kernel driver.
+Returns 0 on success, LIBUSB_ERROR_NOT_FOUND if no kernel driver was active,
+LIBUSB_ERROR_INVALID_PARAM if the interface does not exist,
LIBUSB_ERROR_NO_DEVICE if the device has been disconnected and a LIBUSB_ERROR
code on failure. This function is non-portable.
.
.Pp
.
@@ -271,7 +305,7 @@ failure.
.
.Pp
.Ft int
-.Fn libsub_get_active_config_descriptor "libusb_device *dev"
"libusb_device_descriptor **config"
+.Fn libsub_get_active_config_descriptor "libusb_device *dev" "struct
libusb_config_descriptor **config"
Get the USB configuration descriptor for the active configuration. Returns 0
on
success, returns LIBUSB_ERROR_NOT_FOUND if the device is in unconfigured
state
and return another LIBUSB_ERROR code on error.
@@ -337,7 +371,7 @@ LIBUSB_ERROR code on failure.
.
.Pp
.Ft int
-.Fn libusb_control_transfer "libusb_device_handle *devh" "uint8_t
bmRequestType" "uint16_t wIndex" "unsigned char *data" "uint16_t wLength"
"unsigned int timeout"
+.Fn libusb_control_transfer "libusb_device_handle *devh" "uint8_t
bmRequestType" "uint8_t bRequest" "uint16_t wValue" "uint16_t wIndex" "unsigned
char *data" "uint16_t wLength" "unsigned int timeout"
Perform a USB control transfer. Returns 0 on success, LIBUSB_ERROR_TIMEOUT
if the transfer timeout, LIBUSB_ERROR_PIPE if the control request was not
supported, LIBUSB_ERROR_NO_DEVICE if the device has been disconnected and
Modified: stable/8/lib/libusb/libusb.h
==
--- stable/8/lib/libusb/libusb.h Fri Nov 19 20:23:01 2010
(r215545)
+++ stable/8/lib/libusb/libusb.h Fri Nov 19 21:04:18 2010
(r215546)
@@ -294,6 +294,7 @@ typedef struct libusb_transfer {
/* Library initialisation */
void libusb_set_
Re: copying /dev/da0 with dd(1) to file: output differs
El día Friday, November 19, 2010 a las 12:39:13PM -0700, Warren Block escribió: > > Just an idea: The USB key in question was new and I only created the > > file system on it the usual way (fdisk, bsdlabel, newfs). Then I > > restored the dump on it (which took 26 hours for 3.1 GByte dump file). > > The USB key boots fine, btw. > > 26 *hours*? USB 1.1? I don't think so. It is the Acer One D250 netbook. > Well, they could be anything. But the original filesystem has > formerly-used blocks with old data from deleted files. dump doesn't > copy those, but dd does. > > > Should I overwrite the full USB key from /dev/zero? > > Possibly there would still be differences. Filesystem metadata like > date last mounted, for example. If you want a block-by-block duplicate, > the brute-force method is to just dd the whole drive. Use bs=64k or > bs=1m to help reduce overhead. Warren, perhaps you missed my point. I have a prepared boot-able key and I want to give away a copy of it as a file on DVD. So I dd(1)'ed the key to disk and did this twice to ensure that the copy was fine, but the two files differ. How can I make sure that the file on disk (or DVD) is a exact copy of the key? matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Two questions: how to specify module-load function for driver module and which name of driver is better (according to "standards")
Hello, Paul. You wrote 19 ноября 2010 г., 19:56:26: > Is it possible/sane to integrate two drivers in one? No, they are almost totally different. -- // Black Lion AKA Lev Serebryakov ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 17:27, Pyun YongHyeon wrote: > On Fri, Nov 19, 2010 at 04:23:20PM -0200, Nenhum_de_Nos wrote: >> >> On Fri, November 19, 2010 15:13, Pyun YongHyeon wrote: >> > On Fri, Nov 19, 2010 at 03:19:26AM -0200, Nenhum_de_Nos wrote: >> >> >> >> On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: >> >> > On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: >> >> >> >> >> >> On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: >> >> >> > On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: >> >> >> >> >> >> >> >> On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: >> >> >> >> > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos >> wrote: >> >> >> >> >> >> >> >> >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote: >> >> >> >> >> > The following reply was made to PR usb/140883; it has been >> >> noted >> >> >> by >> >> >> >> >> GNATS. >> >> >> >> >> > >> >> >> >> >> > From: Derrick Brashear >> >> >> >> >> > To: bug-follo...@freebsd.org, sub.m...@gmail.com >> >> >> >> >> > Cc: >> >> >> >> >> > Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet >> >> hangs >> >> >> >> after >> >> >> >> >> > short >> >> >> >> >> > period of traffic >> >> >> >> >> > Date: Thu, 18 Nov 2010 09:36:50 -0500 >> >> >> >> >> > >> >> >> >> >> > Pyun has provided an updated driver which avoids several >> >> issues >> >> >> >> >> > including using a too-large transmit buffer (the chipset >> >> claims >> >> >> >> only >> >> >> >> >> > 8k) but none of the fixes worked until he disabled frame >> >> >> combining >> >> >> >> >> for >> >> >> >> >> > transmit. With only a single packet being sent per frame >> (as >> >> >> was >> >> >> >> the >> >> >> >> >> > case in FreeBSD 7, apparently) seems to make the issue go >> >> away. >> >> >> >> None >> >> >> >> >> > of the cases I could use to reproduce the issue now >> happen. >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > Derrick >> >> >> >> >> >> >> >> >> >> is this already in 8-stable ? I have a couple of axe(4) >> based >> >> >> nic's >> >> >> >> >> they're not ok on 8-stable. I've talked to Pyun before, and >> >> that >> >> >> time >> >> >> >> >> seemed do solve the issue (with gigabit belkin axe based) >> but >> >> now >> >> >> I >> >> >> >> >> can't >> >> >> >> >> get them to work anymore. even fast ethernet linksys axe are >> >> just >> >> >> >> dying >> >> >> >> >> when in a bridge (switched to OpenBSD to have it working). >> >> >> >> >> >> >> >> >> >> how ca I try this to help ? >> >> >> >> >> >> >> >> >> > >> >> >> >> > I uploaded updated if_axe.c/if_axereg.h to the following URL. >> >> >> >> > http://people.freebsd.org/~yongari/axe/if_axe.c >> >> >> >> > http://people.freebsd.org/~yongari/axe/if_axereg.h >> >> >> >> > >> >> >> >> > That files seem to fix axe(4) hang which were seen on >> AX88772A >> >> >> >> > controller. One of most notable changes are removing >> combining >> >> >> >> > multiple TX frames in TX path such that this change may >> result >> >> in >> >> >> >> > sub-optimal performance for most axe(4) controllers. However >> it >> >> >> >> > seems that change makes Derrick's controller work without >> >> problems. >> >> >> >> > Generally I prefer driver stability over performance so if >> this >> >> >> >> > change also fixes other axe(4) stability issues reported so >> far, >> >> I >> >> >> >> > want to check in the change. >> >> >> >> > >> >> >> >> > Thanks. >> >> >> >> >> >> >> >> well, >> >> >> >> >> >> >> >> things did got better here. but the link state UP and DOWN are >> >> still >> >> >> >> there :( >> >> >> >> >> >> >> >> ugen2.3: at usbus2 >> >> >> >> axe1: on >> >> usbus2 >> >> >> >> axe1: PHYADDR 0xe0:0x01 >> >> >> >> miibus2: on axe1 >> >> >> >> ukphy2: PHY 1 on miibus2 >> >> >> >> ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> >> 1000baseT, >> >> >> > ^ >> >> >> >> 1000baseT-FD >> >> >> >> X, auto >> >> >> > >> >> >> > It seems you have PHY driver issue. Normally all gigabit PHYs >> >> >> > should have their own PHY driver since most PHYs hardwares tend >> to >> >> >> > have a special register that reports link state changes. >> >> >> > Show me the output of "devinfo -rv | grep phy". >> >> >> >> >> >> there you are: >> >> >> >> >> >> devinfo -rv|grep phy >> >> >> ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at >> >> phyno=16 >> >> >> ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at >> >> >> phyno=1 >> >> >> ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at >> phyno=1 >> >> >> >> >> > >> >> > Hmm You have many ukphys there. :-) I think the PHY attached to >> >> > the USB controller is ukphy2. The OUI indicates its maker is ASIX. >> >> > Unfortunately there is no dedicated PHY driver for this PHY. I >> >> > guess it may use a modified CICADA PHY though. Updated driver to >> >> > force GPIO configuration for this PHY. Would you try again afte
Re: copying /dev/da0 with dd(1) to file: output differs
On Fri, 19 Nov 2010, Matthias Apitz wrote: El d?a Friday, November 19, 2010 a las 07:16:53PM +0100, Hans Petter Selasky escribi?: I was thinking in a tool just reading each file block by block, comparing the blocks and noting the 1st diff with block offset number. (some 10 lines of C code :-)) matthias Maybe you need to write a small C-program to do that. You can use bcmp() to compare two buffers. Will do that tomorrow. Just an idea: The USB key in question was new and I only created the file system on it the usual way (fdisk, bsdlabel, newfs). Then I restored the dump on it (which took 26 hours for 3.1 GByte dump file). The USB key boots fine, btw. 26 *hours*? USB 1.1? Could it be that unwritten/unformatted blocks are read as random data from that USB key? Well, they could be anything. But the original filesystem has formerly-used blocks with old data from deleted files. dump doesn't copy those, but dd does. Should I overwrite the full USB key from /dev/zero? Possibly there would still be differences. Filesystem metadata like date last mounted, for example. If you want a block-by-block duplicate, the brute-force method is to just dd the whole drive. Use bs=64k or bs=1m to help reduce overhead. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, Nov 19, 2010 at 04:23:20PM -0200, Nenhum_de_Nos wrote: > > On Fri, November 19, 2010 15:13, Pyun YongHyeon wrote: > > On Fri, Nov 19, 2010 at 03:19:26AM -0200, Nenhum_de_Nos wrote: > >> > >> On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: > >> > On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: > >> >> > >> >> On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: > >> >> > On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: > >> >> >> > >> >> >> On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: > >> >> >> > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: > >> >> >> >> > >> >> >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote: > >> >> >> >> > The following reply was made to PR usb/140883; it has been > >> noted > >> >> by > >> >> >> >> GNATS. > >> >> >> >> > > >> >> >> >> > From: Derrick Brashear > >> >> >> >> > To: bug-follo...@freebsd.org, sub.m...@gmail.com > >> >> >> >> > Cc: > >> >> >> >> > Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet > >> hangs > >> >> >> after > >> >> >> >> > short > >> >> >> >> > period of traffic > >> >> >> >> > Date: Thu, 18 Nov 2010 09:36:50 -0500 > >> >> >> >> > > >> >> >> >> > Pyun has provided an updated driver which avoids several > >> issues > >> >> >> >> > including using a too-large transmit buffer (the chipset > >> claims > >> >> >> only > >> >> >> >> > 8k) but none of the fixes worked until he disabled frame > >> >> combining > >> >> >> >> for > >> >> >> >> > transmit. With only a single packet being sent per frame (as > >> >> was > >> >> >> the > >> >> >> >> > case in FreeBSD 7, apparently) seems to make the issue go > >> away. > >> >> >> None > >> >> >> >> > of the cases I could use to reproduce the issue now happen. > >> >> >> >> > > >> >> >> >> > -- > >> >> >> >> > Derrick > >> >> >> >> > >> >> >> >> is this already in 8-stable ? I have a couple of axe(4) based > >> >> nic's > >> >> >> >> they're not ok on 8-stable. I've talked to Pyun before, and > >> that > >> >> time > >> >> >> >> seemed do solve the issue (with gigabit belkin axe based) but > >> now > >> >> I > >> >> >> >> can't > >> >> >> >> get them to work anymore. even fast ethernet linksys axe are > >> just > >> >> >> dying > >> >> >> >> when in a bridge (switched to OpenBSD to have it working). > >> >> >> >> > >> >> >> >> how ca I try this to help ? > >> >> >> >> > >> >> >> > > >> >> >> > I uploaded updated if_axe.c/if_axereg.h to the following URL. > >> >> >> > http://people.freebsd.org/~yongari/axe/if_axe.c > >> >> >> > http://people.freebsd.org/~yongari/axe/if_axereg.h > >> >> >> > > >> >> >> > That files seem to fix axe(4) hang which were seen on AX88772A > >> >> >> > controller. One of most notable changes are removing combining > >> >> >> > multiple TX frames in TX path such that this change may result > >> in > >> >> >> > sub-optimal performance for most axe(4) controllers. However it > >> >> >> > seems that change makes Derrick's controller work without > >> problems. > >> >> >> > Generally I prefer driver stability over performance so if this > >> >> >> > change also fixes other axe(4) stability issues reported so far, > >> I > >> >> >> > want to check in the change. > >> >> >> > > >> >> >> > Thanks. > >> >> >> > >> >> >> well, > >> >> >> > >> >> >> things did got better here. but the link state UP and DOWN are > >> still > >> >> >> there :( > >> >> >> > >> >> >> ugen2.3: at usbus2 > >> >> >> axe1: on > >> usbus2 > >> >> >> axe1: PHYADDR 0xe0:0x01 > >> >> >> miibus2: on axe1 > >> >> >> ukphy2: PHY 1 on miibus2 > >> >> >> ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >> 1000baseT, > >> >> > ^ > >> >> >> 1000baseT-FD > >> >> >> X, auto > >> >> > > >> >> > It seems you have PHY driver issue. Normally all gigabit PHYs > >> >> > should have their own PHY driver since most PHYs hardwares tend to > >> >> > have a special register that reports link state changes. > >> >> > Show me the output of "devinfo -rv | grep phy". > >> >> > >> >> there you are: > >> >> > >> >> devinfo -rv|grep phy > >> >> ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at > >> phyno=16 > >> >> ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at > >> >> phyno=1 > >> >> ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1 > >> >> > >> > > >> > Hmm You have many ukphys there. :-) I think the PHY attached to > >> > the USB controller is ukphy2. The OUI indicates its maker is ASIX. > >> > Unfortunately there is no dedicated PHY driver for this PHY. I > >> > guess it may use a modified CICADA PHY though. Updated driver to > >> > force GPIO configuration for this PHY. Would you try again after > >> > downloading if_axe.c/if_axereg.h? It may show > >> > "unknown PHY mode : 0xXX" if my guess is wrong. > > back to this, no problem of unknown PHY: > > ugen2.2: at usbus2 > axe0: on usbus2 > axe0: PHYADDR
Re: copying /dev/da0 with dd(1) to file: output differs
On 19.11.2010 20:39, Matthias Apitz wrote: El día Friday, November 19, 2010 a las 07:16:53PM +0100, Hans Petter Selasky escribió: I was thinking in a tool just reading each file block by block, comparing the blocks and noting the 1st diff with block offset number. (some 10 lines of C code :-)) matthias Maybe you need to write a small C-program to do that. You can use bcmp() to compare two buffers. Will do that tomorrow. Just an idea: The USB key in question was new and I only created the file system on it the usual way (fdisk, bsdlabel, newfs). Then I restored the dump on it (which took 26 hours for 3.1 GByte dump file). The USB key boots fine, btw. Could it be that unwritten/unformatted blocks are read as random data from that USB key? Should I overwrite the full USB key from /dev/zero? It is allowed behavior for SATA SSDs with TRIM command support. Deleted blocks can be not guarantied to return any predictable or even repeatable value. May be this logic could be extended to USB devices. -- Alexander Motin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: copying /dev/da0 with dd(1) to file: output differs
El día Friday, November 19, 2010 a las 07:16:53PM +0100, Hans Petter Selasky escribió: > > I was thinking in a tool just reading each file block by block, > > comparing the blocks and noting the 1st diff with block offset number. > > (some 10 lines of C code :-)) > > > > matthias > > Maybe you need to write a small C-program to do that. > > You can use bcmp() to compare two buffers. Will do that tomorrow. Just an idea: The USB key in question was new and I only created the file system on it the usual way (fdisk, bsdlabel, newfs). Then I restored the dump on it (which took 26 hours for 3.1 GByte dump file). The USB key boots fine, btw. Could it be that unwritten/unformatted blocks are read as random data from that USB key? Should I overwrite the full USB key from /dev/zero? matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, November 19, 2010 15:13, Pyun YongHyeon wrote: > On Fri, Nov 19, 2010 at 03:19:26AM -0200, Nenhum_de_Nos wrote: >> >> On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: >> > On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: >> >> >> >> On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: >> >> > On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: >> >> >> >> >> >> On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: >> >> >> > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: >> >> >> >> >> >> >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote: >> >> >> >> > The following reply was made to PR usb/140883; it has been >> noted >> >> by >> >> >> >> GNATS. >> >> >> >> > >> >> >> >> > From: Derrick Brashear >> >> >> >> > To: bug-follo...@freebsd.org, sub.m...@gmail.com >> >> >> >> > Cc: >> >> >> >> > Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet >> hangs >> >> >> after >> >> >> >> > short >> >> >> >> > period of traffic >> >> >> >> > Date: Thu, 18 Nov 2010 09:36:50 -0500 >> >> >> >> > >> >> >> >> > Pyun has provided an updated driver which avoids several >> issues >> >> >> >> > including using a too-large transmit buffer (the chipset >> claims >> >> >> only >> >> >> >> > 8k) but none of the fixes worked until he disabled frame >> >> combining >> >> >> >> for >> >> >> >> > transmit. With only a single packet being sent per frame (as >> >> was >> >> >> the >> >> >> >> > case in FreeBSD 7, apparently) seems to make the issue go >> away. >> >> >> None >> >> >> >> > of the cases I could use to reproduce the issue now happen. >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Derrick >> >> >> >> >> >> >> >> is this already in 8-stable ? I have a couple of axe(4) based >> >> nic's >> >> >> >> they're not ok on 8-stable. I've talked to Pyun before, and >> that >> >> time >> >> >> >> seemed do solve the issue (with gigabit belkin axe based) but >> now >> >> I >> >> >> >> can't >> >> >> >> get them to work anymore. even fast ethernet linksys axe are >> just >> >> >> dying >> >> >> >> when in a bridge (switched to OpenBSD to have it working). >> >> >> >> >> >> >> >> how ca I try this to help ? >> >> >> >> >> >> >> > >> >> >> > I uploaded updated if_axe.c/if_axereg.h to the following URL. >> >> >> > http://people.freebsd.org/~yongari/axe/if_axe.c >> >> >> > http://people.freebsd.org/~yongari/axe/if_axereg.h >> >> >> > >> >> >> > That files seem to fix axe(4) hang which were seen on AX88772A >> >> >> > controller. One of most notable changes are removing combining >> >> >> > multiple TX frames in TX path such that this change may result >> in >> >> >> > sub-optimal performance for most axe(4) controllers. However it >> >> >> > seems that change makes Derrick's controller work without >> problems. >> >> >> > Generally I prefer driver stability over performance so if this >> >> >> > change also fixes other axe(4) stability issues reported so far, >> I >> >> >> > want to check in the change. >> >> >> > >> >> >> > Thanks. >> >> >> >> >> >> well, >> >> >> >> >> >> things did got better here. but the link state UP and DOWN are >> still >> >> >> there :( >> >> >> >> >> >> ugen2.3: at usbus2 >> >> >> axe1: on >> usbus2 >> >> >> axe1: PHYADDR 0xe0:0x01 >> >> >> miibus2: on axe1 >> >> >> ukphy2: PHY 1 on miibus2 >> >> >> ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT, >> >> > ^ >> >> >> 1000baseT-FD >> >> >> X, auto >> >> > >> >> > It seems you have PHY driver issue. Normally all gigabit PHYs >> >> > should have their own PHY driver since most PHYs hardwares tend to >> >> > have a special register that reports link state changes. >> >> > Show me the output of "devinfo -rv | grep phy". >> >> >> >> there you are: >> >> >> >> devinfo -rv|grep phy >> >> ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at >> phyno=16 >> >> ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at >> >> phyno=1 >> >> ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1 >> >> >> > >> > Hmm You have many ukphys there. :-) I think the PHY attached to >> > the USB controller is ukphy2. The OUI indicates its maker is ASIX. >> > Unfortunately there is no dedicated PHY driver for this PHY. I >> > guess it may use a modified CICADA PHY though. Updated driver to >> > force GPIO configuration for this PHY. Would you try again after >> > downloading if_axe.c/if_axereg.h? It may show >> > "unknown PHY mode : 0xXX" if my guess is wrong. back to this, no problem of unknown PHY: ugen2.2: at usbus2 axe0: on usbus2 axe0: PHYADDR 0xe0:0x10 Root mount waiting for: usbus2 miibus1: on axe0 ukphy1: PHY 16 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on axe0 ue0: Ethernet address: my mac here ugen2.3: at usbus2 axe1: on usbus2 axe1: PHYADDR 0xe0:0x01 Trying to mount root from ufs:/dev/ad0s3a miibus2: on axe1 ukp
Re: copying /dev/da0 with dd(1) to file: output differs
On Friday 19 November 2010 18:35:19 Matthias Apitz wrote: > El día Friday, November 19, 2010 a las 06:21:09PM +0100, Hans Petter Selasky escribió: > > > > Can you dump the data into hex using hexdump -C and show us the > > > > difference. > > > > > > Note: the output of the dd(1) is around 3.8 GByte. I compared the 1st > > > 2.000.000 lines of the hexdump: no diff; any better tool to show the > > > 1st block which differs? > > > > > > > Usually you would use bs=65536 (Does that change anything)? > > > > > > Same result: they differ :-( > > > > > > matthias > > > > bsdiff ? > > This will not work with such big files (requires 8x memory of the file): > > I was thinking in a tool just reading each file block by block, > comparing the blocks and noting the 1st diff with block offset number. > (some 10 lines of C code :-)) > > matthias Maybe you need to write a small C-program to do that. You can use bcmp() to compare two buffers. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: copying /dev/da0 with dd(1) to file: output differs
El día Friday, November 19, 2010 a las 06:21:09PM +0100, Hans Petter Selasky escribió: > > > Can you dump the data into hex using hexdump -C and show us the > > > difference. > > > > Note: the output of the dd(1) is around 3.8 GByte. I compared the 1st > > 2.000.000 lines of the hexdump: no diff; any better tool to show the 1st > > block which differs? > > > > > Usually you would use bs=65536 (Does that change anything)? > > > > Same result: they differ :-( > > > > matthias > > bsdiff ? This will not work with such big files (requires 8x memory of the file): I was thinking in a tool just reading each file block by block, comparing the blocks and noting the 1st diff with block offset number. (some 10 lines of C code :-)) matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Two questions: how to specify module-load function for driver module and which name of driver is better (according to "standards")
2010/11/19 Hans Petter Selasky : > On Friday 19 November 2010 16:55:27 Lev Serebryakov wrote: >> Hello, Freebsd-usb. >> >> I've implemented driver (ucom-subdriver) for MosChip 7820 and 7840 >> USB2COM multiport bridges. I have two questions: >> > > Hi, > >> (1) How should I specify module-load function? DRIVER_MODULE() >> doesn't help much. I need to run some code only once, at very >> beginning, not for each probe/attach. GEOM modules have methods for >> it, but I can not find such methods for drivers. > > Look at ubt_modevent in sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c. Or use a > so-called SYSINIT() or SYSUNINIT(). > >> >> (2) Which name should I choose? Working name of module/driver/device >> is "mos7840", but it seems, that it is bad name: >> (a) All existing ucom-based drivers is "uXXXcom" >> (b) Driver instances looks ugly (like "mos78400") > umos78400 ? > >> >> Is "umos7840com" good name or it is too long? :) We have "umoscom" >> driver for older MosChip chip in base already. > > Maybe someone else has some comments. Is it possible/sane to integrate two drivers in one? ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: copying /dev/da0 with dd(1) to file: output differs
On Friday 19 November 2010 18:02:59 Matthias Apitz wrote: > El día Friday, November 19, 2010 a las 03:37:25PM +0100, Hans Petter Selasky escribió: > > On Friday 19 November 2010 15:33:37 Matthias Apitz wrote: > > > Hello, > > > > > > How is this possible: > > > > > > $ dd if=/dev/da0 of=f1 > > > 7892087+0 records in > > > 7892087+0 records out > > > $ dd if=/dev/da0 of=f2 > > > 7892087+0 records in > > > 7892087+0 records out > > > $ diff f1 f1 > > > Files f1 and f2 differ > > > > > > (and no, /dev/da0s1a is not mounted). > > > > > > Thx > > > > > > matthias > > > > Hi, > > > > Can you dump the data into hex using hexdump -C and show us the > > difference. > > Note: the output of the dd(1) is around 3.8 GByte. I compared the 1st > 2.000.000 lines of the hexdump: no diff; any better tool to show the 1st > block which differs? > > > Usually you would use bs=65536 (Does that change anything)? > > Same result: they differ :-( > > matthias bsdiff ? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic
On Fri, Nov 19, 2010 at 03:19:26AM -0200, Nenhum_de_Nos wrote: > > On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote: > > On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote: > >> > >> On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote: > >> > On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote: > >> >> > >> >> On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote: > >> >> > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos wrote: > >> >> >> > >> >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote: > >> >> >> > The following reply was made to PR usb/140883; it has been noted > >> by > >> >> >> GNATS. > >> >> >> > > >> >> >> > From: Derrick Brashear > >> >> >> > To: bug-follo...@freebsd.org, sub.m...@gmail.com > >> >> >> > Cc: > >> >> >> > Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs > >> >> after > >> >> >> > short > >> >> >> > period of traffic > >> >> >> > Date: Thu, 18 Nov 2010 09:36:50 -0500 > >> >> >> > > >> >> >> > Pyun has provided an updated driver which avoids several issues > >> >> >> > including using a too-large transmit buffer (the chipset claims > >> >> only > >> >> >> > 8k) but none of the fixes worked until he disabled frame > >> combining > >> >> >> for > >> >> >> > transmit. With only a single packet being sent per frame (as > >> was > >> >> the > >> >> >> > case in FreeBSD 7, apparently) seems to make the issue go away. > >> >> None > >> >> >> > of the cases I could use to reproduce the issue now happen. > >> >> >> > > >> >> >> > -- > >> >> >> > Derrick > >> >> >> > >> >> >> is this already in 8-stable ? I have a couple of axe(4) based > >> nic's > >> >> >> they're not ok on 8-stable. I've talked to Pyun before, and that > >> time > >> >> >> seemed do solve the issue (with gigabit belkin axe based) but now > >> I > >> >> >> can't > >> >> >> get them to work anymore. even fast ethernet linksys axe are just > >> >> dying > >> >> >> when in a bridge (switched to OpenBSD to have it working). > >> >> >> > >> >> >> how ca I try this to help ? > >> >> >> > >> >> > > >> >> > I uploaded updated if_axe.c/if_axereg.h to the following URL. > >> >> > http://people.freebsd.org/~yongari/axe/if_axe.c > >> >> > http://people.freebsd.org/~yongari/axe/if_axereg.h > >> >> > > >> >> > That files seem to fix axe(4) hang which were seen on AX88772A > >> >> > controller. One of most notable changes are removing combining > >> >> > multiple TX frames in TX path such that this change may result in > >> >> > sub-optimal performance for most axe(4) controllers. However it > >> >> > seems that change makes Derrick's controller work without problems. > >> >> > Generally I prefer driver stability over performance so if this > >> >> > change also fixes other axe(4) stability issues reported so far, I > >> >> > want to check in the change. > >> >> > > >> >> > Thanks. > >> >> > >> >> well, > >> >> > >> >> things did got better here. but the link state UP and DOWN are still > >> >> there :( > >> >> > >> >> ugen2.3: at usbus2 > >> >> axe1: on usbus2 > >> >> axe1: PHYADDR 0xe0:0x01 > >> >> miibus2: on axe1 > >> >> ukphy2: PHY 1 on miibus2 > >> >> ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > >> > ^ > >> >> 1000baseT-FD > >> >> X, auto > >> > > >> > It seems you have PHY driver issue. Normally all gigabit PHYs > >> > should have their own PHY driver since most PHYs hardwares tend to > >> > have a special register that reports link state changes. > >> > Show me the output of "devinfo -rv | grep phy". > >> > >> there you are: > >> > >> devinfo -rv|grep phy > >> ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 > >> ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at > >> phyno=1 > >> ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1 > >> > > > > Hmm You have many ukphys there. :-) I think the PHY attached to > > the USB controller is ukphy2. The OUI indicates its maker is ASIX. > > Unfortunately there is no dedicated PHY driver for this PHY. I > > guess it may use a modified CICADA PHY though. Updated driver to > > force GPIO configuration for this PHY. Would you try again after > > downloading if_axe.c/if_axereg.h? It may show > > "unknown PHY mode : 0xXX" if my guess is wrong. > > I downloaded again from above links and are the same as the last: > > valfenda# md5 if_axe* > MD5 (if_axe.c) = 388b7aa84f0d2471f8b144033103618b > MD5 (if_axe.c.original) = c528c7cb5eb964a792d4c14dfaed47cf > MD5 (if_axe.c.v1) = 388b7aa84f0d2471f8b144033103618b > MD5 (if_axereg.h) = 10f85490cab59b8e40de261fd7ad81a5 > MD5 (if_axereg.h.original) = 46f37d0f02a3c09463ceec58b743c6ce > MD5 (if_axereg.h.v1) = 10f85490cab59b8e40de261fd7ad81a5 > > .original are files from 8-stable (via csup) > .v1 are the files from http://people.freebsd.org/~yongari/axe/ downloaded > when the fist test using those files were made. > r
Re: copying /dev/da0 with dd(1) to file: output differs
El día Friday, November 19, 2010 a las 03:37:25PM +0100, Hans Petter Selasky escribió: > On Friday 19 November 2010 15:33:37 Matthias Apitz wrote: > > Hello, > > > > How is this possible: > > > > $ dd if=/dev/da0 of=f1 > > 7892087+0 records in > > 7892087+0 records out > > $ dd if=/dev/da0 of=f2 > > 7892087+0 records in > > 7892087+0 records out > > $ diff f1 f1 > > Files f1 and f2 differ > > > > (and no, /dev/da0s1a is not mounted). > > > > Thx > > > > matthias > > Hi, > > Can you dump the data into hex using hexdump -C and show us the difference. Note: the output of the dd(1) is around 3.8 GByte. I compared the 1st 2.000.000 lines of the hexdump: no diff; any better tool to show the 1st block which differs? > Usually you would use bs=65536 (Does that change anything)? Same result: they differ :-( matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Two questions: how to specify module-load function for driver module and which name of driver is better (according to "standards")
on 19/11/2010 17:55 Lev Serebryakov said the following: > Hello, Freebsd-usb. > > I've implemented driver (ucom-subdriver) for MosChip 7820 and 7840 > USB2COM multiport bridges. I have two questions: > > (1) How should I specify module-load function? DRIVER_MODULE() > doesn't help much. Are you sure? The last two arguments to DRIVER_MODULE() look like what you want. > I need to run some code only once, at very > beginning, not for each probe/attach. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Two questions: how to specify module-load function for driver module and which name of driver is better (according to "standards")
Hello, Andriy. You wrote 19 ноября 2010 г., 19:29:35: >> I've implemented driver (ucom-subdriver) for MosChip 7820 and 7840 >> USB2COM multiport bridges. I have two questions: >> >> (1) How should I specify module-load function? DRIVER_MODULE() >> doesn't help much. > Are you sure? > The last two arguments to DRIVER_MODULE() look like what you want. Yes, it my fault, it works after hint from Hans Petter Selasky. -- // Black Lion AKA Lev Serebryakov ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Two questions: how to specify module-load function for driver module and which name of driver is better (according to "standards")
On Friday 19 November 2010 16:55:27 Lev Serebryakov wrote: > Hello, Freebsd-usb. > > I've implemented driver (ucom-subdriver) for MosChip 7820 and 7840 > USB2COM multiport bridges. I have two questions: > Hi, > (1) How should I specify module-load function? DRIVER_MODULE() > doesn't help much. I need to run some code only once, at very > beginning, not for each probe/attach. GEOM modules have methods for > it, but I can not find such methods for drivers. Look at ubt_modevent in sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c. Or use a so-called SYSINIT() or SYSUNINIT(). > > (2) Which name should I choose? Working name of module/driver/device > is "mos7840", but it seems, that it is bad name: >(a) All existing ucom-based drivers is "uXXXcom" >(b) Driver instances looks ugly (like "mos78400") umos78400 ? > > Is "umos7840com" good name or it is too long? :) We have "umoscom" > driver for older MosChip chip in base already. Maybe someone else has some comments. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Two questions: how to specify module-load function for driver module and which name of driver is better (according to "standards")
Hello, Freebsd-usb. I've implemented driver (ucom-subdriver) for MosChip 7820 and 7840 USB2COM multiport bridges. I have two questions: (1) How should I specify module-load function? DRIVER_MODULE() doesn't help much. I need to run some code only once, at very beginning, not for each probe/attach. GEOM modules have methods for it, but I can not find such methods for drivers. (2) Which name should I choose? Working name of module/driver/device is "mos7840", but it seems, that it is bad name: (a) All existing ucom-based drivers is "uXXXcom" (b) Driver instances looks ugly (like "mos78400") Is "umos7840com" good name or it is too long? :) We have "umoscom" driver for older MosChip chip in base already. -- // Black Lion AKA Lev Serebryakov ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: copying /dev/da0 with dd(1) to file: output differs
On Friday 19 November 2010 15:33:37 Matthias Apitz wrote: > Hello, > > How is this possible: > > $ dd if=/dev/da0 of=f1 > 7892087+0 records in > 7892087+0 records out > $ dd if=/dev/da0 of=f2 > 7892087+0 records in > 7892087+0 records out > $ diff f1 f1 > Files f1 and f2 differ > > (and no, /dev/da0s1a is not mounted). > > Thx > > matthias Hi, Can you dump the data into hex using hexdump -C and show us the difference. Usually you would use bs=65536 (Does that change anything)? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
copying /dev/da0 with dd(1) to file: output differs
Hello, How is this possible: $ dd if=/dev/da0 of=f1 7892087+0 records in 7892087+0 records out $ dd if=/dev/da0 of=f2 7892087+0 records in 7892087+0 records out $ diff f1 f1 Files f1 and f2 differ (and no, /dev/da0s1a is not mounted). Thx matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
