Bug#704242: Driver for PL-2303 HX not working
On Sat, Apr 20, 2013 at 09:50:52AM +0200, Karsten Malcher wrote: Am 19.04.2013 16:39, schrieb Johan Hovold: Then the problem is most likely not in the driver as the characters are being read back in the log you provided. Stop - it's really possible that i send not enough bytes. Sometimes up to 6 Bytes will come back. This time i send this string (3.2.0): 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n I get back the first 3 Bytes of it. Log is attached. Was it really the same log? In the log below there is an error reported but it looks like no data at all is returned: No - this are of course different tests and different logs. Sorry - it's possible that there where no bytes read back in this particular test. I added exact output to my script now. Here are two additional tests with 50 bytes (3.2.0). In sendtest50get2.log i definitely read 2 Bytes back. Yes, in the logs 2 and 4 bytes respectively is received before the same hardware related error EILSEQ (-84) is received. [ 1443.122568] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback - nonzero read bulk status received: -84 Either way, the error is EILSEQ (-84) which usually indicates hardware problems. Maybe this time not plugged in perfectly. This cheap connectors are sometimes not reliable. It's the same connecting an external harddisk - sometimes you have a bad connection. There are 2 beasty questions left: 1. Why it works with PL2303H ? Different device, different hardware. But it's the same driver or not? Yes, same driver. 2. Why i receive sometimes the first bytes? Your particular device could be flakey and sometimes you're able to read a few bytes. The new logs seem to support this. Sorry - i don't think so. 1. It works perfect with kernel 2.6.32 2. It works perfect using windows with the driver from Profilic 3. I have 2 devices of this type and the behaviour is exact the same All three could be explained by flakey hardware. The 2.6.32 driver and possibly the Windows driver could be inefficient enough not to trigger the problem as reliably as the current Linux driver do. You did say it was a pirate chip, right? In the debian bug tracker someone also mentioned having an HX device with the exact same descriptors? If so we would never even be able to identify the broken devices if a work-around could be could be found. A quick test you could do (before reducing buffer sizes and urb counts) is to see what happens if you pace the writes to the device. Say if your test program writes one byte per second? Are more bytes received then? Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420091825.GA21315@localhost
Re: Auto-loading lxfb on OLPC XO systems
On Sat, 2013-04-20 at 03:28 +0100, Ben Hutchings wrote: [x86 XO systems need a framebuffer driver which udev blacklists] This will result in a regression when upgrading one of these systems from squeeze. (Although I don't think Debian kernel images have ever had complete support for them.) I've opened bug #705784 for this against udev, and Marco has said he's willing for me to NMU it. Alternately, in the kernel, I can revert the change to a module, or rename the module to evade the blacklist, but neither of those is particularly nice. But I think any kernel changes now are going to be too disruptive to the installer. A udev change might still be considered too disruptive in any case; CCing Cyril to see if he has any strong opinions. Regards, Adam -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366463898.23177.17.ca...@jacala.jungle.funky-badger.org
Re: Firmware versions for Intel Wireless 6005/6205
On Thu, 2013-04-18 at 04:29 +0100, Ben Hutchings wrote: (a) Update firmware-iwlwifi to include the new firmware. Slightly risky as our users haven't been testing it. (b Change the driver to request firmware ABI 5 then 4. Trivial code change, and only has a negative effect for users that installed firmware-iwlwifi from experimental. (c) Change the driver to request firmware ABI 5, then 6, then 4. Bigger code change; allows people to use the new firmware if they want it but not if they install the firmware-iwlwifi package (as that will have both ABI 5 and ABI 6 until post-jessie). I think (b) looks like the only viable option. Is this a significant enough issue to not consider (at least) one of (d) Postponing the fix to r1 (e) Documenting the issue ? Presumably (b) implies a new kernel upload and therefore d-i respin? Regards, Adam -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366464264.23177.21.ca...@jacala.jungle.funky-badger.org
Bug#705811: Hibernation fails with ATI Radeon 9100 with KMS enabled and non-free firmware missing
Source: linux Version: 3.2.41-2 ATI Radeon 9100 is an old R200-based card, which is expected to work fine with KMS without non-free firmware installed [1], and indeed it does, except one thing: the system freezes during hibernation. After I execute pm-hibernate, the monitor goes into stand-by mode, the HDD LED stays active for about 10 seconds, just like during normal hibernation process, then it switches off... and nothing happens. Pressing Ctrl-Alt-Del and Alt-SysRq-B has no effect, so the hardware reset button is the only option available. This leads to an inevitable loss of all unsaved data with a risk of filesystem corruption. The system hibernates and resumes just fine, if booted with either or both: - firmware-linux-nonfree package installed; - radeon.modeset=0 kernel option. In both cases the monitor doesn't go into stand-by mode during hibernation and stays active until poweroff. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697229 -- Алексей Шилин
Re: Firmware versions for Intel Wireless 6005/6205
On Sat, 2013-04-20 at 14:24 +0100, Adam D. Barratt wrote: On Thu, 2013-04-18 at 04:29 +0100, Ben Hutchings wrote: (a) Update firmware-iwlwifi to include the new firmware. Slightly risky as our users haven't been testing it. (b Change the driver to request firmware ABI 5 then 4. Trivial code change, and only has a negative effect for users that installed firmware-iwlwifi from experimental. (c) Change the driver to request firmware ABI 5, then 6, then 4. Bigger code change; allows people to use the new firmware if they want it but not if they install the firmware-iwlwifi package (as that will have both ABI 5 and ABI 6 until post-jessie). I think (b) looks like the only viable option. Is this a significant enough issue to not consider (at least) one of (d) Postponing the fix to r1 (e) Documenting the issue ? Presumably (b) implies a new kernel upload and therefore d-i respin? Yes. I've made the change in svn, but I'm happy to release-note this for r0. Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Re: Firmware versions for Intel Wireless 6005/6205
On Sat, 2013-04-20 at 14:33 +0100, Ben Hutchings wrote: On Sat, 2013-04-20 at 14:24 +0100, Adam D. Barratt wrote: On Thu, 2013-04-18 at 04:29 +0100, Ben Hutchings wrote: (b Change the driver to request firmware ABI 5 then 4. Trivial code change, and only has a negative effect for users that installed firmware-iwlwifi from experimental. [...] Is this a significant enough issue to not consider (at least) one of (d) Postponing the fix to r1 (e) Documenting the issue [...] Presumably (b) implies a new kernel upload and therefore d-i respin? Yes. I've made the change in svn, but I'm happy to release-note this for r0. Thanks. Avoiding a respin at this stage would definitely be preferable. Regards, Adam -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366465206.23177.25.ca...@jacala.jungle.funky-badger.org
Bug#705788: fb-modules-3.2.0-4-486-di: please include viafb module for OLPC XO-1.5 support in d-i
Control: tag -1 patch
On Fri, 2013-04-19 at 22:07 -0700, Andres Salomon wrote:
Package: fb-modules-3.2.0-4-486-di
Version: 3.2.41-2
The OLPC XO-1.5 doesn't support VESA. It needs the viafb driver in
order to get display output. Similar to #705780, please consider
including viafb.ko in the fb-modules udeb.
I just tried loading viafb on a VIA Epia board (Unichrome CLE266)
running squeeze, and the console is now broken. I can see the GRUB boot
messages (from weeks ago) and a mess of dots in various colours.
The module also has a whole lot of parameters which suggest that it may
need board-specific configuration. So I don't think we can allow it to
be autoloaded on the whole range of device IDs it claims.
What if we apply a patch (attached) to match the specific subsystem ID
on the XO 1.5? (I got this from the Openchrome source so hopefully it's
correct.) This still leaves us needing to update udev and then worry
about kernel vs udev versions, but it should cover the installer.
Ben.
--
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
From: Ben Hutchings b...@decadent.org.uk
Date: Sat, 20 Apr 2013 15:52:02 +0100
Subject: viafb: Autoload on OLPC XO 1.5 only
Bug-Debian: http://bugs.debian.org/705788
It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match. Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.
However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.
---
--- a/drivers/video/via/via-core.c
+++ b/drivers/video/via/via-core.c
@@ -754,7 +754,14 @@ static struct pci_device_id via_pci_tabl
.driver_data = UNICHROME_VX900 },
{ }
};
-MODULE_DEVICE_TABLE(pci, via_pci_table);
+
+static const struct pci_device_id via_pci_autoload_table[] __initconst = {
+ /* OLPC XO 1.5 */
+ { PCI_DEVICE(PCI_VENDOR_ID_VIA, UNICHROME_VX855_DID),
+ .subvendor = 0x152d, .subdevice = 0x0833 },
+ { }
+};
+MODULE_DEVICE_TABLE(pci, via_pci_autoload_table);
static struct pci_driver via_driver = {
.name = viafb,
signature.asc
Description: This is a digitally signed message part
Processed: Re: Bug#705788: fb-modules-3.2.0-4-486-di: please include viafb module for OLPC XO-1.5 support in d-i
Processing control commands: tag -1 patch Bug #705788 [fb-modules-3.2.0-4-486-di] fb-modules-3.2.0-4-486-di: please include viafb module for OLPC XO-1.5 support in d-i Added tag(s) patch. -- 705788: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705788 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b705788.136647048021838.transcr...@bugs.debian.org
Bug#705788: fb-modules-3.2.0-4-486-di: please include viafb module for OLPC XO-1.5 support in d-i
On Sat, 20 Apr 2013 16:07:47 +0100 Ben Hutchings b...@decadent.org.uk wrote: Control: tag -1 patch On Fri, 2013-04-19 at 22:07 -0700, Andres Salomon wrote: Package: fb-modules-3.2.0-4-486-di Version: 3.2.41-2 The OLPC XO-1.5 doesn't support VESA. It needs the viafb driver in order to get display output. Similar to #705780, please consider including viafb.ko in the fb-modules udeb. I just tried loading viafb on a VIA Epia board (Unichrome CLE266) running squeeze, and the console is now broken. I can see the GRUB boot messages (from weeks ago) and a mess of dots in various colours. The module also has a whole lot of parameters which suggest that it may need board-specific configuration. So I don't think we can allow it to be autoloaded on the whole range of device IDs it claims. What if we apply a patch (attached) to match the specific subsystem ID on the XO 1.5? (I got this from the Openchrome source so hopefully it's correct.) This still leaves us needing to update udev and then worry about kernel vs udev versions, but it should cover the installer. The idea seems fine to me, though I think that VX855 is in other systems besides OLPC ones. Cc'ing Daniel, maybe he has some other ideas? Note that simply including the module in debian-installer doesn't cause the module to be loaded as far as I can tell (even with a PCI device id match). It still needs to be manually loaded, so it would seem safe for d-i. signature.asc Description: PGP signature
Bug#698829: kernel swap after upgrade to 3.2.23-1~bpo60+2
Hello Ben, On Thu, Apr 18, 2013 at 7:09 AM, Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2013-04-02 at 10:59 +0200, Sandro Tosi wrote: Hello Ben, i'm a collegue of Daniele and I'd like to add some more information on this issue, which we're still facing with 3.2.35-2~bpo60+1 . [...] Please let us know if you need more information, if we can run some diagnostics or try some solutions, it's really important for us to get that fixed. Sorry, I can't afford to spend any more time on this bug. Thanks for your honest reply. We reached you also because you're the current maintainer of upstream 3.2 branch and because we didn't want Wheezy to release with this bug. We're testing a custom-built 3.7.10 kernel and the slab memory leak seems to be gone (but we're facing with system freezes). Can you please propose what would be the best way for us (and for Debian) to have this problem fixed? Thanks in advance, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB4XWXwXyiMs7o3_aj7sf6S+c1bOKcSoWYOd_ODU=yvtzw8...@mail.gmail.com
Bug#698829: kernel swap after upgrade to 3.2.23-1~bpo60+2
Sandro Tosi wrote: We reached you also because you're the current maintainer of upstream 3.2 branch and because we didn't want Wheezy to release with this bug. We're testing a custom-built 3.7.10 kernel and the slab memory leak seems to be gone (but we're facing with system freezes). If you can run a reverse bisect to find which commit or configuration change fixed it, then I'd be happy to review the patch that that finds and propose it if appropriate for upstream inclusion. Let me know if you would like details about how that's done. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420214556.GD8586@elie.Belkin
Bug#700333: Stack trace
Stack trace picture is here: http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg Vitaliy reported that his system crashes when suspending to disk. This was a regression from 3.2 to 3.7, and remains in 3.8. Some details of this system are in the bug log at http://bugs.debian.org/700333. The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs. The HPET interrupt handler was called immediately after it was registered for CPU 2 (?), before the corresponding clock_event_device was registered. Seems like an obvious race condition, but then shouldn't the HPET have been stopped while the CPU was previously offlined? And it's strange that this system apparently hits the race quite reliably. Anyone? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cc9020446ea75ed733ec96c505039...@yourcmc.ru
Bug#698829: kernel swap after upgrade to 3.2.23-1~bpo60+2
Hello Jonathan, On Sat, Apr 20, 2013 at 11:45 PM, Jonathan Nieder jrnie...@gmail.com wrote: If you can run a reverse bisect to find which commit or configuration change fixed it, then I'd be happy to review the patch that that finds and propose it if appropriate for upstream inclusion. I don't know how affordable that is: we're only able to replicate it on production env (not exactly the best place to run tests) and after at least 7/10 days of live traffic; the time it will take to get to change fixing the behavior could be huge. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAB4XWXydbJiZv9u_nGy=NZ-1gbkHT8E=+Qtc1_N=vytj0ud...@mail.gmail.com
Bug#698829: kernel swap after upgrade to 3.2.23-1~bpo60+2
Sandro Tosi wrote: I don't know how affordable that is: we're only able to replicate it on production env (not exactly the best place to run tests) and after at least 7/10 days of live traffic In that case, a good first step would be to try to replicate it in a more artificial setting, I guess. Then you'd be able to bisect or get help from upstream. Sorry I don't have any better ideas. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420215858.GE8586@elie.Belkin
Bug#698829: kernel swap after upgrade to 3.2.23-1~bpo60+2
On Sat, 2013-04-20 at 23:32 +0200, Sandro Tosi wrote: Hello Ben, On Thu, Apr 18, 2013 at 7:09 AM, Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2013-04-02 at 10:59 +0200, Sandro Tosi wrote: Hello Ben, i'm a collegue of Daniele and I'd like to add some more information on this issue, which we're still facing with 3.2.35-2~bpo60+1 . [...] Please let us know if you need more information, if we can run some diagnostics or try some solutions, it's really important for us to get that fixed. Sorry, I can't afford to spend any more time on this bug. Thanks for your honest reply. We reached you also because you're the current maintainer of upstream 3.2 branch and because we didn't want Wheezy to release with this bug. We're testing a custom-built 3.7.10 kernel and the slab memory leak seems to be gone (but we're facing with system freezes). Can you please propose what would be the best way for us (and for Debian) to have this problem fixed? If you want to just , you have the option of using the 3.8 kernel from experimental and then, once wheezy is out, from testing or wheezy-backports. But if you want to help get this fixed in the standard packages, which would then presumably help some other users, the thing to do would be what Jonathan says - find a way to replicate the problem on a test system, and then bisect to find out when it was fixed. You said that it takes 7-10 days, but it seems that this is the time it takes to become a serious problem. The leak appears to grow fast enough that it should be possible to detect it much earlier if you monitor slabinfo. Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Bug#700333: Stack trace
+ tglx. On Sun, Apr 21, 2013 at 01:38:33AM +0400, vita...@yourcmc.ru wrote: Stack trace picture is here: http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg Vitaliy reported that his system crashes when suspending to disk. This was a regression from 3.2 to 3.7, and remains in 3.8. Some details of this system are in the bug log at http://bugs.debian.org/700333. The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs. The HPET interrupt handler was called immediately after it was registered for CPU 2 (?), before the corresponding clock_event_device was registered. Seems like an obvious race condition, but then shouldn't the HPET have been stopped while the CPU was previously offlined? And it's strange that this system apparently hits the race quite reliably. Anyone? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420225516.gb4...@pd.tnic
Issues with RTL8191SEvB on Debian 6
Hello all How are you doing? People I have a boring problem for few months with my Wireless LAN driver card RTL8191SEvB (Realtek) on Debian6 x64 so.. I dont know what I can do more Could you help me to do working my Wi-Fi please? ( I don't like cable... and I dont want to use Windows) :) Thanks a lot. Following some useful information: #uname -a *Linux 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.35-2~bpo60+1 unknown unknown GNU/Linux * #lspci -v | grep *RTL* *05:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)* * Subsystem: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller* * Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-* * Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx-* * Interrupt: pin A routed to IRQ 18* * Region 0: I/O ports at 3000 [size=256]* * Region 1: Memory at f050 (32-bit, non-prefetchable) [size=16K]* * Capabilities: [40] Power Management version 3* * Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold-)* * Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-* * Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+* * Address: Data: * * Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00* * DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 512ns, L1 64us* * ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-* * DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-* * RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-* * MaxPayload 128 bytes, MaxReadReq 512 bytes* * DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-* * LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 64us* * ClockPM- Surprise- LLActRep- BwNot-* * LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+* * ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-* * LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-* * Capabilities: [100 v1] Advanced Error Reporting* * UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-* * UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-* * UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-* * CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+* * CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+* * AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-* * Capabilities: [140 v1] Virtual Channel* * Caps: LPEVC=0 RefClk=100ns PATEntryBits=1* * Arb: Fixed- WRR32- WRR64- WRR128-* * Ctrl: ArbSelect=Fixed* * Status: InProgress-* *VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-* * Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-* * Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff* * Status: NegoPending- InProgress-* * Capabilities: [160 v1] Device Serial Number 88-55-22-fe-ff-4c-e0-00* * * *--* *Tárcio Sales* *Email:* *ta tbs_sa...@ig.com.brrc...@gmail.com* *MSN:* tarc...@outlook.com *Skype: *starcio3030 *Cell:* +55 (92) 9175- http://meadiciona.com/tarcio_sales
